GitHub이 조직과 저장소 단위에서 전체 저장소 AI 스캔을 켜고 끄는 REST API 설정을 공개 미리보기로 제공한다. 관리자는 스크립트나 인프라 코드로, 설정을 코드로 관리하는 방식으로 여러 저장소에 설정을 적용할 수 있으며, 조직 정책에 맞춰 저장소별 예외도 둘 수 있다.
1. 조직과 저장소에서 설정 관리
GitHub은 2026년 11월 13일 기존 AI 스캔 활성화 기능에 저장소 전체 스캔 여부를 추가했다고 밝혔다. 새 속성인 repository_scan은 활성화와 비활성화 가운데 하나를 받는다. 조직이나 저장소에 조회 또는 변경 요청을 보내 관리한다.
기존에는 변경 코드를 검토하는 풀 리퀘스트, 코드 변경을 검토받기 위해 제안하는 기능 대상 스캔을 설정했다. 이번에 추가된 전체 저장소 스캔 설정은 기존 설정과 함께 한 요청에서 바꿀 수 있다. 새 설정도 기존 설정과 같은 조직·저장소 간 상속 규칙, 상위 설정을 하위에 물려주는 원칙을 따른다.
조직 설정을 비활성화하면 소속 저장소에서 이를 켤 수 없다. 조직이 활성화하면 저장소가 설정을 이어받고, 관리자는 개별 저장소에서 선택적으로 끌 수 있다. 따라서 중앙 정책을 기본값으로 적용하면서 예외 저장소를 따로 관리할 수 있다.
2. 배포 수고를 줄이고 실행 비용을 관리한다
설정 배포와 실제 스캔 실행은 두 단계로 이뤄진다. 관리자가 사용 가능 범위를 정하면, 쓰기 권한이 있는 사용자가 필요할 때 스캔 실행을 요청한다. 각 스캔은 GitHub Code Security AI 크레딧, 사용량에 따라 차감되는 이용 단위를 소비한다.
API로 반복 설정을 자동화하면 저장소를 하나씩 열어 변경하는 수고를 줄이고, 팀이 정한 정책을 일관되게 적용하기 쉽다. 반면 실제 실행에는 크레딧이 들기 때문에, 설정 배포에서 절약한 관리 수고와 별도로 실행 비용을 다뤄야 한다. 일괄 활성화할 저장소의 범위와 실행을 맡길 사용자를 함께 정하는 것이 운영상 중요하다.
3. 적용 대상과 권한 확인
조직 설정은 조직 소유자와 보안 관리자가 관리할 수 있고, 저장소 관리자는 개별 저장소의 설정을 조정할 수 있다. 세분화 토큰, 권한 범위를 세밀하게 정한 인증 키를 쓸 때 조직 변경에는 조직 관리 권한 쓰기가, 저장소 변경에는 저장소 관리 권한 쓰기가 필요하다. 저장소 설정 조회에는 코드 스캐닝 경보, 코드에서 발견된 보안 문제 알림 읽기 권한이 필요하다.
조직 소유 공개 저장소에서 사용할 수 있으며, 비공개 또는 내부 저장소에는 GitHub Code Security나 GitHub Advanced Security가 필요하다. 적용 절차는 엔터프라이즈 소유자가 정책에서 AI 스캔을 허용하는 데서 시작한다.
4. 요청을 한 번에 적용하는 방법
조직 경로와 저장소 경로 모두 설정 조회와 변경을 지원한다. 조직에서는 /orgs/{org}/code-scanning/ai-scan을, 개별 저장소에서는 /repos/{owner}/{repo}/code-scanning/ai-scan을 사용한다.
조회는 GET, 변경은 PATCH 요청으로 보낸다. 아래는 조직에서 풀 리퀘스트 스캔과 저장소 전체 스캔을 함께 활성화하는 원문 예시다. 인증 토큰과 조직 이름을 자신의 환경에 맞춰 지정해 쓴다.
curl -L \
-X PATCH \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/orgs/ORG/code-scanning/ai-scan \
-d '{"pr_scan":"enabled","repository_scan":"enabled"}'요청이 성공하면 두 설정의 상태가 응답에 담긴다. 함께 바꾸려는 설정을 하나의 요청으로 보내면 응답에서 두 값을 확인할 수 있어, 변경 후 상태를 점검하는 절차도 묶을 수 있다.
엔터프라이즈 정책이 활성화를 막거나 값 검증에 실패하면 422 오류가 반환되며, 두 설정을 함께 바꾸는 요청에서 하나라도 막히면 둘 다 기존 값으로 남는다. 저장소가 보관 상태, 변경을 막도록 저장소를 보존한 상태이거나 GitHub Advanced Security가 활성화되지 않은 경우 저장소 변경 요청에 403 오류가 날 수 있고, GitHub Enterprise Server는 지원 대상에서 제외된다.
5. 조회 결과로 조직 설정과 예외를 점검한다
조직 조회 응답은 조직에 저장된 설정값을 보여 주며, 조직의 실제 적용에는 엔터프라이즈 정책이 반영된다. 따라서 관리자는 상위 정책을 확인하고 조직 설정을 배포한 뒤, 저장소별 조회로 개별 설정을 점검하는 순서로 운영 절차를 짤 수 있다.
조직과 저장소의 조회 경로를 함께 활용하면 중앙에서 정한 기본값과 개별 저장소가 선택한 예외를 각 수준에서 확인할 수 있다. 여러 저장소로 기능을 넓힐 때도 설정 변경뿐 아니라 확인 절차까지 스크립트에 포함하는 것이 실용적이다.
조직 단위 설정과 저장소별 예외를 함께 제공해 배포 관리는 간소화하지만, 스캔 실행과 크레딧 관리는 별도로 설계해야 한다.
