안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Building the future with AWS Serverless]을 확인해보시기 바랍니다.

Building the future with AWS Serverless

AWS Lambda의 신기능인 Durable Functions와 서버리스 개발·운영 경험을 혁신하는 최신 AI·개발 도구 및 보안 기능을 소개합니다.

1. Building the future with AWS Serverless 

1-1. 서버리스의 변곡점 인식

• Lambda는 작년에 10주년을 맞이했지만, 현재 변곡점(inflection point)에 도달했습니다.
• 이는 2000년대 초반 인터넷이 그랬던 것처럼 기술 전반에서 나타나는 변화의 시점입니다.
• AI가 기술 발전을 가속화하고 있으며, 이는 이미 개발 속도를 높이고 있습니다.

1-2. 변화의 상수와 기존 전략의 한계

• PJ가 언급한 “모든 변화는 나쁜 변화이다(All change is bad change)”라는 인용구를 통해 변화의 중요성을 강조합니다.
• 고객들과의 대화를 통해 기존 플랫폼 전략이나 구식 방식이 더 이상 효과적으로 작동하지 않음을 확인합니다.
• 엔지니어들은 새로운 것을 시도하고 싶어 하지만, 기존 엔지니어링 팀과 플랫폼 팀 간의 충돌이 심화되고 있습니다.
• 실제 프로덕션 엔지니어링에서 시도 비용이 급감하였으며, AI를 가속화 도구로 활용하여 개발 속도를 높이고 있습니다.
• 배포, 운영, 패치 작업이 방해 요소로 작용할 경우, SDLC(소프트웨어 개발 수명 주기) 전체가 역전될 수 있습니다.
• 많은 고객들이 쿠버네티스 기반 플랫폼을 사용해왔지만, 서버리스를 통해 더 빠른 개발을 원하며 코드 관리의 부담을 줄이고자 합니다.

1-3. 진화적 아키텍처와 트레이드오프

• 현재는 진화의 시기(evolutionary time)이며, 시스템·프로세스·사람이 함께 진화할 수 있는 조직이 성공합니다.
• 서버리스 전략의 핵심 기둥은 개발자 경험과 진화적 아키텍처(evolutionary architectures)의 구축에 초점을 둡니다.
• 완벽한 아키텍처란 존재하지 않으며, 올바른 트레이드오프만 존재합니다.
• 고도로 진화적인 시스템은 변화 관리가 어렵고 디커플링되어 있어 문제 관찰이 쉽지 않습니다.
• 플랫폼 팀 소유자는 개발 속도 향상 요구와 통제, 거버넌스, 규정 준수 사이에서 균형을 맞추는 트레이드오프에 직면합니다.

1-4. 속도의 중요성

• 기술 분야에서 진화는 새로운 개념이 아니며, 속도(speed)는 언제나 비즈니스 성공의 핵심 요소였습니다. 빠를수록 승리할 가능성이 높습니다.

2. AI 기반 CRUD API 구축 및 배포

2-1. Phase 1: 기반 구축 (CRUD API) 

• 기반 구축(Foundation) 단계로 CRUD API를 구축합니다.
• AI 코딩 지원(vibe coding)과 서버리스 MCP 서버를 활용합니다.
• MCP 서버는 선호하는 AI 코딩 도우미가 자연어 프롬프트를 잘 설계된(well-architected) 코드로 변환하도록 지원합니다.

2-2. Phase 1 세부 단계 및 기술 스택 

• 1단계: MCP 서버를 설치합니다.
• 2단계: CRUD API 코드를 작성합니다.
• 3단계: 빌드 및 배포를 진행합니다.

2-3. AI 코딩 지원 및 코드 생성 결과

• 프롬프트를 입력하면 AI 비서(Ko)가 5~10초 만에 코드 파일을 생성하고, 이후 진행할 단계(빌드 및 배포)를 안내합니다.
• MCP 서버 사용 시, 기존에는 포함되지 않았던 자동 오류 처리, DynamoDB 쓰기 시 3회 재시도, 전역 오류 핸들러, 일관된 HTTP 상태 코드, 구조화된 로깅 등이 자동으로 내장됩니다.

2-4. 빌드 및 배포 과정 (SAM 활용) 

• 배포 명령을 비서에게 전달하면 SAM이 YAML, TSConfig, Package 파일을 기반으로 배포를 실행합니다.
• SAM은 배포 과정에서 모범 사례를 강제하며, 변경 세트(change set)를 통해 CloudFormation의 배포 차이(delta)를 표시합니다.
• 배포 완료 후 콘솔에서 5개의 함수가 활성화된 것을 확인합니다.
• 또한 SAM은 API에 인증(authentication)이 없음을 감지하고 사용자에게 확인을 요청합니다.

2-5. GenAI의 역할 

• 약 5~7분 만에 자연어만으로 Well-Architected 프레임워크가 내장된 완전한 백엔드 및 CRUD API를 배포합니다.
• 생성형 AI는 코드 생성 속도는 높이지만, 기존에는 코드 검토나 IaC 등 배포 사이클 전반을 가속화하지 못하는 한계가 존재했습니다.
• 서버리스는 이 전 과정을 혁신하며 코드 생성 시 모범 사례를 강제하도록 개선합니다.
• MCP 서버를 활용하면 개발자의 생산성이 크게 높아지고, 일관된 품질의 코드가 생성되어 코드 리뷰 과정에서 발생하는 문제를 최소화합니다.

3. 트래픽 급증 처리 및 확장성 시연

3-1. 급증 트래픽 시나리오

• 애플리케이션이 뉴스 매체에 소개되어 동시성 트래픽이 급증하는 상황을 가정합니다.
• 기존 방식은 피크 트래픽에 맞춰 오버 프로비저닝하는 방식이었으며, 이는 비용 증가와 지속적인 수동 최적화 및 유지보수를 초래합니다.

3-2. 서버리스의 핸즈프리 확장 옵션

• 서버리스는 핸즈프리(hands-free) 확장 옵션을 제공하며, 확장 속도는 모든 컴퓨팅 선택지 중 가장 빠릅니다.
• 10초마다 1,000개의 실행 환경을 제공할 수 있습니다.
• 함수 실행 시간이 100ms라면, 이는 10초마다 10,000 RPS를 즉시 처리할 수 있음을 의미합니다.
• 시연 결과, 약 25~30초 만에 트래픽이 700~800배 증가했음에도 단 하나의 오류나 스로틀링 없이 Lambda가 이를 흡수합니다.
• 이 모든 과정을 유휴 비용(idle costs) 없이 달성합니다.

3-3. 니들 포인트 트래픽 및 테스트 용이성

• 이러한 트래픽 패턴을 니들 포인트 트래픽(needle point traffic)이라고 부릅니다. (예: 경기 중 QR 코드 스캔, 플래시 세일)
• 테스트가 간단한 이유는 확장성 자체를 테스트할 필요 없이 애플리케이션 로직만 검증하면 되기 때문입니다.
• 구축된 4~5개의 API는 서로 독립적으로 동일한 속도로 확장되며, 노이즈 이웃 문제(noisy neighbor problem)가 제거됩니다.

3-4. 빌드 및 배포 과정 (SAM 활용) 

• 배포 명령을 비서에게 전달하면 SAM이 YAML, TSConfig, Package 파일을 기반으로 배포를 실행합니다.
• SAM은 배포 과정에서 모범 사례를 강제하며, 변경 세트(change set)를 통해 CloudFormation의 배포 차이(delta)를 표시합니다.
• 배포 완료 후 콘솔에서 5개의 함수가 활성화된 것을 확인합니다.
• 또한 SAM은 API에 인증(authentication)이 없음을 감지하고 사용자에게 확인을 요청합니다.

4. Lambda Managed Instances (LMI)

4-1. Lambda Managed Instances (LMI) 소개

• LMI는 Lambda의 단순한 개발자 경험과 통합을 EC2의 유연성(인스턴스 유형, 메모리, 네트워크 선택 등)과 결합하는 것을 목표로 합니다.
• LMI를 통해 Graviton 4와 같은 최신 인스턴스 패밀리 및 최신 세대 인스턴스를 사용할 수 있습니다.
• 모든 요소는 완전 관리형으로 제공되며, AWS가 스케일링, 패치, 요청 라우팅을 계속 담당합니다.
• 멀티 동시성(Multi-concurrency) 기능이 추가되어 하나의 실행 환경에서 여러 요청을 동시에 처리할 수 있습니다.
• EC2 Savings Plans 및 Reserved Instances와 결합하면 비용 최적화 효과가 극대화됩니다.

4-2. LMI 설정 및 개발자 경험

• LMI 사용은 용량 공급자(capacity provider)를 생성하는 것만큼 간단합니다.
• 용량 공급자 생성 시 인스턴스 유형, 확장 정책(최대/최소) 등을 선택적으로 지정할 수 있으며, 지정하지 않으면 Lambda가 자동으로 관리합니다.
• 함수 생성 단계에서 용량 공급자를 구성하면, Lambda가 인스턴스를 프로비저닝하고 워크로드 활용도(utilization)를 지속적으로 최적화합니다.
• 용량 공급자 생성 시 VPC 서브넷, 보안 그룹, 그리고 EC2 조작 권한을 가진 역할(operator role)을 지정합니다.
• 고급 설정에서는 아키텍처(Graviton/x86), 포함하거나 제외할 인스턴스 유형, 확장 정책(Max/Min)을 세부적으로 설정할 수 있습니다.
• 용량 공급자 생성 자체에는 비용이 발생하지 않으며, EC2 인스턴스는 함수가 활성화될 때 시작됩니다.
• 함수 생성 흐름은 기존 Lambda와 동일하며, 용량 공급자 구성 파라미터만 추가됩니다.
• 메모리와 CPU 비율을 사용자 지정할 수 있어, 컴퓨팅 집약적 또는 메모리 집약적 워크로드도 지원할 수 있습니다.
• 시연에서는 메모리 4GB, 멀티 동시성 64 요청, 메모리 대 vCPU 비율 4:1로 설정을 변경합니다.
• 설정을 저장하고 용량 공급자로 돌아가면, 함수가 활성화됨과 동시에 EC2 인스턴스가 생성되며, 이 인스턴스들은 3개 AZ에 걸쳐 균형 있게 분산됩니다.

4-3. LMI 성능 및 비용 최적화 결과

• 부하 테스트 시연: 트래픽이 꾸준히 증가하는 steady state 패턴에서 테스트를 진행합니다.
• 확장이 발생하여 인스턴스 수가 3개에서 7개로 증가하였으며, 활용도는 약 25%를 달성합니다.
• 약 1시간 후 932건의 스로틀이 발생했으나 오류율은 0%를 유지했으며, 인스턴스 수는 21개까지 확장됩니다.
• CPU 활용률 약 25%를 기준으로 스케일 업·다운이 모두 자동으로 트리거되었습니다.
• 비용 최적화 결과: 기존 피크 프로비저닝 방식에서는 6% 활용도 기준 비용이 $85였으나, 9% 활용도로 개선 시 비용이 $5.67로 감소합니다. LMI에서는 자동 확장 기능이 기본 제공되어 처음부터 약 25% 활용도를 달성하며, EC2 비용은 $2.05에 불과합니다.
• LMI는 EC2 인스턴스당 약 15%의 관리 수수료를 부과합니다.
• 이 수수료에는 자동 확장, 프로비저닝, 패치, 지속적 최적화가 포함되어 있으며, 재아키텍처링이 필요 없어 시간 절약 효과가 큽니다.
• 핵심 요약: LMI는 Lambda의 단순성과 EC2의 유연성을 결합하며, 지속적인 활용도 최적화를 통해 비용 효율을 제공하고, 인프라 관리 부담을 완전히 제거합니다.
• CPU 대 메모리 비율 구성 기능으로 인해 기존 서버리스에서 실행하기 어려웠던 새로운 워크로드도 지원할 수 있습니다.

5. AWS Lambda Durable Functions

5-1. Lambda Durable Functions 소개

• Lambda Durable Functions는 신뢰성이 내장된(reliability is baked in) 간단한 순차적 코드를 작성하는 방식으로 동작합니다.
• 현재 Node와 Python을 지원하며, 더 많은 언어가 곧 지원될 예정입니다.
• 장기 실행 작업을 일시 중지하고 재개할 수 있으며, 일시 중지 시 Lambda 비용이 전혀 발생하지 않습니다.
• 이는 Step Functions와 같은 워크플로우 기술이 아니라, 워크플로우 기능이 내장된 컴퓨팅 서비스(Lambda)입니다.

5-2. Durable Functions의 작동 방식 및 특징

• Durable Functions는 간단한 SDK를 사용하며, Lambda 콘솔에서 Durable Functions를 선택하면 런타임에 SDK가 로드됩니다.
• 체크포인트(checkpoint) 시점은 개발자가 직접 결정하며, 이는 Step Functions와 동일한 기반 시스템 위에서 구축됩니다.
• 재실행(replay) 시 이미 체크포인트된 이전 단계는 다시 실행하지 않고 결과만 받아와 컴퓨팅 낭비를 방지합니다.
• LMI와 마찬가지로 장기 실행 워크로드 지원을 위해 Step Functions 팀과 협력하여 기능을 공동 구축합니다.
• 내구성 있는 실행(Durable execution)은 함수 이름과 함께 선택적 내구성 구성(durable configuration)을 제공하여 활성화합니다.

5-3. Durable Functions 시연 및 코드 분석

• 콘솔에 ‘Durable Executions’ 탭이 새롭게 추가되며, Step Functions와 유사한 워크플로우 관측성을 제공합니다.
• 시연에서는 워크플로우가 시작된 후 노트 페치, LLM 전송, 요약 처리 단계를 거치는 진행 상황을 실시간으로 확인할 수 있습니다.
• 워크플로우는 최대 1년까지 실행될 수 있으며, 인간 개입(human-in-the-loop) 시스템 구축에도 사용할 수 있습니다.
• 코드 분석
  - 일반 Lambda의 context 객체 대신 durable context 객체를 받습니다.
  - durable context에는 대기(waiting) 또는 체크포인트 기능과 구조화된 로깅이 포함됩니다.
  - DynamoDB 호출과 같은 단계는 durable context에서 제공하는 명령을 사용해 작성합니다.
  - 멱등성(idempotency): Durable Context의 이름(ID)을 통해 동일한 유형의 워크플로우가 중복 시작되는 것을 방지하여 트랜잭션 일관성을 유지합니다.
  - 대기(Wait): context.wait() 호출 시 실행 환경이 종료되어 비용이 발생하지 않습니다.
  - 대기 완료 후 콜백 또는 조건부 콜백을 통해 실행 환경이 다시 깨어나며, 정확히 대기했던 지점부터 재개합니다.
  - 이러한 방식은 큐나 분산 컴퓨팅을 사용하는 기존 이벤트 기반 아키텍처에서 발생하는 배포, 디버깅, 재수화 등의 복잡성을 크게 단순화합니다.

6. 향후 전략

6-1. AI 개발 도구 및 기존 혁신 요약

• MCP 서버를 통한 GenAI 개발 지원을 제공합니다.
• VS Code용 AWS 툴킷을 통해 Lambda 함수의 원격 디버깅 및 중단점 설정이 가능해지면서 개발자 경험이 개선되고 있습니다.
• LMI는 상태 유지 대규모 워크로드에 대해 EC2 인스턴스 선택의 유연성과 비용 할인을 제공합니다.
• Durable Functions는 장기 실행 워크로드에 대한 신뢰성과 내구성을 제공합니다.

6-2. 테넌트 격리(Tenant Isolation) 기능

• 보안에 민감한 SaaS 애플리케이션을 위해 테넌트 격리 기능을 출시했습니다. (re:Invent 일주일 전)
• 시나리오: 세 개의 테넌트(파랑, 노랑, 초록)가 동일한 Lambda 함수를 사용할 때, 글로벌 변수나 임시 저장소에 남겨진 사이드 이펙트가 다른 테넌트에 영향을 줄 수 있습니다.
• 전통적으로는 테넌트별로 개별 인프라(또는 Lambda 함수)를 생성해야 했습니다.
• 테넌트 격리 기능은 동일한 Lambda 함수를 사용하되, 호출 시 테넌트 ID를 전달하면 AWS가 테넌트별로 공유되지 않는 개별 실행 환경을 생성하여 격리합니다.
• 이를 통해 추가 인프라나 별도 Lambda 함수 관리 없이 민감한 소프트웨어의 격리를 실현할 수 있습니다.

6-3. 서버리스 전략의 최종 요약 및 로드맵

• 서버리스 전략의 핵심은 개발자 중심과 속도이며, 플랫폼 팀의 비용 관련 이의 제기, IaC의 어려움 등 기존의 장애물을 제거하는 데 집중하고 있습니다.
• 개발자 경험(DX)에 중점을 두어 서버리스 개발자가 아니더라도 혜택을 누릴 수 있도록 지원합니다.
• 로드맵 초점: 개발자 경험 개선, 관측성(Observability) 강화(네이티브 OpenTelemetry 지원), 더 많은 런타임 지원(Rust 지원 최근 출시)입니다.
• LMI와 Durable Functions를 통해 기존에는 불가능했던 새로운 클래스의 애플리케이션을 지원합니다.
• 통합(Integrations)은 Lambda 속도의 근간이며, EventBridge, SNS, API Gateway 등과의 내장 통합을 계속 강화할 것입니다.