26. Subagent 돌렸는데 결과가 안 돌아올 때

Subagent를 띄웠는데 한참이 지나도 결과가 안 보이면, 실제로는 “아예 실패”보다 어디에서 결과를 받아야 하는지 흐름이 어긋난 경우가 더 많다. OpenClaw의 subagent는 메인 대화 안에서 바로 이어서 답하는 방식이 아니라, 별도 세션에서 실행된 뒤 완료되면 다시 requester 쪽으로 announce되는 구조다. 그래서 지금 막힌 지점을 빨리 가르는 핵심은 단순하다. 정말 실행이 안 된 건지, 실행은 됐지만 다른 방식으로 결과를 기다리고 있는 건지 먼저 나눠 봐야 한다.

급할 때는 길게 추측하지 말고, spawn 됐는지 → 완료됐는지 → announce를 어디서 받아야 하는지 이 세 가지만 확인하면 된다. 이 순서로 보면 대부분 3~5분 안에 범위가 갈린다.

칠판 치트시트

subagent는 메인 답변 안에서 즉시 끝나는 작업이 아니다

먼저 spawn 성공 여부를 본다

그다음 완료 여부를 본다

완료됐다면 announce가 돌아올 채널/세션을 확인한다

조급하게 새 subagent를 여러 개 더 띄우기 전에 기존 run부터 확인한다

flowchart LR
A[Subagent 실행] --> B{spawn 성공?}
B -- 아니오 --> C[입력/권한/파라미터 수정]
B -- 예 --> D{완료됐는가?}
D -- 아니오 --> E[실행중 로그/타임아웃 확인]
D -- 예 --> F{announce가 돌아올 위치 확인}
F -- 다름 --> G[요청자 세션/채널에서 확인]
F -- 맞음 --> H[정상 수신]

가장 빨리 확인하는 순서

1) 정말로 spawn이 됐는지 먼저 본다

Subagent는 non-blocking으로 시작되고, 먼저 run id가 반환된다. 그래서 첫 확인 포인트는 “결과가 왔냐”가 아니라 **“애초에 시작은 됐냐”**다.

이 단계에서 자주 생기는 착시는 아래 둘이다.

사용자는 긴 응답을 기대했는데 실제로는 백그라운드 run만 시작된 상태
spawn은 실패했는데 메인에서 대기만 하다가 “안 돌아온다”고 느끼는 상태

즉, 첫 질문은 이거다.

run id가 생성됐는가
spawn 단계에서 경고나 오류가 있었는가

2) 완료됐는지와 아직 실행 중인지를 나눈다

OpenClaw 공식 문서 기준으로 subagent는 별도 세션에서 실행된다. 그래서 결과가 아직 없는 이유는 크게 두 가지다.

아직 실행 중이다
이미 끝났지만 announce를 내가 보고 있는 자리에서 안 보고 있다

이 둘을 분리하지 않으면, 아직 도는 작업을 실패로 오해하거나 이미 끝난 작업을 또 띄우는 실수가 생긴다.

실무에서는 여기서 아래만 보면 충분하다.

status가 running인지 completed인지
timeout이 있었는지
실패라면 어느 단계에서 멈췄는지

3) 완료됐다면 “어디로 돌아오는 구조인지”를 본다

subagent 결과는 원래 requester chat channel로 announce되는 구조다. 그래서 메인 세션을 보고 있다고 생각했는데, 실제로는 다른 채널 흐름이나 다른 세션 컨텍스트에서 기다리고 있는 경우가 있다.

쉽게 말하면,

subagent는 백그라운드에서 따로 일하고
끝나면 requester 쪽으로 돌아오는데
내가 지금 다른 창, 다른 흐름, 다른 세션 문맥만 보고 있으면 결과가 안 온 것처럼 느껴질 수 있다.

이 단계에서는 “subagent가 어디서 태어났는지”를 다시 보는 게 제일 빠르다.

왜 이런 일이 자주 생기나

원인 1) subagent를 일반 동기 작업처럼 기대함

subagent는 메인 답변을 길게 이어 쓰는 도구가 아니라, 백그라운드 분리 실행기다. 그래서 “지금 이 답변 안에서 바로 결과가 이어져야 한다”고 기대하면 체감이 어긋난다.

원인 2) 실행 상태와 전달 위치를 섞어 봄

실행은 정상인데 전달 위치를 잘못 보고 있으면 실패처럼 느껴진다. 반대로 전달 위치만 기다리다가 실제 실행 실패를 놓치기도 한다.

원인 3) 기존 run 확인 없이 새 run을 계속 띄움

이 경우는 문제를 더 크게 만든다. 원인 파악 전 새 subagent를 계속 띄우면 어떤 run의 결과가 어떤 요청에 대응하는지 흐려진다.

3분 복구 루틴

A. 시작 단계 확인

spawn 시 run id가 생성됐는지 본다
파라미터 경고가 있었는지 본다
model/thinking/timeout override가 비정상적이지 않은지 본다

B. 진행 단계 확인

아직 running인지 확인한다
timeout이 너무 짧지 않은지 본다
느린 작업인데 메인이 성급하게 실패로 단정하지 않았는지 본다

C. 완료 단계 확인

완료 후 announce가 requester 쪽으로 돌아오는 구조인지 다시 확인한다
결과를 메인 채널에서 받아야 하는지, thread/session 바인딩이 있는지 본다
필요하면 해당 run의 info/log/history로 결과 존재 자체를 먼저 확인한다

현장 미니 사례

사례 A) 실행은 끝났는데 메인 답변에서만 기다림

상황: subagent를 띄워 놓고 같은 답변 안에서 긴 결과가 바로 이어질 거라고 기대함
실제: subagent는 별도 세션에서 끝난 뒤 requester 쪽으로 announce되는 구조였음
해결: 실행 완료 여부와 announce 복귀 위치를 분리해서 확인
결과: “안 왔다”가 아니라 “다른 방식으로 돌아오는 중이었다”로 정리됨

사례 B) 첫 run 확인 없이 같은 작업을 두 번 더 띄움

상황: 1분 안에 결과가 안 보여서 같은 작업을 다시 두 번 실행함
실제: 첫 run은 아직 진행 중이었고, 이후 run까지 겹치며 로그 확인이 더 어려워짐
해결: 기존 run의 상태부터 확인하고, timeout·완료·announce 순서로 재점검
결과: 중복 실행을 멈추고 원래 run에서 결과 회수

이렇게 보면 덜 헷갈린다

정상 흐름

sessions_spawn으로 run 시작
subagent가 자기 세션에서 실행
완료 후 requester 쪽으로 announce
메인이 결과를 검토해 이어서 전달

비정상처럼 느껴지는 흐름

run은 시작됐는데
사용자는 메인 답변 안 즉시 결과를 기대
announce가 돌아올 위치를 안 보고 있음
그래서 “안 돌아왔다”고 판단

상황별 바로 다음 글 10선

지금 바로 적용할 체크리스트

spawn 성공 여부부터 확인했다
running / completed / failed를 구분했다
announce가 돌아올 requester 세션을 다시 확인했다
첫 run 확인 없이 중복 spawn하지 않았다
필요하면 info/log/history로 결과 존재를 먼저 확인했다

한 줄 결론

Subagent 결과가 안 돌아오는 문제는 대개 모델이 멈춘 게 아니라, 실행 상태와 결과 복귀 위치를 섞어 본 문제다. 먼저 시작됨 → 끝남 → 어디로 돌아옴 순서로 나누면 훨씬 빨리 풀린다.

AI 활용 고지

이 문서는 생성형 AI를 활용해 초안을 구성했고, OpenClaw 공식 문서 기준으로 구조와 표현을 점검해 정리했다.

일하는 ai

탐색기