요구사항 정리와 범위 자르기

기능과 비기능으로 나누고 범위 밖을 먼저 자릅니다.

그다음 각 비기능 숫자가 어떤 설계를 강제하는지 말합니다. 최대 50GB 는 단일 요청 상한을 넘으므로 멀티파트가 필수이고, 하루 40TB 는 앱 서버가 통과시킬 수 없으므로 직접 업로드입니다.

흔한 실수: 비기능 요구사항을 "고가용성, 확장성, 저지연" 처럼 형용사로 나열하는 것. 숫자와 그 숫자가 강제하는 결론이 없으면 아무 설계도 정해지지 않습니다. 면접관은 형용사가 아니라 그 값에서 무엇이 따라오는지를 봅니다.

건수가 아니라 바이트입니다. 이 구분이 설계를 바꿉니다.

하루 200만 건 를 초로 나누면 약 23건
피크를 평균의 5배로 잡아도 초당 100건 남짓
같은 기간 전송량은 약 40TB

초당 100건은 어떤 데이터베이스든 받아냅니다. 메타데이터 쓰기는 병목이 아닙니다. 40TB 는 앱 서버가 통과시킬 수 있는 양이 아닙니다.

그래서 설계의 첫 결정이 "파일이 앱을 지나가지 않게 한다" 가 됩니다.

흔한 실수: 초당 요청 수만 계산하고 끝내는 것. 파일 업로드는 요청 하나가 무거운 종류라서, 건수로 환산한 숫자만 보면 병목을 반대로 짚습니다.

아닙니다. 평균이 20MB 이므로 대부분의 파일에는 과설계입니다.

멀티파트는 공짜가 아닙니다. 업로드를 시작하고, 파트마다 서명을 받고, 완료를 알리고, 중단된 조각을 정리하는 상태 관리가 붙습니다.

그래서 설계는 두 갈래가 됩니다. 클라이언트가 파일 크기를 보고 경로를 고르고, 서버는 둘 다 받아들입니다.

흔한 실수: 최대값만 보고 하나의 경로로 통일하는 것. 요구사항에 평균이 함께 적혀 있는 이유가 이것입니다. 최대는 무엇이 가능해야 하는지를 정하고, 평균은 무엇이 흔한지를 정합니다. 흔한 경우를 무겁게 만들면 전체가 느려집니다.

업로드를 받는 쪽을 막지 않고, 잠깐 어긋나는 것을 받아들인다는 뜻입니다.

구체적으로는 이렇게 나타납니다.

반대 선택도 가능합니다. 결제나 재고라면 어긋난 상태를 보이는 대신 쓰기를 거절하는 편이 맞습니다. 같은 구조에서 이 우선순위만 바꿔도 설계가 달라집니다.

파일 공유에서 가용성을 고르는 이유는 실패 비용의 비대칭입니다. 업로드가 거절되면 사용자는 작업을 잃지만, 목록에 몇 초 늦게 나타나는 것은 대개 눈치채지 못합니다.

흔한 실수: 가용성 우선을 "장애가 없다" 로 이해하는 것. 무엇을 포기했는지를 함께 말해야 합니다. 여기서 포기한 것은 방금 쓴 것을 즉시 읽을 수 있다는 보장입니다.