에이전트를 더 저렴하고, 더 빠르며, 동시에 더 뛰어나게 만드는 실용적이고 군더더기 없는 현장 가이드 — 2026년 팀들이 실제로 수행하는 방식입니다.

거대한 변화: 이득은 더 이상 주로 모델 자체에서 나오지 않습니다. 이득은 harness (모델 주변의 오케스트레이션 레이어)와 컨텍스트 엔지니어링 (Context Engineering) (윈도우에 어떤 토큰을 허용할 것인가)에서 나옵니다. 이 두 가지를 제대로 수행하면, 현재 사용 중이거나 미래에 사용할 모든 모델의 비용이 저렴해집니다.

최근 연구를 기반으로 함: Writer — The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI (arXiv:2607.06906, 2026년 7월), Anthropic — Effective context engineering for AI agents 및 Writing effective tools for agents, Chroma — Context Rot, Manus — Context Engineering Lessons, Epoch AI — LLM inference price trends, 그리고 고전적인 ReAct / Reflexion / MemGPT / SWE-agent 계보.

📋 목차

1. 🧭 단 하나의 멘탈 모델 (Mental Model)
2. 💸 토큰 극대화: 질병
3. 🧮 토큰 청구서의 분해
4. 🎛️ Harness: 가격 결정 요인
5. 🧱 청구서를 다시 쓰는 6가지 메커니즘
6. 🧠 컨텍스트 엔지니어링 (Context Engineering): 수요 측면
7. 🧰 토큰 효율성을 위한 도구 설계
8. ⚖️ Harness 레버리지 및 역량 하한선
9. 🚦 라우팅 (Routing), 플릿 (Fleets) 및 복리 절감
10. 📊 KPI 변경: 품질뿐만 아니라 CPM을 측정하라
11. 🛠️ 실전 플레이북
12. 🧰 툴링 환경: 실제로 이를 구현하는 것들
13. 🎯 원페이지 치트 시트

🧭 단 하나의 멘탈 모델

에이전트적 작업(agentic task)은 단 한 번의 모델 호출(one model call)이 아닙니다. _"이 두 계약서를 대조하여 수정안(redline)을 작성하라"_라는 단일 요청은 시스템 프롬프트(system prompt), 툴 스키마(tool schemas), 검색 페이로드(retrieval payloads), 중간 추론(intermediate reasoning), 툴 출력(tool outputs), 그리고 (단순한 설정에서는) 이후의 모든 턴마다 위의 모든 과정을 다시 재생(full replay)하는 과정으로 이어지며 수십 번의 턴으로 전개됩니다.

해당 작업에 대한 비용은 해당 루프(loop)의 총합이며, 이 루프는 모델이 아니라 모델을 둘러싼 소프트웨어, 즉 _하네스(harness)_에 의해 제어됩니다.

flowchart LR
    A[User request] --> H{The Harness}
    H -->|assembles context| C[Context window]
...

🔑 핵심 주장 (Writer, 2026): 작업과 모델을 고정하고 _오케스트레이션 레이어(orchestration layer)_만 교체하면, 품질은 동일하게 유지하면서 작업당 비용(cost per task) -41%, 지연 시간(latency) -44%, **작업당 토큰(tokens per task) -38%**를 절감할 수 있습니다. 해당 워크로드에서 하네스의 전환은 가장 비싼 모델에서 가장 저렴한 모델로 교체하는 것보다 더 큰 비용 절감 효과를 가져왔습니다.

⚠️ 사전 주의 사항: 이 정확한 수치는 **단일 통제 연구(n = 22개 작업, 벤더 작성)**에서 도출된 것입니다_. 방향성은 견고한 것으로 간주하십시오. 이는 아래에서 Anthropic, Manus, Chroma에 의해 독립적으로 확인되었습니다. 다만 정확한 백분율은 보편적인 상수가 아닌 지표로만 취급하십시오.*

두 가지 레버(levers), 두 가지 규율:

아래의 모든 내용은 이 두 가지에 대한 상세한 설명입니다.

💸 토큰 맥싱(Token maxing): 질병

**토큰 맥싱(Token maxing)**은 에이전트 개발에서 지배적인 (나쁜) 패턴입니다. 즉, 토큰으로 능력을 구매하는 것 — 더 긴 추론 흔적(reasoning traces), 더 많은 턴, 더 넓은 툴 페이로드, 더 큰 재생 컨텍스트를 사용하여 작업당 토큰이 작업 가치보다 더 빠르게 증가하게 만드는 것을 의미합니다.

공식적으로, 개발 궤적(development trajectory)은 토큰 강도 $\tau$가 계속 상승하는 동안 토큰당 한계(marginal) 품질이 하락할 때 토큰 맥싱(token maxing) 현상을 보입니다:

$$\tau_{t+1} > \tau_t \quad\text{while}\quad \frac{Q_{t+1}-Q_t}{\tau_{t+1}-\tau_t} < \frac{Q_t}{\tau_t}$$

즉, 각 릴리스가 시스템의 실행 평균보다 더 나쁜 토큰 교환율로 품질을 구매하고 있음을 의미합니다.

이 현상이 지속되는 이유:

• 📉 하락하는 가격이 이를 은폐합니다. 토큰당 가격이 계속 낮아지고 있으며, 이는 _이러한 습관을 뒷받침하는 재원(finances the habit)_이 됩니다. 팀들은 한계 비용 측면에서 토큰을 거의 무료로 취급하며, 그에 맞춰 소비를 확장합니다. 작업당 비용은 감소하지만, 결과적으로 총 지출은 증가합니다. 이는 토큰의 관점에서 재진술된 전형적인 제번스의 역설 (Jevons paradox) (자원의 효율성이 높아지면 가격이 낮아져 전체 소비가 증가하는 현상)입니다.
• 🏆 벤치마크가 이를 보상합니다. 토큰 맥싱은 (품질을 보고하는) 벤치마크 표에서는 보이지 않지만, (토큰을 보고하는) 클라우드 청구서에서는 고통스러울 정도로 명확하게 보입니다. 품질만으로 평가받는 팀은 토큰 맥싱을 하게 될 것입니다. 왜냐하면 토큰은 타인의 비용 항목(line item)이기 때문입니다.

🚨 탈출구는 더 저렴한 토큰이 아닙니다. 더 적은 토큰으로 동일한 작업을 수행하는 것 (백만 토큰당 완료 횟수(completions-per-million-tokens) 비율을 높이는 것)입니다. 그리고 그 토큰의 대부분은 모델이 아니라 코드에 의해 결정됩니다.

🧮 토큰 비용의 분해

작업이 $k$-턴 루프로 실행된다고 가정합니다. $i$번째 턴은 $T_i^{in}$개의 입력 토큰을 제출하고 $T_i^{out}$개의 출력 토큰을 생성합니다. 비용은 다음과 같습니다:

$$C=\sum_{i=1}^{k}\left(p_{in},T_i^{in}+p_{out},T_i^{out}\right)$$

입력 측면이 비용이 발생하는 지점이며, 이는 _하네스(harness)_가 구성하는 항들로 분해됩니다:

$$T_i^{in}=\underbrace{S_i}{\text{시스템 (system }}+\underbrace{H_i}{\text{이력 (history)} }+{\underbrace{G_i}{\text{도구 스키마 (tool schemas)} }+{\underbrace{R_i}{\text{검색 (retrieval)} }+{\underbrace{U_i}_{\text{사용자 턴 (user turn)}}$$

두 가지 사실이 이 상황을 가혹하게 만들지만, 동시에 해결 가능하게 만듭니다:

1. 단순한 이력 재생(Naive history replay)은 이차 함수적(quadratic)입니다

단순한 하네스는 매 턴마다 전체 대화 기록을 재생하므로, 총 입력 토큰은 턴 수에 따라 $O(k^2)$로 증가합니다:

$$\sum_{i=1}^{k}T_i^{in}\approx k,S+\frac{k(k-1)}{2},\bar{m}+k,\bar{G}+\sum_i R_i$$

이력을 압축(compacts)하고, 불변 접두사(invariant prefix)를 캐싱(caches)하며, 부피가 큰 도구 출력(tool outputs)을 오프로드(offloads)하고, 검색(retrieval)을 최소한으로 다듬는(trims) 하네스(harness)는 해당 이차항(quadratic term)을 (대략) **선형(linear)**으로 변환합니다. 여기에는 두 가지 서로 다른 레버(levers)가 각기 다른 역할을 수행하고 있으며, 이를 명확히 구분하는 것이 중요합니다. **압축(compaction)**은 토큰 *개수(count)*를 $O(k^2)$에서 $O(k)$로 꺾어주는 역할을 합니다. 즉, 각 턴이 얼마나 많은 이력을 가져갈지를 제한합니다. **캐싱(Caching)**은 개수를 전혀 바꾸지 않습니다. 대신 남아 있는 토큰의 *비용(price)*을 바꿉니다(다음 섹션 참조). 두 가지 모두가 필요합니다. 모델의 무엇도 변하지 않지만, 청구서(bill)는 변합니다.

flowchart TD
    subgraph Naive["Naive harness — O(k²)"]
        N1[Turn 1] --> N2[Turn 2: replay 1] --> N3[Turn 3: replay 1+2] --> N4[Turn k: replay all]
...

두 곡선 사이의 음영 처리된 간격은 품질 향상에는 기여하지 못하는 지출입니다.

2. 에이전트 워크로드는 입력 중심적이다 — 따라서 캐싱이 핵심이다

대화 기록(transcript)이 매 턴마다 다시 제출되기 때문에, 프로덕션 에이전트들은 입력:출력(input:output) 토큰 비율이 100:1에 가깝다고 보고합니다. $p_{in}$ 항이 단연 압도적인 비중을 차지합니다. 물론 공격적으로 캐싱을 수행하면 청구서 전체가 바뀌지는 않지만 말입니다(Tier 2b 참조).

그리고 입력 토큰의 가격은 단일 숫자가 아닙니다. 이전에 본 적이 있는 접두사(prefix)를 반복하는 토큰은 기본 요율의 약 0.1배로 캐시(cache)에서 제공됩니다(이는 Anthropic의 읽기 배수(read multiplier)이며, OpenAI와 Google은 0.25배에 더 가깝습니다). 입력 토큰의 일부 $h$가 배수 $\kappa$인 캐시 읽기라면:

$$p_{in}^{\text{eff}}=p_{in}\left(1-h(1-\kappa)\right),\qquad \kappa\approx 0.1$$

$h$를 1에 가깝게 유지하면, 지배적인 항에 대해 정가(list price)의 대략 10분의 1만 지불하게 됩니다. 결정적으로, $h$는 모델의 속성이나 제공업체의 호의가 아닙니다. 이는 *턴 간 프롬프트 바이트 안정성(prompt byte-stability across turns)*의 함수이며, 이는 여러분의 오케스트레이션 레이어(orchestration layer)가 컨텍스트를 어떻게 구성하느냐에 따라 전적으로 결정됩니다.

⚠️ 캐싱은 공짜가 아닙니다 — 쓰기(write) 비용을 주의하세요. _읽기(Read)_는 기본 비용의 ~0.1배이지만, 접두사(prefix)가 처음 캐싱될 때는 쓰기 프리미엄(write premium)을 지불해야 합니다: 기본 5분 캐시의 경우 ~1.25배, 1시간 캐시의 경우 ~2배. 따라서 캐싱은 접두사가 만료되기 전에 재사용될 때만 이득이 됩니다. 5분 캐시의 경우 두 번째 요청에서 손익분기점에 도달하며 (1.25배 쓰기 + 0.1배 읽기 = 1.35배, 캐싱하지 않은 두 번의 호출 비용인 2배와 비교 시), 1시간 캐시의 경우 세 번째 요청에서 도달합니다. 한 번 캐싱된 후 재사용되지 않는 접두사는 아예 캐싱하지 않는 것보다 비용이 더 많이 듭니다. 이것이 바이트 안정성(byte-stability)이 중요한 이유입니다. 안정적으로 유지하는 모든 바이트는 다시 지불하지 않아도 되는 쓰기 비용입니다.

실제로 작동하는지 확인하세요 — cache_read_input_tokens는 여러분의 청구 금액을 예측하는 단 하나의 지표입니다:

resp = client.messages.create(...)
resp.usage.cache_read_input_tokens      # ~0.1배로 제공됨 — 이 값이 높아야 합니다
resp.usage.cache_creation_input_tokens  # ~1.25배로 기록됨 — 한 번 지불하는 프리미엄
...

동일한 접두사를 사용하는 반복적인 호출에도 불구하고 cache_read_input_tokens가 계속 0으로 유지된다면, **조용한 무효화 요인(silent invalidator)**이 접두사를 깨뜨리고 있는 것입니다. 시스템 프롬프트 내의 datetime.now(), 요청마다 생성되는 UUID, 또는 정렬되지 않은 JSON(sort_keys=True가 없는 json.dumps) 등이 그 예입니다.

🔑 harness는 청구 금액의 두 가지 요소 모두를 제어합니다: 제출되는 토큰의 양과 지배적인 토큰에 적용되는 가격입니다. 캐시 히트율(Cache hit rate)은 에이전트가 가질 수 있는 가장 강력한 비용 레버리지 변수입니다.

🎛️ harness: 가격 결정자

harness는 여러분의 애플리케이션과 파운데이션 모델(foundation model) 사이의 런타임(runtime)입니다. harness는 다음을 관리합니다:

1. 컨텍스트 조립 (Context assembly) — 시스템 프롬프트, 대화 상태, 검색 페이로드(retrieval payloads)
2. 도구 레이어 (The tool layer) — 네이티브 도구 + 외부 커넥터 (MCP), 스키마 노출, 호출 중재
3. 워크플로우 실행 (Workflow execution) — 엔드 투 엔드로 실행되는 다단계 플레이북(playbooks)
4. 위임 (Delegation) — 범위가 지정된 하위 에이전트(sub-agents)를 생성하고 그 결과를 병합
5. 관측 가능성 (Observability) — 매 턴마다 프롬프트 토큰, 완료(completion) 토큰, 도구 이벤트 및 실제 경과 시간(wall-clock)을 기록하는 트레이스 심(trace shim)

마지막 항목은 보기보다 훨씬 중요합니다. 토큰을 측정하는 계층이 곧 감사 추적(audit trail)이며, 토큰을 절약하는 계층이 곧 거버넌스 접점(governance surface)입니다. 효율성과 제어는 '하나'의 컴포넌트가 가진 속성입니다. 이것이 바로 harness가 모든 것의 핵심에 위치하는 이유입니다.

기본 루프(default loop) vs. 설계된 harness (engineered harness)

업계 표준인 "관습적인 루프(conventional loop)"는 다음과 같은 모습입니다. 각 요소는 '누락'을 통해 결정된 토큰 경제학적 결정의 결과물입니다.

💡 일반적인 조달 본능은 벤더 간의 $/Mtok(100만 토큰당 비용)을 비교하는 것입니다. 하지만 청구 금액은 $p \times \tau$이며, $\tau$는 harness의 영역에 속합니다. 오케스트레이션(orchestration) 계층을 '임대'하는 조직은 자신이 가장 많이 제어할 수 있는 단 하나의 변수를 외주 준 셈입니다.

🧱 비용 구조를 재작성하는 6가지 메커니즘

이것이 핵심입니다. 한 문장으로 요약한 설계 목표는 다음과 같습니다: (a) 캐시되고, (b) 의사결정에 유의미하며, (c) 확정되고 회수 가능한 작업 내에서 소비되는 토큰의 비율을 극대화하고 — 모델의 동작이 아닌 구조를 통해 이 세 가지를 강제하는 것.

1. 🧊 캐시 형태 규율(Cache-shape discipline): 2구역 프롬프트

모든 프롬프트에 의도적인 **물리적 형태(physical shape)**를 부여하십시오. 즉, 바이트 안정적 접두사(byte-stable prefix)(전체 도구 스키마 카탈로그 + 안정적인 시스템 프롬프트 + 추가 전용(append-only) 트랜스크립트)를 앞에 두고, 그 뒤에 매 턴마다 재구축되는 휘발성 꼬리(volatile tail)(시계, 파일 목록, 계획 상태, 원샷(one-shot) 리마인더)를 배치하는 것입니다.

flowchart LR
    subgraph Prefix["🧊 바이트 안정적 접두사 — 캐시됨 (최대 4개의 중단점까지)"]
        P1[도구 스키마 카탈로그] --> P2[안정적인 시스템 프롬프트] --> P3[추가 전용 내구성 트랜스크립트]
...

이를 최적화가 아닌 **정확성 규칙(correctness rule)**으로 강제하십시오. 매 턴마다 변경되는 모든 것은 구조적으로 접두사(prefix)에 포함되는 것이 금지되며, 캐시 마커(cache-marker) 로직은 첫 번째 휘발성 메시지 지점이나 그 이후에는 중단점(breakpoint)을 설정하는 것을 거부합니다.

📈 동일한 접두사(identical-prefix) 호출로 측정 시: 7,886개의 프롬프트 토큰 중 7,876개(99.9%)가 캐시 읽기(cache reads)로 제공됨 → 지배적인 입력 항목의 가격이 목록 가격의 약 0.1배로 책정되었습니다. 이는 입력 중심의 워크로드(workload)에서 받을 수 있는 가장 큰 단일 할인입니다.

무시할 경우 캐싱을 조용히 망가뜨리는 네 가지 메커니즘 (Anthropic의 구체적인 사례이며, 다른 곳에서도 유사한 형태를 보입니다):