탄력적이고 확장 가능한 AWS Lambda + S3 아키텍처 구축

Source: Dev.to

저는 AWS Lambda와 Amazon S3가 백본을 이루는 서버리스 시스템을 여러 번 구축하고 검토했습니다—파일 수집 파이프라인, 미디어 처리 플랫폼, 이벤트‑드리븐 API 등. 시간이 지나면서 반복되는 문제를 발견했습니다: 사람들은 Lambda + S3를 너무 단순하게(“업로드 시 함수를 트리거한다” 정도) 보거나, 다이어그램이 복잡해지면 너무 추상적으로 여깁니다.

이 글에서는 실제 사례와 최신 AWS 기능을 활용해 복잡하지만 이해하기 쉬운 Lambda + S3 아키텍처를 설계하는 방법을 단계별로 설명합니다. 또한 Lucidchart에서 이 아키텍처를 어떻게 그리는지 보여드려, 명확하고 폭넓게 설명할 수 있도록 하겠습니다.

해결하고자 하는 과제

서버리스 시스템을 설계할 때 보통 다음 세 가지를 원합니다:

• 사용자와 클라이언트를 위한 간단한 진입점
• 백그라운드에서 비동기적이고 복원력 있는 처리
• 시스템이 확장될 때 비용과 운영을 강력히 제어

개별 AWS 서비스를 따로 생각하기보다 아키텍처를 레이어로 나눕니다. 이 사고 모델은 Lucidchart 다이어그램과도 매우 잘 맞습니다.

Edge / Client 레이어

요청이 시작되는 곳:

• 웹 또는 모바일 클라이언트
• CLI 도구 또는 서드파티 웹훅

대부분의 경우 클라이언트는 Lambda에 직접 접근하지 않습니다. 깔끔한 경계를 유지하는 것이 좋습니다.

API & Ingress 레이어

여기서는 보통 다음을 사용합니다:

• API Gateway – REST 또는 HTTP API용
• Lambda Function URLs – 매우 제한된 내부 엔드포인트용
• CloudFront + WAF – API가 공개되어 보호가 필요할 때

이 레이어는 인증, 검증, 라우팅만 담당하고 복잡한 로직은 처리하지 않습니다.

Compute 레이어 (Lambda)

Lambda가 빛을 발하는 곳입니다. 책임을 여러 함수에 나누어 두는 것이 일반적입니다:

• Request Lambdas – 빠르고 동기적인 작업(인증, 프리사인드 URL)
• Processor Lambdas – 비동기 워커(이미지 리사이즈, 메타데이터 추출)
• Indexer Lambdas – 백그라운드 작업(검색 인덱싱, 임베딩)

Storage & Data Plane (S3‑centric)

시스템의 핵심이 되는 부분입니다. 보통 목적이 명확한 여러 버킷을 사용합니다:

• ingest-bucket – 원시 업로드 파일
• processed-bucket – 파생 아티팩트
• archive-bucket – 장기 보관

제가 적극적으로 활용하는 주요 S3 기능:

• 프리사인드 URL을 이용한 직접 업로드(클라이언트가 Lambda를 우회)
• 비용을 자동으로 최적화하는 S3 Intelligent‑Tiering
• 실시간 변환을 위한 S3 Object Lambda
• 대규모 재처리를 위한 S3 Batch Operations + Lambda

아래는 위 구조를 시각화한 인프라 다이어그램입니다:

마무리 생각

Lambda와 S3는 종종 단순한 서비스로 소개되지만, 함께 사용하면 매우 정교한 시스템을 구현할 수 있습니다. 핵심 포인트는 다음과 같습니다:

• 동기 경로는 최소화하고 작게 유지하기
• 나머지는 모두 이벤트로 전환하기
• S3가 가장 잘하는 일, 즉 대규모 확장 및 저비용 저장을 맡기기