
요즘 서버리스 구조로 빠르게 배포하고 검증하는 일이 많아졌죠. 하지만... 개발자라면 한 번쯤 이런 아찔한 경험이 있을 겁니다:
"DEV에서 테스트한 코드가 운영에 그대로 반영되었어요... 🫠"
이런 사고를 막기 위해 저는 AWS Lambda 버저닝과 API Gateway Stage 분리를 도입했습니다. 운영 환경을 깨뜨리지 않고, 안전하게 개발과 검증을 병행할 수 있는 방법! 오늘은 이걸 블로그로 정리해봅니다.
MVP를 빠르게 만들던 그때는 Lambda + API Gateway를 하나로 묶어서 쓰는 게 효율적이었어요. 일단 기능만 돌아가면 됐으니까요.
그런데 점점 기능이 늘어나고 사용자도 많아지니까, 운영 중 실수로 코드가 덮이는 위험이 현실로 다가왔습니다. 그래서 이번 확장 개발을 하면서, 이 잔재를 정리하고 확실하게 운영/검증 환경을 분리하기로 결심했어요.
이 과정을 안전하게 적용하려면 순서를 꼭 지켜야 합니다. 실수 한 번이면 운영 서버에 영향 줄 수 있으니 신중하게요!
Lambda 코드를 배포한 후, Publish new version으로 고정 버전을 생성합니다.

이후, 해당 버전에 대해 alias를 만들어서 운영과 개발을 명확하게 분리합니다:


| Alias | 연결 버전 | 설명 |
|---|---|---|
| dev | $LATEST or 최신버전 | 개발 & 검증용 |
| prod | 안정된 고정버전 | 운영 환경에만 적용됨 |
이 alias는 이후 API Gateway에서 직접 호출하게 되므로, Lambda 함수에 반드시 alias별로 Invoke 권한을 확인해야 합니다!
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:region:account-id:function:functionName:prod"
}
dev, prod Stage를 생성합니다.| Stage | Variable Key | Value |
|---|---|---|
| dev | alias | dev |
| prod | alias | prod |


arn:aws:lambda:region:account-id:function:functionName:${stageVariables.alias}
→ 이걸로 Stage에 따라 자동으로 dev 또는 prod alias를 호출하게 됩니다.
| 항목 | 효과 |
|---|---|
| 개발/운영 환경 분리 | 실수로 운영에 영향을 주는 일 없음 |
| 안정성 | 배포 후에도 prod alias는 고정 버전을 유지 |
| 유연성 | dev alias로 자유로운 테스트 가능 |
| 추적 가능성 | 버전 기반으로 롤백이나 상태 확인이 용이 |
| 권한 제어 | 운영 접근 권한 제한으로 보안 강화 |
Lambda 버저닝과 Alias, 그리고 API Gateway Stage 분리는 단순한 구조 개선이 아닙니다.
이건 실수를 줄이고, 팀 전체의 배포 품질을 높이며, 보안까지 강화하는 운영 안정성의 최소 조건입니다.
혹시 아직 $LATEST로 운영 중이시라면?
오늘 당장 Publish version, Alias, Stage Variables를 꺼내보시는 걸 추천드립니다 😉