인간은 비동기 API다 — Temporal로 만드는 내구성 있는 Human-in-the-Loop 에이전트

URL: https://www.youtube.com/watch?v=jc3kbZkuHTo
날짜: 2026-10-05
채널: aiDotEngineer
원문 제목: The Human Is an Async API — Melanie Warrick, Temporal

메타데이터

• 발표자: Melanie Warrick, Temporal Developer Relations
• 영상 길이: 1,156초(약 19분 16초)
• 주제: Temporal을 이용한 내구성 있는 Human-in-the-Loop 에이전트와 다중 에이전트 오케스트레이션
• 핵심 프레임워크: Google ADK, LangGraph, Temporal
• 처리일: 2026-10-05 (Asia/Seoul)
• 자막: 영어 자동 생성 자막을 바탕으로 한국어로 정리

---

📌 핵심 질문 / 인간의 응답을 기다리는 에이전트를 어떻게 망가지지 않게 만들 것인가

==인간은 200밀리초 안에 응답하는 함수가 아니라 수분·수일·수주가 걸릴 수 있는 비동기 API이므로, 사람을 기다리는 상태를 프로세스 메모리가 아니라 내구성 있는 워크플로 상태로 보존해야 한다.==

• 에이전트의 reason → act → observe 루프에 사람의 판단이 들어오면 일반적인 함수 호출은 blocking call이 될 수 있다.
• 서비스가 재배포되거나 중단되면 메모리에만 있던 질문·대기 상태·이전 작업 결과를 잃고 작업을 중복 실행하거나 누락할 수 있다.
• Temporal의 Workflow, Activity, Worker와 wait condition, Signal은 사람을 기다리는 동안 스레드를 붙잡지 않고 상태를 보존하며, 서비스가 복구된 뒤 정확히 다음 단계부터 재개하게 한다.

Melanie Warrick은 Ziggy의 아이스크림 배달이라는 다중 에이전트 예제로 사람에서 에이전트로 전달되는 주문 변경과 에이전트에서 사람으로 올라오는 고가 주문 승인이라는 두 방향의 Human-in-the-Loop를 설명한다. Google ADK와 LangGraph가 에이전트 루프를 소유하고 Temporal이 그 아래에서 상태·재시도·대기·복구를 담당하면, 사람의 느리고 불확실한 응답도 분산 시스템의 정상적인 비동기 사건으로 다룰 수 있다.

1. Ziggy의 아이스크림 배달과 첫 번째 Human-in-the-Loop 흐름

Ziggy의 가상 아이스크림 가게와 배달 차량이 Google ADK 및 Temporal 위에서 움직이고, Temporal UI가 전체 사건 이력을 보여준다.

1.1. 가상의 가게와 세 에이전트

1. Ziggy의 배달 세계

   1. 가게와 캐릭터: Ziggy는 Temporal의 마스코트이며, 실제로 가게를 운영하는 것은 아니지만 샌프란시스코 Ferry Building에 아이스크림 가게가 있다고 가정한다.
   2. 배달 상황: 화면에는 여러 배달이 동시에 진행되고, 아이스크림이 각 주문의 목적지로 이동한다.
   3. 세 역할: Fleet Agent는 차량·운전기사 쪽을, Customer Agent는 주문 쪽을, Dispatch Agent는 두 에이전트가 조사한 결과를 바탕으로 배차 결정을 담당한다.

2. Google ADK와 Temporal의 결합

   1. Google ADK: Google이 제공하는 에이전트 오케스트레이션 솔루션으로, 여러 에이전트의 활동을 조정한다. 자막의 “80K”는 문맥상 Google ADK를 가리킨다.
   2. Temporal의 역할: ADK 안에 통합되어 배달 과정에서 일어나는 상태를 추적·관리한다.
   3. 가시성: Temporal UI는 현재 작업의 Event History를 보여주며, Ziggy 배달 스위트 전체 활동의 부모 Workflow가 화면에 나타난다.

1.2. 사람이 주문을 바꾸는 순간

1. 주문 변경 요청

   1. 고객의 변심: 고객이 주문을 제출한 뒤 “주문을 바꾼 것 같다”고 생각해 변경을 요청한다.
   2. 일반적인 위험: 구현 방식에 따라 이런 변경 요청이 시스템 전체를 깨뜨릴 수 있다. 사람이 단순히 입력을 제출했다는 이유로 시스템이 무너지면 안 된다.

2. 한 부분만 멈추는 구조

   1. Driver A의 대기: 주문 변경이 처리되는 동안 Driver A만 해당 업데이트를 기다리며 멈춘다.
   2. 나머지 작업의 지속: 전체 시스템을 멈추지 않고 다른 주문은 계속 들어오고 채워진다.
   3. 사람의 승인: 다른 사람이 변경을 승인할지 결정하고 approve를 누른다.
   4. 배달 재개: 업데이트가 읽힌 뒤 주문은 다음 목적지인 Oracle Park로 이동하고, 작은 배달 차량 A가 주문을 전달한다.

3. 첫 번째 데모가 보여주는 결론

   1. 부분 격리: 사람의 입력은 시스템 전체가 아니라 해당 주문·차량에 연결된 한 Workflow의 진행만 잠시 멈춘다.
   2. 내구성 있는 실행: Google ADK와 Temporal의 통합은 사람의 변경 승인과 배달 재개를 상태로 남긴다.

2. 에이전트 Harness와 내구성의 자리

에이전트를 프로덕션에 배치하는 Harness에는 실행 루프뿐 아니라 실패 복구와 상태 관리까지 포함되어야 한다.

2.1. 에이전틱 루프의 기본

1. 반복 구조

   1. 세 단계: 에이전트는 reason, act, observe를 반복한다.
   2. 다른 표현: 같은 구조를 think, act, perceive라고도 부를 수 있다.
   3. 구현 형태: for 루프일 수도 있고 while 루프일 수도 있다.

2. Ziggy 배달의 세 루프

   1. Fleet Agent 루프: 실제 운전기사와 차량을 조사하고 Google Maps 같은 도구를 사용한다.
   2. Customer Agent 루프: 주문 정보를 조사하며 Google Search 같은 도구를 사용한다.
   3. Dispatch Agent 루프: 두 조사 결과를 받아 배차 결정을 내린다.
   4. 사람의 위치: 사람은 세 루프의 일부에 입력을 제공하는 외부 판단 주체로 들어올 수 있다.

2.2. Harness의 경계와 논쟁

1. Harness의 목적

   1. 프로덕션 구조화: Harness는 에이전트가 프로덕션에서 합리적으로 작동하도록 구조를 제공한다.
   2. 경계의 미확정성: 모델이 Harness에 포함되는지, 아니면 바깥에 있는지에 관해 의견이 갈린다.
   3. 포함 후보: 도구, 메모리, Guardrail, 보안이 어디까지 Harness의 일부인지도 논쟁 중이다.

2. 발표자의 태도

   1. 전문성의 한계 인정: Warrick은 Harness의 전문가라고 주장하지 않고, 조사한 내용을 바탕으로 현재 이해할 수 있는 지도를 제시한다고 말한다.
   2. 내구성의 필요성: 경계가 어떻게 정의되든 에이전트를 프로덕션에 넣으려면 Harness 안에 Durability가 있어야 한다.

2.3. Temporal이 제공하는 내구성

1. 분산 시스템의 공통 문제

   1. 실패 처리 표준화: Temporal은 에이전트가 포함된 분산 시스템의 Failure Handling을 표준화한다.
   2. 상태 관리 표준화: 시스템이 현재 어디까지 진행했는지와 다음 단계가 무엇인지 추적한다.
   3. 복잡성 대응: 다중 에이전트 분산 시스템은 상태가 복잡하기 때문에 실행이 계속 살아 있고 복구 가능한 기반이 필요하다.

2. 제품 형태와 사용 방식

   1. 소프트웨어와 서비스: Temporal은 바로 코드에 적용할 수 있는 Primitive를 제공하는 소프트웨어이면서, 상태 관리를 맡길 수 있는 서비스이기도 하다.
   2. 언어 지원: Python, TypeScript, Rust 등 여러 언어에서 사용할 수 있다.
   3. 운영 선택권: Temporal은 GitHub에서 오픈 소스로 제공되며, 사용자가 직접 Self-hosting하거나 관리형 서비스에 비용을 지불할 수 있다.

3. Worker·Workflow·Activity로 상태를 구조화하기

Temporal의 세 가지 기본 Primitive는 실행 주체, 결정의 순서, 외부 세계와의 상호작용을 분리한다.

3.1. 세 가지 Primitive

1. Worker

   1. 역할: 코드를 실제로 실행한다.
   2. 운영 관점: Worker 프로세스가 사라져도 Workflow History가 보존되어 있으면 다른 Worker가 이어받을 수 있다.

2. Workflow

   1. 역할: 시스템의 단계와 상태를 추적한다.
   2. 에이전트 배치: Google ADK 같은 프레임워크나 에이전트 루프를 Workflow 안에서 실행할 수 있다.
   3. 결정성: Workflow는 결정적이어야 하며, 같은 Event History를 재생하면 같은 현재 상태에 도달해야 한다.

3. Activity

   1. 역할: 외부 시스템과 통합하거나 상호작용하는 작업이다.
   2. 배치 대상: 모델 호출과 도구 호출은 Activity로 구성한다.
   3. 비결정성: 외부 API·모델·검색·지도 데이터는 매번 달라질 수 있으므로 Activity로 분리해 재시도와 실행 결과 추적의 경계를 만든다.

3.2. 에이전트 루프와 Temporal 경계

1. 구조화 방식

   1. 에이전트가 루프를 돌며 판단하는 부분은 Workflow가 단계로 추적한다.
   2. 모델 호출과 도구 호출은 Activity가 담당해 외부 상호작용과 실패를 분리한다.
   3. Worker는 Workflow와 Activity 코드를 받아 실제 실행한다.

2. 내구성이 필요한 이유

   1. 작업 재실행 방지: 이미 비용을 낸 모델·도구 호출의 결과를 보존하고, 장애 때문에 처음부터 모두 실행하지 않는다.
   2. 상태 복원: 프로세스가 내려가도 Event History를 사용해 마지막으로 완료된 단계와 다음 단계를 판별한다.
   3. 다중 에이전트 조정: 여러 에이전트의 결과를 부모·자식 Workflow 관계로 연결한다.

4. 인간을 Blocking Call이 아닌 비동기 API로 모델링하기

사람의 응답을 일반 함수의 반환값처럼 기다리면 에이전트 시스템이 장애에 취약해지므로, 질문과 답변을 내구성 있는 사건으로 분리해야 한다.

4.1. 사람도 에이전트의 도구다

1. 사람의 특수한 역할

   1. 도구로서의 인간: 인간은 일반적인 소프트웨어 도구는 아니지만, 에이전트 관점에서는 정보를 제공하고 판단을 반환하는 도구처럼 연결된다.
   2. 두 방향의 상호작용: 사람이 먼저 에이전트에 변경을 보내거나, 에이전트가 판단을 위해 사람에게 질문할 수 있다.

2. 직접 함수 호출의 함정

   1. Blocking Call: call_human()처럼 사람에게 입력을 요구하는 함수를 루프 안에 곧바로 쓰면 호출이 끝날 때까지 실행이 막힌다.
   2. 상태 유실: 서비스가 내려가면 사람과의 상호작용이 어디까지 진행됐는지 프로세스가 잃어버릴 수 있다.
   3. 운영 결과: 질문을 잊거나, 주문을 버리거나, 이미 수행한 모델 호출을 다시 실행하거나, 같은 결정을 두 번 적용할 위험이 있다.

4.2. wait condition과 Signal

1. 대기 조건으로 상태 저장

   1. 이벤트 격리: 사람의 응답이 필요한 이벤트를 Workflow 안에서 분리한다.
   2. 내구성 계층에 저장: wait condition을 적용해 대기 상태를 Workflow의 Durability Layer와 Event History에 남긴다.
   3. 재시작 가능성: 시스템이 중단됐다가 올라오면 마지막으로 기다리던 위치를 알고 재개한다.

2. Signal로 응답 주입

   1. 비동기 입력: 사람의 응답은 어느 시점에든 Signal로 실행 중인 Workflow에 주입한다.
   2. 전체 시스템 지속: 사람의 응답을 기다리는 한 호출에 시스템 전체가 막히지 않고 다른 Workflow와 배달은 계속 진행된다.
   3. 다음 단계 실행: Signal이 상태를 바꾸면 대기 조건이 충족되고, Workflow가 사람의 답변을 다음 입력으로 사용한다.

3. 실행 자원과 확장성

   1. 스레드 미점유: 사람을 기다리는 동안 스레드를 붙잡지 않는다.
   2. 코루틴 지속: 특정 Workflow의 코드를 멈추되 그 Workflow의 다른 코루틴과 시스템의 다른 Workflow는 계속 실행할 수 있다.
   3. Parked Workflow: 당장 실행할 것이 없으면 Workflow를 메모리에서 내려 Parked 상태로 둘 수 있다.
   4. 대규모 대기: 수백만 개의 Workflow가 사람의 응답을 기다리며 주차된 상태로 확장될 수 있다.
   5. Timeout: 사람이 일정 시간 안에 응답하지 않을 경우를 위해 Timeout 등 기본 Primitive를 적용할 수 있다.

5. Google ADK와 Temporal의 구현 방식

Google ADK 통합은 모델·도구·Worker를 Temporal Primitive에 맞춰 감싸는 형태로 구성된다.

5.1. 모델과 도구를 Activity로 감싸기

1. Temporal Model

   1. 모델 래퍼: ADK에 전달할 모델을 Temporal Model Class로 감싼다.
   2. 에이전트 생성: 래핑한 모델을 ADK 에이전트 설정에 넘기고, 일반적인 ADK 방식처럼 에이전트를 실행한다.

2. Activity Tool

   1. 도구 래퍼: ADK가 사용하는 도구를 Temporal Activity Tool로 감싼다.
   2. 외부 호출 경계: Google Maps, Google Search, 모델 API처럼 외부 상태에 의존하는 작업을 Activity로 분리한다.

3. Worker와 플러그인

   1. Worker 구성: Worker를 설정하고 Google ADK Plugin을 전달한다.
   2. 결과: Worker·Workflow·Activity가 연결되어 에이전트 루프의 상태와 외부 호출을 Temporal이 추적한다.

5.2. ADK에서 대기와 Signal 사용하기

1. Workflow 대기

   1. 비동기 대기: Python의 asyncio와 wait를 사용해 특정 Workflow를 멈춘다.
   2. 선택적 중단: 해당 Workflow에서는 이후 코드를 실행하지 않지만, 같은 Workflow의 다른 코루틴과 시스템의 다른 Workflow는 실행을 계속한다.

2. Workflow Signal

   1. 입력 주입: workflow.signal은 실행 중인 Workflow에 어떤 형태의 입력이든 주입할 수 있다.
   2. 메모리 밖 보관: 당장 실행 중이 아닌 Workflow는 시스템 메모리에서 내려 Parked 상태로 둘 수 있다.
   3. 복구: Worker가 다시 실행되면 보존된 상태와 Signal을 사용해 사람의 입력을 처리한다.

6. LangGraph와 결합한 에이전트→사람 흐름

Temporal은 특정 에이전트 프레임워크에 종속되지 않으며, Google ADK와 LangGraph를 한 시스템 안에서 조합할 수 있다.

6.1. 프레임워크 간 역할 분리

1. 데모 구성

   1. Customer Agent와 Fleet Agent: Google ADK에서 실행된다.
   2. Dispatch Agent: LangGraph에서 실행된다.
   3. Temporal의 위치: 두 프레임워크 전체에 Temporal이 엮여 상태·대기·복구를 담당한다.

2. LangGraph의 Temporal 경계

   1. Graph Node: Temporal 통합 정보를 각 LangGraph Node에 전달한다.
   2. Activity: 모델을 invoke하거나 도구를 호출하는 작업은 Activity로 설정한다.
   3. Workflow: 전체 과정의 단계는 Workflow로 설정한다.
   4. 결정성 구분: Workflow 단계는 결정적이어야 하고 Activity의 모델·도구 상호작용은 비결정적일 수 있다.
   5. Plugin: Worker에는 LangGraph용 Plugin을 전달한다.

6.2. LangGraph interrupt와 Temporal wait

1. 질문 발생

   1. Graph에서 호출: LangGraph Node가 사람에게 물어야 할 때 LangGraph의 interrupt를 사용해 그래프 밖으로 질문을 보낸다.
   2. 대기 연결: 해당 interrupt를 추적하는 루프에 Temporal의 wait condition을 적용한다.

2. 응답 재개

   1. 응답 캡처: 사람이 질문에 답하면 Signal이 그 응답을 포착한다.
   2. 그래프 재개: Workflow가 응답을 다음 관찰값으로 전달하고 그래프 실행을 재개한다.
   3. 프레임워크 비종속성: ADK의 에이전트 루프와 LangGraph의 그래프를 모두 같은 내구성 계층 아래에 둘 수 있다.

7. 고가 주문 승인과 Worker 장애 복구 데모

에이전트가 사람의 판단을 요청한 뒤 Worker를 강제로 종료해도, 질문·승인·다음 실행 단계가 유실되지 않는다.

7.1. 에이전트가 사람에게 묻는 과정

1. 주문별 자식 Workflow

   1. 전체 시스템: Fleet, Customer, Dispatch 에이전트가 계속 주문을 평가한다.
   2. 주문 단위 분리: 각 주문마다 프레임워크별 자식 Workflow를 나누어 특별 주문도 독립적으로 평가한다.
   3. 평가 전달: Customer Agent와 Fleet Agent가 작업을 마치고 결과를 Dispatch Agent로 보낸다.

2. 고가 주문의 승인 게이트

   1. 사람 개입 판단: 고가 주문은 잘못 배차했을 때 비용이 크므로 사람의 판단이 필요할 가능성이 높다.
   2. Dispatch Agent의 대기: Dispatch Agent가 “사람을 참여시켜야 한다”고 판단하면 해당 Workflow를 Pause 상태로 만든다.
   3. 다른 배달의 지속: 승인 대기 중에도 다른 차량과 주문은 계속 움직인다.

7.2. 인간 응답의 시간 규모

1. 200밀리초의 거부

   1. 현실적인 사람의 응답: 인간은 대개 200밀리초 안에 답하지 않는다.
   2. 응답 범위: 몇 분, 며칠, 몇 주, 또는 그보다 더 오래 걸릴 수 있다.
   3. 설계의 결론: Workflow 하나의 이벤트만 멈추게 하면 그 긴 시간 동안 시스템 전체를 막을 필요가 없다.

2. 시각적 확인

   1. 움직이는 차량: 승인 카드가 대기 중인 동안 화면의 작은 자동차들은 계속 이동한다.
   2. 부분 정지: 사람의 판단이 필요한 주문만 Pause되고 나머지 배달 상태는 계속 갱신된다.

7.3. Worker를 끄고 오프라인에서 승인하기

1. 장애 주입

   1. 서비스 종료: 데모 중 Worker를 종료하면 화면이 Disconnected 상태가 된다.
   2. 오프라인 승인: Worker가 내려간 상태에서 approve를 누른다.

2. 외부 내구성 계층의 처리

   1. 프로세스 밖의 기록: Workflow 상태와 이벤트는 서비스 프로세스가 아닌 자체 데이터 저장소에 남아 있다.
   2. 대기열 보존: Worker가 없어도 승인 이벤트를 추적하고 Queue에 넣는다.
   3. 유실 방지: 사람의 승인이 실행 중인 Worker 메모리에만 있지 않으므로 종료 순간에 사라지지 않는다.

3. Worker 복귀와 Replay

   1. 재기동: Worker를 다시 올리면 Dispatch Agent가 Workflow를 이어받는다.
   2. Replay의 의미: Event Log는 처음부터 작업을 다시 수행하는 것이 아니라 마지막 위치까지 재생된다.
   3. 현재 상태 계산: Replay가 현재 상태를 복원하고, 그 상태에서 다음 단계가 무엇인지 결정한다.
   4. 승인 반영: 대기 중이던 Signal이 처리되어 사람이 승인했다는 사실이 다음 단계에 전달된다.
   5. 최종 결과: 주문이 배정되고, 이미 배달까지 완료된다.

8. 언제 사람을 루프에 넣을 것인가

Human-in-the-Loop는 항상 넣는 기능이 아니라, 자동화 오류의 비용과 사람의 경보 피로를 비교해 선택하는 설계 결정이다.

8.1. 오판 비용을 기준으로 판단하기

1. 높은 오류 비용

   1. 사례별 판단: 어떤 문제에 사람을 넣을지는 문제마다 다르다.
   2. 비용 평가: 자동화가 틀렸을 때 실제로 얼마의 비용이 발생하는지 평가한다.
   3. 보안 고려: 보안 상황에서는 잘못된 판단의 비용과 영향 범위를 특히 따져야 한다.

2. 자율성의 한계

   1. 목표: 시스템은 가능한 한 높은 자율성을 지향한다.
   2. 확률적 모델: 현재 모델은 확률적이며 완전히 신뢰할 수 있는 수준으로 만들기 어렵다.
   3. Harness의 필요성: 모델이 확률적이라는 사실 때문에 Harness와 실행 내구성 설계가 중요해진다.

8.2. Alert Fatigue와 승인 남용

1. 경보 피로

   1. 반복 승인: 시스템이 계속 질문하면 사람은 내용을 확인하지 않고 “yes, yes, yes”를 반복하게 된다.
   2. 안전 효과의 약화: 모든 경보를 습관적으로 승인하면 사람이 루프에 들어온 의미가 줄어든다.

2. 두 비용의 균형

   1. 오류 비용: 사람을 넣지 않아 자동화가 잘못될 때의 피해를 계산한다.
   2. 피로 비용: 사람을 너무 자주 불러 판단 품질이 떨어지는 비용을 계산한다.
   3. 모델 개선: 모델을 더 신뢰할 수 있게 만들어 불필요한 승인 요청을 줄여야 한다.
   4. 현재의 현실: 모델은 여전히 확률적이므로 문제의 성격에 따라 개입 임계값을 계속 평가해야 한다.

9. 주요 발언 모음

“인간은 200밀리초 안에 응답하지 않는다. 에이전트가 인간을 기다린다고 무너지게 만들지 마라.”

“인간은 도구는 아니지만, 에이전트에게는 하나의 도구다.”

“사람을 호출하는 함수를 곧바로 쓰면 Blocking Call이 될 수 있고, 서비스가 내려갔을 때 잃어버릴 수 있다.”

“사람을 기다리는 한 호출에 시스템 전체가 막히지 않도록 wait condition과 Signal을 사용하라.”

“수백만 개의 Workflow를 주차해 두고 계속 실행할 수 있다.”

“Event Log는 다시 실행되는 것이 아니라 마지막으로 멈춘 지점까지 Replay된다.”

“사람을 루프에 넣을지는 틀렸을 때의 비용이 높은지에 달려 있다.”

“사람이 매번 묻는 질문에 yes, yes, yes, yes라고 답하기 시작하면 Alert Fatigue가 현실이 된다.”

“Temporal은 여러 프레임워크와 함께 작동하며, 프레임워크에 종속되지 않는다.”

10. 발표 중 현장 반응과 진행 흐름

1. 예상 밖의 데모 진행

   1. Warrick은 시작부터 관계자가 넘지 말라고 한 “상자 밖”으로 이미 나왔다고 농담한다.
   2. 두 번째 데모를 준비하며 예제를 Reset했지만 원하는 만큼 “easy peasy”하게 되지 않는다고 말한다.

2. 신체 상태와 환경

   1. 눈을 다쳐서 때때로 눈을 찡그리고 있고, 준비하지 못한 추가 지원이 필요하지만 상황에 맞춰 적응할 수 있다고 말한다.
   2. 청중에게 목소리가 잘 들리는지 확인하고, 주변 소음 속에서 진행하는 것이 흥미로운 조건이라고 말한다.
   3. 눈 관련 농담 뒤 청중이 웃는다.

3. 마무리 상호작용

   1. 청중에게 몇 분 더 머물며 질문을 받겠다고 한다.
   2. Temporal과 데모 자료로 연결되는 QR 코드를 소개하고, 데모와 발표 자료를 GitHub에 올리겠다고 말한다.
   3. 슬라이드는 발표 직전까지 계속 수정하고 있어 나중에 GitHub 저장소와 연결할 예정이라고 설명한다.
   4. 청중이 현재 어떤 에이전트 문제를 해결하고 어떻게 자율적으로 구축하는지 듣고 싶다며 연락을 요청한다.
   5. “에이전트 클립(agent clips)”을 재미있게 만들라고 말하며 감사를 전하고, 청중의 환호로 끝난다.

핵심 데이터 & 수치

• 1,156초: 제공된 영상 길이로 약 19분 16초다.
• 3개 에이전트: Fleet Agent, Customer Agent, Dispatch Agent가 Ziggy 배달을 조정한다.
• 2개 핵심 Primitive: 사람의 대기를 보존하는 wait condition과 응답을 주입하는 Signal이다.
• 3개 Temporal Primitive: 실행하는 Worker, 단계를 추적하는 Workflow, 외부 상호작용을 담당하는 Activity다.
• 200밀리초: 사람이 일반적으로 응답한다고 가정하면 안 되는 짧은 시간의 예시다.
• 수분·수일·수주 이상: 사람의 승인 응답이 실제로 걸릴 수 있는 시간 범위다.
• 수백만 개: 응답을 기다리며 Parked 상태에 둘 수 있는 Workflow 규모의 예시다.
• 여러 언어: Temporal은 Python, TypeScript, Rust 등에서 사용할 수 있다.
• 여러 프레임워크: Google ADK와 LangGraph를 한 시스템 안에서 함께 사용할 수 있다.
• 두 방향의 Human-in-the-Loop: 사람이 주문을 바꾸는 Human → Agent와 에이전트가 승인을 요청하는 Agent → Human이다.

결론 및 시사점

1. 사람의 응답을 빠른 함수 반환값으로 가정하지 말고, 수분에서 수주까지 걸릴 수 있는 비동기 API로 모델링해야 한다.
2. wait condition으로 질문이 필요한 Workflow를 내구성 있게 멈추고, Signal로 나중에 도착한 사람의 답변을 주입해야 한다.
3. Workflow에는 결정적 단계와 상태 추적을, Activity에는 모델·도구·외부 API 호출을, Worker에는 실제 실행을 배치해야 한다.
4. Worker가 죽거나 서비스가 재배포되어도 Event History를 Replay해 마지막 상태와 다음 단계를 복원할 수 있어야 한다.
5. 사람의 승인을 기다리는 주문만 멈추고 다른 Workflow와 배달은 계속 실행해야 전체 시스템의 처리량을 보존할 수 있다.
6. Google ADK와 LangGraph처럼 서로 다른 에이전트 프레임워크의 루프를 Temporal 아래에서 연결하면 프레임워크별 강점을 유지하면서 핸드오프를 내구성 있게 만들 수 있다.
7. Human-in-the-Loop를 추가할지는 자동화 오류의 비용, 보안 위험, 사람의 Alert Fatigue를 함께 계산해 결정해야 한다.
8. 신뢰할 수 있는 에이전트 시스템은 모델의 자율성만 높이는 것이 아니라, 실패·대기·재시작·사람의 늦은 응답을 정상적인 상태 전이로 다룬다.