AWS Lambda, API Gateway를 활용한 서버리스 MVP 구축 – 콜드 스타트와 방어 전략

최근 AI 페르소나 챗봇 서비스(‘바이블톡’)의 초기 MVP를 기획하면서,
백엔드 아키텍처에 대한 깊은 고민이 많았습니다.
일반적으로 알려진 대규모 서비스 아키텍처와 달리, 초기 스타트업 단계의 개발 속도 및 운영 비용을 고려하여 AWS Lambda를 활용한 서버리스 MVP 구축을 시도했고,
그 과정에서 API Gateway, 콜드 스타트 등 새로운 개념을 마주했습니다.

이번 글에서는 서버리스 아키텍처를 실제 프로젝트에 적용하면서 고민했던 내용과 경험한 시행착오를 정리해보려 합니다.

스타트업 아키텍처

초기 스타트업은 항상 ‘자본’과 ‘시간’이라는 극단적인 제약 조건이 있다고 생각합니다.
트래픽을 전혀 예측할 수 없는 서비스 런칭 초기에 무작정 24시간 돌아가는 EC2 서버를 띄워두는 것은 불필요한 비용 낭비였고, 개발자인 제가 인프라 관리(OS 패치, 스케일링 등)에 시간을 뺏기는 것도 피해야 했습니다. (거기에 본업도 있으니까요 ㅎㅎ)

비용을 최소화하면서도 기민하게 시장의 반응을 테스트하기 위해 제가 선택한 무기는 AWS API Gateway와 Lambda를 조합한 완전 관리형 서버리스(Serverless) 아키텍처였습니다.

왜 Lambda와 API Gateway였을까?💡

예전에 AWS 서비스를 공부하다가 자격증을 하나 따놓은 게 있습니다.
그 때 어렴풋이 공부했던 기억이 나서 찾아본 거였는데,
확인 해보니 딱 스타트업에 필요했던 서비스지 않았나 싶습니다.

AWS API Gateway와 Lambda, 서버리스 아키텍처를 구성하는 두 가지 서비스를 간단하게 정리하고 넘어가겠습니다.

– AWS API Gateway

AWS API Gateway는 가장 먼저 요청을 받아주는 ‘대문’ 역할을 합니다.
트래픽이 몰리면 알아서 확장되고, 인증이나 속도 제한(Throttling)을 관리형으로 제공해주기 때문에 개발자가 비즈니스 로직에만 집중할 수 있게 해줍니다.

– AWS Lambda

API Gateway가 문을 열어주면, 실질적인 비즈니스 로직을 실행하는 컴퓨팅 서비스입니다.

가장 큰 매력은 ‘서버를 띄워둘 필요 없이, 코드가 실행된 딱 그 100ms 단위의 시간만큼만 과금된다’는 점이었습니다.

초기 트래픽이 없을 때는 인프라 비용이 사실상 ‘0원’에 수렴하므로, 자본이 부족한 초기 MVP 테스트에 이보다 더 완벽한 아키텍처는 없다고 판단했습니다.

서버리스 MVP 구축

1. API 환경 만들기

먼저 사용자가 챗봇에 메시지를 보내면 응답을 반환하는 간단한 Lambda 함수와 이를 호출할 API Gateway를 붙여봅니다.

Step 1-1. AWS Lambda 함수 생성

AWS 콘솔에서 Lambda 서비스로 이동 후 [함수 생성]을 클릭합니다.

사용할 언어에 맞게 런타임을 선택하고,
ARM64 아키텍처를 On 처리합니다.
※ ARM64 아키텍처는 비용 대비 성능이 20%가량 우수하다고 합니다.

그리고 우측 하단에 ‘함수 생성’을 누르세요.

그럼 Visual Studio Code IDE를 그대로 옮겨놓은듯한 화면이 나와요.

1번처럼 비즈니스 로직이 들어간 함수를 작성한 다음,
2번의 Test나 Create new test event를 눌러서
3번 처럼 Test API Request를 작성하세요.

별거 없습니다. 그냥 테스트 용도로 작성해서 Save하세요.
함수 테스트 하실 거 필요하면 아래 소스 그대로 사용하셔도 돼요!

import json
import time

def lambda_handler(event, context):
    # DynamoDB 조회 및 AI 모델 API 호출 작성 예정
    time.sleep(0.5) # AI 처리 시간 가정
    
    body = {
        "message": "헬로월ㄷ~~",
        "status": "success"
    }
    
    return {
        'statusCode': 200,
        'body': json.dumps(body)
    }

Deploy 한 다음 Test를 눌러 보면,
작성한 함수가 정상적으로 response된 것을 확인할 수 있습니다.

※ 참고로 지금 아래 응답값은 유니코드 escape형태로, 디코딩 하면 헬로월ㄷ~~ 그대로 나옵니다.

Step 1-2. API Gateway 연동 (트리거 추가)

이제 Lambda가 웹의 요청을 받을 수 있도록 문을 열어주어야 합니다.
상단의 [트리거 추가]를 누르고

트리거 구성에서 [API 게이트웨이]를 선택하세요

API 유형은 REST API의 고급 기능은 필요하지 않았기 때문에,
더 저렴하고 빠른 HTTP API를 선택했습니다.
테스트니까 보안 옵션도 그냥 ‘열기’로 선택하고 ‘추가’해주세요.

그럼 API Gateway의 엔드포인트 URL이 발급된 겁니다.
브라우저나 Postman으로 이 주소에 접속하면 Lambda가 실행됩니다.

2. 콜드 스타트 방어

이건 프로젝트가 좀 더 진행된 상황에서 마주했던 이슈입니다.
테스트 초기에 응답 속도는 50ms 내외로 아무 문제 없었지만, 어느 순간 3~4초 정도 응답이 지연되는 현상을 발견했습니다.

텍스트가 즉각적으로 오가야 하는 실시간 챗봇 서비스에서 대답이 3~4초 이상이 추가로 소요된다는 것은 치명적이였기 때문에 무슨 문제인지 알아봤고, 범인은 서버리스의 단점으로 말할 수 있는 ‘콜드 스타트(Cold Start)’였습니다.

AWS Lambda는 리소스를 효율적으로 쓰기 위해, 일정 시간 동안 함수의 호출이 없으면 할당해둔 컴퓨팅 자원(컨테이너)을 회수해버립니다. 이후 새로운 요청이 들어오면 다시 런타임 환경을 구축하고 코드를 로드하느라 딜레이가 발생하는 것이죠.

트래픽이 적은 MVP 환경에서 ‘비용을 0원으로 맞추려다 보니, 정작 중요한 첫 고객의 응답 속도를 망쳐버리는’ 완벽한 트레이드오프(Trade-off)의 딜레마에 빠진 순간이었습니다.

해결책: 프로비저닝된 동시성 (Provisioned Concurrency) 적용

이 치명적인 첫 응답 지연을 해결하기 위해 여러 방법을 고민하다가 AWS가 공식적으로 제공하는 해결책을 찾게 되었습니다. 바로 프로비저닝된 동시성(Provisioned Concurrency)이란 건데, 설정한 개수만큼의 컨테이너를 항상 ‘웜(Warm)’ 상태로 미리 데워두는 기능입니다.

웜 생성 방법은 처음에 doc보면서 찾아보다가 고생좀 했는데, 의외로 간단합니다.
Lambda함수에서 [작업] → [새 버전 발행]을 누르세요.

설명은 안 적어도 됩니다.
‘게시’ 하시면

버전: 1이 생긴 것을 확인하실 수 있습니다.

[구성] 탭으로 이동해서 [프로비저닝된 동시성]을 누르고, [편집]을 누르세요.

여기에 예상 되는 최소 동시 접속자 수를 넣고 만들면 끝입니다.

하지만 예상치 못한 경고문을 보실 수도 있어요.
AWS에서는 갑작스러운 과금 방지를 위해 신규 계정은 이런 Validation을 걸어둡니다.

※ 허용되는 최대 프로비저닝된 동시성은 사용 가능한 예약되지 않은 동시성(10)에서 예약되지 않은 최소 계정 동시성(10)을 뺀 값인 0입니다.

따로 고객센터에 티켓을 넣어서 풀어달라고 해야 풀 수 있다고 하네요.
전 당시엔 그냥 서비스 상용화 가능성 보일 때 쯤에 하려고 넘어갔습니다 ㅎㅎ
괜히 과금 만들고 싶진 않아서요.

마치며

이번 글에선 간단히 AWS Lambda를 다루는 방법에 대해 작성했습니다.
비싸고 빠른 대규모 아키텍처가 아닌, 소규모 서비스 출시 관점으로 생각하면서 개발해보니 ec2가 아닌 새로운 서비스도 사용해 보는 것도 나름 재밌는 거 같습니다.

다음 포스팅에서는 RDBMS(RDS)가 아닌 DynamoDB를 선택한 이유와 NoSQL 모델링에 작성하겠습니다.