지난 화요일, 제 에이전트가 예전에는 3분 만에 수행하던 작업을 하는 데 14분이 걸렸습니다. 트랜스크립트(transcript)는 반복되는 컨텍스트(context)의 벽이었습니다. 몇 달 동안 하나의 세션에 작업을 계속 쌓아왔기 때문에, 매 턴마다 동일한 40,000개의 토큰(tokens)을 다시 읽고 있었습니다.

해결책은 부끄러울 정도로 간단했습니다. 모든 것을 하나의 에이전트(agent)를 통해 실행하려는 시도를 멈추는 것이었습니다.

저는 작업 부하를 병렬로 실행되는 세 개의 서브 에이전트(sub-agents)로 나누었습니다. 응답 시간은 90초 미만으로 떨어졌습니다. 작업당 토큰(token) 사용량은 약 60% 감소했습니다. 그리고 메인 에이전트(main agent)는 동일한 세션 내에서 3시간 전에 발생한 일들에 대해 환각(hallucinating) 현상을 일으키며 설명을 지어내는 것을 멈췄습니다.

제가 정확히 무엇을 변경했는지, 그리고 왜 이것이 작동하는지 설명하겠습니다.

문제점: 컨텍스트(Context) 누적이 에이전트 성능을 저하시킨다

모든 OpenClaw 세션에는 컨텍스트 창(context window)이 있습니다. 세션이 이력과 함께 커질수록, 모델(model)은 매 턴마다 더 많은 토큰(tokens)을 처리해야 합니다. 이는 세 가지 복합적인 효과를 가져옵니다:

1. 지연 시간(Latency) 상승 — 더 많은 토큰은 더 긴 추론(inference)을 의미합니다.
2. 작업당 비용 상승 — 매 턴마다 모든 것을 다시 읽는 데 비용을 지불하게 됩니다.
3. 신뢰도 하락 — 모델이 자신의 이력에 의해 주의가 분산되어 무엇이 언제 일어났는지 혼동하기 시작합니다.

저는 이를 연구 작업에서 처음 발견했습니다. 에이전트(agent)는 다섯 명의 경쟁사에 대한 데이터를 수집하고, 각각을 요약하며, 비교 보고서를 작성해야 했습니다. 하지만 결과적으로 20분 동안 실행되었음에도 불구하고, 어떻게 된 일인지 두 명의 경쟁사를 완전히 놓쳤고 세 번째 경쟁사에 대해서는 중복 작업을 수행했습니다. 트랜스크립트(transcript)를 보니 어떤 연구가 이미 완료되었는지에 대해 혼란을 겪고 있었습니다.

이것은 모델의 지능 문제가 아닙니다. 아키텍처(architecture) 문제입니다.

해결책: 서브 에이전트(Sub-Agents)를 통한 격리 및 위임

OpenClaw를 사용하면 깨끗한 자식 세션(child sessions), 즉 서브 에이전트(sub-agents)를 생성할 수 있습니다. 이들은 각각 새로운 컨텍스트(fresh context)를 가진 상태로 독립적으로 실행됩니다. 메인 에이전트(main agent)가 특정 작업을 위임하면, 서브 에이전트(sub-agent)가 이를 격리된 상태에서 처리한 후 결과만을 반환합니다.

이것은 도구 호출 (tool call)과는 다릅니다. 도구 호출은 동일한 세션 내에서 실행됩니다. 반면 서브 에이전트 (sub-agent)는 자신만의 컨텍스트 윈도우 (context window), 자신만의 모델 선택 (model selection), 그리고 자신만의 도구 (tools)를 가진 별도의 세션에서 실행됩니다. 서브 에이전트가 작업을 마치면 결과만을 반환합니다. 메인 세션은 결과값만을 볼 뿐, 그 결과에 도달하기까지 거친 80단계의 중간 과정은 보지 않습니다.

패턴은 다음과 같습니다:

// 한 경쟁사에 대한 조사용 리서치 서브 에이전트 생성
sessions_spawn({
  task: `${company_name}에 대해 조사하세요. 다음 내용을 포함한 200단어 요약을 반환하세요:
...

각 sessions_spawn 호출은 병렬로 실행됩니다. 다섯 개의 경쟁사 조사 서브 에이전트가 모두 실행되는 동안, 메인 에이전트는 자유로운 상태를 유지합니다. 즉, 차단되지 않으며 컨텍스트 비대화 (context bloat)로 인해 토큰을 낭비하지도 않습니다. 서브 에이전트들이 결과를 반환하면, 메인 에이전트는 다섯 개의 깔끔한 요약본을 받아 비교 보고서를 작성합니다.

중복되는 컨텍스트도 없고, 무엇이 완료되었는지에 대한 혼란도 없습니다.

실제로 이 방식으로 실행하고 있는 작업들

작업을 서브 에이전트들로 분리한 지 일주일이 지난 후, 현재의 분류 현황은 다음과 같습니다:

제가 내린 규칙은 다음과 같습니다: 만약 어떤 작업이 10개 이상의 파일을 살펴봐야 하거나, 완료하기까지 5번 이상의 도구 호출 (tool calls)이 필요하다면 서브 에이전트에게 맡깁니다. 그 외의 모든 것은 메인 세션에 머뭅니다.

일주일 후의 결과

제 OpenClaw 대시보드의 수치는 다음과 같습니다:

• 평균 작업 지연 시간 (latency): 11.3분에서 2.1분으로 감소 (병렬성 + 격리)
• 리서치 작업당 토큰 사용량: 약 58% 감소 — 40k 토큰 분량의 기록을 다시 읽을 필요가 없음
• 다단계 작업의 오류율 (error rate): 23%에서 4%로 하락
• 일일 생성된 서브 에이전트 수: 모든 작업 유형에 걸쳐 평균 14개

오류율의 하락이 저를 가장 놀라게 했습니다. 각 서브 에이전트가 신선한 컨텍스트 (fresh context)를 가질 때, 메인 세션에 누적된 혼란을 물려받지 않기 때문입니다. X사를 조사하는 서브 에이전트는 이전 세 번의 조사 호출이 A, B, C사에 대한 것이었다는 사실을 알지 못합니다. 오직 해당 작업에만 집중합니다.

주의해야 할 점 하나

서브 에이전트 (Sub-agents)는 메인 세션 (main session)과 메모리 (memory)를 공유하지 않습니다. 만약 서브 에이전트가 특정 내용을 알아야 한다면, 작업 프롬프트 (task prompt)에 명시적으로 전달해야 합니다. 저는 코드 리뷰 서브 에이전트가 실제 프로젝트가 무엇인지에 대한 컨텍스트 (context)가 전혀 없어, 리포지토리 (repo) 구조를 파악하기 위해 처음 세 번의 도구 호출 (tool calls)을 허비했을 때 이 사실을 뼈아프게 배웠습니다.

해결 방법은 간단합니다. 모든 서브 에이전트 작업의 시작 부분에 짧은 컨텍스트 블록 (context block)을 포함시키세요.

task: `컨텍스트 (Context): 당신은 ${repo_name} 프로젝트의 PR #${pr_number}를 리뷰하고 있습니다.
  메인 브랜치 (main branch)는 'main'입니다. 이 PR은 인증 (auth) 모듈을 변경합니다.
  [추가적인 관련 컨텍스트]
...

이것이 에이전트 워크플로우 (Agent Workflows) 설계 방식을 어떻게 바꾸는가

전통적인 접근 방식은 다음과 같습니다: 하나의 에이전트, 많은 도구, 그리고 긴 세션. 이 방식은 한계에 부딪히기 전까지는 잘 작동합니다.

서브 에이전트 위임 (Sub-agent delegation)은 설계 질문 자체를 바꿉니다. "어떻게 하면 이 에이전트에게 더 많은 능력을 부여할 수 있을까?" 대신, "독립적인 작업 흐름 (workstreams)은 무엇이며, 각 흐름을 어떻게 적절한 컨텍스트에 전달할 것인가?"가 질문이 됩니다.

이는 유능한 엔지니어링 팀이 운영되는 방식에 더 가깝습니다: 명확한 범위 (scope)를 가진 전문가들이 결과물을 코디네이터 (coordinator)에게 전달하는 방식입니다. 메인 에이전트는 코디네이터이며, 서브 에이전트는 전문가입니다.

만약 당신의 메인 에이전트가 컨텍스트 혼란으로 인해 느려지거나, 비용이 많이 들거나, 오류를 범하고 있다면, 그 해답은 더 나은 모델 (model)이 아니라 아마도 더 나은 아키텍처 (architecture)일 것입니다. 우선 한 가지 유형의 작업을 격리하여 서브 에이전트로 실행하는 것부터 시작해 보세요. 첫 번째 실행에서 바로 차이를 느끼게 될 것입니다.

저는 다양한 작업 유형에 걸쳐 하루에 14개의 서브 에이전트를 실행하고 있습니다. 만약 여러분도 비슷하게, 혹은 다르게 무언가를 하고 있다면, 어떤 아키텍처 선택이 효과적이었는지 듣고 싶습니다.