GitHub 휴면 저장소 예약 스캔 변경: 초기 검증과 주간 분석을 구분하기
조직 전체에 보안 구성을 적용한 뒤 조용한 저장소에서 매주 분석이 실행되면, 그 비용과 알림을 실제 개발 활동으로 오해하기 쉽습니다. 반대로 실행이 줄었다고 보호가 사라졌다고 판단하는 것도 성급합니다.
2026년 10월 1일 GitHub는 code scanning default setup과 GitHub Code Quality의 예약 분석 시작 조건을 바꿨다고 발표했습니다. 이 글은 공식 변경 내용과 이를 운영에 적용하는 제안을 구분해 설명합니다.
초기 검증은 여전히 실행됩니다
default setup을 활성화할 때 초기 검증 분석은 계속 실행되며 결과도 바로 채워집니다. 주간 예약 스캔은 push 또는 pull request가 분석을 유발한 뒤 시작합니다. 시작 판단에는 활성화 이전 Git 활동이 아니라 분석 이력이 쓰입니다.
code scanning과 Code Quality는 활동 판단을 공유합니다. GitHub Enterprise Cloud에는 현재 적용되며 Enterprise Server 3.24에서 지원될 예정입니다. 공식 공지는 설정 변경이 필요 없다고 설명합니다. 자신의 서버 버전까지 같은 동작이라고 단정하지 마세요.
대시보드에는 활성화와 분석을 나누어 적으세요
운영 제안은 저장소마다 setup 상태, 가장 최근 분석의 원인, 커밋, 결과 시각, 담당자를 별도 필드로 남기는 것입니다. 설정을 켰다는 기록만으로 주간 분석의 지속 실행을 보장했다고 표시하지 마세요.
예를 들어 보관용 저장소에 초기 검증 결과만 있다면 ‘설정 적용·초기 분석 확인’으로 기록합니다. push나 pull request에 따른 분석이 확인된 경우에는 그 이력을 함께 적습니다. 이것은 GitHub가 제공하는 새 상태 이름이 아니라 팀이 만들 수 있는 점검 기록입니다.
실행 감소를 보안 개선 점수로 바꾸지 마세요
이번 변경으로 불필요한 주간 분석이 줄 수 있지만, 분석 횟수가 줄었다는 사실은 취약점이 줄었다는 뜻이 아닙니다. 경고의 유효성, 처리 상태, 실제 서비스에 연결된 저장소인지 여부를 따로 확인해야 합니다.
오래된 저장소도 배포 중인 서비스의 소스일 수 있습니다. 개발 활동이 적다는 이유만으로 중요도가 낮다고 분류하지 마세요. 분석 범위, 의존성 관리, 배포 자산의 담당자를 함께 점검하는 편이 좋습니다.
작은 범위에서 상태 차이를 확인하세요
먼저 유지보수 중인 저장소와 보관용 저장소를 각각 하나씩 골라 현재 분석 이력과 설정 화면을 읽어 보세요. push·pull request·초기 검증을 구분할 수 있는지 확인한 뒤 조직 보고서의 필드를 정리합니다.
이 점검을 위해 의미 없는 커밋을 만들거나 검증된 설정을 바꿀 필요는 없습니다. 공식 문서와 실제 분석 결과가 다르면 환경과 버전을 기록하고 원인을 조사하세요. 이 글의 도식은 확인 순서를 설명하며 제품 UI나 실제 스캔 결과 캡처가 아닙니다.