AWS Certified Developer - Associate (DVA-C02) #2 Domain 1-1 AWS 서비스로 개발: Lambda 깊이

#1 시험 소개에서 DVA-C02의 무게 중심은 서버리스이고, 그 중심의 중심은 Lambda라고 했습니다. 개발 도메인이 32%로 가장 크며, Lambda는 그 안에서 가장 자주 등장하는 서비스입니다. 시험은 Lambda를 “함수를 올리는 곳"이 아니라 **“어떤 이벤트가 어떻게 함수를 호출하고, 실패하면 어디로 가며, 동시 실행은 어떻게 제어되는가”**라는 동작 문제로 묻습니다.

이 글은 Lambda의 기본 개념(런타임,핸들러)은 빠르게 지나가고, 호출 유형,동시성,실패 처리처럼 시험에서 정답을 가르는 지점에 시간을 씁니다.

세 가지 호출 유형 #

Lambda를 이해하는 가장 중요한 틀은 누가, 어떻게 호출하는가입니다. 호출 유형에 따라 재시도 동작과 실패 처리가 완전히 달라지므로, 시험은 이 구분을 반복해서 묻습니다.

동기 호출 #

호출자가 응답을 기다립니다. API Gateway가 Lambda를 호출하고 그 결과를 클라이언트에게 돌려주는 경우가 대표적입니다. Lambda가 오류를 던지면 재시도하지 않고 호출자에게 그대로 전달됩니다. 재시도 여부는 호출자(예: API Gateway, SDK)가 결정합니다.

비동기 호출 #

호출자는 이벤트를 Lambda의 내부 큐에 넣고 즉시 반환받습니다. S3가 객체 생성 이벤트로 Lambda를 부르거나, SNS가 메시지를 전달하는 경우입니다. 함수가 실패하면 Lambda가 자동으로 두 번 더 재시도(지연을 두고)하며, 그래도 실패하면 DLQ(Dead Letter Queue) 또는 Destination으로 보냅니다.

스트림 폴링(이벤트 소스 매핑) #

SQS,Kinesis,DynamoDB Streams는 Lambda를 직접 호출하지 않습니다. 대신 Lambda 서비스가 **이벤트 소스 매핑(Event Source Mapping)**으로 소스를 폴링해 배치를 가져온 뒤 함수를 호출합니다. SQS 표준 큐는 자동으로 폴링되며, 처리에 실패한 메시지는 가시성 시간 초과 후 다시 큐로 돌아오고, maxReceiveCount를 넘기면 DLQ로 이동합니다.

시험 함정: SQS의 DLQ는 큐 자체의 설정입니다. 비동기 호출의 DLQ는 Lambda 함수의 설정입니다. 둘은 위치가 다릅니다.

동시성(Concurrency) #

동시성은 같은 순간에 실행 중인 함수 인스턴스의 수입니다. 계정,리전마다 기본 동시 실행 한도(보통 1000)가 있고, 이를 함수들이 공유합니다. 시험은 동시성 제어의 두 옵션을 자주 묻습니다.

핵심 구분은 이것입니다. **예약 동시성은 “수량 보장/제한”**이고, **프로비저닝 동시성은 “미리 데워 두기”**입니다. “콜드 스타트로 첫 응답이 느리다"는 문제의 답은 예약 동시성이 아니라 프로비저닝 동시성입니다.

함수가 동시성 한도를 초과하면 Lambda는 추가 호출을 스로틀링합니다. 동기 호출에서는 429 TooManyRequestsException이 호출자에게 반환되고, 비동기 호출에서는 재시도 큐에 들어가 나중에 다시 시도됩니다.

콜드 스타트 #

새 실행 환경이 처음 만들어질 때, 코드 다운로드와 런타임 초기화에 걸리는 추가 지연이 콜드 스타트입니다. 줄이는 방법은 정해져 있습니다.

• 프로비저닝 동시성. 환경을 미리 초기화해 따뜻하게 유지.
• 패키지 크기 축소,핸들러 밖 초기화. DB 연결, SDK 클라이언트는 핸들러 바깥에서 한 번만 만들어 재사용.
• VPC 연결 최소화. 과거 병목이었으나 Hyperplane ENI 도입으로 크게 개선됨. 그래도 불필요한 VPC 연결은 피함.

핸들러 밖에서 초기화한 객체는 같은 실행 환경이 재사용되는 동안(warm) 유지됩니다. DB 커넥션을 핸들러 안에서 매번 새로 여는 코드는 안티 패턴입니다.

환경변수와 레이어 #

• 환경변수. 설정값을 코드와 분리해 주입합니다. 기본적으로 저장 시 암호화되며, 민감한 값은 KMS 고객 관리형 키로 암호화하거나 Parameter Store,Secrets Manager에서 런타임에 읽어 옵니다. 환경변수에 평문 비밀번호를 넣는 답안은 오답입니다.
• 레이어(Layer). 공통 라이브러리,의존성을 분리해 여러 함수가 공유합니다. 배포 패키지를 작게 유지하고 의존성을 한 곳에서 관리할 수 있습니다. 한 함수에 최대 5개까지 붙이며, 압축 해제 기준 총 250MB 한도에 포함됩니다.

버전과 별칭 #

Lambda는 코드를 게시하면 **불변 버전(version)**이 생기고, **별칭(alias)**으로 특정 버전을 가리킵니다. 별칭은 배포 전략에서 가중치 기반 카나리 배포의 핵심이 되므로, 여기서는 “별칭이 버전을 가리키는 포인터"라는 점만 잡아 둡니다.

실패 처리: DLQ와 Destination #

비동기 호출에서 모든 재시도가 실패하면 이벤트가 사라지지 않도록 보관해야 합니다.

Destination이 더 새롭고 권장되는 방식입니다. 성공,실패를 모두 라우팅할 수 있고, 실패 이벤트에 오류 컨텍스트가 더 풍부하게 담깁니다. DLQ는 실패 이벤트만 보관합니다.

멱등성(Idempotency) #

비동기,스트림 기반 호출은 같은 이벤트가 두 번 이상 전달될 수 있습니다(at-least-once). SQS 표준 큐, 비동기 재시도가 모두 중복을 만들 수 있으므로, 함수는 같은 입력으로 여러 번 실행돼도 결과가 같도록 설계해야 합니다.

• 멱등성 키(주문 ID 등)를 DynamoDB에 조건부 쓰기로 기록해 중복 처리를 막습니다.
• 결제,재고 차감처럼 부수 효과가 있는 작업일수록 멱등성 설계가 필수입니다.

이 주제는 #6 SDK 개발 패턴에서 더 다룹니다.

시험 출제 패턴 #

• “API Gateway가 호출한 Lambda가 실패하면 자동 재시도되는가?” → 동기 호출이므로 Lambda 자동 재시도 없음. 호출자가 처리.
• “S3 이벤트로 호출된 Lambda가 실패했다. 이벤트를 잃지 않으려면?” → 비동기 호출이므로 DLQ/Destination 설정.
• “함수의 첫 응답이 느리다(콜드 스타트). 해결책은?” → 프로비저닝 동시성.
• “특정 함수가 계정 전체 동시성을 잡아먹어 다른 함수가 스로틀링된다.” → 예약 동시성으로 격리.
• “DB 커넥션을 매 호출 새로 연다.” → 핸들러 밖에서 초기화해 재사용.
• “SQS가 같은 메시지를 두 번 전달했다.” → 멱등성 설계(표준 큐는 at-least-once).

자주 만나는 함정 #

1) 비동기 재시도 횟수를 동기에 적용 #

자동 2회 재시도는 비동기 호출의 동작입니다. 동기 호출은 Lambda가 재시도하지 않습니다.

2) 예약 동시성과 프로비저닝 동시성 혼동 #

예약 동시성은 수량을 확보·제한하는 옵션이고, 프로비저닝 동시성은 콜드 스타트를 제거합니다. 지연에 민감하다면 프로비저닝 동시성을 선택합니다.

3) DLQ 위치 혼동 #

SQS 트리거에서 DLQ는 큐 자체에 설정하고, 비동기 Lambda 호출에서 DLQ는 Lambda 함수에 설정합니다.

4) 환경변수에 비밀 평문 저장 #

민감 정보는 Secrets Manager/Parameter Store에서 읽거나 KMS로 암호화합니다.

정리 #

이번 글에서 잡은 것:

• 호출 유형. 동기(재시도 없음),비동기(자동 2회 + DLQ/Destination),스트림 폴링(이벤트 소스 매핑)
• 동시성. **예약(수량 확보/제한)**과 **프로비저닝(콜드 스타트 제거)**은 목적이 다름
• 콜드 스타트. 프로비저닝 동시성, 핸들러 밖 초기화 재사용으로 완화
• 환경변수는 설정 분리, 레이어는 공통 의존성 공유
• 실패 처리. Destination(성공,실패 모두)이 DLQ(실패만)보다 권장
• at-least-once 전달이므로 멱등성 설계가 필수

다음: Domain 1-2 API Gateway #

Lambda가 백엔드 로직이라면, 그 앞에서 HTTP 요청을 받아 라우팅하는 관문이 API Gateway입니다. #3 API Gateway에서는 REST API와 HTTP API의 차이, Lambda 프록시 통합, 인증(IAM,Cognito,Lambda 오서라이저), 스로틀링과 사용량 계획, 캐싱, 그리고 스테이지와 배포까지 정리하겠습니다.