2026년 6월 1일부터 GitHub Copilot의 과금 체계가 변경되었습니다.

X(Twitter)에서는 일본뿐만 아니라 해외에서도 신랄한 의견들이 쏟아져 나오고 있었습니다. Claude Sonnet의 크레딧 소비량이 구 제도 대비 9배, Claude Opus의 경우 무려 27배에 달한다는 수치가 일부 사용자로부터 보고되고 있어, Agent mode를 일상적으로 사용하던 사람들에게는 사실상의 대폭 인상입니다.

이 소동을 계기로 "애초에 토큰을 어떻게 절약할 것인가"라는 주제를 조사해 보고 싶어졌습니다.

이번에는 X(Twitter)에서 주로 해외 유저들의 토큰 절약에 관한 정보를 수집했습니다.

Netflix 엔지니어가 만든 토큰 압축 도구인 "Headroom"에 대해서는 이전에 게시한 기사를 참조해 주세요. 이번에는 그 외의 기법들을 중심으로 정리합니다.

• GitHub Copilot이 6/1부터 종량제로 이행하며, Agent mode 다용자는 실질적으로 대폭 인상됨
• 출력(Output) 감소에는 케이브맨(Caveman, 원시인) 프롬프트, 입력(Input) 감소에는 **프롬프트 캐싱(Prompt Caching)**이 현재의 2대 기법 - 설계서→코드 단계에는 캐싱 전략, 코드→설계서 단계에는 서브 에이전트(Sub-agent) 분리가 현실적인 정답

구 제도에서는 "프리미엄 리퀘스트(Premium Request)"라는 단위로 관리되었습니다. GPT-4o나 Claude Sonnet을 호출할 때마다 일정량의 프리미엄 리퀘스트를 소비하며, 상한선을 초과하면 저품질 모델로 자동 전환되는 설계였습니다. 상한에 도달해도 완전히 정지되지는 않는 안전장치가 있었습니다.

새로운 제도인 "GitHub AI Credits"는 토큰 소비량 기반의 종량제입니다. 1 AI Credit은 **달러 환산 시 대략 $0.01 상당(기준)**이며, 입력(Input)·출력(Output)·캐시(Cache) 토큰이 모델별 단가로 계산됩니다.

플랜별 월간 부여 크레딧은 다음과 같습니다.

※ 출처: GitHub 공식 문서 - 개인 사용량 기반 과금

월 정액은 그대로 유지하되, 동일한 금액 상당의 크레딧이 부여되는 구조입니다.

중요하므로 강조해 둡니다. 인라인 보완(Inline Completion)과 Next Edit 제안은 AI Credits를 소비하지 않습니다. 모든 플랜에서 현시점에서는 무제한입니다. 소동이 되고 있는 것은 채팅(Chat)·Agent mode·코드 리뷰(Code Review)입니다.

채팅에서 짧은 질문을 할 경우, 입력 500토큰·출력 200토큰 정도라면 소비되는 크레딧은 매우 적어 1회당 큰 금액이 되지 않습니다.

Agent mode는 다릅니다. "이 기능을 수정해 줘"라는 한마디에 에이전트가 여러 파일을 읽고, 도구(Tool)를 호출하며, 직전의 문맥을 재투입하고, 구현과 검증을 반복합니다. 하나의 요청이 내부적으로 수십 번의 모델 호출로 분해되어 입력과 출력이 쌓이게 됩니다. 게다가 구 제도의 폴백(Fallback) 기능이 폐지되었기 때문에, 크레딧을 다 쓰면 기능이 정지됩니다(코드 보완은 계속됨).

2026년 3월경, GitHub에 JuliusBrussee/caveman이라는 리포지토리가 등장하여 며칠 만에 수천 개의 스타(Star)를 획득했습니다.

발상은 단순합니다. **"LLM을 원시인처럼 말하게 하는 것"**입니다.

※ Caveman(케이브맨) = 원시인

# Caveman Mode
- No filler
- No grammar if not needed
...

일반적인 LLM은 다음과 같이 답합니다.

"JOIN을 사용할 수 있습니다. SQL에서는 공통 키를 사용하여 두 테이블에서 데이터를 결합할 때 JOIN 절을 활용할 수 있습니다."

Caveman Mode라면 다음과 같이 됩니다.

"JOIN 사용"

의미는 같습니다. 토큰 수는 천지차이입니다.

"75% 절감"이라는 홍보 문구로 퍼졌지만, 검증한 사람들의 수치는 다음과 같습니다.

Headroom 때와 마찬가지로, "코드 블록 자체는 압축되지 않는다"는 사양 때문에 수치가 낮아집니다. 출력의 대부분이 코드라면 효과는 제한적입니다.

2026년 3월의 arXiv 논문(arXiv:2604.00025)에 따르면, 31개 모델을 1,485개 문항으로 평가한 결과, 간결함을 제약했을 때 대형 모델의 정확도가 올라가는 케이스가 있다는 것을 알 수 있었습니다.

대형 모델이 불필요한 설명을 쓰다가 스스로 혼란에 빠지는 현상(spontaneous scale-dependent verbosity라고 불림)이 원인인 것으로 보입니다. 이는 비용뿐만 아니라 품질 측면에서도 긍정적인 방향으로 작용할 가능성이 있습니다.

Caveman Prompt의 시스템 프롬프트(System Prompt) 본체는 수백 토큰에 달합니다. 단발성 쿼리(Query)라면 이 추가 비용이 절감분을 상회합니다. 하지만 여러 턴의 대화에서 프롬프트 캐싱(Prompt Caching)이 적용되기 시작하면 이야기가 달라집니다.

적합한 상황:

• 긴 에이전트 세션(Agent Session)을 반복할 때 (캐싱이 적용됨)
• 코드가 아닌 설명·분석·요약을 생성할 때
• 에이전트가 동일한 질문을 여러 번 반복하는 파이프라인

부적합한 상황:

• 단발성 질문
• 출력의 대부분이 코드 블록(Code Block)일 때
• 상세한 설명이 필요한 문서 생성

GitHub Copilot의 새로운 요금 체계에서도 캐시 토큰의 단가는 입력(Input)보다 저렴하게 설정되어 있습니다. 이를 의식하여 설계하느냐에 따라, 동일한 작업을 하더라도 청구 금액이 달라집니다.

LLM이 동일한 텍스트를 매번 처음부터 다시 읽는 것은 비효율적입니다. Anthropic은 KV(Key-Value) 캐시라는 메커니즘을 통해, 한 번 읽은 접두사(Prefix)의 계산 결과를 서버에 저장합니다. 두 번째 호출부터는 90% 할인(Anthropic 공식) 됩니다.

X(Twitter)에서도 캐싱을 통한 대폭적인 비용 절감 사례가 보고되고 있습니다.

# 캐싱이 잘 적용되는 배치 (순서가 핵심)
[상단 배치: 정적인 것]
- 시스템 프롬프트
...

Anthropic API에서는 캐시 브레이크포인트(cache_control) 지정이 필요하지만, Copilot이나 각종 AI 에이전트에서는 내부적으로 유사한 캐시 전략이 이용되고 있기 때문에, 정적인 정보를 앞부분에 배치하는 설계가 일반적으로 권장됩니다.

시스템 프롬프트에 타임스탬프를 삽입하거나, 세션 중에 모델을 교체하거나, 도구(Tool) 정의의 순서를 바꾸는 행위.

이러한 것들은 모두 캐시 미스(Cache Miss)를 유발합니다.

Copilot의 새로운 체계에서 특히 중요해진 사고방식입니다. 고성능 모델을 모든 태스크에 사용하는 것은 택시를 타고 출퇴근하는 것과 같습니다.

Copilot에서 이용 가능한 주요 모델의 비용 체감(크레딧 소비량은 모델의 실제 토큰 단가에 기반함):

일부 사용자로부터 보고된 Claude Sonnet의 멀티플라이어(Multiplier)는 구 제도 대비 9배, Opus는 27배입니다. Pro(월 1,500 크레딧)에서 Opus 계열을 마음껏 사용한다면 며칠 만에 크레딧이 고갈될 것입니다.

파일 탐색 · grep · 테스트 실행 등 '읽기 부하가 큰 작업'을 별도의 컨텍스트 윈도우(Context Window)로 분리하여, 메인 대화를 가볍게 유지하는 접근 방식입니다.

Agent mode에서 파일을 대량으로 읽게 하면 입력 토큰이 쌓이게 됩니다. 서브 에이전트(Sub-agent)에게 조사를 위임하고 요약만 돌려받게 하면, 메인 컨텍스트에 미치는 영향을 최소화할 수 있습니다.

이렇게 지시하십시오.

src/auth 하위의 인증 플로우를 조사해서,
시퀀스 다이어그램에 필요한 클래스와 메서드만
불렛 포인트로 반환해 주세요 (코드 본체는 불필요).

이렇게만 해도 파일 탐색 비용이 메인 세션에 부담을 주지 않게 됩니다.

이 두 가지를 조합할 수도 있습니다. Caveman Prompt를 시스템 프롬프트에 넣어두면, 추가 프롬프트 부분은 캐시 대상이 되기 때문에, 오버헤드를 억제하면서 출력 절감 효과를 얻을 수 있습니다.

Headroom은 이 두 가지에는 효과가 없다고 지난번에 말씀드렸습니다. 그렇다면 무엇을 사용해야 할까요?

가장 효과적인 것은 **프롬프트 캐싱(Prompt Caching)**입니다. 설계서는 '매 턴 변하지 않는 정적 텍스트'이므로 캐시와의 궁합이 매우 좋습니다. 설계서를 상단에 배치하고 캐시 브레이크포인트를 설정하면, 사양 추가나 수정이 일어날 때마다 전체 비용을 들여 다시 읽을 필요가 없어집니다.

서브 에이전트 분리 (Sub-agent separation) 가 현실적인 정답입니다. 코드를 전부 메인 컨텍스트 (Main context) 에 읽어들이면 순식간에 용량이 가득 차버립니다. "필요한 클래스와 메서드만 불렛 포인트로 반환해줘"와 같은 위임 태스크 (Delegation task) 를 중간에 끼워 넣음으로써, 메인으로 유입되는 데이터 양을 대폭 줄일 수 있습니다.

참고로, 설계서 출력에 Caveman Prompt를 사용하는 것은 추천하지 않습니다. 설계서가 원시인 언어처럼 변해버립니다.

GitHub Copilot의 요금 개정은 단순히 "요금표가 바뀐 것"이 아니라, "무엇을 어떤 모델로 어떻게 사용할 것인가"를 다시 한번 생각하게 만드는 계기가 되고 있습니다.

Agent mode를 아무 생각 없이 사용하다가는 순식간에 크레딧 (Credit) 이 녹아 없어집니다. 다만, 코드 보완 (Code completion) 은 현 시점에서는 무제한인 상태이므로, "채팅과 에이전트만 주의한다"는 것이 당면한 현실적인 방침입니다.

Copilot 대시보드에서 모델별·기능별 소비량을 확인할 수 있게 되어 있으므로, 우선 자신의 소비 패턴을 확인한 뒤 대책을 선택하는 것이 순서라고 생각합니다. 시도해 보신 분들은 소감을 댓글로 알려주세요!

※ 진행 중인 Qiita 캠페인의 "에너지 드링크 파"가 최하위이므로 본 기사에 "좋아요" 부탁드립니다 m(__)m

※ 이 외에도 토큰 비용을 절약하는 Netflix 엔지니어가 만든 도구인 "Headroom"에 대해 조사해 보았으니, 아래 기사도 참고해 주세요.

• Updates to GitHub Copilot billing and plans (공식)
• JuliusBrussee/caveman (GitHub)
• I Benchmarked the Viral "Caveman" Prompt - Kuba Guzik
• Caveman: Reducing LLM Output Tokens - Better Stack
• GitHub Copilot のAI クレジット移行を整理する - Qiita
• arXiv: Brevity Constraints Reverse Performance Hierarchies in Language Models (2026년 3월)