Tokenomics: 에이전트 기반 소프트웨어 개발에서 토큰이 어디에 쓰이는지 정량 분석

Who Should Read

LLM 기반 코딩 에이전트(Copilot, Cursor 등)를 팀에 도입했거나 도입을 검토 중인 개발자 또는 AI 에이전트 워크플로우의 비용을 예측하고 최적화하고 싶은 백엔드/MLOps 엔지니어.

Core Mechanics

• 이 연구는 ChatDev 프레임워크로 소프트웨어 개발 작업 30개를 실행하면서 GPT-o1 계열 추론 모델의 토큰 소비 패턴을 단계별로 측정했다. 분석 대상 단계는 설계(Design), 코딩(Coding), 코드 완성(Code Completion), 코드 리뷰(Code Review), 테스팅(Testing), 문서화(Documentation) 6단계다.
• 가장 충격적인 결과는 Code Review 단계 하나가 전체 토큰의 평균 59.4%를 차지한다는 점이다. 처음 코드를 생성하는 비용보다 코드를 검토하고 반복 수정하는 비용이 훨씬 크다는 의미다.
• 토큰 유형별로 보면 입력 토큰(input token)이 평균 53.9%로 가장 큰 비중을 차지한다. 에이전트가 무언가를 출력하기 전에 엄청난 양의 컨텍스트를 읽어들이는 과정 자체가 주된 비용이라는 뜻이다.
• 이 비율은 '에이전트 협업 비효율성'의 경험적 증거로 해석된다. 에이전트끼리 서로의 결과물을 맥락으로 넘기고 또 읽는 과정에서 입력 토큰이 폭증한다.
• 연구팀은 SDLC(소프트웨어 개발 생명주기) 각 단계를 표준화된 평가 프레임워크로 매핑했는데, 이게 앞으로 에이전트 시스템 비용을 비교하고 예측하는 기준선(baseline) 역할을 할 수 있다.
• 결론적으로 에이전트 소프트웨어 개발의 핵심 비용은 '코드 생성'이 아니라 '자동화된 검증과 반복 개선'에 있다. 따라서 비용을 줄이려면 리뷰 루프를 얼마나 효율적으로 설계하느냐가 핵심이다.
• 이 연구는 LLM-MA(LLM 멀티에이전트) 시스템의 운영 효율성과 자원 소비가 그동안 제대로 측정된 적이 없어서 실제 도입을 가로막고 있다는 문제의식에서 출발했다. 예측 불가능한 비용과 환경 영향이 주된 장벽이었다.

Evidence

• 실제 에이전트 사용자 한 명이 '입력:출력 토큰 비율이 10:1 정도'라고 경험을 공유했다. 에이전트가 코드 한 줄 수정하려고 백만 토큰을 읽는 경우도 있다며, 논문의 53.9% 입력 비중은 오히려 보수적으로 잡은 수치일 수 있다고 봤다. 만약 출력 토큰이 더 많다면 에이전트에 문제가 있거나 코드베이스가 텅 빈 상태일 가능성이 높다는 의견이었다.
• GitHub Copilot 사용자는 한 달은 아무 문제 없이 썼는데 다음 달 가격 정책 변경 이후 이틀 만에 토큰을 다 썼다는 경험을 공유했다. 이 변동성을 보면 토큰 가격 책정이 자의적이고, AI 업계 자체가 자금 압박을 받고 있는 신호일 수 있다는 해석을 덧붙였다.
• '샘플 수가 겨우 30개 작업'이라 통계적 신뢰도가 낮다는 지적이 있었지만, 결과 자체는 본인들이 직접 경험한 패턴과 일치한다는 반응이 많았다. 코드 리뷰가 토큰을 가장 많이 먹는다는 발견이 현장 경험과 잘 맞아떨어진다는 것이다.
• 에이전트를 써보니 동적 테스트는 거의 안 하고 단위 테스트(unit test)를 수천 개씩 쏟아내는 경향이 있다는 흥미로운 관찰도 공유됐다. 이는 에이전트가 검증 방식으로 정적인 테스트 코드 작성을 선호하는 패턴을 보인다는 의미로, 토큰 낭비의 또 다른 형태다.
• 한 댓글에서는 제품 검토 미팅 중 간단한 단일 쿼리 하나에 25만 토큰이 소비된 걸 발견하고 '누가 토큰 비용을 부담하는지, 예산 한도는 있는지' 물었더니 담당자가 대답을 못 했다는 일화를 소개했다. AI를 제품에 끼워넣을 때 실제 운영 비용이 전혀 계산되지 않고 있다는 업계 전반의 문제를 꼬집는 사례였다.
• 'Tokenomics'라는 단어는 이미 암호화폐 경제학 용어로 쓰이고 있는데 AI 분야에서 같은 단어를 재정의하려는 시도가 혼란스럽다는 지적도 있었다.

How to Apply

• 에이전트 기반 코드 작성 도구(Copilot Workspace, Devin, SWE-agent 등)의 월간 비용이 예상보다 훨씬 많이 나오는 경우, Code Review 루프 횟수를 제한하거나 리뷰 에이전트의 컨텍스트 윈도우 크기를 줄이는 방향으로 최적화하면 전체 토큰 소비의 절반 이상을 줄일 수 있다.
• LLM 멀티에이전트 파이프라인을 직접 구축 중이라면, 각 단계(설계, 코딩, 리뷰, 테스트)별로 토큰 사용량을 로깅하는 계측 코드를 먼저 심어라. 어느 단계가 병목인지 파악하지 않으면 최적화 방향을 잡을 수 없고, 이 논문의 프레임워크를 참고해서 단계별 비교 기준을 만들 수 있다.
• 입력 토큰이 출력보다 훨씬 많다는 점(평균 53.9%)을 감안하면, 에이전트에게 넘기는 컨텍스트(코드 파일, 히스토리, 도구 설명 등)를 압축하거나 필터링하는 전처리 단계를 추가하는 것만으로도 비용을 의미 있게 줄일 수 있다. 예를 들어 관련 파일만 선택적으로 포함하거나, 롤링 요약(rolling summary)으로 이전 대화를 압축하는 방식을 쓸 수 있다.
• AI 기능을 SaaS 제품에 포함시켜 '라이선스에 포함' 형태로 제공할 계획이라면, 이 논문의 단계별 토큰 소비 분포를 참고해서 사용자당 예상 토큰 소비량을 추정하고 반드시 사용량 상한(rate limit)과 예산 경보를 설정해야 한다. 단순 쿼리 하나에 25만 토큰이 소비될 수 있다는 현장 사례를 반드시 염두에 두자.

Terminology

관련 논문

• Claude Code는 프롬프트 읽기 전에 33k 토큰을 전송한다; OpenCode는 7k

  동일한 모델과 작업 환경에서 Claude Code와 OpenCode의 실제 토큰 사용량을 API 레벨에서 측정한 결과, Claude Code가 시스템 프롬프트 오버헤드만으로 OpenCode 대비 4.7배 더 많은 토큰을 소비한다는 것을 확인했다.

• Mesh LLM: iroh 기반 분산 AI 컴퓨팅

  사무실, 집, 클라우드에 흩어진 GPU들을 하나의 OpenAI 호환 API로 묶어주는 분산 LLM 실행 시스템으로, 비싼 API 비용 없이 큰 모델을 직접 운영할 수 있다.

• Frugon – LLM API 호출 로그를 분석해서 더 싼 모델로 대체 가능한 구간을 찾아주는 로컬 도구

  내 LLM API 비용이 어디서 새는지 로컬에서 분석해주는 오픈소스 CLI 도구로, 비싼 모델 대신 저렴한 모델로 전환 가능한 호출을 골라낸다.

• 로컬에서 SOTA LLM 실행하기 완전 가이드 (하드웨어부터 설정까지)

  2천 달러짜리 RTX 3090 한 장부터 4만 달러짜리 RTX PRO 6000 4장 셋업까지, 로컬에서 최신 LLM을 직접 돌리는 방법을 하드웨어 선택·구성·실행 설정까지 통째로 정리한 실전 가이드다.

• Manticore Search에서 ONNX 경로를 재설계해 임베딩 속도를 14배 높인 방법

  Manticore Search가 기존 SentenceTransformers/Candle 백엔드를 ONNX Runtime으로 교체해 텍스트 임베딩 생성 속도를 평균 14배 향상시켰다. 별도 모델 서비스 없이 DB 내부에서 직접 임베딩을 처리하는 구조에서 INSERT 속도가 곧 임베딩 속도이기 때문에 이 개선은 실질적인 ingest 처리량 향상으로 직결된다.

• Asymmetric Quantization: 97% 스토리지 절감으로 Late Interaction 검색 품질 유지하기

  멀티벡터 검색 모델의 문서 벡터를 1비트 이진값으로 압축하고 쿼리 벡터만 int8로 유지하는 비대칭 양자화 기법으로, 스토리지를 97% 줄이면서 검색 품질 손실을 0.61점(NDCG@10 기준)에 그치게 만든 실제 프로덕션 적용 사례다.

Related Resources

• 원문 논문 (arXiv:2601.14470)
• Zachary Whitley의 Substack 관련 글
• 토큰 효율적 예산 가이던스 관련 논문 (Google Scholar)