GitHub가 Agentic Workflows를 실제 저장소 운영에 쓰면서 가장 먼저 부딪힌 문제는 “에이전트가 잘 작동하는가”만이 아니었습니다. 자동화가 Pull Request마다 실행되면 LLM API 호출이 눈에 잘 보이지 않게 누적되고, 토큰 비용은 CI 비용처럼 조용히 커질 수 있습니다.
이번 GitHub Blog 글은 Agentic Workflows의 토큰 사용량을 어떻게 계측했고, 어떤 비효율을 줄였으며, 어떤 결과를 얻었는지 설명합니다. ActualStack 관점에서 핵심은 하나입니다. 에이전트 자동화는 기능보다 먼저 관측 가능성과 비용 구조를 설계해야 한다는 점입니다.
핵심 판단
- PR마다 도는 에이전트 자동화는 작은 비효율도 반복 횟수 때문에 큰 비용으로 바뀔 수 있습니다.
- GitHub는 API 프록시를 통해 프레임워크별 로그 차이를 흡수하고, 모든 API 호출을
token-usage.jsonl로 정규화했습니다. - 가장 실용적인 절감 패턴은 쓰지 않는 MCP 도구 제거, 결정적 데이터 조회를 CLI 단계로 이동, 불필요한 LLM 호출 자체를 건너뛰는 것입니다.
- 토큰 수만 보면 안 됩니다. 모델별 단가, 캐시 읽기, 출력 토큰, 작업 난이도 변화, 결과 품질을 함께 봐야 합니다.
무슨 변화인가
GitHub는 2026년 4월부터 내부에서 사용하는 여러 Agentic Workflows의 토큰 사용량을 체계적으로 최적화하기 시작했습니다. 대상은 GitHub Actions 위에서 실행되는 에이전트 기반 유지보수·CI 워크플로우입니다.
GitHub가 먼저 한 일은 “최적화”가 아니라 “계측”이었습니다. Claude CLI, Copilot CLI, Codex CLI처럼 프레임워크마다 로그 형식이 다르기 때문에, 에이전트가 직접 인증정보에 접근하지 못하게 하는 API 프록시 계층에서 호출 정보를 모았습니다. 각 워크플로우는 API 호출별 입력 토큰, 출력 토큰, 캐시 읽기/쓰기 토큰, 모델, provider, timestamp를 담은 token-usage.jsonl 아티팩트를 남기도록 했습니다.
이후 GitHub는 두 가지 일일 최적화 워크플로우를 만들었습니다.
| 워크플로우 | 역할 | 의미 |
|---|---|---|
| Daily Token Usage Auditor | 최근 실행의 토큰 사용량을 집계하고 비정상 증가·고비용 워크플로우를 표시 | 어디를 봐야 할지 알려주는 관측 계층 |
| Daily Token Optimizer | 소스와 최근 로그를 분석해 구체적인 비효율과 수정안을 GitHub 이슈로 제안 | 관측 결과를 수정 가능한 작업으로 바꾸는 계층 |
가장 먼저 줄인 것: 쓰지 않는 MCP 도구
GitHub가 확인한 가장 흔한 비효율은 등록만 되어 있고 실제로 쓰지 않는 MCP 도구였습니다.
LLM API는 기본적으로 stateless하게 동작하므로, 에이전트 런타임은 매 호출마다 MCP 도구의 함수 이름과 JSON schema를 컨텍스트에 포함하는 경우가 많습니다. GitHub MCP 서버에 40개 도구가 있고 실제로는 2개만 쓴다면, 나머지 38개 도구의 schema는 매 요청마다 따라다니는 비용이 됩니다.
GitHub는 smoke-test 워크플로우에서 쓰지 않는 MCP 도구를 제거했을 때 호출당 컨텍스트 크기가 8~12KB 줄었고, 동작 변화 없이 실행당 수천 토큰을 절감했다고 설명했습니다. 이건 개인이나 소규모 팀에도 바로 적용 가능한 패턴입니다. “일단 전체 도구를 붙여두자”는 편하지만, 반복 실행되는 CI 에이전트에는 비용이 됩니다.
GitHub MCP 대신 GitHub CLI를 쓰는 이유
두 번째 큰 최적화는 PR diff, 파일 내용, 리뷰 코멘트처럼 결정적으로 가져올 수 있는 데이터 조회를 GitHub MCP 호출에서 GitHub CLI 호출로 옮긴 것입니다.
MCP 도구 호출은 단순 데이터 조회처럼 보여도 에이전트 입장에서는 하나의 reasoning step입니다. 도구를 고르고, 인자를 만들고, 결과를 다시 컨텍스트에 넣는 왕복 과정이 필요합니다. 반면 gh pr diff 같은 명령은 LLM 추론이 필요 없는 결정적 HTTP 요청입니다.
GitHub는 두 가지 방식으로 이 구조를 바꿨습니다.
- Pre-agentic data downloads: PR diff나 변경 파일 목록처럼 항상 필요한 데이터는 에이전트가 시작하기 전에
gh명령으로 내려받아 workspace 파일로 저장합니다. - In-agent CLI proxy substitution: 런타임에 에이전트가 무엇을 가져올지 결정해야 하는 경우, 인증 토큰을 노출하지 않는 경량 HTTP 프록시를 통해
gh pr view --json같은 CLI 호출을 허용합니다.
핵심은 “에이전트가 생각해야 하는 일”과 “그냥 가져오면 되는 일”을 분리하는 것입니다. CI 비용을 줄이는 데 가장 강한 원칙은 여전히 단순합니다. 가장 싼 LLM 호출은 하지 않는 LLM 호출입니다.
측정은 왜 어려운가
토큰 최적화는 단순히 총 토큰 수가 줄었는지만 보면 위험합니다. GitHub가 지적한 혼동 요인은 세 가지입니다.
| 혼동 요인 | 문제 | 대응 |
|---|---|---|
| 모델별 단가 차이 | Haiku, Sonnet, Opus는 같은 토큰 수라도 비용이 다름 | 모델 multiplier를 적용한 Effective Tokens(ET) 사용 |
| 라이브 저장소의 작업량 변화 | 5줄 수정 PR과 200줄 PR은 자연스럽게 토큰 사용량이 다름 | 토큰 수와 LLM 호출 수, 토큰/호출 지표를 함께 확인 |
| 품질 변화 | 더 싼 모델이나 제한된 워크플로우가 결과 품질을 낮출 수 있음 | turn 수, 출력 토큰, tool-call completion 같은 process signal 확인 |
GitHub는 Effective Tokens(ET)라는 지표도 제시했습니다. 새 입력 토큰, 캐시 읽기 토큰, 출력 토큰에 서로 다른 가중치를 적용하고, 모델별 비용 multiplier를 곱하는 방식입니다. 특히 출력 토큰은 주요 provider에서 비싼 편이므로 더 높은 가중치를 둡니다.
초기 결과
GitHub는 gh-aw와 gh-aw-firewall 저장소의 약 12개 production workflow에 auditor와 optimizer를 적용했고, 그중 9개가 optimizer 추천 변경을 받았다고 밝혔습니다. 충분한 전후 실행 수가 있는 워크플로우만 결과에 포함했습니다.
| 워크플로우 | 보고된 개선 | 해석 |
|---|---|---|
| Auto-Triage Issues | 109개 post-fix run 기준 62% 감소 | 이슈마다 자주 실행되므로 누적 절감 효과가 큼 |
| Daily Compiler Quality | 12개 post-fix run 기준 19% 개선 | 일 1회성이라 절감률보다 안정성이 중요 |
| Daily Community Attribution | 8개 post-fix run 기준 37% 개선 | 반복 조회 구조를 줄인 효과 |
| Security Guard | 43% 개선 | 보안 관련 파일이 아닐 때 LLM을 건너뛰는 relevance gate가 효과적 |
| Smoke Claude | 59% 개선 | MCP tool pruning과 더 저렴한 모델 tier 전환 영향 |
특히 Auto-Triage Issues는 평균 6.8회/일, 최대 15회/일 실행되기 때문에 per-run 절감률이 누적 비용 절감으로 크게 이어집니다. Agentic workflow에서는 “한 번에 얼마나 쓰는가”와 함께 “얼마나 자주 실행되는가”를 반드시 같이 봐야 합니다.
팀에서 바로 적용할 체크리스트
| 점검 항목 | 질문 | 권장 조치 |
|---|---|---|
| 토큰 로그 | 워크플로우별 input/output/cache token을 남기고 있는가? | API 프록시 또는 런타임 로그를 JSONL로 정규화 |
| MCP 도구 | 등록된 도구 중 실제 호출되지 않는 것이 많은가? | tool manifest와 실제 tool call을 대조해 pruning |
| 데이터 조회 | PR diff, 파일 목록, 이슈 메타데이터를 에이전트가 매번 도구로 읽는가? | CLI 사전 다운로드 또는 deterministic step으로 이동 |
| 실행 조건 | 모든 PR에 LLM이 필요한가? | 파일 경로·라벨·변경 범위 기반 relevance gate 추가 |
| 비용 우선순위 | 가장 비싼 워크플로우가 가장 자주 실행되는가? | run frequency × per-run ET로 우선순위 결정 |
| 품질 검증 | 토큰 절감 후 결과 품질이 유지되는가? | turn 수, 실패율, 재시도율, 사람 수정률을 함께 기록 |
실사용 판단
이 글은 GitHub Agentic Workflows만의 이야기가 아닙니다. Claude Code, Codex CLI, Copilot, 자체 에이전트, MCP 서버를 CI에 붙여 쓰는 팀이라면 거의 같은 문제가 생깁니다. 에이전트는 한 번 잘 돌면 편하지만, 이벤트 기반으로 자주 실행되기 시작하면 비용 구조가 빨리 흐려집니다.
작은 팀이라면 먼저 모든 것을 자동화하려고 하기보다 다음 순서가 안전합니다.
- PR마다 실행되는 에이전트 작업과 수동 실행 작업을 분리합니다.
- 항상 필요한 데이터는 에이전트 시작 전에 파일로 내려받습니다.
- 에이전트에게 주는 MCP 도구 목록을 최소화합니다.
- 토큰 사용량과 실패율을 워크플로우별로 남깁니다.
- 비용이 튀는 실행을 사람이 확인할 수 있게 알림을 둡니다.
보류해야 하는 경우
- 워크플로우 결과 품질을 아직 측정할 방법이 없는 경우
- 에이전트가 인증정보나 민감한 저장소 데이터에 접근하는 구조를 통제하지 못하는 경우
- 도구 호출 로그, 토큰 로그, 실패 로그를 남기지 않는 상태에서 PR마다 자동 실행하려는 경우
- 자동화가 실패했을 때 어떤 변경을 되돌려야 하는지 운영 절차가 없는 경우
후속 작업
이미 에이전트 기반 CI를 쓰고 있다면, 새 모델이나 새 도구를 붙이기 전에 비용 계측부터 넣는 편이 좋습니다. GitHub가 제안한 시작점도 같습니다. API 프록시를 추가하고, 로그를 켜고, 어떤 워크플로우가 비용을 만드는지 데이터로 확인하는 것입니다.
GitHub는 글 말미에서 gh-aw CLI로 token audit과 optimizer workflow를 추가하는 예시도 제시했습니다. 그대로 도입하지 않더라도 구조는 참고할 만합니다. 핵심은 에이전트에게 더 많은 일을 시키는 것이 아니라, 에이전트가 하지 않아도 되는 일을 먼저 제거하는 것입니다.
출처와 검증
- GitHub Blog: Improving token efficiency in GitHub Agentic Workflows
- GitHub Agentic Workflows CLI documentation
- GitHub Community discussion
원문 발행일: 2026-05-07. 이 글은 원문을 그대로 번역한 것이 아니라, 개발팀의 비용·운영 판단 기준으로 재구성한 ActualStack 편집본입니다.