[한영자막] 인간은 비동기 API입니다: AI 에이전트가 사람을 기다리다 멈추지 않는 법

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

인간의 응답을 비동기 API처럼 처리하고 대기 상태를 보존하면, AI 에이전트는 사람을 기다리는 동안에도 다른 작업을 계속하고 장애 뒤에도 이어서 실행할 수 있다.

📌 핵심 요점

1. 인간의 응답은 수분에서 수주까지 걸릴 수 있다. 이를 단순한 동기 함수 호출로 처리하면 작업이 막히거나 서비스 장애 때 진행 상태를 잃을 수 있다.
2. 핵심 패턴은 대기 조건과 시그널이다. 사람의 판단이 필요한 워크플로만 기다리게 하고, 응답이 도착하면 시그널로 결과를 전달해 실행을 이어간다.
3. Temporal은 실행 상태와 이벤트 이력을 관리하는 내구성 계층으로 소개된다. 데모에서는 주문 변경 승인을 기다리는 동안에도 다른 주문과 배송이 계속 진행됐다.
4. 에이전트 프레임워크와 내구성 계층은 함께 사용할 수 있다. 고객·차량 에이전트는 Google ADK, 배차 에이전트는 LangGraph를 사용하고 Temporal이 전체 실행에 연결됐다.
5. 사람의 개입 여부는 오판 비용과 승인 피로를 함께 고려해야 한다. 모든 판단을 사람에게 넘기면 반복적인 승인 요청이 형식적인 확인으로 흐를 수 있다.

🧩 배경과 문제 정의

이 발표는 아이스크림 배송 데모를 통해 인간의 판단이 필요한 다중 에이전트 시스템의 대기와 복구 문제를 설명한다. 고객, 차량, 배차 에이전트가 협업하는 가운데 고객의 주문 변경이나 고액 주문의 승인 요청이 발생한다.

문제는 사람이 시스템과 같은 속도로 응답하지 않는다는 점이다. 사람의 입력을 단순한 함수 호출로 기다리면 작업이 막힐 수 있고, 서비스가 내려가면 진행 상태를 잃을 수 있다. 발표자는 Temporal의 상태 관리와 내구성 있는 실행을 이용해 특정 작업만 기다리게 하고, 응답이나 재시작 이후에도 이어서 처리하는 방식을 제시한다.

🕒 시간순 섹션별 상세정리

1. 아이스크림 배송으로 소개하는 다중 에이전트 시스템

• 발표자는 자신이 근무하는 Temporal을 아이스크림 배송 데모로 보여준다. Ziggy의 가상 매장에서 차량·고객·배차 에이전트가 배송을 함께 조정한다. [00:56]
• Google ADK는 에이전트 활동을 조정하고, 통합된 Temporal은 배송 과정의 상태를 추적·관리한다. [01:31]
• Temporal UI에는 현재 실행의 이벤트 이력과 배송 활동을 묶는 부모 워크플로가 표시된다. [01:44]

2. 주문 변경 승인을 기다려도 다른 배송은 진행된다

• 고객이 주문 변경을 요청하면 해당 주문의 운전자 A가 업데이트를 기다린다. 이 변경은 시스템의 한 부분만 대기시키며 다른 작업은 계속 실행된다. [02:34]
• 사람이 변경을 승인하는 동안에도 다른 주문은 접수되고 처리된다. 승인된 변경은 해당 주문에 반영된다. [02:57]
• 변경 처리 후 운전자 A는 새 목적지인 Oracle Park로 이동한다. 발표자는 이를 Temporal과 ADK를 통합한 내구성 있는 실행 사례로 보여준다. [03:19]

3. 에이전트 루프와 운영 환경의 내구성

• 에이전트의 기본 구조는 추론·행동·관찰을 반복하는 루프이며, 이를 통해 자율적으로 작업을 수행한다. [03:57]
• 에이전트 하네스에 모델, 도구, 메모리, 가드레일, 보안 중 무엇이 포함되는지는 논쟁이 있다고 보여준다. [04:32]
• 하네스의 목적을 운영 환경에서 에이전트가 제대로 작동하도록 구조를 제공하는 것으로 보고, 여기에 내구성도 포함돼야 한다고 강조한다. [04:43]

4. 세 에이전트의 역할과 Temporal의 상태 관리

• 차량 에이전트는 Google Maps 같은 도구로 운전자 정보를 조사하고, 고객 에이전트는 Google Search 같은 도구로 주문을 조사한다. 배차 에이전트는 이 입력을 바탕으로 결정한다. [05:12]
• 사람의 입력이 들어오는 구조에서도 시스템이 계속 작동하려면 내구성이 필요하다. Temporal은 실패 처리와 상태 관리를 표준화하는 역할로 묶인다. [05:46]
• 발표자는 여러 언어에서 코드에 기본 구성 요소를 적용해 상태를 유지하는 시스템을 만들 수 있다고 보여준다. [06:09]

5. 워커·워크플로·액티비티의 구분

• 워커는 코드를 실행하고, 워크플로는 실행 단계와 상태를 추적한다. 에이전트 루프나 ADK 기반 실행을 워크플로 안에 둘 수 있다. [06:34]
• 액티비티는 외부와 상호작용하는 부분이며, 모델 호출과 도구 호출을 여기에 배치한다고 보여준다. [06:48]
• Temporal 소프트웨어는 무료 오픈소스로 자체 호스팅할 수 있고, 회사가 상태 관리를 맡는 서비스는 유료라고 안내한다. [07:08]

6. 사람을 비동기 응답 대상으로 다루는 핵심 패턴

• 사람의 입력을 단순한 함수 호출로 기다리면 호출이 막힐 수 있고, 서비스 장애 때 사람과의 상호작용 상태를 잃을 수 있다. [07:46]
• 대기 조건을 워크플로의 내구성 계층에 보존하고 시그널로 응답을 전달하면, 재시작 후에도 마지막 위치를 알 수 있으며 다른 작업은 계속 진행된다. [08:26]
• 발표자는 이 대기가 스레드를 붙잡지 않으며 타임아웃을 적용할 수 있다고 보여준다. 수백만 개의 워크플로를 대기시킬 수 있다는 확장성 주장도 제시한다. [09:03]

7. ADK 통합 코드와 대기 중 실행 방식

• 발표자는 다음 데모를 초기화하며 준비 과정의 어려움을 언급한 뒤 코드 설명으로 돌아간다. [10:00]
• ADK 통합에서는 모델을 Temporal 모델 클래스로 감싸고 도구에는 액티비티 도구를 적용하며, 워커에 Google ADK 플러그인을 전달한다고 보여준다. [10:44]
• 대기 조건은 해당 실행 흐름을 기다리게 하면서 다른 코루틴이나 워크플로의 실행을 허용한다. 시그널은 실행 중인 워크플로에 입력을 전달하고, 수행할 일이 없으면 워크플로는 대기 상태에 놓인다. [11:20]

8. LangGraph 통합과 에이전트가 사람에게 묻는 흐름

• 사람이 먼저 변경을 요청하는 경우에 이어, 에이전트가 사람의 판단을 요청하는 경우를 보여준다. Temporal이 여러 프레임워크와 함께 작동한다고 보여준다. [11:49]
• LangGraph 통합에서는 모델·도구 호출을 액티비티로 구성하고 실행 단계를 워크플로로 다룬다. 발표자는 워크플로의 결정성과 액티비티의 비결정성을 구분한다. [12:32]
• LangGraph의 interrupt로 사람의 개입을 요청하고, 대기 조건과 시그널로 응답을 연결한다. 데모는 고객·차량 에이전트에 ADK, 배차 에이전트에 LangGraph를 사용한다. [13:22]

9. 고액 주문만 사람의 승인을 기다리게 한다

• 고액 주문을 넣자 주문별·프레임워크별로 분리된 자식 워크플로에서 평가가 진행되고, 고객·차량 에이전트의 결과가 배차 에이전트에 전달된다. [14:11]
• 배차 에이전트는 사람의 판단이 필요하다고 보고 대기 상태에 들어간다. 발표자는 사람의 응답이 수분, 수일 또는 수주 걸릴 수 있다고 보여준다. [14:40]
• 해당 작업이 기다리는 동안에도 화면의 다른 차량은 계속 이동한다. [14:51]

10. 워커 중단 중 접수한 승인과 재시작 후 복구

• 발표자는 워커를 종료해 연결이 끊긴 상태를 만든 뒤 승인을 입력한다. 이벤트는 워커와 별도의 저장소에서 추적되고 대기열에 들어간다고 보여준다. [15:31]
• 워커를 다시 실행하면 이벤트 로그를 재생해 마지막 실행 상태를 복원한다. 발표자는 이전 작업을 처음부터 다시 수행하는 것과 이력 재생을 구분한다. [15:58]
• 복원된 실행은 대기 중 접수된 승인을 반영해 주문을 배정하고 배송을 완료한다. 이를 복잡한 분산 시스템에서의 내구성과 복구 사례로 정리한다. [16:26]

11. 사람의 개입 기준과 발표의 마무리

• 사람의 개입 여부는 오판 비용, 특히 보안상의 영향을 고려해 업무별로 판단해야 한다. 동시에 반복되는 질문에 무조건 승인하는 알림 피로도 균형 있게 고려해야 한다. [17:29]
• 사람이 먼저 요청하든 에이전트가 먼저 요청하든, 대기 조건으로 워크플로를 기다리게 하고 사람의 시그널로 실행을 이어가는 패턴은 같다. 여러 프레임워크에서도 이를 적용할 수 있다고 정리한다. [18:03]
• 마지막으로 QR 코드의 Temporal 자료와 GitHub 데모를 안내하고, 슬라이드는 추후 저장소에 연결하겠다고 드러낸다. 청중의 에이전트 구축 사례와 질문을 요청하며 발표를 마친다. [18:43]

🧾 결론

• 사람의 개입은 전체 시스템을 멈추는 절차가 아니라, 특정 작업의 상태를 보존하며 기다리는 과정으로 설계할 수 있다.
• 데모의 복구 원리는 이벤트 이력을 재생해 마지막 상태를 복원하고, 워커 중단 중 접수된 승인 결과를 다음 단계에 반영하는 것이다.
• 에이전트의 추론·행동·관찰 루프를 운영 환경에 배치하려면 상태 관리와 실패 처리도 함께 설계해야 한다.
• 사람에게 확인할 시점은 업무별 오판 비용에 따라 정하고, 불필요한 승인 요청이 누적되는지도 살펴야 한다.

📈 투자·시사 포인트

• 에이전트 운영 도구를 평가할 때는 자율적인 판단 능력과 함께 장기 대기, 상태 보존, 장애 복구를 어떻게 지원하는지 확인필요가 있다.
• 영상은 ADK와 LangGraph를 함께 사용하는 사례를 제시한다. 여러 프레임워크의 실행을 공통 상태 관리 계층으로 연결하는 방식이 기술 평가의 한 관점이 된다.
• Temporal은 무료 오픈소스 자체 호스팅과 유료 관리형 서비스를 소개한다. 도입 검토에서는 직접 운영할 부담과 관리형 서비스의 비용을 비교할 수 있다.
• 영상에는 매출, 수익성, 시장 규모나 가격 비교 자료가 없다. 이 데모만으로 기업 가치나 투자 수익을 판단할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 발표자는 자신이 근무하는 Temporal을 소개한다고 밝힌다. 데모에서 제시한 장점과 실제 운영 환경의 성능·비용은 구분해 확인필요가 있다.
• 수백만 개의 워크플로가 대기할 수 있다는 설명은 있지만, 이를 뒷받침하는 부하 테스트 조건이나 자원 사용량은 제공되지 않는다.
• 장애 시연은 워커를 중단하고 다시 시작하는 경우다. 상태 저장소 장애, 중복 승인, 외부 도구 호출의 재시도에 관한 구체적인 동작은 영상에서 확인되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 에이전트 흐름에서 사람의 응답을 기다리는 지점을 찾고, 그 대기가 다른 작업까지 막는지 점검한다.
• 주문이나 요청별로 대기 상태를 분리하고, 사람의 응답을 시그널로 전달하는 작은 실행 흐름을 검증한다.
• 승인을 기다리는 워커를 중단한 뒤, 중단 중 승인을 접수하고 재시작했을 때 다음 단계로 이어지는지 확인한다.
• 사람의 응답 제한 시간과 시간 초과 뒤 처리 방식을 정한다. 영상에서 소개한 타임아웃 기능의 적용 방법도 확인한다.

❓ 열린 질문

• 어떤 판단에서 오판 비용이 충분히 높아 사람의 승인이 필요하며, 그 기준은 누가 정할 것인가?
• 사람이 수일 또는 수주 동안 응답하지 않으면 해당 작업을 언제 만료하거나 다른 담당자에게 넘길 것인가?
• 중복되거나 뒤늦게 도착한 승인 시그널은 어떤 규칙으로 처리해야 하는가?