서론: 지난 기사의 정답을 확인해 보겠습니다

이전에 과금 방식 변경이 발표된 직후에 이 기사를 작성했습니다.

이 기사에서는 「AI credits」, 「풀링 (Pooling)」, 「4단계 예산 제한」 등 발표 시점의 사양을 정리했습니다.

그로부터 2026년 6월 1일에 종량제 (Pay-as-you-go)가 정식으로 시행되어 실운용이 시작됨에 따라, 발표 당시에는 보이지 않았던 중요한 사실들이 여러 가지 밝혀지고 있습니다.

결론부터 말씀드리면, 지난 기사의 조언 중 일부는 시행 후의 사양에 비추어 볼 때 수정이 필요했습니다. 본 기사는 그 정답을 확인하고, 시행 후의 문서 및 커뮤니티의 반응을 바탕으로 한 「정말로 효과적인 비용 관리」 실무를 정리한 속편입니다.

지난 기사를 읽지 않은 분들도 이 기사만으로 완결되도록 작성했습니다.

시행 후 판명된, 놓치기 쉬운 3가지 사실

발표 당시의 이해와 시행 후의 실태에는 차이가 있습니다.

특히 운용 설계를 좌우하는 3가지 점을 먼저 짚고 넘어가겠습니다.

사실 1: 고갈 후의 「경량 모델로의 자동 폴백 (Fallback)」은 폐지되었다

이것이 가장 큰 변경점입니다. 기존의 프리미엄 리퀘스트 (Premium Request) 방식에는 할당량을 다 써도 경량한 베이스 모델 (Base Model)로 자동 전환되어 작업을 계속할 수 있는 안전망이 있었습니다.

새로운 종량제에서는 이 안전망이 폐지되었습니다. credits나 예산을 다 쓰는 순간, 대상 기능에 대한 액세스는 중단되며, 저비용 모델로의 자동 폴백 (Fallback)은 이루어지지 않습니다.

재개할 수 있는 것은 다음 청구 사이클에서 월간분이 리프레시되거나, 관리자가 예산을 올렸을 때뿐입니다.

지난 기사에서는 「채팅이 멈추더라도 코드 보완 (Code Completion)은 남으므로 극단적으로 보수적인 예산 설정은 불필요하다」라고 적었습니다.

코드 보완이 무제한이라는 점은 지금도 맞지만, 채팅이나 에이전트 (Agent)가 완전히 정지하는 설계로 바뀌었으므로, 정지가 업무에 미치는 영향은 당시의 상정보다 크다고 다시 파악해야 합니다.

사실 2: Copilot code review는 GitHub Actions 비용도 소비한다

Copilot의 코드 리뷰는 에이전트형 아키텍처 (Agent-based architecture)로 이행하여, GitHub Actions 상에서 동작하게 되었습니다.

그 결과, 6월 1일 이후에 Copilot으로 풀 리퀘스트 (Pull Request)를 리뷰하면, AI credits에 더해 포함된 Actions 분량이 일반적인 Actions 워크플로우 (Workflow)와 동일한 종량 단가로 소비됩니다.

월간 청구에는 토큰 (Token) 소비 비용과 Actions 분량 소비가 모두 포함됩니다.

즉, 「AI credits의 예산만 보고 있으면 안심」할 수 없습니다.

코드 리뷰를 많이 사용하는 팀은 Actions 분량의 소비도 함께 모니터링 대상에 포함해야 합니다.

사실 3: 연간 플랜은 폐지되었고, PRU 방식은 순차적으로 종료된다

연간 플랜은 폐지되었습니다. 현재 연간 플랜을 계약 중인 경우에는 계약 만료 시까지 기존의 프리미엄 리퀘스트 방식을 계속합니다. 다만 연간 계약자를 대상으로 모델 단가 배율이 6월 1일에 인상되었다는 점에 주의하십시오. 만료 시 종량제로 이행되는 흐름입니다.

AI credits의 기본 사양 (시행 후 확정판)

여기서 현재의 확정 사양을 정리합니다.

credits와 토큰의 관계

새로운 과금 단위는 AI credits이며, 모델이 처리하는 토큰 (Token) 양에 따라 소비됩니다.

• 1 AI credits = $0.01 USD
• 소비 대상 토큰: 입력 토큰, 출력 토큰, 캐시 토큰의 3종류
• 단가는 모델마다 다르며, 선택한 모델의 API 레이트 (Rate)로 환산됨

경량 모델에서의 짧은 채팅이라면 1 credits의 몇 분의 일로 해결되는 반면, 고성능 모델로 여러 파일에 걸친 장시간의 에이전트 세션 (Agent Session)을 돌리면 더 많은 토큰을 소비하기 때문에 비용이 올라갑니다.

소비 대상과 대상 외

개발자가 가장 빈번하게 사용하는 인라인 보완 (Inline Completion)이 무제한으로 남는 점은 변하지 않았습니다. 자동 보완이 주요 사용법이라면 청구 금액은 거의 변하지 않는다고 생각해도 좋습니다.

라이선스에 포함되는 credits 양

도입 초기 3개월 동안은 이행 지원을 위해 부여량이 증량되어 있습니다. 9월 1일 이후에는 표준량으로 돌아가기 때문에, 프로모션 기간 중의 소비 실측치를 그대로 향후 예측에 사용할 경우 과소평가될 수 있다는 점에 주의가 필요합니다.

풀링 (Pooling)의 동작

credits는 개인에게 귀속되지 않고, 과금 엔티티 (Billing Entity) 단위로 풀링됩니다. Copilot Business 사용자가 100명이라면, 개별 버킷이 아니라 조직 전체에서 190,000 credits의 공유 풀 (Shared Pool)을 가집니다.

• 라이선스를 월 중간에 추가한 경우: 풀이 즉시 증가함
• 라이선스를 월 중간에 삭제한 경우: 풀이 즉시 축소되지 않으며, 다음 청구 주기 시작 시 반영됨

4단계 예산 제어를 올바르게 이해하기

이 부분이 지난 기사보다 해상도가 가장 높아진 대목입니다. 예산 제어에는 4가지 종류가 있으며, 각각 "언제 적용되는가"와 "하드 스톱 (Hard Stop)인가"가 다릅니다. 이는 대안이 아니라 조합해서 사용하는 것입니다.

여기서 운영상의 핵심 포인트(急所) 4가지를 꼽겠습니다.

핵심 1: 사용자 예산만이 '풀 단계'에서도 작동한다

사용자 예산은 공유 풀에서 차감되는 단계와, 풀 고갈 후의 종량제 단계 모두에서 항상 유효한 유일한 제어 수단입니다.

게다가 사용자 예산은 항상 하드 스톱 (Hard Stop)이며, 상한을 초과하여 계속 사용할 수 있는 옵션은 없습니다. $0로 설정하면 즉시 해당 사용자를 차단할 수 있습니다.

반면 코스트 센터 (Cost Center) 예산과 엔터프라이즈 (Enterprise) 예산은 공유 풀이 고갈된 이후의 종량제 과금에만 적용됩니다. 풀이 존재하는 동안에는 그대로 통과됩니다.

핵심 2: '상한 도달 시 중지'는 기본적으로 OFF

엔터프라이즈 예산과 코스트 센터 예산에는 "Stop usage when budget limit is reached"라는 설정이 있으며, 이것이 기본값으로 OFF 되어 있습니다.

OFF 상태로 두면, 상한에 도달해도 과금이 중단되지 않고 상한을 초과하여 과금이 계속 쌓이게 됩니다.

지난 기사에서 언급한 "$0로 중지"만으로는 불충분하며, 종량제 단계의 제동을 걸기 위해서는 지출 상한을 생성할 때 반드시 이 설정을 ON으로 해야 합니다. 참고로 사용자 예산은 항상 하드 스톱이므로 이 설정이 따로 없습니다.

핵심 3: 엔터프라이즈 예산은 '총액의 상한'이 아니다

이 부분은 오해가 생기기 쉬운 지점입니다. 엔터프라이즈 예산은 풀 고갈 후의 종량제 과금만을 억제하는 것이지, 월 총 지불액의 상한이 아닙니다.

총 지불액의 최댓값은 라이선스 요금에 엔터프라이즈 예산을 더한 값이 됩니다.

예를 들어 Copilot Business를 400 라이선스 계약했다면 월 라이선스료는 $7,600이며, 여기에 엔터프라이즈 예산 $5,000를 설정하면 최대 청구액은 $5,000가 아니라 $12,600가 됩니다.

핵심 4: lowest remaining headroom wins

사용자 예산과 지출 상한은 독립된 별개의 제어입니다. 두 가지가 맞물리지 않으면 사용자가 예상치 못하게 차단될 수 있습니다.

시스템은 "남은 용량(Headroom)이 가장 적은 예산이 먼저 차단한다"라는 규칙으로 동작합니다. 예를 들어 사용자 개별 예산이 $5 남아 있더라도, 엔터프라이즈 예산의 잔액이 $1라면 개인 예산이 고갈되지 않았더라도 엔터프라이즈 예산 측에서 차단됩니다.

사용자 예산을 올릴 때는 그만큼의 초과분이 지출 상한에 의해 커버될 수 있는지 반드시 확인하십시오.

비용 관리: 시행 후의 실무 단계

이제부터가 본론입니다. GitHub 공식 기능과 운영 규칙을 조합하여, 시행 후에 유효한 절차를 우선순위 순으로 정리합니다.

단계 1: 현황 파악

가장 먼저 해야 할 일은 대시보드를 통한 실측입니다.

• Organization / Enterprise 설정에서 Billing, Copilot으로 이동하여 Usage 리포트를 확인한다.
• 6월의 첫 1주일이 지나면, 모델별 토큰 소비를 보고 월간 총액을 예측하여 모델 선택이나 지출 상한을 조정한다.
• 헤비 유저(Heavy user)를 특정한다. Chat, 에이전트(Agent), cloud agent, 대규모 컨텍스트(Large context) 이용이 많은 계층이 후보가 된다.

프로모션 기간 중에는 부여량이 많기 때문에, 소비가 적어 보이더라도 9월 이후에는 표준량으로 돌아간다는 전제하에 견적을 산출하십시오.

단계 2: 예산 제어 설정

앞서 언급한 급소를 바탕으로 다음 순서로 설정합니다.

• 전체 기본 사용자 예산을 설정하여 공유 풀(Shared pool)에 대한 공평한 액세스를 보장한다.
• 헤비 유저에게는 개별 사용자 예산으로 상한을 높이고, 억제하고 싶은 사용자에게는 낮은 개별 예산을 설정한다.
• 종량제(Pay-as-you-go)를 허용하는 경우, 엔터프라이즈 예산 또는 코스트 센터(Cost center) 예산을 설정하고, 반드시 "Stop usage when budget limit is reached"를 ON으로 한다.
• 완전히 차단하고 싶은 사용자에게는 사용자 예산을 $0로 설정한다.
• 사용자 예산과 지출 상한의 잔여 용량이 서로 맞물려 있는지 확인한다.

참고로 종량제 발생 자체를 원하지 않는 경우, "AI credit paid usage" 정책을 비활성화해 두면 풀이 고갈되는 시점에 일괄 차단됩니다.

단계 3: 모델 선택의 최적화

시행 후 가장 구체적이고 공식적인 절약책은 모델 선택입니다.

• 유료 플랜에서는 Copilot Chat, Copilot CLI, cloud agent에서 auto model selection을 사용하면 모델 비용이 10% 할인된다.
• auto는 신뢰성과 가용성에 기반하여 자동으로 모델을 배분하므로, 대부분의 프롬프트는 이것으로 충분하다.
• 경량 모델은 빠른 편집이나 정형화된 코드 생성, 단순한 질문에 사용한다.
• 추론 모델(Reasoning model)은 복잡한 리팩터링이나 아키텍처 판단, 다단계 디버깅에 한정한다.
• 커스텀 에이전트(Custom agent)에서 특정 서브 태스크를 비용 효율이 좋은 모델로 배분한다.

"어쨌든 고성능 모델을 상용하지 않는다", "태스크의 복잡도에 모델을 맞춘다"라는 원칙은 예전부터 유효했지만, auto의 10% 할인은 종량제 시대에 새롭게 추가된 명확한 이점입니다.

단계 4: 토큰 소비를 줄이는 워크플로우

크레딧(Credits)은 토큰량으로 결정되기 때문에, 컨텍스트 설계가 비용에 직접적인 영향을 미칩니다.

• 컨텍스트를 최소화한다. 리포지토리 전체를 매번 읽게 하지 않는다.
• 계획과 구현을 분리하고, 에이전트의 작업 범위를 명시적으로 스코프(Scope)한다.
• 왕복 횟수를 줄인다. 모호한 지시로 여러 번 다시 하기보다, 처음에 요구사항을 확정한다.
• MCP나 외부 문서를 사용하는 경우, 취득한 정보가 실제로 모델의 컨텍스트에 들어가는지를 의식한다. 취득 자체가 아니라 컨텍스트 투입이 과금의 경계가 된다.
• 코드 리뷰는 Actions 분량도 소비하므로, 자동 리뷰의 대상 범위를 재검토한다.

단계 5: 이용 정책과 거버넌스

조직으로서 운영 규칙을 정합니다.

• 코드 보완과 다음 편집 제안은 과금 대상이 아니므로 무제한 활용해도 좋다.
• Chat, 에이전트, 코드 리뷰는 가치가 발생하는 장면에 집중한다는 방침을 공유한다.
• 주간·월간 사용량 리포트를 공유하여 소비의 편중을 가시화한다.
• IDE와 플러그인을 최소 요구 버전 이상으로 업데이트한다. 오래된 버전은 모델 가격의 오표시나 사용량의 부정확한 표시, 알림 미전송의 원인이 된다.

참고로 주요 클라이언트의 최소 요구 버전은 VS Code가 1.120, Visual Studio 2022가 17.14.33, JetBrains 플러그인이 1.9.1, Copilot CLI가 1.0.48입니다.

시행 후 커뮤니티의 반응

도입 직후부터 개발자 커뮤니티의 반응은 냉담합니다. 짧은 시간 내에 월간 한도의 대부분을 소비했다는 보고나, 월 사용료가 크게 뛰었다는 목소리가 Reddit, X, GitHub 디스커션에 퍼지고 있습니다.

이 반발의 본질은 단순한 가격 인상이 아니라, 지금까지 정액제로 인해 파악하기 어려웠던 에이전트형 개발의 계산 비용이 종량제라는 형태로 가시화되었다는 데 있습니다. 그렇기에 "Copilot을 쓰지 않는다"가 아니라, 경량 확인 작업과 고비용 실행을 분리하고 예산 제어로 제동을 거는 설계가 현실적인 해답이 됩니다.

대체·하이브리드 전략

완전한 전환은 신중히 검토해야 하지만, 선택지를 확보해 두는 것 자체는 유효합니다.

• 로컬 LLM (Local LLM)을 병용하여 일상적인 경량 태스크를 분담시킨다
• 사용량이 많은 팀부터 순차적으로 타 도구의 PoC (Proof of Concept)를 실시하여 ROI (투자 대비 효율)를 비교한다
• 코드 보완 중심의 사용 방식이라면 애초에 청구 금액이 거의 변하지 않으므로, 이전할 필요성이 낮다

Copilot의 GitHub 네이티브 통합 가치는 여전히 높기 때문에, 보완 중심의 이용과 종량제 기능의 이용을 분리한 뒤 기능별로 최적의 도구를 선택하는 하이브리드 방식이 현실적입니다.

요약: 지난번 내용에서 업데이트해야 할 결론

지난 기사의 "AI 리소스를 조직 전체에서 최적화하는 체계로의 진화"라는 관점 자체는 지금도 유효합니다. 그 위에, 시행 후에 밝혀진 사실로부터 결론을 다음과 같이 업데이트합니다.

• 고갈 후의 자동 폴백 (Fallback) 기능은 폐지되었다. 중단이 업무에 미치는 영향은 발표 당시의 예상보다 크므로, 예산 설정은 "멈춰도 괜찮다"가 아니라 "멈추고 싶지 않은 범위를 파악한다"는 발상으로 진행한다
• 코드 리뷰는 Actions 분량도 소비한다. AI credits뿐만 아니라 Actions 분량도 모니터링 대상으로 삼는다
• 지출 상한은 "Stop usage when budget limit is reached"를 ON으로 설정하지 않으면 제동 장치가 되지 않는다
• 엔터프라이즈 예산은 총액 상한이 아니라, 라이선스 비용에 추가되는 종량제 부분의 상한이다
• auto 모델 선택 시 제공되는 10% 할인은 종량제 시대의 명확한 절약 레버 (Lever)로서 적극적으로 활용한다

우선 대시보드에서의 실측과 사용자 예산·지출 상한의 정합성 확인을 이번 주 내로 마칠 것을 강력히 권장합니다. 상황은 유동적이므로, Billing 대시보드와 커뮤니티 디스커션 (Discussion)을 정기적으로 확인하는 것을 습관화하십시오.

출처:

Discussion