Temporal 다중 AI 프레임워크 통합 정식 제공… 스트리밍 기능은 미리보기

Temporal은 10월 30일 여러 AI 라이브러리와 에이전트 프레임워크용 통합 기능을 정식 제공한다고 발표했다. 이 사이트의 발행일은 11월 1일이지만 원 발표일은 10월 30일이다. 정식 제공이라는 말은 목록에 적힌 통합 패키지에 적용된다. 토큰 전송을 위한 Workflow Streams는 Python과 TypeScript에서 별도로 공개 미리보기라고 표시돼 있어 같은 단계로 취급할 수 없다.

지원 범위는 언어별로 다르다. Google ADK는 Python, Go, TypeScript이며 OpenAI Agents SDK는 Python과 TypeScript이고 Python판은 이미 정식 제공 중이었다. AWS Strands는 Python과 TypeScript, LangGraph는 Python, LangSmith는 Python과 TypeScript, Vercel AI SDK는 TypeScript, Gemini SDK는 Python이다. 팀은 실제 사용하는 언어의 패키지와 문서를 확인해야 한다. ‘AI 프레임워크 지원’이라는 문구가 모든 프레임워크와 언어의 조합을 보장하지 않는다.

설계의 중심은 오래 지속되는 조정 로직인 Workflow와 외부 작업인 Activity의 분리다. 모델 호출, API 요청, 데이터베이스 접근 같은 부작용은 Activity가 수행한다. 통합 패키지는 각 프레임워크의 동작을 이 경계에 맞춘다. Google ADK의 Python 예시에서는 일반 모델 이름 대신 `TemporalModel`을 사용해 매 모델 호출을 Activity로 만들고, Client와 Worker에 `GoogleAdkPlugin`을 등록한다. 다른 프레임워크에는 다른 연결 지점이 있으므로 ADK 예시를 모든 패키지의 설치법으로 사용할 수 없다.

복구는 Event History에 저장된 진행 상황에 달려 있다. Worker가 다시 시작되거나 배포 중 실행이 끊기면 Temporal은 기록으로 Workflow를 재구성한다. 재생 과정에서 이미 끝난 Activity의 결과를 다시 사용하며 같은 모델이나 도구 요청을 재전송하지 않는다. 비용이 들거나 외부 상태를 바꾸는 호출에 중요한 성질이다. 다만 부작용을 실제로 Activity 안에 둬야 한다. 패키지만 가져오고 재생되는 조정 코드에서 외부 API를 직접 부르면 같은 보장을 얻지 못한다.

재시도 책임도 정리해야 한다. Temporal 설명에 따르면 통합 기능은 프레임워크 자체의 재시도 루프를 끄거나 끄도록 요구해 Temporal이 재시도와 시간 제한을 한곳에서 관리하도록 한다. 두 규칙이 겹치면 호출 횟수가 늘어나고 장애 분석이 어려워진다. 클라이언트와 자격 정보는 Worker에 남겨 Workflow 기록에 넣지 않는다. 추적 문맥은 프로세스를 넘어 전달하되 재생할 때 같은 span을 중복 전송하지 않도록 한다.

에이전트는 사람의 승인이나 외부 입력을 기다리는 동안 계속 폴링하거나 Worker 프로세스를 붙잡아 둘 필요가 없다. 지원되는 경우 Workflow Streams로 토큰을 전송할 수 있지만 이 부분은 공개 미리보기다. 기존 Workflow를 업그레이드할 때는 릴리스 노트에서 패키지와 import의 변경, Worker Versioning 필요 여부를 확인해야 한다. 오래 실행 중인 작업을 새 버전으로 무조건 옮기는 판단은 위험할 수 있다.

도입 전에는 해당 언어 패키지의 예시를 실행하고 Worker를 의도적으로 중단한 뒤 복구하며 Event History와 외부 API 기록에서 중복 호출이 없는지 살펴야 한다. 이 기사는 복구 성공률을 측정하지 않았다. 확인된 것은 Temporal이 이름을 밝힌 통합들의 정식 제공과 Workflow/Activity 실행 모델을 발표했다는 사실이다. 실제 운영 품질은 선택한 조합과 경계 설계로 검증해야 한다.

재실행의 안전성은 부작용의 위치에 달려 있다. 모델 호출, 외부 API 요청, 데이터 저장을 Workflow 본문에서 직접 수행하면 복구 과정에서 같은 작업이 다시 발생할 수 있다. 해당 작업을 Activity로 분리하고 기록된 결과를 재사용하는 경로를 실제 중단 시험으로 확인해야 한다. 프레임워크 내부의 재시도와 Temporal 재시도가 겹치지 않는지, 외부 작업에 멱등성 키가 필요한지도 점검한다. 이미 실행 중인 Workflow를 바꿀 때에는 버전 관리와 릴리스 문서의 호환성 주의를 먼저 읽는다.

중단이 모델 제공자의 응답 직후에 일어났지만 Activity 완료 기록 전에 발생한 경우처럼 경계가 애매한 상황도 시험해야 한다. 재시도 횟수, 요청 식별자, 외부 저장 상태를 함께 남기면 중복 호출 여부를 확인할 수 있다. 최종 답변만 비교하면 추가 비용이나 반복된 도구 작업을 놓칠 수 있다.