멀티 에이전트 추론 논문을 읽고 Claude 네이티브 버전을 구축하여 모든 것을 측정해 보았다

RecursiveMAS (arXiv 2604.25917)는 내부 추론 상태 (internal reasoning state)를 공유하는 에이전트가 최종 출력값 (final outputs)만을 공유하는 에이전트보다 성능이 뛰어남을 보여주었습니다. 벤치마크 전반에 걸친 평균 정확도 향상은 8.3포인트였습니다. 그 메커니즘은 다음과 같습니다: 각 에이전트가 단순히 정답만을 전달하는 것이 아니라, 자신의 추론 과정에서 생성된 잠재 임베딩 (latent embeddings)을 전달하며, 다음 에이전트는 이 두 가지 모두를 조건 (condition)으로 삼아 동작합니다. 이 논문은 훌륭한 결과물입니다.

문제는 접근성입니다. RecursiveMAS는 추론 시점에 은닉 상태 (hidden states)가 노출되는 오픈 웨이트 (open-weight) 모델을 필요로 합니다. 이로 인해 Claude, GPT-4o, Gemini는 제외됩니다. 저는 Anthropic의 확장된 사고 (extended thinking) API를 사용하여 Claude 네이티브 버전을 구축했습니다. 핵심 아이디어는 그대로 전이됩니다: 잠재 벡터 (latent vectors)를 전달하는 대신, 전체 사고 텍스트 (thinking text)를 전달하는 것입니다. 논문에서는 이를 내부 상태 공유 (internal state sharing)라고 부르며, Claude 버전에서는 사고 블록 전달 (thinking-block relay)이라고 부릅니다.

아키텍처 문제

Claude의 확장된 사고 블록 (extended thinking blocks)에는 시작된 대화와 연결된 암호화된 서명 (encrypted signature)이 포함되어 있습니다. 서명된 사고 블록을 다른 에이전트의 메시지 배열 (messages array)로 전달할 수 없습니다. API가 이를 거부하기 때문입니다. 해결 방법은 사고 블록에서 텍스트를 추출하여 일반 사용자 메시지 (user message)로 주입하는 것입니다.

# Agent 1에서 사고 텍스트 추출
thinking_text = next(
    (b.thinking for b in response.content if b.type == "thinking"), ""
...

서명은 전달되지 않지만, 추론 (reasoning)은 전달됩니다.

relay-structured: 내가 처음 구축한 것

첫 번째 아키텍처는 Planner > Critic > Solver 루프였으며, 각 에이전트는 가공되지 않은 사고 텍스트 대신 압축된 멘탈 모델 (mental model) JSON을 생성합니다. 1024 토큰 예산 내에서의 가공되지 않은 사고는 종종 압축되고 파편화됩니다. 저의 가설은 150 토큰의 구조화된 신호 (structured signal)가 1024 토큰의 압축된 산문보다 토큰당 더 많은 정보를 담고 있다는 것이었습니다.

각 에이전트가 생성하는 스키마 (schema):

{
  "interpretation": "에이전트가 문제를 해석한 방식",
  "key_steps": ["단계 1", "단계 2"],
...

confidence (신뢰도)와 potential_errors (잠재적 오류)가 핵심적인 지지 구조(load-bearing) 역할을 하는 필드입니다. 이 필드들은 하위 에이전트(downstream agents)가 전체 추론 과정(reasoning trace)을 파싱할 필요 없이, 어디에 더 세밀한 검토(scrutiny)를 적용해야 하는지 알려줍니다. "confidence: 0.4, potential_errors: x에 대한 제약 조건을 잘못 읽었을 수 있음"을 볼 수 있는 비평가(critic)는, 800토큰의 산문(prose)을 읽고 동일한 내용을 추론해야 하는 비평가와는 시작점부터 다릅니다.

결과 (n=50, 예비 결과)

조건	정확도 (Accuracy)	평균 토큰 (Avg tokens)
단일 에이전트 (single-agent)	70.0%	1,212
릴레이 구조 (relay-structured)	72.0%	18,821

+2포인트. 15배의 토큰 비용. 릴레이 구조(relay-structured)가 50개 문제 중 단 한 문제 차이로 승리했습니다. 방향은 맞습니다. 하지만 비용 비율은 이대로 배포할 수 있는 수준이 아닙니다. 모든 요청에 대해 Planner > Critic > Solver 전체 체인을 실행하는 것은 n=50 기준에서 2포인트의 이득만으로는 정당화되지 않습니다.

'read-before'를 구축하지 않은 이유

명백한 다음 단계는 에이전트 2가 자신의 답을 내놓기 전에 에이전트 1의 JSON을 읽게 하는 것입니다. 저는 이를 건너뛰었습니다. 문제는 앵커링(anchoring, 정박 효과)입니다. 에이전트 2는 자신의 견해를 형성하기 전에 에이전트 1의 답을 보게 되며, 이는 도전하기보다는 확인하려는 경향을 보일 것입니다. 이는 역할 전문화(role specialization)가 제거되고 앵커링이 추가된 릴레이 구조(relay-structured)와 수학적으로 동일합니다. 예상되는 결과는 더 나빠질 뿐, 더 좋아지지 않습니다. 구축할 가치가 없었습니다.

'read-after' + 불일치 에스컬레이션 (disagreement escalation)

설계: 두 에이전트가 독립적으로 추론합니다. 추론 과정 중에는 공유된 컨텍스트(shared context)가 없습니다. 두 에이전트가 모두 완료한 후, API 호출 없이 코드상에서 그들의 답을 비교합니다. 만약 두 답이 일치하면, 더 높은 신뢰도(higher-confidence)를 가진 답을 반환합니다. 만약 불일치한다면, 두 답과 두 멘탈 모델(mental model) JSON을 모두 확인하여 더 강력한 추론 체인(reasoning chain)을 선택하는 리졸버(resolver)를 실행합니다.

독립적인 추론(Independent reasoning)을 우선시한다는 것은 앵커링(anchoring)이 없음을 의미합니다. 비교 단계는 순수하게 코드로 이루어지므로, 에이전트들이 의견이 일치할 때는 토큰 비용이 발생하지 않습니다. 리졸버(resolver)는 실제 의견 불일치가 발생할 때만 실행되는데, 어려운 MATH 문제에 대해 5,000토큰 예산을 사용할 경우 이는 약 40%의 빈도로 나타납니다. 두 에이전트가 동의하는 쉬운 질문의 경우 비용은 단일 에이전트(single-agent)의 2배입니다. 리졸버가 필요한 더 어려운 질문의 경우 약 3.5배입니다. 두 경우의 가중 평균은 단일 에이전트 대비 약 2.9배이며, 이는 relay-structured 방식의 15배와 대조적입니다.

구현의 핵심:

def run_self_relay(question, n_rounds=2, model=DEFAULT_MODEL, budget_tokens=DEFAULT_BUDGET):
    # 두 에이전트가 독립적으로 추론하며, 공유된 컨텍스트(shared context)는 없음
    mm1, answer1, tokens1 = agent_call_structured("solver", question, [], [], model, budget_tokens)
...

결과

200개의 예시, MATH 레벨 4-5, claude-sonnet-4-6, 예산=5,000 토큰, 예비 결과:

조건	정확도 (Accuracy)	평균 토큰 (Avg tokens)
단일 에이전트 (single-agent)	63.0%	1,234
셀프 릴레이 (self-relay)	65.5%	3,290

self-relay는 토큰 비용이 2.7배인 상태에서 단일 에이전트보다 2.5포인트를 높였습니다. 이는 2포인트 상승을 위해 15배의 비용이 들었던 relay-structured와는 다른 프로필을 보여줍니다. 즉, read-after 아키텍처는 약 6분의 1 수준의 토큰 오버헤드로 유사한 정확도 이득을 얻습니다. 이 벤치마크에서의 불일치율(disagreement rate)은 약 40%였으며, 이는 예상 범위와 일치합니다.

토큰 비용은 단일 에이전트의 2.7배입니다. relay-structured는 15배였습니다. 동일한 5,000토큰 예산에서 self-relay는 리졸버가 필요할 때만 실행되기 때문에 훨씬 적은 비용으로 유사한 정확도 이점을 얻습니다.

이것이 프로덕션에 적용되는 방식

Self-relay는 오답의 비용이 두 번째 호출의 비용보다 큰 모든 곳에 적합합니다. 법률 문서 검토, 코드 보안 감사, 의료 분류 (medical triage), 금융 분석 등이 이에 해당합니다. 이러한 작업에서 두 개의 독립적인 추론 체인 (reasoning chains)을 실행하고, 두 답변이 불일치할 때만 중재 (arbitration) 비용을 지불하는 것은 매우 직관적인 신뢰성 패턴입니다.

실제 배포 방식은 항상 켜져 있는 리레이 (always-on relay)가 아니라 신뢰도 게이팅 (confidence-gating)입니다. 먼저 단일 에이전트 (single-agent)를 실행하고 멘탈 모델 (mental model) JSON에서 confidence 필드를 확인합니다. 만약 신뢰도가 임계값 (threshold)보다 높으면 답변을 반환합니다. 그렇지 않으면 Self-relay로 에스컬레이션 (escalate)합니다.

def answer_with_confidence_gate(question, threshold=0.75, model="claude-sonnet-4-6", budget=5000):
    # 1차 패스: 멘탈 모델을 사용한 단일 에이전트
    mm, answer, tokens = agent_call_structured("solver", question, [], [], model, budget)
...

질문의 약 25-30%가 임계값 미만으로 떨어지는 실제 워크로드 (workload)에서, 이는 평균 토큰 오버헤드 (token overhead)를 단일 에이전트 대비 2.7배에서 약 1.3-1.5배로 낮춰줍니다. 리레이는 실제로 필요한 요청에서만 실행됩니다.

다음에 시도해 볼 것

n=500 임계값은 트리거되지 않았으므로 (65.5%는 72.0% 미만임), 이 결과들은 n=200 상태로 유지됩니다. 다음으로 유용한 테스트는 신뢰도 임계값 (confidence threshold)을 교정 (calibrating)하는 것입니다. 어느 수준에서 Self-relay로의 에스컬레이션이 정답을 회복하며, 잘못된 에스컬레이션 비율 (false-escalation rate)은 어느 정도인지 확인해야 합니다. 또한 법률 검토나 코드 분석과 같은 도메인 특화 벤치마크 (domain-specific benchmark)를 통해, 불일치 패턴과 리졸버 (resolver)의 정확도가 경시대회 수학 이외의 영역에서도 유지되는지 스트레스 테스트 (stress-test)를 진행할 것입니다.

저장소는 github.com/bhj37193/relay에 있습니다. 평가 하네스 (eval harness)는 relay/eval_structured.py에 있으며, 모든 결과는 eval_structured_results.json에 포함되어 있습니다.