[AWS] Serverless
Serverless
서버를 직접 관리하지 않고 코드 실행에만 집중하는 서버리스 아키텍처 정리. 동작 원리부터 EC2와의 비교, Lambda와 API Gateway까지.
| Category | Level | Reads | Status |
|---|---|---|---|
| AWS · Compute | 초급 ~ 중급 | 약 10분 | VERIFIED |
서버리스(Serverless)란?
서버리스는 "서버가 없다"는 뜻이 아니라, 개발자가 서버의 존재를 신경 쓰지 않아도 되는 컴퓨팅 모델이다.
서버 프로비저닝, OS 패치, 용량 계획, 오토스케일링 같은 인프라 관리를 AWS가 대신 처리해주고, 개발자는 비즈니스 로직(코드) 작성에만 집중한다. 즉 서버가 사라진 게 아니라 "누가 그 서버를 관리하느냐"가 바뀐 것이다.
내가 서버를 만들고, 켜두고, 패치하고, 트래픽에 맞춰 직접 늘리고 줄인다. 서버는 항상 "존재"한다.
요청이 올 때만 코드가 실행되고, 끝나면 사라진다. 서버는 AWS 뒤편에 있지만 내가 다룰 일이 없다.
동작 방식
서버리스 컴퓨팅의 핵심은 FaaS(Function as a Service) 모델이다. 코드를 함수 단위로 미리 업로드해두면, 특정 이벤트가 발생할 때만 그 함수가 실행된다.
HTTP 요청, 파일 업로드, 메시지 큐 도착, 스케줄 등 다양한 트리거가 함수를 깨운다.
클라우드가 코드를 실행할 컨테이너를 자동으로 준비한다. 이 과정에서 발생하는 초기화 지연을 콜드 스타트라고 부른다.
코드가 실행되고 결과를 반환한다. 함수는 기본적으로 Stateless(무상태)라 이전 호출의 상태를 기억하지 않는다.
유휴 시간이 지나면 컨테이너는 종료된다. 짧은 시간 안에 다시 호출되면 컨테이너를 재사용하는 웜 스타트로 더 빠르게 응답한다.
서버 기반(EC2)과 비교하면
EC2는 개발자가 직접 프로비저닝하고 관리하는 "항상 켜져 있는" 가상 서버다. 서버리스(Lambda)와 나란히 놓고 보면 차이가 명확해진다.
| 항목 | EC2 (서버 기반) | Lambda (서버리스) |
|---|---|---|
| 프로비저닝 | 인스턴스를 직접 생성·설정 | 필요 없음, 코드만 업로드 |
| 과금 방식 | 켜져 있는 시간만큼 (초/시간 단위) | 실행된 시간(ms) + 호출 횟수 |
| 유휴 상태 비용 | 트래픽 없어도 과금됨 | 호출 없으면 과금 없음 |
| 스케일링 | 오토스케일링 그룹 직접 구성 | 요청량에 따라 자동·즉시 확장 |
| 실행 시간 | 제한 없음 | 최대 15분 |
| 콜드 스타트 | 없음 (이미 부팅됨) | 있을 수 있음 |
| 운영 부담 | OS 패치·보안·용량 계획 직접 | AWS가 인프라 계층 관리 |
| 상태 유지 | 서버 메모리에 유지 가능 | 기본적으로 Stateless |
서버리스의 장단점
- 인프라 관리 부담 제로 — 프로비저닝, 패치, 스케일링 불필요
- 사용한 만큼만 과금 — 유휴 시간엔 비용 발생 안 함
- 즉각적인 자동 확장 — 트래픽 폭증에도 별도 설정 없이 병렬 실행
- 빠른 개발 속도 — 인프라 코드 없이 로직에만 집중
- 콜드 스타트 지연 — 뜸한 트래픽의 함수는 첫 요청이 느릴 수 있음
- 실행 시간·리소스 제한 — Lambda 최대 15분, 메모리 상한 존재
- 벤더 종속(Lock-in) — AWS 특화 구조라 이전이 까다로움
- 디버깅·모니터링이 상대적으로 복잡 — 분산된 함수 단위 실행
- 항상 부하가 큰 워크로드엔 오히려 비쌀 수 있음
언제 뭘 써야 효율적일까
트래픽이 간헐적이거나 예측 불가능한 API, 이벤트 기반 처리(업로드 트리거·큐 처리), 짧고 가벼운 작업, 빠른 MVP/프로토타입.
트래픽이 항상 높고 예측 가능한 서비스, 장시간 실행되는 배치·스트리밍 작업, 15분을 넘는 워크로드, 세밀한 OS·네트워크 제어가 필요한 경우.
AWS Lambda란?
Lambda는 AWS의 대표적인 FaaS 서비스다. 코드를 업로드해두면 이벤트가 발생할 때만 실행되고, 실행된 시간만큼만 과금되는 완전관리형 컴퓨트 서비스다.
주요 트리거
API Gateway 요청, S3 파일 업로드, DynamoDB 스트림, EventBridge 스케줄, SQS 메시지 등 대부분의 AWS 서비스 이벤트가 Lambda를 직접 호출할 수 있다.
- 자동 스케일링 — 동시 요청 수천 건까지 자동 확장
- 사용량 기반 과금 — 유휴 비용 없음
- AWS 서비스와 손쉬운 이벤트 통합
- 서버 관리가 아예 필요 없음
- 최대 실행 시간 15분 제한
- 콜드 스타트로 인한 지연 가능성
- 메모리 설정에 CPU 할당이 비례 — 세밀한 튜닝 필요
- 대용량·장시간 처리에는 부적합
사용 이유 — 이벤트 기반 백엔드 로직, 이미지 리사이징, 알림 처리, 크론잡 대체, 마이크로서비스의 개별 함수 단위 실행 등에 잘 맞는다.
Amazon API Gateway란?
API Gateway는 REST·HTTP·WebSocket API를 만들고 게시, 유지관리, 모니터링, 보안까지 관리해주는 완전관리형 서비스다. 클라이언트 요청을 받아 Lambda나 다른 AWS 서비스로 라우팅하는 "현관문" 역할을 한다.
- 인증·인가 내장 (IAM, Cognito, Lambda Authorizer)
- 요청 제한(Throttling)·캐싱 지원
- 버전·스테이지 관리가 용이함
- Lambda와 완벽 통합해 서버리스 API를 빠르게 구축
- 리소스·메서드별 설정이 많아질수록 복잡해짐
- 요청이 한 단계를 더 거치므로 지연시간이 소폭 추가됨
- 호출량이 많아지면 비용이 누적됨
사용 이유 — Lambda 함수를 REST API로 외부에 노출하고 싶을 때, 인증·속도제한·모니터링을 직접 구현하지 않고 관리형으로 처리하고 싶을 때 선택한다.