AWS Lambda와 API Gateway 서버리스 완벽 가이드: 서버 없이 백엔드 구축하기

"사이드 프로젝트에 백엔드가 필요해서 AWS EC2를 띄웠는데, 아무도 접속 안 하는 새벽에도 매달 2만 원씩 요금이 나가고 있습니다. 이거 정상인가요?"

안녕하세요! 클라우드 인프라 요금 다이어트와 효율적인 아키텍처 설계에 진심인 개발자입니다.

주니어 개발자나 프론트엔드 개발자가 개인 프로젝트를 진행할 때 가장 큰 장벽은 '백엔드 서버 유지비'입니다. 24시간 내내 켜두어야 하는 기존의 서버 호스팅(EC2 등) 방식은 트래픽이 없는 시간대에도 불필요한 비용을 발생시킵니다.

이러한 요금 폭탄의 공포와 서버 관리의 복잡함을 한 번에 해결해 주는 현대 클라우드의 마법이 바로 '서버리스(Serverless)'입니다. 그중에서도 가장 대중적이고 강력한 조합인 AWS Lambda와 API Gateway를 사용하면, 코드가 실행된 딱 그 0.1초의 찰나에만 비용을 지불하는 환상적인 백엔드를 구축할 수 있습니다.

이번 글에서는 서버리스가 도대체 무엇인지 직관적인 비유로 알아보고, 현업에서 이 두 가지 서비스를 어떻게 결합하여 상용 API를 만드는지, 그리고 반드시 마주치게 되는 '콜드 스타트(Cold Start)' 에러 해결법까지 깊이 있게 파헤쳐 보겠습니다.

1. 서버리스(Serverless)란? 진짜 서버가 없는 걸까?

서버리스라는 단어를 처음 들으면 "서버가 없는데 코드가 어디서 돌아가지?"라는 의문이 생깁니다. 결론부터 말하자면 서버는 존재하지만, 개발자인 내가 직접 서버를 관리할 필요가 없다는 뜻입니다.

이를 '자가용(EC2)'과 '택시(Lambda)'에 비유해 보겠습니다.

• 기존 서버 (AWS EC2) = 자가용:
• 차를 사면(서버 임대), 내가 운전을 안 하고 주차장에 세워만 두어도 매달 보험료와 주차비(고정 요금)가 나갑니다. 엔진 오일도 직접 갈아야 하고(OS 업데이트), 손님이 많아지면 더 큰 차로 직접 바꿔야 합니다(스케일 업).
• 서버리스 (AWS Lambda) = 택시:
• 택시는 차를 소유하지 않습니다. 내가 이동하고 싶을 때(API 요청이 들어올 때) 택시를 부르고, 딱 목적지까지 달린 거리(코드 실행 시간)만큼만 미터기 요금을 지불합니다. 평소에는 요금이 0원이며, 차단기 고장이나 정비는 택시 회사(AWS)가 알아서 다 해줍니다.

2. API Gateway와 Lambda의 환상적인 콤비 (동작 원리)

택시(Lambda)가 준비되었다면, 손님(클라이언트)의 호출을 받아 택시를 배차해 줄 '콜택시 센터'가 필요합니다. 이 역할을 하는 것이 바로 Amazon API Gateway입니다.

웹이나 앱에서 [https://api.my-domain.com/users](https://api.my-domain.com/users) 라는 주소로 사용자 정보를 달라고 GET 요청을 보내면, 그 요청은 직접 Lambda로 가지 않고 API Gateway를 거치게 됩니다.

[클라이언트 브라우저 / 앱] 
         │ 
    (HTTP GET /users 요청)
         ▼
[Amazon API Gateway (콜센터 직원)] 
         │ "어? /users 경로네? 사용자 조회 담당 Lambda를 깨워라!"
         ▼
[AWS Lambda (요리사 / 함수)]
         │ DB 조회 및 JSON 데이터 생성 후 반환
         ▼
[클라이언트 브라우저 / 앱] (결과 수신)

📊 API Gateway와 Lambda 역할 비교

서비스	아키텍처 역할	비유적 역할	주요 기능 및 특징
API Gateway	문지기 & 라우터	레스토랑 홀 매니저	URL 경로 매핑, 트래픽 제한(Rate Limit), 인증 인가(CORS, JWT), 파라미터 검증
AWS Lambda	컴퓨팅 연산 처리	주방 요리사	비즈니스 로직 실행, 데이터베이스 연동, 외부 API 통신 (최대 실행 시간 15분)

API Gateway가 악성 트래픽을 막아주고 권한을 검사한 뒤, 안전한 요청만 Lambda로 넘겨주기 때문에 백엔드 시스템이 매우 견고해집니다.

3. 현업 실무 시나리오: '좋아요' 카운트 API 만들기

실제 제가 프론트엔드 위주의 포트폴리오 사이트를 만들 때, 백엔드 서버 없이 게시글의 '좋아요' 버튼 기능을 구현했던 시나리오입니다.

Lambda 함수는 Node.js, Python, Java 등 다양한 언어를 지원합니다. 아래는 Node.js를 기반으로 한 Lambda의 기본적인 코드 뼈대(Handler)입니다.

JavaScript

 

// index.mjs (AWS Lambda 핸들러 함수)

export const handler = async (event, context) => {
    // 1. API Gateway가 넘겨준 요청(event)에서 파라미터를 꺼냅니다.
    // 예: /likes?postId=123
    const postId = event.queryStringParameters?.postId;

    if (!postId) {
        return {
            statusCode: 400,
            body: JSON.stringify({ message: 'postId가 필요합니다.' }),
        };
    }

    try {
        // 2. 데이터베이스(예: DynamoDB)에서 좋아요 수를 +1 증가시킵니다.
        const currentLikes = await updateLikesInDatabase(postId);

        // 3. API Gateway를 통해 프론트엔드로 응답을 보냅니다.
        return {
            statusCode: 200,
            headers: {
                "Access-Control-Allow-Origin": "*", // CORS 허용 필수!
            },
            body: JSON.stringify({ 
                message: '좋아요 성공!', 
                likes: currentLikes 
            }),
        };
    } catch (error) {
        console.error("DB 업데이트 중 에러 발생:", error);
        return {
            statusCode: 500,
            body: JSON.stringify({ message: '서버 내부 오류가 발생했습니다.' }),
        };
    }
};

💡 실무 핵심 포인트:

프론트엔드에서 API를 호출할 때 브라우저의 CORS 에러를 막으려면, Lambda의 반환값(Return) headers 객체에 반드시 "Access-Control-Allow-Origin": "*" 를 포함해서 내려주어야 합니다. 이것을 누락해서 하루 종일 삽질하는 주니어 분들이 정말 많습니다!

4. 주니어가 겪는 서버리스 최대 난제: '콜드 스타트(Cold Start)'

서버리스를 실무에 도입하면 첫 테스트에서 묘한 이질감을 느끼게 됩니다.

"어? 방금 첫 번째 클릭 때는 로딩이 3초나 걸렸는데, 두 번째 클릭부터는 0.1초 만에 되네요?"

이 현상이 바로 서버리스의 태생적 한계인 '콜드 스타트(Cold Start)'입니다.

Lambda는 평소에 비용을 아끼기 위해 쿨쿨 잠을 자고 있습니다(컨테이너 종료 상태). 그런데 갑자기 요청이 들어오면, AWS가 부랴부랴 1) 가상 환경을 띄우고 2) 코드를 다운로드하고 3) 초기화하는 과정을 거치게 됩니다. 이 과정에서 발생하는 몇 초간의 지연 시간을 콜드 스타트라고 부릅니다. 반면, 한 번 깨어난 Lambda는 당분간(약 10~15분) 잠들지 않고 대기하는데, 이때 요청이 들어오면 지연 없이 즉시 처리하는 것을 웜 스타트(Warm Start)라고 합니다.

✅ 실무에서의 콜드 스타트 해결책

1. 가벼운 언어 선택: Java나 C#처럼 초기화가 무거운 언어보다는, Node.js나 Python, Go 언어를 사용하는 것이 콜드 스타트를 획기적으로 줄여줍니다.
2. EventBridge(CloudWatch Events)로 핑(Ping) 날리기: 10분마다 람다를 찔러주는(호출하는) 빈 이벤트를 예약해 두어 람다가 잠들지 않게 괴롭히는(?) 꼼수입니다.
3. Provisioned Concurrency (예약된 동시성): 트래픽이 많고 지연 시간이 치명적인 상용 서비스라면, AWS에 돈을 조금 더 내고 "항상 람다 5대는 깨워둬!"라고 예약할 수 있는 기능입니다.

5. 실무 경험에서 얻은 서버리스 설계 팁 3가지

서버리스 아키텍처를 프로덕션 환경에 배포하며 체득한 피와 땀이 섞인 팁을 공유합니다.

• 팁 1: API Gateway의 29초 타임아웃을 명심하세요.
• Lambda 자체는 최대 15분까지 코드를 실행할 수 있습니다. 하지만 그 앞단에 서 있는 API Gateway는 무조건 29초 안에 응답을 주지 않으면 클라이언트에게 504 Gateway Timeout 에러를 뱉어버립니다. 딥러닝 모델 추론이나 대용량 엑셀 다운로드처럼 30초 이상 걸리는 무거운 작업은 API Gateway를 거치는 동기식으로 설계하면 절대 안 됩니다. (이 경우 비동기식 설계가 필요합니다.)
• 팁 2: 모든 기능을 하나의 Lambda에 때려 넣지 마세요 (Fat Lambda 지양).
• Express.js나 Spring Boot로 라우팅을 짜듯 하나의 Lambda 파일 안에 유저 조회, 상품 등록, 결제 로직을 다 넣으면 (이른바 뚱뚱한 람다), 파일 용량이 커져 콜드 스타트가 심해지고 유지보수가 지옥이 됩니다. 기능 단위(마이크로서비스)로 람다를 쪼개서 API Gateway에서 URL별로 연결해 주는 것이 정석입니다.
• 팁 3: 환경 변수(Environment Variables)로 DB 비밀번호를 하드코딩하지 마세요.
• 코드 내부에 DB 비밀번호를 적어두는 것은 금물입니다. Lambda의 구성 탭에서 환경 변수로 분리하여 주입하고, 더 높은 보안이 필요하다면 AWS Secrets Manager나 Parameter Store를 결합해 런타임에 안전하게 비밀번호를 가져오도록 설계하세요.

클라우드의 발전으로 이제 개발자는 '서버 인프라 구축'이라는 무거운 짐을 내려놓고, 오직 '비즈니스 로직(코드)'에만 집중할 수 있는 시대가 되었습니다. 특히 사이드 프로젝트나 포트폴리오를 준비하는 주니어 개발자에게 매달 0원에 수렴하는 비용으로 무한한 확장이 가능한 서버리스 아키텍처는 선택이 아닌 필수 무기입니다. 오늘 배운 내용을 바탕으로 나만의 첫 번째 서버리스 API를 띄워보시길 바랍니다!