lambda 서버리스컴퓨팅

March 4, 2026

TL;DR

lambda 서버리스컴퓨팅의 핵심 개념과 적용 범위를 정리
등장 배경과 필요한 이유를 요약
주요 특징과 실무 활용 포인트를 정리

1. 개념

lambda 서버리스컴퓨팅의 핵심 개념과 범위를 간단히 정의하고, 왜 이 문서가 필요한지 요점을 잡습니다.

2. 배경

이 주제가 등장하게 된 배경과 문제 상황, 기술적 맥락을 짚습니다.

3. 이유

왜 이 접근이 필요한지, 기존 대안의 한계나 목표를 설명합니다.

4. 특징

문서에서 다루는 주요 구성요소와 실전 적용 포인트를 정리합니다.

5. 상세 내용

AWS Lambda - 서버리스 컴퓨팅

작성일: 2026-03-04 카테고리: Cloud / AWS 포함 내용: Lambda, Serverless, FaaS, Cold Start, SnapStart, Provisioned Concurrency, API Gateway, EventBridge, Step Functions, Lambda@Edge, Firecracker, MicroVM, Event-Driven, Pay-per-execution, EC2 비교, ECS 비교, Fargate 비교, Lambda Function URL, Lambda Managed Instances, Durable Functions

1. AWS Lambda란 무엇인가

정의

AWS Lambda는 Amazon Web Services가 제공하는 서버리스(Serverless) 컴퓨팅 서비스다. 개발자가 서버를 직접 프로비저닝하거나 관리하지 않고, 코드(함수)만 업로드하면 AWS가 실행 환경 전체를 자동으로 관리해준다.

Lambda는 FaaS(Function as a Service) 모델의 대표 서비스로, 코드가 실행될 때만 비용이 발생하는 Pay-per-execution 방식이다.

핵심 개념

┌─────────────────────────────────────────────────────┐
│                  AWS Lambda 구조                     │
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐  │
│  │  Event    │───▶│ Handler  │───▶│   Response   │  │
│  │  Source   │    │ (진입점) │    │   (결과)     │  │
│  └──────────┘    └──────────┘    └──────────────┘  │
│       │               │                             │
│       │          ┌────┴────┐                       │
│       │          │ Context │ 실행시간, 메모리,     │
│       │          │         │ 요청ID 등             │
│       │          └─────────┘                       │
│       │                                             │
│  ┌────┴────────────────────────────────────────┐   │
│  │         Execution Environment               │   │
│  │    (Firecracker MicroVM 기반 격리 컨테이너) │   │
│  │                                              │   │
│  │  ┌────────┐  ┌────────┐  ┌───────────────┐ │   │
│  │  │Runtime │  │ Layer  │  │  /tmp (임시)  │ │   │
│  │  │(Node,  │  │(공유   │  │  스토리지     │ │   │
│  │  │Python) │  │라이브러리)│  │              │ │   │
│  │  └────────┘  └────────┘  └───────────────┘ │   │
│  └─────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘

개념	설명
함수(Function)	실행 단위. 하나의 Lambda 함수 = 하나의 특정 작업 수행 코드
이벤트(Event)	함수 실행을 유발하는 트리거. S3 업로드, HTTP 요청, SQS 메시지 등
실행 환경(Execution Environment)	Lambda 함수가 실행되는 격리된 컨테이너 (Firecracker microVM 기반)
핸들러(Handler)	이벤트를 받아 처리하는 함수의 진입점
컨텍스트(Context)	실행 시간, 메모리, 요청 ID 등 런타임 정보 객체
레이어(Layer)	여러 함수가 공유하는 라이브러리, 런타임, 종속성 패키지

2. 탄생 배경 - Serverless 패러다임의 등장

왜 만들었나

2014년 이전, 클라우드 컴퓨팅의 주류는 EC2(가상 서버)였다. 개발자는 여전히 OS 관리, 서버 용량 예측, 패치 적용 등의 인프라 부담을 안고 있었다.

AWS 내부에서 Tim Wagner를 중심으로 “개발자가 인프라 대신 코드에만 집중할 수 있는 플랫폼”에 대한 PRFAQ(내부 제안서)가 작성되었고, 이것이 Lambda의 시초가 되었다.

┌──────────────────────────────────────────────────────────┐
│              컴퓨팅 추상화 수준의 진화                     │
│                                                          │
│  물리 서버  →  VM(EC2)  →  컨테이너(ECS)  →  함수(Lambda) │
│                                                          │
│  관리 부담:  ████████     ██████        ████        ██   │
│  추상화:    █             ███           █████      ████████│
│                                                          │
│  Before Lambda: 개발자 = 코드 작성자 + 인프라 관리자      │
│  After Lambda:  개발자 = 코드 작성자만                    │
└──────────────────────────────────────────────────────────┘

연도별 주요 이정표

연도	사건
2014.11	AWS re:Invent에서 Lambda 최초 발표 (Preview). Node.js 지원
2015	Lambda GA(정식 출시). “Serverless” 용어 확산
2016	Python, Java, C# 지원 추가
2017	Lambda@Edge 출시 (CloudFront 엣지 컴퓨팅)
2018	실행 시간 제한 15분으로 확장, Go/Ruby 지원
2019	Provisioned Concurrency 출시 (Cold Start 해결)
2020	컨테이너 이미지 지원 (최대 10GB)
2021	ARM64(Graviton2) 지원
2022	Lambda Function URL 정식 출시, SnapStart 출시 (Java)
2024.11	SnapStart가 Python, .NET으로 확장
2025	Lambda Managed Instances, Durable Functions 발표
2025.08	INIT 단계 과금 시작

3. 어떻게 사용하는가

동작 방식

┌──────────┐     ┌──────────┐     ┌──────────────┐     ┌──────────┐
│  이벤트   │────▶│  트리거   │────▶│ Lambda 함수  │────▶│  결과    │
│  소스     │     │          │     │   실행       │     │  반환    │
│           │     │          │     │              │     │          │
│ S3 업로드 │     │  자동    │     │ 코드 실행    │     │ 처리완료 │
│ API 호출  │     │          │     │              │     │          │
│ SQS 메시지│     │          │     │              │     │          │
└──────────┘     └──────────┘     └──────────────┘     └──────────┘

내부적으로는 Firecracker MicroVM 위에서 격리된 실행 환경이 생성되어, 함수가 실행된 후 일정 시간 동안 재사용(warm 상태)되거나 폐기된다.

지원 언어 (2025-2026 기준)

언어	최신 지원 버전
Node.js	22.x, 24.x
Python	3.12, 3.13, 3.14
Java	8, 11, 17, 21 (Corretto)
.NET	8
Go	1.x (Custom Runtime 기반)
Ruby	3.3
Rust	Custom Runtime
기타	Custom Runtime API로 모든 언어 가능

트리거 방식

동기(Synchronous) - 즉각 응답 필요

Amazon API Gateway (REST/HTTP)
Lambda Function URL
ALB (Application Load Balancer)
Amazon Cognito

비동기(Asynchronous) - 큐에 쌓인 후 처리

Amazon S3 (파일 업로드/삭제 이벤트)
Amazon SNS
Amazon EventBridge (CloudWatch Events)

스트림/폴링(Poll-based) - 데이터 스트림 소비

Amazon SQS
Amazon Kinesis Data Streams
Amazon DynamoDB Streams
Amazon MSK (Kafka)

4. 왜 사용하는가 - 장점과 비용

주요 장점

장점	설명
인프라 관리 불필요	OS 패치, 서버 프로비저닝, 스케일링 전부 AWS 담당
자동 스케일링	요청이 늘어나면 자동으로 병렬 실행 환경 생성
사용한 만큼만 과금	실행 시간(밀리초 단위) + 요청 건수만 과금
높은 가용성	AWS가 자동으로 여러 AZ에 걸쳐 실행 보장
빠른 개발/배포	인프라 없이 코드만으로 즉시 서비스 가능
이벤트 드리븐 설계	AWS 생태계 150개 이상 서비스와 자연스럽게 통합

비용 구조 (2026년 기준)

무료 사용 한도 (Free Tier - 매월 영구 제공):

요청 수: 1,000,000건 무료
컴퓨팅: 400,000 GB-초 무료

유료 과금:

항목	요금
요청 건당	$0.20 / 1백만 건
컴퓨팅(GB-초)	$0.0000166667 / GB-초
INIT(초기화) 단계	2025년 8월부터 과금 (기존 무료)

주의: 2025년 8월부터 Cold Start의 초기화(INIT) 단계가 유료화. Java, .NET 등 무거운 런타임 사용 시 Lambda 비용 10-50% 증가 가능.

5. 어떤 때 효과적인가

Lambda가 적합한 유스케이스

유스케이스	이유
REST API / 마이크로서비스 백엔드	API Gateway 연계, 트래픽 변동 대응
이미지/동영상 처리	S3 업로드 → 자동 리사이징, 트랜스코딩
데이터 파이프라인 / ETL	Kinesis/SQS → Lambda → DynamoDB/S3
예약 작업(Cron Job)	EventBridge 스케줄러 연계
IoT 데이터 처리	센서 → IoT Core → Lambda → 저장/분석
웹훅(Webhook) 처리	GitHub, Stripe, Slack 콜백 처리
파일 변환	PDF 생성, CSV 파싱 등 단발성 처리

Lambda가 부적합한 경우

상황	이유	대안
장시간 작업 (>15분)	최대 15분 제한	ECS/Fargate, EC2
WebSocket / 실시간 스트리밍	지속 연결 불가	EC2, ECS
GPU 연산 (ML 학습)	GPU 인스턴스 미지원	EC2 GPU, SageMaker
고정적 대용량 트래픽	Provisioned Concurrency 비용 > EC2	EC2, ECS
대규모 인메모리 상태 유지	실행 환경 간 상태 공유 불가	EC2, ECS
레거시 모놀리식 앱	아키텍처 전환 비용 큼	EC2, Elastic Beanstalk

6. 기존 방식과의 차이점

Lambda vs EC2 vs ECS/Fargate 비교

항목	EC2	ECS/Fargate	Lambda
관리 수준	OS, 런타임, 앱 전부 직접 관리	컨테이너만 관리	코드만 관리
실행 단위	인스턴스(VM)	컨테이너 태스크	함수(Function)
스케일링	수동 또는 Auto Scaling	Auto Scaling (태스크 단위)	완전 자동, 이벤트 기반
최소 비용	인스턴스 시간 과금	태스크 시간 과금	요청 없으면 $0
시작 속도	수 분	수 십 초	밀리초~수 초
실행 시간 제한	없음	없음	최대 15분
상태 관리	스테이트풀 가능	스테이트풀 가능	스테이트리스
패키징	AMI 이미지	Docker 이미지	ZIP 또는 Docker
적합 워크로드	복잡한 장시간, GPU	마이크로서비스, 배치	이벤트 드리븐, 간헐적

선택 기준 플로우차트:

트래픽 예측 가능?
├─ NO → 간헐적? → YES → Lambda
│                  NO → Lambda + Provisioned Concurrency
└─ YES → 15분 초과?
         ├─ YES → 컨테이너 필요? → YES → ECS/Fargate
         │                        NO → EC2
         └─ NO → Lambda (비용 비교 후 결정)

7. Cold Start 문제

Cold Start란

Lambda 함수가 처음 실행되거나, 실행 환경이 폐기된 후 새로 실행될 때 발생하는 초기화 지연 현상.

Cold Start 흐름:
┌─────────────────────────────────────────────────────┐
│  요청 도착                                          │
│    │                                                │
│    ▼ ┌────────────────────────────────────┐         │
│      │ INIT 단계 (Cold Start 구간)       │         │
│      │  1. MicroVM 생성                  │         │
│      │  2. 런타임 초기화 (JVM 부팅 등)   │         │
│      │  3. 함수 코드 로드                │         │
│      │  4. 핸들러 외부 코드 실행         │         │
│      └────────────────────────────────────┘         │
│    │                                                │
│    ▼ ┌────────────────────────────────────┐         │
│      │ INVOKE 단계 (실제 비즈니스 로직)  │         │
│      └────────────────────────────────────┘         │
│    │                                                │
│    ▼ 응답 반환                                      │
└─────────────────────────────────────────────────────┘

Warm Start: INVOKE 단계만 실행 → Cold Start 없음

언어별 Cold Start 시간

런타임	Cold Start 시간
Go, Rust	~수십 ms (가장 빠름)
Python, Node.js	~100~500ms
.NET, Java	~1~5초 (무거운 JVM/CLR)

해결 방법

1. Lambda SnapStart (권장, 무료)

Firecracker MicroVM의 메모리/디스크 스냅샷을 미리 캐싱
함수 버전 퍼블리시 시 스냅샷 생성 → 이후 요청은 스냅샷에서 복원
Cold Start 90% 이상 감소, 일부 케이스 13-15배 빠름
지원: Java 11+, Python, .NET (2024년 11월 확장)

2. Provisioned Concurrency (유료)

지정한 수의 실행 환경을 항상 Warm 상태로 유지
Cold Start를 완전히 제거
단점: 사용 여부와 관계없이 시간당 비용 발생 (5개×1GB ≈ 월 $220)

3. 메모리 증가

128MB → 512MB 증가 시 Cold Start 30-50% 단축
CPU 성능이 메모리에 비례하기 때문

4. 패키지 크기 최소화

불필요한 라이브러리 제거, Tree Shaking
50MB → 10MB 시 Cold Start 20-40% 단축

5. VPC 최적화

과거 VPC 내 Lambda는 ENI 생성으로 수 초 추가
현재(2025) Hyperplane ENI로 VPC 오버헤드 100ms 이하

8. 제한사항

항목	한도	조정 가능
최대 실행 시간	15분(900초)	불가
메모리	128MB ~ 10,240MB	함수별 설정
임시 스토리지(/tmp)	기본 512MB, 최대 10GB	설정 가능
배포 패키지 크기	ZIP 50MB, S3 경유 250MB, 이미지 10GB	불가
환경 변수 크기	총 4KB	불가
동시 실행 수	계정당 리전별 1,000개 (기본)	증가 요청 가능
레이어	함수당 최대 5개	불가
요청 페이로드(동기)	6MB	불가
요청 페이로드(비동기)	256KB	불가
응답 페이로드	6MB (스트리밍 제외)	불가

중요: Lambda는 Stateless(무상태) 설계가 기본이다. 실행 환경이 재사용될 수 있지만 보장되지 않으므로, 상태는 DynamoDB, S3, ElastiCache 등 외부에 저장해야 한다.

9. 실제 아키텍처 패턴

패턴 1: API Gateway + Lambda (가장 일반적)

┌────────┐     ┌─────────────┐     ┌────────┐     ┌──────────┐
│ Client │────▶│ API Gateway │────▶│ Lambda │────▶│ DynamoDB │
│        │◀────│ (인증/CORS) │◀────│        │     │ / RDS    │
└────────┘     └─────────────┘     └────────┘     └──────────┘

패턴 2: Lambda Function URL (간단한 HTTP)

┌────────┐     ┌──────────────────┐
│ Client │────▶│ Lambda (자체 URL) │
│        │◀────│ API GW 불필요     │
└────────┘     └──────────────────┘

API Gateway 없이 Lambda에 직접 HTTP URL 부여. 비용 절감.

패턴 3: S3 이벤트 + Lambda (파일 처리)

┌─────────┐     ┌──────────┐     ┌────────┐     ┌───────────┐
│ Upload  │────▶│ S3 Event │────▶│ Lambda │────▶│ S3        │
│ S3/raw/ │     │          │     │ 리사이징│    │ processed/│
└─────────┘     └──────────┘     └────────┘     └───────────┘

패턴 4: SQS + Lambda (비동기 메시지 처리)

┌──────────┐     ┌─────┐     ┌────────┐     ┌──────────┐
│ Producer │────▶│ SQS │────▶│ Lambda │────▶│ DynamoDB │
│          │     │ Queue│     │        │     │ / 외부API│
└──────────┘     └─────┘     └────────┘     └──────────┘
                    │                       실패 시
                    └───────────────────▶ DLQ (Dead Letter Queue)

패턴 5: EventBridge + Lambda (Fan-out)

                              ┌──▶ Lambda A (이메일)
┌───────────┐    ┌──────────┐│
│ Service A │───▶│EventBridge├──▶ Lambda B (DB 업데이트)
└───────────┘    └──────────┘│
                              └──▶ SQS → Lambda C (리포트)

패턴 6: Step Functions + Lambda (워크플로우)

┌──────────────────────────────────────────┐
│           Step Functions                 │
│                                          │
│  Lambda A ──▶ Lambda B ──▶ Lambda C     │
│  (데이터     (결제       (이메일        │
│   검증)       처리)       발송)         │
│                                          │
│  재시도, 분기, 병렬 실행 지원           │
└──────────────────────────────────────────┘

패턴 7: Lambda@Edge (CDN 레벨 처리)

┌────────┐     ┌────────────┐     ┌──────────────┐     ┌────────┐
│ Client │────▶│ CloudFront │────▶│ Lambda@Edge  │────▶│ Origin │
│        │     │            │     │ (요청/응답    │     │        │
│        │     │            │     │  변조)       │     │        │
└────────┘     └────────────┘     └──────────────┘     └────────┘

A/B 테스트, 인증 헤더 추가, URL 리라이팅, 이미지 최적화.

10. 2025-2026 최신 동향

re:Invent 2025 주요 발표

Lambda Managed Instances (미리보기)

Lambda 함수를 EC2 인스턴스 위에서 실행하는 새로운 모드
400개 이상 EC2 인스턴스 타입 선택 가능 (GPU 포함)
멀티 동시성: 하나의 실행 환경이 여러 요청을 동시 처리 (기존 1:1 매핑 탈피)
EC2 Savings Plans, Reserved Instances 적용 가능
“EC2의 성능 + Lambda의 단순성”

Lambda Durable Functions (미리보기)

최대 1년까지 지속 가능한 장기 실행 워크플로우
외부 이벤트 대기 중에는 컴퓨팅 비용 미발생
기존 Step Functions이 필요했던 워크플로우를 Lambda 코드 내에서 직접 처리

테넌트 격리(Tenant Isolation)

SaaS 앱에서 테넌트별 별도 실행 환경에서 함수 실행
멀티테넌트 보안 아키텍처 단순화

2024-2025 기타 주요 업데이트

시기	내용
2024.11	SnapStart Python, .NET 확장
2025	Node.js 24, Python 3.14 지원
2025.08	INIT 단계 과금 시작
2026.06.30	Amazon Linux 2 EoL (마이그레이션 필요)

11. 흔한 실수와 트러블슈팅

실수 1: Cold Start 무시

특히 Java/.NET에서 API 응답 시간이 불규칙해지는 원인
해결: SnapStart 활성화 또는 Provisioned Concurrency

실수 2: /tmp 디렉토리 의존

실행 환경이 재사용될 때 이전 실행의 /tmp 파일이 남아있을 수 있음
해결: /tmp를 캐시로만 사용, 상태 저장은 S3/DynamoDB 사용

실수 3: 동시 실행 한도 미설정

Reserved Concurrency 미설정 시 하나의 함수가 전체 계정 한도를 소진 가능
해결: 중요 함수에 Reserved Concurrency 설정

실수 4: 함수 타임아웃 기본값 방치

기본 타임아웃 3초로, 외부 API 호출 시 쉽게 초과
해결: 실제 필요한 시간 + 여유분으로 설정

실수 5: Sync vs Async 호출 혼동

API Gateway 뒤의 Lambda는 동기, S3 트리거는 비동기
비동기 실패 시 자동 2회 재시도 → 멱등성(Idempotency) 보장 필수

실수 6: 패키지 크기 비대

node_modules 전체 포함 시 Cold Start 악화
해결: Tree Shaking, Lambda Layer, esbuild 번들링

m1ser4ble