논문 전문(2,423행 추출본)에 graph라는 단어는 0회 나온다. 논문의 어휘는 topolog- 계열(어간 11회)과 orchestrat- 계열(어간 39회)이다. "그래프 엔지니어링"이라는 이름표는 논문이 붙인 것이 아니다. ✔ 원문
유통 중인 수치 상당수가 v1(2025-12-09) 초록의 값이다. 구성 수 180→260, 설명력 R²=0.513→0.373으로 v3에서 바뀌었다. ✖ 불일치
"에이전트 3~4개 권장"은 원문에 없다. 원문은 "3~4개를 넘어서면 에이전트당 추론 용량이 감당 불가하게 얇아진다"는 상한 경고다. ✖ 불일치
논문은 무엇을 했나
WHAT THE PAPER ACTUALLY DID
「Towards a Science of Scaling Agent Systems」는 구글 리서치·구글 딥마인드·MIT 연구진 20인이 낸 논문이다. ✔ 원문 문제의식은 단순하다 — 멀티에이전트 시스템이 실제로 언제 이기고 언제 지는지를, 주장이 아니라 통제된 측정으로 알아보자는 것이다. 논문 스스로 "more agents is all you need"라는 기존 주장을 대비 대상으로 지목한다. ✔ 원문
설계는 다음과 같다. 아키텍처 5종(단일 · 독립 · 중앙집중 · 분산 · 하이브리드) × LLM 3계열(OpenAI · Google · Anthropic) × 에이전틱 벤치마크 6종을 조합해 N=260개 구성을 돌렸다. 도구·프롬프트·연산량을 표준화해 아키텍처 효과만 분리하는 것이 통제의 핵심이다. ✔ 원문
용어오케스트레이터-워커(orchestrator–worker)가 뭔가요?▶
Claude Code에서 서브에이전트를 띄워 본 적이 있다면 이미 써 본 구조입니다. 오케스트레이터는 일을 쪼개 나눠 주고 결과를 모아 합치는 역할, 워커는 받은 조각을 처리해 돌려주는 역할입니다. 워커끼리는 서로 이야기하지 않고, 모든 통신이 오케스트레이터를 거칩니다.
이 구조의 값어치는 속도가 아니라 검문소에 있습니다. 결과가 합쳐지기 전에 반드시 한 곳을 지나가므로, 그 지점에서 틀린 결과를 걸러낼 수 있습니다. 대신 대가가 있습니다 — 오케스트레이터가 병목이 되고, 지시·보고를 오가느라 토큰이 더 듭니다. 반대로 워커들을 서로 연결하면(분산) 병목은 사라지지만 검문소도 함께 사라집니다.
※ 이 카드는 일반 개념 설명이다. 이 논문이 측정한 구체 수치·구성은 본문의 소스 등급을 따른다.
| 아키텍처 | 통신 구조 (논문 정의) | 등급 | 실무자 관점 메모 |
|---|---|---|---|
| 단일(SAS) | 에이전트 1개. 논문에서 |A|=1로 정의 | ✔ 원문 | 이 글에서 가장 중요한 줄. 나머지 넷은 전부 이것과 비교당한다 |
| 독립 | 동료 간 통신 없이 각자 수행하고 집계기에만 보고 | ✔ 원문 | 가장 짜기 쉽고 가장 위험하다 — 오류 증폭이 제일 크게 측정된 구조 |
| 중앙집중 | 오케스트레이터↔에이전트 링크만 존재 | ✔ 원문 | 오케스트레이터가 집계 방식·거부권·중단 조건을 쥔다. 느리지만 오류를 잡는다 |
| 분산 | 에이전트 간 직접 통신(오케스트레이터 없음) | ✔ 원문 | 중앙 병목이 없는 대신 검증 병목도 없다 |
| 하이브리드 | 중앙집중 + 제한적 동료 간 통신 | ✔ 원문 | 가장 복잡한 구조. 토큰 효율은 5종 중 최하로 측정됐다(뒤 표) |
| 벤치마크 6종 | BrowseComp-Plus · Finance-Agent · PlanCraft · Workbench · SWE-bench Verified · Terminal-Bench | ✔ 원문 | 웹 탐색·금융·계획·업무·SWE·터미널. 코딩 하나로 일반화하지 않은 점이 이 논문의 강점 |
남는 발견 — 여기까지는 진짜다
WHAT SURVIVED THE CHECK
먼저 원문 대조를 통과한 것부터 적는다. 유행의 포장을 걷어내도 이 논문에는 실무자가 가져갈 것이 남는다.
능력 천장(capability ceiling). 단일 에이전트 정확도가 이미 45%를 넘는 과제에서는 에이전트를 더 붙일수록 수익이 마이너스로 돌아선다. 조정 비용이 남은 개선 여지를 넘어서기 때문이다(계수 β=−0.236, p=0.004). ✔ 원문 실무 번역은 이렇다 — 이미 어느 정도 되는 일에 에이전트를 더 붙이는 것은 대체로 손해다.
오류 증폭. 독립형은 트레이스 수준 오류를 17.2배로 증폭시킨다. 중간에 아무도 걸러 주지 않으니 개별 실수가 최종 산출물까지 연쇄한다. 중앙집중은 검증 병목을 강제해 이를 4.4배로 억제한다. ✔ 원문
용어오류 증폭(error amplification)이 뭔가요?▶
에이전트 하나가 낸 작은 실수가 다음 단계의 입력이 되면서 커지는 현상입니다. 사람이 매 턴 결과를 보는 대화형 사용에서는 잘 안 보입니다 — 이상하면 우리가 바로 잡아 주니까요. 무인 실행이나 멀티에이전트에서 문제가 됩니다. 아무도 안 보는 사이에 틀린 중간 결과가 다음 에이전트에게 "사실"로 건네집니다.
증폭 배수는 "개별 단계의 오류율 대비 최종 산출물의 오류율이 몇 배인가"로 잽니다. 배수가 1에 가까우면 오류가 퍼지지 않고 그 자리에서 멈춘다는 뜻이고, 크면 한 번의 실수가 전체를 망친다는 뜻입니다. 배수를 낮추는 방법은 대체로 하나입니다 — 합치기 전에 검사하는 지점을 만드는 것. 그 지점이 곧 병목이므로, 속도와 정확도를 맞바꾸는 결정이 됩니다.
※ 이 카드는 일반 개념 설명이다. 17.2배·4.4배 같은 이 논문의 측정치는 본문의 소스 등급을 따른다.
구조와 과제의 정합. 단일 대비 성능 변화는 분해 가능한 금융 추론에서 +80.8%, 순차 계획에서 −70.0%까지 벌어진다(계획 과제 전반 −39%~−70%). ✔ 원문 같은 아키텍처가 어떤 과제에선 최선, 어떤 과제에선 최악이다. 논문이 제시한 예측 모델은 미지 과제의 87%에서 최적 아키텍처를 맞혔다. ✔ 원문
여기까지가 원문에서 확인한 것이다. 문제는 이 논문을 인용한다고 말하는 글들이 실제로 인용하고 있는 것이 이 v3가 아니라는 점이다.
유통 중인 수치는 넉 달 전 판본이다
THE STALE-VERSION PROBLEM
이 논문은 세 번 올라왔다. v1(2025-12-09), v2(2025-12-17), 그리고 v3(2026-04-08). ✔ 원문 타임라인에서 도는 수치를 v1 초록과 맞춰 보면 거의 그대로 겹친다. 즉 대부분의 게시물은 초판을 읽고 쓴 글이거나, 초판을 읽고 쓴 글을 읽고 쓴 글이다. △ 보도 — 어떤 수치가 유통 중인지는 2차 게시물 관찰이며, 이 글이 1차 소스로 확인한 것은 v1과 v3의 값이 다르다는 사실뿐이다.
| 항목 | 유통 중인 값 (출처 대조 결과) | 현행 v3 · 2026-04 | 판정 |
|---|---|---|---|
| 구성 수 | 180 configurations — v1 초록에서 확인 | N=260 | ✖ 불일치 |
| 설명력 R² | 0.513 — v1 초록에서 확인 | 0.373 (ACI 지표 시 0.413) | ✖ 불일치 |
| 병렬 과제 이득 | +80.9% — v1 초록에서 확인 | +80.8% | ✖ 불일치(경미) |
| 순차 과제 손실 | 39~70% 저하 — v1 초록에서 확인 | −39%~−70% | ✔ 원문 유지 |
| 능력 천장 계수 β | −0.408 — v1 초록에 없다. 어느 판본에서 왔는지 우리는 확인하지 못했다 | −0.236 (p=0.004) | ✖ 불일치 — v3에 −0.408은 없음 |
가장 눈여겨볼 줄은 R²다. 0.513에서 0.373으로 내려갔다는 것은, 논문이 제시한 예측 모델의 설명력이 개정 과정에서 상당히 떨어졌다는 뜻이다. ✔ 원문 "스케일링 법칙"이라는 표현에 실리는 무게가 초판과 현행에서 같을 수 없다. 그런데 유행은 초판 수치로 굴러가고 있다.
"180"이라는 숫자는 v3에도 남아 있다 — 다만 의미가 다르다. v3에서 180은 비용 추적이 완비된 4개 벤치마크의 부분집합을 가리키는 수이고, 전체 구성 수는 260이다. ✔ 원문 숫자만 검색해서 옮기면 정확히 이 지점에서 틀린다.
반대로 우리도 확인하지 못한 것을 적어 둔다. 유통본이 인용하는 β=−0.408은 v3에 없지만, v1 초록에도 없다. 어느 판본·어느 표에서 나온 값인지 이 글은 특정하지 못했다. 따라서 "v1 값"이라고 부르지 않고 "출처 미확인 값"이라고만 쓴다. 확인되면 추기한다.
가장 큰 왜곡 — "3~4개 권장"은 정반대 문장이다
THE INVERTED SENTENCE
유행 속에서 가장 자주 보이는 처방이 "에이전트는 3~4개가 최적"이다. 원문의 해당 문장은 이렇다.
"beyond 3–4 agents, per-agent reasoning capacity becomes prohibitively thin" — 3~4개를 넘어서면 에이전트당 추론 용량이 감당 불가하게 얇아진다. ✔ 원문
이것은 권장이 아니라 고정 예산 아래에서의 붕괴 지점 경고다. 총 토큰 예산을 맞춰 놓고 에이전트 수를 늘리면 1인당 몫이 줄어들고, 그 지점이 3~4개 언저리라는 관찰이다. 더구나 논문은 "최적 에이전트 수는 모델 용량과 조정 전략에 따라 달라진다"고 별도로 못박는다. ✔ 원문 고정 상수를 처방한 적이 없다.
왜곡의 방향이 일정하다는 점을 짚어 둘 만하다. 경고를 처방으로 바꾸면 바로 쓸 수 있는 팁이 되고, 팁은 잘 퍼진다. 검증하는 쪽이 아니라 퍼뜨리는 쪽에 유리한 변형이다. 이건 편집자의 해석이며, 논문이 말한 바는 아니다.
① "Head of Claude Code가 85%라고 말했다" 류의 인용문 ✖ 불일치
복수 계정이 토씨까지 동일한 문구로 유포 중이나 △ 보도, 이 논문 v3 전문(2,423행 추출본)에서 해당 문구도 85%라는 수치도 찾지 못했다. 논문이 출처인 것처럼 함께 붙어 다니지만 논문에는 없다. 원 발화의 1차 출처가 따로 존재하는지는 아직 확인하지 못했으므로 "허위"라고 단정하지 않는다 — "이 논문 근거로는 확인 불가"가 현재 정확한 상태이며, 검증 노트의 대기 항목으로 남겼다.
② 토큰 1,000개당 처리량 "67 / 21 / 14" ✖ 불일치
수치 자체는 원문에 있다. ✔ 원문 그러나 원문의 값은 다섯 개다 — 단일 67.7, 독립 42.4, 분산 23.9, 중앙집중 21.5, 하이브리드 13.6. 유통본은 이 중 세 개(단일·중앙집중·하이브리드)만 골라 반올림했다. △ 보도 빠진 독립형 42.4를 되돌려 놓으면 "멀티에이전트는 무조건 3~5배 비효율"이라는 인상이 성립하지 않는다. 체리피킹으로 판정한다.
③ "고정 예산 4,800토큰" ✖ 불일치
원문 표현은 "total reasoning-token budget (mean 4,800 tokens per trial)" — 시행당 평균이다. 총 토큰을 맞춘 통제 설계라는 서술은 별도로 존재하지만, 4,800이라는 숫자 자체는 고정 상한이 아니다. 이 논문의 예산 설계를 비판할 때(해외 커뮤니티에서 제기된 지점) 이 구분이 없으면 비판도 과녁을 빗나간다.
④ 이름표: "그래프 엔지니어링" ✖ 불일치
논문 전문에 graph는 0회, context engineering도 0회다. 논문이 쓰는 말은 topolog- 계열 11회(topology 8 · topologies 3)와 orchestrat- 계열 39회(orchestrator 23 · orchestration 11 · orchestrators 3 · orchestrated 2)다. pdftotext 추출본 기준 단어 단위 계수이며, 어간 계수와 단어 계수를 구분해 적는다 — 이 구분을 뭉개면 이 기사가 지적하는 것과 같은 종류의 오류가 된다. 유행의 이름은 논문 밖에서 붙었다. 이름이 나쁘다는 뜻은 아니다 — 다만 논문을 근거로 그 이름을 정당화할 수는 없다.
실무 유의점
FIELD NOTES — 멀티에이전트를 직접 굴리는 사람 기준
arXiv 링크는 버전을 숨긴다 — /abs/2512.08296은 항상 최신판으로 리다이렉트되므로, 작년에 읽은 사람과 오늘 읽는 사람이 다른 문서를 같은 이름으로 부른다. 유통 중인 수치가 초판 값과 겹친다는 관찰은 2차 게시물 기준이다 △ 보도. 논문 수치를 인용할 땐 vN과 개정일을 함께 적는 습관을 들일 것. 이 매거진이 모든 스냅샷에 확보 시각을 박는 이유와 같다.
원문은 그 지점을 붕괴가 시작되는 상한으로 적었고, 최적 수는 모델 용량·조정 전략에 따라 달라진다고 명시했다. 실무 함의는 개수가 아니라 예산이다 — 총 토큰이 고정된 상태에서 에이전트를 늘리는 것은 같은 파이를 더 잘게 자르는 일이다. 늘리기 전에 물어야 할 것은 "몇 개가 좋은가"가 아니라 "1인당 몫이 아직 충분한가"다.
이 글에서 가장 바로 쓸 수 있는 줄이다. 멀티에이전트를 붙이기 전에 단일로 먼저 재라. 기준선이 없으면 개선인지 퇴보인지도 모른 채 복잡도만 늘린다. 단, 45%는 이 논문의 벤치마크 6종에서 관측된 수치이고 당신 과제의 상수가 아니다 — "기준선을 먼저 잰다"가 옮겨갈 원칙이고, 45%는 옮겨가지 않는다.
병렬로 쫙 펼치는 구조가 빠르고 시원해 보이지만, 논문 측정에서 오류 증폭이 가장 큰 것이 정확히 그 구조(독립)다. 자작 하네스에서 서브에이전트 결과를 합치기 전에 검사하는 지점이 없다면, 지금 사고 있는 것은 속도가 아니라 보이지 않는 오류다. 승인 게이트·체크포인트와 같은 논리다 — 지웠을 때 무엇이 막히는가로 판별하라.
예측 모델이 설명하는 분산이 절반에 못 미친다는 뜻이다. 최적 아키텍처를 87% 맞혔다는 결과와 함께 읽어야 균형이 맞는다 — 순위는 꽤 맞히지만 성능값 자체는 잘 못 맞힌다. 다만 균형을 위해 덧붙이면, 논문 자신은 과제 기반 지표(ACI)로 바꿨을 때의 0.413을 향후 주 지표로 권고한다. ✔ 원문 초록이 앞세우는 값은 0.373이다. "스케일링 법칙"이라는 단어에 물리학 같은 무게를 싣지 말 것. 논문 제목도 법칙(law)이 아니라 "~을 향하여(Towards)"다.
검증 노트
LAB LOG — 이 매거진은 돌려본 것만 "검증됨"이라 부른다
[ OK 08-02 ] abs 페이지 직접 수집 — v3(2026-04-08) 및 v1(2025-12-09) 초록 확보·대조
[ OK 08-02 ] PDF 원문 확보 — 44쪽, pdftotext -layout로 2,423행 텍스트 추출
[ OK 08-02 ] 라이선스 확인 — nonexclusive-distrib/1.0 (CC BY 아님) → 전문 번역 정본 미생성
[ OK 08-02 ] 핵심 수치 7건 대조 — 45% / 17.2× / 4.4× / -39~-70% / 87% / 5아키텍처 / 3계열 일치
[ OK 08-02 ] 구판 대조 — 유통 수치 4건이 v1 초록 값과 일치 (180->260 / 0.513->0.373 / 80.9->80.8 / -39~-70 유지)
[ OK 08-02 ] 용어 계수(단어 단위 집계 · 어간 합계) — graph=0, context engineering=0, topolog-=11, orchestrat-=39
[ OK 08-02 ] 인용문 대조 — "Head of Claude Code 85%" 문구·수치 전문에서 미발견
[ PENDING ] v2(2025-12-17) 대조 — 어느 개정에서 수치가 바뀌었는지 특정
[ PENDING ] b=-0.408 출처 추적 — v1/v2 본문·표에 실재하는 값인지 확인
[ PENDING ] 부록 A 확인 — Intelligence Index 산식과 모델 티어 매핑
[ PENDING ] 저자 공개 코드·데이터 확인 — 재현 가능 여부
[ PENDING ] 자체 재현 — 벤치마크 1종으로 아키텍처 간 낙차 재측정
[ PENDING ] 인용문 출처 추적 — "Head of Claude Code" 발화의 1차 출처 존재 여부
$ verify status
docs_verified=7/7 docs_pending=5 reproduced=0/1 # 결과는 이 글에 추기(追記)로 갱신한다
그래서 무엇을 가져갈까
WHERE IT FITS
이 글은 논문을 깎으려고 쓴 것이 아니다. 통제된 조건에서 260개 구성을 돌려 아키텍처와 과제의 정합을 측정한 작업은 드물고 값지다. 깎이는 것은 논문과 유행 사이의 거리다. 이름표는 논문 밖에서 붙었고, 수치는 넉 달 전 판본이며, 가장 널리 퍼진 처방은 원문에서 경고였다.
실무자가 가져갈 것은 세 줄로 줄어든다. 단일로 먼저 재고, 합치기 전에 검사하는 지점을 두고, 에이전트 수가 아니라 1인당 예산을 본다. 이 셋은 v1이든 v3든 흔들리지 않았다.
다만 이 글이 아직 하지 않은 일도 분명히 해 둔다. 우리는 이 논문을 재현해 보지 않았다. 위 랩 로그의 대기 항목 다섯 개가 끝나기 전까지 이 기사의 배지는 "부분 검증"에 머문다. 특히 ①어느 개정에서 수치가 바뀌었는지와 ②문제의 인용문에 1차 출처가 존재하는지는 결론을 바꿀 수 있는 항목이므로, 확인되는 대로 이 글에 추기한다. 소리 없이 고치지 않는다.