OpenClaw ADHD 스레드가 농담인 줄 알았는데, 에이전트 위임(Agent Delegation)이 비용의 5배 가치를 갖는 시점을 가르쳐

나는 "OpenClaw에 ADHD를 주었다"라는 게시물을 보고 밈(Meme)일 것이라 예상하며 클릭했다.

하지만 그 대신, 왜 그렇게 많은 코딩 에이전트(Coding Agents)들이 여전히 프로덕션(Production) 환경에서 실패하는지에 대한 가장 명확한 설명 중 하나를 발견했다.

그 스레드는 r/openclaw에 올라온 것이었으며, 아이디어는 간단했다: OpenClaw가 하나의 직선적인 방식으로만 생각하도록 강요하는 것을 멈추는 것이다. 대신 여러 개의 후보 생각(Candidate Thoughts)을 생성하게 하고, 그 위에 비판자(Critic)를 실행하여 유망한 가지(Branches)들을 유지하게 하는 것이다.

이것은 그것이 기본적으로 더 나은 Reddit 제목을 가진 사고의 트리(Tree of Thoughts) 방식이라는 것을 깨닫기 전까지는 엉뚱하게 들릴 수 있다.

그리고 가장 유용한 부분은 그 영리함이 아니었다. 그것은 트레이드오프(Tradeoff)였다.

작가는 이 접근 방식이 비용을 약 5배, 지연 시간(Latency)을 약 10배 증가시킨다고 말했다.

이것은 각주 수준의 이야기가 아니다. 이것이 설계 논의의 핵심이다.

만약 당신이 OpenClaw, LangGraph, AutoGen, n8n, Make, 또는 당신만의 OpenAI 호환 스택(OpenAI-compatible stack)으로 에이전트를 구축하고 있다면, 이것이 진짜 질문이다:

언제 에이전트가 가지를 치고 탐색해야 하며, 언제 생각을 멈추고 실행을 결정론적 코드(Deterministic Code)에 넘겨야 하는가?

농담 같은 게시물 속에 숨겨진 프로덕션 교훈

그 스레드에서 가장 훌륭한 문장은 이것이었다:

"한계: 비용은 약 5배, 출력 시간은 약 10배 증가하지만, 즉각적인 새로운 사고를 가능하게 한다. 브레인스토밍과 계획에는 좋지만, 코딩에는 적합하지 않다."

이것은 대부분의 세련된 에이전트 데모보다 더 유용하다.

왜냐하면 이제 우리에게 실제적인 규칙이 생겼기 때문이다:

작업이 모호할 때는 가지치기(Branching)가 도움이 된다.
작업이 명확하고 실행 중심적일 때는 가지치기가 해가 된다.

따라서 올바른 아키텍처는 "항상 더 많은 에이전트를 사용하는 것"이 아니다.

그것은 "선택적으로 가지를 치는 것"이다.

당연하게 들리겠지만, 많은 에이전트 시스템들은 여전히 그 반대로 행동한다. 그들은 모든 작업을 추론 벤치마크(Reasoning Benchmark)처럼 취급하고는, 왜 비용이 폭발하고 신뢰성이 무너지는지 의아해한다.

에이전트 루프에서 실제로 무너지는 것

대부분의 에이전트 실패는 모델의 순수한 지능 문제 때문이 아니다.

그것은 성급한 확정(Premature Commitment)에 관한 것이다.

에이전트는 첫 번째로 그럴듯한 계획을 선택하고 파고들기 시작한다.

당신이 에이전트 루프 안에서 GPT-5, Claude Opus, 또는 Grok을 지켜봤다면 이런 모습을 본 적이 있을 것이다:

작업에 대한 한 가지 해석을 선택합니다.
하나의 쿼리, 하나의 파일, 하나의 API 경로를 선택합니다.
너무 일찍 확정(Commit)해 버립니다.
20단계가 지난 후에야 2단계가 틀렸다는 사실을 발견합니다.

더 긴 프롬프트(Prompt)도 이를 해결하지 못합니다.

더 큰 컨텍스트 윈도우(Context Window)도 이를 해결하지 못합니다.

"신중하게 생각하라(Think carefully)"라는 말은 확실히 이를 해결하지 못합니다.

도움이 되는 방법은 런타임(Runtime)에 유능한 엔지니어들이 자연스럽게 하는 행동을 할 수 있는 권한을 부여하는 것입니다:

몇 가지 그럴듯한 접근 방식(Approaches)을 생성합니다.
그것들을 점수 매깁니다(Score).
약한 옵션들을 조기에 제거합니다.
하나의 경로가 명확하게 승리할 때만 확정(Commit)합니다.

이것이 실제 시스템에서 사고의 나무(Tree of Thoughts) 기법이 유용한 부분입니다.

선형 루프(Linear loops) vs 분기형 런타임(Branching runtimes)

실용적인 버전은 다음과 같습니다.

접근 방식	장점
선형 에이전트 루프 (Linear agent loop)	낮은 비용, 낮은 지연 시간(Latency), 단순한 실행
...

이것들은 서로 경쟁하는 아이디어가 아닙니다.

계층적으로 쌓여야(Stacked) 합니다.

생각할 때는 분기(Branching)를 사용하세요.

실행할 때는 결정론적 인프라(Deterministic infrastructure)를 사용하세요.

간단한 멘탈 모델 (Mental model)

저는 다음과 같은 규칙을 사용하기 시작했습니다:

생각할 때는 분기하고, 실행할 때는 제약하라.

이 한 문장이 수많은 에이전트 실패 사례를 설명해 줍니다.

만약 당신의 에이전트가 하나의 거대한 프롬프트 형태의 덩어리(Blob) 안에서 계획(Planning), 실행(Execution), 재시도(Retries), 페이지네이션(Pagination), 권한(Permissions), 그리고 복구(Recovery)를 모두 수행하려고 한다면, 데모에서는 똑똑해 보일지 몰라도 프로덕션(Production) 환경에서는 불안정할 것입니다.

분기가 도움이 되는 경우

첫 번째 답변이 틀리는 경우가 많을 때 분기가 유용합니다.

좋은 예시:

아키텍처 결정 (Architecture decisions)
마이그레이션 계획 (Migration planning)
근본 원인 조사 (Root-cause investigation)
연구 작업 (Research tasks)
안전 분석 (Safety analysis)
구현 전 초기 설계 (Early design before implementation)

의사 코드 흐름 예시 (Example pseudo-flow):

candidates = planner.generate_candidates(task, n=4)
scored = [critic.score(c) for c in candidates]
best = select_top(scored, threshold=0.8)
...

이는 거대한 프롬프트를 한 번 통과하는 것만으로 항상 최선의 계획이 나올 것이라고 가정하는 것보다 훨씬 낫습니다.

분기가 최악의 아이디어인 경우

추가적인 추론(Reasoning)이 대부분 낭비가 되는 작업들이 있습니다.

분기를 사용하면 안 되는 곳:

1,000개의 BoldSign 문서 전송
API 페이지네이션 (Pagination)
실패한 웹훅 (Webhooks) 재시도
대량 전사 (Bulk transcription)
많은 파일에 걸친 기지의 코드 변경 사항 적용

이러한 작업의 경우, 모델은 행동을 선택한 다음, 방해하지 않고 물러나야 합니다.

예를 들어, 다음과 같은 작업을 1,000번이나 "추론 (Reasoned through)"해서는 안 됩니다:

for page in $(seq 1 100); do
  curl -s "https://api.vendor.com/items?page=$page" >> items.json
  sleep 0.2
...

이것은 코드에 속해야 할 영역입니다.

Claude나 GPT-5가 매 페이지 전환을 결정하는 루프 안에 있어서는 안 됩니다.

가장 훌륭한 OpenClaw의 통찰은 OpenClaw에 관한 것이 아니었다

OpenClaw 스레드를 읽는 동안, 기업 워크플로 (Enterprise workflows)에서 이를 사용하는 팀들로부터 또 다른 유용한 점을 발견했습니다.

그들의 논거는 기본적으로 다음과 같습니다:

벤더 API (Vendor APIs)를 감싸는 범용 MCP 래퍼 (Wrappers)는 모델이 모든 통합 작업을 직접 수행해야 한다면 확장성 (Scale)을 갖지 못합니다.

그 말은 모델이 결국 다음과 같은 것들을 처리하게 된다는 의미입니다:

엔드포인트 선택 (Endpoint selection)
페이지네이션 (Pagination)
재시도 (Retries)
루핑 (Looping)
에러 핸들링 (Error handling)
권한 민감형 작업 (Permission-sensitive actions)

이것이 바로 많은 "에이전트 프레임워크 (Agent framework)" 프로젝트들이 잘못되는 지점입니다.

그들은 유연해 보인다는 이유로 운영 로직 (Operational logic)을 모델에 밀어 넣습니다.

하지만 유연함이 좋은 아키텍처 (Architecture)와 같은 것은 아닙니다.

더 합리적인 형태는 다음과 같습니다:

에이전트 플래너 (Agent planner) -> 도구 라우터 (Tool router) -> 결정론적 서비스 (Deterministic service) -> 결과 (Result)

또는, 더 명시적으로 표현하자면 다음과 같습니다:

OpenClaw -> 런타임/오케스트레이터 (Runtime/orchestrator) -> 제한된 워커 (Locked-down worker)

플래너는 결정합니다.

워커는 실행합니다.

런타임은 재시도, 배치 (Batching), 타임아웃 (Timeouts), 그리고 상태 (State)를 처리합니다.

이것이 위임 (Delegation)입니다.

예시: 실행이 아닌 계획 단계에서 분기하라

다음은 제가 실제로 배포할 만한 패턴입니다.

1단계: 계획 생성 시에만 분기

{
  "task": "webhook 인입 서비스를 폴링(Polling) 방식에서 이벤트 기반 처리(Event-driven processing) 방식으로 마이그레이션",
  "mode": "branch",
...

2단계: 하나의 계획 선택

{
  "selected_plan": "멱등성 소비자(Idempotent consumers)와 재생 지원(Replay support)을 갖춘 큐 기반 인입(Queue-backed ingestion) 사용"
}

3단계: 결정론적 실행으로 전환

./run_migration_checklist.sh
terraform apply -auto-approve
python scripts/verify_replay.py

그 분기(split)는 중요합니다.

실행 과정 내내 계속해서 분기(branching)를 유지한다면, 더 이상 사고(thought)가 도움이 되지 않는 지점에서도 과도한 추가 사고 비용을 지불하게 됩니다.

비용은 사람들이 말하기 꺼려하는 부분입니다

분기(Branching)는 지적으로는 매력적이지만, 경제적으로는 성가신 작업입니다.

OpenClaw 게시물이 주목받은 이유는 사람들이 그 동작을 즉각적으로 알아차렸기 때문입니다. 하지만 그들은 동시에 청구서도 알아차렸습니다.

5배의 비용 증가와 10배의 지연 시간(latency) 증가는 "약간 더 비싸진" 수준이 아닙니다. 그것은 완전히 다른 제품 결정(product decision)의 문제입니다.

그리고 바로 이 지점에서 인프라(infrastructure)가 프롬프팅(prompting)보다 더 중요해지기 시작합니다.

토큰(token)당 비용을 지불하고 있다면, 분기(branching)는 빠르게 고통스러운 작업이 됩니다.

불확실한 모든 단계는 하나의 미니 팬아웃(fan-out) 이벤트가 됩니다:

3개의 후보 계획 (candidate plans)
3개의 비판 (critiques)
1개의 종합 (synthesis)
그 이후에 아마 또 다른 분기

이것이 단순한 워크플로우(workflow)가 예상치 못한 청구서로 변하는 방식입니다.

n8n, Make, Zapier, OpenClaw 또는 커스텀 자동화(custom automations)에서 하루 종일 에이전트(agent)를 실행하는 팀들에게, 이것은 정확히 실험을 가로막는 요소입니다. 모든 분기가 비용이 많이 드는 것처럼 느껴지기 때문에 에이전트에게 탐색(explore)을 요구하는 것을 멈추게 됩니다.

그것이 에이전트 워크플로우에서 무제한 컴퓨팅(unlimited compute)이 매우 중요한 이유 중 하나입니다.

만약 당신의 API가 OpenAI API를 그대로 대체할 수 있고, 토큰당 과금이 아닌 월정액 요금제를 사용하고 있다면, 토큰 불안(token anxiety)을 고려하여 설계를 맞추는 대신 실제로 도움이 되는 곳에 분기(branching)를 사용할 여유가 생깁니다.

이것이 에이전트 빌더들에게 Standard Compute가 흥미로운 이유입니다. 한 번의 계획 단계(planning pass)를 더 거치는 것이 비용만큼의 가치가 있는지 끊임없이 자문할 필요가 없기 때문에, 선택적 분기(selective branching)를 실무에서 훨씬 더 쉽게 사용할 수 있게 해줍니다.

여전히 절제(discipline)는 필요합니다. 무제한 컴퓨팅이 무제한의 잘못된 아키텍처(architecture)를 의미하는 것은 아닙니다.

하지만 다음과 같은 유용한 패턴들을 사용할 수 있음을 의미합니다:

불확실성이 높은 작업에서 분기(branch) 수행
분기 폭(branch width) 제한
공격적인 가지치기(prune)
결정론적 도구(deterministic tools)로 실행 경로 지정
토큰 지출에 집착하지 않고 에이전트를 24/7 가동 유지

실용적인 라우팅 정책 (routing policy)

만약 여러분이 오늘날 에이전트 런타임 (agent runtime)을 구축하고 있다면, 이것이 괜찮은 시작점이 될 것입니다.

routing:
  planning:
    strategy: branch
...

해당 정책은 지루하지만, 바로 그 점 때문에 효과가 있습니다.

나의 주관적인 견해

대부분의 멀티 에이전트 (multi-agent) 열풍은 가짜 분리입니다.

연구자 에이전트 (Researcher agent). 비평가 에이전트 (Critic agent). 플래너 에이전트 (Planner agent). 리뷰어 에이전트 (Reviewer agent).

대부분의 경우, 이는 그저 하나의 모델이 동일한 모호한 루프 (mushy loop) 안에서 서로 다른 역할(hats)을 수행하고 있는 것에 불과합니다.

실제로 중요한 것은 관심사의 분리 (separation of concerns)입니다.

진정한 위임 (delegation)은 다음을 의미합니다:

하나의 컴포넌트가 옵션을 탐색하고
하나의 컴포넌트가 점수를 매기거나 선택하며
하나의 컴포넌트가 제한된 권한으로 실행하고
하나의 컴포넌트가 재시도 (retries), 배치 (batching), 그리고 복구 (recovery)를 처리하는 것

이것이 아키텍처 (architecture)입니다.

프롬프트 코스프레 (prompt cosplay)가 아닙니다.

내가 지금 당장 구축한다면

만약 내가 프로덕션 환경에서 사용할 에이전트 스택 (agent stack)을 설계한다면, 다음과 같이 할 것입니다:

표준 에이전트 호출에는 빠른 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 사용한다.
불확실성이 높다고 표시된 작업에 대해서만 브랜칭 (branching)을 활성화한다.
브랜치 너비 (branch width)를 작게 유지한다.
API 집약적인 작업에는 결정론적 서비스 (deterministic services)를 사용한다.
모델 외부에서 엄격한 타임아웃 (timeouts) 및 재시도 정책 (retry policies)을 추가한다.
브랜칭이 결과물을 개선하는 지점과 단순히 지연 시간 (latency)만 낭비하는 지점을 추적한다.

그리고 시스템이 지속적으로 실행되기를 기대한다면, 토큰당 과금 (per-token pricing)보다는 정액제 컴퓨팅 (flat-rate compute)을 강력히 선호할 것입니다.

왜냐하면 일단 에이전트가 브랜칭하고, 재시도하며, 긴 워크플로 (workflows)를 실행하게 되면, 토큰 기반 과금은 청구서가 아니라 브레이크 페달처럼 느껴지기 시작하기 때문입니다.

실제 핵심 요약

"OpenClaw에게 ADHD를 주었다"라는 스레드는 재미있었습니다.

동시에 그것은 옳았습니다.

에이전트 설계의 다음 단계는 아마도 "더 똑똑한 프롬프트를 작성하는 것"이 아닐 것입니다.

그것은 바로 이것입니다:

문제가 불확실할 때는 브랜칭(branch)하라
작업이 운영적(operational)일 때는 제약(constrain)하라
실행을 결정론적 시스템(deterministic systems)에 위임하라
과금 방식이 여러분이 실제로 사용하고자 하는 아키텍처를 방해하게 두지 마라

이것이 농담 속에 숨겨진 유용한 교훈입니다.

그리고 솔직히 말해서, 이는 내가 최근에 읽은 대부분의 진지한 에이전트 조언보다 더 낫습니다.