GitHub AI Scan GA: 보안 경고·병합 차단·청구 계정을 따로 확인하세요

조직의 AI Scan을 켜기 전에는 ‘보안 검사를 하나 더 붙인다’는 생각보다 먼저 세 칸을 나눠 적는 편이 안전하다. 적용할 저장소와 PR, 실제 병합을 막을 필수 검사, 사용량이 청구될 계정이다. AI 경고가 있는가, 병합을 막는가, 어디로 청구되는가는 서로 다른 질문이다. 특히 조직 설정을 활성화하면 적격 저장소에 바로 적용되므로, 저장소별 제외 작업보다 과금 확인을 먼저 해야 한다.

GitHub는 2026년 10월 15일 PR용 AI Scan의 정식 제공을 발표했다. 이 글은 10월 16일 수집한 공식 발표와 문서의 본문을 기준으로, 도입 전에 구분할 조건을 정리한다. 정식 제공은 모든 PR을 검사한다거나, 경고가 자동으로 병합을 차단한다거나, 사용료가 없다는 뜻은 아니다. 아래 판단표에서 자기 저장소에 해당하는 행부터 확인하면 된다.

먼저 나눠 볼 세 가지 결과

확인할 질문	공식 문서가 설명하는 결과	운영자가 따로 결정할 일
AI Scan이 취약점 의심 사항을 찾았는가?	PR에 AI 표시가 붙은 advisory finding을 보여 준다	위험 설명과 변경 코드를 읽고 수정 필요성을 판단한다
그 finding이 병합을 막는가?	AI finding은 code scanning 검사를 실패시키지 않으며 ruleset 필수 조건으로 병합을 막지 못한다	기존 필수 검사와 리뷰 승인 정책을 별도로 확인한다
스캔 사용량은 어디에 잡히는가?	Code Security AI Credits로 집계하며 저장소 소유 관계와 해당 계정의 청구 조건을 따른다	실제 청구 계정, 포함 크레딧과 예산을 확인한다

AI finding과 검사 실패는 같은 신호가 아니다. 공식 문서의 advisory 동작으로 만든 반례이며 실제 PR 화면이나 실행 결과가 아니다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/code-scanning/ai-powered-security-detections.

가령 PR에 AI 경고가 보이는데 code scanning 검사가 통과한 상황을 생각해 보자. 이 조합은 문서상 가능하다. ‘검사가 통과했으니 AI 경고도 없었다’고 결론 내리면 잘못된 판독이다. 반대로 AI 경고가 생겼다는 이유만으로 ‘병합이 반드시 막혔다’고 보고해서도 안 된다. 여기서 필요한 것은 경고의 내용 검토와 실제 병합 요건 확인을 분리하는 일이다. 이는 문서의 advisory 성격에서 도출한 편집상 운영 제안이지, 특정 PR에서 재현한 관측 결과는 아니다.

PHP 변경이 있어도 모든 PR이 대상은 아니다

AI Scan은 CodeQL이 현재 다루지 않는 언어·프레임워크의 PR 변경에서 보안 문제를 찾는 보완 경로다. 공식 예시에는 PHP, Shell/Bash, Terraform의 HCL, Dockerfiles 등이 있다. 이를 ‘CodeQL을 대체하는 전체 저장소 검사’로 이해하면 적용 범위를 과대평가하게 된다. 문서는 전체 저장소 스캔을 지원하지 않으며, finding이 저장소 보안 화면의 backlog alert로 남는 경로와도 다르다고 설명한다.

실행 조건도 함께 봐야 한다. 저장소에서 code scanning이 활성화되어 있고, 실효 AI Scan 설정도 켜져 있어야 한다. 여기에 CodeQL이 다루지 않는 지원 언어·프레임워크의 변경이 포함된 적격 PR이어야 한다. 포크에서 온 PR과 Dependabot이 만든 PR은 제외된다. 조건을 충족하면 PR 생성과 새 커밋마다 검사한다. CodeQL default setup이 필수인 것은 아니며, CodeQL 분석이 실패하거나 대기 중인 상태에도 AI Scan은 독립적으로 실행될 수 있다.

실행되지 않은 PR을 탐지 실패나 안전 판정으로 오해하지 않기 위한 조건표다. 지원 언어와 범주는 바뀔 수 있다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/code-scanning/ai-powered-security-detections.

내 저장소·변경의 상태	도입 전에 내릴 판단
조직 또는 개인 소유 공개 저장소	저장소 유형은 제공 범위에 들어가지만 실효 설정과 PR 조건도 확인한다
조직 소유 비공개·내부 저장소	GitHub Code Security 또는 GitHub Advanced Security 요건을 먼저 확인한다
개인 소유 비공개 저장소	문서의 제공 대상이 아니다
관리형 사용자 계정의 개인 네임스페이스	code scanning을 켰더라도 제공 대상이 아니다
포크 PR 또는 Dependabot PR	AI Scan이 실행되지 않는 제외 조건으로 취급한다

예를 들어 공개 PHP 저장소라는 이유만으로 외부 기여자의 포크 PR까지 AI Scan이 보호한다고 안내하면 안 된다. 저장소의 자격과 개별 PR의 자격은 별개다. 경고가 없을 때도 먼저 대상 PR인지 확인해야 하며, 무경고를 안전 인증으로 바꿔 말해서는 안 된다. 지원 언어와 탐지 범주는 기능 발전에 따라 달라질 수 있다.

Copilot 라이선스 불필요와 무료는 다른 말

공식 문서는 AI Scan 사용에 GitHub Copilot 라이선스가 필요하지 않다고 설명한다. 그러나 사용량은 active-committer 라이선스와 별도로 Code Security AI Credits에 잡힌다. 라이선스가 없어도 이용할 수 있다는 접근 조건과, 실제 스캔에 어떤 비용이 생기는지는 서로 다른 층위다. 발표문에는 기업 청구·라이선스의 AI usage에서 Advanced Security 제품으로 사용량을 확인할 수 있다고 안내되어 있다.

조직 소유 저장소는 해당 조직의 청구를 담당하는 계정으로 사용량이 청구된다. 개인 소유 공개 저장소는 원칙적으로 개인 계정에 청구되지만 예외가 있다. 저장소 소유자가 조직이나 엔터프라이즈에서 제공한 Copilot 라이선스를 가지고 있다면, 그 라이선스를 제공하는 조직 또는 엔터프라이즈로 청구될 수 있다. 따라서 ‘개인 저장소니까 언제나 개인 카드로 잡힌다’는 가정도 피해야 한다.

개인 공개 저장소 소유자가 조직·기업 제공 Copilot 라이선스를 가진 경우의 청구 예외다. 모든 개인 저장소가 조직에 청구된다는 뜻은 아니다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/code-scanning/ai-powered-security-detections.

해당 청구 계정이 Copilot entitlement를 통해 포함 AI 크레딧을 받는 경우에는 그것부터 사용한다. 포함분이 없거나 소진되면 적용 예산에 따라 사용량이 계량된다. 문서는 hard budget 때문에 사용 가능한 Code Security AI Credits가 남지 않으면 finding을 생성할 수 없고, 관리자가 제한 예산을 늘리거나 다음 청구 주기가 시작되면 재개된다고 설명한다. 단순한 예산 알림이 언제나 검사를 차단한다는 뜻으로 확대하면 안 된다.

이 글에서 PR당 비용이나 탐지 정확도는 계산하지 않는다. 확인한 자료만으로 단위 크레딧 가격, PR별 소비량, 오탐률이나 재현율을 정할 수 없기 때문이다. 예산 담당자가 확인할 것은 임의의 원화 예상액이 아니라 실제 청구 계정, 포함분의 존재, 적용되는 계량 예산과 차단형 한도다. 라이선스 요건을 충족했다는 사실만으로 사용량 비용까지 해결된 것은 아니다.

조직 전체 활성화 전에 확인할 순서

권한의 ‘허용’과 기능의 ‘켜짐’도 나눠 보자. 엔터프라이즈 소유자는 조직이 AI Scan을 활성화할 수 있게 허용하거나 막을 수 있지만, 허용 정책 자체가 검사를 켜지는 않는다. 문서상 기본 정책은 허용하지 않음이다. 실제 조직 설정은 조직 소유자와 보안 관리자가 활성화하며, 적격 저장소는 그 설정을 상속한다.

주의할 부분은 조직에서 켜는 순간이다. code scanning이 활성화된 적격 저장소에 즉시 적용되며, 저장소 관리자가 제외하기 전에 적격 PR이 크레딧을 소비할 수 있다. 조직 소유 저장소 관리자는 조직이 켠 기능에서 빠질 수 있지만 조직 설정이 꺼져 있는데 개별적으로 들어갈 수는 없다. 개인 소유 공개 저장소는 관리자가 Code scanning 아래 AI Scan 토글로 직접 관리한다.

조직 설정을 켜면 code scanning이 켜진 적격 저장소에 즉시 적용된다. 저장소 관리자의 제외 전에 크레딧이 소비될 수 있으므로 사전 검토를 앞에 두었다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/code-scanning/ai-powered-security-detections.

그래서 이 글이 제안하는 순서는 ‘누가 청구받는지 확인 → 적격 저장소와 제외할 저장소 목록 확인 → 엔터프라이즈 허용과 조직 실효 설정 구분 → 활성화 후 PR 경고와 사용량을 따로 검토’다. 조직을 먼저 켠 뒤 나중에 제외할 목록을 만드는 방식에는 그 사이 사용량이 발생할 수 있다는 차이가 있다. 이 흐름은 공식 문서의 조건을 운영 순서로 재구성한 것이며, 별도의 시험용 활성화 버튼이나 요금 없는 파일럿을 보장하지 않는다.

경고를 받은 뒤에도 남는 사람의 판단

finding은 위험 설명과 권장 수정을 포함할 수 있고, 제공되는 경우 Copilot Autofix가 코드 변경을 제안할 수 있다. 그렇다고 제안이 이미 안전하게 테스트된 패치라는 뜻은 아니다. 변경 내용을 검토하고 프로젝트의 테스트와 리뷰 절차를 적용할 책임은 남는다. AI 기반 탐지에는 오탐도 있을 수 있으므로, 경고 개수만으로 보안 수준을 비교하거나 누락이 없다고 주장하지 않는다.

이 글은 공식 문서를 바탕으로 만든 운영 판단표이며, 실제 저장소 설정 변경이나 유료 스캔 실행 결과가 아니다. 도입의 결론은 간단하다. AI Scan은 PR에서 검토할 신호를 늘리는 기능으로 평가하되, 병합 통제와 청구 책임까지 자동으로 따라온다고 가정하지 말자. 활성화 전 기록을 세 갈래로 나누면 ‘설정은 켰는데 왜 병합되었나’, ‘개인 저장소인데 왜 조직 사용량에 잡히나’, ‘공개 저장소인데 왜 이 PR은 검사하지 않나’를 각각 다른 조건으로 진단할 수 있다.

출처와 확인 범위

• GitHub Changelog, AI Scan for pull requests generally available, 2026년 10월 15일 발표. 정식 제공 범위, advisory 동작과 크레딧 과금 설명을 확인했다.
• GitHub Docs, AI Scan for pull requests, 2026년 10월 16일 보존 본문. Availability, Billing, How AI Scan works, Limitations, Enabling AI Scan 절의 자격·청구 예외·설정 권한을 확인했다. 이후 문서 변경 가능성이 있다.