GitHub Agentic Workflows 토큰 최적화 해설: MCP 도구를 많이 붙이는 것보다 CLI 사전 수집과 무추론 게이트를 먼저 설계해야 하는 이유

발행일: 2026-05-09 | 카테고리: 개발정보

1. 한 줄 문제 정의

핵심 요약: AI 코드 자동화의 비용은 모델이 비싸서만이 아니라, 추론이 필요 없는 읽기 작업까지 LLM 턴으로 태우기 때문에 커집니다.

GitHub는 2026년 5월 7일 공개한 글에서, 자사 저장소에서 실제로 돌리는 Agentic Workflows를 계측한 뒤 어떤 지점이 토큰을 새고 있는지 공개했습니다. 대상 독자는 GitHub Actions 안에서 Copilot CLI, Claude CLI, Codex CLI 같은 에이전트를 운영하는 플랫폼 엔지니어, DevEx 담당자, 보안/품질 자동화 담당 팀입니다. 현실 문제는 단순합니다. PR마다 자동으로 도는 에이전트는 눈에 띄지 않게 비용을 누적시키고, 그 비용의 상당 부분이 정작 판단이 필요 없는 데이터 수집 단계에서 발생합니다.

이 글의 범위는 GitHub Agentic Workflows의 토큰 최적화 운영 기준입니다. 특정 모델 벤더 우열 비교나 일반적인 프롬프트 작성 팁은 다루지 않습니다. 또 “MCP가 나쁘고 CLI가 무조건 좋다”는 이분법도 지지하지 않습니다.

2. 먼저 결론

핵심 요약: 비용을 가장 크게 줄이는 순서는 모델 다운그레이드가 아니라 불필요한 MCP schema 제거 → 사전 데이터 다운로드 → LLM 자체를 건너뛰는 relevance gate입니다.

• 지금 바로 적용할 팀: PR triage, issue 분류, 보안 점검, 리뷰 코멘트 생성처럼 반복형 GitHub Actions 에이전트를 이미 돌리는 팀
• 아직 과한 팀: 일회성 실험만 하는 소규모 저장소, 워크플로 실행 빈도가 낮아 비용보다 구현 시간이 더 비싼 팀
• 제 판단: Agentic Workflow 최적화의 핵심은 “에이전트를 더 똑똑하게”가 아니라 에이전트가 생각하지 않아도 되는 구간을 설계로 없애는 것입니다.

GitHub 사례에서 가장 설득력 있었던 수치는 Auto-Triage Issues 워크플로가 최적화 후 62% 절감을 보였다는 점입니다. 이 변화는 프롬프트 미세 조정이 아니라, 읽기 작업을 LLM 루프 밖으로 빼낸 구조 변경에서 나왔습니다. 그래서 저는 토큰 절감 프로젝트를 “모델비 절약”보다 워크플로 구조 개선으로 보는 편이 맞다고 봅니다.

3. 핵심 구조 분해

핵심 요약: GitHub가 공개한 구조는 단순한 비용 대시보드가 아니라 계측, 감사, 자동 최적화, 실행면 분리 네 층으로 되어 있습니다.

1. 계측 계층: 모든 워크플로가 token-usage.jsonl 아티팩트를 남기고, API 호출마다 input/output/cache 토큰, 모델, 제공자, 시각을 기록합니다.
2. 감사 계층: Daily Token Usage Auditor가 최근 실행을 집계해 비정상 증가, 가장 비싼 워크플로, LLM 턴 급증 같은 패턴을 보고합니다.
3. 최적화 계층: Daily Token Optimizer가 워크플로 소스와 로그를 읽고, 구체적인 비효율과 수정 제안을 이슈로 남깁니다.
4. 실행 계층: 실제 최적화는 MCP tool pruning, gh CLI 사전 다운로드, runtime CLI proxy, relevance gate 같은 구조적 변경으로 반영됩니다.

쉽게 말해, GitHub는 “에이전트가 비싸다”라고 불평한 것이 아니라 어디서 왜 비싸졌는지 자동으로 말해주는 관측 시스템을 먼저 만들었습니다. 이것이 중요한 이유는, 토큰 최적화가 감으로 하면 금세 “모델만 더 싼 걸 쓰자” 수준으로 끝나기 쉽기 때문입니다.

4. 설계 의도 해설

핵심 요약: GitHub의 진짜 설계 의도는 MCP를 버리는 것이 아니라, MCP를 추론이 필요한 구간에만 쓰도록 축소하는 데 있습니다.

MCP(Model Context Protocol)는 AI 앱이 외부 도구와 표준 방식으로 연결되게 만드는 개방형 규격입니다. 문제는 표준화의 이점과 별개로, 워크플로 한 번에 필요 없는 도구 스키마까지 계속 프롬프트에 실어 나르기 쉽다는 점입니다. GitHub 설명에 따르면 40개 도구를 가진 GitHub MCP 서버는 호출 한 번마다 10~15KB의 JSON schema를 컨텍스트에 더할 수 있습니다.

그래서 GitHub가 택한 방향은 “MCP를 없애자”가 아니라 “정적 읽기 작업은 gh CLI나 사전 파일로 빼고, 에이전트 판단이 필요한 구간만 MCP/LLM에 남기자”입니다. 이 판단은 꽤 합리적입니다. PR diff 읽기, changed files 목록 받기, 이슈 메타데이터 조회는 사람이 해도 기계적으로 하는 작업에 가깝기 때문입니다.

여기서 포기하는 것도 있습니다. ad-hoc하게 필요한 도구를 즉석에서 다 쓰는 자유도는 줄어듭니다. 대신 얻는 것은 재현성, 예측 가능한 비용, 더 낮은 runaway loop 확률입니다. 저는 반복 실행되는 CI형 에이전트에서는 이 trade-off가 거의 항상 이득이라고 봅니다.

5. 근거 및 비교

핵심 요약: 비교 기준은 “어떤 방식이 더 멋져 보이는가”가 아니라 토큰 비용, 추론 턴 수, 운영 통제, 품질 유지입니다.

GitHub 공개 수치를 보면 unused MCP tools를 제거했을 때 호출당 8~12KB 컨텍스트가 줄었고, 워크플로당 수천 토큰을 아꼈습니다. 또 구조 최적화 후 Auto-Triage Issues 62%, Daily Compiler Quality 19%, Daily Community Attribution 37% 개선을 확인했다고 밝혔습니다. 이 수치는 “조금 더 짧게 프롬프트 쓰자” 수준이 아니라, 아키텍처를 바꾸면 비용 곡선이 달라진다는 근거입니다.

또 GitHub는 단순 토큰 수 대신 Effective Tokens(ET)를 썼습니다. 공식 글의 식은 ET = m × (1.0 × I + 0.1 × C + 4.0 × O)입니다. output token 비용을 더 높게, cache-read token 비용을 더 낮게 반영해 실제 비용과 가까운 지표를 만들려는 시도입니다. 이 관점도 중요합니다. 같은 10만 토큰이라도 어떤 토큰인지에 따라 운영 비용은 다르기 때문입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 첫 주에는 계측과 pruning, 둘째 주에는 CLI 사전 수집, 셋째 주에는 relevance gate를 붙이는 순서가 가장 안전합니다.

1. 토큰 사용 로그를 아티팩트로 남기십시오
   워크플로마다 토큰 사용 로그를 같은 형식으로 남겨야 비교가 됩니다.
   

   - name: Upload token usage
     uses: actions/upload-artifact@v4
     with:
       name: token-usage
       path: token-usage.jsonl
       retention-days: 5

2. 실제 사용하지 않는 MCP 도구를 먼저 줄이십시오
   도구 manifest와 실제 tool call 로그를 대조해 zero-call 도구를 빼십시오. 특히 PR 리뷰 워크플로에서 gist, webhook, org 관리 도구가 같이 실려 있으면 거의 낭비입니다.
3. 항상 필요한 GitHub 데이터는 에이전트 시작 전에 내려받으십시오
   PR diff, changed files, review comments는 대개 사전 준비가 가능합니다.
   

   mkdir -p .agent
   GH_TOKEN="$GITHUB_TOKEN" gh pr diff "$PR_NUMBER" > .agent/pr.diff.txt
   GH_TOKEN="$GITHUB_TOKEN" gh pr view "$PR_NUMBER" --json files,comments,reviews > .agent/pr-view.json

4. 에이전트 프롬프트는 '파일을 읽어 판단하라'로 바꾸십시오
   MCP 호출을 유도하는 대신 작업공간 파일을 우선 읽게 하면 추론 턴 수가 줄어듭니다.
   

   먼저 .agent/pr.diff.txt 와 .agent/pr-view.json을 읽고,
   추가 조회가 없으면 MCP를 호출하지 말 것.

5. 런타임 조회가 꼭 필요하면 CLI proxy를 쓰십시오
   GitHub 사례처럼 토큰을 직접 에이전트에 주지 않고, 프록시를 통해 gh pr view --json 같은 구조화 조회만 허용하는 방식이 안전합니다.
6. LLM 생략 게이트를 만드십시오
   예를 들어 보안 민감 경로가 바뀌지 않은 PR은 Security Guard를 실행하지 않도록 사전 규칙을 둡니다.
   

   if ! git diff --name-only "$BASE_SHA" "$HEAD_SHA" | grep -Eq '(^infra/|^auth/|secret|policy)'; then
     echo 'skip_agent=true' >> "$GITHUB_OUTPUT"
   fi

7. 효율과 품질을 함께 보십시오
   GitHub처럼 LLM call count, turns per run, completion rate를 같이 보지 않으면, 실제로는 덜 일했는데 효율이 좋아진 것처럼 착각할 수 있습니다.

7. 실수/함정(Pitfalls)

핵심 요약: 비용 절감 실패는 대개 모델 선택이 아니라 잘못된 계측, 잘못된 게이트, 잘못된 경로 허용에서 나옵니다.

• 실수 1. 토큰 총량만 보고 품질이 유지됐다고 착각
  예방: run당 LLM 턴 수, completion rate, 결과물 길이와 리뷰 통과율을 함께 보십시오.
  복구: 효율 변경 전후 샘플 PR을 다시 검토해 실제 누락이 없는지 확인하십시오.
• 실수 2. 안 쓰는 MCP 도구를 그대로 싣고 다님
  예방: 최소 월 1회 tool-call histogram을 뽑아 zero-call 도구를 제거하십시오.
  복구: 워크플로별 toolset을 분리하고, 공용 full-set 기본값을 없애십시오.
• 실수 3. relevance gate가 너무 공격적이라 필요한 검사까지 건너뜀
  예방: 민감 경로 목록을 코드오너와 같이 관리하고, skip 비율을 주간 점검하십시오.
  복구: false negative가 난 패턴을 게이트 정규식에 추가하고, 임시로 보수적 모드로 되돌리십시오.
• 실수 4. allowlist/경로 규칙 때문에 도구 호출이 막혀 runaway loop 발생
  예방: GitHub 사례처럼 상대경로, glob, 임시 디렉터리 규칙을 테스트 워크플로에서 먼저 검증하십시오.
  복구: 실패 로그를 보고 차단 규칙을 수정한 뒤, 같은 조건으로 smoke test를 재실행하십시오.

8. 강점과 한계

핵심 요약: 이 방식은 반복형 워크플로에는 매우 강하지만, 사용자별 상호작용이 많은 대화형 에이전트에는 그대로 복제하기 어렵습니다.

• 강점: 비용 예측 가능성 상승, 도구 호출 감소, 런어웨이 루프 완화, 동일 워크플로 반복 시 최적화 효과가 큼
• 한계: 사전 파일화가 어려운 동적 조회 작업에는 효과가 제한적, 게이트 설계 품질에 따라 누락 리스크 존재, 준비 공수가 듦
• 반례: 채팅형 지원 에이전트처럼 사용자가 매번 다른 권한과 다른 조회를 요구하는 경우에는 pure CLI 치환보다 MCP의 사용자별 인증 장점이 더 중요할 수 있습니다.

즉, 이 패턴은 “모든 에이전트의 정답”이 아니라 반복 자동화형 GitHub 워크플로의 정답에 가깝다고 보는 편이 정확합니다.

9. 더 깊게 공부할 포인트

핵심 요약: 다음 단계는 MCP냐 CLI냐의 종교전이 아니라, 어떤 읽기 작업을 추론에서 분리할 수 있는가를 찾는 일입니다.

• MCP 서버별 schema 크기와 실제 tool usage 분포를 수집해 보십시오.
• PR/issue/workflow 유형별로 항상 필요한 데이터와 조건부 데이터가 무엇인지 나눠 보십시오.
• ET 같은 비용 정규화 지표를 팀 상황에 맞게 정의해 보십시오.
• skip gate의 false negative 사례를 모아, 어디까지 규칙화할 수 있는지 확인해 보십시오.
• 대화형 에이전트와 CI형 에이전트를 같은 아키텍처로 운영하고 있지는 않은지 점검해 보십시오.

10. 실행 체크리스트 + 작성자 관점

핵심 요약: 에이전트 비용을 줄이고 싶다면 프롬프트보다 먼저 읽기 경로와 실행 조건을 고정해야 합니다.

• 모든 반복형 에이전트 워크플로가 토큰 사용 아티팩트를 남긴다
• 워크플로별 MCP toolset이 실제 사용 도구만 포함하도록 분리되어 있다
• PR diff, 파일 목록, 기본 메타데이터는 에이전트 시작 전 파일로 내려받는다
• 런타임 추가 조회는 CLI proxy 또는 최소 MCP만 허용한다
• 보안/품질 점검 워크플로에는 relevance gate가 있다
• 효율 지표와 품질 지표를 함께 본다
• allowlist와 경로 규칙을 smoke test로 검증한다

Definition of Done: 반복 실행되는 한 워크플로에서 도구 pruning, 사전 데이터 다운로드, skip gate를 적용한 뒤 품질 저하 없이 ET 또는 동등 지표가 20% 이상 감소하면 1차 최적화가 완료된 것입니다.

제 추천: GitHub Actions 안에서 에이전트를 이미 돌리고 있다면, 다음 분기 최적화 과제는 모델 교체보다 MCP 호출을 어디까지 파일/CLI/게이트로 대체할 수 있는지를 보는 것이 맞습니다. 반대로 아직 워크플로 수가 적고 실행 빈도가 낮다면, 너무 이른 최적화보다 먼저 계측부터 해 두는 편이 낫습니다. 비용은 보이지 않을 때 가장 빨리 불어납니다.

참고자료

• GitHub Blog - Improving token efficiency in GitHub Agentic Workflows (2026-05-07)
• Model Context Protocol - What is MCP? (확인일: 2026-05-09)
• GitHub Docs - Store and share data with workflow artifacts (확인일: 2026-05-09)
• GitHub CLI Manual - gh pr diff (확인일: 2026-05-09)
• GitHub CLI Manual - gh pr view (확인일: 2026-05-09)
• Firecrawl Blog - MCP vs CLI for AI Agents (2026-04-10, 업계 비교 관점 참고)