요약

  • 관련 정책을 켜면 Copilot 라이선스가 없는 조직 구성원도 코드 검토를 이용할 수 있다. 이들의 AI credits 사용은 조직이나 기업에 추가 유료 사용으로 직접 청구되며 개인 예산에 배정되지 않는다.
  • 저장소나 조직 규칙이 새 푸시와 초안의 검토를 요구하면 개인 설정으로 끌 수 없다. 검토 범위를 정한 사람이 이후 작업에서 발생할 구매도 정하는 셈이다.

구매팀이 Copilot 좌석을 지급하지 않은 직원에게도 Copilot 청구서는 생길 수 있다. 직원에게 날아오는 청구서는 아니다. 회사가 관련 기능을 열어 두었다면, 그 직원의 코드 검토에 쓰인 AI credits는 조직이나 기업이 낸다. 구독 좌석을 세는 일과 서비스 소비를 세는 일이 여기서 갈라진다.

간헐적으로 코드를 수정하는 구성원에게도 검토를 제공할 수 있다는 것은 분명한 장점이다. 몇 번의 작업을 위해 사람마다 구독을 배정하는 절차를 줄일 수 있다. 다만 검토가 자동 규칙에 들어가는 순간, 구매는 누군가 버튼을 누를 때만 발생하는 행위가 아니다. 먼저 정한 규칙이 나중에 올라오는 변경을 보며 계속 주문한다.

개인 예산 바깥의 정상적인 결제 경로

GitHub 제품 문서는 라이선스가 없는 구성원에게 기능을 열기 위한 조건을 두 단계로 나눈다. AI credits 유료 사용을 허용하고, 라이선스 없는 구성원의 코드 검토를 허용해야 한다. 두 번째 정책은 기본적으로 꺼져 있다. 켜진 조직에서는 해당 구성원의 자동·수동 검토가 직접 조직 과금으로 이어진다. 이 기능에 쓸 개인 월간 제공량은 없고, 사용량은 개인 예산에 귀속되지 않는다.

유료 라이선스를 가진 구성원은 기본적으로 자신의 이용 권익을 쓴다. 조직 또는 기업 소유자는 이를 조직 결제로 바꿀 수 있다. 유료 사용 허용은 필요하지만 예산 설정은 선택 사항이다. 결제 주체를 바꾸는 설정은 접근 권한을 따로 부여하지 않는다.

따라서 관리자에게는 세 가지 일이 남는다. 누가 쓸 수 있는지, 어디에 사용료를 붙일지, 어느 한도에서 멈출지를 정하는 일이다. 개인별 표가 얌전하다고 전체 구매까지 얌전하다고 볼 수 없는 이유다. 모두의 지갑을 검사해도 회사 명의 외상 장부는 발견되지 않는다.

요청 방식이 회계상의 이름을 바꾼다

기본 귀속 규칙에서 자동 검토의 AI 사용은 풀 리퀘스트 작성자에게 붙는다. 다른 사용자가 수동으로 요청하면 그 요청자에게 붙는다. Copilot cloud agent가 작성한 변경은 연결된 인간 공동 작성자를 먼저 찾고, 그에게 과금할 수 없으면 조직으로 넘어간다. 다른 봇이 작성했거나 봇이 검토를 요청한 경우에는 조직에 직접 청구한다.

같은 코드 변경이라도 추가 검토를 누가 요청했는지에 따라 사용량이 다른 칸에 들어갈 수 있다. 개발자 이름만 보고 소비의 원인을 설명하기 어려워진다. 팀이 자동화를 늘리면 사람의 요청이 줄어드는 동시에 조직 직접 과금이 늘어날 수도 있다. 어느 변화가 있었는지는 실제 요청과 귀속을 연결해서 살펴야 한다.

검토를 막는 한도 역시 선택된 결제 주체를 따른다. 개인에게 과금하면 개인 예산이, 조직에 과금하면 적용되는 조직·비용 센터·기업 한도가 검토의 지속 여부에 영향을 준다. 결제 주체를 옮기는 일은 단순한 보고서 재분류보다 크다. 어떤 자원이 소진됐을 때 서비스가 멈추는지도 바뀐다.

회사가 요구한 점검을 회사가 부담하면 기여가 많은 직원의 개인 잔액에 공통 업무를 맡기는 문제를 줄일 수 있다. 그 편의를 얻은 뒤에는 공통 서비스의 구매 책임을 정해야 한다. 더 많이 점검하자는 사람과 남은 예산을 설명하는 사람이 서로의 판단을 볼 수 있어야 한다.

‘매번’이라는 말이 만드는 수요

자동 검토 설정 안내에는 새 푸시마다 검토하는 옵션과 초안부터 검토하는 옵션이 있다. 개인 설정과 저장소·조직 규칙은 각각 평가된다. 같은 사건에 여러 설정이 적용돼도 검토는 한 번만 게시된다. 그러나 개인은 규칙이 켠 푸시·초안 검토를 자신의 설정에서 취소할 수 없다.

비용이 반복되는 지점은 중복 설정 자체보다 작업이 진행되면서 새로 생기는 검토 기회다. 수정하고, 다시 보내고, 또 수정하는 과정에 매번 기계가 들어온다. 풀 리퀘스트 한 건을 고정된 가격의 한 번짜리 구매처럼 세면 그 안의 여러 차례 실행이 사라진다.

초기에 오류를 발견하면 동료가 읽기 전에 고칠 수 있다. 반대로 작은 조정을 보낼 때마다 같은 부분을 재확인하는 데 돈을 쓸 수도 있다. 회사가 구매할 것은 유용한 발견인지, 검토가 있었다는 안도감인지 판단해야 한다. 자주 확인하는 습관은 성실해 보이지만, 성실한 표정이 한계비용을 지불하지는 않는다.

검토의 깊이에도 별도 통제가 있다. 조직의 기본 검토 강도는 저장소에서 조정할 수 있지만, 조직이 정한 최대 강도는 넘을 수 없다. 기본값은 관행을 안내하고 최대값은 선택 가능한 구매 범위를 제한한다. 권장 메뉴를 적어 둔 뒤 지출 한도를 정했다고 생각해서는 계산이 맞지 않는다.

AI가 읽기 전에 계산 자원이 움직인다

GitHub는 2026년 4월 27일 공지에서 6월 1일부터 코드 검토에 AI credits와 GitHub Actions 실행 시간이 함께 소비된다고 밝혔다. 모델과의 상호작용에 드는 사용량, 맥락 수집과 도구 호출을 실행하는 자원을 나눠 계산한다. 비공개 저장소의 표준 호스팅 실행 자원에서는 포함된 계산 사용량과 초과분을 구분해야 한다.

러너 구성 문서는 GitHub 호스팅 러너를 비활성화하면 해당 에이전트 기능이 사라지고 더 제한된 검토로 전환된다고 설명한다. 직접 운영하는 러너를 쓸 수도 있다. 공식 지원 방식은 ARC가 관리하는 Ubuntu x64 러너이며, 네트워크 통제는 조직이 마련해야 한다.

직접 운영하면 Actions 실행 분량을 소비하지 않는다. 대신 장비와 네트워크, 유지 작업이 회사의 몫이 된다. 플랫폼 청구서에서 지운 항목이 내부 운영 업무로 옮겨 간다. 또 댓글이 계속 달린다고 해서 같은 맥락을 조사한 검토가 계속 제공되는 것도 아니다. 구매 비교에는 비용과 함께 실제 기능이 들어가야 한다.

공개 문서에는 특정 고객의 실행 이력, 대조된 청구액, 유용한 발견 수가 없으며 이 셋을 맞춰야 추가 검토의 가치를 계산할 수 있다. 그 자료를 기다리기 전에 할 일도 있다. 자동 검토를 요구한 팀에게 그 규칙이 일으킨 전체 소비를 보여 주는 일이다. 검토를 주문하는 권한은 이미 존재한다. 이제 그 주문서를 책임질 사람을 찾으면 된다.