MCP 도구 삭제보다 먼저 할 일: GitHub CI 에이전트 비용 감사법

풀 리퀘스트마다 자동 실행되는 에이전트가 있다면, 한 번의 응답 가격보다 반복되는 불필요한 일을 먼저 보자. 사람이 직접 쓰는 채팅에서는 요청이 매번 달라지지만, CI 작업은 정해진 목적과 입력을 반복해서 처리한다. 도구를 호출하지 않았다는 사실만으로 비용이 발생하지 않았다고 판단할 수도 없다. 호출할 수 있는 도구의 정의가 매 요청의 문맥에 포함될 수 있기 때문이다.

GitHub의 Landon Cox와 Mara Kiefer는 2026년 5월 7일 공개하고 5월 13일 수정한 「Improving token efficiency in GitHub Agentic Workflows」에서 운영 워크플로의 토큰 기록과 최적화 사례를 소개했다. 이 글은 그 자료를 바탕으로 어떤 증거를 먼저 보고, 어떤 변경을 비교하며, 어디서 결론을 멈춰야 하는지를 정리한다. 공식 사례의 해설과 자체 진단 설계이며 제품 사용 후기나 독립 벤치마크가 아니다.

1. 비용을 실행별 평균 하나로 뭉치지 않는다

원문 팀은 에이전트 프레임워크마다 다른 로그 형식과 과거 기록의 누락을 API 프록시에서 정규화했다. 각 워크플로는 API 호출 하나당 레코드 하나가 담긴 token-usage.jsonl을 만든다고 설명한다. 새 입력, 출력, 캐시 읽기, 캐시 쓰기, 모델, 제공자, 시각을 기록하고 나머지 실행 로그와 연결한다. 이는 GitHub가 보고한 계측 방식이며 여기서 그 프록시를 설치하거나 운영 로그를 수집한 것은 아니다.

자신의 환경에 적용할 때는 실행 식별자와 변경 버전도 함께 묶는 편이 좋다. 총 토큰만 있으면 모델이 달라진 것인지, 캐시가 깨진 것인지, 더 큰 변경을 검토한 것인지 분리하기 어렵다. 도구 등록 목록과 실제 호출 목록은 별도 항목으로 두고, 거절된 요청과 반복 재시도도 성공한 도구 호출과 구분한다. 감사용 로그 자체에는 인증 토큰이나 민감한 문서 본문이 섞이지 않도록 한다.

호출별 기록을 실행 로그와 연결해야 모델·캐시·반복 호출을 분리할 수 있다. GitHub 보고 구조의 원본 도식이며 실제 화면이 아니다. 출처: github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows.

반복 실행이 많은 작업과 한 번의 실행이 비싼 작업을 함께 보아야 우선순위가 생긴다. 원문에서 Auto-Triage는 하루 평균 6.8회, 최대 15회 실행됐다. 이 빈도는 그 운영 사례의 값이지 모든 저장소의 예상 호출 횟수가 아니다. 독자는 자신의 실제 발생 빈도와 실행당 비용을 연결해야 한다. 단일 실행의 최대값만 잡으면 매일 쌓이는 작은 낭비를 놓칠 수 있다.

2. 미사용 MCP 도구는 조사 대상이지 자동 삭제 대상이 아니다

원문은 도구 40개를 등록한 GitHub MCP 서버의 스키마가 턴마다 10–15 KB를 더할 수 있다고 설명한다. 실제 사용이 두 개뿐인 예에서는 나머지 38개를 계속 문맥으로 운반하는 셈이다. 스모크 테스트에서 미사용 도구를 줄였을 때 호출당 문맥이 8–12 KB 줄었다는 관찰도 제시한다. KB는 바이트 규모이며 토큰 수나 청구 금액과 같은 단위가 아니다. 도구 하나당 고정 비용으로 환산해서는 안 된다.

반례도 있다. Community Attribution은 GitHub MCP 도구 여덟 개를 등록하고 한 실행에서 한 번도 호출하지 않았지만, 도구를 제거해도 ET가 줄지 않았다. 전체 문맥에서 도구 정의가 차지하는 비중이 작았기 때문이다. 같은 워크플로의 전체 개선 수치를 도구 삭제 하나의 효과로 설명하는 것은 잘못이다.

미사용 도구가 있어도 비용 효과는 문맥 구성에 따라 다르다. 서로 다른 워크플로의 관찰이며, KB 감소를 금액이나 토큰 절감률로 환산하지 않았다. 출처: github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows.

따라서 먼저 실제 요청에서 도구 정의가 얼마나 차지하는지, 제거 후 새 입력과 캐시 읽기가 어떻게 바뀌는지 확인하자. 요청 사이마다 도구 목록과 순서를 바꾸면 재사용 가능한 접두부를 깨뜨릴 수 있다. 이는 유지해야 할 운영상 경계이며 이 GitHub 글에서 캐시 손실을 별도로 측정했다는 뜻은 아니다. 안정된 업무 범위의 도구 집합을 비교하되 호출 허용과 서버 권한 검사는 그대로 유지한다. 비용을 줄이기 위해 보안 경계를 넓히거나 권한 검사를 생략하지 않는다.

3. 이미 필요한 자료와 실행 중 선택할 자료를 분리한다

PR diff나 변경 파일 목록처럼 매번 필요한 자료는 에이전트 시작 전에 결정적인 조회 단계로 받아 작업 공간 파일에 저장할 수 있다. 이 경우 모델이 조회 대상을 고르고 도구 인자를 만드는 일을 굳이 반복하지 않도록 설계하는 것이다. 원문은 이를 pre-agentic data downloads라고 부른다.

반면 어떤 댓글이나 파일을 볼지 실행 중에 판단해야 한다면 사전 다운로드로 모두 대체할 수 없다. GitHub 팀은 인증 토큰을 에이전트에 노출하지 않는 프록시를 통해 실행 중 CLI 조회를 제공했다고 설명한다. CLI를 썼다는 사실만으로 LLM 턴이 사라지는 것은 아니다. 에이전트가 명령을 선택하고 결과를 읽는 단계는 여전히 추론 과정에 포함될 수 있다.

조회할 자료가 미리 확정됐는지가 경로 선택의 기준이다. 실행 중 CLI를 선택하는 경우 모델의 판단 단계가 남을 수 있다. 출처: github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows.

편집자의 제안은 조회 위치를 바꿀 때 자료의 의미도 검증하라는 것이다. 사전 저장한 diff가 실제 검토 대상 커밋과 맞는지, 최신 댓글을 빠뜨리지 않았는지, 실패한 다운로드가 빈 파일로 성공 처리되지 않았는지를 확인한다. 호출 수가 줄었어도 필요한 증거를 잃었다면 효율 개선으로 인정할 수 없다. 모든 자료를 미리 받는 것도 해답은 아니다. 쓰지 않을 대용량 파일을 전부 입력하면 오히려 문맥이 커질 수 있다.

4. ET는 비교 렌즈이지 보편적인 청구 공식이 아니다

원문은 모델과 토큰 유형을 묶어 비교하기 위해 다음 Effective Tokens 지표를 사용한다.

ET = m × (1.0 × I + 0.1 × C + 4.0 × O)

여기서 I는 새 입력, C는 캐시 읽기, O는 출력이다. 원문이 택한 모델 가중치는 Haiku 0.25, Sonnet 1, Opus 5다. 이것은 해당 글의 비용 정규화 방식이지 현재 모든 제공자의 가격표가 아니다. 캐시 쓰기는 로그에 기록되지만 이 표시된 수식에는 별도 항이 없다. 실제 비용 감사에서는 모델 버전, 실제 단가, 캐시 쓰기 과금 등 청구 항목을 따로 맞춰야 한다. ET가 일정 비율 감소했다고 모든 환경의 실제 청구액도 같은 비율로 감소한다고 보장하지 않는다.

보고된 Auto-Triage의 ET 감소는 62%이며 변경 후 실행은 109회다. Daily Compiler는 19%와 변경 후 12회, Community Attribution은 37%와 변경 후 여덟 회다. 원문은 변경 전후 각각 적어도 여덟 회 실행한 워크플로만 결과에 포함했다고 밝힌다. 이 수치는 성공률이 아니며 동일 입력의 무작위 대조 실험 결과도 아니다. 특히 Smoke Claude의 개선에는 도구 축소와 Haiku 전환이 함께 들어가므로 도구만의 효과로 분해할 수 없다.

작업량 혼란은 Contribution Check에서 드러난다. 원문 기준 작은 작업의 비중은 41%에서 9%로, 큰 작업은 39%에서 65%로 바뀌었다. 여기서 작은 작업은 ET < 100K, 큰 작업은 ET > 300K로 분류했다. 중간 구간도 있으므로 두 비율의 합이 전체를 뜻하지 않는다. 출력 토큰은 14% 증가했고 평균 ET도 5% 증가했다. 원문은 더 무거운 작업의 증가로 설명하지만, 턴당 효율이 실제로 개선됐다는 인과 효과까지 분리해 입증한 것은 아니다. 더구나 비용 지표로 작업군을 나누면 비용 변경 자체가 구간 이동에 영향을 줄 수 있으므로, 자체 감사에는 변경 파일·규모·유형 같은 입력 조건도 함께 남기는 것이 좋다.

5. 실전 진단표: 원인 하나와 보류 조건 하나를 붙인다

비용 감사의 단위는 도구 개수가 아니라 같은 종류의 작업을 완료한 실행이다. 아래 표는 공식 도구가 자동으로 내리는 판정이 아니라 운영자가 사용할 수 있도록 재구성한 진단 흐름이다.

관찰한 현상	먼저 확인할 증거	변경 후보	효율 결론을 보류할 조건
등록 도구가 많고 실제 호출은 적다	정의의 문맥 비중, 새 입력·캐시 읽기 변화	안정된 업무 범위에 맞춰 미사용 정의 축소	캐시 손실이 커지거나 필요한 도구 호출 실패
매번 같은 PR 자료부터 조회한다	조회 대상이 실행 전에 확정되는지	결정적 사전 조회와 파일 전달	자료가 오래됐거나 조회 실패·누락
평균 비용만 상승한다	모델·버전, 입력 작업량, 출력 규모	같은 입력 조건끼리 재비교	큰 작업 비중이 바뀌었는데 전체 평균만 비교
거절 뒤 호출이 길게 반복된다	거절 원인, 경로·인자, 재시도 종료 조건	허용된 범위에서 입력 오류 수정과 중단 조건 설계	권한을 넓혀야만 통과하거나 실패 로그가 불명확
토큰·턴 수가 함께 줄었다	누락된 검토 항목과 결과 판정	성공한 작업 기준으로 재평가	처리하지 않은 업무를 절감으로 계산

비용이 내려가도 필요한 일을 덜 했다면 효율 개선이 아니다. 결과 품질을 확인할 수 없으면 승인 결론을 보류하는 편집자 설계다. 출처: github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows.

실행 순서는 기록 확보, 작업군 분리, 변경 하나 적용, 결과 품질 확인으로 잡는다. 비용이 큰 작업을 찾은 뒤 곧바로 모델·도구·프롬프트를 모두 바꾸면 어느 수정이 효과를 냈는지 알기 어렵다. 같은 조건의 비교에서도 필요한 출력이 생성됐는지, 지적이 실제로 맞는지, 중요한 결함을 놓치지 않았는지를 별도로 확인해야 한다. 실패하거나 판단할 수 없는 실행을 평균에서 조용히 빼면 절감이 과장될 수 있으므로 제외 기준도 기록한다.

6. 턴 수가 안정적이어도 정답 품질은 미확인일 수 있다

원문의 Smoke Copilot은 개선 전후 약 다섯 LLM 턴으로 실행됐고 출력·호출 완료 같은 과정 신호도 안정적이었다. 그러나 저자들은 그것이 결과 신호가 아니며 정답 품질이 개선됐는지 악화됐는지 직접 알 수 없다고 명시한다. 비용 보고서의 마지막 칸에 성공률을 임의로 채우지 말아야 하는 이유다. 정답 데이터가 없다면 표본 결과 검토와 실제 업무 기준을 추가하고, 여전히 모르는 부분은 미확인으로 남긴다.

또 원문에는 절대 /tmp 경로와 상대 경로 허용 패턴이 맞지 않아 컴파일이 거절되고, 에이전트가 64턴의 대체 작업 루프에 빠진 사례가 있다. 비용 폭증은 반드시 모델의 추론 능력이나 도구 개수 문제가 아니다. 저자들은 기준 실행이 부족해 개선폭을 정밀하게 계산하지 못했다고 설명한다. 이 사례를 이유로 로컬 권한 설정을 바꾸거나 전체 샌드박스를 느슨하게 만들지 말자. 거절 원인을 관찰하고 승인된 경계 안에서 수정 가능한지 판단하는 것이 먼저다.

결론은 “MCP를 없애라”가 아니다. 반복되는 CI에서 무엇을 운반하고, 무엇을 실제로 조회하며, 무엇 때문에 다시 시도하는지 분리해서 보자는 것이다. 절감 후보는 작업 빈도까지 고려해 정하고, 성공한 업무와 결과 품질을 확인한 뒤에만 효율 개선이라고 부른다.

이 진단표는 원문 사례를 운영 판단으로 재구성한 편집자 분석이며, 실제 CI 설치나 모델 성능의 독립 재현 결과가 아니다. AI를 활용해 공개 자료의 해설과 원본 도식을 작성했으며, 공식 제품의 화면이나 실제 운영 측정치를 새로 만들어 제시하지 않았다.

출처와 더 읽기

• GitHub 원문: Improving token efficiency in GitHub Agentic Workflows — 호출별 계측, ET, 전후 비교와 반례의 근거. 2026년 5월 13일 수정본을 보존 자료로 확인했다.
• 내부 관련 글은 이번 패키지에 추가하지 않았다. 기존 캐시·모델 전환 글과의 차이는 동결된 선정 근거에서 확인했지만, 이 단계에서 정확한 공개 URL과 현재 본문의 연결 검증을 새로 수행하지 않아 링크를 추측하지 않았다.