데모에서 연구 에이전트가 세 개의 도구(tool)를 호출하게 만드는 것은 쉽습니다. 진짜 어려운 부분은 일곱 번째 도구 호출이 타임아웃(timeout)되고, 이미 실행된 앞선 여섯 번의 호출이 비용을 소모하고 어딘가의 상태(state)를 변경해 버렸을 때 시작됩니다.

따라서 이것은 AI 프레임워크에 관한 질문이 아니라, 복구(recovery)에 관한 질문입니다. Temporal과 Diagrid Catalyst는 모두 내구 실행 (Durable Execution)을 수행하며, 둘 다 AI 워크로드(workload)를 대상으로 포지셔닝하고 있습니다. 이 둘을 구분 짓는 것은 각 방식이 에이전트 주변에 무엇을 구축하고 운영하도록 요구하느냐입니다.

실패 계약(failure contract)부터 시작하기

당신의 에이전트가 내부 문서를 검색하고, 외부 연구 API를 호출하며, LLM에게 증거를 합성하도록 요청한 뒤, 사람이 결과를 승인할 때까지 기다린다고 가정해 봅시다. 해당 설계가 프로덕션(production)에 적용되기 전에, 다음 네 가지 질문에 대한 답이 필요합니다.

1. 충돌(crash) 발생 후 다시 실행되지 않아야 할 완료된 단계는 무엇인가?
2. 비멱등적 (non-idempotent) 도구 호출이 두 번 실행되는 것을 어떻게 방지할 것인가?
3. 에이전트가 프로세스를 열어둔 채로 유지하지 않고 몇 시간 동안 대기할 수 있는가?
4. 운영자가 에이전트가 무엇을 왜 수행했는지 재구성할 수 있는가?

Temporal은 실패하기 쉬운 작업을 액티비티 (activities)로 취급하며, 이를 내구 워크플로 (durable workflows)에 의해 조정합니다. Temporal은 워크플로 상태를 지속시키고(persist) 히스토리를 재생(replaying)함으로써 이를 재구축합니다. Temporal을 셀프 호스팅(self-host)하거나 Temporal Cloud를 사용할 수 있으며, Temporal의 현재 자료들은 에이전트 기반 애플리케이션 및 프레임워크 통합을 직접적으로 다루고 있습니다.

Catalyst는 Dapr Workflows를 기반으로 구축되었습니다. 당신의 에이전트는 내구 워크플로로 실행되며, Catalyst는 기존의 에이전트 프레임워크를 위한 러너(runners)를 제공합니다. Diagrid의 문서에 따르면, 에이전트, 워크플로, MCP 서버 및 애플리케이션 전반에 걸쳐 내구성 (durability), 워크로드 ID (workload identity), 정책 집행 (policy enforcement) 및 운영 가시성 (operational visibility)을 처리하는 공유 런타임 레이어 (shared runtime layer)를 설명합니다.

접근 방식이 갈라지는 지점

Temporal은 애플리케이션 로직을 자체의 워크플로 및 액티비티 (workflow-and-activity) 모델로 작성하기를 원할 때 적합합니다. 개념적 모델이 성숙해 있고, 언어 지원이 광범위하며, 학습할 수 있는 분산 시스템 (distributed-systems) 가이드가 방대합니다. 그 대가는 숙련도입니다. 팀원 중 누군가는 재생 (replay)에 대해 추론할 수 있을 정도로 Temporal의 실행 의미론 (execution semantics)을 충분히 이해해야 하며, 에이전트의 정체성 (identity), 액세스 정책 (access policy), 플랫폼 거버넌스 (platform governance)가 어디에 위치할지는 여전히 별도로 결정해야 합니다.

Catalyst는 에이전트가 이미 LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, OpenAI Agents 또는 다른 지원되는 프레임워크에 존재하며, 그 선택을 유지하고 싶을 때 적합합니다. Catalyst는 이러한 프레임워크를 대체하는 것이 아니라, 그 아래에서 공유 실행 및 거버넌스 레이어 (shared execution and governance layer)로 자리 잡습니다.

이러한 차이는 에이전트 팀의 수가 늘어날수록 커집니다. 단일 연구 에이전트 프로젝트라면 워크플로 SDK를 표준화하는 것으로 충분할 수 있습니다. 하지만 Python, .NET, TypeScript 에이전트를 동시에 지원하는 플랫폼 팀은 프레임워크에 구애받지 않는 (framework-agnostic) 레이어와 한 곳에서 설정할 수 있는 정책에 더 관심을 가질 것입니다.

아키텍처 리뷰에 가져갈 내용

워크플로-as-코드 (workflow-as-code)가 실제로 원하는 애플리케이션 모델이고, 해당 추상화 (abstractions)를 중심으로 구축할 의사가 있으며, 그 생태계와 운영 모델이 플랫폼 전략과 일치한다면 Temporal을 선택하십시오.

에이전트 프레임워크 선택을 유지하는 것이 중요하거나, 도구 호출 (tool calls)에 워크로드 정체성 (workload identity) 및 정책을 적용해야 하거나, 여러 배포 환경에 걸쳐 에이전트를 관리해야 한다면 Catalyst를 선택하십시오.

어떤 선택을 하더라도 멱등성 있는 부작용 (idempotent side effects)을 설계하거나 인간의 개입 시점을 결정해야 하는 과제에서 벗어날 수는 없습니다. 내구 실행 (Durable execution)은 장애 발생 후의 동작을 변화시킬 뿐, 위험한 도구 호출을 안전하게 만들어주지는 않습니다.

그다음 두 플랫폼 중 하나로 실험을 진행해 보세요. 비용이 많이 드는 모델 호출 (model call) 직후, 상태를 변경하는 도구 호출 (state-changing tool call)이 일어나기 전에 에이전트를 강제로 종료한 뒤, 무엇이 재개되는지, 무엇이 두 번 실행되는지, 그리고 어떤 흔적이 남는지 확인하십시오. 해당 동작을 개발자, 운영자, 그리고 보안 검토자에게 가장 쉽게 설명할 수 있는 플랫폼을 선택하면 됩니다.

공식 출처

• Diagrid Catalyst
• Diagrid 내구 실행 (durable execution)
• Diagrid 검증 가능한 실행 (verifiable execution)
• Diagrid AI 에이전트 (AI agents)
• Temporal