Lambda는 DVA-C02 시험에서 가장 많이 출제되는 서비스입니다. Lambda를 처음 접하는 분을 위해 기본 개념부터 설명하겠습니다. Lambda는 서버를 직접 관리하지 않고 코드만 실행할 수 있는 서비스입니다. 쉽게 말하면 "코드 자판기"입니다. 동전을 넣으면(이벤트 발생) 원하는 음료가 나오듯(코드 실행), 서버 걱정 없이 함수만 작성하면 됩니다. 이 글에서는 Lambda를 실제로 개발하고 구성할 때 알아야 할 핵심 내용을 초보자 눈높이에서 설명합니다.
Lambda 핵심 구성
환경 변수 — 코드와 설정 분리하기
데이터베이스 비밀번호나 API 키 같은 민감한 정보를 코드에 직접 적어두는 것은 매우 위험합니다. 환경 변수는 이런 설정값을 코드 바깥에서 주입하는 방법입니다. 레스토랑 메뉴와 레시피를 분리해서 관리하는 것처럼, 코드(레시피)는 그대로 두고 설정값(재료 공급업체 정보)만 바꿀 수 있습니다. KMS(Key Management Service)를 이용하면 환경 변수를 암호화해서 더 안전하게 보관할 수 있습니다.
Lambda Layers — 공통 라이브러리 공유하기
여러 개의 Lambda 함수가 같은 라이브러리(예: 이미지 처리 라이브러리, 공통 유틸리티)를 사용한다고 가정해봅시다. 각 함수마다 같은 라이브러리를 포함시키면 중복이 발생하고 관리가 어려워집니다. Lambda Layers는 공통으로 사용하는 라이브러리를 별도 레이어로 패키징해서 여러 함수가 함께 쓸 수 있게 합니다. 마치 회사의 공용 문구함처럼, 각 팀이 직접 살 필요 없이 공용 자원을 함께 사용합니다.
메모리와 타임아웃
Lambda 함수를 실행할 때 두 가지 한계를 설정합니다.
메모리는 128MB에서 10,240MB(약 10GB)까지 설정할 수 있습니다. 중요한 점은 메모리를 늘리면 CPU 성능도 비례해서 올라간다는 것입니다. 함수가 느리다면 메모리를 올려보는 것이 한 방법입니다.
타임아웃은 함수가 실행될 수 있는 최대 시간으로, 최대 15분입니다. 15분이 넘는 작업은 Lambda로 처리할 수 없으니 Step Functions나 다른 서비스를 활용해야 합니다.
동시성 모델 — 여러 요청을 동시에 처리하는 방법
Lambda는 요청이 들어오면 자동으로 새로운 실행 환경을 만들어 동시에 처리합니다. 이것이 동시성(Concurrency)입니다.
예약 동시성 (Reserved Concurrency)
특정 함수에 동시 실행 수를 미리 할당해두는 방식입니다. 예를 들어 결제 함수에 예약 동시성 100을 설정하면, 다른 함수들이 아무리 바빠져도 결제 함수는 항상 100개의 실행 환경이 보장됩니다. 0으로 설정하면 함수를 완전히 비활성화하는 효과가 있습니다. 점검 시간에 특정 함수를 멈추고 싶을 때 유용합니다.
프로비저닝된 동시성 (Provisioned Concurrency)
이 개념을 이해하려면 먼저 콜드 스타트를 알아야 합니다. Lambda는 요청이 없을 때는 실행 환경을 준비해두지 않습니다. 갑자기 요청이 오면 환경을 새로 만들어야 하는데, 이 시간(콜드 스타트)이 응답을 느리게 만듭니다. 프로비저닝된 동시성은 미리 실행 환경을 준비해두어 콜드 스타트를 없애는 방법입니다. 비용이 추가되지만, 지연 시간이 중요한 서비스(예: 실시간 금융 거래, 게임)에 적합합니다.
!Reserved vs Provisioned Concurrency
콜드 스타트 vs 웜 스타트
콜드 스타트는 Lambda가 처음 실행될 때 거치는 준비 과정입니다. 새 실행 환경 생성, 코드 패키지 다운로드, 런타임(Python, Java 등) 초기화, 그리고 나서야 실제 코드(핸들러)가 실행됩니다. 마치 PC를 처음 켤 때 부팅 시간이 걸리는 것과 같습니다.
웜 스타트는 이미 준비된 실행 환경을 재사용하는 경우입니다. 바로 핸들러만 실행되므로 매우 빠릅니다. 켜져 있는 PC에서 프로그램을 바로 실행하는 것과 같습니다.
콜드 스타트를 줄이는 방법이 세 가지 있습니다. 첫째, 프로비저닝된 동시성을 사용합니다. 둘째, DB 연결이나 초기화 코드를 핸들러 함수 바깥에 배치합니다. 이렇게 하면 웜 스타트 시 연결을 재사용할 수 있습니다. 셋째, 배포 패키지 크기를 작게 유지합니다. 다운로드할 코드가 적을수록 빨리 시작됩니다.
VPC에서 Lambda 실행
VPC(Virtual Private Cloud)는 AWS 안에서 만드는 가상의 사설 네트워크입니다. 외부에서 직접 접근할 수 없는 프라이빗 서브넷에 있는 데이터베이스(RDS 등)에 Lambda가 접근하려면 Lambda를 VPC에 연결해야 합니다.
VPC에 연결된 Lambda는 ENI(Elastic Network Interface)라는 가상 네트워크 카드를 VPC의 서브넷에 생성합니다. 이를 통해 같은 VPC 안의 리소스에 접근할 수 있습니다.
한 가지 주의할 점이 있습니다. VPC에 연결된 Lambda는 기본적으로 인터넷에 접근할 수 없습니다. 인터넷 접근이 필요하면 NAT 게이트웨이가 있는 퍼블릭 서브넷을 통하거나, VPC 엔드포인트를 사용해야 합니다.
오류 처리 — 실패했을 때 어떻게 할까
DLQ (Dead Letter Queue)
Lambda를 비동기적으로 호출했는데 실패한 경우, 그 실패 이벤트를 SQS 큐나 SNS 토픽으로 전달할 수 있습니다. 나중에 이 실패 이벤트를 분석하거나 재처리할 수 있습니다.
Lambda Destinations
DLQ보다 더 강력한 방법입니다. 함수가 성공했을 때와 실패했을 때 각각 다른 대상(SQS, SNS, Lambda, EventBridge)을 지정할 수 있습니다. 예를 들어 성공 시 다음 Lambda를 호출하고, 실패 시 알림 SNS로 보내는 식으로 유연하게 구성할 수 있습니다.
시험 핵심 정리
"여러 함수에서 공통 라이브러리 공유" -- Lambda Layers
"콜드 스타트 제거" -- 프로비저닝된 동시성
"특정 함수에 동시 실행 수 고정" -- 예약 동시성
"함수를 비활성화" -- 예약 동시성을 0으로 설정
"VPC 내 RDS에 접근" -- Lambda를 VPC에 연결 (ENI 필요)
"VPC Lambda가 인터넷에 접근" -- NAT 게이트웨이 필요
"비동기 호출 실패 처리" -- DLQ 또는 Lambda Destinations
"성공/실패 시 각각 다른 대상" -- Lambda Destinations
초기화 코드는 핸들러 밖에 배치하여 연결 재사용 → 성능 향상