AI 워크플로우, 끝없는 토큰 비용 고민

소프트웨어 개발 과정에서 반복적이고 사소한 오류 수정, 코드 품질 개선 등의 작업을 자동화하는 GitHub Agentic Workflows는 개발자들의 작업 효율을 크게 향상시킵니다.

마치 숙련된 청소부 팀처럼, 이 워크플로우들은 저장소의 전반적인 위생과 품질을 높이는 데 기여합니다.

하지만 이러한 자동화 작업이 늘어날수록 토큰 비용은 개발자들에게 새로운 고민거리가 되고 있습니다.

특히 CI(지속적 통합) 작업처럼 자동으로 예약되고 트리거되는 워크플로우의 경우, 비용은 사용자 몰래 빠르게 축적될 수 있습니다.

다행히도, 대화형 데스크톱 세션과 달리, 에이전트 워크플로우는 YAML 파일에 명확하게 정의되고 반복적으로 실행되므로 자동화된 작업을 더 효율적으로 만드는 것이 상대적으로 용이합니다.

GitHub는 자사 저장소에서도 Agentic Workflows를 직접 유지하고 사용하기에, 사용자들과 마찬가지로 토큰 효율성에 대한 깊은 우려를 가지고 있습니다.

이러한 배경 속에서, GitHub 팀은 2026년 4월부터 매일 사용하는 워크플로우들의 토큰 사용량을 체계적으로 최적화하는 작업에 착수했습니다.

본 포스팅에서는 이들이 어떤 계측을 수행했고, 어떤 최적화 기법을 적용했으며, 그 결과는 어떠했는지 상세히 소개합니다.

토큰 사용량 계측, 효율 최적화의 첫걸음

GitHub는 수백 개의 에이전트 워크플로우를 저장소 유지보수 및 CI 작업에 활용하고 있습니다.

이 워크플로우들은 모두 실제 API 속도 제한을 적용받는 GitHub Actions 환경에서 실행됩니다.

마치 비행기를 날리면서 동시에 제작하는 것처럼, 이들은 비용을 소모하면서 효율성을 개선해 나가고 있었습니다.

토큰 소비량을 최적화하기 위해서는 무엇보다 현재 토큰이 어떻게 소비되고 있는지 정확히 파악하는 것이 선행되어야 했습니다.

첫 번째 난관은 Claude CLI, Copilot CLI, Codex CLI 등 각기 다른 에이전트 프레임워크가 서로 다른 형식의 로그를 배출한다는 점이었습니다.

이로 인해 과거 실행 기록에 대한 사용량 데이터가 불완전할 수 있었습니다.

다행히도, Agentic Workflows의 보안 아키텍처는 에이전트가 인증 정보를 직접 접근하는 것을 방지하는 API 프록시를 사용합니다.

이 프록시 덕분에 모든 실행 기록에 대해 단일화되고 정규화된 형식으로 토큰 사용량을 포착할 수 있었습니다.

이제 모든 워크플로우는 token-usage.jsonl이라는 아티팩트를 출력합니다.

이 아티팩트에는 API 호출당 하나의 레코드가 포함되며, 입력 토큰, 출력 토큰, 캐시 읽기 토큰, 캐시 쓰기 토큰, 모델, 제공자, 타임스탬프 등의 상세 정보가 담깁니다.

이 데이터를 워크플로우의 다른 로그와 결합함으로써, 토큰이 전통적으로 어떻게 사용되었는지 역사적인 관점을 확보하고 향후 실행을 위한 최적화 기반을 마련할 수 있었습니다.

워크플로우가 워크플로우를 최적화하다

파악된 토큰 데이터를 바탕으로, GitHub 팀은 두 가지 일일 최적화 워크플로우를 구축했습니다.

첫 번째는 Daily Token Usage Auditor입니다.

이 감사자는 최근 워크플로우 실행 기록에서 토큰 사용량 아티팩트를 읽어 들여, 워크플로우별 소비량을 집계하고 구조화된 보고서를 생성합니다.

이 감사자의 역할은 최근 사용량이 현저히 증가한 워크플로우를 식별하고, 가장 비용이 많이 드는 워크플로우를 표면에 노출시키며, 비정상적인 실행(예: 정상적으로 4번의 LLM 턴으로 완료되는 워크플로우가 18번의 턴을 소모한 경우)을 기록하는 것입니다.

감사자가 특정 워크플로우를 플래그하면, 두 번째 워크플로우인 Daily Token Optimizer가 해당 워크플로우의 소스 코드와 최근 로그를 분석하여 구체적인 비효율성을 설명하고 특정 최적화 방안을 제안하는 GitHub 이슈를 생성합니다.

Optimizer는 이 과정을 통해 개발자들이 놓쳤을 수 있는 수많은 비효율성을 발견했습니다.

물론, 이 감사자와 최적화 워크플로우 자체도 에이전트 워크플로우이기 때문에, 이들의 토큰 사용량 역시 일일 보고서에 포함되어 작은 선순환 구조를 만듭니다.

불필요한 MCP 도구 제거 전략

초기 Auditor 및 Optimizer 결과를 바탕으로, 가장 흔한 비효율성은 사용되지 않는 MCP(Meta-Programmable Core) 도구 등록으로 파악되었습니다.

LLM API는 상태를 저장하지 않기 때문에, 에이전트 런타임은 일반적으로 각 요청에 MCP 도구의 함수 이름과 JSON 스키마를 포함합니다.

이는 사실상 모든 도구 세트가 각 호출의 컨텍스트 일부가 될 수 있음을 의미합니다.

예를 들어, 40개의 도구를 갖춘 GitHub MCP 서버의 경우, 도구 하나당 10~15KB의 스키마가 매 턴마다 추가될 수 있습니다.

만약 에이전트가 단 두 개의 도구만 사용한다면, 나머지 38개 도구는 모든 요청에 순수한 오버헤드로 추가되는 것입니다.

워크플로우 작성자들은 일반적으로 가장 쉬운 경로를 택하기 때문에 전체 도구 세트로 시작하는 경향이 있으며, 에이전트가 필요한 도구를 스스로 식별할 것이라고 가정합니다.

하지만 시간이 지남에 따라 대부분의 워크플로우는 좁고 안정적인 도구 세트에 의존하게 됩니다.

Optimizer는 이러한 패턴을 도구 매니페스트와 실제 도구 호출을 교차 분석하여 식별하고, 구성에서 사용되지 않는 도구를 제거할 것을 권장합니다.

GitHub 팀은 자체 스모크 테스트 워크플로우에서 사용되지 않는 도구를 MCP 구성에서 제거함으로써, 호출당 컨텍스트 크기를 8~12KB 줄여, 동작 변화 없이 실행당 수천 개의 토큰을 절약하는 성과를 거두었습니다.

GitHub CLI 전환: 구조적 개선의 핵심

사용되지 않는 MCP 도구를 제거하는 것은 비교적 간단한 개선 사항입니다.

여기서 더 나아가, GitHub 팀은 GitHub MCP 호출을 GitHub CLI 호출로 대체하는 보다 구조적인 기회를 포착했습니다.

이는 풀 리퀘스트 diff, 파일 내용, 리뷰 코멘트와 같은 데이터 가져오기 작업에 해당합니다.

이 변경은 불필요한 도구의 오버헤드를 줄이는 것 이상으로 큰 영향을 미쳤습니다.

MCP 도구 호출은 데이터 검색뿐만 아니라 추론 단계를 포함하기 때문입니다.

에이전트는 도구를 호출할지 결정하고, 인수를 구성하며, 그 출력을 컨텍스트의 일부로 받아야 합니다.

이는 도구 사용 JSON 스키마, 인수 블록, 응답에 대한 토큰을 소모하는 완전한 왕복 LLM API 호출입니다.

반면에 gh pr diff와 같은 GitHub CLI 명령을 호출하는 것은 LLM의 개입 없이 GitHub REST API로의 결정적인 HTTP 요청입니다.

GitHub 팀은 이러한 전환을 위해 두 가지 전략을 사용했습니다.

  • 사전 에이전트 데이터 다운로드: 에이전트가 항상 필요로 하는 데이터(예: 풀 리퀘스트 diff 또는 변경된 파일 목록)의 경우, 에이전트가 시작되기 전에 gh 명령을 실행하는 워크플로우 설정 단계를 추가하고 결과를 작업 공간 파일에 씁니다. 에이전트는 MCP 호출 대신 해당 파일을 읽습니다. 이를 통해 도구 호출 오버헤드가 제거되고, 에이전트는 bash 스크립팅에 대한 광범위한 훈련을 활용하여 데이터를 효율적으로 처리할 수 있습니다.

  • 인-에이전트 CLI 프록시 대체: 에이전트가 런타임에 가져올 데이터를 결정해야 하는 경우 사전 다운로드가 불가능합니다. 이러한 상황에서는 에이전트에 인증 토큰을 노출하지 않으면서 CLI 트래픽을 GitHub API 서버로 라우팅하는 경량의 투명 HTTP 프록시에 의존합니다. 에이전트는 gh pr view --json과 같은 명령을 실행하고, 터미널에서 사용자처럼 구조화된 데이터를 받습니다. 이는 제로 시크릿(zero-secrets) 보안 요구사항을 침해하지 않으면서 토큰 사용량을 줄입니다. 이러한 기술들을 통해 GitHub 데이터 가져오기의 대부분을 LLM 추론 루프 밖으로 이동시켰습니다.

효율성 개선 측정의 복잡성

워크플로우 최적화를 진행하면서, GitHub 팀은 더 복잡한 문제에 직면했습니다.

어떤 변경이 실제로 효율성을 높인 것인지, 아니면 단순히 워크플로우가 수행하는 작업의 양을 줄인 것인지(결과적으로 작업의 질이 저하되었을 가능성 포함)를 어떻게 알 수 있을까요? 세 가지 교란 요인이 존재했습니다.

  • 모든 토큰이 동일하게 생성되는 것은 아닙니다. 동일한 워크플로우를 Claude Haiku와 Claude Sonnet에서 실행하면 유사한 토큰 수가 나오지만, 비용은 매우 다릅니다. Haiku는 Sonnet보다 토큰당 약 4배 저렴하므로, 모델을 전환한 워크플로우는 원시 토큰 수에서는 변함이 없어 보이지만 상당한 비용 절감을 의미합니다. 이를 설명하기 위해, GitHub 팀은 Effective Tokens (ET)라는 지표를 사용합니다. 이 지표는 각 토큰 유형에 모델별 승수를 적용합니다: ET = m × (1.0 × I + 0.1 × C + 4.0 × O). 여기서 m은 모델 비용 승수(Haiku = 0.25×, Sonnet = 1.0×, Opus = 5.0×)이며, I는 새로 처리된 입력 토큰, C는 캐시 읽기 토큰, O는 출력 토큰입니다. 출력 토큰은 모든 주요 제공자에서 가장 비용이 많이 드는 토큰 유형이므로 4배의 가중치를 갖습니다. 캐시 읽기 토큰은 신선한 입력의 일부 비용으로 제공되므로 0.1배의 가중치만 갖습니다. 이 공식은 모델 계층 간의 소비를 정규화하여, 10% ET 감소는 어떤 모델을 사용하든 진정한 10% 비용 감소를 의미합니다.

  • 워크로드는 라이브 저장소입니다. 알려진 바에 따르면, 토큰 사용량을 최적화할 수 있는 에이전트 워크플로우 벤치마크가 존재하지 않습니다. 워크플로우별 토큰 사용량을 조사하기 시작했을 때, 한 번의 실행에서는 5줄짜리 수정 작업을 처리했지만, 다음 실행에서는 200줄짜리 풀 리퀘스트를 처리하는 경우를 발견했습니다. 첫 번째 실행은 자연스럽게 더 적은 토큰을 사용하지만, 그 차이는 효율성의 갑작스러운 변화 때문이 아닙니다. 원시 토큰 수는 워크로드 변화와 효율성 변동을 혼동시킬 수 있습니다. GitHub 팀은 LLM API 호출 횟수를 추적하여 이를 정규화하려고 시도합니다.

이러한 복잡성에도 불구하고, GitHub의 지속적인 노력은 AI 기반 개발 워크플로우의 경제성과 확장성을 확보하는 데 중요한 발판이 될 것입니다.

토큰 효율성 최적화는 단순히 비용 절감을 넘어, AI가 더욱 광범위하고 실용적인 개발 도구로 자리매김하게 하는 필수적인 과정입니다.

자주 묻는 질문 (FAQ)

Q: GitHub Agentic Workflows에서 토큰 효율성이 중요한 이유는 무엇인가요?

A: Agentic Workflows는 AI 모델을 사용하여 코드 품질 개선 및 오류 수정을 자동화합니다.

이 과정에서 AI 모델과의 통신에 토큰이 사용되며, 워크플로우가 반복적으로 실행될수록 토큰 사용량이 누적되어 비용 증가로 이어지기 때문에 효율적인 토큰 관리가 중요합니다.

Q: GitHub Agentic Workflows의 토큰 효율성을 개선하기 위한 주요 전략은 무엇인가요?

A: 주요 전략으로는 불필요한 MCP 도구 등록 제거, GitHub CLI를 활용한 데이터 가져오기 작업 전환, 그리고 모델별 토큰 비용을 고려한 Effective Tokens (ET) 지표 도입 등이 있습니다.

Q: Effective Tokens (ET) 지표는 무엇이며 왜 사용되나요?

A: ET는 모델별 토큰 비용 차이를 반영하여 실제 비용 효율성을 측정하는 지표입니다.

이를 통해 서로 다른 모델을 사용하더라도 일관된 비용 절감 효과를 비교하고 측정할 수 있어, 효율성 개선 정도를 정확하게 파악하는 데 도움이 됩니다.

Q: GitHub CLI로 전환하는 것이 토큰 효율성에 어떤 영향을 미칩니까?

A: GitHub CLI 호출은 LLM 추론 단계를 거치지 않고 GitHub API로 직접 통신하므로, LLM API 호출 시 발생하는 입력/출력 토큰 및 추론 관련 토큰 소모를 줄일 수 있습니다.

이는 데이터 가져오기 작업의 비용을 크게 절감합니다.