GitHub 라이선스 검사 GA: 허용 목록보다 예외의 수명을 관리하기
의존성 업데이트 PR에 보안 경고가 없다고 라이선스 검토까지 끝난 것은 아니다. 반대로 라이선스 검사가 초록색이라고 제품의 모든 배포 방식이 검토된 것도 아니다. 2026년 10월 16일 GitHub의 라이선스 준수 검사 정식 출시를 계기로, 도구가 판정하는 범위와 팀이 책임질 판단을 나눠 볼 때다.
정식 출시는 누구에게 적용되나
공식 발표의 대상은 GitHub Enterprise Cloud와 데이터 레지던시 환경이며, 저장소에는 GitHub Code Security가 활성화되어 있어야 한다. 모든 Free·Team 저장소에 자동 적용되는 기능으로 읽으면 안 된다. 기업 정책을 만들고, ruleset의 Require license compliance results before merging 조건으로 저장소를 지정하는 과정이 필요하다. 먼저 우리 계정의 자격, 저장소 대상, 실제 병합 조건을 각각 확인해야 한다. Active 모드는 병합을 막고 Evaluate 모드는 주석만 남기므로 ruleset 모드도 확인한다. 별도의 댓글 해결 필수 보호 규칙이 있으면 주석이 병합에 영향을 줄 수 있다.
검사가 묻는 것은 변경된 의존성
의존성을 추가하거나 수정하는 PR에서 새로 들어오거나 바뀐 패키지의 라이선스를 정책과 비교한다. 정책을 위반하면 PR에 표시되고, 패키지 제거·교체, 정책 변경 또는 패키지 예외로 대응할 수 있다. 이 설명은 기존 배포물 전체의 검토 완료를 뜻하지 않는다. 운영상 중요한 질문은 어떤 버전과 변경이 검사되었고, 어떤 정책으로 판단했는지다. 이 글의 절차 제안은 공식 기능 설명과 구분한 운영 해석이다.
예외에는 담당자와 재검토 시점을 붙인다
Enterprise Open-Source License Manager 역할은 종료 요청을 검토·승인할 담당자를 정하는 수단이다. 팀이 추가로 남길 기록은 패키지와 버전, 해당 PR, 사용 방식, 승인 이유, 책임자, 재검토 시점이다. 예를 들어 데모 용도로 승인한 패키지가 고객 배포물에 포함되면 같은 승인을 그대로 재사용하지 않도록 검토 계기를 정할 수 있다. 이는 GitHub가 자동으로 예외 만료를 강제한다는 뜻이 아니라 팀이 설계할 관리 절차다.
에이전트의 패키지 선택 앞에 확인을 둔다
발표에는 패키지가 정책을 준수하는지 확인하는 API와 정책 변경 감사 이벤트도 포함되어 있다. 에이전트가 패키지를 설치하기 전에 확인하도록 연결하면 뒤늦은 교체 비용을 줄일 여지가 있다. 다만 API 응답을 받았다는 사실만 저장하지 말고 확인한 패키지·정책·시각과 결과를 변경 기록에 연결해야 한다. 응답 실패나 알 수 없는 라이선스는 조용히 허용하지 않고 검토 대상으로 넘기는 방식이 현실적이다.
오늘은 작은 시험 PR 두 개로 시작할 수 있다. 승인된 의존성과 의도적으로 정책에 맞지 않는 의존성을 각각 넣어 표시와 병합 차단을 확인하고, 예외 승인 후 기록이 어디에 남는지 살핀다. 실제 고객 코드는 바꾸지 않는 시험 저장소가 적합하다. 기존 CI와 정책이 충돌하면 조직 전체로 확대하기 전에 담당자와 해제 절차부터 정리한다. 이것은 제안하는 검증 방법이며 실제 시험을 수행했다는 보고는 아니다.
도입을 고민하는 실무 질문은 기능이 켜졌는지보다 누가 예외를 닫고 다음에 무엇이 바뀌면 다시 검토할지다. 공식 발표는 커뮤니티 토론도 안내하지만 여기서는 참여 규모나 도입률을 추정하지 않았다. 이 글은 도구 운영 설명이며 개별 라이선스의 법적 판단을 대신하지 않는다. 다음 의존성 PR 하나에 판단 근거와 재검토 계기를 함께 남기는 것부터 시작하자.
출처와 확인 범위
GitHub Docs · Open source license compliance
2026년 10월 17일 공식 출시 공지를 확인했다. 실제 계정의 설정과 최신 문서를 함께 확인하자.