큰 문제를 새로 열린 agent에게 넘긴다

부모 agent의 딜레마

Claude Code에게 "이 10만 줄 Rust 저장소가 동시성을 어떻게 처리하는지 알아봐 줘"라고 한다고 상상해보세요. 직관적인 방법: 스스로 ls, cat, grep으로 주 context에서 한 번 훑어봅니다.

문제: 이 탐색 과정에서 messages[]에 30개의 tool_result가 쌓이고, 각각이 수천 token입니다. 실제로 답을 작성하기 시작할 때는 context가 탐색 과정으로 가득 차서—몇 단계 더 하면 한도에 달하고, 답도 엉망이 됩니다.

s04의 해법: 탐색 작업을 새로운 agent에게 넘깁니다. 새 agent는 messages=[]로 시작해 스스로 탐색하고, 최종적으로 부모 agent에게 summary만 반환합니다. 부모의 context에는 "task 도구를 한 번 호출했고 결과는 XXX"라는 한 줄만 추가됩니다. 깔끔합니다.

def run_subagent(prompt: str) -> str:
    sub_messages = [{"role":"user", "content": prompt}]  # 완전히 새로운 context
    for _ in range(30):  # 안전 상한, 폭주 방지
        response = client.messages.create(..., messages=sub_messages, tools=CHILD_TOOLS, ...)
        ...
    # 마지막 텍스트만 반환, 중간 추론은 모두 버립니다
    return "".join(b.text for b in response.content if hasattr(b, "text"))

부모/자식 context 비교

이 widget은 실제 작업을 시뮬레이션합니다: "이 저장소에서 deprecated API를 사용하는 모든 곳을 나열해줘". 두 가지 전략으로 실행할 수 있습니다: (A) 부모 agent가 직접 하기; (B) subagent를 spawn하기. 두 context의 최종 크기를 비교하세요.

CHILD_TOOLS: 자식 agent가 가질 수 있는 도구

s04 구현에서 놓치기 쉬운 세부 사항이 있습니다: 자식 agent는 task 도구를 가지지 않습니다.

# 자식 agent는 기본 도구만 가질 수 있고, 손자를 spawn할 수 없습니다
CHILD_TOOLS = [bash, read_file, write_file, edit_file]

# 부모 agent는 task 도구를 하나 더 가집니다
PARENT_TOOLS = CHILD_TOOLS + [task]

왜냐고요? 재귀적 파견이 트리 구조로 폭발하는 것을 막기 위해서입니다. 하나의 subagent가 4개의 sub-subagent를 spawn하고, 몇 번 반복하면 수십 개의 동시 호출이 생겨 token과 API 속도 제한 모두 버티지 못합니다. s04의 규칙: spawn은 평면적, 부모→자식 한 층만. 실제 Claude Code 구현에서도 마찬가지—Task tool 안에서 Task tool을 다시 호출하는 것이 금지되어 있습니다.

알 수 있는 것과 없는 것

책임 정리: 아래 질문들 중 어떤 것이 T이고 어떤 것이 F일까요?