AX LABS
← 블로그 에이전트 제품 설계

Subagent는 큐로 다뤄야 한다

위임보다 중요한 것은 join과 cancel이다

AX LABS 5분 읽기

AI agent를 업무에 붙이면 처음에는 대화가 잘 되는지가 관심사다. 곧 다른 문제가 보인다. supervisor가 subagent 하나를 불러 놓고 끝날 때까지 멈춘다. 사용자는 다음 지시를 못 한다. 중간 결과도 못 본다. 잘못 간 작업을 끊지도 못 한다. 이 구조는 데모에서는 조용하지만 운영에서는 병목이 된다.

Subagent 호출은 함수 호출이 아니다

Subagent를 함수처럼 생각하면 supervisor는 blocking call의 포로가 된다. “조사해 와”, “검증해”, “초안 만들어” 같은 작업은 시간이 길고, 실패 가능성이 있고, 중간에 방향이 바뀐다. 그래서 subagent 호출은 return 값을 기다리는 함수 호출이 아니라, 상태를 가진 원격 작업으로 다뤄야 한다.

LangChain의 async subagents 문서는 supervisor가 background task를 시작하면 즉시 task ID를 받고, 이후 check·update·cancel 도구로 상태를 관리한다고 설명한다. 이 구조는 subagent run을 supervisor 메시지 히스토리에만 묻어 두지 않고 별도 상태 채널에 저장한다는 점이 핵심이다. context compaction이 일어나도 task ID가 사라지면 안 되기 때문이다. (docs.langchain.com)

운영형 agent 설계의 단위는 prompt가 아니라 task ID다.

비동기 큐는 네 가지 동사를 가져야 한다

Supervisor가 remote subagent를 안정적으로 다루려면 최소 동사는 네 개다. delegate, join, update, cancel이다. 이름은 프레임워크마다 달라도 의미는 같아야 한다.

동사 supervisor의 책임 운영상 의미
delegate 작업 설명과 제약을 넘기고 task ID를 받는다 대기하지 않고 다음 상호작용을 계속한다
join task ID로 완료 상태와 산출물을 회수한다 결과를 합치고 의사결정한다
update 같은 task ID에 추가 지시를 보낸다 중간 방향 전환을 기록한다
cancel 더 이상 유효하지 않은 작업을 중단한다 비용과 오류 전파를 막는다

OpenAI의 Background mode도 긴 작업을 비동기로 실행하고 response object를 polling하며, cancel API로 중단할 수 있는 구조를 둔다. A2A specification 역시 task 조회, task 구독, task cancel, terminal state를 명시한다. 서로 다른 제품의 문법은 다르지만 방향은 같다. 장기 실행 agent는 호출-응답이 아니라 작업 생명주기로 관리된다. (platform.openai.com)

cancel 없는 delegation은 통제가 아니다

현장에서 가장 위험한 설계는 “여러 subagent에게 나눠 시키면 빠르다”에서 멈추는 것이다. 병렬화는 쉽다. 통제가 어렵다. 같은 데이터를 여러 agent가 따로 해석하고, 이미 틀린 가정 위에서 작업을 계속하고, 사용자가 조건을 바꿨는데도 이전 작업이 살아 있으면 supervisor는 산출물을 수습하는 역할로 전락한다.

A2A JavaScript SDK 예시는 cancelTask를 executor에 구현하고, 실행 루프가 task ID별 cancellation set을 확인한 뒤 canceled 상태 이벤트를 발행하는 패턴을 보여준다. cancel은 UI 버튼이 아니다. worker 내부에 checkpoint를 심고, 중단 가능한 상태를 정의하고, 최종 상태를 남기는 실행 계약이다. (github.com)

Claude Code의 subagent와 hooks 문서도 같은 교훈을 준다. subagent는 독립적으로 작업하고 결과를 반환하며, hooks는 tool use와 subagent stop 같은 이벤트를 가로채 통제 지점을 만든다. agent harness는 모델 바깥의 작업 상태, 권한, 이벤트, 관측성을 포함해야 한다. (code.claude.com)

참고와 다음 행동

Async subagent task queue는 agent를 더 복잡하게 만드는 장식이 아니다. supervisor가 일을 맡기고, 잊지 않고, 다시 합치고, 필요하면 끊는 운영 장치다. AX Ops 관점에서는 먼저 업무별 subagent를 정하는 것이 아니라 task lifecycle부터 그린다. 어떤 작업이 비동기인지, task ID를 어디에 저장할지, join 기준은 무엇인지, cancel이 안전한 지점은 어디인지부터 정해야 한다.

참고:

Agent 제품을 PoC가 아니라 운영 시스템으로 만들려면 task queue, 상태 저장, cancellation contract를 먼저 설계해야 한다. 이 설계가 AX Ops의 agent 운영 골격이다. AX Ops 방법론 →