r/langchain•2개월 전•15•9
Temporal을 장기 실행 AI 에이전트의 런타임으로 성공적으로 사용해 본 분 계신가요?
Has anyone successfully used Temporal as the runtime for long-running AI agents?
핵심 요약
Temporal을 AI 에이전트 런타임으로 활용할 때의 아키텍처적 한계와 대안에 대한 논의입니다.
- Temporal 활용 — 워크플로우 내구성을 위해 Temporal을 도입했으나 에이전트 런타임 모델과의 괴리를 경험함
- 아키텍처 고민 — 리플레이 처리, 세션 상태 유지, 스트리밍, 정책 관리 등 에이전트 특유의 문제 해결이 어려움
- 운영 방식 — 에이전트 로직을 Temporal 내부에 두기보다 외부 런타임으로 분리하는 방식이 선호됨
- 경험 공유 — 오케스트레이터로서의 Temporal과 별도의 에이전트 런타임 계층을 분리하는 것이 복잡성 해결의 핵심임
우리는 장기 실행 AI 에이전트의 내구성 계층으로 Temporal을 사용하는 실험을 해왔는데, 복합적인 감정이 들었음.
결정론적 워크플로우(결제, 주문 처리, 백그라운드 작업)의 경우, 아주 훌륭한 선택처럼 느껴짐.
하지만 자율형 에이전트의 경우, 다음과 같은 아키텍처적 의문들에 계속 부딪혔음:
- 다음 LLM 호출이 합법적으로 다른 도구를 선택할 수 있을 때 리플레이를 어떻게 처리할 것인가?
- 워커가 이동하면 장기 실행되는 로컬 세션 상태는 어떻게 할 것인가?
- 워크플로우 기록을 엉망으로 만들지 않으면서 스트리밍을 어떻게 처리할 것인가?
- 런타임 정책(도구 제한, 완료 확인, 루프 감지)은 실제로 어디에 위치해야 하는가?
- 에이전트 루프를 단일 불투명 Activity로 취급할 것인가, 아니면 모든 도구 호출을 노출할 것인가?
실험을 거듭할수록 Temporal은 워크플로우 내구성을 해결하고 있지만, 에이전트 자체는 다른 런타임 모델이 필요하다는 느낌을 받았음.
혹시 여기서 Temporal 위에서 프로덕션 에이전트를 돌리고 있는 사람이 있는지 궁금함.
- 어떤 아키텍처로 최종 결론을 내렸나?
- 어떤 문제들에 부딪혔나?
- 에이전트를 Temporal 내부에 유지했나, 아니면 외부 런타임으로 취급했나?
참고로 우리는 Claude Agents와 Temporal을 실험하면서 발견한 아키텍처적 트레이드오프를 문서화해 두었지만, 우리의 결론이 보편적이라고 가정하기 전에 다른 사람들은 어떻게 접근했는지 더 들어보고 싶음.
