서버리스로 옮겼다가 다시 돌아온 이야기 - Lambda Cold Start의 현실

서버리스는 마법처럼 보였다. 서버 관리 없이 코드만 배포하면 되고, 사용한 만큼만 비용을 지불한다. “이게 미래다!”라고 생각하며 우리 API를 AWS Lambda로 옮겼다. 하지만 4개월 후, 우리는 다시 EC2로 돌아갔다. 이 글은 그 실패와 배움의 기록이다.

시작: 서버리스에 대한 환상

왜 서버리스를 선택했나

2025년 8월, 우리는 Express.js로 작성된 REST API를 운영하고 있었다. 트래픽이 불규칙했고, 피크 시간대에만 서버가 바쁘고 대부분의 시간은 유휴 상태였다.

“서버리스로 옮기면 서버 관리 부담도 없고, 사용한 만큼만 비용을 내면 되잖아.” 이렇게 생각하며 AWS Lambda로 마이그레이션하기로 결정했다.

초기 기대감

서버리스의 장점들이 매력적이었다:

• 서버 관리 불필요
• 자동 스케일링
• 사용한 만큼만 비용 지불
• 빠른 배포

팀원들도 대부분 긍정적이었다. “서버 관리에서 해방되면 좋겠다”는 반응이었다.

첫 번째 문제: Cold Start의 현실

첫 번째 요청의 충격

Lambda로 옮긴 직후, 첫 번째 요청을 보냈다. 응답 시간이 3초가 넘었다.

“뭐지? 이전에는 200ms였는데?”

이것이 바로 Cold Start였다. Lambda 함수가 오랫동안 사용되지 않아 “차가워진” 상태에서 첫 실행 시 발생하는 지연 시간이다.

사용자 불만

사용자들이 불만을 토로하기 시작했다.

“앱이 너무 느려졌어요.” “로딩이 3초나 걸려요.”

특히 모바일 앱 사용자들이 많이 불만을 표시했다. 첫 화면 로딩이 너무 느렸다.

Cold Start 최적화 시도

Cold Start를 줄이기 위해 여러 방법을 시도했다:

1. Provisioned Concurrency 사용

• 비용이 크게 증가했다
• 항상 실행 중인 인스턴스를 유지해야 했다
• 서버리스의 장점이 사라졌다

2. 함수 최적화

• 패키지 크기 최소화
• 불필요한 의존성 제거
• 하지만 여전히 1-2초의 지연이 있었다

3. Keep Warm 패턴

• CloudWatch Events로 주기적 호출
• 하지만 이건 꼼수였고, 비용도 발생했다

두 번째 문제: 비용 폭증

예상과 다른 비용

서버리스는 “사용한 만큼만 비용을 지불한다”고 했지만, 우리의 경우는 달랐다.

이전 (EC2):

• 월 비용: $50 (t3.small 인스턴스)
• 트래픽: 평균 100만 요청/월

Lambda 전환 후:

• 월 비용: $180
• 트래픽: 동일

왜 이렇게 비쌌을까?

비용 분석

Lambda 비용:

• 요청 수: 100만 요청 × $0.20/1M = $0.20
• 실행 시간: 평균 500ms, 512MB 메모리
• GB-second: 100만 × 0.5초 × 0.5GB = 250,000 GB-second
• 실행 비용: 250,000 × $0.0000166667 = $4.17

하지만 실제 비용이 높았던 이유:

1. API Gateway 비용: 요청당 $0.0035
2. 데이터 전송 비용: 요청/응답 데이터 전송
3. CloudWatch 로깅: 로그 저장 비용
4. Provisioned Concurrency: Cold Start 해결을 위한 추가 비용

총 비용이 예상보다 3배 이상 높았다.

팀장의 질책

월말 비용 리포트를 받은 팀장이 놀랐다.

“비용이 왜 이렇게 늘었어?” “서버리스가 더 저렴하다고 했는데?”

설명하기가 어려웠다. 서버리스가 항상 저렴한 것은 아니었다.

세 번째 문제: 디버깅의 어려움

로컬 환경과의 차이

로컬에서는 잘 작동하던 코드가 Lambda에서는 다르게 동작했다.

문제 1: 환경 변수

• 로컬과 Lambda의 환경 변수가 달랐다
• 설정 관리가 복잡해졌다

문제 2: 파일 시스템

• Lambda는 읽기 전용 파일 시스템을 사용한다
• 임시 파일을 사용해야 했다

문제 3: 타임아웃

• Lambda는 최대 15분 실행 가능
• 장시간 실행 작업이 불가능했다

디버깅 도구의 한계

Lambda 함수를 디버깅하는 것이 어려웠다. CloudWatch Logs를 확인해야 했고, 로컬에서 재현하기 어려웠다.

특히 비동기 에러를 찾는 것이 힘들었다. 에러가 발생해도 로그에 제대로 남지 않는 경우가 많았다.

네 번째 문제: 데이터베이스 연결

연결 풀링의 문제

Lambda는 상태를 저장하지 않는다. 매번 새로운 실행 환경에서 시작된다. 데이터베이스 연결 풀을 만들 수 없었다.

문제:

• 매 요청마다 새로운 DB 연결 생성
• 연결 수 제한에 걸림
• 연결 생성 시간이 오래 걸림

해결 시도:

• RDS Proxy 사용
• 하지만 추가 비용 발생
• 복잡도 증가

세션 관리의 어려움

세션을 관리하기도 어렵었다. Lambda는 상태를 저장할 수 없어서 Redis나 DynamoDB를 사용해야 했다. 추가 인프라와 비용이 필요했다.

다섯 번째 문제: 팀원들의 불만

개발 경험의 저하

3개월이 지나면서 팀원들의 불만이 커졌다.

“로컬에서 테스트하기 어려워.” “디버깅이 너무 힘들어.” “배포는 빠른데, 문제 해결은 오래 걸려.”

특히 주니어 개발자들이 힘들어했다. Lambda의 제약사항을 이해하는 것도 어려웠고, 문제를 해결하는 것도 복잡했다.

내 고민

나도 고민이 많았다. 분명히 좋은 선택이라고 생각했는데, 현실은 달랐다. Cold Start 문제, 비용 증가, 디버깅 어려움까지. 서버리스가 우리 프로젝트에 맞지 않았나?

결국 되돌리기로 결정

결정의 순간

2025년 12월, 팀 회의에서 서버리스를 포기하기로 결정했다. 4개월 동안의 시도가 실패로 끝났다.

결정 이유:

1. Cold Start로 인한 사용자 불만
2. 비용이 오히려 증가
3. 디버깅이 어려움
4. 개발 경험이 나빠짐

되돌리는 과정

되돌리는 것도 쉽지 않았다. Lambda 함수를 다시 Express.js로 변환하고, EC2 인스턴스를 설정하고, 로드 밸런서를 구성해야 했다. 하지만 예상보다 빠르게 완료되었다. 이미 알고 있던 기술이었기 때문이다.

배운 점들

1. 서버리스가 모든 경우에 적합한 것은 아니다

서버리스는 특정 사용 사례에 적합하다:

• 트래픽이 불규칙하고 낮을 때
• 짧은 실행 시간의 작업
• 이벤트 기반 처리

하지만 우리의 경우:

• 트래픽이 일정 수준 이상
• 긴 실행 시간이 필요한 작업
• 상태 관리가 필요한 경우

이런 경우에는 전통적인 서버가 더 적합했다.

2. 비용을 정확히 계산해야 한다

서버리스가 항상 저렴한 것은 아니다. 요청 수, 실행 시간, 데이터 전송량 등을 모두 고려해서 비용을 계산해야 한다. 우리는 Lambda 비용만 계산하고 API Gateway, 데이터 전송 등의 비용을 간과했다.

3. Cold Start를 간과하면 안 된다

Cold Start는 서버리스의 가장 큰 문제 중 하나다. 사용자 경험에 직접적인 영향을 미친다. Cold Start를 해결하려면 Provisioned Concurrency가 필요하지만, 이는 비용을 증가시키고 서버리스의 장점을 잃게 만든다.

4. 개발 경험도 중요하다

서버 관리 부담이 줄어드는 것은 좋지만, 개발 경험이 나빠지면 안 된다. 디버깅이 어렵고, 로컬 테스트가 어렵고, 배포가 복잡해지면 개발 생산성이 떨어진다.

5. 실패를 빠르게 인정하는 용기

4개월이나 걸렸지만, 결국 실패를 인정하고 되돌렸다. 이 결정이 쉽지 않았지만, 지금 생각해보면 더 빨리 결정했어야 했다.

지금은 어떻게 하고 있나

개선된 EC2 전략

서버로 돌아간 후, 우리는 EC2를 개선했다:

자동 스케일링:

• 트래픽에 따라 인스턴스 수 자동 조정
• 비용 최적화

로드 밸런싱:

• 여러 인스턴스에 트래픽 분산
• 고가용성 확보

모니터링:

• CloudWatch로 성능 모니터링
• 자동 알림 설정

현재 상태

지금은 EC2로 잘 운영하고 있다. 비용도 줄었고, 사용자 경험도 개선되었고, 개발 경험도 좋아졌다. 서버 관리가 필요하지만, 그만한 가치가 있다.

다른 개발자들에게

서버리스를 고려한다면

서버리스를 도입하려는 팀이 있다면, 다음을 고려해보길 바란다:

1. 사용 사례 확인: 서버리스에 적합한 사용 사례인가?
2. 비용 계산: 모든 비용을 포함해서 정확히 계산하라
3. Cold Start 고려: Cold Start가 사용자 경험에 미치는 영향을 평가하라
4. 개발 경험: 개발 경험이 나빠지지 않는지 확인하라
5. 작은 프로젝트부터: 전체를 한 번에 옮기지 말고 작은 프로젝트부터 시작하라

실패를 두려워하지 말라

우리의 실패 경험이 다른 팀에게는 도움이 될 수 있다. 서버리스가 우리 프로젝트에 맞지 않았을 뿐, 다른 프로젝트에게는 적합할 수 있다. 하지만 우리의 경험을 통해 실수를 피할 수 있을 것이다.

결론: 서버리스의 현실

서버리스는 마법이 아니다. 특정 상황에서 강력한 도구이지만, 모든 경우에 적합한 것은 아니다. 우리는 서버리스의 장점에만 집중하고 단점을 간과했다.

지금은 전통적인 서버로 잘 운영하고 있다. 하지만 서버리스에 대한 경험은 소중했다. 언젠가 적절한 사용 사례가 생기면 다시 시도할 수도 있다. 그때는 이번 경험을 바탕으로 더 신중하게 접근할 것이다.

실패는 배움의 기회다. 이 경험이 다른 개발자들에게 도움이 되기를 바란다.