파일 업로드 시스템 설계 면접 퀴즈

시스템 설계는 요구사항을 기능과 비기능으로 나누고 범위 밖을 먼저 잘라내는 것에서 시작합니다. 이 토픽은 아래 하나의 요구사항을 끝까지 풉니다.

기능 요구사항과 범위 밖

범위 밖을 말하는 것이 실력입니다. 다 만들겠다고 하면 무엇도 깊게 못 하고, 면접에서는 우선순위를 못 정하는 것으로 읽힙니다.

비기능 요구사항이 설계를 정한다

숫자를 그냥 적어두면 장식입니다. 각 숫자가 어떤 결론을 강제하는지까지 가야 요구사항 정리가 끝난 것입니다.

평균값은 반대로 읽는다

평균 20MB 라는 숫자는 과설계를 막는 쪽으로 씁니다. 최대가 50GB 라서 멀티파트가 필요하지만, 실제 파일 대부분은 한 번에 올려도 됩니다.

그래서 설계는 하나가 아니라 두 갈래가 됩니다. 작은 파일은 단순 경로로, 큰 파일만 멀티파트로 보냅니다. 최대값만 보고 모든 파일을 멀티파트로 처리하면 대부분의 요청에 불필요한 왕복과 상태 관리를 붙이는 셈입니다.

용량 산정은 자릿수만 맞으면 된다

하루 200만 건 를 초로 환산하면 약 23건입니다. 피크를 평균의 다섯 배로 잡아도 초당 100건 남짓입니다. 쓰기 자체는 크지 않고, 문제는 건수가 아니라 바이트입니다.

이 구분이 설계를 바꿉니다. 초당 100건은 어떤 데이터베이스든 받아냅니다. 하루 40TB 는 앱 서버가 통과시킬 수 없습니다. 그래서 병목은 메타데이터가 아니라 파일 전송 경로입니다.

파일 업로드 설계는 파일이 어디를 지나가는지로 갈립니다. 앱 서버 디스크에 두는 방식에서 오브젝트 스토리지로, 다시 클라이언트가 스토리지로 직접 올리는 방식으로 올라갑니다. 각 칸이 앞 칸의 특정 결함을 고칩니다.

1번 칸이 왜 깨지나

앱 서버 디스크에 저장하면 세 가지가 동시에 문제가 됩니다.

마지막이 가장 비쌉니다. 서버를 늘리는 것만으로 해결되지 않는 문제가 되기 때문입니다.

2번 칸이 남기는 것

파일을 오브젝트 스토리지에 두면 용량과 소실과 무상태가 한 번에 풀립니다. 서버는 파일을 들고 있지 않으므로 언제든 교체할 수 있습니다.

그런데 파일이 여전히 앱 서버를 통과합니다. 앱이 받아서 다시 보내므로 대역폭과 메모리를 앱이 내고, 요청 하나가 오래 붙잡히므로 동시 업로드가 늘면 스레드가 먼저 바닥납니다.

요구사항의 숫자가 이 칸의 한계를 보여줍니다. 하루 40TB 가 앱을 통과해야 하고, 최대 50GB 파일 하나가 요청 하나를 아주 오래 붙잡습니다. 파일을 저장하지 않아도 지나가게 하는 것만으로 앱이 병목입니다.

3번 칸으로 올라가는 이유

앱 서버는 권한을 확인하고 서명된 주소만 내려줍니다. 파일은 클라이언트가 스토리지로 직접 보냅니다. 앱 서버가 지나가는 경로에서 빠지므로 파일 크기가 앱의 부담과 무관해집니다.

대신 새 숙제가 생깁니다. 파일이 앱을 거치지 않으니 앱은 업로드가 끝났는지 모릅니다. 검증도 못 하고 메타데이터도 기록하지 못합니다. 이 숙제를 푸는 것이 다음 개념들입니다.

사다리를 오르지 않아도 되는 경우

3번이 항상 정답은 아닙니다. 하루 열 건에 100KB 짜리 설정 파일이라면 1번으로 충분하고, 서명 발급과 완료 통보를 만드는 것이 오히려 손해입니다. 선택을 정하는 것은 기술의 새로움이 아니라 파일 크기와 동시 업로드 수입니다.

앱 서버는 권한을 확인하고 서명된 주소만 내려줍니다. 파일은 클라이언트가 스토리지로 직접 보내고, 스토리지가 그 서명을 검증합니다. 앱이 경로에서 빠지므로 파일 크기가 앱의 부담과 무관해집니다.

그 대가로 앱은 업로드를 보지 못합니다. 서명이 무엇을 담고 무엇을 못 하는지를 아는 것이 이 개념의 전부입니다.

서명에 조건을 박는다

서명은 단순한 접근 허가가 아니라 조건이 붙은 허가입니다. 조건을 서명에 넣으면 스토리지가 대신 거절해 줍니다.

만료는 짧게 잡습니다. 업로드를 시작할 시간만 있으면 되고, 큰 파일은 시작 후 오래 걸려도 됩니다. 서명이 만료돼도 진행 중인 전송은 끊기지 않기 때문입니다.

앱이 모른다는 문제

파일이 앱을 거치지 않으니 앱은 세 가지를 모릅니다. 업로드가 끝났는지, 무엇이 올라갔는지, 그것이 유효한지입니다.

그래서 완료 통보 경로를 따로 만듭니다. 방법은 둘입니다.

실무에서는 둘을 함께 씁니다. 빠른 경로는 클라이언트 통보, 안전망은 스토리지 이벤트입니다. 한쪽만 두면 통보를 못 받은 파일이 스토리지에만 남습니다.

클라이언트 검사는 통제가 아니다

서명을 발급할 때 클라이언트가 보낸 파일명과 크기를 그대로 믿으면 안 됩니다. 클라이언트는 고쳐 보낼 수 있는 쪽입니다. 조건은 서명 안에 박아야 스토리지가 강제합니다.

이 구분이 면접에서 자주 갈립니다. 크기 제한을 화면에서만 하고 서명에 넣지 않으면, 요청을 직접 만들어 보내는 것으로 우회됩니다.