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

관련 논문

• 로컬에서 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 기준)에 그치게 만든 실제 프로덕션 적용 사례다.

• Bash4LLM+ – 의존성 없는 경량 Bash LLM API 래퍼

  Python이나 Node.js 없이 순수 Bash만으로 Groq 등 OpenAI 호환 LLM API를 호출할 수 있는 단일 스크립트 도구로, Termux(Android)를 포함한 모든 Unix 환경에서 동작한다.

• Wayfinder Router: 로컬과 hosted LLM 간 deterministic 쿼리 라우팅 도구

  프롬프트의 복잡도를 모델 호출 없이 오프라인으로 점수화해서 간단한 쿼리는 로컬 모델로, 어려운 쿼리는 유료 모델로 자동 라우팅하는 CLI 도구다. LLM 비용을 줄이면서도 응답 품질을 유지하고 싶은 개발자에게 유용하다.

• Apple Neural Engine: 아키텍처, 프로그래밍, 성능 (리버스 엔지니어링 가이드)

  Apple 기기에 내장된 AI 전용 칩인 ANE(Apple Neural Engine)를 리버스 엔지니어링으로 분석한 302페이지짜리 기술 문서로, Core ML 아래 숨겨진 내부 구조와 직접 접근 경로를 처음으로 공개한다.

Related Resources

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