GitHub Copilot 크레딧,
요금 폭탄 안 맞는 법

크레딧은 '요청 수'가 아니라 토큰으로 깎인다

2026년 6월 1일, GitHub 은 Copilot 의 모든 플랜을 사용량 기반 과금으로 옮기면서 기존의 프리미엄 요청 단위(PRU) 를 GitHub AI Credits 로 교체했습니다. 이게 결정적인 변화입니다. 예전에는 "이번 달 프리미엄 요청 300건"처럼 횟수를 셌지만, 지금은 모델에 오간 토큰을 셉니다.

여기서 가장 먼저 외워야 할 건 무엇이 공짜인가입니다. 코드 자동완성(inline suggestion)과 Next Edit Suggestions 는 유료 플랜에서 크레딧을 전혀 쓰지 않고 무제한입니다. 크레딧이 깎이는 건 Copilot Chat, Copilot CLI, 클라우드 에이전트, Copilot Spaces, Spark, 그리고 서드파티 코딩 에이전트 쪽입니다.

모델별 단가 — 20배 차이가 그냥 놓여 있다

표를 세로로 훑으면 입력 기준 GPT-5 mini 와 GPT-5.5 사이에 20배, 출력 기준으로도 15배가 벌어져 있습니다. 같은 질문을 던져도 드롭다운에서 뭘 골랐느냐에 따라 청구서가 한 자릿수 바뀝니다.

그런데 이 표에는 잘 안 보이는 사실이 하나 더 있습니다. Copilot 문서에 적힌 Claude 모델 단가를 Anthropic 이 공개한 API 가격과 나란히 놓아 보면, 위 표에 실은 세 모델(Haiku 4.5 $1/$5 · Sonnet 5 $2/$10 · Opus 5 $5/$25)은 입력·출력 숫자가 그대로 일치합니다. 마진을 얹은 자체 화폐를 만든 게 아니라 모델 공급가를 그대로 넘기는 구조로 보인다는 뜻입니다. GitHub 이 전 모델에 대해 마진 0을 선언한 건 아니니 단정할 일은 아니지만, 적어도 크레딧 단가를 깎아 달라고 요구하는 접근은 의미가 없다는 결론은 나옵니다.

그래서 실제로 바뀐 건 가격이 아니라 누가 변동비를 떠안느냐입니다. 예전엔 "얼마를 쓰든 $10"이라며 GitHub 이 초과분을 흡수했고, 지금은 그 위험이 통째로 여러분 쪽으로 넘어왔습니다. 정액 뷔페가 그램 단위 계산대로 바뀐 셈입니다.

그래서 해법도 달라집니다. 협상하거나 항의해서 단가를 깎을 수는 없습니다. 깎을 수 있는 건 소비량뿐입니다.

그런데 학생은 싼 모델만 썼는데도 첫날에 털렸다

서두의 그 학생 이야기로 돌아가 봅시다. 사용 내역이 공개돼 있는데, 읽다 보면 등골이 서늘합니다.

단가만 보면 말이 안 됩니다. GPT-5 mini 입력이 100만 토큰에 $0.25인데, 35크레딧($0.35)이면 입력만 따져도 140만 토큰입니다. 채팅 몇 번에 소설 열 권 분량의 토큰이 어떻게 오갔을까요?

답은 에이전트 모드입니다. 에이전트는 한 번의 "요청"이 아닙니다. 파일을 읽고, 검색하고, 고치고, 테스트를 돌리고, 결과를 보고 다시 고칩니다. 그 모든 왕복마다 지금까지의 대화와 읽은 파일이 통째로 다시 입력에 실립니다. 10턴짜리 세션이면 초반 컨텍스트가 10번 청구되는 구조입니다.

계산해 보면 잔인합니다. Pro 의 1,500크레딧은 에이전트 세션 두 번이면 사라집니다. 프런티어 모델로 하루 한 번씩 진지한 에이전트 작업을 돌리면 3~4일 만에 한 달 치가 끝납니다.

여기서 대부분의 가이드가 틀립니다. "싼 모델을 쓰세요"라는 조언은 단가만 건드립니다. 그런데 청구서는 단가 × 수량이고, 에이전트 모드가 바꾸는 건 수량 쪽입니다. 20배 싼 모델을 골라도 토큰을 1,000배 쓰면 50배 더 나옵니다. 학생이 겪은 게 정확히 그 산수였습니다.

안 태우는 습관 다섯 가지

단가표를 외울 필요는 없습니다. 아래 다섯 개를 몸에 붙이면 대부분 해결됩니다.

1. 가벼운 작업은 자동완성만으로 끝낸다 변수명 짓기, 반복 블록 채우기, 보일러플레이트, 간단한 리팩터링. 이건 Tab 키로 끝나는 일이고 크레딧이 0입니다. 같은 걸 채팅창에 물어보는 순간 과금이 시작됩니다. "이거 채팅에 물어볼 일인가, 그냥 치면 Copilot 이 알아서 이어 쓸 일인가"를 한 번 자문하는 습관이 가장 큰 절감입니다.
2. Chat 과 CLI 는 '막혔을 때만' 연다 전체 흐름 설계, 낯선 라이브러리 이해, 원인을 모르겠는 버그 — 이런 데 씁니다. 반대로 "이 함수 뭐 하는 거야" 같은 질문은 코드를 5초 읽으면 알 수 있는 경우가 많습니다. 에이전트는 상시 페어 프로그래머가 아니라 호출 단가가 있는 외부 컨설턴트라고 생각하면 판단이 쉬워집니다.
3. 에이전트에 던지기 전에 범위를 좁힌다 "이 저장소 고쳐줘"와 "이 파일 이 함수의 null 처리 고쳐줘"는 같은 모델을 써도 토큰 소비가 자릿수 단위로 다릅니다. 관련 파일만 열어 두고, 작업 지시를 한 문장으로 특정하고, 끝나면 새 세션을 시작하세요. 이전 대화를 끌고 가면 그 전부가 매 턴 다시 입력됩니다.
4. 같은 맥락은 이어서 물어 캐시를 살린다 단가표의 '캐시 입력' 열을 다시 보면 일반 입력의 10분의 1입니다. 같은 파일을 다룬다면 세션을 닫았다 열기보다 연달아 물어보는 쪽이 캐시 히트를 만들어 냅니다. 다만 주제가 바뀌면 캐시는 어차피 깨지니, 그때는 3번 원칙대로 새로 시작하는 게 낫습니다.
5. 모델 드롭다운을 기본값으로 방치하지 않는다 질문 성격에 따라 갈아탑니다. 문법·API 사용법·짧은 설명이면 GPT-5 mini 나 Haiku 급으로 충분하고, 아키텍처 판단이나 긴 컨텍스트 디버깅에서만 상위 모델을 꺼냅니다. 단가 20배 차이는 이 드롭다운 하나에 달려 있습니다.

다섯 개를 한 줄로 줄이면 이렇습니다. 단가는 모델이, 수량은 에이전트가 정한다. 절감의 8할은 수량 쪽에서 나옵니다.

잔량은 어디서 보고, 알림은 언제 오나

습관보다 먼저 필요한 게 계기판입니다. 안 보고 달리면 어떤 습관도 소용없습니다.

개인 플랜 — 사용량 페이지

GitHub 설정에서 Settings → Billing and licensing → Metered usage → Copilot 으로 들어가면 이번 청구 주기의 포함 할당량과 소진량이 나옵니다. 요청별 비용과 어떤 모델을 썼는지까지 CSV 로 내려받을 수 있다는 점이 중요합니다. "왜 이렇게 많이 나왔지"를 추측하지 말고, CSV 를 열어 상위 몇 줄을 보면 범인이 바로 보입니다. 대개 한두 번의 긴 에이전트 세션입니다.

조직 플랜 — 예산과 이메일 경고

관리자는 엔터프라이즈·코스트센터·사용자 단위로 예산을 걸 수 있고, 구성원이 예산에 근접하면 관리자에게 이메일 알림이 갑니다. 2026년 7월 업데이트로 Business·Enterprise 구성원도 예산이 따로 설정돼 있지 않은 경우 이번 주기에 자신이 쓴 크레딧 총량을 직접 확인할 수 있게 됐습니다.

포함분이 바닥났을 때 선택지는 셋입니다. 상위 플랜으로 올려 포함량을 늘리거나, 예산을 설정해 초과분을 종량으로 결제하거나, 다음 달 리셋까지 기다리는 것. 조직에서는 관리자가 초과 사용 자체를 막아 두는 설정도 가능하니, 예측 불가능한 청구서가 무서운 팀이라면 먼저 이 캡부터 걸어 두는 걸 권합니다.

그래도 넘친다면: 정액제와 실비용 비교

습관을 고쳐도 에이전트를 많이 돌려야 하는 사람은 있습니다. 그때는 도구를 바꾸는 게 맞습니다. 다만 비교는 기능이 아니라 돈으로 해야 합니다.

이 표에서 읽어야 할 건 순위가 아니라 손익분기입니다. 월 2만 크레딧($200어치) 언저리까지 쓰는 사람에게 Copilot Max 의 $100 은 경쟁력 있는 가격입니다. 그 아래로 가볍게 쓰는 사람은 Pro 로 충분하고, 그 위로 폭주하는 사람에게는 정액제가 유리해집니다. Claude Code 는 Pro(월 $20)·Max(Pro 대비 5배 사용량, 월 $100부터) 구독에 포함되며 공식 요금 페이지 기준으로 채팅과 사용량 풀을 공유합니다. 즉 쓰는 만큼 청구되는 대신 바쁠 때 한도에 막히는 방식으로 비용을 통제하는 모델입니다. 위 세 요금은 모두 2026년 9월 각 사 공식 요금 페이지를 조회한 값이고, 요금제는 자주 바뀌니 결제 전에 링크를 직접 눌러 확인하시길 권합니다.

여기서 이상한 역설이 하나 있습니다

Copilot 은 모델별 단가를 소수점 셋째 자리까지 공개했습니다. 사용 내역도 CSV 로 내줍니다. 업계에서 가장 투명한 과금입니다. 반면 Cursor 는 개인 플랜을 $20부터 두면서도 각 티어에 얼마치 사용량이 포함되는지를 금액으로 밝히지 않고 "확장된 한도", "넉넉한 한도"라고만 적어 둡니다.

그런데 개발자들이 더 편안해하는 쪽은 후자입니다. 왜일까요. 청구서가 무서운 이유는 비싸서가 아니라 모르고 쓰다가 나중에 알게 돼서입니다. 투명한 종량제는 매 순간 미터기를 의식하게 만들고, 그 인지 부담 자체가 비용으로 느껴집니다. 불투명한 정액제는 실제로 더 비쌀 수도 있지만 적어도 놀라게 하지는 않습니다.

그러니 갈아탈지 말지를 정할 때 질문을 바꿔 보세요. "어느 쪽이 싼가"가 아니라 "내가 매달 얼마까지 놀라지 않을 수 있나"입니다. 그 금액이 정해지면 선택은 대부분 자동으로 따라옵니다. 종량제를 유지하되 그 금액으로 예산 캡을 걸든, 아예 정액제로 넘어가든.