[reinvent 2025] [신규 출시] AWS Lambda Durable Functions 심층 분석
Summary
Durable Lambda의 프로그래밍 모델을 확장하여, JavaScript, TypeScript, Python과 같은 익숙한 언어 패턴으로 내결함(fault-tolerant) 애플리케이션을 쉽게 구축할 수 있도록 지원합니다. 이번 세션에서는 내장된 재시도 메커니즘을 통해 실패 처리를 간소화하고, 인간 참여가 필요한 처리(human-in-the-loop)를 효율적으로 관리하며, 진행 상태를 추적할 수 있는 상태 관리(state management) 기능 등 새로운 기능들을 살펴봅니다.
리인벤트 2025 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
아키텍처의 진화
초기 모놀리식 아키텍처는 개발이 편리했지만 결합도가 높아 확장이 어려웠습니다. 이후 마이크로서비스가 등장하면서 느슨한 결합과 독립적 개발이 가능해졌지만, 복잡성과 실패 처리 문제, 인지적 부담이 생겼습니다.
Serverless 역사
AWS는 대규모 애플리케이션 운영 경험을 바탕으로 개발자가 서버리스 환경에서 쉽게 애플리케이션을 구축할 수 있도록 Serverless를 도입했습니다. 그 시작은 AWS Lambda로, 처음으로 순수 컴퓨팅 서비스 기반의 Serverless 개념을 대규모로 소개했습니다. Lambda는 기본적으로 실행 시간이 짧고, 상태를 유지하지 않는다는 특징이 있습니다. 이는 큰 장점인 동시에, 복잡한 비즈니스 로직을 구현할 때는 별도의 상태 관리나 오케스트레이션이 필요하다는 과제를 안겨주었습니다. 이를 해결하기 위해 Step Functions(2016)와 Amazon EventBridge(2019)가 등장하여 복잡한 워크플로우와 서비스 간 상호작용을 쉽게 관리하고, 결합도를 낮춘 유연한 아키텍처를 구현할 수 있게 되었습니다.
그럼에도 개발자들은 Lambda 기반 환경에서 더 복잡한 로직을 안정적이며 친숙한 프로그래밍 모델로 개발하기를 원했습니다. 이를 위해 모놀리스처럼 작성하되, 실행은 마이크로서비스처럼 분리되는 형태가 요구되기 시작했습니다.
Durable Functions의 등장
이러한 요구들을 해결하기 위해 Lambda의 단점을 보완한 Durable Function이 등장했습니다. Durable Function은 Lambda 기반 애플리케이션에서 실행 상태를 자동으로 저장하고(checkpoint), 장애나 중단 발생 시 재실행(replay)을 통해 이전 진행 상황부터 이어서 실행할 수 있도록 해주는 신뢰성 높은 장기 실행 모델입니다.
Checkpoint는 현재 진행 상태를 저장하고 중단 지점을 생성하는 기능입니다. 이를 활용하면 장애가 발생하더라도 동일 지점에서 다시 이어서 수행할 수 있습니다.
Replay는 실행 중단 시 저장된 체크포인트를 기반으로 완료된 작업은 건너뛰고, 미완료 작업만 다시 실행하여 효율적으로 복구하는 기능입니다.
SDK는 개발자가 기존 Lambda 코드 작성 방식 그대로 Durable Function의 기능을 활용할 수 있게 해주는 요소입니다. step, wait과 같은 내구성 있는 연산을 제공하며, 코드 내의 모든 await는 자동으로 일시 정지 가능한 지점이 되어 체크포인트로 저장됩니다. 별도의 오케스트레이션 코드를 작성하지 않아도 익숙한 프로그래밍 패턴 안에서 Lambda가 실행을 멈추고, 상태를 저장하고, 필요할 때 다시 실행하는 주는 구조를 사용할 수 있습니다.
Monitoring
Durable Function은 Replay 중 중복 로그가 쌓이지 않도록 자동 필터링합니다.
Best Practice
1. 간단하게 시작하기
KISS: Keep It Simple, Stupid 원칙을 그대로 적용하는 것이 좋습니다. 작은 Step들로 구성된 간단한 흐름부터 시작해 Durable Execution의 동작(중단, 체크포인트, Replay)에 익숙해진 다음 확장하는 방식이 안정적입니다.
2. SDK를 번들링하여 배포하기
Durable Function에서 제공하는 Step, Wait 등 핵심 기능은 SDK를 통해 사용할 수 있습니다.
Lambda를 배포할 때 SDK가 번들링되어 있어야 로직이 정상 작동하기 때문에, 사용 중인 빌드 도구(webpack, esbuild, Parcel 등)나 패키지 매니저(NPM/Yarn/PNPM)를 활용해
SDK가 빌드 결과물에 반드시 포함되도록 구성해야 합니다.
3. LLM 기반 에이전트는 사전 준비가 필요
LLM 기반 Agentic AI를 Durable Function으로 실행할 경우, 시스템 프롬프트, 초기 상태 메타데이터, 모델 설정(temperature, context 등) 등 초기값이 매 실행마다 동일하도록 priming을 준비해야 합니다.
4. 함수 타임아웃과 Durable Execution 타임아웃 정렬
Durable Function은 최대 1년 동안 실행될 수 있는 반면, Lambda 함수의 단일 실행 시간은 최대 15분입니다. Lambda 타임아웃, Durable Execution 전체 타임아웃, Step 내부 wait 시간 등을 함께 고려해 설정해야 불필요한 재실행이나 중단을 방지할 수 있습니다.
5. 비결정론적 코드는 Step 안에서만 실행
Durable Execution은 재실행될 수 있으므로 매번 결과가 달라지는 연산(UUID, 현재 시각, 외부 API 호출 등) 을 함수 본문에 직접 작성하면 안 됩니다. 이런 작업은 반드시 Context.step() 안에서 실행해야 하며, 최초 실행 시의 결과가 체크포인트로 저장되므로 Replay 시 일관성을 유지할 수 있습니다.
6. Replay-aware Logger 사용
Replay 과정에서 불필요한 로그가 쌓이지 않도록 Replay-aware Logger를 사용하면 실제 실행 흐름과 재생 흐름이 분리되어 디버깅이 쉬워집니다.
7. SDK의 동시성 기능 활용
Durable Function SDK는 Replay 환경에서도 안전하게 동작하도록 설계된 동시성 primitive를 제공합니다. 일반 비동기/병렬 코드와 달리, Durable Execution에서는 Replay가 발생할 수 있으므로 SDK가 제공하는 동시성 기능을 사용하는 것이 안정성과 일관성 측면에서 필수입니다.
8. 대용량 페이로드와 암호화를 위한 (De)serializer 활용
Durable Function은 체크포인트 데이터를 저장해야 하기 때문에 대용량 페이로드나 민감 정보 처리 시 전용 serializer/deserializer 기능을 활용하여 데이터 크기와 암호화 정책을 관리하는 것이 좋습니다.
Pricing
Durable Execution의 과금 체계는 크게 세 가지 차원으로 구성됩니다. 실행 단계마다 체크포인트를 남기고, 상태를 저장하며, 오래된 데이터를 유지하는 특성 때문에 각각의 리소스 사용량에 따라 비용이 부과됩니다. 람다 자체 비용(요청 수)도 동일하게 적용됩니다.
Step Functions VS Lambda durable functions
인프라 관리 없이 다양한 AWS 서비스 전반에 걸쳐 오케스트레이션이 필요할 때 Step Functions가 유리하고, 코드 중심의 개발 환경에서 애플리케이션 내부 로직을 상세하게 제어할 때 Lambda Durable Functions가 유리합니다.
이러한 차이점은 각 서비스가 해결하고자 하는 문제의 영역이 다름을 의미합니다. 따라서 기술적 우위를 따지기보다는,구현하려는 워크플로의 복잡도, 팀의 선호도 및 숙련도를 종합적으로 고려하여 최적의 서비스를 채택하는 전략적 접근이 필요합니다.
