Claude : 에이전트 8개를 띄웠는데, 21개가 돌아가고 있었다

AI 학습 커리큘럼 사이트에 39개 레슨 페이지를 채우려고 백그라운드 에이전트 8개를 병렬로 돌렸다. 그런데 완료 알림 하나가 이상한 문장을 남겼고, 확인해보니 에이전트가 스스로를 두 배 넘게 늘려놓은 상태였다.

 

내가 띄운 에이전트: 8
실제로 돌던 에이전트: 21
최종 산출물: 39 files (전부 정상)

 

기획자용 AI 학습 로드맵을 웹사이트로 만드는 중이었다. 전체 39개 모듈 중 1-1 하나는 손으로 다 만들어서 디자인·구조 템플릿을 확정해뒀고, 남은 38개를 Phase별로 8개 배치로 나눠 각각 백그라운드 에이전트에게 맡겼다. 지시는 단순했다. 이 템플릿을 그대로 따라서, 네가 배정받은 파일들을 WebSearch로 참고문헌 찾아가며 직접 써라.
여기까지는 흔한 병렬 작업 위임이었다. 문제는 첫 완료 알림에서 시작됐다.

 

수상한 한 줄
Phase 2(2-1~2-7) 담당 에이전트가 제일 먼저 완료 상태로 돌아왔다. 그런데 결과 메시지가 이랬다.
에이전트 응답 원문: I'll wait for the running agents to report back before launching the remaining two (2-6, 2-7).
직역하면 나머지 두 개(2-6, 2-7)를 띄우기 전에, 지금 돌고 있는 에이전트들이 보고할 때까지 기다리겠다는 뜻이었다.
이상했다. 나는 이 에이전트한테 네가 직접 써라라고 했지, 일부는 또 다른 에이전트한테 맡겨라라고 한 적이 없었다. 게다가 이 에이전트가 실제로 쓴 도구 호출 수는 10번뿐이었다. 파일 7개를 WebSearch와 Write로 직접 완성하려면 최소 수십 번은 필요한데, 숫자가 너무 적었다.

 

21개, 왜?
ListAgents로 전체 목록을 조회했다. 내가 직접 띄운 건 8개인데, 화면에는 21개가 running 상태로 떠 있었다.
원인은 명확했다. 일부 에이전트가 이건 병렬로 처리하는 게 더 빠르겠다고 스스로 판단해서, 자기한테 배정된 파일 하나하나마다 또 다른 서브 에이전트를 호출한 것이었다. 범용(general-purpose) 에이전트에게는 Agent 툴 자체를 쓸 권한도 있었기 때문에 가능한 일이었다. 나는 직접 써라고만 했지 다른 에이전트를 부르지 마라고 명시적으로 막지는 않았다.
이게 왜 위험했냐면, 내가 직접 띄운 에이전트가 완료되면 나한테 알림이 오지만, 그 안에서 파생된 손자뻘 에이전트의 완료 알림은 나한테 안 가고 자기를 띄운 부모 에이전트한테 간다. 부모가 이미 완료 상태로 멈춰 있으면, 그 알림이 부모를 다시 깨워야만 결과가 이어져 처리된다. 안 깨우면 결과가 조용히 묻힐 수 있는 구조였다.

 

시퀀스
Dispatch: Phase 1 나머지부터 Phase 8까지, 8개 배치로 나눠 에이전트 병렬 투입.
First Return: Phase 2 담당이 완료로 복귀. 결과 문장에서 위화감 포착. 도구 호출 수(10회)와 작업량이 안 맞음.
Audit: ListAgents 조회 결과 8개가 아니라 21개 실행 중 확인.
Correction: 8개 전체에 서브 에이전트 스폰 금지, 이미 생성된 파일은 인정하고 나머지는 직접 작성하라는 정정 메시지 일괄 발송.
Resolution: 모든 에이전트 정상 완료. 39개 파일 전부 구조 검증(참고문헌 20개씩, 앵커 링크, 페이저) 통과.

 

그런데 왜 안 터졌나
결과적으로 실질적인 피해는 없었다. 각 에이전트와 그 서브 에이전트가 모듈 ID 기준으로 파일명이 겹치지 않게 작업했기 때문에, 중첩 스폰이 있었어도 덮어쓰기나 충돌은 발생하지 않았다. 벌어진 건 순수한 비효율이었다. 계획보다 훨씬 많은 에이전트가 돌면서 토큰을 추가로 태웠고(일부 부모 에이전트는 최종적으로 15만에서 22만 토큰까지 소모했다), 내가 흐름을 눈으로 추적하기 어려워졌다.

 

배운 것
위임형 에이전트에게 병렬로 하지 마는 암묵적 기대가 아니라 명시적 제약으로 써야 한다. 툴 접근 권한이 있으면 쓸 수 있다는 걸 전제해야 한다.
에이전트의 완료 메시지에서 애매하거나 의도와 안 맞는 문장이 나오면, 일단 완료됐으니 넘어가자가 아니라 즉시 실제 상태를 조회해서 검증한다.
예상 작업량과 실제 도구 호출 수(tool_uses)의 괴리는 꽤 신뢰할 만한 이상 신호였다.
병렬 작업을 파일 단위로 쪼갤 때 네임스페이스가 겹치지 않게 설계해두면, 오케스트레이션이 예상과 다르게 흘러가도 최소한 데이터 손상까지는 안 간다.