mcp2cli -> 매 턴마다 도구 스키마 (tool schemas)에 낭비되는 토큰의 96–99%를 절약; caveman -> laude Code 기술로 65% 절감.

저는 컨텍스트 엔지니어링 (context engineering)과 그것이 어떻게 막대한 비용을 아껴줄 수 있는지에 대한 수많은 논의를 계속 접하고 있습니다. 이는 에이전트 하네스 (agent harness)에 플러그인으로 연결할 수 있는 또 다른 MCP/Skill/CLI의 전례 없는 주장들을 확인하는 것이거나, 혹은 몇 가지 트릭과 접근 방식에 대해 논의하는 것입니다. AI 비용이 통제 불능 상태로 치솟고 있는 상황에서, 이러한 방향들은 합리적인 전진 방향처럼 보입니다.

하지만 저는 토큰 최적화 (token optimization)에 집중하는 것이 우회로이자 주의 분산이 될 수 있다고 생각합니다. 그 주장들이 사실이 아니기 때문이 아닙니다... 예를 들어, 저는 mcp2cli를 테스트해 보았고, 광고된 절감 효과를 상식적으로 기대하지도 않았습니다 (결국 MCP 도구 정의가 시스템 프롬프트에서 20k의 토큰을 소비하더라도, 그것들이 캐싱(cached)되어 아주 저렴한 비용이 든다면 누가 신경을 쓰겠습니까). 저는 단지 MCP 지원 없이 에이전트에서 MCP를 사용하는 방법을 연구했을 뿐입니다... 또는 제 친구가 caveman+graphiphy를 사용한 경험을 공유해 주었는데 (계획을 위해 Opus를 사용하고, 실행을 위해 Sonnet을 사용하는 동일한 작업), 그는 기본 Claude Code를 사용했을 때 16달러가 들었지만 두 도구를 모두 사용했을 때는 13.5달러가 들었습니다.

토큰 회계 (token accounting)에 집중하다 보면, 올해 일어난 에이전트적 전환 (agentic transition)의 핵심을 놓칠 수 있습니다. 혹독한 컨텍스트 엔지니어링을 통해 20%를 절약할 수는 있겠지만, 여러 하위 에이전트 (subagents)를 실행하는 장기적인 에이전트적 실행 (agentic execution) 과정에서 100배 더 많은 비용을 쓸 수도 있습니다.

현재의 토큰 경제학 (tokenomics) 대화에는 이상한 냄새가 납니다.

한쪽에서는 기업들이 직원들에게 "AI를 더 많이 사용하라"고 말하고 있습니다. 다른 한쪽에서는 청구서가 도착하기 시작하고, 벤더 크레딧 (vendor credits)은 만료되고 있으며, Copilot 스타일의 구독 모델은 사용량 기반 (consumption)으로 이동하고 있고, 재무 팀은 AI 사용량이 깔끔하고 고정적인 SaaS 시트 비용 (SaaS seat cost)이 아니라는 사실을 깨닫고 있습니다. 그것은 클라우드 지출 (cloud spend)과 더 비슷하게 작동합니다. 다만 이제는 채팅창과 IDE 에이전트를 가지고 있으며, 더 생산적이어야 한다는 막연한 명령을 받은 모든 직원의 손에 신용카드가 쥐어져 있다는 점이 다를 뿐입니다.

Ed Zitron은 AI에는 ROI가 없다라고 설명합니다. 즉, 직원들은 보조금이 지급된 구독 서비스를 통해 AI를 비용이 들지 않는 것처럼 취급하도록 훈련받았고, 이후 관리자와 경영진으로부터 개별 작업 단위의 비용이 얼마인지 확인하지도 못한 채 대규모로 AI를 도입하라는 압박을 받았습니다. 이러한 행동 양식은 숨겨진 가격 책정(hidden pricing) 하에서 형성되었으며, 이후 사용량 기반 가격 책정(usage pricing) 하에서 평가받게 된 것입니다.

첫 번째 대응책은 보통 목록 형태로 나타납니다. 사용하지 않는 탭 닫기. 로그 최소화하기. 더 짧은 시스템 프롬프트 (system prompts) 사용하기. 차이점(diffs) 요청하기. /compact 사용하기. 영어로 프롬프트 작성하기. 전체 파일 붙여넣지 않기. JSON 대신 CSV 사용하기. 스크린샷 해상도 낮추기. MCP 도구 끄기. 이 중 일부는 합리적입니다. 일부는 민간 전승(folklore)에 불과합니다. 일부는 무해합니다. 일부는 주의를 분산시킵니다. 이러한 트릭의 대부분은 미미한 수준에서 도움이 됩니다. 이들은 비용 방정식에서 가장 작은 항을 겨냥하고 있지만, 정작 비싼 부분들은 다른 곳에서 계속 커지고 있습니다.

방정식

AI 에이전트의 경우, 저는 비용을 다음과 같이 생각합니다. 이를 '에이전트 루프 경제학 (Agent Loop Economics)'이라고 부릅시다.

AgentLoopCost ~= Tasks x Attempts x AgentTurns x ContextSize x ModelPrice x Parallelism

이 방정식은 통제 불능의 비용을 찾아내기 위한 대략적인 승수 지도 (multiplier map)입니다. 이는 사용자나 조직이 실제로 영향을 미칠 수 있는 요소들에 가깝게 유지됩니다: 얼마나 많은 작업(tasks)이 AI로 전달되는지, 얼마나 많은 시도(attempts)를 허용하는지, 에이전트가 얼마나 오래 실행되는지, 얼마나 많은 컨텍스트(context)를 유지하는지, 어떤 모델/노력 계층(effort tier)을 사용하는지, 그리고 얼마나 많은 에이전트가 동시에 실행되는지입니다.

항 (Term)	증가 요인	중요한 이유
Tasks	더 많은 작업이 AI를 통해 처리됨	비용은 조달 부서의 계정(seat) 수가 아니라 일상적인 행동을 따름
...

프롬프트에서 5,000개의 토큰 (tokens)을 줄이는 것이 책임감 있게 느껴질 수 있지만, 여전히 예산을 탕진하는 핵심 요소를 놓칠 수 있습니다. 모델은 확률적 (probabilistic)입니다. 환경은 상태 유지적 (stateful)입니다. 프레임워크 (harness)는 도구 사용 (tool use)을 권장합니다. 작업이 깔끔하게 종료되지 않을 수도 있습니다. 에이전트는 너무 많이 읽거나, 너무 많이 테스트하거나, 다른 에이전트를 호출하거나, 혹은 그것이 더 안전하다고 판단하여 오래된 컨텍스트 (stale context)를 계속 유지할 수 있습니다.

컨텍스트 정리 (Context cleanup)는 ContextSize를 줄여줍니다. 코딩 에이전트(coding agents)가 코드를 작성하기 전에 매우 많은 양을 읽어야 하는 현 시점에서는 이것이 매우 중요할 수 있습니다. 하지만 Attempts, AgentTurns, 그리고 Parallelism (병렬성) 수치가 폭발적으로 증가하고 있는 상황에서는 여전히 거의 아무런 효과가 없습니다.

계속해서 움직이는 계량기

사용자 행동 문제 아래에는 별개의 문제가 자리 잡고 있습니다. 바로 계량기(meter) 자체가 유동적이라는 점입니다.

GitHub의 Copilot 사용량 기반 과금 (Copilot usage-based billing)에 관한 2026년 4월 포스트가 명확한 예시입니다. Copilot은 그동안 프리미엄 요청 단위 (premium request units)를 기준으로 가격이 책정되어 왔습니다. 하지만 6월 1일부터 해당 단위들은 GitHub AI 크레딧 (GitHub AI Credits, 필수적인 센트 단위)으로 대체되었으며, 각 모델의 공표된 API 요율에 따라 입력(input), 출력(output), 그리고 캐시된 토큰(cached tokens)을 포함한 토큰 사용량에 따라 소비됩니다. GitHub의 설명은 매우 직설적입니다. Copilot이 에디터 내 어시스턴트에서 길고 다단계적인 코딩 세션을 수행하는 에이전트 플랫폼 (agentic platform)으로 진화했기 때문에, 간단한 채팅 질문과 몇 시간 동안 지속되는 자율 코딩 세션이 사용자에게 더 이상 동일한 비용을 청구할 수 없게 되었다는 것입니다.

좋습니다. 그것은 제공자 입장에서의 합리적인 이야기입니다. 하지만 고객 입장에서는 어제의 사용 습관, 어제의 한도, 그리고 요청 하나가 얼마의 "비용"을 발생시키는지에 대한 어제의 감각이 매우 빠르게 무의미해질 수 있음을 의미합니다.

변동 요소들은 결코 작지 않습니다:

변동 요소	변경 사항	중요한 이유
과금 단위 (Billing unit)	요청이 크레딧이 되고, 크레딧은 토큰이 되며, 토큰은 다양한 카테고리를 포함함	하나의 계량기에 익숙해진 사람들이 갑자기 다른 계량기 아래에서 살게 됨
...

정적인 트릭 목록만으로는 취약한 비용 정책이 됩니다. 오늘 사실인 것이 모델 출시, 토크나이저 (tokenizer) 변경, Copilot 과금 체계 이전, 새로운 기본 작업 설정, 또는 파일을 건드리기 전에 컨텍스트를 두 배 더 많이 읽기로 결정한 새로운 에이전트 하네스 (agent harness)로 인해 금방 구식이 될 수 있습니다.

실질적인 대응책은 지루할 수도 있습니다. 벤더의 가격 책정(pricing)과 측정 방식을 버전이 지정된 의존성(versioned dependencies)으로 취급하는 것입니다. 미터링(meter) 방식이 변경되면 반복되는 워크플로우(workflows)의 기준점(re-baseline)을 다시 설정하십시오. 가이드라인 옆에 가정을 명시해 두어야 합니다. 만약 어떤 권장 사항이 "이 작업에는 이 모델을 사용하십시오"라고 말한다면, 그것이 언제 테스트되었는지, 어떤 하네스(harness)에서, 어떤 과금 규칙 하에 테스트되었는지, 그리고 어떤 상황이 재테스트를 강제하는지도 함께 명시해야 합니다.

토큰을 아끼려는 논의 속에서 간과되는 한 가지 차이점이 있습니다. 바로 '누가 제어권을 쥐고 있는가?'입니다.

만약 여러분이 Claude Code, Codex, Cursor, Copilot, 또는 Windsurf를 사용하고 있다면, 작업을 범위화(scope)하고, 루프(loop)의 상한을 설정하며, 도구가 노출하는 경우 모델이나 노력 수준(effort level)을 선택하고, 도구를 제한하며, 병렬/백그라운드 에이전트(agents)가 증식하는 것을 막을 수 있습니다. 하지만 일반적으로 프롬프트 캐시(prompt-cache) 중단점, 배치 API 작업(batch API jobs), 캐시 제거(cache eviction), 또는 제공업체의 숨겨진 시스템 스캐폴딩(system scaffolding)을 미세 조정할 수는 없습니다. 그것들은 플랫폼의 선택 사항입니다.

만약 여러분이 API 제품을 구축하거나 게이트웨이(gateway)를 운영하고 있다면 이야기는 달라집니다. 프롬프트 레이아웃(prompt layout), 캐싱 전략(caching strategy), 배치 처리(batch processing), 라우팅(routing), 폴백(fallbacks), 그리고 키별 예산(per-key budgets)이 실제적인 레버(levers)가 됩니다. 호스팅된 코딩 에이전트(coding agent)를 사용하는 최종 사용자의 입장에서 "캐싱 최적화"는 대부분 "제공업체와 하네스가 이를 잘 수행하는 도구를 선택하라"는 의미가 됩니다. 접점(surface)에 따라 플레이북(playbook)이 변하는 것입니다.

채택 곡선은 사실 비용 곡선입니다

비용 이야기는 여러 단계(phases)를 거치지만, 이 단계들은 개인보다는 조직에 속합니다. 구매 부서(Procurement)는 여전히 라이선스(seats)를 구매하고 있을 수 있고, 엔지니어링 팀은 이미 에이전트를 실행하고 있을 수 있으며, 재무 팀은 몇 주 후에나 인보이스(invoice)를 확인할 수도 있고, 직원들은 미터링(meter)에 대해 거의 감을 잡지 못할 수도 있습니다.

이 단계들을 승수(multipliers)의 스택으로 읽으십시오. 각 단계는 루프가 더 커질 수 있는 새로운 방식을 추가합니다. 더 많은 작업, 더 많은 파워 유저, 더 많은 도구 호출(tool calls), 더 높은 인보이스 가시성, 더 많은 거버넌스(governance), 그리고 결국 ROI(투자 대비 수익)에 대한 요구로 이어집니다.

1. Push Phase (추진 단계): 경영진은 "모든 곳에 AI를 사용하라"고 말하며, 비용은 추상적입니다.
2. Power User Phase (파워 유저 단계): 5%의 사용자가 진정한 레버리지를 발견하고 불균형적으로 많은 토큰 (tokens)을 소모합니다.
3. Agentic Phase (에이전트 단계): 워크플로우가 채팅에서 장기적 목표를 가진 에이전트 (long-horizon agents)로 전환됩니다. 도구 호출 (tool calls), 컨텍스트 (context), 그리고 검증 루프 (verification loops)가 폭발적으로 증가합니다.
4. Invoice Phase (인보이스 단계): 재무 부서에서 실제 소비량을 확인하게 되고, 크레딧이 만료되며, 벤더 (vendor) 조건이 변경됩니다.
5. Governance Phase (거버넌스 단계): 사용량 제한 (caps), 대시보드 (dashboards), 쇼백/차지백 (showback/chargeback), 라우팅 (routing), 모델 정책 (model policy), FinOps가 도입됩니다.
6. ROI Phase (ROI 단계): 지출은 열정이나 토큰 양이 아닌, 비즈니스 결과에 따라 평가됩니다.

추진 단계 (push phase)에서 비용은 추상적입니다. 경영진은 도입을 원합니다. 직원들은 회의, 문서, 코드, 연구, 지원, 조달 등 모든 분야에서 AI를 사용하도록 권장됩니다. 많은 사용자가 불투명한 할당량 (quotas), 보조된 사용량, 모호한 측정치, 그리고 수시로 변하는 제한 사항이 적용된 개인용 또는 기업용 구독 서비스를 이용합니다. 어떤 이들은 청구서를 전혀 보지 못합니다. 어떤 이들은 다른 사람의 예산이기 때문에 신경 쓰지 않습니다. 어떤 이들은 작업 도중 제한에 걸리고 나서야 계량기의 형태를 알게 됩니다.

이러한 추진 방식은 빠르게 기묘한 양상을 띠었습니다. Fortune은 Meta의 직원이 만든 Claudeonomics 리더보드를 보도했는데, 여기서 직원들은 토큰 지위를 두고 경쟁했으며, 30일 동안 대시보드 총 사용량은 60조 토큰을 초과했고 상위 개인은 평균 2,810억 토큰을 사용했습니다. 이후 Yahoo Finance는 Amazon이 내부 KiroRank 토큰 리더보드를 폐쇄했다고 보도했으며, 한 부사장(SVP)은 직원들에게 "단순히 AI를 사용하기 위한 목적으로 AI를 사용하지 마십시오"라고 말했습니다. 토큰 사용은 처음에는 열정의 대리 지표가 되었으나, 갑자기 비용 문제로 변했습니다.

그다음에는 파워 유저(Power users)들이 등장합니다. Cursor의 Developer Habits Report는 이를 명확히 보여줍니다. AI 사용량은 매우 집중되어 있으며, AI 생성 코드 라인(AI lines)의 지니 계수(Gini score)는 0.77, AI 지출(AI spend)은 0.75, 토큰(tokens)은 0.72를 기록했습니다. 상위 1%(P99) 개발자들은 활성 사용자 중앙값(median)보다 하루에 46배 더 많은 AI 코드 라인을 생성하며, 활성 PR 작성자 중앙값보다 15배 더 많은 PR을 머지(merge)합니다. 평균적인 사용자를 바라보는 것은 잘못된 접근입니다. 비용이 폭증하기 시작하는 지점은 바로 꼬리 부분(the tail)입니다.

그다음에는 워크플로(workflows)가 더욱 에이전트화(agentic)됩니다. Cursor의 보고에 따르면 세션당 평균 도구 호출(tool calls) 횟수는 2026년 3월 초 약 114회에서 5월 중순 약 145회로 두 달 만에 약 30% 증가했습니다. 또한 입력/출력 토큰 비율(input/output token ratios)도 1월 약 4.5배에서 5월 11배 이상으로 상승했으며, 5월에는 입력 토큰(input tokens)이 일반적인 입출력 토큰 볼륨의 90% 이상을 차지했습니다.

자동 완성(Autocomplete)은 보통 제안이 이루어진 후 멈춥니다. 하지만 에이전트 도구(Agentic tools)는 파일을 검사하고, 도구를 호출하며, 명령을 실행하고, 결과를 검증하며, 다시 시도하는 동안 계속해서 비용을 지출합니다. 비용이 많이 드는 핵심은 바로 이 루프(loop)입니다.

에이전트가 읽고, 검색하고, 편집하고, 명령을 실행하고, 검증하고, 스스로 수정(self-correct)하기 시작하면, 비용의 중심은 "내 프롬프트(prompt)가 얼마나 길었는가?"에서 "시스템이 얼마나 많은 작업을 수행하기로 결정했는가?"로 이동합니다.

청구서 단계에 이르면 분위기가 바뀝니다. Wall Street Journal은 이를 AI를 위한 클라우드 FinOps(FinOps)의 등장으로 묘사했습니다. 즉, 대시보드(dashboards), 알림(alerts), 쇼백(showback), 차지백(chargeback), 상한선(caps), 그리고 CFO의 가시성(visibility)이 도입되는 것입니다. Priceline은 토큰 사용량을 추적하며 사용량이 많은 직원들과 면담을 진행합니다. Smartsheet는 부서 및 관리자별 사용자 대시보드를 운영합니다. Qualcomm은 상한선(caps)과 쇼백(showback)을 사용합니다. OpenText는 쇼백(showback) 또는 차지백(chargeback)을 통해 토큰 비용을 20%에서 30%까지 낮출 수 있다고 말합니다.

FinOps Foundation의 2026 State of FinOps는 이러한 패턴이 더 이상 일화적인 수준이 아님을 보여줍니다. 응답자의 98%가 현재 AI 지출을 관리하고 있으며, 이는 2025년 63%, 2024년 31%에서 크게 증가한 수치입니다. 또한 FinOps 팀의 78%가 현재 CTO 또는 CIO에게 보고하고 있다고 밝혔습니다. 이러한 장소(venue)의 변화는 중요합니다. AI 비용이 송장 검토(invoice review)의 영역을 벗어나 기술 가치 관리(technology-value management)의 영역으로 이동하고 있기 때문입니다.

이것이 조직 계층(org layer)의 모습입니다. 화려하지는 않지만, AI 사용이 예상치 못한 송장 문화(surprise invoice culture)로 변질되지 않고 확장될 수 있을지를 결정하는 계층이기도 합니다.

토큰 가격이 저렴해진다고 해서 작업 비용이 저렴해지는 것은 아닌 이유

여기에는 두 가지 함정이 있습니다.

첫 번째 함정은 토큰당 가격(per-token price)이 작업 비용(task cost)을 예측할 것이라고 가정하는 것입니다. 두 번째 함정은 더 비싼 모델이 실제 사용 시에도 항상 더 많은 비용이 들 것이라고 가정하는 것입니다.

Business Insider의 modelmaxxing 관련 기사는 이러한 변화의 문화적 버전을 포착합니다. 기업과 파워 유저들은 "모든 AI를 사용하자"는 방식에서 모델 간에 작업을 라우팅(routing)하는 방식으로 이동하고 있습니다. 슬로건은 잠시 무시해 봅시다. Brian Armstrong의 더 강력한 주장은 별도의 Coinbase 중심 글에서 반복되는데, 워크로드의 80%는 99% 더 저렴한 모델에서 처리될 수 있는 반면, 나머지 20%는 여전히 프런티어(frontier) 모델에 비용을 지불할 가치가 있다는 것입니다. 저는 이를 보편적인 라우팅 테이블(routing table)이 아닌, 하나의 테스트 의무(testing obligation)로 취급하겠습니다.