서버리스 아키텍처 구성 요소와 배포 흐름 뜯어보기

과금 방식을 요청 수·실행 시간 기준으로 바꾸면 유휴 서버 비용이 사라진다. 서버리스 컴퓨팅(Serverless Computing)은 서버 프로비저닝·패치·스케일링을 클라우드 제공자가 전적으로 관리하고, 사용자는 함수 또는 관리형 서비스 조합으로 애플리케이션을 구축하는 모델이다. 클라우드 네이티브 워크로드의 비용 효율·확장성·운영 편의성을 극대화하는 이 아키텍처 패턴을 구성 요소별로 뜯어본다.

함수와 관리형 서비스, 실행 단위

FaaS(Function as a Service)는 코드를 함수 단위로 이벤트 트리거해 실행하고, BaaS(Backend as a Service)는 인증·데이터베이스·스토리지·메시징 같은 관리형 백엔드 서비스를 제공한다. 핵심 특성은 이벤트 드리븐, 짧은 라이프사이클과 무상태, 자동 확장·축소, 운영 작업의 완전 또는 준완전 위임이다. 트레이드오프도 구조적으로 존재한다. 콜드 스타트, 벤더 종속성, 실행 제한(시간·네트워킹)이 그것이다.

실행 모델과 스케줄링

API Gateway, 메시지 큐, 스트림, 오브젝트 스토리지, 스케줄러 같은 이벤트 소스가 함수를 트리거하는 구조이며, 자동 수평 확장으로 버스트 트래픽을 흡수한다. 함수는 무상태(stateless) 설계가 전제이므로 상태는 외부 저장소에 유지해야 한다.

컴퓨트 계층(FaaS)이 다루는 것들

함수는 단위 배포·버전·별칭으로 관리하며, 프로비저닝된 동시성(Provisioned Concurrency)으로 콜드 스타트를 완화한다. 언어·런타임은 다양하게 지원되지만, 패키지 크기와 의존성 수가 콜드 스타트·초기화 지연의 주요 요인이라는 점은 변하지 않는다.

관리형 백엔드(BaaS)와 관측성

인증(Cognito·Auth0 등), 데이터 저장(RDS·NoSQL·Storage), 메시징(Queue·Stream), API 관리(API Gateway) 같은 서비스를 조합해 구성한다. 데이터 일관성·내구성 보장 수준과 비용은 서비스별로 다르고, 트랜잭션은 사가(Sagas)·아웃박스 패턴으로 보완한다. 관측성은 구조화 로그, 분산 트레이싱, 메트릭(에러율·지연·동시성), 알람으로 확보하며, DLQ·리트라이·백오프 전략으로 실패 내성을 갖춘다. 배포는 SAM·CDK·Terraform 같은 IaC로 재현성과 거버넌스를 확보하고, 스테이지·릴리스 채널(버전·별칭)로 점진 배포한다.

보안·거버넌스는 어디를 지켜야 하는가

최소 권한 IAM, 시크릿 관리(Secrets Manager·Parameter Store), VPC 격리·아웃바운드 제어를 적용한다. 데이터는 분류·암호화(KMS)하고, 멀티테넌시 격벽과 비용·동시성 가드레일로 소비를 통제한다.

요청이 함수 실행까지 흐르는 경로

⤢✕

현장에서 쓰이는 패턴

API 백엔드·웹훅 처리는 API Gateway + Lambda + DynamoDB/S3로 구성하고, 인증·요청 유효성 검증에 서킷브레이커·스로틀링을 더한다. 서드파티 웹훅을 수신·정규화·검증한 뒤 비동기 파이프라인으로 넘긴다.

데이터 파이프라인·ETL은 S3 업로드 이벤트→Lambda 변환→Kinesis/Firehose/DWH 적재로 이어지며 배치·마이크로배치를 혼용한다. 스키마 진화, 재시도·DLQ, 멱등 처리 키 설계가 필수다.

스트리밍 처리·알림은 Kinesis·Kafka 소비자 함수로 실시간 집계·알림을 발송하고 처리량 변화에 자동으로 대응한다. 실패 레코드는 DLQ와 재처리 잡으로 분기한다.

스케줄러 기반 운영 작업은 EventBridge·Cloud Scheduler로 리포트·보관 정책·비용 점검 같은 주기 작업을 수행하며, 단명 태스크 중심으로 비용과 관리를 최소화한다.

AI·비동기 워크플로는 프롬프트 전처리→모델 호출→후처리 파이프라인으로 구성되고, 장시간 작업은 Step Functions 같은 상태 머신으로 관리한다. API Rate Limit 보호, 코스트 캡, 타임아웃 설계가 함께 필요하다.

서버리스 FaaS와 컨테이너를 나란히 놓으면

항목	서버리스 FaaS	컨테이너(Kubernetes)
성능	콜드 스타트 존재, 짧은 태스크에 유리	워밍업 필요 없음, 장기 실행·고정 부하에 유리
확장성	자동 확장·축소, 초단위 탄력	HPA/스케일러 구성 필요, 세밀 제어 가능
일관성	무상태 전제, 외부 트랜잭션·사가 필요	상태풀/스테이트풀워크로드까지 포괄
안정성	관리형 인프라, 리트라이·DLQ 패턴	노드/클러스터 운영 책임, 고가용성 직접 설계
운영 편의	인프라 관리 최소, 과금 단순	네트워킹/스토리지/옵저버빌리티 직접 통합

API 하나를 배포해보면

전제조건은 AWS Lambda(Python 3.11), Amazon API Gateway HTTP API, AWS SAM CLI ≥ 1.116, AWS 계정·권한이다. 핸들러 코드(app.py)는 다음과 같다.

# Python 3.11, 최소 의존성. 글로벌 초기화로 콜드 스타트 비용 절감
import json
import os
from datetime import datetime, timezone

def _now_iso():
    return datetime.now(timezone.utc).isoformat()

def handler(event, context):
    # 입력 검증
    method = event.get("requestContext", {}).get("http", {}).get("method", "GET")
    if method not in ("GET", "POST"):
        return {"statusCode": 405, "headers": {"Content-Type": "application/json"}, "body": json.dumps({"message": "method not allowed"})}

    # 멱등성 키(있으면 추출)
    idem_key = None
    headers = event.get("headers") or {}
    for k, v in headers.items():
        if k.lower() == "idempotency-key":
            idem_key = v
            break

    body = {"ok": True, "time": _now_iso(), "idempotencyKey": idem_key}
    return {"statusCode": 200, "headers": {"Content-Type": "application/json"}, "body": json.dumps(body)}

SAM 템플릿(template.yaml)은 다음과 같다.

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: Simple serverless API

Resources:
  ApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: .
      Handler: app.handler
      Runtime: python3.11
      MemorySize: 256
      Timeout: 10
      Tracing: Active
      Events:
        HttpApi:
          Type: HttpApi
          Properties:
            Path: /hello
            Method: ANY
      Policies:
        - AWSXRayDaemonWriteAccess
Outputs:
  ApiUrl:
    Value: !Sub "https://${ServerlessHttpApi}.execute-api.${AWS::Region}.amazonaws.com/hello"

배포는 sam build 다음 sam deploy --guided로 진행하고, 완료 후 출력된 ApiUrl을 호출해 확인한다. 부하 테스트를 할 때는 프로비저닝된 동시성을 설정해 p95 지연을 안정화하는 것이 좋다.

보안·아키텍처·운영에서 놓치기 쉬운 것들

보안에서는 최소 권한 IAM, 아웃바운드 제어(VPC + egress 정책), Secrets Manager·Parameter Store 기반 시크릿 관리를 적용한다. 입력 검증·JWT 검증·요청 서명 검증(Webhook)과 KMS 암호화 기본값 준수도 필요하다. 아키텍처에서는 무상태·멱등 처리(Idempotency-Key, 아웃박스 패턴)를 기본으로 하고, 장시간 작업은 상태 머신·큐 기반으로 분해하며 스키마 진화 전략(버전 필드·백필)과 이벤트 스키마 레지스트리를 관리한다. 운영에서는 프로비저닝된 동시성·패키지 슬리밍·VPC 최적화로 콜드 스타트를 완화하고, 동시성·스로틀 가드레일로 비용을 통제하며, 구조화 로그(JSON)와 트레이싱 상관관계(Trace/Span ID), 에러 버짓·SLO 기반 알람을 운영한다.

비용과 성능이 갈리는 지점

비연속 트래픽·스파이크 워크로드에서는 서버 상시 가동 대비 TCO를 3070% 절감한 사례가 관찰되며, 고정 대기 리소스가 사라지는 효과가 크다. 다만 지속적인 고정 고부하 워크로드는 컨테이너 상시 가동 대비 비용이 역전될 가능성이 있다. 성능 측면에서는 초당 수천수만 요청까지 자동 확장할 수 있고(제공자·리전·할당량에 의존, 최신 정보 확인 필요), 프로비저닝된 동시성을 쓰면 p95 지연이 안정화된다. 콜드 스타트는 언어·VPC·패키지 크기에 따라 50~500ms 수준으로 관찰된다(최신 정보 확인 필요). 운영 생산성 측면에서는 패치·스케일링·용량 관리가 사라지면서 운영 시간이 40% 이상 절감되고 배포 주기가 짧아지며, 표준화된 관측·알람·IaC가 변경 리스크를 줄인다. 안정성 측면에서는 관리형 내구성과 리전 가용성이 보장되고, 재시도·DLQ·멱등 설계로 데이터 손실을 최소화하며, 암호화·최소 권한 같은 보안 기본값이 규정 준수를 쉽게 만든다.

언제 쓸지는 워크로드가 정한다

벤더 종속성은 추상화 레벨이 높아질수록 이식성이 떨어지는 문제라, 포터빌리티가 필요하면 OpenFunction·Knative 같은 대안을 검토할 만하다. 비용 역전 가능성도 감안해 고정 고부하·지속 실행 워크로드는 컨테이너와 혼합 배치하는 편이 낫다. 프로토타이핑·API 백엔드·ETL·스케줄 태스크·이벤트 파이프라인은 서버리스로, 고정 고부하는 컨테이너로 나누고 표준화된 IaC·관측·거버넌스를 갖추면 팀 생산성과 안정성을 함께 얻을 수 있다.