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

관련 논문

• Silurus/ooxml: 브라우저에서 Office 문서를 pixel-faithful하게 렌더링하는 라이브러리

  Rust + WebAssembly로 DOCX/XLSX/PPTX 파일을 브라우저 Canvas에 직접 렌더링하는 오픈소스 라이브러리로, 코드 전체가 Claude(AI)로 작성된 점이 화제가 됐다.

• Lowfat – CLI 출력을 필터링해서 LLM 토큰을 91.8% 절약한 도구

  AI 에이전트가 CLI 명령어 출력을 읽을 때 불필요한 노이즈를 제거해 토큰 사용량을 줄여주는 Rust 기반 CLI 필터 도구. Claude Code, OpenCode 등 주요 AI 코딩 에이전트와 통합 가능하다.

• 1-bit/Ternary Bonsai Image 4B: 로컬 디바이스용 이미지 생성 모델

  4B 파라미터 이미지 생성 모델의 가중치를 1비트/3값으로 극단적으로 압축해서 iPhone에서도 돌아가게 만든 모델. 7.75GB짜리 diffusion transformer를 0.93GB까지 줄였다.

• Tiny-vLLM: C++와 CUDA로 만드는 고성능 LLM 추론 엔진

  vLLM의 핵심 기능을 C++와 CUDA로 직접 구현하며 배울 수 있는 교육용 LLM 추론 엔진 프로젝트로, 소스코드와 단계별 강의가 함께 제공된다.

• 일반 데이터센터 GPU에서 요청당 3,000 tokens/s 실시간 LLM 추론

  Kog AI가 8× AMD MI300X에서 요청당 3,000 tokens/s를 달성하는 LLM 추론 엔진을 공개했고, 기존 소프트웨어 스택의 병목을 GPU 메모리 대역폭 최대화로 풀어냈다는 내용이다.

• LLM을 위한 수면과 유사한 컨텍스트 통합 메커니즘

  LLM이 긴 컨텍스트를 처리할 때 발생하는 Attention 비용 문제를 해결하기 위해, 사람의 수면처럼 주기적으로 컨텍스트를 fast weight에 압축·저장하는 새로운 메커니즘을 제안한 논문이다.

Related Resources

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