AWS 서버리스 파일 저장소 — S3·DynamoDB·SQS·Lambda로 확장하는 구조

핵심 메시지

• 브라우저가 파일을 서버 디스크에 쌓는 전통적 방식은 사용자가 늘면 디스크가 차서 무너진다.
• S3에는 파일 바이트를, DynamoDB에는 이름·크기·상태 같은 메타데이터를 나눠 저장한다.
• 업로드는 한 시간짜리 사전 서명 URL로 처리해 S3 버킷을 외부에 직접 노출하지 않는다.
• S3 이벤트를 SQS 큐로 받아 폭주와 실패를 흡수하고, Lambda가 이를 처리해 DynamoDB를 갱신한다.
• API Gateway를 유일한 정문으로 두고 API 키와 사용량 계획으로 요청을 통제한다.

쉽게 이해하기

영상은 나만의 구글 드라이브 같은 파일 저장 앱을 만든다. 흔한 방식은 브라우저가 파일을 서버로 올리면 서버가 디스크에 쓰고 기록을 남기는 것이다. 처음에는 잘 돌아가지만 수백 명이 한꺼번에 업로드하면 서버 디스크가 가득 차 전체가 무너진다. 그래서 AWS 위에 완전한 서버리스 백엔드로, 수백만 개의 파일까지 확장되도록 설계한다.

가장 먼저 IAM으로 누가 무엇을 할 수 있는지 정한다. 컴퓨트 서버용과 함수용, 두 개의 역할을 만들어 각자 꼭 필요한 권한만 부여하고 그 이상은 주지 않는다. 어디에도 비밀번호나 액세스 키를 심지 않는다. 파일 자체는 저렴하고 내구성 있으며 사실상 무한한 S3 객체 스토리지에 저장하되, 퍼블릭 접근 차단은 켜 둔다. 아무도 버킷에 직접 닿아서는 안 되기 때문이다.

대신 업로드가 필요하면 API가 웹 앱에 사전 서명 URL을 건넨다. 이는 한 파일을 한 시간 동안 한 번 업로드하도록 허용하는 임시 서명 링크로, 웹 앱은 이 링크로 파일을 안전하게 S3로 스트리밍한다. 바이트를 저장하는 것은 절반일 뿐이라, 무엇이 들어 있는지는 별도로 알아야 한다. 수백만 객체를 매번 스캔하면 느리므로, 이름·크기·상태 같은 메타데이터만 빠른 키-값 테이블인 DynamoDB에 둔다. 바이트는 S3에, 그에 관한 사실은 DynamoDB에 사는 셈이다.

테이블을 최신 상태로 유지하는 방법이 이벤트 파이프라인이다. 파일이 도착하는 순간 S3가 이벤트를 발생시키고, 이를 SQS 큐로 보낸다. 큐를 두는 이유는 업로드가 몰리거나 실패할 수 있기 때문이다. 큐는 한꺼번에 쏟아지는 이벤트를 안전하게 담아 두고 실패한 것은 재시도해 아무것도 잃지 않는다. 이 큐가 첫 번째 Lambda인 메타데이터 처리기를 깨우고, 이 함수는 이벤트를 읽어 파일 이름과 크기를 뽑아 DynamoDB에 새 행을 쓴다. 파일→S3, 이벤트→SQS, 큐→Lambda, Lambda→DynamoDB로 이어지는 쓰기 경로가 완전히 스스로 돌아간다.

읽기와 명령 쪽에는 두 번째 Lambda인 드라이브 API가 있어 업로드·다운로드용 사전 서명 링크를 발급하고, DynamoDB에서 파일 목록을 조회하며, S3와 테이블 양쪽에서 파일을 지운다. Lambda는 인터넷에 직접 열려 있을 수 없으므로 앞에 API Gateway라는 정문 하나를 둔다. 게이트웨이는 업로드 링크 요청, 다운로드 링크 요청, 목록 조회, 삭제라는 네 개의 라우트를 노출하고, 각 라우트는 사용량 계획으로 요청 수를 제한하는 API 키 뒤에 잠긴다. 사용자가 실제로 보는 화면은 작은 EC2 인스턴스에서 도는 가벼운 Flask 웹 앱 대시보드다.

주요 인사이트

• 바이트와 메타데이터를 S3와 DynamoDB로 분리하면, 수백만 객체를 매번 스캔하지 않고도 빠르게 파일 목록을 보여줄 수 있다.
• 사전 서명 URL은 버킷을 공개하지 않으면서도 임시·단건·시간 제한 업로드를 가능하게 해 보안과 확장성을 동시에 확보한다.
• SQS 큐는 업로드 폭주를 흡수하고 실패를 재시도하는 완충 장치로, 이벤트 유실을 막는 핵심이다.
• IAM 최소 권한 원칙과 API 키·사용량 계획으로, S3와 DynamoDB는 결코 외부에 직접 노출되지 않는다.
• 각 구성 요소가 정확히 한 가지 일만 맡아 서로 느슨하게 연결되므로, 저장소가 스스로 확장된다.

자주 묻는 질문

관련 AI 소식