본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 05. 23:08

멀티 에이전트 Claude Code 스택에 빠져 있는 의사결정 계층

요약

멀티 에이전트 Claude Code 스택에서 결여된 '의사결정 계층'의 중요성을 다룹니다. Cynefin 프레임워크를 통한 문제 분류, 베이지안 확률 기반의 명세서 작성, 그리고 인지 도구로서의 게이트 활용 등 체계적인 에이전트 워크플로우 설계 전략을 제안합니다.

핵심 포인트

  • Cynefin 프레임워크를 활용한 문제 유형별 분해 전략 수립
  • 베이지안 사전 확률을 적용한 반증 가능한 명세서 작성
  • 단순 체크포인트가 아닌 인지 도구로서의 게이트 설계
  • 리스크 기반의 검증 또는 폐기(Validate-or-Kill) 프로세스 도입

요약 (TL;DR)

대부분의 멀티 에이전트 (multi-agent) Claude Code 스택에는 에이전트가 문제에 접근하기 전, 문제를 어떻게 생각할지 결정하는 계층이 빠져 있습니다. 실제로는 다음과 같은 계층의 모습입니다. 첫 번째 라우팅 결정으로서의 Cynefin 분류. 명시적인 베이지안 사전 확률 (Bayesian priors)을 가진 하위 가설들의 결합으로서의 명세서 (Specs). 체크포인트라기보다는 인지 도구 (cognitive tools)의 예정된 순환으로서의 게이트 (Gates). 제약 이론 (Theory of Constraints)을 런타임 상태로 활용. 모든 주장에 대한 기본값으로서의 반증 가능성 (Falsifiability).

빠져 있는 계층

대부분의 멀티 에이전트 Claude Code는 플래너 (planner) LLM, N개의 하위 에이전트 (subagents), 그리고 기도뿐입니다. 거의 항상 빠져 있는 부분은 에이전트가 문제에 손을 대기 전, 문제를 어떻게 생각할지 선택하는 의사결정 계층 (decision-making layer)입니다.

만약 당신이 멀티 에이전트 워크플로우 (multi-agent workflows)를 실행하고 있는데, 플래너가 작업 트리 (task tree)를 생성하기 전에 "이 작업은 어떤 체제 (regime)에 있는가"라는 질문에 답할 수 없다면, 나머지는 그저 희망 사항일 뿐입니다.

무엇보다 먼저 Cynefin으로 분류하기

모든 프로젝트의 첫 번째 단계는 Cynefin 분류여야 합니다. 명확함 (Clear), 복잡함 (Complicated), 난해함 (Complex), 또는 혼돈 (Chaotic). 이 분류가 분해 전략 (decomposition strategy)을 결정합니다.

  • **명확함 (Clear)**은 기능적 (Functional) 분해를 수행합니다. 정답이 알려져 있으며, 기능 경계에 따라 구조화합니다.
  • **복잡함 (Complicated)**은 계층 기반 (Layer-based) 분해를 수행합니다. 전문가가 분석할 수 있으며, 추상화에 따라 구조화합니다.
  • **난해함 (Complex)**은 리스크 기반 (Risk-based) 분해를 수행합니다. 불확실성이 가장 높은 것을 우선시하며, 시간 제한이 있는 탐색 (time-boxed probes)을 수행하고, 종료 날짜를 전혀 추정하지 않습니다.
  • **혼돈 (Chaotic)**은 행동-감지-반응 (Act-Sense-Respond)을 수행합니다. 먼저 출혈을 막고, 그다음 분석합니다.

플래너는 작업 트리를 자유롭게 구성할 수 없습니다. 인식론적 체제 (epistemic regime)가 이를 제약합니다.

명세서는 베이지안 사전 확률을 가진 하위 가설들의 결합이다

기능 목록으로 작성된 명세서 (spec)는 소망일 뿐입니다. 사전 확률 (priors)을 가진 하위 가설들의 결합으로 작성된 명세서는 반증 가능한 (falsifiable) 계획입니다.

P(프로젝트 성공) = P(H1) × P(H2) × ... × P(Hn)

결합 사전 확률 (joint prior)이 20% 미만으로 떨어지면, Phase 0의 '검증 또는 폐기 (Validate-or-Kill)' 스프린트가 실존적 위험을 먼저 해결하기 전까지는 어떠한 인프라 작업도 수행되지 않습니다. 폐기 조건 (Kill conditions)은 동기부여가 생기기 전, 즉 사전 사후 분석 (pre-mortem) 단계에서 명세서 (spec)에 작성됩니다.

신념 추적기 (Belief tracker: Prior, After Gate 0, After Gate 1, ...)는 새로운 증거가 실제로 확률을 변화시키고 있는지, 아니면 단순히 활동만을 생성하고 있는지를 보여줍니다. 매몰 비용 (Sunk cost)은 팀이 프로젝트를 포기하기에는 너무 깊이 몰입해 버린 Gate-3 리뷰 단계가 아니라, 명세서 (spec) 단계에서부터 공학적으로 배제됩니다.

게이트 (Gates)는 체크포인트가 아니라 인지 도구의 순환입니다

대부분의 스택은 스프린트 리뷰를 "게이트"라고 부릅니다. 그것은 체크포인트 (checkpoint)입니다. 진정한 게이트는 각 도구가 영향력을 발휘할 수 있는 시점에 맞춰 계획된 인지 프레임워크 (cognitive frameworks)의 순환입니다.

페이즈 시작 시:

  1. Cynefin 분류. 우리가 어떤 체제 (regime)에 있는지 확인합니다.
  2. Polya. 문제가 실제로 요구하는 것이 무엇인지 파악합니다.
  3. 역발상 (Inversion) / 사전 사후 분석 (pre-mortem). 이것이 어떻게 실패할 것인지 분석합니다.
  4. 분해 (Decompose). 선택된 체제에 따른 전략에 따라 분해합니다.
  5. 제약 이론 (Theory of Constraints). 현재 병목 현상 (bottleneck)은 무엇인지 파악합니다.
  6. Fermi. 자릿수 단위의 추정치 (order-of-magnitude estimates)로 규모를 측정합니다.

페이즈 진행 중:

  1. 베이지안 실행 (Bayesian execution). 증거가 도착함에 따라 사전 확률 (priors)을 업데이트합니다.

게이트 리뷰 시:

  1. 8가지 편향 감사 (8-bias audit) + 5 Whys

세 가지 편향이 감지되면 의무적으로 일시 중단하고 처음부터 다시 프레임을 재설정해야 합니다.

게이트 의사결정 매트릭스 (Gate Decision Matrix)는 네 가지 값으로 구성됩니다: 진행 (Go), 반복 (Iterate), 피벗 (Pivot), 폐기 (Kill). "수정하기 (Fix it)"는 유효한 탈출구가 아닙니다. 폐기 (Kill)는 일급 시민 (first-class)이며, 이를 정당화하는 조건들은 사전 사후 분석 (pre-mortem)의 직접적인 결과물로서 사전에 등록됩니다.

제약 이론 (Theory of Constraints)은 슬로건이 아니라 런타임 상태입니다

현재의 병목 현상은 디스크에 기록되며 매 게이트마다 업데이트됩니다. 병목이 아닌 에이전트 (non-bottleneck agents)들은 재공품 (WIP)을 쌓아두는 대신 대기합니다.

유휴 상태 (Idle)는 진단 도구이지 실패가 아닙니다.

대부분의 멀티 에이전트 (multi-agent) 스택은 할당되지 않은 에이전트를 낭비되는 용량으로 취급하고 작업을 계속 쌓아 올립니다. 이는 올바른 방향의 정반대입니다. 병목이 아닌 작업을 실제 제약 조건 (constraint)에 종속시키는 것이 시스템을 수렴하게 만드는 핵심입니다.

모든 것은 반증 가능합니다 (Everything is falsifiable)

변화하는 모든 도구 호출 (tool call)은 추가만 가능한 감사 로그 (append-only audit log)에 기록을 남깁니다:

{
  "task_id": "T42",
  "agent_id": "backend-architect",
...

이 로그는 bash와 Python 구현 모두에서 비트 단위로 동일(bit-identical)하므로, 언어 간에 귀속(attribution) 정보가 어긋날 수 없습니다.

보정 실패(calibration miss) 카운터는 자기 검토(self-review)를 반증 가능하게(falsifiable) 만듭니다. 실행자(executor)가 심각도를 NONE 또는 LOW로 자가 보고했는데, 독립적인 적대적 검토자(adversarial reviewer)가 HIGH 또는 CRITICAL이라고 판단한다면 그것은 실패(miss)입니다. 최근 4번의 쌍 검토(paired reviews) 동안 실패율이 50%를 넘으면 재학습 권고(retraining advisory)가 트리거됩니다.

쌍을 이루는 두 번째 목소리 없는 자기 검토는 검토가 아닙니다. 그것은 희망 사항일 뿐입니다.

시스템의 형태가 핵심이다

에이전트 시스템(agentic systems)을 구축하는 것은 대부분 의사결정을 반증 가능하게 만드는 작업입니다.

  • 계획하기 전에 분류(Classify)하십시오.
  • 사전 확률(priors)을 가지고 가설을 세우십시오(Hypothesize).
  • 영향력이 있는 위치에 따라 순환되는 인지 도구(cognitive tools)로 게이트(Gate)를 설정하십시오.
  • 모든 변이(mutation)를 해시(hash)에 귀속시키십시오.
  • 종료(Kill)를 모든 게이트의 일급 결과물(first-class outcome)로 허용하십시오.
  • 분해 전략(decomposition strategy)을 플래너 LLM(planner LLM)이 생성하고 싶어 하는 방식이 아니라, 인식론적 체제(epistemic regime)에 따라 선택하십시오.

각 구성 요소는 특정 실패 모드(failure mode)를 대체합니다. 플래너 LLM이 잘못된 형태의 트리(tree)를 생성했습니다. 팀이 결합 사전 확률(joint prior)이 8%인 프로젝트를 위해 인프라를 배포했습니다. 팀이 내내 빠져 있었던 편향(bias)이 체크리스트에 포함되지 않았기 때문에 세 개의 게이트를 통과했습니다. 에이전트가 실제로 작동하지 않는 기능에 대해 성공했다고 자가 보고했습니다.

오늘 바로 적용할 수 있는 것들

시작하기 위해 스택을 처음부터 다시 구축할 필요는 없습니다. 가장 적은 비용으로 가장 높은 레버리지(leverage)를 얻을 수 있는 방법을 선택하십시오.

  1. 사양 템플릿(spec template) 상단에 Cynefin 분류 필드를 추가하십시오. 에이전트가 작업에 손을 대기 전에 이를 사용하십시오.
  2. 다음 사양을 사전 확률을 가진 하위 가설들의 결합(conjunction)으로 작성하십시오. 결합 확률을 계산하십시오. 만약 20% 미만이라면, 인프라 투자 전에 저렴한 단계 0(Phase 0)을 설계하십시오.
  3. 검토 가능한 모든 작업에 독립적인 적대적 검토자(adversarial reviewer)를 쌍으로 지정하십시오. 의견 불일치 횟수를 세십시오. 그 수치가 당신이 가진 자기 검토 품질에 대한 유일하고 정직한 측정 지표입니다.

질문

만약 당신이 멀티 에이전트 (multi-agent) Claude Code를 실행하고 있는데, 계획 (planning)이 시작되기 전의 라우팅 결정 (routing decision)이 무엇이었는지 나에게 말할 수 없다면, 모든 가정 (assumptions)의 결합 확률 (joint probability)이 바닥으로 떨어질 때 당신의 정지 조건 (stop condition)은 무엇입니까?

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0