Stateful vs Stateless Agent Design은 에이전트가 대화·도구 결과·사용자 선호·작업 상태를 어디에 보관할지 정하는 아키텍처 문제다. 단순 챗봇은 stateless로 충분할 수 있지만, 장기 작업 에이전트는 상태 계층 없이는 같은 맥락을 계속 잃는다.
차이
| 설계 | 장점 | 단점 | 맞는 상황 |
|---|---|---|---|
| Stateless | 수평 확장, 장애 복구, 테스트가 쉽다 | 매 요청마다 필요한 상태를 다시 주입해야 한다 | 짧은 질의응답, 독립 요청, 저위험 API 호출 |
| Stateful | 개인화, 장기 작업, 연속 워크플로에 강하다 | 상태 오염, 동기화, 개인정보 관리가 어려워진다 | 코딩 세션, 리서치, 고객 지원, 장기 자동화 |
실전에서는 혼합한다
프로덕션 에이전트는 보통 완전 stateful도, 완전 stateless도 아니다. 런타임 호출은 stateless 함수처럼 만들고, 상태는 외부 저장소에 계층화한다.
- 최근 대화와 도구 결과는 짧은 세션 상태로 둔다.
- 사용자 선호와 반복 업무 정보는 장기 메모리로 분리한다.
- 결제, 삭제, 메일 발송 같은 위험 행동은 상태와 무관하게 명시적 승인을 요구한다.
- 오래된 상태는 요약·만료·삭제 정책을 둔다.
이 구조는 agentic-memory와 long-running-agents의 핵심 전제와 맞닿아 있다. 상태는 모델 컨텍스트 창 안에 쌓아두는 것이 아니라 검색, 요약, 권한, 감사가 가능한 외부 계층으로 관리해야 한다.
관련 문서
- agentic-memory — 에이전트 장기 기억 계층
- long-running-agents — 장기 실행 에이전트 상태 관리 패턴
- memora — 장기 작업 에이전트를 위한 추상화·구체성 균형 메모리
- durable-objects — 에이전트별 상태를 서버리스에서 오래 유지하는 Cloudflare 액터 런타임
참고 자료
- Stateful vs. Stateless Agent Design — Machine Learning Mastery (2026-07-27)