서버 유지비 없이 Python 스크립트를 Lambda로 전환해 비용·운영 시간을 크게 줄이는 실무 가이드. 단계별 체크리스트와 비용 비교표 포함.
매일 엑셀 반복 작업에 시달리던 실무자 A씨는 기존의 온프레 미니 서버에서 파이썬 스크립트를 주기적으로 실행해 월 240달러의 고정비를 부담하고 있었다. 동일 워크플로를 AWS Lambda로 전환하면 월 평균 비용을 80%까지 낮출 수 있었다.
이 글은 기획자 B씨처럼 서비스 도입을 검토하는 담당자가 실무에 바로 적용할 수 있는 절차와 주의사항을 정리한다.
주요 내용
Lambda 전환 전 필수 확인 항목은 다음과 같다. 체크리스트처럼 빠르게 점검하라.
- 작업 패턴: 트리거(스케줄, S3 이벤트, API)와 평균 실행 시간
- 메모리/CPU 요구량: 현재 스크립트의 메모리 사용량 및 I/O 병목 여부
- 의존성 크기: 파이썬 패키지 전체 용량(필요 시 Lambda Layer 또는 컨테이너 이미지 사용)
- 동시 실행성: 동시 실행 제한과 스로틀 발생 가능성
- 감시 및 로깅: CloudWatch 로그/지표, 알람 구조설계 여부
우선 워크로드의 실행 빈도와 평균 런타임을 2주간 관찰해 P95 실행시간을 산출하면, Lambda 적합성을 판단하는 핵심 근거가 된다.
사례 분석: A씨의 엑셀 자동화 전환 과정
기존 환경: 온프레 VM에서 매일 오전 2시에 스크립트가 실행되어 CSV를 생성하고 내부 공유 폴더에 업로드. 실행 시간 평균 90초, 동시성 1, 월 고정 서버비 240달러(전력·관리비 포함).
전환 설계 요약:
- 트리거: EventBridge(정기 스케줄)로 전환
- 파일 입출력: S3로 통합하여 공유 폴더 의존성 제거
- 패키지 관리: 불필요한 패키지 제거 및 공통 라이브러리를 Lambda Layer로 분리
- 모니터링: CloudWatch 지표 + SNS 알림 구성
실행 환경 튜닝: 메모리 512MB에서 1024MB로 테스트한 결과 CPU 성능 향상으로 실행시간이 90초→48초로 단축되었고, 총 비용은 더 낮아졌다(메모리당 GB-초 비용과 실행 시간의 곱으로 비용이 결정되므로 메모리 증가가 오히려 비용을 낮추는 경우가 발생).
예상 비용 산식(간단화)
요금 = 요청수 * 요청요금 + (메모리(GB) * 실행시간(초)) * GB-초 단가
Python 패키지 용량을 20% 줄이면 Cold start와 배포 실패 가능성을 동시에 낮춘다. 가능하면 Lambda Layer로 공통 의존성을 분리하고, 컨테이너 이미지 방식은 100MB 이상 패키지에서 고려하라.
데이터 비교표: 도입 전/후 비용·성능
| 항목 | 온프레 VM (기존) | AWS Lambda (전환 후) |
|---|---|---|
| 월 고정비 | $240 | $0 (사용량 기반) |
| 월 평균 요청수 | – | 30,000회 |
| 평균 실행시간 | 90초 | 48초 |
| 메모리 | 1 vCPU / 2GB | 1 vCPU (512→1024MB 튜닝) |
| 월 추정비용 | $240 | $38 (요청+GB-초 기준 환산) |
| 절감율 | 약 84% |
비용 계산은 Lambda의 GB-초 요금과 요청 요금을 기반으로 단순화했다. 실제 비용은 지역, 프로비저닝(예: Provisioned Concurrency), 추가 서비스(S3, API Gateway, SNS 등)에 따라 달라진다.
테스트 중 발견된 주의사항
다음 항목은 실제 전환 과정에서 빈번히 발생한 문제다. 사전 점검 체크리스트로 활용할 것.
- 환경 변수·시크릿 관리: 평문 하드코딩 금지. Secrets Manager 또는 Parameter Store 사용 권장.
- Cold start: 라이브러리 크기와 초기화 코드가 원인. 초기화 지연을 줄이고 필요 시 Provisioned Concurrency를 검토하라.
- 동시 실행 제한: 계정 기본 한도를 확인하고, 급격한 트래픽 증가 시 스로틀을 피하기 위한 예약(concurrency reservation) 전략 필요.
- 장기 실행 작업: Lambda는 최대 실행시간 제한이 있으므로(최대 15분) 장시간 작업은 Fargate/Batch로 분리.
- 모니터링 비용: CloudWatch 로그/지표 저장 비용이 누적될 수 있음. 로그 레벨/저장 기간을 정책으로 관리.
# 간단한 AWS CLI 배포 예시 (Zip 방식)
zip function.zip lambda_function.py
aws lambda create-function \
--function-name my-task \
--runtime python3.11 \
--handler lambda_function.handler \
--role arn:aws:iam::123456789012:role/lambda-exec \
--zip-file fileb://function.zip \
--timeout 300 \
--memory-size 1024
실행 전략과 비용 최적화 체크리스트
실행 전략은 다음과 같다.
- 작업 분해: 15분 이상 소요되는 작업은 배치 처리로 전환
- 메모리 튜닝: 메모리-성능 곡선을 측정해 GB-초 비용을 최소화하는 메모리 값 선택
- 런타임 아키텍처: Graviton(arm64) 런타임으로 비용 절감 여부 검증
- 의존성 관리: Layer로 공통 라이브러리 분리, 필요시 ECR 기반 컨테이너 이미지 사용
- 오케스트레이션: 복잡한 워크플로는 Step Functions로 상태 관리
실행 전 표준 성능 테스트(메모리별 P95 실행시간 측정)를 자동화해 CI(예: GitHub Actions)에서 배포 전 비교를 수행하면 비용 리그레션을 방지할 수 있다.
마이그레이션 샘플 로드맵 (빠른 적용용)
1주차: 워크로드 분석(실행 빈도·평균시간·패키지 크기) → P95 계산
2주차: 간단한 Lambda PoC 작성(Zip or Layer) → 메모리 스윕 테스트(128→3008MB 범위에서 P95 측정)
3주차: 트리거(EventBridge/S3) 전환, CloudWatch 지표·알람 설정
4주차: 운영 모니터링 및 비용 리포트(자동화된 비용 알림), 필요 시 Provisioned Concurrency 도입 여부 결정
테스트 후 권장 운영 정책
- 로그 보존 정책: 중요 로그는 30일, 디버그 로그는 7일로 설정
- 알람 임계치: 에러율>1% 또는 평균 실행시간 2배 증가 시 자동 롤백 트리거
- 비용 대시보드: 매주 GB-초 및 요청수 집계와 전월 대비 증감 리포트
- 정기 리팩토링: 3개월 주기로 의존성/패키지 점검 및 불필요한 라이브러리 제거
추가로, Lambda를 포함한 전체 아키텍처 관점의 베스트프랙티스는 AWS 공식 문서를 참조하라.