서버리스로 더 가볍게 만들기

서버리스는 서버가 없다는 뜻이 아니다

지금까지 우리는 EC2를 만들고, 로드 밸런서로 요청을 나누고, Auto Scaling으로 서버 수를 조절하는 구조를 배웠다. 이 방식은 웹 서비스를 이해하는 데 매우 중요하다. 서버가 어디에 있고, 네트워크가 어떻게 연결되고, 장애가 나면 어떤 일이 생기는지 직접 볼 수 있기 때문이다.

하지만 모든 기능에 항상 EC2가 필요한 것은 아니다. 예를 들어 회원 가입 후 환영 이메일을 보내는 기능, 이미지가 업로드되면 썸네일을 만드는 기능, 매일 밤 정해진 시간에 보고서를 생성하는 기능은 계속 켜져 있는 서버가 없어도 된다. 일이 생겼을 때만 잠깐 실행되면 충분하다.

서버리스는 바로 이런 방식이다. 서버가 실제로 사라지는 것은 아니다. 서버는 여전히 어딘가에서 실행된다. 다만 AWS가 서버 준비, 실행 환경 관리, 확장, 장애 복구의 상당 부분을 대신 맡아 준다. 우리는 "어떤 이벤트가 발생하면 어떤 코드를 실행할지"에 더 집중한다.

서버리스의 핵심 장점은 가볍게 시작할 수 있다는 점이다. 작은 기능을 빠르게 만들고, 사용량이 적을 때는 비용을 낮게 유지할 수 있다. 대신 실행 시간 제한, 콜드 스타트, 권한 설정 같은 제약도 함께 이해해야 한다. 운영이 완전히 사라지는 것이 아니라, 서버 관리 중심의 운영에서 이벤트, 권한, 로그, 비용을 관리하는 운영으로 성격이 바뀐다고 보면 된다.

AI 생성 이미지

Lambda는 필요할 때만 실행되는 코드 조각이다

AWS Lambda는 서버리스 컴퓨팅의 대표 서비스다. EC2가 "빌려 쓰는 서버"라면, Lambda는 "필요할 때 실행되는 함수"에 가깝다.

예를 들어 사용자가 /hello 주소로 요청을 보냈다고 하자. 이 요청이 Lambda와 연결되어 있다면 AWS는 Lambda 실행 환경을 준비하고, 우리가 작성한 코드를 실행한 뒤, 결과를 돌려준다. 요청이 없을 때는 우리가 직접 서버를 켜 둘 필요가 없다.

비용 방식도 EC2와 다르다. EC2는 인스턴스가 켜져 있는 시간에 따라 비용이 발생한다. 반면 Lambda는 주로 요청 수와 실행 시간, 그리고 함수에 할당한 메모리 크기에 따라 비용이 계산된다. 함수가 0.2초 실행되고 끝나면 그만큼만 계산된다. 그래서 요청이 가끔 들어오는 기능이나, 짧게 끝나는 작업에는 매우 효율적이다.

다만 "항상 Lambda가 더 싸다"는 뜻은 아니다. 요청이 매우 많고 실행 시간이 길다면 EC2, 컨테이너, 또는 다른 배포 방식이 더 적합할 수 있다. 서버리스는 비용을 없애는 마법이 아니라, 서버 운영 부담을 줄이고 사용량에 맞춰 실행 단위를 잘게 나누는 선택지다.

Lambda 함수를 만들 때는 보통 다음을 정한다.

• 런타임: Python, Node.js, Java 같은 실행 언어

• 핸들러: 이벤트가 들어왔을 때 처음 실행될 함수

• 메모리: 함수에 할당할 메모리 크기

• 제한 시간: 함수가 최대 얼마나 실행될 수 있는지

• IAM 역할: 함수가 어떤 AWS 서비스에 접근할 수 있는지

여기서 IAM 역할이 중요하다. Lambda가 DynamoDB에 데이터를 저장해야 한다면, 해당 테이블에 쓰기 권한이 있어야 한다. 반대로 S3나 RDS를 사용하지 않는 함수라면 그 권한은 없어야 한다. 서버리스에서도 최소 권한 원칙은 그대로 적용된다.

API Gateway와 Lambda로 HTTP API 만들기

사용자가 웹이나 모바일 앱에서 Lambda를 직접 호출하는 경우는 많지 않다. 보통 앞에 HTTP 입구가 필요하다. 이 역할을 하는 서비스가 Amazon API Gateway다.

API Gateway는 사용자의 HTTP 요청을 받아 뒤쪽의 Lambda로 전달한다. 이전에 배운 로드 밸런서가 서버 앞의 입구 역할을 했다면, API Gateway는 서버리스 API 앞의 입구 역할을 한다고 볼 수 있다.

간단한 흐름은 다음과 같다.

1. 사용자가 GET /hello로 요청을 보낸다.

2. API Gateway가 요청 경로와 메서드를 확인한다.

3. 연결된 Lambda 함수를 실행한다.

4. Lambda가 응답 데이터를 만든다.

5. API Gateway가 HTTP 응답으로 사용자에게 돌려준다.

예를 들어 Lambda가 다음과 같은 JSON을 반환할 수 있다.

{
  "message": "Hello from serverless"
}

이 정도의 기능이라면 EC2를 만들고, 웹 서버를 설치하고, 포트를 열고, 로드 밸런서를 붙이는 과정 없이도 구현할 수 있다. 그래서 서버리스는 작은 API, 내부 관리 도구, 자동화 작업, 이벤트 처리 기능을 빠르게 만들 때 특히 유용하다.

실습 흐름은 단순하다.

1. Lambda 함수를 만든다.

2. 테스트 이벤트로 함수가 잘 실행되는지 확인한다.

3. API Gateway에서 HTTP API를 만든다.

4. GET /hello 경로를 Lambda와 연결한다.

5. 브라우저나 curl로 호출해 응답을 확인한다.

6. 실습 후 API와 Lambda를 삭제해 불필요한 비용을 막는다.

처음에는 인증 없이 테스트할 수 있지만, 실제 서비스에서는 인증과 호출 제한을 고려해야 한다. 공개 API는 누구나 호출할 수 있기 때문이다. API Gateway의 인증 설정, 사용량 제한, 로깅을 함께 검토해야 안전하다.

비동기 처리는 SQS, SNS, EventBridge로 나눈다

모든 작업을 사용자가 기다리게 만들 필요는 없다. 주문 요청을 예로 들어 보자. 사용자는 "주문이 접수되었습니다"라는 응답을 빠르게 받고 싶다. 하지만 결제 확인, 재고 차감, 알림 발송, 정산 데이터 생성은 뒤에서 차례로 처리되어도 된다.

이때 비동기 처리가 필요하다. 비동기는 요청한 작업을 즉시 끝까지 처리하지 않고, 일단 받아 둔 뒤 나중에 처리하는 방식이다. AWS에서는 SQS, SNS, EventBridge가 자주 사용된다.

SQS는 대기열이다. 해야 할 일을 줄 세워 놓는다고 생각하면 쉽다. Lambda가 한 번에 처리하기 어려운 요청이 몰리면, SQS가 메시지를 보관하고 Lambda가 가능한 만큼 꺼내 처리한다. 갑자기 트래픽이 몰려도 작업을 완충하는 역할을 한다.

다만 SQS를 사용할 때는 "메시지가 한 번만 처리된다"고 단정하면 안 된다. 네트워크 문제나 재시도 때문에 같은 메시지가 다시 전달될 수 있다. 그래서 메시지를 처리하는 Lambda는 같은 메시지를 두 번 받아도 문제가 없도록 설계하는 것이 좋다. 순서가 꼭 중요하다면 일반 SQS 큐가 아니라 FIFO 큐 같은 선택지도 함께 검토해야 한다.

SNS는 알림 확성기에 가깝다. 하나의 메시지를 여러 구독자에게 동시에 전달할 때 사용한다. 예를 들어 주문 완료 이벤트가 발생했을 때 이메일 알림, 문자 알림, 내부 분석 시스템에 동시에 알려야 한다면 SNS가 어울린다.

EventBridge는 이벤트 라우터다. "이런 일이 발생하면 저 서비스로 보내라"는 규칙을 만든다. 예를 들어 OrderCreated 이벤트가 들어오면 결제 처리 Lambda로 보내고, UserDeleted 이벤트가 들어오면 데이터 정리 작업으로 보내는 식이다. 서비스들이 서로를 직접 알지 않아도 이벤트를 통해 느슨하게 연결할 수 있다.¹

간단히 구분하면 다음과 같다.

• SQS: 작업을 대기열에 쌓아 두고, 처리 가능한 속도에 맞춰 안정적으로 꺼내 처리하고 싶을 때

• SNS: 하나의 알림을 여러 대상으로 퍼뜨리고 싶을 때

• EventBridge: 이벤트 종류에 따라 여러 서비스로 규칙 기반 연결을 하고 싶을 때

처음부터 세 서비스를 모두 써야 하는 것은 아니다. 사용자가 기다리지 않아도 되는 작업이 있다면 먼저 SQS부터 떠올리면 된다. 이후 여러 대상에게 알림을 보내야 하면 SNS, 서비스 간 이벤트 흐름이 복잡해지면 EventBridge를 검토하면 된다.

DynamoDB와 Lambda로 서버리스 백엔드 만들기

서버리스 백엔드의 대표 조합은 API Gateway, Lambda, DynamoDB다. API Gateway가 요청을 받고, Lambda가 비즈니스 로직을 실행하고, DynamoDB가 데이터를 저장한다.

예를 들어 간단한 메모 API를 만든다고 하자.

• POST /notes: 새 메모 저장

• GET /notes/{id}: 특정 메모 조회

• DELETE /notes/{id}: 메모 삭제

이 구조에서는 EC2 웹 서버를 직접 운영하지 않는다. 요청이 들어올 때만 Lambda가 실행되고, 데이터는 DynamoDB 테이블에 저장된다. DynamoDB는 서버를 직접 설치하거나 디스크를 관리하지 않아도 되는 관리형 NoSQL 데이터베이스다.

기본 흐름은 다음과 같다.

1. 사용자가 API Gateway로 메모 저장 요청을 보낸다.

2. API Gateway가 요청 본문을 Lambda에 전달한다.

3. Lambda가 입력값을 검사한다.

4. Lambda가 DynamoDB 테이블에 항목을 저장한다.

5. Lambda가 저장 결과를 응답으로 반환한다.

여기서도 권한이 중요하다. Lambda 실행 역할에는 해당 DynamoDB 테이블에 대한 PutItem, GetItem, DeleteItem 같은 필요한 작업만 허용한다. 모든 DynamoDB 테이블에 모든 권한을 주는 방식은 피해야 한다.

DynamoDB를 사용할 때는 테이블 설계도 중요하다. 관계형 데이터베이스처럼 나중에 아무 조건으로나 자유롭게 조인해서 조회하는 방식이 아니다. "어떤 키로 자주 조회할 것인가"를 먼저 정해야 한다. 메모 API라면 사용자 ID와 메모 ID를 기준으로 조회할 가능성이 높다. 이 조회 패턴에 맞춰 파티션 키와 정렬 키를 설계해야 한다.

서버리스에서 주의할 점

서버리스는 편하지만 제약이 있다. 이 제약을 모르고 만들면 운영 중에 예상치 못한 문제가 생긴다.

첫째, 콜드 스타트가 있다. Lambda 함수가 한동안 실행되지 않다가 처음 호출되면 실행 환경을 준비하는 시간이 추가될 수 있다. 보통 짧은 작업에서는 큰 문제가 아니지만, 응답 시간이 매우 중요한 API라면 영향을 줄 수 있다.

둘째, 실행 시간 제한이 있다. Lambda는 무한히 오래 실행되는 작업에 적합하지 않다. 긴 영상 변환, 대용량 배치, 오래 유지해야 하는 연결은 Lambda보다 컨테이너나 EC2가 더 나을 수 있다. Lambda는 짧고 명확한 작업에 잘 맞는다.

셋째, 상태를 함수 안에 저장하면 안 된다. Lambda 실행 환경은 재사용될 수 있지만 언제든 사라질 수 있다. 그래서 중요한 데이터는 DynamoDB, S3, RDS 같은 외부 저장소에 저장해야 한다. 임시 파일이나 캐시를 잠깐 활용할 수는 있지만, 그 값이 다음 실행에도 반드시 남아 있다고 기대하면 안 된다.

넷째, 중복 실행을 고려해야 한다. 네트워크 오류나 재시도 때문에 같은 이벤트가 두 번 처리될 수 있다. 결제, 주문, 포인트 적립처럼 중복 처리가 위험한 기능은 같은 요청을 한 번만 처리하도록 설계해야 한다. 이를 멱등성이라고 한다. 쉽게 말해 같은 요청이 여러 번 와도 결과가 한 번 처리된 것처럼 유지되게 만드는 것이다.

다섯째, 관찰 가능성을 챙겨야 한다. 서버가 눈에 보이지 않는다고 운영이 사라지는 것은 아니다. CloudWatch Logs로 로그를 남기고, 오류 수와 실행 시간을 확인해야 한다. SQS를 사용한다면 처리되지 못한 메시지를 모아 두는 데드 레터 큐도 검토해야 한다.

마지막으로 비용을 확인해야 한다. 기본적인 Lambda 함수는 요청이 없으면 비용이 거의 없지만, API Gateway 호출 수, DynamoDB 읽기·쓰기, CloudWatch 로그 저장, EventBridge 이벤트, SQS 메시지 요청이 모두 비용에 영향을 준다. 작은 서비스는 저렴하게 시작할 수 있지만, 호출이 많아지면 구성별 비용을 따로 봐야 한다.

언제 서버리스가 좋은 선택일까

서버리스는 다음 상황에 잘 맞는다.

• 요청이 가끔 발생하거나 사용량 변동이 큰 기능

• 짧게 실행되고 결과가 명확한 작업

• 파일 업로드 후 처리, 알림 발송, 예약 작업 같은 이벤트 기반 기능

• 빠르게 실험하고 싶은 작은 API

• 서버 패치와 운영 부담을 줄이고 싶은 팀

반대로 다음 상황에서는 신중해야 한다.

• 항상 일정한 고성능이 필요한 서비스

• 실행 시간이 길고 무거운 작업

• 지연 시간이 매우 민감한 API

• 복잡한 네트워크 연결과 지속 연결이 필요한 시스템

• 기존 서버 기반 애플리케이션을 거의 그대로 옮기려는 경우

서버리스는 EC2를 대체하는 유일한 답이 아니다. EC2, 컨테이너, 서버리스는 서로 경쟁만 하는 선택지가 아니라 상황에 따라 함께 쓰는 도구다. 정적 파일은 S3와 CloudFront로 제공하고, 간단한 API는 API Gateway와 Lambda로 만들고, 복잡한 백엔드는 컨테이너나 EC2에서 운영할 수 있다.

중요한 기준은 "이 기능을 계속 켜 둔 서버가 처리해야 하는가, 아니면 이벤트가 있을 때만 실행해도 되는가"이다. 이 질문에 답할 수 있으면 서버리스가 필요한 순간을 훨씬 쉽게 판단할 수 있다.

참고

¹Event-Driven Serverless Architecture on AWS