Lambda의 확장성, 자동화된 자원 관리, 비용 효율성 등으로 마이그레이션을 고려하는 상황들이 증가하고 있습니다. EC2에서 AWS Lambda로의 마이그레이션은 단순한 호스팅 환경 변경이 아니라, 아키텍처 전환(Re-Architecture)에 가까운 작업입니다. Lambda는 서버리스 환경을 기반으로 하며, 기존 상태 유지형 구조나 장시간 실행 로직과는 본질적으로 작동 방식이 다릅니다. 따라서 모든 애플리케이션이 Lambda에 적합한 것은 아니며, 전환 시 명확한 기준과 사전 준비가 필요합니다.
아키텍처 차이에 따른 전환 난이도
| 항목 | EC2 | Lambda |
|---|---|---|
| 실행 방식 | 상시 실행 | 요청 시 실행 (Event-driven) |
| 상태 유지 | 가능 (세션, 캐시 등) | 불가능 (Stateless) |
| 파일시스템 접근 | 자유로움 | 제한적 (/tmp 디렉토리만 가능) |
| 서버 접근성 | SSH 접속 가능 | 불가능 |
| 실행 시간 | 무제한 | 기본 최대 15분 제한 |
| 언어/환경 구성 | 사용자 맞춤 설정 | 제한된 런타임 내에서 실행 |
마이그레이션 전 반드시 고려할 핵심 요소
구조 분해(Decomposition)
Lambda는 모놀리식 구조의 앱을 그대로 옮기는 것을 허용하지 않습니다. 각 기능을 독립된 함수 단위로 분리해야 하며, 이는 곧 전체 애플리케이션을 마이크로서비스화하거나 Function-as-a-Service(FaaS) 형태로 재설계해야 함을 의미합니다.
상태 분리(Stateless 설계)
| 상태 요소 | 대체 방안 |
|---|---|
| 세션/로그인 상태 | Redis (Amazon ElastiCache) |
| 파일 저장 | Amazon S3 |
| DB 연결 | RDS Proxy 또는 Lambda 전용 커넥션 풀 구성 |
| 임시 변수 | /tmp 디렉토리 또는 메모리 내 처리 (15분 제한) |
트리거 기반 실행 설계
EC2는 요청을 기다리는 서버 형태의 구조지만, Lambda는 항상 외부 이벤트에 의해 호출됩니다. 따라서 먼저 "누가 이 함수를 호출할 것인가?"를 정의하고, 이에 맞춰 트리거 설계를 해야 합니다.
마이그레이션 팁과 실행 전략
| 전략 | 설명 |
|---|---|
| 단계적 마이그레이션 | 전체 앱을 한 번에 옮기지 말고, 이미지 처리, 메일 발송 등 개별 기능부터 Lambda로 전환 |
| Serverless 프레임워크 활용 | Serverless Framework, AWS SAM, CDK를 통해 반복적인 배포 및 구성을 자동화 |
| 로컬 테스트 툴 | localstack, sam local 등 로컬 개발 환경을 활용해 실제 Lambda 환경을 시뮬레이션 |
| 비용 시뮬레이션 | Lambda는 호출 수/실행 시간에 따라 비용 발생 → AWS Cost Explorer로 EC2 대비 비용 비교 필수 |
| 로깅 및 모니터링 강화 | CloudWatch Logs, AWS X-Ray, CloudTrail을 통해 함수 실행, 오류, 퍼포먼스를 실시간 추적 |
Lambda에 적합한 애플리케이션 유형
- REST API 서비스 (API Gateway 연동)
- 이미지/영상 변환 및 리사이징
- 비동기 이벤트 기반 처리 (파일 업로드, 로그 수집 등)
- 예약(Cron) 작업 처리
- 단일 목적의 유틸리티 함수 (Slack 알림, 이메일 발송 등)
- 머신러닝 모델 추론 (단시간 내 응답 필요 시)
마이그레이션은 곧 재설계
기존 EC2 애플리케이션을 Lambda로 이전하는 것은 단순히 코드를 옮기는 것이 아니라, 전체 구조를 다시 설계하는 과정입니다. 이 과정에서 Lift & Shift 방식은 거의 통하지 않으며, 반드시 다음 요소들을 기준으로 판단해야 합니다:
- 현재 구조의 상태 유지 여부
- 파일 시스템, 네트워크, 환경 설정 의존도
- 실행 시간 및 호출 빈도
- 트래픽 패턴과 스파이크 발생 빈도
Lambda는 제대로 활용하면 비용을 절감하면서도 고가용성 아키텍처를 구현할 수 있는 도구로 사용할 수 있습니다. 그러나 정확한 정보와 준비없이 전환하면, 오히려 운영 복잡도와 비용이 상승할 수 있으므로, 부분 마이그레이션부터 시작하여 점진적으로 서버리스로 전환하는 전략이 가장 안전하다고 생각합니다.