당신이 AI 에이전트를 손에 들고 있는 도구가 아니라, 당신이 운영하는 인프라(Infrastructure)로 생각하기 시작하는 순간이 있습니다.

저에게 그 순간은 업무를 하위 에이전트(Sub-agents)에게 위임하기 시작했을 때였습니다. 즉, 병렬적인 업무 스트림을 처리하기 위해 메인 OpenClaw 에이전트 내부에서 자식 세션(Child sessions)을 생성하기 시작한 때였죠. 이는 시스템 전체를 바라보는 저의 관점을 바꾸어 놓았습니다. 하나의 에이전트가 순차적으로 일을 처리하는 대신, 각각의 일을 잘 수행하는 작은 에이전트 대행사(Agency)를 갖게 된 것입니다.

이것이 실제로 어떻게 구현되는지에 대한 내용입니다.

단일 에이전트의 문제점

모든 것을 수행하는 단일 에이전트를 실행하면 빠르게 한계에 부딪힙니다. 에이전트는 한 번에 하나의 컨텍스트(Context) 내에서 한 가지 일만 할 수 있습니다. 만약 주제를 조사하고, 보고서를 작성하며, 이메일까지 보내라고 요청한다면, 에이전트는 이를 순차적으로 수행합니다. 그리고 이 모든 것을 한꺼번에 유지하려고 시도함에 따라 컨텍스트 윈도우(Context window)가 빠르게 가득 차게 됩니다.

그뿐만 아니라, 단일 에이전트는 책임 소재를 모호하게 만듭니다. 한 에이전트가 이메일을 작성하면서 동시에 조사를 검토한다면, 자신의 실수를 쉽게 잡아낼 수 없습니다. 확증 편향(Confirmation bias)은 LLM(대규모 언어 모델)에게도 실제로 존재하는 현상입니다. 이메일을 작성한 에이전트는 자신이 두 가지 모두를 작성했기 때문에, 이를 뒷받침하는 조사 내용이 견고하다고 생각하게 됩니다.

하위 에이전트(Sub-agents)는 이 두 가지 문제를 모두 해결합니다.

OpenClaw에서 위임이 작동하는 방식

OpenClaw를 사용하면 메인 세션 내에서 격리된 자식 세션, 즉 하위 에이전트(Sub-agents)를 생성할 수 있습니다. API 호출은 깔끔합니다:

# 병렬 조사를 위한 하위 에이전트 생성
result = sessions_spawn(
    task="2026년 기준 상위 5개 오픈 소스 AI 에이전트 프레임워크를 조사하십시오. 각 프레임워크의 이름, repo_url, stars, 그리고 한 줄 설명을 포함한 JSON 배열을 반환하십시오.",
...

이 코드는 조사를 위한 작업을 새로운 격리된 에이전트에게 발송합니다. 그동안 메인 에이전트는 다른 일, 예를 들어 이메일 초안을 작성하거나, 크론 잡(Cron job)을 설정하는 등 두 번째 우선순위가 무엇이든 다른 작업을 수행할 수 있습니다.

하위 에이전트가 작업을 마치면, 그 출력값은 구조화된 결과(Structured result)로 돌아옵니다. 그러면 메인 에이전트는 이를 통합하거나, 검토하거나, 혹은 다음 하위 에이전트에게 전달할 수 있습니다.

핵심 키워드는 **격리 (isolated)**입니다. 자식 세션은 (명시적으로 포크 (fork)하지 않는 한) 사용자의 메인 대화 컨텍스트 (context)를 상속받지 않습니다. 이는 버그가 아니라 기능입니다. 격리되어 있다는 것은 하위 에이전트 (sub-agent)가 메인 에이전트의 편향 (biases)에 오염되지 않으며, 메인 세션의 상태 (state)를 실수로 덮어쓸 수 없음을 의미합니다.

실제로 무엇이 위임되는가

이 패턴을 몇 주 동안 실행해 본 결과, 무엇이 좋은 위임 작업인지 배우게 되었습니다.

좋은 후보:

• 리서치 작업: 여러 소스를 가져오고 합성 (synthesizing)해야 하는 모든 작업
• 배치 작업 (Batch operations): "이 10개의 URL을 확인하고 각각을 요약하세요"
• 초안 생성: 하위 에이전트가 거친 초안을 작성하게 한 뒤, 메인 세션에서 이를 검토
• 병렬 데이터 수집: "5개 공급업체로부터 현재 가격을 가져온 다음, 데이터를 정규화 (normalize)하세요"

나쁜 후보:

• 이 세션의 메인 에이전트 컨텍스트 (context)나 메모리 (memory)에 대한 접근이 필요한 모든 작업
• 진행하기 전에 인간 참여형 (human-in-the-loop) 확인이 필요한 작업
• 직접 하는 것이 더 빠른 한 줄짜리 작업들

제가 사용하는 패턴은 다음과 같습니다: 만약 어떤 작업이 명확한 입력 (input), 명확한 출력 (output)을 가지고 있으며, 메인 세션에서 다른 일이 무엇이 일어나고 있는지 알 필요가 없다면, 그것은 위임됩니다.

깨달음을 준 코드

저에게 진정한 돌파구는 위임 (delegation)을 크론 잡 (cron jobs)과 결합한 것이었습니다. 새벽 2시에 모든 것을 수행하는 하나의 크론 잡을 두는 대신, 이제는 전체 작업 컨텍스트 (context)를 가진 하위 에이전트를 생성하는 크론 잡을 사용합니다:

# 크론 잡 페이로드 (payload) 내에서 — 격리된 에이전트 턴 (agent turn)을 실행
payload = {
    "kind": "agentTurn",
...

메인 세션은 관여하지 않습니다. 크론이 실행되면, 하위 에이전트가 깨어나 작업을 수행하고 사라집니다. 컨텍스트 오염 (context pollution)도 없고, 순차적 병목 현상 (sequential bottleneck)도 없습니다.

트레이드오프 (Tradeoffs)는 실재한다

이 방식에 어떤 비용이 드는지 솔직하게 말씀드리고 싶습니다.

지연 시간 (Latency). 하위 에이전트를 생성하고 그 결과를 기다리는 것은 동일한 컨텍스트 내에서 직접 작업을 수행하는 것보다 더 오래 걸립니다. 2분 미만의 빠른 작업의 경우, 이는 종종 그만한 가치가 없습니다.

컨텍스트 파편화 (Context fragmentation). 3개의 하위 에이전트 (sub-agents)가 병렬로 작업할 때, 3개의 별도 결과 스트림이 돌아오게 됩니다. 결과가 메인 세션으로 어떻게 다시 전달될지에 대한 명확한 규약 (convention)이 필요합니다. 그렇지 않으면 절약한 시간만큼이나 결과물을 하나로 엮는 데 시간을 쓰게 됩니다.

실패 모드 (Failure modes)의 증폭. 만약 메인 에이전트가 생성한 하위 에이전트가 조용히 실패한다면, 확인 절차 (acknowledgment checks)를 구축해야 합니다. 저는 각 하위 에이전트가 완료 시점에 기록할 수 있도록 data/subagent-results/에 가벼운 결과 로그를 추가했습니다:

# 각 하위 에이전트는 성공 시 이를 기록합니다
with open(f"data/subagent-results/{task_id}.json", "w") as f:
    json.dump({"status": "done", "output": result, "timestamp": now()}, f)

그러면 메인 세션은 확인이 필요한 경우 이 디렉토리를 폴링 (poll) 할 수 있습니다.

내가 배운 것들

위임 (Delegation)은 당신의 에이전트를 대체하는 것이 아닙니다. 품질을 희생하지 않으면서 동시에 여러 가지 일을 처리할 수 있는 능력을 에이전트에게 부여하는 것입니다.

가장 큰 변화는 심리적인 것이었습니다. 저는 제가 직접 일을 해야 한다는 느낌을 버렸습니다. "이 작업을 어떻게 더 빨리 할 수 있을까?"라고 묻는 대신, "이 작업이 애초에 내 것이어야 하는가?"라고 묻기 시작했습니다.

때로는 정답이 '예'일 때도 있습니다. 특히 판단력, 관계적 맥락, 또는 메인 세션만이 알고 있는 정보에 대한 접근이 필요한 경우 말입니다. 하지만 놀라울 정도로 많은 비중의 작업에 대해 정답은 다음과 같습니다: 하위 에이전트를 생성하고, 그것이 처리하게 둔 뒤, 결과물을 검토하십시오.

이것은 당신의 에이전트 스택 (agent stack)과 맺는 근본적으로 다른 관계입니다. 당신은 더 이상 그것을 운전하는 것이 아닙니다. 그것을 운영 (operating) 하는 것입니다.

대시보드를 확인했을 때 밤사이 3개의 하위 에이전트가 각각 별도의 조사 작업을 완료한 것을 처음 보았을 때, 저는 단일 에이전트 설정에서는 결코 느껴보지 못한 것을 느꼈습니다. 그것은 단순한 도구가 아니라, 실제로 하나의 시스템을 구축했다는 감각이었습니다.

배운 점: 위임 (Delegation)은 입력(Input)과 출력(Output)이 명확하고, 고립되어 있으며 잘 정의된 작업에 가장 효과적입니다. 공유된 컨텍스트 (Shared context)나 인간의 판단이 필요한 작업에는 실패합니다. 첫날부터 서브 에이전트 (Sub-agent) 작업에 결과 로깅 (Result-logging) 기능을 구축하십시오. 새벽 2시에 무언가 고장 나서 어디서 무슨 일이 일어났는지 추적해야 할 때, 스스로에게 고마워하게 될 것입니다.