에이전트 아키텍처는 연산 할당 문제이다: 어드바이저 전략, 비용 곡선 프레임의 재귀적 적용

2026년 4월, Anthropic은 _"The advisor strategy: Give agents an intelligence boost"_라는 제목의 블로그 포스트를 게시하며, 그들이 운영 환경에서 A/B 테스트를 진행해 온 패턴의 이름을 명명했습니다: 저렴한 모델이 에이전트 루프(agent loop)를 처음부터 끝까지 실행하고, 저렴한 모델이 해결할 수 없는 결정에 부딪혔을 때만 비싼 모델에게 자문을 구하는 방식입니다. 그들은 구체적인 수치를 보고했습니다 — BrowseComp에서 Haiku + Opus 어드바이저 조합은 41.2%(Haiku 단독 사용 시 19.7%)의 성능을 보였으며, 이는 Sonnet을 전체 작업에 사용하는 비용의 15% 수준이었습니다.

2026년 5월 18일, Tobi Lutke (Shopify의 CEO)는 정확히 이와 동일한 방식의 자동 조사(autoresearch) 설정을 트윗했습니다: RTX 6000에서 로컬로 실행되는 Qwen 3.6 27B와, 방향성을 잡기 위해 주기적으로 GPT-5.5를 호출하는 작은 "어드바이저 확장 기능(advisor extension)"의 조합입니다. 이 트윗은 13,000회의 노출, 2,400개의 좋아요를 기록했으며, 수십 명의 엔지니어들이 이 패턴을 재현하거나 몇 시간 내에 오픈 소스 구현체를 구축하며 답글을 남겼습니다.

이 두 사례의 밑바탕에는 몇 달 전 발표된 Stanford HazyResearch의 Minions 논문이 있었으며, 이 논문은 동일한 패턴을 압축기-예측기(compressor-predictor) 프레임워크로 추상화했습니다: 작은 로컬 모델이 원시 컨텍스트(raw context)를 압축된 텍스트로 증류(distill)하면, 더 큰 원격 모델이 이를 바탕으로 추론하는 방식입니다. 그들은 자신들의 Deep Research 시스템이 API 비용의 26%만으로 프론티어 모델(frontier-model) 정확도의 99%를 회복했다고 보고했습니다.

약 6개월이라는 비슷한 기간 동안 세 개의 독립적인 흐름이 동일한 아키텍처로 수렴했습니다. 이 수렴 자체가 바로 핵심적인 이야기입니다.

이 포스트는 이에 대해 구체적인 주장을 펼칩니다: 어드바이저 전략은 LLM을 위해 발명된 새로운 패턴이 아닙니다. 이는 이 미니 시리즈 초반에 다루었던 비용 곡선(cost-curve) 프레임의 **세 번째 재귀(third recursion)**입니다 — 코드 검색(code retrieval)에는 RAG보다 grep이 더 낫다고 주장했던 아이디어, 그리고 grep 대체 도구(CodeGraph)가 필요로 하는 심볼 그래프(symbol-graph) 저장소에는 벡터 DB보다 SQLite + FTS5가 더 낫다고 주장했던 것과 동일한 아이디어입니다. 모델 오케스트레이션(model-orchestration) 계층에 적용되었을 때, 이 프레임은 어드바이저 전략을 만들어냅니다. 전략이 아키텍처라면, 프레임은 그 이유(why)입니다.

요약 (tl;dr) — Anthropic, Tobi Lutke, 그리고 HazyResearch는 2026년 초에 독립적으로 동일한 에이전트 패턴을 출시(또는 설명)했습니다. 즉, 저렴한 모델이 루프 (loop)를 실행하고, 비싼 모델은 결정이 필요한 시점에만 자문을 구하는 방식입니다. 이러한 수렴은 해당 패턴이 옳다는 증거입니다. 이 패턴이 옳은 이유는 이 시리즈의 첫 번째 포스트에서 다룬 비용 곡선 (cost-curve) 프레임을 검색 아키텍처 (retrieval-architecture) 계층이 아닌 모델 선택 (model-choice) 계층에 적용했기 때문입니다. 파트 B에서는 교차점 (crossover) 아래에서는 구축/유지 비용이 쿼리당 비용을 압도하기 때문에 grep+loop가 RAG보다 우수하다고 주장했습니다. 어드바이저 전략 (advisor strategy)은 토큰에 대해서도 동일한 형태를 주장합니다. 즉, 저가형 모델 실행자 (executor) 비용이 대부분의 저가치 작업(컨텍스트 읽기, 형식 변환, 재시도)에서 고가형 모델 어드바이저 (advisor) 비용을 압도하므로, 고가형 모델의 토큰은 오직 고가치 결정 지점에서만 소비되어야 한다는 것입니다. 동일한 프레임이 세 번째 계층에 적용된 것입니다.

이 포스트는 세 가지를 수행합니다: (1) 수렴하는 세 가지 흐름을 각각의 기여 내용과 함께 보고합니다; (2) 비용 곡선 재귀 (cost-curve recursion) 논증을 명시적으로 제시합니다 — L1 검색 (retrieval), L2 저장 (storage), L3 모델 오케스트레이션 (model orchestration); (3) 과장된 홍보에서 생략되는 주의 사항들(핸드오프 시 데이터 이그레스 (data egress), 평가 (eval)의 어려움, 실제 엔지니어링으로서의 핸드오프 계약 (handoff-contract) 설계, 하드웨어 현실성)을 매핑합니다. 이 미니 시리즈는 5개의 포스트를 통해, 비용 곡선 프레임이 에이전트 아키텍처의 세 계층에 걸친 메타 설계 법칙임을 보여주며 여기서 마무리됩니다.

출시 순서에 따른 세 가지 수렴하는 흐름

이러한 수렴은 개별적인 흐름보다 더 중요합니다. 각각은 독립적이었으며, 서로 6개월 이내의 기간 안에 출시되었고, 각기 다른 관점에서 동일한 아키텍처를 설명하고 있습니다. 이것이 바로 이 패턴이 단순히 한 팀의 설계 선호도가 아니라 실재하는 패턴임을 알 수 있는 방법입니다.

Anthropic의 공식 어드바이저 전략 (2026-04-09)

Anthropic 엔지니어링 블로그 _"The advisor strategy: Give agents an intelligence boost"_는 이 패턴을 제품화된 엔지니어링 프리미티브 (engineering primitive)로 정의합니다:

"Sonnet 또는 Haiku가 실행자 (executor)로서 작업을 엔드투엔드 (end-to-end)로 수행합니다... 실행자가 합리적으로 해결할 수 없는 결정 지점에 도달하면, 어드바이저 (advisor)로서 Opus에게 조언을 구합니다."

"어드바이저는 도구를 호출하거나 사용자에게 직접적인 출력을 생성하지 않으며, 오직 실행자에게 가이드라인만을 제공합니다."

보고된 실증적 수치:

구성 (Configuration)	벤치마크 (Benchmark)	점수 (Score)	비용 (Sonnet 엔드투엔드 대비)
Sonnet 단독 (어드바이저 없음)	SWE-bench Multilingual	(기준점)	1.00×
...

수치에 대한 두 가지 관찰 결과가 있습니다. 첫째: Sonnet + Opus 조합은 Sonnet 단독 사용 시보다 성능이 뛰어나면서도 비용은 더 저렴합니다. 이는 단일 축의 트레이드오프 (trade-off)가 아니라, 파레토 개선 (Pareto improvement)입니다. 둘째: Haiku + Opus 조합은 Haiku 단독 점수를 두 배로 높이면서도 비용은 Sonnet의 15% 수준입니다. 이것이 바로 복합적인 이득 (compound gain) — 즉, 더 나으면서 동시에 더 저렴해지는 것입니다.

블로그의 구체적인 세부 사항: 어드바이저의 출력은 일반적으로 400–700 토큰 (tokens) 입니다. 즉, 전체 솔루션이 아닌 짧은 계획 (plan)입니다. 이는 비용 곡선 (cost curve)이 시사하는 바를 설계 단계에서 명시적으로 드러낸 것입니다. 즉, 어드바이저는 작업을 수행하기 위해서가 아니라 방향을 재설정하기 위해 존재합니다.

Tobi Lutke의 개인적 실험 (2026-05-18)

Tobi Lutke (Shopify의 CEO)가 X에 게시한 내용:

"로컬 Qwen 3.6 26B 모델로 자동 조사 (autoresearch)를 수행하면서 매우 좋은 결과를 얻었습니다. 주기적으로 GPT 5.5에 아이디어를 물어볼 수 있게 해주는 간단한 'vibed pi 어드바이저' 확장 프로그램을 사용한 덕분입니다. 저는 이 방향이 많은 가치가 있다고 생각합니다."

Tobi의 설정은 Anthropic의 제품화된 패턴을 오픈 소스 방식으로 미러링(mirroring)한 것이며, 두 가지 아키텍처 변형을 보여줍니다:

지역성 (Locality): 실행자는 Anthropic의 API가 아닌 본인의 하드웨어(RTX 6000에서 실행되는 Qwen 3.6 27B)에서 실행됩니다. 기본적으로 로컬 우선 (Local-first) 방식입니다.
프런티어 모델 선택 (Frontier model choice): 어드바이저는 Opus (Anthropic)가 아닌 GPT-5.5 (OpenAI)입니다. 이 패턴은 어드바이저 측면에서 모델에 구애받지 않습니다 (model-agnostic).

하드웨어 측면의 주의 사항은 실재하며 명시할 가치가 있습니다. RTX 6000은 소비자용 하드웨어가 아닌 전문가급 (professional-grade) 장비입니다. 자동 조사 (autoresearch) 길이의 컨텍스트 (context)를 가진 27B-dense 모델은 노트북으로 처리할 수 있는 작업량이 아닙니다. 이 패턴은 범용 인프라 (commodity infrastructure) 상의 아키텍처 (architecture) 수준에서 재현 가능하지만, Tobi가 보여준 특정 설정은 실제적인 투자가 필요합니다.

Tobi의 트윗이 올라온 지 몇 시간 만에, 개발자 Rob Zolkos는 pi-lifeline을 공개했습니다. 이는 해당 트윗에서 명시적으로 영감을 받은 오픈 소스 에스컬레이션 (escalation) 확장 기능으로, 다음과 같은 합리적인 기본값 (defaults)을 제공합니다: 첫 번째 어드바이저 (advisor) 호출 전 최소 5라운드 유지, 3회 연속 실패 시 자동 에스컬레이션, 6라운드 후 정체 (plateau) 감지, 세션당 최대 10회의 어드바이저 호출, 기본 어드바이저 모델은 GPT-5.5. 이것은 단순한 한 줄의 설정이 아니라, 핸드오프 계약 (handoff contract)에 대한 _엔지니어링 (engineering)_이며, 이에 대해서는 나중에 다시 다루겠습니다.

Stanford HazyResearch Minions (2025–2026 출판 예정)

Tobi의 트윗에 달린 답글에서 링크된 내용입니다. Dan Biderman은 HazyResearch의 Minions 논문 (arXiv 2512.21720)을 지목했는데, 이 논문은 해당 패턴을 _압축기-예측기 프레임워크 (compressor-predictor framework)_로 추상화합니다:

"더 작은 '압축기 (compressor)' 언어 모델 (LM)(로컬에서도 실행 가능)이 원시 컨텍스트 (raw context)를 압축된 텍스트로 증류 (distill)하며, 이를 더 큰 '예측기 (predictor)' 언어 모델이 소비합니다."

Minions 논문의 구체적인 수치적 기여도는 다음과 같습니다: 그들의 딥 리서치 (Deep Research) 시스템에서, 로컬 3B-파라미터 압축기는 API 비용의 26%만으로 프런티어 모델 (frontier-model) 정확도의 99%를 회복합니다. 이것이 바로 경험적 경계 (empirical bounds)를 가진 동일한 아키텍처의 학술적 버전입니다.

HazyResearch의 프레임워크가 Anthropic의 제품 블로그보다 추가로 제공하는 세 가지 사항은 다음과 같습니다:

압축기 (Compressor)가 반드시 27B일 필요는 없습니다 — 작업에 따라 컨텍스트 증류 (Context distillation)를 위해 3B 모델로도 충분합니다. 압축기의 크기가 작아질수록 더 로컬 (Local) 환경에서 실행할 수 있습니다.
비용 회복 곡선 (Cost-recovery curve)은 특정한 형태를 가집니다 — 26%의 비용으로 99%의 정확도를 달성하는 것은 선형적이지 않습니다. 이는 Anthropic이 제품 형태로 보고한 것과 동일한 파레토 개선 (Pareto improvement)입니다: 단순히 더 저렴해지는 것이 아니라, 더 뛰어나면서도 더 저렴해지는 것입니다.
일반적인 프레임워크는 "압축 후 결정 (Compress then decide)"입니다 — 이는 "실행자 (Executor) + 어드바이저 (Advisor)"보다 약간 더 넓은 프레임입니다. 왜냐하면 압축기가 시작 시점에 한 번 실행되고 예측기 (Predictor)가 마지막에 한 번 실행되며, 에스컬레이션 루프 (Escalation loop)가 없는 경우까지 포함하기 때문입니다. 어드바이저 전략은 압축이 반복적으로 일어나는, "압축 후 결정"의 스트리밍 (Streaming) 버전입니다.

세 가지 독립적인 확인이 중요한 이유

각 스레드는 서로 다른 관점에서 도출되었습니다:

Anthropic: 제품 엔지니어링 (Product engineering). 모델을 소유하고, 워크로드 (Workload)를 설계하며, 현장 지표 (Field metrics)를 보고합니다.
Tobi Lutke: 개인 실무자. 서로 다른 모델 제공업체 (Qwen + GPT-5.5), 서로 다른 호스팅 (Local + Cloud), 서로 다른 워크로드 (코딩 벤치마크가 아닌 자동 연구 (Autoresearch))를 사용합니다. Anthropic과 협력하지 않고도 이 패턴을 재현했습니다.
HazyResearch: 학술 연구. 서로 다른 프레임워크 (압축기-예측기), 서로 다른 시간 지평 (논문이 Anthropic의 블로그보다 앞섬), 서로 다른 비용-품질 측정 방법론을 가집니다.

세 가지 독립적인 관점이 동일한 아키텍처적 해답을 내놓을 때, 그 설계는 해당 작업을 후원하는 주체가 누구인지와 상관없이 견고합니다. 이것이 바로 수렴을 증거로 삼는 논거입니다 — 이 패턴은 실재하며, 단순히 한 조직의 선호도에 따른 결과가 아닙.

이제 흥미로운 질문은 이 패턴이 작동하느냐가 아니라 (수렴이 이를 증명합니다), 왜 작동하느냐입니다. 그리고 그 질문에 대한 명확한 답은 이 미니 시리즈의 앞부분에 나와 있습니다.

비용 곡선의 재귀: 동일한 프레임, 세 번째 레이어

Piece B (이 시리즈의 첫 번째 포스트)에서는 LLM 기반 코드 검색(code retrieval)이 비용 곡선 (cost curve) 위에 있다고 주장했습니다. 인덱스 기반(index-based) 접근 방식은 높은 구축 비용(build cost)과 초선형적(super-linear) 유지 비용(maintain cost)을 지불하는 반면, 툴 루프(tool-loop) 접근 방식은 쿼리당 비용(per-query cost)만 지불합니다. 대부분의 프로젝트 규모보다 훨씬 높은 지점에 위치한 교차점(crossover point) 아래에서는 툴 루프가 승리합니다. 그 지점을 넘어서면 인덱스가 이득을 줍니다.

이 논리는 일반화될 수 있습니다. 다른 에이전트 아키텍처(agent-architecture) 결정 사항에 적용하더라도, 동일한 프레임워크는 계속해서 올바른 판단을 도출해냅니다.

레이어 1 — 검색 아키텍처 (Layer 1 — Retrieval architecture) (Piece B)

	툴 루프 (Tool-loop) (grep + LLM iteration)	인덱스 (Index) (vector RAG)
구축 비용 (Build cost)	0	리포지토리 크기에 따라 초선형적 (super-linear)
...
결론: 대부분의 리포지토리의 경우, 구축/유지 비용이 쿼리당 절감액보다 더 크기 때문에 툴 루프가 승리합니다. Anthropic은 Claude Code를 위해 인덱스가 아닌 grep+Glob+Read 방식을 선택했습니다.

레이어 2 — 인덱스 저장소 (Layer 2 — Index storage) (C2, CodeGraph에 대한 제1원리적 분석)

실제로 곡선을 넘어 인덱스가 필요한 경우 — 즉, CodeGraph의 영역에 도달한 경우 — 다음 결정 사항은 어떤 저장 계층(storage layer)을 사용할 것인가입니다.

	FTS5 + SQLite (CodeGraph)	벡터 DB (Vector DB) (Chroma / Pinecone)
구축 비용 (Build cost)	소스 크기에 따라 선형적 (linear), 파싱(parse)만 수행	초선형적 (super-linear) (모든 파일에 대해 청크(chunk) 생성 + 임베딩(embed))
...
CodeGraph의 쿼리는 정확한 조회(exact lookups) (심볼 X 찾기, A→B 추적, Y의 호출자 찾기 등)이므로 FTS5가 승리합니다. 레이어 1과 동일한 프레임입니다: 워크로드(workload)가 요구하는 비용만 지불하십시오.

레이어 3 — 모델 오케스트레이션 (Layer 3 — Model orchestration) (본 포스트 — 어드바이저 전략)

모델 간의 토큰 할당(token allocation)에 동일한 프레임을 적용해 보겠습니다.

	Cheap-only (Haiku 단독, Qwen 단독)	Expensive-only (Sonnet/Opus 엔드투엔드)	Executor + Advisor
대량 작업 시 토큰당 비용	낮음	높음	낮음 (저렴한 executor가 토큰의 90% 이상을 처리)
...

대부분의 에이전트 작업은 마지막 열에 해당합니다. 어드바이저 전략(advisor strategy)이 승리하는 이유는 Layer 1에서 grep+loop가 승리하는 것과 동일한 구조적 이유 때문입니다: "대량 (bulk)" 작업의 비용이 "의사결정 (decision)" 작업의 비용을 압도하므로, 아키텍처는 대량 경로에는 저렴한 도구를 배치하고 의사결정 경로에는 비싼 도구를 예약해야 합니다.

메타 설계 프레임으로서의 비용 곡선 (Cost-curve)

일반화된 내용을 명시적으로 기술하자면 다음과 같습니다: 아키텍처가 "많은 저가치 작업 + 적은 고가치 작업" 구조를 가질 때마다, 두 작업 모두에 비싼 도구를 일률적으로 적용하는 것은 저가치 작업에 대해서도 높은 비용을 지불하게 만듭니다. 올바른 설계는 두 경로를 분리하고, 대량 경로에는 저렴하지만 충분히 괜찮은 (cheap-but-good-enough) 도구를 사용하는 것입니다.

이것은 비용 곡선 프레임이 본 시리즈에서 적용된 모든 계층에서 만들어낸 설계 규칙입니다. 이는 LLM에만 국한된 것이 아닙니다. 데이터베이스 커뮤니티에서는 이를 "쿼리 클래스를 만족하는 가장 저렴한 인덱스를 사용하라"고 부르고, 시스템 커뮤니티에서는 이를 "계층형 스토리지 (tiered storage)"라고 부르며, 칩 설계 커뮤니티에서는 이를 "메모리 계층 구조 (memory hierarchy)"라고 부릅니다. LLM 엔지니어링 버전은 어드바이저 전략과 그 친척 격인 검색 아키텍처(retrieval-architecture)들입니다.

이것이 본 시리즈의 다섯 개 포스트가 주장하는 메타 설계 법칙입니다. 이 논증의 힘은 수렴(convergence)에서 나옵니다. 즉, 동일한 프레임의 세 가지 독립적인 재귀적 적용이 매번 올바른 아키텍처를 만들어냈다는 점입니다. 이것은 우연이 아니라, 프레임이 제 역할을 수행하고 있는 것입니다.

이것이 Piece B의 소스 코드 분석으로부터 검증하는 것

Claude Code의 소스 코드를 분석한 Piece B의 보고서는 특정 발견 사항을 전달했습니다: Explore 서브에이전트(subagent)는 non-ant 빌드(외부 사용자) 시 Sonnet이나 Opus가 아닌 Haiku에서 실행됩니다. Piece B의 추론 섹션은 다음과 같이 관찰했습니다: