「어라, Copilot 이용 한도가 부족하네」에서 깨달은 점

2026년 6월, 평소처럼 GitHub Copilot으로 채팅을 사용하고 있었는데, 월 초반임에도 불구하고 이용 한도가 이미 가득 차 있었다. 원인은 과금 체계 그 자체의 변경이었다.

나는 본업이 제조업의 생산 기술직이며, 부업 시간은 주당 10시간 정도밖에 내지 못한다. 그 한정된 시간 속에서 C# 도구 개발이나 컨설팅 업무에 GitHub Copilot을 최대한 활용하고 있는 입장으로서, 상한선을 신경 쓰며 작업하는 것은 은근히 고통스러운 일이다. 같은 시기에 Claude 측에서도 유사한 과금 변경 움직임이 있었다는 것을 알고, "이것은 일시적인 현상이 아니구나"라고 판단하여 본격적으로 조사하기 시작한 것이 이 글의 계기다.

결론부터 말하자면, 기본 대책(프롬프트 캐싱 (Prompt Caching)・상세한 plan → 구현의 철저한 준수)에 더해, 나는 현재 Headroom과 RTK를 주력으로 사용하고, 상황에 따라 caveman 스킬을 보조적으로 사용하는 것으로 결론을 내렸다. 왜 그렇게 판단했는지, 조사한 범위 내의 사실관계와 함께 남겨둔다.

왜 지금, 토큰 효율화가 「개인의 노력」만으로는 부족해졌는가

GitHub Copilot: Premium Requests제에서 AI Credits제로

GitHub는 2026년 6월 1일, Copilot의 과금 방식을 Premium Requests(리퀘스트 단위의 종량제)에서 GitHub AI Credits(토큰 소비 기반의 종량제)로 모든 플랜에서 전환했다. 코드 보완(Code Completion)과 Next Edit Suggestions는 유료 플랜이라면 계속해서 무제한으로 사용할 수 있지만, 채팅(Chat)・Agent Mode・Code Review 등은 "입력 토큰 수 × 모델의 입력 단가 + 출력 토큰 수 × 모델의 출력 단가"로 AI Credits가 소비되는 구조로 바뀌었다.

1 AI Credit = 0.01달러이며, Copilot Business는 사용자당 월 1,900 크레딧, Enterprise는 월 3,900 크레딧이 부여된다. 기존 법인 사용자에게는 2026년 9월 1일까지 더 많은 크레딧(Business 3,000 / Enterprise 7,000)이 부여되는 이행 조치도 있지만, 이 또한 한시적이다. 지금까지 "가벼운 질문도 몇 시간 동안의 Agent 세션도 똑같은 1 리퀘스트"였던 거친 과금 방식에서, 토큰 단위의 정밀한 과금 방식으로 바뀌었다는 것은, 뒤집어 말하면 "무엇에 얼마나 많은 토큰을 쓰고 있는지"를 파악하지 못하는 사람일수록 손해를 보기 쉬운 설계가 되었다는 뜻이기도 하다.

Claude Agent SDK: 구독 범위에서의 분리는 「일시 중지 중」

Anthropic 측에서도 비슷한 시기에 유사한 움직임이 있었다. 채팅이나 대화형 Claude Code 이용은 계속해서 구독(Subscription) 범위 내에 있지만, Agent SDK의 직접 호출・claude -p (헤드리스 실행)・Claude Code GitHub Actions・서드파티 에이전트를 통한 이용에 대해서는, 구독과는 별도의 "월간 크레딧"으로 분리하는 변경이 예고되어 있었다. 크레딧 금액은 플랜 월정액과 동일한 금액(Pro라면 20달러분 등)이지만, 월간 리셋 시 이월 불가라는 내용이다.

이는 2026년 6월 15일에 시행될 예정이었으나, 시행 당일에 긴급히 일시 중지되었다. 현시점(2026년 6월 20일)에서는 Agent SDK나 claude -p는 기존처럼 통상적인 구독 범위에서 소비되는 운용이 계속되고 있다. OpenAI의 대폭적인 가격 인하 보도와 거의 비슷한 시기였다는 점이나, Anthropic이 상장 준비 프로세스에 있다고 알려진 점 등, 일시 중지의 배경을 추측하는 보도도 있으나 공식적으로 이유가 명시된 것은 아니다. 어쨌든 "구독 내에서 무제한에 가깝게 사용할 수 있는 상태"가 언제까지 지속될지는 불투명하다는 것이 솔직한 심정일 것이다.

계산 자원·전력이라는, 더 큰 배경

개별 기업의 과금 변경 이면에는 업계 전체의 구조적인 문제도 있다. 국제 에너지 기구(IEA)의 추산에 따르면, 데이터 센터의 전력 소비는 2022년 약 460TWh에서 2026년에는 약 1,000TWh로 두 배 증가할 전망이며, 이는 일본의 연간 총 소비 전력에 필적하는 규모다. AI 업계 컨퍼런스에서는 현재의 AI 이용 요금이 "적자를 각오한 특별 가격"이며, 2027년까지는 본래의 시장 가격(현재의 최대 10배라고도 불리는)에 가까워지지 않겠느냐는 지적도 나오고 있다.

GitHub Copilot과 Claude 모두 단독적인 가격 인상이라기보다는, 계산 자원 및 전력의 부족이라는 더 큰 흐름 속에서 일어나고 있는 변화로 파악하는 것이 좋아 보인다. 그렇다면 개인이나 소규모 팀 개발자에게 있어 「토큰을 효율적으로 사용하는」 노력은 임시방편이 아니라 앞으로도 유효한 기술이 될 것이다.

효율화의 토대: 프롬프트 캐싱 (Prompt Caching)과 「먼저 계획, 나중에 구현」

OSS 도구 이야기를 하기 전에, 토대가 되는 기본 대책 두 가지를 확인해 두고 싶다.

프롬프트 캐싱 (Prompt Caching)의 활용. Anthropic API의 Prompt Caching은 긴 시스템 프롬프트 (system prompt)나 문서 컨텍스트 (document context)를 재사용할 때, 캐시 읽기 분량의 입력 단가를 약 10% (즉, 약 90% 할인)로 만들어 주는 메커니즘이다. 대신 캐시 쓰기는 5분 TTL (Time To Live) 기준 일반 가격의 1.25배, 1시간 TTL 기준 2배의 비용이 들지만, 동일한 컨텍스트를 반복해서 호출하는 방식 (규모가 큰 리포지토리를 하루 종일 다루거나, 방대한 도구 정의를 가진 에이전트 (Agent)를 구동하는 등)이라면 쓰기 비용은 금방 회수할 수 있다. GitHub Copilot의 채팅이나 에이전트 계열 도구에서도 동일한 파일이나 컨텍스트를 재사용하는 세션 설계를 의식하는 것만으로도 캐시 히트율 (cache hit rate)은 달라진다.

상세한 계획 (plan)을 세운 뒤 구현하기. 이는 미미해 보이지만 효과가 크다. 에이전트 모드 (Agent Mode)에 갑자기 "이것을 구현해 줘"라고 통째로 맡겨버리면, 시행착오를 겪을 때마다 파일 전체를 다시 읽거나 엉뚱한 변경 사항을 생성하여 되돌리는 과정에서 토큰을 반복해서 낭비하게 된다. 먼저 플랜 모드 (Plan mode)에서 방침을 확정하고 변경 범위를 좁힌 뒤 구현에 들어가는 것이 결과적으로 소비 토큰도 적고 되돌리는 작업 (rework)도 줄어든다. 나 자신도 VBA에서 C#으로의 전환 작업에서 에이전트 모드를 사용했을 때, 처음에 대략적인 전환 방침과 파일 단위의 작업 순서를 결정하고 착수한 세션이, 즉흥적으로 진행했던 세션보다 확연히 대화가 짧게 끝났다.

이 두 가지는 특정 OSS에 의존하지 않는, 말하자면 기초 체력에 해당하는 부분이다. 여기서부터는 그 위에 쌓아 올리는 「전용 도구」에 관한 이야기다.

토큰 효율화 OSS 비교

조사하는 과정에서 유사한 컨셉의 OSS가 2026년에 들어서며 차례차례 등장하고 있음을 알 수 있었다. 이번에 비교한 것은 다음 6가지다.

숫자는 모두 각 리포지토리의 공식 README 및 공식 문서에 기재된 값이며, 필자가 직접 측정한 것이 아니다. 콘텐츠의 종류나 사용 방식에 따라 실제 절감률은 달라지므로 참고용으로만 봐주길 바란다.

여기서부터는 내가 주력 후보로 깊이 있게 살펴본 Headroom, RTK, caveman을 중점적으로 다루고, 나머지 3개는 요점만 소개하겠다.

Headroom — 모든 콘텐츠 유형을 로컬에서 가역 압축한다

Headroom는 Netflix의 시니어 엔지니어가 개인적으로 개발하여 공개한 OSS로, AI 에이전트가 읽어들이는 프롬프트, 툴 출력, 로그, RAG 결과, 파일을 LLM에 전달하기 직전에 로컬에서 압축하는 "컨텍스트 압축 레이어 (Context Compression Layer)"이다. 저자 본인도 월 Claude Code 이용료가 약 280달러가 되어 내역을 조사한 결과, 불필요한 JSON 행들이 컨텍스트를 채우고 있었다는 사실을 깨달았으며, Headroom 도입 후에는 약 110달러까지 낮아졌다고 보고했다 (이는 어디까지나 자기 신고 수치이다).

핵심이 되는 것은 ContentRouter라는 메커니즘으로, 콘텐츠의 종류를 자동으로 판정하여 전용 압축기로 배분한다. JSON 배열은 SmartCrusher, 소스 코드는 AST 분석을 동반하는 CodeCompressor, 검색 결과는 SearchCompressor, 빌드/테스트 로그는 LogCompressor, diff는 DiffCompressor, 일반 텍스트는 Kompress-base(자체 머신러닝 모델)가 담당한다. 공식 문서에 기재된 절감률은 검색 결과나 로그처럼 중복되기 쉬운 콘텐츠의 경우 8095%, 정보 밀도가 높은 소스 코드의 경우 4070%로, 콘텐츠의 성격에 따라 차이가 있다.

또 다른 특징은 CCR(Content Compression Retrieval)이라 불리는 가역 압축 메커니즘이다. 압축 전의 오리지널을 로컬에 저장해 두었다가, LLM이 상세 정보가 필요할 때만 추출 도구를 통해 복원할 수 있다. "너무 압축해서 필요한 정보가 사라질까 봐 두렵다"라는 불안에 대해, 퇴로를 마련해 둔 설계라고 할 수 있다. 공식 벤치마크에서는 GSM8K(수학적 추론)에서 정확도 변화 없음, TruthfulQA(사실성)에서는 약간의 개선이라는 결과도 나오고 있다.

도입 형태는 4가지가 준비되어 있다.

# Proxy로서 실행 (코드 변경 없이 테스트 가능)
pip install "headroom-ai[proxy]"
headroom proxy --port 8787
...

코드를 고치고 싶지 않다면 headroom proxy나 headroom wrap claude와 같은 에이전트 래핑(Agent wrap), 자체 앱에 세밀하게 통합하고 싶다면 Library, MCP 클라이언트를 통해 사용하고 싶다면 MCP server라는 선택지가 된다. 대응 에이전트는 Claude Code, Codex, Cursor, Aider, Copilot CLI, OpenClaw 등이다. Claude/Codex/Gemini를 가로지르는 공유 메모리 기능이나, 실패한 세션으로부터 CLAUDE.md로의 수정을 자동 학습하는 headroom learn도 있어, 여러 에이전트를 구분해서 사용하는 사람일수록 이점이 큰 설계로 되어 있다.

주의점도 있다. Headroom는 로컬 프로세스를 실행할 수 있는 환경을 전제로 하기 때문에, 로컬 실행이 불가능한 샌드박스 환경에서는 사용할 수 없다. 단일 프로바이더의 네이티브한 대화 압축 기능만으로 충분한 사람에게는 굳이 추가할 만큼의 가치가 낮을 수도 있다.

RTK — CLI 출력만을 깎아내는 경량 단일 바이너리

RTK는 CLI 커맨드 출력의 토큰 소비를 60~90% 절감하는 Rust 기반의 싱글 바이너리(Single Binary)다. 의존 라이브러리가 거의 제로에 가깝고, 대응 커맨드는 100개 이상이며, 오버헤드는 10밀리초 미만이라고 한다. 스코프는 CLI 커맨드 출력으로 한정되어 있으며, Headroom와 같은 가역 압축 메커니즘은 가지고 있지 않다.

흥미로운 점은, Headroom가 이 RTK 바이너리를 내부에 동봉하여 쉘 출력의 재작성에 이용하고 있다는 점이다. 즉, 두 관계는 단순한 경쟁 관계라기보다, RTK가 CLI 출력이라는 한 점에 특화되어 있고 Headroom가 그 하류에서 모든 콘텐츠 타입을 다루는 보완 관계에 가깝다. "CLI 출력 절감만으로 충분하다" 혹은 "어쨌든 경량 단일 바이너리로 끝내고 싶다"라면 RTK 단독 사용, "CLI 이외의 로그나 RAG, 파일도 한꺼번에 줄이고 싶다"라면 Headroom라는 식으로 역할 분담이 된다.

나의 경우 이미 Headroom 도입을 결정했으므로, RTK를 단독으로 추가할 필요는 별로 없다. 다만 "우선 가장 가벼운 대책부터 시도해보고 싶다"는 사람에게는 RTK 단독 사용부터 시작하는 것도 충분히 합리적이다.

caveman — Claude를 "과묵하게" 만들어 출력 토큰을 줄이는 이색적인 스킬

caveman은 성격이 완전히 다르다. 인디 개발자 Julius Brussee가 공개한 Claude Code 스킬로, Claude의 응답을 "문장이 아닌 파편"으로 돌려받는, 말하자면 톤(Tone) 자체를 바꾸는 접근 방식이다. "알겠습니다", "훌륭한 질문입니다"와 같은 서두, 문제의 재진술, "추가로 조정하고 싶은 점이 있다면 말씀해 주세요"와 같은 맺음말을 깎아내어 전보(Telegram) 스타일의 응답으로 만든다. 생성되는 코드나 실행 내용 자체는 변하지 않는다. 변하는 것은 그것을 설명하는 문장의 "포장지" 부분이다.

공식 README에 기재된 수치는 10개 프롬프트 평균으로 출력 토큰(Output Token) 65% 절감(범위는 2287%)이다. 반면 독립적인 검증 기사에서는 헤드라인대로의 75%가 아니라 실측 1525% 정도라는 결과가 보고되고 있다. 나는 이 "벤더의 공칭값과 독립 검증 사이에 차이가 발생하는" 구도 자체가 성실함의 척도가 된다고 느끼고 있으며, caveman을 보조적으로 사용할지 판단하는 기준 중 하나가 되었다.

# macOS / Linux / WSL / Git Bash
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

솔직히 말하면, 처음에 이 컨셉을 보았을 때는 "장난삼아 만든 도구(Neta tool)가 아닐까"라며 반신반의했다. 하지만 조사해 보니, 출력 토큰은 주요 프로바이더에서 입력 토큰보다 2~5배의 비용이 드는 경우가 많아, "출력을 줄이는 것"은 비용 효율성 측면에서 가장 투자 대비 효율이 높은 지점이라는 논리는 일리가 있다. 반면, 복잡한 원인 규명이나 학습 목적의 대화처럼 설명의 장황함 그 자체에 가치가 있는 상황에는 적합하지 않다. 기계적인 작업(리팩터링, 정형화된 커밋, 로그 정렬)에는 사용하고, 원인 불명의 버그를 쫓을 때는 끄는 식으로 구분하여 사용하는 것이 현실적일 것이다.

번외: context-mode, lean-ctx, h5i에 대해서도 언급해 두기

주력 후보는 아니지만, 조사 과정에서 눈에 띈 3가지에 대해서도 간단히 언급해 두겠다.

context-mode는 Claude Code와 MCP 도구 사이에 위치하는 MCP 서버로, 도구 출력을 압축 및 필터링한 후 대화 이력에 전달한다. 공식 측은 315KB의 출력을 5.4KB까지 압축(98% 절감)한 사례를 소개하고 있으며, 동일한 200K 토큰 상한에서 세션 지속 시간이 30분에서 3시간으로 늘어났다는 보고도 있다. SQLite FTS5 기반의 인덱스로 Markdown 콘텐츠를 검색할 수 있게 하여, BM25 랭킹으로 해당 부분을 좁힐 수 있다. MCP 도구를 대량으로 활성화하고 있는 사람일수록 효과를 체감하기 쉬울 것이다.

lean-ctx는 "AI 개발을 위한 Context OS"를 표방하는 로컬 바이너리로, CLI 출력, 파일 읽기, 검색 결과, 프로젝트 컨텍스트를 63개의 MCP 도구와 10종류의 읽기 모드로 커버한다. 캐시된 콘텐츠의 재읽기에서는 최대 99%의 절감을 주장하고 있다. MCP를 축으로 컨텍스트 관리를 구축하고 싶을 때의 후보가 된다.

h5i는 성격이 조금 달라서, "AI 에이전트를 위한 Git"을 표방하는 도구다. 커맨드 출력을 통일된 스키마로 변환하여, 에이전트에게는 압축된 요약만 보여주면서 생데이터(Raw data)는 Git LFS와 같은 메커니즘으로 외부 참조 가능한 형태로 저장한다. 옥스퍼드발 연구(Git 방식의 컨텍스트 관리가 SWE-Bench Verified의 태스크 해결률을 13% 이상 개선했다는 논문)에서 착안했다고 알려져 있으며, AI 생성 코드를 격리 환경에서 실행한 후 가져오는 감사용 샌드박스 기능도 갖추고 있다. 공식 측은 "95%의 토큰 낭비를 절감"한다고 밝히고 있다.

이 세 가지는 이번에 깊게 파고들지는 않았지만, MCP 도구를 다용하는 구성이라면 context-mode나 lean-ctx, 여러 에이전트의 인수인계나 감사 로그를 중시한다면 h5i라는 방향성은 염두에 두는 것이 좋다.

현재의 결론: Headroom + RTK를 주력으로, caveman은 상황에 따라

지금까지의 정리를 바탕으로, 나는 Headroom와 RTK를 적극적으로 사용하고, 상황에 따라 caveman을 보완하는 방식으로 운영하기로 결정했다. 이유는 다음 세 가지다.

첫 번째는 Headroom의 넓은 커버리지와 CCR에 의한 가역성(reversibility)이다. 프롬프트, 툴 출력, 로그, 파일까지 일괄적으로 다룰 수 있으며, 만약 너무 압축해서 문제가 생기더라도 원본을 되찾을 수 있다. 이는 "공격적인 압축을 시도하더라도 정확도가 떨어질 리스크를 억제할 수 있다"는 안심 요인이 된다.

두 번째는 RTK가 Headroom에 내포되어 있는 사실상의 보완 관계라는 점이다. 굳이 별도의 툴로 늘리는 비용이 거의 들지 않는다.

세 번째는 caveman의 효과가 독립 검증에서 15~25% 정도에 그친다는 솔직한 수치다. 결코 작지는 않지만, headline의 75%라는 수치를 그대로 믿을 수는 없다. 그렇기에 "항시 온(Always-on)"이 아니라, 기계적인 작업에 한정하여 사용하는 보조적인 위치로 설정했다.

한편, 여기에 적은 절감률이나 효과는 모두 각 툴의 공식 기재 값 또는 제삼자의 검증 기사에서 인용한 것이며, 나 자신이 아직 실제 업무에서 측정한 수치는 아니다. 주 10시간이라는 한정된 시간 내에서의 도입이 될 것이므로, 처음 몇 주간은 "사용 가능한가, 정말 효과가 있는가"를 판별하는 것부터 시작해야 할 것 같다.

다음에 할 일

여기까지는 조사와 선정에 관한 기사이며, 실제 실전 투입은 이제부터다. 다음에는 실제로 Headroom와 RTK를 나의 C# 개발 및 컨설팅 업무 워크플로우에 편입시켜, 토큰 소비량이 얼마나 변했는지, CCR의 가역 압축으로 인해 정확도 면에서 위화감은 없었는지, caveman을 어떤 상황에서 온/오프했는지와 같은 "사용해 본 실감"을 수치와 함께 정리할 예정이다.

자주 묻는 질문 (FAQ)

Q. Headroom와 RTK를 둘 다 설치해야 하나요?

A. Headroom는 RTK 바이너리를 내부에 동봉하여 CLI 출력의 재작성에 이용하고 있기 때문에, Headroom를 설치하면 RTK의 기능은 사실상 커버됩니다. CLI 출력 절감만으로 충분하다면 가벼운 RTK 단독 사용을, 로그나 RAG·파일까지 포함하여 줄이고 싶다면 Headroom만으로 둘 다 해결할 수 있습니다.

Q. caveman 스킬은 항상 켜두는 것이 좋은가요?

A. 리팩터링(Refactoring)이나 정형화된 커밋, 코드 리뷰와 같은 기계적인 작업에는 적합하지만, 원인 불명의 버그를 추적할 때나 학습 목적으로 설명을 읽고 싶을 때는 장황함 그 자체에 가치가 있기 때문에 부적합합니다. 태스크에 따라 온/오프를 전환하는 것이 현실적입니다.

Q. GitHub Copilot의 AI Credits제로 바뀌면서 가장 변한 점은 무엇인가요?

A. 코드 완성(Code Completion)과 Next Edit Suggestions는 유료 플랜이라면 계속해서 무제한이지만, 채팅(Chat), Agent Mode, Code Review 등은 토큰 소비량에 따라 AI Credits가 차감되는 방식으로 바뀌었습니다. 월초에 크레딧 잔량을 확인하는 운영이 거의 필수적이 됩니다.

Q. Claude Agent SDK의 과금 변경은 결국 어떻게 되었나요?

A. 2026년 6월 15일에 시행될 예정이었으나, 시행 당일에 일시 정지되었습니다. 본 기사 작성 시점에서는 Agent SDK나 claude -p는 계속해서 일반적인 구독 범위 내에서 소비되는 운영이 이어지고 있습니다. 향후 다시 변경 사항이 발표될 가능성은 있습니다.

Q. 이러한 OSS를 도입하면 과금 체계 변경 자체에 대한 대책이 될까요?

A. 토큰 소비량을 줄이는 것은 AI Credits든 API 종량제(Pay-as-you-go)든 지출 억제와 직결되므로 유효한 대책 중 하나가 됩니다. 다만 툴 도입에만 의존하지 말고, 모델 선정의 재검토 및 프롬프트 설계 개선과 병행하여 추진하는 것을 추천합니다.

Discussion