대용량 파일 업로드를 위한 Presigned URL

Presigned URL이 필요한 이유

파일 업로드를 API 서버가 직접 중계하면 파일 크기가 커질수록 서버가 불필요한 병목이 된다. 네트워크 대역폭, 메모리, 타임아웃 관리 비용이 모두 서버 쪽으로 몰리기 때문이다.

Presigned URL은 이 문제를 해결하기 위해, 서버가 스토리지 접근 권한만 짧게 위임하고 실제 파일 전송은 클라이언트가 스토리지로 직접 보내도록 만든 방식이다.

구조는 보통 다음과 같다.

1. 클라이언트가 업로드 요청을 보낸다.
2. 애플리케이션 서버가 업로드 대상과 만료 시간을 검토한다.
3. 서버가 Presigned URL을 발급한다.
4. 클라이언트가 그 URL로 스토리지에 직접 업로드한다.
5. 서버는 메타데이터와 업로드 상태만 관리한다.

어떤 점이 좋은가

• 서버가 파일 바이트를 중계하지 않는다.
• 대용량 업로드에서 API 서버 부담이 크게 줄어든다.
• 모바일, 브라우저, 외부 클라이언트에서도 구조가 단순하다.
• 업로드 권한을 짧은 시간 동안만 제한적으로 위임할 수 있다.

설계할 때 중요한 포인트

1. 업로드 성공과 비즈니스 완료를 분리

S3 업로드가 성공했다고 해서 비즈니스적으로 “파일 등록 완료”라고 보면 안 된다. 바이러스 검사, MIME 검증, 메타데이터 저장, 후처리 큐 등록 같은 작업이 뒤따를 수 있다.

즉 업로드 완료와 도메인 처리 완료는 다른 상태로 관리하는 편이 안전하다.

2. 키를 클라이언트가 임의로 정하지 않게 하기

업로드 대상 키를 사용자가 자유롭게 정하게 두면 덮어쓰기, 경로 추측, 다중 테넌트 충돌 문제가 생길 수 있다. 보통은 서버가 키 규칙을 정하고 발급한다.

3. 만료 시간을 짧게 유지

URL은 짧게 발급할수록 안전하다. 특히 업로드 권한은 오래 열어둘 이유가 없다.

4. 대용량이면 multipart를 고려

파일이 커질수록 단일 PUT보다 multipart upload가 더 안정적이다. 실패 구간만 재시도할 수 있고, 네트워크 불안정 상황에도 유리하다.

자주 하는 실수

• 업로드 URL만 발급하고 이후 검증 절차가 없다.
• 파일 크기 제한, MIME 제한, 확장자 정책이 없다.
• 클라이언트가 원하는 경로로 아무 키나 업로드할 수 있다.
• 서버가 실제 업로드 여부를 추적하지 않는다.

Presigned URL은 스토리지 접근을 우회시키는 것이지, 업로드 정책 자체를 없애는 것이 아니다.

Presigned URL과 STS의 차이

Presigned URL은 특정 객체 요청 하나에 가까운 제한된 권한을 위임한다. 반면 STS 임시 자격 증명은 더 넓은 권한 범위를 일정 시간 부여하는 방식이다.

일반적인 웹 업로드에서는 Presigned URL이 단순하고 통제하기 쉽다. 여러 객체 조작이나 SDK 기반 복합 작업이 필요할 때는 STS가 더 맞을 수 있다.

정리

Presigned URL의 핵심은 “파일은 스토리지로 직행시키고, 서버는 권한과 상태만 관리한다”는 데 있다. 대용량 업로드 아키텍처에서 서버 병목을 줄이는 가장 실용적인 패턴 중 하나다.