Copilot 통합 정책·과금 변경 대응법: 9월 28일 전에 확인할 설정

검색 의도: Copilot 통합 정책, Copilot billing 변경, Copilot cloud agent 정책, Copilot code review Balanced 설정

GitHub는 9월 말부터 Copilot 정책과 과금 방식을 단계적으로 바꾼다. 9월 1일부터 신규 Copilot Business·Enterprise 카드 결제 가입이 다시 열리고, seat 할당 시 결제 확인이 더 엄격해진다. 10월 1일부터는 기존 카드·PayPal 결제 고객에게도 할당된 seat 기준 upfront charge가 적용된다. 9월 28일 이후에는 Copilot Chat on github.com, GitHub Mobile의 Copilot Chat, Copilot cloud agent가 하나의 통합 Copilot experience와 단일 정책으로 수렴한다. 같은 시점에 Copilot code review의 Default effort도 Lite에서 Balanced로 바뀐다.

이 글은 공지를 해석하는 글이 아니라, 조직 관리자가 지금 무엇을 확인해야 하는지 정리한 운영 가이드다. Copilot을 개인 도구로 쓰면 크게 신경 쓰지 않아도 된다. 하지만 Business나 Enterprise에서 seat, usage, cloud agent, code review를 조직 단위로 켜뒀다면 9월 28일 전에 설정을 확인해야 한다.

바뀌는 영역을 세 가지로 나누기

첫 번째는 billing이다. 신규 seat는 접근 전에 결제가 필요하고, 기존 고객도 다음 billing cycle부터 할당 seat에 대한 upfront charge가 적용된다. 가격 자체가 오른다는 뜻은 아니지만, seat를 느슨하게 할당해둔 조직은 현금 흐름과 사용량 관리가 달라질 수 있다. 특히 퇴사자, 휴직자, 외주 계정, 임시 프로젝트 계정에 seat가 남아 있으면 비용이 먼저 발생한다.

두 번째는 policy consolidation이다. 기존에는 github.com Chat, Mobile Chat, cloud agent 정책을 따로 생각할 수 있었다. 통합 이후에는 하나의 정책이 적용되고, unified experience가 기본 활성화된다. opt out하면 github.com과 Mobile에서 Copilot 접근을 잃을 수 있다는 점이 중요하다. 즉 “cloud agent만 꺼두고 웹 채팅은 유지” 같은 기대가 정책 변경 후에는 맞지 않을 수 있다.

세 번째는 code review effort default다. Default 값을 그대로 둔 repository와 organization은 9월 28일부터 Balanced가 기본이 된다. Lite를 유지하고 싶다면 Default가 아니라 명시적으로 Lite를 선택해야 한다. Balanced는 더 깊은 리뷰를 기대할 수 있지만, 사용량과 리뷰 노이즈가 늘 수 있다.

seat 정리부터 해야 하는 이유

AI 비용 관리는 모델 단가보다 seat hygiene에서 먼저 새는 경우가 많다. seat가 많으면 포함 사용량도 넓어지지만, 실제 활성 사용자가 적으면 비용 대비 효과가 낮다. 9월 변경에서는 할당 seat가 upfront charge와 더 직접적으로 연결되므로, 관리자는 “누가 써야 하는가”를 다시 확인해야 한다.

권장 순서는 간단하다. 최근 30일 Copilot active user를 뽑고, seat 보유자와 교차한다. 사용량이 0에 가까운 계정은 팀 리드에게 확인한다. 외주·인턴·테스트 계정은 만료일을 붙인다. seat 부여 기준도 문서화한다. 예를 들어 “프로덕션 코드 작성자, 리뷰어, 데이터 엔지니어, DevOps 담당자는 기본 부여. 읽기 전용 PM 계정은 요청 기반 부여”처럼 기준이 있어야 한다.

통합 Copilot experience 설정 확인

GitHub 공지에 따르면 9월 28일 이후 통합 Copilot experience는 기본 활성화된다. cloud agent는 Sandbox를 활용해 더 빠른 cloud experience를 제공하고, github.com Copilot은 agent sessions experience로 이관된다. 이때 chat data retention이 28일이 아니라 account lifetime에 맞춰진다는 변화도 있다.

관리자는 이 지점을 보안팀과 같이 봐야 한다. 조직 정책상 웹에서의 AI 사용을 제한해왔거나, cloud agent가 PR을 생성하는 흐름을 아직 승인하지 않았거나, 장기 retention이 내부 기준과 충돌한다면 opt out 또는 별도 가이드가 필요하다. 반대로 웹과 모바일에서 Copilot을 적극 활용하려면 opt out하지 말고, 허용되는 repo, 금지되는 데이터, 리뷰 기준을 명확히 적어야 한다.

Code review Balanced 전환 테스트

Copilot code review의 effort level은 리뷰 비용과 품질에 직접 영향을 준다. Balanced가 기본이 되면 Lite보다 더 많은 지적을 할 수 있고, 복잡한 변경에서는 도움이 된다. 하지만 작은 문서 수정, 단순 dependency bump, generated file 변경에서는 과한 리뷰가 될 수 있다. Default에 맡기기보다 repository 성격별로 기본값을 정하는 것이 낫다.

예를 들어 결제, 인증, 권한, 데이터 삭제가 들어가는 레포는 Balanced 또는 더 높은 effort를 기본으로 둔다. 마케팅 페이지나 문서 레포는 Lite를 유지한다. 모노레포라면 repository-level default만으로 부족할 수 있으니 CODEOWNERS, PR label, CI workflow와 함께 리뷰 요청 정책을 나누는 방법을 검토한다.

실제 점검 절차

1단계는 inventory다. Copilot seat 목록, active usage, cloud agent 사용 여부, github.com Chat 사용 여부, Mobile 사용 여부, code review 사용 repo를 한 파일에 모은다. 2단계는 policy review다. 통합 experience를 켤지, 끌지, 누구에게 허용할지 결정한다. 3단계는 billing simulation이다. 현재 seat가 10월 1일 기준으로 얼마의 upfront charge를 만들지 계산한다. 4단계는 repository review setting이다. Default로 남아 있는 code review effort를 찾아 Lite 유지 또는 Balanced 수용을 명시한다.

마지막은 공지다. 개발자에게는 장황한 정책 설명보다 “9월 28일부터 바뀌는 사용 방식”을 짧게 알려야 한다. 예시는 다음과 같다. “웹 Copilot과 cloud agent가 같은 정책으로 묶입니다. 회사 코드를 외부 웹 세션에서 다룰 때는 approved repository만 사용하세요. code review는 일부 레포에서 Balanced로 바뀌며, 과한 리뷰가 반복되면 label로 예외 요청하세요.”

실행 체크리스트

• 30일 기준 Copilot active user와 seat 할당자를 비교한다.
• 미사용 seat, 임시 계정, 외주 계정의 유지 필요성을 확인한다.
• 10월 1일 upfront charge 예상액을 계산한다.
• 9월 28일 전 통합 Copilot experience 정책을 검토한다.
• account lifetime retention이 내부 보안 기준과 충돌하는지 확인한다.
• cloud agent가 접근 가능한 repository와 작업 범위를 문서화한다.
• Copilot code review Default effort를 repository별로 명시값으로 바꾼다.
• Lite 유지 레포와 Balanced 전환 레포를 구분한다.
• 변경 내용을 개발자에게 1페이지 가이드로 배포한다.

Copilot 통합 정책·과금 변경은 “설정 화면 몇 개 확인”으로 끝낼 일이 아니다. seat, retention, agent 권한, code review effort가 동시에 바뀐다. 9월 28일 전에 한 번 정리해두면 비용 폭탄보다 더 골치 아픈 “팀마다 다르게 쓰는 AI 도구” 문제를 줄일 수 있다.