본문으로 건너뛰기
Previous
Next
AWS Lambda 완벽 가이드 | Serverless·API Gateway

AWS Lambda 완벽 가이드 | Serverless·API Gateway

AWS Lambda 완벽 가이드 | Serverless·API Gateway

이 글의 핵심

AWS Lambda 완벽 가이드에 대해 정리한 개발 블로그 글입니다. AWS Lambda로 서버리스 앱을 구축하는 완벽 가이드입니다. 함수 작성, API Gateway, DynamoDB, S3, EventBridge, Cold Start 최적화까지 실전 예제로 정리했으며, 실행 환경 수명… 개념과 예제 코드를 단계적으로 다루며, 실무·학습에 참고할 수 있도록 구성했습니다. 관련 키워드:…

예전에 새벽에 배포해놓고 잠들었다가, 아침에 대시보드 열었을 때 p99가 갑자기 2초 찍힌 적 있어. 원인 뜯어보니 “우리 앱 느려진 거 아니고” 그 시간대에 트래픽이 끊겼다가 다시 몰리면서 콜드 스타트가 연속으로 터진 거였어. 런타임 뜨고, 패키지 풀리고, VPC 붙이면 ENI 잡는 시간까지 합쳐지면 체감이 확 올라가거든. 그날 느꼈지, Lambda가 “그냥 항상 가볍다”는 말이 왜 위험한지.

콜드 스타트 이야기를 조금만 더 할게. 첫 요청이 와서 실행 환경이 막 열릴 때는 런타임 Init에서 모듈 로드하는 시간이 먹히고, 그다음에야 비로소 handler가 돌아가. 이게 한 번 열리면 잠깐 쉬는 동안은 웜이라 빠른데, 트래픽이 흩어지거나 새 버전 뜰 때마다 또 이별-재회를 반복해. “그럼 메모리만 올리면 되지”라고 말하는 사람도 있는데, 맞는 말이긴 한데 그건 비용이랑 같이 봐야 하고, 진짜 애매한 건 Provisioned Concurrency 걸어서 콜드 줄이는 선택인데, 이건 애초에 “상시 띄워둔다”에 가깝잖아. 그러면 서버리스가 항상 저렴한 건 아냐 쪽으로 기우는 거지. 사용한 만큼만 낸다는 문구만 믿고 들어갔다가, 트래픽 패턴만 꼬이면 EC2 꾸려놓는 것보다 청구서가 이상해질 수 있어.

솔직히 말하면 나는 Lambda를 “절대 정답”으로는 안 써. 대신 이벤트 딱 터질 때만 돌리면 되는 배치, 업로드 후 이미지 한 번 눌러주는 worker, API Gateway 뒤에 얇은 CRUD, 이런 쪽엔 꽤 잘 맞아. 모델이 이벤트 기반이고, S3·DynamoDB·EventBridge랑 궁합 맞추는 게 편하니까. 반대로 말하자면, 항상 뜨는 서비스에 “그냥 다 Lambda로” 하면, 콜드·동시성 한도·다운스트림 DB 커넥션까지 합쳐서 괴상한 병목이 생기는 경우가 많아. 그때는 차라리 컨테이너 올리거나, 오케스트레이션(Step Functions 같은 것)으로 흐름을 쪼개는 편이 정신 건강에 이득이야.

코드 쪽은 지루하니까 최소한만. Node면 이런 느낌이고, 어차피 핵심은 handler 시그니처랑 반환 JSON 맞추는 거.

// index.js
export const handler = async (event) => {
  console.log('Event:', JSON.stringify(event));
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Hello from Lambda!', input: event }),
  };
};

API 붙일 땐 Serverless Framework 쓰는 팀도 많고, 뭐로 하든 events에 HTTP만 잘 꽂으면 돼. REST든 HTTP API든, “Lambda 프록시로 다 넘기고”에서 팀 문화가 갈리는 편이야. 난 응답 포맷이랑 에러코드 룰만 팀에서 합의 안 되어 있으면 골치 아프다고 봄.

DynamoDB·S3 트igger 이런 건 문서에 예제 투성이라 여기서 길게 안 늘릴게. 대신 실전에서 꼭 챙기라고 느낀 것만 말해볼게. 이벤트는 최소 한 번은 온다고 가정하는 게 편하니까, 결제·포인트 같은 건 멱등 키는 기본이고, 실패 나면 DLQ에 빼서 사람이 눈으로 보게 하는 게 좋아. CloudWatch에 JSON 로그 찍을 때 request id는 같이 박아. 나중에 “왜 이 요청만” 찾을 때 인생이 달라져.

콜드 줄이는 트릭은 대충 이 정도야. 런타임은 팀이 익숙한 걸로 가고(난 Node 최신 LTS 쪽 선호), 패키지는 덩치 큰 거 쓰면 Init에서 죽는다고 생각하면 됨. 메모리 올리면 CPU도 같이 느는 쪽이 있어서, 지연이랑 청구를 같이 보면서 튜닝해. 그리고 VPC 꼭 필요할 때만 써. “보안상”이라는 이유로 아무 생각 없이 붙이면, 콜드에 돈+시간만 얹는 경우 많이 봤어.

끝으로 한 마디만. Firecracker·마이크로VM·격리 이런 얘기는 멋지지만, 현장에선 “언제 콜드가 뜨냐” “동시에 몇 개까지 뜨냐” “빌이 왜 이 모양이냐” 세 가지가 제일 많이 올라와. 딱 이 세 줄만 기억하고 가도, “완벽 가이드” 말고 “살아남기 가이드”에는 충분해.

같이 보면 괜찮은 주제 — Cloudflare Workers 쪽이랑, 이벤트 기반 쪽으로는 Inngest 글, 그리고 람다(함수) 아니고 C++ 람다 이야기는 그냥 cpp-constexpr-lambda 랑 연결돼 있으니 C++ 하시는 분만…

키워드: AWS, Lambda, Serverless, API Gateway, DynamoDB, S3, Cloud, Firecracker, 동시성, 이벤트