인간은 비동기 API다 — AI 에이전트가 사람을 기다리다 멈추지 않는 법

URL: https://www.youtube.com/watch?v=HjQ1G1NvvHQ
날짜: 2026-10-09
채널: Tech Bridge
원문 제목: [한영자막] 인간은 비동기 API입니다: AI 에이전트가 사람을 기다리다 멈추지 않는 법

---

📌 핵심 질문·논점

==사람의 응답을 기다리는 AI 에이전트가 전체 시스템을 막거나 상태를 잃지 않도록, 인간을 오래 걸릴 수 있는 비동기 API로 취급하고 durable execution을 적용하려면 어떻게 설계해야 하는가?==

• 에이전트는 reason → act → observe 또는 think → act → perceive 루프를 반복하며 자율적으로 움직인다.
• 사람의 승인·수정·추가 입력은 200밀리초가 아니라 수분, 수일, 수주 또는 그 이상 걸릴 수 있으므로 일반적인 동기 함수 호출로 구현하면 안 된다.
• workflow 안에 대기 조건(wait condition)을 저장하고, 사람의 응답은 signal로 전달하면 한 부분만 멈추고 나머지 시스템은 계속 실행할 수 있다.
• Temporal은 워크플로 상태, 실패 처리, 이벤트 이력, 재시작 후 복구를 표준화하고 Google ADK·LangGraph 같은 여러 에이전트 프레임워크를 연결한다.

에이전트 시스템에서 중요한 것은 모델 호출 자체만이 아니다. 도구·메모리·가드레일·보안으로 구성된 harness에 구조와 내구성을 더하고, 모델이 틀렸을 때의 비용이 높은 지점에만 사람을 개입시켜야 한다. 사람의 응답이 도착할 때까지 스레드를 붙잡아 두는 대신, 실행을 내구성 있는 저장소에 주차하고 나중에 이어서 실행하는 방식이 핵심이다.

1. 아이스크림 배송으로 확인하는 다중 에이전트와 durable execution

아이스크림 주문을 여러 에이전트가 협력해 처리하는 예제는 인간 개입이 포함된 분산 시스템의 문제를 작게 보여준다.

1.1. Ziggy 배송 서비스의 구성

1. Ziggy와 아이스크림 가게

   1. Ziggy는 시스템의 마스코트이며, 실제로 가게를 운영하는 것은 아니지만 샌프란시스코 Ferry Building에서 아이스크림을 배달하는 가상의 사업자로 설정된다.
   2. 화면에는 Ziggy의 아이스크림 서비스 배송을 조정하는 여러 에이전트가 표시된다.
   3. 발표자는 처음부터 정해진 발표 범위를 조금 벗어났다고 농담하고, Ziggy를 좋아한다고 말하며 예제를 친근하게 소개한다.

2. 세 에이전트의 역할

   1. Fleet agent는 실제 배달 기사와 차량 정보를 조사하며, Google Maps 같은 도구를 사용한다.
   2. Customer agent는 주문 정보를 조사하며, Google Search 같은 도구로 주문 관련 정보를 확인한다.
   3. Dispatch agent는 fleet agent와 customer agent가 보낸 조사 결과를 받아 배송 결정을 내린다.
   4. 세 에이전트는 각자 루프를 실행하지만, 최종적으로 아이스크림이 올바른 목적지에 도착하도록 협력한다.

1.2. Google ADK와 Temporal의 결합

1. ADK가 담당하는 에이전트 오케스트레이션

   1. Google의 ADK(Agent Development Kit)는 하나 또는 여러 에이전트를 오케스트레이션하는 솔루션이다.
   2. 이 예제에서는 fleet·customer·dispatch 에이전트의 활동을 조정하는 역할을 맡는다.
   3. Temporal 통합이 ADK 안에 포함되어 에이전트 실행의 상태를 추적할 수 있다.

2. Temporal UI가 보여주는 상태

   1. Temporal은 현재 상태를 추적·관리하고, 화면에서 실행 중인 내용을 확인할 수 있는 UI를 제공한다.
   2. UI에는 현재 Ziggy 배송 제품군에서 실행되는 모든 활동의 상위(parent) 워크플로와 이벤트 이력이 표시된다.
   3. 이벤트 이력은 시스템이 어디까지 진행했는지, 재시작했을 때 어느 지점부터 이어야 하는지를 나타내는 내구성 있는 기록이다.

1.3. 주문 변경과 사람의 승인

1. 한 주문만 일시 정지하기

   1. 고객이 주문을 제출한 뒤 마음을 바꾸어 주문 변경을 요청하는 상황을 가정한다.
   2. 일반적인 방식으로 변경 요청을 처리하면 시스템 전체가 깨질 수 있지만, 내구성 있는 워크플로에서는 특정 주문에 해당하는 driver A의 처리만 멈춘다.
   3. 사람의 변경 요청을 다른 사람이 승인할지 결정하는 동안에도 전체 시스템은 계속 실행된다.

2. 나머지 주문의 지속 실행

   1. driver A가 업데이트를 기다리는 동안 다른 주문은 계속 들어오고 채워진다.
   2. 승인 버튼을 누르면 업데이트가 처리되고, 잠시 네트워크 지연이 있었지만 주문이 다음 위치로 이동한다.
   3. 예제 주문의 다음 목적지는 Oracle Park이며, 작은 차량 아이콘 A가 주문을 배달한다.
   4. 하나의 인간 입력이 한 실행 경로만 막고 다른 경로까지 막지 않는 것이 durable execution의 핵심이다.

2. 에이전트 루프와 production harness에 필요한 내구성

에이전트의 자율성은 반복 루프를 통해 만들어지지만, 실제 운영 환경에서는 그 루프가 실패·재시작·인간 개입을 견뎌야 한다.

2.1. reason → act → observe 루프

1. 반복되는 인지·행동 구조

   1. 에이전트는 추론(reason)하고 행동(act)한 뒤 관찰(observe)한다.
   2. 같은 구조를 생각하고(thinking), 행동하고(acting), 지각하는(perceiving) 루프로도 표현할 수 있다.
   3. 구현 형태는 for 루프일 수도 있고 while 루프일 수도 있지만, 핵심은 다음 행동을 결정하기 위해 앞 단계의 관찰을 계속 반영하는 것이다.

2. 세 배송 에이전트에 적용되는 루프

   1. fleet agent는 기사와 이동 경로에 대한 조사를 반복한다.
   2. customer agent는 주문에 대한 조사를 반복한다.
   3. dispatch agent는 두 조사 결과를 이용해 배송 결정을 반복한다.
   4. 사람은 이 구조 안에서 승인·변경·판단을 제공하는 입력원이 될 수 있다.

2.2. harness의 범위에 관한 논쟁

1. harness가 해결하려는 문제

   1. 2026년 내내 에이전트를 production에 배치하기 위한 harness가 무엇이어야 하는지 논의가 이어지고 있다.
   2. harness의 정확한 경계에는 합의가 없으며, 모델 자체가 포함되는지 여부부터 의견이 갈린다.
   3. 모델, 도구, 메모리, 가드레일, 보안이 harness의 일부인지에 대해서도 여러 견해가 있다.

2. 공통 목적

   1. 세부 구성요소의 경계가 달라도 목표는 에이전트에 충분한 구조를 부여해 production에서 합리적으로 작동하게 하는 것이다.
   2. 그 구조에는 실패 처리와 상태 보존을 포함하는 durability가 반드시 들어가야 한다.
   3. 아이스크림 배송처럼 여러 루프가 동시에 돌면 한 루프의 인간 대기나 실패가 다른 루프를 연쇄적으로 멈추지 않아야 한다.

2.3. Temporal이 제공하는 표준화

1. 실패 처리와 상태 관리

   1. Temporal은 에이전트가 포함된 분산 시스템의 실패 처리와 상태 관리를 표준화한다.
   2. 특정 에이전트, 서비스 또는 작업이 내려가도 이미 진행한 상태와 다음 실행 지점을 잃지 않도록 한다.
   3. 소프트웨어로 직접 사용할 수도 있고, 상태 관리를 맡기는 서비스로 사용할 수도 있다.

2. 코드에 적용하는 기본 기능

   1. Temporal은 코드베이스에 바로 적용할 수 있는 표준 primitive를 제공한다.
   2. Python, TypeScript, Rust 등 여러 언어에서 동일한 개념을 적용할 수 있다.
   3. 무료 오픈소스이며, GitHub에서 직접 가져와 자체 호스팅할 수 있고, 관리형 서비스를 이용하면 Temporal이 상태 관리를 운영한다.

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

에이전트 루프와 외부 상호작용을 서로 다른 primitive로 나누면 무엇을 재생해야 하고 무엇을 다시 실행해야 하는지 명확해진다.

3.1. 세 가지 핵심 primitive

1. Worker

   1. Worker는 실제 코드를 실행한다.
   2. 워크플로와 활동을 실행할 프로세스이며, Google ADK 또는 LangGraph용 플러그인을 연결하는 장소다.

2. Workflow

   1. Workflow는 시스템의 단계와 현재 진행 상태를 추적한다.
   2. ADK 프레임워크로 동작하는 에이전트 루프 자체를 workflow 안에서 실행할 수 있다.
   3. 단계 순서와 대기 상태를 보존하므로, 프로세스가 내려갔다가 올라와도 마지막 상태부터 계속할 수 있다.

3. Activity

   1. Activity는 외부 시스템과 통합하거나 상호작용하는 작업이다.
   2. 모델 호출과 도구 호출은 비결정적이므로 activity로 감싼다.
   3. 외부 API 응답, 검색 결과, 지도 계산처럼 같은 입력에도 결과가 달라질 수 있는 작업을 workflow의 결정론적 단계와 분리한다.

3.2. 결정론과 비결정론의 분리

1. Workflow의 결정론성

   1. workflow는 동일한 이벤트 이력을 재생했을 때 동일한 상태 전이를 만들어야 한다.
   2. 어떤 단계가 끝났고 다음에 무엇을 해야 하는지에 관한 구조는 workflow로 기록한다.

2. Activity의 비결정론성

   1. 모델 호출과 도구 호출은 외부 세계와 상호작용하므로 결과가 달라질 수 있다.
   2. 이런 호출을 activity로 분리하면 workflow 재생 시 외부 작업을 무분별하게 다시 실행하지 않고 필요한 결과와 상태를 기준으로 진행할 수 있다.

4. 인간은 동기 함수가 아니라 비동기 API다

사람을 호출하는 코드를 일반 함수처럼 작성하면 긴 대기 시간과 서비스 장애 때문에 입력을 잃거나 전체 실행을 막을 수 있다.

4.1. 동기적인 사람 호출의 문제

1. 사람을 도구로 보는 관점

   1. 사람은 소프트웨어 도구는 아니지만 에이전트 입장에서는 정보를 제공하는 도구로 기능할 수 있다.
   2. 에이전트가 사람에게 질문하고 결과를 받아 루프에 넣는 구조 자체는 자연스럽다.

2. 일반 함수 호출의 위험

   1. call_human()처럼 사람의 입력을 바로 반환하는 함수로 작성하면 동기적 blocking call이 된다.
   2. 사람의 응답을 기다리는 동안 스레드나 실행 자원을 붙잡고, 서비스가 내려가면 어떤 질문을 했고 어디까지 기다렸는지 잃을 수 있다.
   3. 사람 한 명의 느린 응답이 전체 시스템의 진행을 막는 구조가 된다.

4.2. wait condition과 signal

1. 대기 조건 저장

   1. 워크플로 안에 wait condition을 적용해 특정 이벤트가 발생할 때까지 해당 실행을 일시 정지한다.
   2. 대기 상태와 필요한 문맥을 durability layer에 저장하므로 시스템이 내려갔다가 복구해도 마지막 위치를 안다.
   3. 기다리는 동안 해당 workflow의 다른 코루틴이나 시스템의 다른 workflow는 계속 실행할 수 있다.

2. signal로 응답 전달

   1. 사람의 응답은 나중에 어느 시점에서든 signal로 보낼 수 있다.
   2. signal은 실행 중인 workflow에 질문에 대한 답이나 승인 결과를 주입한다.
   3. 응답이 도착하면 대기 조건이 해소되고, 저장된 상태에서 다음 단계가 이어진다.

3. 자원과 장애 회복

   1. 이 방식은 대기 중인 사람마다 스레드를 붙잡지 않는다.
   2. 프로세스 충돌을 견디고, timeout을 걸어 일정 시간 뒤 자동으로 다른 경로를 선택하게 할 수 있다.
   3. 수백만 개의 workflow를 대기 상태로 주차해 두고도 시스템을 계속 실행할 수 있다.

4.3. Python 구현의 개념

1. 대기 구현

   1. Python 예제에서는 async.io의 wait 계열 조건을 사용해 특정 workflow만 멈춘다.
   2. 그 workflow가 아무 코드도 더 실행하지 않도록 일시 정지하지만, 같은 workflow의 코루틴과 다른 workflow의 실행까지 중단하지는 않는다.

2. 신호 구현

   1. signal handler는 어떤 입력이 도착했는지 받아 실행 중인 workflow의 상태에 주입한다.
   2. workflow는 승인, 거절, 수정 내용 같은 결과를 읽고 다음 단계를 수행한다.
   3. timeout 등 내장 primitive를 조합하면 사람의 응답이 영원히 오지 않는 경우도 제어할 수 있다.

5. ADK와 LangGraph에 같은 내구성 모델 적용하기

Temporal은 특정 에이전트 프레임워크에 종속되지 않으며, 프레임워크의 실행 단위에 workflow·activity·signal을 매핑한다.

5.1. ADK를 Temporal에 연결하는 방식

1. 모델과 도구 감싸기

   1. ADK를 사용할 때 Temporal model class로 모델을 감싼다.
   2. ADK의 각 도구는 Temporal activity tool로 감싸 외부 상호작용을 activity로 만든다.
   3. 그 뒤 ADK에서 하던 방식과 동일하게 에이전트를 실행한다.

2. Worker 설정

   1. Temporal worker를 설정하고 Google ADK plugin을 전달한다.
   2. 이 구성이 worker·workflow·activity를 연결해 ADK 에이전트 루프를 내구성 있는 실행으로 바꾼다.

3. 인간 대기 연결

   1. workflow에 wait condition을 추가해 사람이 응답할 때까지 해당 작업을 주차한다.
   2. 사람이 signal을 보내면 같은 workflow가 저장된 상태에서 재개된다.

5.2. LangGraph와의 통합

1. 그래프 노드와 실행 단위

   1. LangGraph는 여러 에이전트 구성을 그래프로 만들며, Temporal은 각 그래프 노드에 필요한 메타데이터를 전달한다.
   2. 모델을 invoke하거나 다른 도구를 호출하는 노드는 activity로 설정한다.
   3. 단순히 프로세스의 다음 단계로 넘어가는 구조적 단계는 workflow로 설정한다.

2. LangGraph의 interrupt

   1. LangGraph에는 노드에서 외부로 빠져나와 인간 개입을 요청하는 interrupt 기능이 있다.
   2. interrupt를 호출하면 loop tracking에서 wait condition을 적용해 workflow를 멈춘다.
   3. 사람의 응답은 signal로 캡처하고, 해당 노드가 응답을 받은 것처럼 그래프를 이어간다.

3. 프레임워크 독립성

   1. Temporal은 ADK와 LangGraph를 포함해 다양한 도구와 함께 작동한다.
   2. LangGraph는 단순한 프레임워크 이상의 성격을 가질 수 있지만, 예제에서는 에이전트 그래프를 실행하는 프레임워크로 사용한다.
   3. 어떤 프레임워크를 선택하더라도 모델·도구 호출은 activity, 상태 전이와 단계는 workflow라는 공통 원칙을 적용한다.

6. 고가 주문 승인 데모와 장애 복구

사람의 판단이 필요한 고가 주문을 별도 child workflow로 분리하고, Worker가 내려간 상태에서도 승인 이벤트를 보존하면 긴 인간 대기와 장애를 동시에 다룰 수 있다.

6.1. 고가 주문의 평가 흐름

1. 데모 시스템 구성

   1. customer agent와 fleet agent는 ADK에서 실행된다.
   2. dispatch agent는 LangGraph에서 실행된다.
   3. Temporal은 세 에이전트 전체에 엮여 상태와 실행 이력을 보존한다.

2. 주문별 child workflow

   1. 전체 시스템 workflow는 모든 에이전트가 주문을 계속 평가하는 상태를 보여준다.
   2. 각 프레임워크별로 주문마다 분리된 child workflow를 만들도록 구성한다.
   3. 고가 주문은 자기만의 평가 흐름을 가지며, 일반 주문의 진행을 멈추지 않는다.

3. dispatch의 인간 개입 결정

   1. customer agent와 fleet agent가 각자 조사·평가를 끝낸다.
   2. 두 결과를 dispatch agent에 보내면 dispatch agent가 고가 주문에는 사람의 승인이 필요하다고 판단한다.
   3. dispatch agent는 human response를 기다리는 pause 상태로 들어가고, 배송 차량 아이콘들은 계속 움직인다.

6.2. 사람의 현실적인 응답 시간

1. 200밀리초라는 비현실적인 기대

   1. 사람은 보통 200밀리초 안에 응답하지 않는다.
   2. 발표자는 그렇게 빨리 응답하는 사람이 있다면 대단한 일이고, 아마 몇 명쯤은 있을 것이라고 농담한다.

2. 긴 대기 시간의 범위

   1. 사람의 답변은 수분이 걸릴 수 있다.
   2. 업무 상황에 따라 수일, 수주 또는 그보다 오래 걸릴 수도 있다.
   3. 이 긴 대기가 한 특정 이벤트에만 영향을 주도록 workflow를 주차해야 하며, 배송 시스템 전체를 멈춰서는 안 된다.

6.3. Worker를 끈 뒤 승인하기

1. 서비스 오프라인 상태

   1. 데모에서 worker를 종료해 서비스를 오프라인으로 만든다.
   2. 화면에는 연결이 끊겼다는 상태가 표시되지만, workflow 이벤트가 사라지는 것은 아니다.

2. 오프라인 승인 보존

   1. 서비스가 내려간 동안에도 승인 버튼을 누를 수 있다.
   2. 이 승인은 실행 서비스 자체가 아니라 별도의 데이터 저장소에 기록되고 대기열에 들어간다.
   3. worker가 다시 올라오기 전에도 시스템은 사람의 이벤트를 추적할 수 있다.

3. 복구 후 이벤트 재생

   1. worker를 다시 시작하면 dispatch agent의 이벤트 로그가 마지막 상태까지 재생된다.
   2. 이 과정은 과거 작업을 다시 실행하는 것이 아니라, 이벤트를 다시 읽어 상태를 복원하는 것이다.
   3. 시스템은 현재 상태와 다음 단계가 무엇인지 확인하고, 승인 결과를 다음 단계에 전달한다.
   4. 주문은 이미 배정되고 실제 배송까지 완료된다.
   5. 서비스가 내려갔다가 복귀해도 복잡한 분산 상태를 잃지 않고 이어가는 것이 durability의 실질적인 효과다.

7. 언제 사람을 loop에 넣을 것인가

인간 개입은 많이 넣는다고 항상 안전해지지 않으며, 잘못된 결정의 비용과 승인 피로를 함께 평가해야 한다.

7.1. 잘못될 비용이 높은 지점

1. 사례별 판단

   1. 사람을 loop에 넣어야 하는지에 대한 보편적인 정답은 없다.
   2. 문제마다 잘못된 판단의 비용이 얼마나 큰지 평가해야 한다.
   3. 모델이 안정적으로 동작해 완전한 자율성에 가까워지는 것이 목표지만, 현재 모델은 여전히 확률적이다.

2. 보안과 위험

   1. 보안상 잘못된 결정이 큰 피해로 이어지는 작업에는 사람의 확인이 유효하다.
   2. 반대로 잘못될 비용이 낮은 단순 작업까지 모두 사람에게 묻는다면 자동화의 장점이 줄어든다.
   3. 자율성과 인간 검토 사이의 경계는 해결하려는 문제의 위험도에 맞춰 정해야 한다.

7.2. alert fatigue의 역효과

1. 무조건 승인하는 습관

   1. 시스템이 계속 사람에게 질문하면 사람은 알림을 확인하지 않고 매번 “yes, yes, yes, yes”라고 누르게 된다.
   2. 이런 alert fatigue는 인간 검토가 있다는 형식만 남기고 실제 안전성을 낮춘다.

2. 신뢰와 개입 빈도의 균형

   1. 모델을 더 신뢰할 수 있게 만들수록 불필요한 확인 요청을 줄일 수 있다.
   2. 그렇지만 확률적 모델이 존재하는 한, 위험도가 높은 판단에는 신중한 검토가 필요하다.
   3. 인간 개입의 기준을 비용·보안·응답 피로를 함께 고려해 설계해야 한다.

주요 발언 모음

“인간은 에이전트에게 도구다. 하지만 인간은 동기 함수가 아니라 비동기 API로 다뤄야 한다.”

“사람은 200밀리초 안에 응답하지 않는다. 수분, 수일, 수주 또는 그보다 오래 걸릴 수 있다.”

“한 특정 이벤트를 기다리는 동안에도 작은 자동차들은 계속 움직인다.”

“이벤트 로그는 다시 실행되는 것이 아니라 재생된다.”

“잘못되는 비용이 높은 경우가 인간을 loop에 넣을 때다.”

“에이전트 loop를 재미있게 만들고, 지금 어떤 문제를 에이전트로 해결하고 있는지 알려 달라.”

핵심 데이터·수치

• 3개 에이전트: fleet agent, customer agent, dispatch agent가 아이스크림 배송을 협력 처리한다.
• 2개 핵심 인간 개입 primitive: wait condition으로 workflow를 주차하고 signal로 응답을 전달한다.
• 200밀리초: 사람이 일반적으로 응답할 수 있다고 기대하기에는 비현실적인 시간이다.
• 수분·수일·수주·그 이상: 인간의 승인 응답에 걸릴 수 있는 현실적인 대기 범위다.
• 수백만 workflow: Temporal은 응답을 기다리며 주차된 workflow를 대규모로 유지할 수 있다.
• 3가지 실행 primitive: worker는 코드를 실행하고, workflow는 결정론적 단계·상태를 추적하며, activity는 외부 모델·도구 호출을 담당한다.
• 지원 언어 예시: Python, TypeScript, Rust에서 동일한 내구성 primitive를 적용할 수 있다.
• 2개 에이전트 프레임워크: customer·fleet agent에는 ADK, dispatch agent에는 LangGraph를 사용한 통합 구성이 제시된다.
• 1개 고가 주문 child workflow: 주문별로 분리된 평가 흐름이 사람 승인 대기 중에도 일반 배송 흐름을 막지 않는다.
• 1회 Worker 장애: worker를 끄고 오프라인에서 승인한 뒤 다시 시작해 이벤트 재생과 복구를 확인한다.

결론 및 시사점

1. AI 에이전트의 자율성은 모델의 추론 능력만으로 완성되지 않는다. production에서는 루프가 실패하고 재시작하며 외부 도구와 사람을 기다린다는 사실까지 실행 모델에 포함해야 한다.
2. 사람의 응답을 동기 함수로 호출하면 긴 대기 시간과 장애가 전체 시스템의 병목이 된다. workflow의 wait condition과 signal을 사용해 사람을 비동기 API로 모델링해야 한다.
3. Worker·workflow·activity를 분리하면 실행 코드, 결정론적 상태 전이, 비결정론적 외부 호출의 책임이 나뉘어 장애 복구와 이벤트 재생이 쉬워진다.
4. ADK·LangGraph처럼 서로 다른 프레임워크를 사용하더라도 모델·도구 호출은 activity로, 구조적 단계는 workflow로, 인간 승인은 signal로 연결하는 공통 설계를 적용할 수 있다.
5. 인간 개입 지점은 “모델을 믿을 수 있는가”라는 단일 질문이 아니라 잘못될 비용, 보안 영향, 응답 지연, alert fatigue를 함께 따져 정해야 한다.
6. 가장 실용적인 설계는 한 주문이나 한 위험 이벤트만 주차하고 나머지 workflow는 계속 실행하는 것이다. 이를 위해 durable state와 이벤트 이력을 시스템의 기본 구성요소로 삼아야 한다.
7. 고가 주문 데모처럼 서비스가 오프라인인 동안 들어온 승인도 저장하고, 복구 후 이벤트를 재생해 다음 단계로 이어가야 한다. 재실행과 재생을 구분하는 것이 외부 부작용을 중복 발생시키지 않는 핵심이다.
8. 최종 목표는 인간을 제거하는 것이 아니라, 사람이 꼭 필요한 판단에 집중하도록 만들면서도 사람이 늦게 응답하거나 시스템이 잠시 내려가도 에이전트 시스템이 멈추지 않게 하는 것이다.

20줄 핵심 요약

1. 사람의 응답은 200밀리초가 아니라 수분·수일·수주 또는 그 이상 걸릴 수 있다.
2. AI 에이전트는 추론하고 행동하고 관찰하는 루프를 반복하며 자율적으로 작업한다.
3. 에이전트 production harness에는 모델뿐 아니라 도구·메모리·가드레일·보안과 내구성이 필요하다.
4. Ziggy의 가상 아이스크림 가게는 여러 에이전트가 배송을 협력하는 예제다.
5. fleet agent는 기사와 경로를 조사하고 customer agent는 주문을 조사한다.
6. dispatch agent는 두 조사 결과를 받아 배송 결정을 내린다.
7. Google ADK는 여러 에이전트의 오케스트레이션을 담당하고 Temporal은 상태를 추적한다.
8. 고객의 주문 변경은 driver A의 경로만 멈추고 다른 주문은 계속 처리할 수 있다.
9. 사람을 일반 함수처럼 호출하면 응답 지연이나 서비스 장애로 상태를 잃을 수 있다.
10. wait condition은 사람의 응답을 기다리는 workflow를 내구성 있는 상태로 주차한다.
11. signal은 사람이 나중에 보낸 승인이나 수정 내용을 workflow에 전달한다.
12. Worker는 코드를 실행하고 workflow는 상태를 기록하며 activity는 외부 호출을 감싼다.
13. 모델 호출과 도구 호출은 비결정적이므로 activity로 분리해야 한다.
14. ADK에서는 Temporal model class와 activity tool로 에이전트와 도구를 연결한다.
15. LangGraph에서는 노드의 모델·도구 호출을 activity로, 단계와 interrupt를 workflow로 연결한다.
16. 고가 주문은 별도 child workflow에서 평가되어 사람 승인 대기 중에도 다른 주문을 막지 않는다.
17. worker가 내려가도 별도 저장소에 승인 이벤트를 기록하면 응답을 잃지 않는다.
18. worker가 복구되면 이벤트 로그가 재실행이 아니라 재생되어 마지막 상태에서 이어진다.
19. 사람의 개입 여부는 잘못될 비용과 보안 위험, alert fatigue를 함께 평가해 결정해야 한다.
20. 인간을 비동기 API로 설계하면 긴 응답 지연과 장애 속에서도 에이전트 시스템이 계속 실행된다.