GitHub 라이선스 정책 검사 정식 출시, AI 코딩에 연결할 API도 제공합니다

AI가 추천한 라이브러리를 프로젝트에 넣을 때는 기능과 성능 외에 확인할 것이 있습니다. 그 패키지가 조직의 오픈소스 라이선스 정책에 맞는지입니다. 코드가 잘 실행된다는 사실만으로는 이 질문에 답하기 어렵습니다.

GitHub는 2026년 10월 16일 오픈소스 라이선스 정책 검사 기능을 정식 출시했습니다. 기업의 공통 정책을 풀 리퀘스트(PR)에 적용하고, 패키지를 선택하는 도구에서도 같은 정책을 조회할 수 있게 한 점이 중요합니다. 다만 이용 대상은 GitHub Enterprise Cloud이며, 적용할 저장소에 GitHub Code Security가 활성화돼 있어야 합니다. GitHub 정식 출시 발표

PR 검사는 이미 있었고, 기업 운영을 위한 기능이 늘었습니다

의존성을 추가하거나 바꾸는 PR에서 라이선스를 검사하는 기능은 6월 30일 공개 프리뷰에 이미 포함돼 있었습니다. 기업 단위 정책과 병합 전 검사, 예외 승인 절차를 이번에 처음 생긴 기능으로 읽으면 변화의 범위를 잘못 이해하게 됩니다. 공개 프리뷰 발표

정식 출시에서는 데이터 레지던시를 사용하는 Enterprise Cloud 환경도 지원합니다. 해당 환경의 의존성 그래프와 소프트웨어 구성 명세서(SBOM)에도 라이선스 정보가 들어갑니다. 정책 변경은 감사 로그에 남고, 기업 정책을 내려받거나 수정·교체하는 API와 패키지의 정책 준수 여부를 확인하는 API가 추가됐습니다. 정식 출시의 변경 사항

여기서 실무적으로 읽을 수 있는 변화는 정책을 운영하는 접점이 넓어졌다는 것입니다. 개발자가 변경을 제출했을 때 검사하는 절차에 더해, AI 코딩 도구가 패키지를 제안하는 단계에도 조직의 기준을 연결할 수 있습니다.

시작은 이용 조건과 검토 담당자입니다

설정에 앞서 Enterprise Cloud 이용 여부, 대상 저장소의 Code Security 활성화, 의존성 그래프 활성화를 확인해야 합니다. 기업 정책과 규칙 집합(ruleset)을 관리할 권한도 필요합니다. GitHub Free나 Team의 모든 저장소에서 바로 켤 수 있는 기능으로 소개해서는 안 되는 이유입니다. 설정 전 요구사항

그다음에는 허용할 라이선스와 예외를 검토할 사람을 정합니다. GitHub는 Enterprise Open-Source License Manager 역할을 제공하며, 담당자는 요청 알림을 받고 예외를 검토할 수 있습니다. 라이선스 목록의 위험도 분류는 참고 정보이므로, 조직의 허용 기준은 법무 담당자와 확인하는 편이 좋습니다. 정책과 담당자 설정

먼저 담당자를 정하는 이유는 단순합니다. 검사가 문제를 찾았어도 누가 판단할지 정해져 있지 않으면, 개발자는 어떤 근거로 패키지를 바꾸거나 예외를 요청해야 할지 알기 어렵습니다.

Evaluate에서 확인하고, 예외 처리 뒤 Active로 옮깁니다

GitHub는 패키지 명세가 바뀐 PR에서 기준 브랜치와의 의존성 차이를 비교하고, 감지한 라이선스를 정책과 대조합니다. 의존성 그래프가 찾아낸 간접 의존성도 평가에 포함됩니다. 검사 범위와 동작

처음 적용할 때는 일부 저장소를 Evaluate 모드로 두고 어떤 변경이 걸리는지 살펴볼 수 있습니다. 이 모드는 검사 결과를 PR에 표시하며, 라이선스 규칙 자체로 병합을 막지는 않습니다. 다만 별도의 브랜치 보호 규칙이 댓글 대화 해결을 요구하면 Evaluate에서 생긴 알림도 병합을 막는 원인이 될 수 있습니다. 시험 적용 전에는 기존 보호 규칙도 함께 확인해야 합니다. Evaluate와 병합 제한

위반 사항은 패키지를 제거하거나 교체하고, 필요한 경우 정책 변경이나 예외 승인을 거쳐 해결할 수 있습니다. 예외는 저장소 범위 또는 기업 범위에 적용할 수 있으므로, 한 프로젝트의 필요를 어디까지 허용할지도 검토해야 합니다. 예외를 승인해도 다른 필수 검사가 실패한 상태라면 병합할 수 없습니다. 예외 검토 방법

이 과정을 확인한 저장소부터 Active로 전환하는 방식이 현실적입니다. Active 모드에서 라이선스 검사 조건을 사용하면 정책 위반이 해결될 때까지 PR 병합이 차단됩니다. 운영 순서는 이용 조건 확인, 정책과 담당자 지정, Evaluate 시험, 예외 검토, Active 적용으로 잡아볼 수 있습니다.

AI 코딩에는 별도의 API 연동이 필요합니다

새 패키지 검사 API는 제출한 패키지 URL(PURL)을 저장소의 유효한 라이선스 정책과 비교합니다. 호출 경로는 POST /repos/{owner}/{repo}/license-compliance/package-checks이며, 요청 본문에 검사할 PURL 목록을 넣습니다. 세분화된 토큰에는 Repository license policy의 읽기 권한이 필요합니다. 사용자를 대신하는 요청이라면 해당 사용자에게 저장소 쓰기 권한 또는 라이선스 정책 보기 권한도 있어야 합니다. 패키지 검사 REST API

예를 들어 코딩 에이전트가 후보 패키지를 고른 뒤 API로 허용 여부를 확인하고, 그 결과를 다음 작업에 반영하도록 설계할 수 있습니다. 이는 발표와 API를 바탕으로 생각해볼 수 있는 연동 방식입니다. 모든 Copilot 작업에 검사가 자동으로 붙는다고 발표된 것은 아닙니다. API 연결과 함께 조회 실패나 정책 미설정 때 작업을 멈출지, 사람에게 넘길지도 정해야 합니다.

처음부터 에이전트 연동까지 한꺼번에 만들 필요는 없습니다. PR에서 정책과 예외 처리 흐름을 확인한 뒤, 필요할 때 같은 기준을 패키지 선택 단계로 앞당기면 됩니다.

검사가 통과했다는 말의 범위를 남겨야 합니다

이번 기능이 확인하는 것은 감지한 의존성이 조직의 정책에 맞는지입니다. 결과를 전체 코드의 법적 적합성을 보증하는 것으로 확대해서는 안 됩니다. 허용 기준을 정하고 예외를 판단하는 책임은 운영 절차에 남아 있습니다.

AI가 패키지를 골라도 팀이 확인할 질문은 구체적입니다. 어떤 의존성이 추가됐는지, 어느 정책으로 검사했는지, 예외를 누가 승인했는지입니다. AI 코드 리뷰 이후의 검증과 마찬가지로, 완료 표시와 함께 판단 근거를 남겨야 다음 변경에서도 같은 기준을 이어갈 수 있습니다.

이 글은 GitHub의 공식 발표와 문서를 바탕으로 정리한 해설입니다. 설정 순서와 에이전트 연동 예시는 적용을 위한 제안이며, 직접 운영해본 결과는 포함하지 않았습니다.