Agents Are Going Async

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Deep Agents는 사용자와 대화하는 오케스트레이터와 장기 작업을 병렬 수행하는 비동기 서브에이전트를 분리해, 응답성과 작업 처리 능력을 함께 높이는 구조를 도입했다.

📌 핵심 요약

• 기존 ReAct 루프에서는 긴 도구 호출이 루프를 막아 다른 작업이 대기한다. 글은 Claude Code, OpenAI의 dots, DeepSeek Harness를 사례로 들며, 사용자 대응과 백그라운드 작업을 분리하는 구조가 확산하고 있다고 설명한다.
• Deep Agents의 비동기 서브에이전트는 작업을 시작한 뒤 즉시 제어를 반환하고 백그라운드에서 독립적으로 실행된다. 오케스트레이터는 자신의 루프가 바쁘지 않을 때 사용자에게 응답할 수 있으며, 전체 작업 묶음이 끝나기를 기다리지 않고 새 작업을 시작할 수 있다.
• 오케스트레이터는 start_async_task, check_async_task, update_async_task, cancel_async_task, list_async_tasks로 작업을 관리한다. 실행 중 지시를 갱신할 때 update_strategy의 기본값인 interrupt는 현재 실행을 중단하고 새 지시로 재시작하며, enqueue는 현재 실행이 끝난 뒤 후속 지시를 처리한다.
• 미완료 작업은 오케스트레이터의 시스템 프롬프트에 표시된다. 작업 결과는 오케스트레이터가 실행 중이면 다음 모델 호출 전에 수신하고, 유휴 상태면 새 실행을 깨우며, 승인 대기 중이면 사용자가 답한 뒤 전달된다. 서브에이전트 자체의 승인은 해당 서브에이전트 스레드에서 처리한다.
• 비동기 서브에이전트는 Python·JavaScript용 Deep Agents와 Managed Deep Agents에서 제공된다. Managed Deep Agents에서는 async: True로 설정하며, 제공되는 각 에이전트에 general-purpose 서브에이전트의 비동기 사본도 추가된다. 작업 알림은 베타여서 API가 바뀔 수 있고, async-deep-agents 저장소에는 Python·TypeScript 예제가 있다.

🧩 주요 포인트

1. 긴 호출로 막히는 ReAct 루프 → 사용자 대화를 담당하는 오케스트레이터와 병렬 작업자를 분리해, 하나의 루프 길이 대신 백그라운드 작업자 수에 따라 처리 범위를 넓히는 구조.
2. 작업 관리 도구와 interrupt·enqueue의 구분 → 사용자에게 응답하는 기능과 실행 중 작업의 방향을 수정하는 기능을 별도로 다루며, 즉시 수정과 완료 후 추가 작업을 구별.
3. 실행·유휴·승인 대기에 따른 결과 전달과 베타 API → 오케스트레이터 상태별 알림 처리를 고려해야 하며, Deep Agents 도입 시 작업 알림 API의 변경 가능성도 검토할 필요.

🧠 상세 정리

1. 더 큰 목표를 수행하는 에이전트의 요구

글은 큰 프로젝트를 맡을 때마다 사라졌다가 완료 후에만 돌아오는 비서실장의 비유로, 에이전트에 필요한 응답성과 생산성을 설명한다. 좋은 비서실장이 백그라운드에서 프로젝트를 진행하면서도 연락을 받고 상황을 공유하듯, 에이전트도 이전 대화의 맥락을 유지하며 새 지시에 대응하고 여러 장기 작업을 함께 진행해야 한다는 주장이다. 그러나 기존 ReAct 루프에서는 긴 도구 호출 하나가 전체 루프를 막아 다른 작업이 뒤에서 기다리므로 두 요구를 함께 충족하기 어렵다고 본다. 글은 Claude Code의 기본 백그라운드 서브에이전트, OpenAI의 dots가 사용하는 백그라운드 작업자, 사용자와 대화하는 라우터와 병렬 작업자를 둔 DeepSeek Harness를 이러한 구조 전환의 사례로 제시한다.

2. 오케스트레이터와 비동기 작업자의 분리

Deep Agents가 도입한 비동기 서브에이전트는 사용자와 대화하고 맥락을 정리하는 오케스트레이터와, 오래 걸리는 작업을 수행한 뒤 결과를 보고하는 백그라운드 작업자를 분리한다. 기존에는 모델이 도구를 호출하면 결과가 돌아올 때까지 기다렸지만, 비동기 호출은 asyncio.create_task나 아직 기다리지 않는 Promise처럼 즉시 제어를 반환하고 작업을 독립적으로 진행한다. 이에 따라 서브에이전트가 오케스트레이터의 루프를 붙잡지 않으며, 사용자는 오케스트레이터 자신의 루프가 바쁘지 않을 때 접근할 수 있다. 오케스트레이터는 전체 작업 묶음이 끝나기를 기다리지 않고 들어오는 작업을 추가로 시작하며, 글은 처리할 수 있는 업무 범위가 단일 루프의 길이보다 백그라운드 작업자 수에 따라 커진다고 설명한다.

3. 다섯 가지 도구와 실행 중 지시 변경

오케스트레이터는 다섯 가지 도구로 비동기 서브에이전트의 생명주기를 관리하며, 작업을 시작하거나 상태를 확인하는 것 외에 실행 중 지시 변경과 취소도 할 수 있다. start_async_task는 별도 스레드에서 서브에이전트를 시작하고 즉시 반환하며, check_async_task는 상태와 완료된 결과를 가져오고, list_async_tasks는 모든 작업과 상태를 나열한다. update_async_task는 실행 중인 작업에 새 지시를 보내고, cancel_async_task는 실행 중인 작업을 중단한다. 지시 변경 방식은 서브에이전트 정의의 update_strategy로 정하며, 기본값 interrupt는 현재 실행을 멈추고 새 지시로 재시작하므로 Postgres를 사용하라는 수정에 적합하다. enqueue는 현재 실행이 끝날 때까지 후속 지시를 보류하므로 작업 완료 후 테스트를 실행하라는 추가 요청에 적합하며, 이러한 작업 조정은 사용자와 오케스트레이터 사이의 접근 가능성과 별개로 다뤄진다.

4. 오케스트레이터 상태에 따른 결과 알림

완료되지 않은 모든 작업은 오케스트레이터의 시스템 프롬프트에 나열되므로, 오케스트레이터는 진행 중인 작업을 파악하고 check_async_task로 상태를 조회할 수 있다. 서브에이전트가 스스로 결과를 보고할 수도 있으며, 오케스트레이터가 실행 중이라면 각 모델 호출 전에 미완료 작업을 확인해 진행 도중 결과를 받아들인다. 오케스트레이터가 유휴 상태일 때는 서브에이전트가 새 실행을 깨우고, 승인 대기 중이라면 기존 승인을 그대로 둔 채 사용자가 답한 뒤 결과를 전달한다. 서브에이전트 자체가 승인을 필요로 하면 waiting 상태로 표시되고, 사용자는 오케스트레이터를 중단시키지 않고 해당 서브에이전트의 스레드에서 응답한다. Managed Deep Agents의 Slack 환경에서는 이 승인 요청이 원래 스레드에 게시된다고 설명한다.

5. 서브에이전트에서 일반 도구로의 확장 전망

글은 비동기 실행과 결과 전달의 패턴이 서브에이전트에만 머물지 않고 도구 전반으로 확장될 것으로 예상한다. 그 근거로 OpenAI가 최근 추가한 비동기 도구 호출 지원을 들며, 모델이 도구를 호출한 뒤에도 계속 작업하고 애플리케이션이 이후 요청에서 결과를 돌려줄 수 있다고 설명한다. 이는 느린 호출마다 결과를 기다리는 기존 루프와 달리, 도구 호출 시점과 결과를 받아들이는 시점을 분리하는 방식이다. 다만 도구 전반으로의 일반화는 글쓴이의 전망이며, 본문이 구체적으로 설명한 Deep Agents의 기능은 비동기 서브에이전트와 이를 관리하는 도구 및 알림 동작이다.

6. 사용 환경과 베타 단계의 제약

비동기 서브에이전트는 Python과 JavaScript용 Deep Agents 및 Managed Deep Agents에서 사용할 수 있으며, Managed Deep Agents에서는 서브에이전트 정의에 async: True 필드를 추가해 활성화한다. 본문의 예제는 define_deep_agent로 research-assistant를 정의하고 openai:gpt-5.5 모델 아래 researcher 서브에이전트를 백그라운드 조사 작업에 배치한다. Managed Deep Agents에서 제공되는 각 에이전트에는 general-purpose 서브에이전트의 비동기 사본도 추가되어, 실행 시점에 위임 작업을 포그라운드나 백그라운드 중 어디서 수행할지 결정할 수 있다. 작업 알림은 베타이므로 API가 바뀔 수 있으며, async-deep-agents 저장소에는 researcher와 coder 서브에이전트를 사용하는 supervisor의 Python 및 TypeScript 동작 예제가 제공된다.

🧾 핵심 주장 / 시사점

• 비동기 서브에이전트는 사용자와의 대화가 장기 작업 완료에 종속되는 문제를 줄이지만, 오케스트레이터 자신의 루프가 바쁜 경우까지 즉시 응답을 보장하는 것은 아니다.
• interrupt와 enqueue의 구분은 실행 중 작업의 방향을 바로 바꾸는 요청과 현재 작업 이후에 수행할 요청을 서로 다른 방식으로 처리하도록 한다.
• 백그라운드 실행만으로 구조가 완성되는 것은 아니며, 진행 중 작업의 가시성, 상태별 결과 전달, 별도 승인 처리가 함께 사용자 대응과 작업 진행을 뒷받침한다.

✅ 액션 아이템

• Deep Agents 적용 대상에서 긴 도구 호출로 ReAct 루프가 막히는 작업과 병렬 실행할 작업을 구분.
• 실행 중 지시 변경의 성격에 따라 update_strategy의 interrupt와 enqueue 적용 방식을 검토.
• Managed Deep Agents 도입 시 실행·유휴·승인 대기 상태의 결과 전달과 작업 알림 베타 API의 변경 가능성을 검토.

❓ 열린 질문

• Deep Agents에서 백그라운드 작업으로 분리할 우선 대상은 어떤 장기 작업인가?
• 실행 중 지시 변경 가운데 interrupt로 즉시 반영할 요청과 enqueue로 완료 후 처리할 요청은 각각 무엇인가?
• 작업 알림이 베타인 상황에서 API 변경 가능성은 Managed Deep Agents 도입 판단에 어떤 영향을 주는가?