VS Code에서 GitHub Copilot 크레딧이 소진됐다는 안내가 뜨면, Pro+로 올려야 하는지부터 고민하게 됩니다.
그런데 지금 필요한 것은 더 큰 요금제일 수도 있고, 추가 사용 예산을 열거나 월초까지 기다리는 선택일 수도 있죠.
먼저 AI usage에서 포함량과 추가 사용량을 나눠 보고, 예산의 사용 중지 설정과 다음 초기화 날짜를 확인하세요. 돈을 더 쓸지 결정하기 전에 현재 어떤 제한에 걸렸는지부터 알아야 합니다.
개인용 Copilot을 쓰는 독자를 위한 확인 순서죠.
검토 기준: 2026년 10월 15일 GitHub 공식 요금표와 결제·예산·사용량 문서를 대조했습니다. 실제 계정 결제나 소진 실험은 하지 않았으며, 아래 작업 사례는 설명을 위한 가정이죠.
소진 안내에서 바로 결제창으로 가지 않아도 됩니다
📚 관련 글: Claude Code로 AI 코딩 도구 만들기 — 2주 30 Phase 완주기
잔여량이 없다는 말만으로는 판단하기 어렵습니다. 구독에 들어 있는 양을 다 썼는지, 이미 허용한 추가 사용도 한도에 닿았는지에 따라 확인할 화면이 달라집니다.
개인 계정은 GitHub 결제 설정의 AI usage에서 시작하면 됩니다. 포함 크레딧 소비량, 포함량을 넘어 쓴 양, 모델별 사용량과 비용을 볼 수 있죠.
Copilot settings의 Usage에서도 현재 사용량을 확인할 수 있습니다 (GitHub 공식: 사용량 확인).
여기서 총량 숫자 하나만 옮겨 적지 마세요. 포함량과 추가 사용량을 따로 적어 두면, “구독은 결제했는데 왜 더 나오지?”라는 의문을 풀기 쉽습니다.
정액 구독료와 초과 사용을 한 항목으로 묶으면 다음 달 예산도 헷갈리죠.
VS Code에서는 상태 표시줄의 Copilot 아이콘으로 사용량 정보를 열 수 있죠.
작업 중 잔여량과 초기화 날짜를 빨리 보는 용도로 쓰고, 구매 판단에는 웹의 모델별 내역까지 함께 확인하는 편이 좋겠습니다 (GitHub 공식: IDE에서 보기).
오래된 VS Code라면 표시부터 점검하세요
정확한 과금·사용량 표시를 위한 권장 최소 버전은 공식 문서상 VS Code 1.120이죠. 구버전에서도 계속 동작하지만 과금 용어나 사용량, 알림이 부정확할 수 있어요.
현재 안정 버전과 확장을 확인한 뒤 웹 표시와 대조하세요 (GitHub 공식: 클라이언트 호환성).
참고로, 문서를 읽기 위한 새 도구 설치는 필요 없죠. 버전 확인과 추가 결제는 따로 판단해도 괜찮습니다.
| 막힌 지점 | 점검할 대상 | 먼저 할 일 |
|---|---|---|
| 채팅·에이전트의 소진 안내 | 포함 크레딧과 추가 사용 | 웹 AI usage의 두 항목을 대조. |
| 자동완성까지 동작하지 않음 | 크레딧 외의 가능성 | 추가 결제부터 하지 말고 계정·클라이언트 확인. |
| premium requests 표시 | 기존 연간 과금 예외 또는 오래된 표시 | 웹 계정의 과금 방식과 문서 대조. |
예를 들어 작은 수정 몇 건 뒤 소진됐다고 느껴졌다면, 오늘 수정 횟수만 세어서는 답이 안 나옵니다. 어떤 모델로 어떤 작업을 했는지 내역을 먼저 보세요.
의심되는 작업을 찾기 전부터 플랜을 올리면, 늘어난 포함량을 어디에 쓰는지 모르는 상태가 이어집니다.
회사에서 받은 Copilot 좌석이라면 개인 카드의 예산부터 바꾸는 순서는 맞지 않습니다.
Business·Enterprise 사용자는 Copilot settings에서 개인 소비량을 확인하며, 소진 시 관리자에게 예산을 요청하는 안내가 제공됩니다.
이 글의 개인 구독 변경 판단과 구분해 보세요 (GitHub 공식: 조직 사용자 안내).
질문 한 번이 크레딧 한 개일까요?
GitHub AI Credits는 질문 개수를 세는 표가 아니죠. 보낸 입력, 생성된 출력, 캐시 관련 토큰에 모델별 단가가 적용되고, 비용이 크레딧으로 환산됩니다.
1크레딧은 미화 0.01달러입니다 (GitHub 공식: 모델별 과금 원리).
그래서 “오늘 질문을 적게 했는데 왜 많이 썼지?”라는 상황이 생길 수 있죠. 짧게 입력했다는 사실과 모델이 처리한 내용이 적다는 사실은 다릅니다.
사용자가 보낸 한 줄 뒤에 파일 내용과 대화 기록이 붙고, 에이전트가 여러 번 판단했다면 질문 횟수만으로 비용을 예상하기 어렵습니다.
공식 최적화 가이드도 열린 파일과 첨부 문맥, 긴 대화가 입력에 포함된다고 설명합니다. 문제를 바꿀 때 새 대화를 시작하고, 관련 문맥만 주도록 권하는 이유입니다 (GitHub 공식: 문맥 관리).
Chat과 에이전트까지 전부 무제한이라는 뜻으로 읽으면 안 됩니다. 무료 플랜의 코드 자동완성은 월 2,000회로 표시됩니다 (GitHub 공식 요금표).
소진 안내를 봤다면 무엇이 멈췄는지도 적어 보세요. 채팅에서 막혔는지, 에이전트 실행 중 안내가 나왔는지, 자동완성 자체가 안 되는지에 따라 질문이 달라집니다.
자동완성까지 안 된다는 증상을 크레딧 부족 하나로 단정해 추가 결제를 시작할 이유는 없죠.
예전 글의 premium requests가 보인다면
2026년 6월 1일 사용량 기반 과금 전환 뒤에도 예외가 있죠.
기존 연간 Pro·Pro+ 구독자 중 요청 기반 과금에 남아 있는 계정에는 legacy 문서가 적용됩니다.
연간 결제라는 이유만으로 모두 예외라고 보거나, 모든 계정이 이미 크레딧으로 바뀌었다고 단정하면 틀립니다 (GitHub 공식: 기존 연간 플랜 예외).
화면에 premium requests가 보인다면 먼저 내 계정의 과금 체계를 확인하세요. 크레딧 표의 숫자를 남은 요청 수에 대입하면 계산부터 어긋나죠.
검색으로 찾은 과거 표가 지금 내 화면과 다를 때는 날짜만 비교하지 말고, 그 문서가 어느 구독자를 대상으로 하는지도 함께 봐야 합니다.
카드 결제일에 크레딧도 초기화될까요?
현재 크레딧 방식의 포함량은 매달 1일 00:00 UTC에 초기화됩니다. 한국 시간으로는 매달 1일 오전 9시이죠.
남은 포함량은 다음 달로 이월되지 않으며, 구독 결제일에 맞춰 초기화되는 구조도 아닙니다 (GitHub 공식: 포함량 초기화).
월 중간에 구독을 시작했다고 해서 그 가입일을 잔여량 회복일로 잡지 마세요. 카드 명세서를 보는 날과 다음 작업을 재개할 수 있는 날을 같은 달력 표시로 관리하면 혼동하기 쉽습니다.
| 확인할 날짜 | 의미 | 독자가 할 일 |
|---|---|---|
| 매달 1일 오전 9시 KST | 현재 크레딧 방식의 월간 포함량 초기화 | 대기 가능한 작업을 이 날짜와 비교. |
| 계정에 표시된 결제일 | 구독·청구 확인에 쓰는 날짜 | 결제 설정과 명세서에서 확인. |
| 작업 마감일 | 본인이 정한 일정 | 초기화까지 기다릴 수 있는지 결정. |
GitHub의 사용량 기반 항목은 달력 월 기준으로 집계하고 결제일에 청구하는 구조를 설명합니다. 달력 월의 사용량 집계와 계정의 청구 일정을 분리해서 읽으세요 (GitHub 공식: 결제 주기).
가정해 보겠습니다. 10월 말에 개인 프로젝트의 문서 정리만 남아 있고 며칠 미뤄도 된다면, 포함량이 돌아오는 날짜를 보고 기다릴지 판단할 수 있죠.
반대로 오늘 수정본을 제출해야 한다면 추가 사용과 플랜 변경을 비교할 이유가 생깁니다. 어느 쪽이든 “다 썼으니 상위 플랜”이라는 한 단계로 끝낼 문제는 아니죠.
한 달 사용량을 평가할 때도 같은 기준을 쓰는 편이 낫습니다. 결제일부터 오늘까지를 임의로 묶은 기록과 달력 월의 포함량을 비교하면, 과하게 쓴 달인지 아닌지 판단하기 어렵습니다.
먼저 같은 기간끼리 놓고 본 뒤 이번 달 작업이 평소와 달랐는지 생각해 보세요.
추가 과금 설정에서 핵심은 알림보다 '중지'입니다
예산이라는 이름만 보고 설정을 끝내면 위험한 오해가 남습니다.
알림을 받는 설정과, 한도 도달 시 사용을 막는 설정은 역할이 다릅니다. 월간 지출을 통제하려는 사람이라면 예산 금액을 적었는지만 확인하고 화면을 닫지 마세요.
개인 결제 설정의 Budgets and alerts → New budget에서 예산을 만듭니다.
AI 기능 전반을 묶으려면 Bundled AI credits budget을 보고, 적용 범위와 금액을 정합니다.
화면에서 제공되는 경우 Stop usage when budget limit is reached를 선택해야 한도에서 사용이 중지됩니다.
이 옵션을 끄면 초과 알림만 받고 사용은 이어질 수 있습니다 (GitHub 공식: 예산 생성과 사용 중지).
user-level 예산은 항상 사용 중지를 적용하므로 해당 옵션 자체가 제공되지 않는다는 예외도 있죠. 체크박스가 보이지 않는다는 사실만으로 “이 계정은 중지할 수 없다”고 결론 내리지 마세요.
어떤 유형의 예산을 보고 있는지부터 확인해야 합니다 (GitHub 공식: 예산 유형 예외).
알림의 분모도 다릅니다. 예산 알림은 설정한 예산의 75%·90%·100%, 포함 사용량 알림은 플랜 포함량의 90%·100%를 기준으로 합니다.
“90% 메일을 받았다”는 말만으로 어느 한도인지 알 수 없으니, 알림 제목과 설정 항목을 함께 보세요 (GitHub 공식: 두 종류의 알림).
설정을 저장한 뒤에는 새 예산의 범위와 중지 여부를 다시 읽어 보세요. 같은 AI 작업을 관리하려고 만든 예산인지, 다른 제품의 예산을 보고 있는지 확인하는 단계이죠.
금액이 작아도 적용 범위가 애매하면 지출 계획이 어긋날 수 있죠.
이 글에서 예산을 권하는 목적은 원하는 지출 정책을 명시하는 것이죠. 어떤 계정에서나 정확히 같은 금액으로 청구를 보장한다는 뜻으로 받아들이지는 마세요.
개인 계정의 설정, 조직 정책, 실제 표시되는 적용 범위를 확인해야 합니다. 상한을 정하려 했다면 “알림이 온다”는 설명으로 점검을 끝내지 않는 것이 요점이죠.
추가 크레딧 구매 메뉴가 예상과 다를 때는 가입 경로도 확인하세요.
GitHub Mobile의 iOS·Android에서 현재 구독 중이거나 과거에 구독한 적이 있으면 추가 AI 크레딧 구매를 이용할 수 없다는 제한이 있죠.
다른 계정을 만들거나 결제 경로를 바꾸기 전에 공식 제한과 자신의 이력을 대조하는 편이 먼저입니다 (GitHub 공식: 모바일 구독 이력 제한).
Pro+로 올리면 이번 달 사용량은 어떻게 되나요?
2026년 10월 15일 공식 요금표의 개인 유료 플랜은 아래와 같습니다. 금액은 미화 월 구독 표시이며, 실제 결제 화면의 청구 조건을 별도로 확인해야 합니다.
표는 기능 순위가 아니라 포함량을 비교하기 위한 자료이죠.
| 개인 플랜 | 월 표시 가격 | 기본 크레딧 | Flex | 월 합계 |
|---|---|---|---|---|
| Copilot Pro | 10달러 | 1,000 | 500 | 1,500 크레딧. |
| Copilot Pro+ | 39달러 | 3,900 | 3,100 | 7,000 크레딧. |
| Copilot Max | 100달러 | 10,000 | 10,000 | 20,000 크레딧. |
표의 가격과 포함량은 GitHub 공식 요금표 기준이죠.
Flex는 영구 고정 혜택이 아닌 변동 가능한 포함량이죠. 지금 표의 합계만으로 장기간의 사용량을 보장받는다고 생각하지 마세요 (GitHub 공식: 기본·Flex 구분).
플랜을 올릴 때도 새 포함량 전체가 별도 보너스로 더해지는 것은 아니죠. 업그레이드는 기존 플랜과의 가격 차액을 청구하고, 앞서 쓴 양이 새 플랜의 더 큰 포함량 안에 반영됩니다.
“이번 달 Pro를 다 쓰고 Pro+의 전량을 새로 받는다”는 계산은 피하세요 (GitHub 공식: 업그레이드 처리).
저라면 플랜 이름보다 이번 달 남은 작업이 일회성인지를 먼저 적겠습니다. 설치 오류 하나를 마저 고치는 달과 여러 저장소의 에이전트 작업을 계속하는 달은 같은 구매 판단을 할 필요가 없죠.
이 문장은 사용 경험담이 아니라 판단 순서에 대한 제안이죠.
가령 이번 달에만 큰 마이그레이션을 진행했고 다음 달에는 자동완성 중심으로 돌아갈 계획이라면, 추가 사용을 제한적으로 허용하는 안과 월 구독을 올리는 안을 따로 비교해 볼 수 있죠.
매달 비슷한 작업 때문에 포함량이 모자랐다면 상위 플랜의 포함량을 검토할 근거가 더 생깁니다.
이미 확인한 월간 내역, 남은 일정, 이번 달 허용할 추가 금액을 가지고 판단하는 편이 덜 추측적이죠.
추가 사용을 선택하려면 예산 설정이 필요하며, 추가 사용 자체에 제한이 걸릴 수도 있죠. 지출을 더 허용했다고 언제까지나 중단 없이 실행된다는 보장은 없죠.
기다리기·추가 사용·업그레이드라는 선택지를 놓고 결정하되, 오늘 작업을 끝낼 수 있는지와 장기 구독을 올릴지를 한 번에 묶지 마세요 (GitHub 공식: 소진 후 선택지).
예산을 늘렸는데도 추가 사용 제한이 남아 있나요? 공식 안내에 따르면 이미 소비한 추가 사용료를 먼저 결제해야 계속할 수 있는 경우도 있죠. 한도 안내와 미결제 사용료를 확인하세요.
CLI의 작업별 한도는 월간 예산과 함께 씁니다
월 전체 예산을 정해도 한 번의 에이전트 작업이 너무 길어질 수 있죠.
Copilot CLI를 쓰는 독자라면 세션 한도를 보조 장치로 볼 수 있죠. 웹 채팅 사용자라면 이 명령을 따라 입력하려고 CLI를 설치할 필요는 없죠.
공식 문서의 세션 한도는 현재 public preview이죠.
대화형 CLI에서는 아래 첫 줄을, 명령행에서 한 번 실행하는 경우에는 두 번째 줄과 같은 형태를 사용합니다. 100은 설명용 값이며, 최소 설정값은 30크레딧입니다 (GitHub 공식: 세션 한도 명령).
/limits set max-ai-credits 100
copilot -p "로그인 오류의 원인만 분석하고 수정 전에 멈춰 줘" --max-ai-credits 100명령을 복사하기 전에 둘의 실행 위치를 구분하세요. 첫 줄은 Copilot의 대화형 세션 안에 넣는 명령이죠. 두 번째 줄은 터미널에서 CLI를 호출하는 예시이죠.
자신의 실제 작업 지시로 바꾸되, 예산을 늘리기 위해 습관적으로 큰 숫자를 적는 방식은 피하는 편이 낫겠습니다.
한도에 닿았을 때 처리 중인 응답은 끝나므로 실제 소비량이 설정값을 조금 넘을 수 있죠. 100크레딧을 적었다고 정확히 1달러에서 칼같이 잘리는 장치로 이해하면 안 됩니다.
월간 전체 지출을 관리하는 예산을 대신하지도 않습니다 (GitHub 공식: 응답 완료와 초과 가능성).
한도에 도달했을 때는 숫자를 올리기 전에 현재 결과를 확인해 보세요. 원인 후보가 나왔는지, 수정까지 끝났는지, 아직 탐색만 하는지에 따라 다음 지시가 달라집니다.
“남은 작업 전체를 계속”보다 “찾아낸 원인 중 재현 가능한 한 가지를 확인”처럼 범위를 다시 정하는 편이 검토하기 쉽습니다.
자동 실행을 걸어 놓는 독자라면 한도만 정하고 떠나는 것으로 끝내지 말고, 어떤 결과가 나오면 작업 완료로 볼지도 지시에 담으세요. 비용 제한과 완료 기준은 서로 다른 질문이죠.
하나는 얼마나 쓰도록 둘지, 다른 하나는 무엇을 만들면 멈출지에 답합니다.
다음 달에도 빨리 소진된다면 작업을 잘라 보세요
플랜을 바꾸기 전에 고칠 수 있는 것은 요청의 범위이죠. 공식 가이드는 작업 목표와 관련 문맥, 멈출 조건을 분명히 주고, 불필요한 문맥을 줄이라고 권합니다.
무분별한 모델 전환이 캐시 재사용을 깨뜨릴 수 있다는 점도 짚습니다 (GitHub 공식: 프롬프트와 캐시).
예를 들어 “사이트 전체를 개선해 줘” 대신 “로그인 버튼을 눌렀을 때 중복 요청이 발생하는 원인을 찾아 줘.
우선 해당 컴포넌트와 호출 함수를 보고, 수정 전에 계획을 알려 줘”라고 요청해 볼 수 있죠. 설명용 예시이며, 이 문구가 특정 비율의 크레딧을 절약한다는 실험 결과는 아니죠.
범위를 정하면 결과도 판단하기 쉬워지죠. 전체 개선은 끝났는지 평가하기 어렵지만, 중복 요청의 재현 경로와 수정 계획은 확인할 수 있죠.
불필요한 일을 했을 때 무엇이 범위를 벗어났는지도 말하기 쉬워지고요.
단순한 작업까지 매번 비싼 모델로 고정할 필요가 있는지도 검토해 보세요.
Auto는 모든 Copilot 플랜에서 제공되며 작업에 맞춰 모델을 선택합니다.
유료 플랜은 Chat·CLI·GitHub Copilot 앱·cloud agent에서 Auto 사용 시 모델 비용 10% 할인 대상입니다 (GitHub 공식: Auto와 할인 범위).
이 10%는 월 구독료나 최종 카드 청구액 전체를 할인한다는 뜻이 아니죠.
Auto를 골라도 선택된 모델의 사용 비용은 발생합니다. 할인 문구를 “남은 크레딧 없이 계속 쓸 수 있다”로 읽지 마세요.
무엇을 선택하든 소비 내역을 보며 자신의 작업에 맞는지 확인하는 단계는 남습니다.
여러 설정을 한 번에 바꾸기보다 한 작업의 목표를 정하고 끝난 뒤 결과와 사용량을 함께 적어 보세요.
비싼 모델을 썼더라도 어려운 오류를 해결했는지, 저렴한 모델로 시작했지만 재시도가 길어졌는지를 살펴야 합니다.
값이 작은 모델을 고르는 것과 원하는 결과를 적절한 비용에 얻는 것은 같은 말이 아니죠.
검토용 메모에는 민감한 코드나 토큰을 넣을 필요가 없죠. 작업 종류, 선택 모델, 시작·종료 때 확인한 사용량, 완료 여부 정도면 다음 구매 판단의 재료가 됩니다.
실제 수치를 모으기 전에는 “이 방식이면 몇 배 오래 쓴다”는 기대치를 고정하지 않는 편이 좋습니다.
다른 AI 코딩 도구와 함께 쓴다면
Copilot에 남은 양이 없어서 Claude Code로 옮길 생각이라면, 두 서비스의 구독과 사용량을 한 지갑처럼 보지 마세요.
Claude 쪽 인증과 API 결제를 점검하는 순서는 Claude Code 구독과 API 추가 비용을 구분하는 글에서 이어서 볼 수 있죠.
설치 후 어떤 작업부터 맡길지 막막하다면 Claude Code 작업 지시와 활용 팁도 참고할 수 있죠.
Copilot의 크레딧 문제를 해결하는 설정 안내와 다른 도구를 익히는 과정은 따로 잡으세요. 도구를 옮기는 시간까지 감안해야 오늘 마감을 위한 선택인지 판단할 수 있죠.
코드 리뷰도 별도 확인 대상이죠. GitHub 공식 문서는 Copilot code review가 AI 크레딧과 GitHub Actions 실행 시간을 사용한다고 안내합니다.
Actions 시간이 잡힌다는 이유만으로 모두 유료 초과분이라고 볼 수는 없으므로, 자신의 무료 포함량과 함께 확인하세요 (GitHub 공식: 코드 리뷰 비용 고려 사항).
작업을 재개하기 직전, 이 세 가지가 설명되면 됩니다
처음의 소진 안내로 돌아가 보겠습니다. 지금 어떤 양을 다 썼는지, 추가 사용을 어디까지 허용할지, 포함량이 언제 돌아오는지 설명할 수 있다면 결제 판단에 필요한 바탕은 마련된 것이죠.
추가 지출을 원하지 않는 독자는 예산의 중지 동작을 확인하고 대기 가능한 작업을 나누면 됩니다. 오늘 끝낼 일이 있는 독자는 남은 작업 범위를 적고 추가 사용과 상위 플랜을 비교하면 됩니다.
둘 다 사용량 화면에서 확인한 사실을 출발점으로 삼습니다.
설정 후 Copilot을 다시 열었을 때도 안내가 남아 있다면, 곧바로 예산을 더 올리지 말고 같은 계정과 같은 과금 체계를 보고 있는지부터 재확인하세요.
내 계정에 적용되는 legacy 예외나 모바일 가입 이력 같은 조건을 빠뜨리지 않았는지도 점검할 차례이죠.
GitHub Copilot 크레딧 소진은 업그레이드를 검토할 계기지만, 업그레이드가 항상 첫 조치는 아니죠. AI usage 확인, 예산 중지 설정 확인, 한국 시간 월초 초기화일 확인.
소진 원인을 파악한 뒤 오늘 필요한 작업에 비용을 더 허용할지 결정해 보세요.
2026-10-15 확인 · 개인용 Copilot 크레딧 점검 기준 v1. 요금·포함량·preview 기능은 변경될 수 있으므로 결제 직전 연결된 공식 문서와 계정 표시를 확인하세요.
본문에는 사용 경험이나 절감률 실측을 주장하지 않았습니다.
'IT,테크' 카테고리의 다른 글
| Ollama GPU 사용 확인: 100% GPU가 사용률 100%는 아닌 이유 (0) | 2026.10.18 |
|---|---|
| 내 PC NPU 확인: 작업관리자에 안 보일 때와 Copilot+ 40 TOPS 읽는 법 (0) | 2026.10.18 |
| Claude Code 요금, Pro·Max 구독인데 API 비용이 또 나오는 이유와 결제 전 확인표 (0) | 2026.10.15 |
| 노트북 살 때 램 온보드인지 확인하는 법: 8GB 고정 모델이 2026년에 위험해진 이유 (0) | 2026.09.27 |
| USB 오디오 코드 10, 9월 업데이트 뒤 헤드셋·스피커 소리가 안 난다면: '이 장치를 시작할 수 없습니다'가 오디오 1.0 버그인지 가려내는 법 (0) | 2026.09.27 |