GitHub Enterprise에 Copilot 포함: 무료 사용과 다른 좌석·예산 조건

GitHub가 2026년 10월 28일 기업용 플랫폼에 Copilot 접근을 포함하는 새 모델을 발표했습니다. 핵심은 접근 권한에 포함되는 비용과 AI를 실제로 쓴 비용을 나눠 보는 것입니다. GitHub Enterprise Cloud를 쓴다고 모든 회사가 자동 전환되거나 AI 사용량까지 무료가 되는 것은 아닙니다. 판매 담당자와 계약을 검토하는 개발팀·구매 담당자라면, 기존 플랜을 유지할 때와 새 모델로 옮길 때를 같은 사용 조건으로 비교해 보시면 좋겠습니다.

이 글은 11월 1일 공식 발표와 문서를 재확인한 해설입니다. 실제 기업 계정의 계약, 청구서, 설정을 시험하지 않았습니다. 아래에서 확인 사실은 공식 출처와 연결하고, 비교표와 검토 순서는 독자를 위한 제안으로 구분합니다. 11월 2일의 계정별 제공 상태나 전환 완료를 보장하지는 않습니다.

무엇이 바뀌었고, 지금 누구에게 해당하나요?

10월 28일 공식 발표의 현재 대상은 GitHub 또는 Microsoft 판매 담당자와 협의하는 GitHub Enterprise Cloud 고객입니다. 셀프서비스로 구독을 관리하는 고객에게는 아직 제공되지 않으며 기존 셀프서비스 구독도 영향을 받지 않는다고 안내합니다. 따라서 이번 소식을 읽고 바로 기존 구독을 취소하기보다, 자신의 구매 경로부터 확인하는 편이 안전합니다.

여기서 Enterprise Cloud는 GitHub의 클라우드 기업용 플랫폼을 말합니다. 이름이 비슷한 제품을 쓰고 있다는 이유만으로 대상이라고 판단하지 마세요. 구매 요청서 첫 줄에 현재 제품명과 계약 경로를 적으면, 영업 상담에서 서로 다른 조건을 전제로 대화하는 일을 줄일 수 있습니다. 이는 계정 정보를 공개하라는 뜻이 아니라 회사 내부 검토 자료의 범위를 분명히 하자는 제안입니다.

공식 플랜 안내는 Enterprise Cloud 라이선스가 있는 사용자의 Copilot 좌석 비용과, 그 라이선스가 없는 사용자의 Copilot Standalone을 구분합니다. 전자는 Copilot 좌석 비용이 0달러이고 후자는 월 10달러입니다. 이는 Enterprise Cloud 자체가 무료라는 의미가 아닙니다. 기능·모델 이용 자격도 관리자 정책과 지출 통제를 따릅니다.

먼저 확인할 질문	검토 자료에 적을 내용
어떤 계약인가요?	Cloud 제품명, 판매 담당자 경로 또는 셀프서비스 여부
누가 사용할 예정인가요?	사용자 명단과 Enterprise Cloud 라이선스 보유 여부
무엇을 비교하나요?	현재 유지안과 전환 검토안의 같은 기간·사용자 범위
무엇이 미확정인가요?	계정별 자격, 실제 견적, 효력 발생일과 승인 담당자

포함된다는 말이 왜 총비용 절감을 뜻하지 않나요?

사용량 과금 문서에 따르면 기존 Copilot Business·Enterprise에는 공동으로 사용하는 AI 크레딧이 포함됩니다. 새 Copilot access에는 포함 사용량이 없어 크레딧을 소비하는 기능은 첫 사용부터 별도 과금됩니다. AI 크레딧은 사용량의 청구 단위이며, 비용은 모델과 입력·출력·캐시 토큰의 양에 따라 달라집니다. 질문 횟수가 같다는 이유만으로 같은 비용이라고 볼 수는 없습니다.

검토할 때는 고정비와 사용비를 두 칸으로 나누어 보세요. 좌석 비용이 줄어드는 변화와, 기존 포함량으로 처리하던 사용이 별도 청구로 옮겨지는 변화는 동시에 일어날 수 있습니다. 한쪽만 보면 전환안이 지나치게 유리하거나 불리하게 보입니다. 특히 지금 추가 청구가 적다는 사실은 AI를 적게 썼다는 사실과 같지 않습니다. 포함량 안에서 쓴 부분도 비교 대상에 들어가야 합니다.

아래는 계산 결과가 아닌 비교 설계 제안입니다. 지난달 자료를 기준으로 삼는다면 두 안 모두 같은 달, 같은 사용자 집합, 같은 사용 기록을 사용해 보세요. 한 안에는 현재 인원만 넣고 다른 안에는 채용 예정 인원까지 넣으면 계약 구조의 차이와 인원 증가 효과를 구분하기 어렵습니다. 인원 확대 계획은 기본 비교가 끝난 뒤 별도 시나리오로 붙이는 편이 읽기 쉽습니다.

현재 유지안에는 실제 좌석 비용과 실제 추가 사용료를 적고, 전환 검토안에는 포함량 없이 다시 평가한 사용료와 Standalone 대상자의 비용을 적는 방식입니다. 기존 Enterprise Cloud 계약 비용처럼 두 안에서 유지되는 항목도 표 밖으로 지우지 말고 공통 비용으로 표시해 두세요. 이 글은 실제 사용량을 보지 못했으므로 어느 쪽이 더 저렴하다는 결론이나 절감률을 제시하지 않습니다.

기존 플랜은 유지할 수 있고, 일부 부서만 바꿀 수 있나요?

전환 안내는 기존 Business·Enterprise 유지와 자발적 전환을 명시합니다. 다만 새 접근 모델과 기존 두 플랜의 좌석을 같은 enterprise 안에서 섞을 수는 없습니다. 새 모델 안에서는 Enterprise Cloud 라이선스를 통한 접근과 Standalone을 함께 사용할 수 있습니다. 두 종류의 혼합을 같은 것으로 생각하지 않는 것이 중요합니다.

그래서 구매 회의에서는 “우리 부서만 먼저 바꿔 볼까요?”라는 질문 앞에 계약 경계를 확인해 보세요. 조직 이름과 회사의 청구 단위가 반드시 같다고 전제하면, 작은 시험 전환이라고 생각한 일이 더 넓은 범위의 결정이 될 수 있습니다. 실제로 어떤 경계가 적용되는지는 회사 관리자와 판매 담당자가 확인해야 합니다. 시험을 위해 새 enterprise를 만들거나 현재 계정을 옮기라고 권하는 안내는 아닙니다.

같은 전환 안내는 새 모델에서도 소유자가 좌석을 배정해야 하며 자동으로 접근이 생기지 않는다고 설명합니다. 판매 담당자에게 문의하는 것만으로 청구나 접근이 바뀌지도 않습니다. 따라서 내부 일정표에는 상담 요청, 조건 확인, 승인, 효력 발생, 사용자 확인을 따로 적어 두는 편이 좋습니다. 안내상 전환은 월 첫날 효력이 발생하므로 실제 적용일은 담당자와 확인해야 합니다.

이 과정을 나누는 이유는 승인 절차를 늘리기 위해서가 아닙니다. 구매 담당자는 비용 전환이 끝났다고 이해하고 개발자는 아직 사용할 수 없다고 느낄 수 있기 때문입니다. 사내 공지에는 “신청했습니다”와 “이 계정에 적용됐습니다”를 구분하고, 누가 어떤 화면에서 확인할지 정해 주세요. 이는 이번 변경을 회사 업무에 연결하기 위한 운영 제안이며 실제 전환 성공 사례가 아닙니다.

예산을 입력하면 자동으로 지출이 멈추나요?

공식 예산 문서는 개인별 사용 한도와 조직·비용 센터·enterprise의 지출 한도를 구분합니다. 개인별 한도는 항상 사용을 중단시키지만, 집단 단위 지출 한도는 한도 도달 시 중단 옵션을 켜야 강제됩니다. 그 옵션은 기본적으로 꺼져 있다고 안내합니다. 또한 enterprise 예산은 라이선스 비용 자체를 제한하지 않습니다.

“예산을 설정했습니다”라는 한 문장으로 확인을 끝내지 말고, 알림만 받는 상태인지 실제 차단되는 상태인지 물어보세요. 사용자를 보호하려는 한도와 회사 전체 지출을 관리하는 한도는 목적이 다릅니다. 양쪽의 책임자를 정해 두면 사용 중단을 오류로 오해하거나, 알림을 지출 차단으로 오해하는 일을 줄일 수 있습니다. 여기서는 설정을 바꾸지 않았으며 각 회사의 현재 값을 확인하자는 제안만 합니다.

예산이 남았는데도 특정 사용자가 멈춘다면 개인별 한도와 집단 한도를 함께 확인할 질문이 생깁니다. 반대로 한도가 도달했다는 알림 후에도 계속 쓸 수 있다면 중단 옵션의 상태를 확인할 필요가 있습니다. 어느 경우에도 메시지 하나만 보고 결제 오류라고 단정하거나 한도를 무조건 올리지 않는 편이 좋겠습니다. 문제를 재현하려고 실제 업무를 불필요하게 반복할 이유도 없습니다.

발표는 예산이 없어도 코드 자동 완성과 다음 수정 제안은 유지되지만, 채팅·코드 리뷰·클라우드 에이전트는 사용할 예산이 필요하다고 설명합니다. 따라서 “Copilot이 된다/안 된다”보다 어느 기능이 막혔는지 적어 두는 편이 정확합니다. 좌석이 남아 있는 상태와 유료 사용이 허용되는 상태를 구분하면 관리자에게 전달할 정보도 구체적이 됩니다.

우리 팀은 어떤 자료로 전환을 판단하면 좋을까요?

다음 표는 제품이 제공하는 성과표가 아니라 내부 의사결정용 제안입니다. 현재 월평균 총액만 비교하면 가끔 큰 작업을 하는 사람과 짧게 자주 사용하는 사람의 차이가 가려질 수 있습니다. 비교에 필요한 범위를 정하고, 사람을 평가하기보다 업무 유형과 필요한 이용 범위를 중심으로 검토해 보세요. 비용을 낮추는 목표와 업무가 멈추지 않아야 하는 조건을 함께 적는 것이 핵심입니다.

검토 상황	먼저 확보할 근거
이용자가 많고 실제 사용은 드물어요	좌석별 접근 필요성과 전체 사용량을 분리한 자료
일부 업무에 사용이 몰려요	집중 작업 기간을 포함한 기록과 중단 시 대체 절차
앞으로 사용자를 늘릴 예정이에요	현재 인원 비교와 증원 시나리오를 나눈 추정
여러 부서가 함께 써요	같은 청구 경계인지와 비용 검토 책임자

가령 같은 팀 안에서도 자동 완성만 필요한 업무와 긴 대화를 통해 변경안을 만드는 업무가 있을 수 있습니다. 이는 가상의 비교 상황입니다. 모든 사람의 사용을 한 사람의 대표 사례로 대체하지 말고, 대표 업무를 몇 가지로 나누어 판단해 보세요. 이용 빈도가 낮다고 무조건 새 모델이 유리한 것도 아니고, 자주 쓴다고 기존 플랜이 항상 유리한 것도 아닙니다. 실제 계약 조건과 사용 구성이 결론을 바꿉니다.

공식 모델·가격 안내에서는 모델과 토큰 종류에 따라 사용료가 달라지는 구조를 확인할 수 있습니다. 코드 리뷰에는 AI 크레딧 외 GitHub Actions 실행 시간도 관련될 수 있다고 설명합니다. 따라서 AI 사용료 표 하나를 회사 전체 개발 도구 비용으로 취급하지 마세요. 단가를 확인한 날짜와 추정에 넣은 항목을 같이 기록하면 나중에 차이를 설명하기 쉽습니다.

실제 상담을 요청한다면 긴 제품 질문보다 정리된 비교표 한 장을 준비해 보세요. 현재 계약 경로, 라이선스 있는 사람과 없는 사람의 범위, 비교 기간, 예상 사용 변화, 꼭 유지해야 하는 기능을 적으면 됩니다. 그런 다음 제공 자격, 계정별 가격, 계약 경계, 적용일을 확인받으세요. 수치를 넣을 자료가 없는 칸은 임의로 채우지 말고 미확인으로 남겨야 다음 확인 대상이 드러납니다.

구매 전에 자주 생기는 질문을 정리해 볼까요?

지금 셀프서비스를 쓰면 당장 신청할 수 있나요? 11월 1일 확인한 발표에서는 아직 제공되지 않는다고 안내합니다. 향후 단계적 제공을 예고했지만 계정별 날짜를 이 글에서 확정할 수는 없습니다. 기다리는 동안에도 현재 플랜의 실제 비용 자료를 정리하는 일은 가능합니다.

전환을 서두르지 않으면 현재 플랜을 못 쓰나요? 공식 안내는 기존 플랜 유지와 자발적 전환을 설명합니다. 발표가 나왔다는 이유로 당장 바꿀 필요는 없습니다. 계약 갱신이 가까우면 그 시점과 비교하고, 근거가 부족하면 미확정 조건을 먼저 확인하는 순서가 합리적입니다.

계산표가 저렴하면 바로 바꿔도 될까요? 계산 결과 외에 실제 자격·정책·좌석 배정·효력 발생 확인이 남습니다. 반대로 기능 확인만 끝났다고 비용 검토가 완료되는 것도 아닙니다. 최종 결재 자료에 금액과 이용 가능 조건을 나란히 적어 두세요.

이번 발표를 활용하는 좋은 출발점은 무료라는 단어에 결론을 맡기지 않는 것입니다. 현재 유지안과 전환 검토안을 같은 조건으로 비교하고, 확정된 항목과 상담이 필요한 항목을 구분해 보세요. 이 글의 근거는 공개 문서이며 회사 계정의 실제 청구·성능·업무 효과를 확인한 결과는 아닙니다. 가격과 제공 조건은 작성일 기준이므로 구매 직전 공식 안내와 계정별 계약을 다시 확인해 주세요.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.