본문으로 건너뛰기

토큰을 더 준다고 더 잘하지 않는다 — 같은 예산에서 76점을 89점으로

홍승아10분

1. 이 글은 무엇에 관한 글인가

Anthropic의 플랫폼 엔지니어링 리드 Katelyn Lesse와 플랫폼 프로덕트 리드 Angela Jiang의 발표 토큰에게도 각자의 역할이 필요합니다 — Anthropic의 에이전트 설계법을 보고 정리한 글입니다. 한 줄로 요약하면 이렇습니다.

토큰 예산을 늘리는 건 전략이 아닙니다. 같은 예산 안에서 토큰에 서로 다른 역할을 주는 것이 전략입니다.

발표가 보여주는 실측치는 이렇습니다. 고정 예산 60만 토큰, 금융 분석 벤치마크, 같은 모델. 76점에서 89점. 예산은 한 톨도 늘지 않았습니다.

이 블로그에서 이어온 축으로 보면 위치가 분명합니다.

앞의 두 글이 "총량"에 관한 이야기였다면, 이 발표는 배분 에 관한 이야기입니다.

2. 토큰은 대체재가 아니다

발표의 출발점은 익숙한 직관을 깨는 데서 시작합니다.

흔한 가정:  성능이 부족하다 → 토큰을 더 준다 → 성능이 오른다
            (토큰은 균질한 자원이고, 많을수록 좋다)
 
실제:       성능이 부족하다 → 토큰을 더 준다 → 같은 실수를 더 길게 한다

브루트 포스로 예산만 키우면 무슨 일이 벌어지는지는 에이전트를 돌려본 사람이라면 다 압니다. 잘못된 방향으로 출발한 실행은 예산이 크면 더 멀리 갑니다. 추론을 더 오래 한다고 해서 초반의 잘못된 전제가 스스로 교정되지는 않습니다. 오히려 그 전제 위에 쌓인 토큰이 많아져서, 뒤집기가 더 어려워집니다.

그래서 발표의 표현이 정확합니다 — 모든 토큰이 같은 토큰이 아닙니다. 같은 1,000토큰이라도

  • 실행에 쓰인 1,000토큰
  • 실행 전에 방향을 잡는 데 쓰인 1,000토큰
  • 산출물을 채점하는 데 쓰인 1,000토큰

은 기대 효용이 다릅니다. 예산이 고정이라면, 이 비율 이 곧 설계입니다.

3. 세 가지 역할 — 조언 · 평가 · 회고

발표는 실행(execution) 외에 세 가지 역할을 제안합니다.

역할하는 일언제 토큰을 쓰나
조언 (Advising)실행 전·중에 방향을 잡아준다실행 앞쪽
평가 (Grading)나온 산출물을 기준에 대고 채점한다실행 뒤쪽
회고 (Dreaming)끝난 작업에서 배운 것을 남긴다실행 바깥

세 역할이 각각 다른 지점의 낭비를 막습니다.

조언 — 앞쪽의 낭비를 막는다

가장 비싼 실패는 방향이 틀린 채로 끝까지 간 실행 입니다. 조언 토큰은 실행이 길게 가기 전에 개입합니다. 실행하는 쪽은 저렴하고 빠른 모델이어도 되고, 판단이 필요한 갈림길에서만 더 똑똑한 쪽에 물어봅니다.

평가 — 뒤쪽의 낭비를 막는다

"다 했습니다"라고 말하는 에이전트와 실제로 기준을 통과한 산출물 은 다릅니다. 평가 토큰은 별도의 채점자가 기준표에 대고 항목별로 점수를 매기고, 미달 항목을 실행 쪽에 돌려줍니다. 여기서 중요한 건 채점자가 실행자와 컨텍스트를 공유하지 않는다는 점 입니다. 자기가 쓴 답을 자기가 채점하면 후하게 줍니다.

회고 — 다음 실행의 낭비를 막는다

세 번째가 제일 낯선 역할입니다. 회고 토큰은 이번 작업의 산출물이 아니라 다음 작업의 입력 을 만듭니다. 이번에 막혔던 지점, 통했던 접근, 잘못된 가정을 정리해서 남깁니다. 이번 세션에서는 순수 비용이고, 다음 세션부터 회수됩니다.

세 역할을 한 줄로 묶으면 이렇게 됩니다.

조언 = 틀린 방향으로 가는 토큰을 줄인다      (이번 실행에서 회수)
평가 = 틀린 채로 끝나는 토큰을 줄인다        (이번 실행에서 회수)
회고 = 같은 실수를 반복하는 토큰을 줄인다     (다음 실행에서 회수)

4. 고정 예산 실험

발표에서 가장 중요한 설계는 예산을 고정했다는 것 입니다.

벤치마크:  실무형 금융 분석
예산:      60만 토큰 (양쪽 동일)
 
A. 전부 실행에 투입                    →  76점
B. 실행 + 조언 + 평가 + 회고로 배분     →  89점

이 실험이 설득력 있는 이유는 비교가 공정하기 때문 입니다. "조언을 붙였더니 좋아졌다"는 주장은 대개 토큰을 더 쓴 결과라서, 좋아지는 게 당연합니다. 예산을 고정하면 질문이 달라집니다 — 조언에 쓴 토큰이 실행에서 뺏어온 토큰보다 더 벌었는가?

발표의 답은 그렇다는 것이고, 13점 차이가 그 답의 크기입니다.

여기서 주의할 점 하나. 13점은 이 벤치마크, 이 예산, 이 배분에서의 숫자 입니다. 배분 비율은 작업 성격에 따라 달라지고, 발표도 고정 레시피를 주지는 않습니다. 가져갈 것은 숫자가 아니라 "예산을 고정하고 배분을 바꿔서 측정한다"는 실험 방식 입니다.

5. 80% 정확도가 실무에서 무용지물인 이유

발표의 중반부가 이 글에서 제일 중요한 대목이라고 생각합니다.

벤치마크에서는 80%가 괜찮은 점수입니다. 실무에서는 아닙니다.

벤치마크 관점:  100건 중 80건 정답 → 80점 → "꽤 잘한다"
 
실무 관점:      100건 중 20건이 틀림
                → 어느 20건인지 모름
                → 100건을 전부 사람이 검토해야 함
                → 자동화된 것은 0건

틀린 답이 어디 있는지 모르면, 맞은 답도 신뢰할 수 없습니다. 금융 분석처럼 숫자 하나가 의사결정을 바꾸는 영역에서는 이 구조가 더 가혹합니다. 80%짜리 산출물은 "80% 완성된 일"이 아니라 "검토 부담이 100%인 일" 입니다.

그래서 진짜 비용을 계산하는 단위가 바뀝니다.

잘못된 단위올바른 단위
무엇을 재나요청당 토큰완결된 정답 하나당 토큰
80%의 의미준수한 성능사람 검토 100% 필요
저렴한 실행요청 단가가 싸다재시도·검토를 합치면 비싸다

이 단위로 보면 평가 토큰의 성격이 달라집니다. 채점은 부가 비용이 아니라, 검토 비용을 사람에게서 모델로 옮기는 이전 입니다. 사람이 100건을 다 보는 대신 채점자가 걸러낸 미달 항목만 보면 됩니다.

지우고, 어렵게 주고, 검증시켜라에서 정리했던 "검증"이 여기서 비용 계산과 만납니다. 검증은 품질 장치이기도 하지만, 토큰 효율 장치이기도 합니다.

6. 프리미티브로 옮기면 — Claude Managed Agents

발표의 마지막 축은 "이 전략들을 처음부터 짜지 말고, 이미 있는 기본 요소(primitive)를 조합하라"는 것입니다. Claude Managed Agents는 에이전트 루프와 실행 샌드박스를 서버가 맡는 형태라서, 위 세 역할이 각각 대응되는 구성요소를 가집니다.

아래 매핑은 발표가 그대로 말한 것이 아니라, 세 역할을 현재 API 표면에 대본 제 해석 입니다. 파라미터 이름과 제약은 공식 문서를 확인하세요.

조언 → Advisor

실행 모델(executor)과 조언 모델(advisor)을 짝지어, 실행은 저렴한 쪽이 하고 판단이 필요한 순간에만 더 똑똑한 쪽을 부르는 구조입니다. Messages API에서는 advisor 도구로, Managed Agents에서는 멀티에이전트 로스터의 advisor 항목으로 붙습니다.

제약이 하나 있습니다 — 조언 모델은 실행 모델보다 같거나 더 유능해야 합니다. 반대로 짝지으면 요청 자체가 거부됩니다.

{
  "type": "advisor_20260301",
  "name": "advisor",
  "model": "claude-opus-5"
}

주의할 점도 있습니다. 비용 관점에서 advisor가 이기는 구간은 두 모델의 역량 차가 크고, 실행 쪽이 실제로 자주 물어볼 때 입니다. 물어보는 빈도가 떨어지면 실행 모델 단독보다 못한 결과가 나올 수 있습니다. 붙이기 전에 재보는 게 맞습니다.

평가 → Outcomes

세션에 "무엇이 완료인가"를 기준표(rubric)로 주면, 별도 컨텍스트를 가진 채점자 가 매 반복을 채점하고 미달 항목을 실행 쪽에 돌려줍니다. 기준을 통과하거나 최대 반복 횟수에 닿을 때까지 돕니다.

기준표를 쓸 때의 원칙이 명확합니다 — "데이터가 괜찮아 보인다" 같은 항목은 쓰지 않습니다. "CSV에 숫자형 price 컬럼이 있다"처럼 항목별로 독립 판정이 되어야 합니다. 모호한 항목은 채점 결과를 흔들고, 흔들린 채점은 반복 루프를 낭비로 바꿉니다.

이건 에이전트가 실제로 따르는 스펙 쓰는 법에서 다뤘던 이야기와 같은 축입니다. 판정 가능한 문장으로 쓰지 않으면, 사람이든 채점자든 판정할 수 없습니다.

회고 → Memory Stores

세션은 기본적으로 휘발됩니다. 메모리 스토어는 세션 밖에 남는 작은 텍스트 문서 묶음이고, 세션에 붙이면 컨테이너에 디렉토리로 마운트돼서 일반 파일 도구로 읽고 씁니다. 회고 토큰이 만든 결과물이 갈 곳이 여기입니다.

한 가지는 못 박아둘 만합니다 — 자격증명은 절대 넣지 않습니다. 메모리는 이후 세션의 컨텍스트로 그대로 다시 들어가므로, 한 번 적힌 키는 계속 재생됩니다.

팬아웃 → Multiagent

읽기 위주의 작업이 여러 갈래로 나뉘면 코디네이터가 하위 스레드로 넘깁니다. 각 스레드는 자기 컨텍스트 창을 갖고, 코디네이터에게는 보고서만 돌아옵니다. 조언·평가와 결이 같습니다 — 토큰을 어디에 두느냐로 컨텍스트 오염을 관리하는 것 입니다.

7. 이 블로그 저장소에 대보면

늘 하던 대로 남 얘기로 두지 않고 이 저장소에 대봅니다. 이 저장소에서 에이전트가 하는 일은 대체로 "글 하나를 추가하고 깨지는 테스트를 고친다"입니다.

역할이 저장소의 상태
실행대부분 여기에 몰려 있다. 대화형 한 세션
조언없다. 방향이 틀리면 끝까지 틀린 채로 간다
평가있다. pnpm test / e2e / typecheck가 기준표 역할을 한다
회고부분적으로 있다. CLAUDE.md + 메모리 파일 3개

정직하게 적으면 이렇습니다.

평가는 우연히 잘 되어 있습니다. 새 글을 추가하면 하드코딩된 테스트 네 곳이 깨지는데, 이게 성가신 대신 완결 조건이 기계 판정 가능하게 적혀 있다 는 뜻입니다. 5절의 단위로 말하면, 이 저장소에서는 "완결된 정답 하나"가 무엇인지 모호하지 않습니다.

회고도 절반은 됩니다. CLAUDE.md에 배포 특이사항이 적혀 있고, 별도 메모리에 "새 글을 추가하면 같이 고쳐야 하는 테스트 네 곳"과 "썸네일은 생성 스크립트가 없다"가 남아 있습니다. 둘 다 한 번 삽질한 결과를 다음 세션이 물려받은 것 이라, 회고 토큰이 회수된 사례입니다.

조언이 완전히 비어 있습니다. 그리고 이 저장소에서 가장 비싼 실패가 정확히 그 모양입니다 — 글의 구조를 잘못 잡고 끝까지 쓴 다음, 다 지우고 다시 쓰는 것. 실행 토큰을 가장 많이 태우는 지점인데, 그 앞에 아무 장치가 없습니다.

한 가지는 규모 때문에 유보합니다. 이 저장소의 작업은 60만 토큰짜리가 아니라서, advisor를 붙이는 게 이득인지 아닌지는 재보기 전에는 모릅니다. 6절에 적은 주의 그대로입니다.

8. 오해하기 쉬운 지점

오해 1 — "토큰을 더 쓰면 안 된다는 얘기다"

아닙니다. 발표가 부정하는 건 토큰 증량 자체가 전략이라는 생각 입니다. 예산을 늘릴 수 있으면 늘리는 게 낫습니다. 다만 늘린 예산도 결국 배분해야 하고, 배분이 잘못되어 있으면 늘린 만큼 같은 비율로 낭비됩니다.

오해 2 — "조언·평가·회고를 다 붙여야 한다"

세 개는 서로 다른 지점의 낭비를 막습니다. 자기 작업에서 어느 지점이 새는지 부터 보는 게 순서입니다. 방향이 자주 틀리면 조언, "다 했다"가 자주 거짓이면 평가, 같은 삽질을 반복하면 회고입니다. 안 새는 곳에 붙인 장치는 순수 비용입니다.

오해 3 — "채점자를 붙이면 품질이 보장된다"

기준표가 모호하면 채점도 모호합니다. 채점자는 기준표를 판정할 뿐이고, 기준표를 쓰는 건 여전히 사람의 일 입니다. 평가를 붙이는 비용의 대부분은 토큰이 아니라 기준표를 쓰는 시간입니다.

오해 4 — "89점이면 실무에 쓸 수 있다"

5절의 논리를 그대로 적용하면 89점도 같은 문제를 가집니다. 11건이 어디 있는지 모르면 100건을 봐야 합니다. 발표가 말하는 건 "89점이면 충분하다"가 아니라 "같은 예산으로 76에서 89까지 올릴 여지가 있었다" 입니다. 남은 11점을 어떻게 할지는 별개의 설계입니다.

오해 5 — "이건 큰 에이전트 시스템 얘기다"

배분의 문제는 규모와 무관합니다. 다만 장치를 붙이는 고정비가 있어서, 작업이 작으면 회수가 안 될 수 있습니다. 7절에서 유보한 게 그 이유입니다. 규모가 아니라 회수 가능성이 기준입니다.

9. 정리

내용왜
1. 토큰은 균질하지 않다실행·조언·평가·회고는 기대 효용이 다르다예산이 고정이면 비율이 곧 설계다
2. 예산을 고정하고 배분을 바꿔라60만 토큰 고정, 76 → 89증량은 공정한 비교가 아니다
3. 세 역할은 각각 다른 낭비를 막는다앞쪽 · 뒤쪽 · 다음 실행안 새는 곳에 붙이면 순수 비용이다
4. 단위를 바꿔 재라요청당 토큰이 아니라 완결된 정답당 토큰80%는 검토 부담 100%다
5. 처음부터 짜지 말고 조합하라Advisor · Outcomes · Memory · Multiagent직접 만들 루프가 아니다

이 블로그에서 이어온 이야기와 붙여보면 같은 방향입니다.

네 글이 전부 총량을 늘리지 않고 성과를 올리는 방법 을 말합니다. 그리고 이 발표가 거기에 측정 가능한 방법론을 하나 더합니다 — 예산을 고정하고, 배분을 바꾸고, 재보는 것입니다.

예산을 늘릴 수 없을 때 남는 질문은 하나뿐입니다. 이 토큰은 무슨 역할을 하고 있는가?

참고 문서