GitHub 라이선스 정책: 패키지 사전 조회와 병합 차단을 나눠 확인하기

코딩 에이전트가 패키지를 추천하기 전에 라이선스 정책을 확인하게 만들고 싶다면, 먼저 두 질문을 나눠야 한다. “이 후보를 써도 되는가?”와 “이 변경을 병합할 수 있는가?”는 같은 검사가 아니다. 패키지를 고르기 전에는 정책 적합성을 조회하고, 병합 전에는 적용된 ruleset과 별도 브랜치 보호 규칙을 확인한다.

빠른 판단은 이렇다. 아직 후보를 고르는 단계라면 사전 정책 조회를 연결할 수 있는지 검토한다. 이미 PR에 의존성이 들어갔다면 라이선스 검사 결과와 ruleset 모드를 확인한다. Evaluate 결과가 보이는데 병합이 막혔다면 “Evaluate는 차단하지 않는다”만 반복하지 말고, 주석 해결을 요구하는 별도 브랜치 보호 규칙도 살펴본다. 예외가 필요하면 에이전트가 정책을 느슨하게 바꾸게 하지 말고 지정된 승인자에게 검토를 요청한다.

먼저 분리할 것: 후보 선택과 병합 허용

GitHub의 2026년 10월 16일 정식 제공 발표는 조직 정책에 패키지가 부합하는지 확인하는 새 API를 설명한다. 코딩 에이전트가 정책을 위반하는 패키지를 추천하거나 포함하지 않도록 통합할 수 있는 접점이다. 발표에는 기업 라이선스 정책을 내려받고, 갱신하고, 교체하는 API와 정책 변경 감사 로그도 나온다.

그렇다고 모든 코딩 에이전트가 자동으로 이 API를 호출한다는 뜻은 아니다. 에이전트가 정책을 읽는 경로와 실패했을 때의 행동은 별도로 설계해야 한다. 또 후보 조회가 긍정적이었다는 이유만으로 실제 PR의 병합을 보장할 수 없다. PR 단계에서는 변경된 의존성과 탐지된 라이선스, 적용 대상 규칙을 다시 평가하기 때문이다. 사전 조회는 후보 선택을 돕는 관문이고 병합 규칙은 변경 반영을 통제하는 관문이라는 구분이 실무상 중요하다.

후보 선택용 정책 조회와 PR 병합 조건은 별개다. 공식 발표·문서를 해설한 자체 도식이며 실제 API 실행 결과가 아니다. 출처: github.blog/changelog/2026-10-16-open-source-license-compliance-generally-available.

여기서 API 구현 예제를 복사해 바로 실행하려고 멈출 필요는 없다. 이번에 보존한 REST 의존성 그래프 색인 본문에서는 패키지 적합성 조회의 구체적인 엔드포인트·HTTP 메서드·토큰 권한 범위를 확인하지 못했다. 따라서 이 글은 작동한다고 주장하는 호출 코드나 최소 권한 목록을 제공하지 않는다. API의 존재는 발표로 확인하되, 실제 통합 전에는 해당 기능의 구체적인 최신 API 문서와 조직의 인증 정책을 별도 확인해야 한다.

증상별 결정표: 어떤 관문을 살펴볼까

다음 표는 공식 문서의 동작을 바탕으로 작성한 진단 안내다. 제품에서 실행해 얻은 시험 결과가 아니라, 독자가 확인 대상을 좁히도록 구성한 편집상 분석이다.

지금 보이는 상황	우선 확인할 대상	피해야 할 결론
에이전트가 새 패키지를 제안한다	후보 선택 과정에 정책 적합성 조회가 실제 연결됐는지	API가 있으니 에이전트도 이미 검사한다
비준수 의존성을 넣은 PR이 막힌다	Active ruleset의 라이선스 결과 요구 조건과 적용 대상	사전 후보 조회만 통과하면 병합도 된다
Evaluate에서 주석이 생겼다	주석 내용과 별도 주석 해결 브랜치 보호 규칙	Evaluate이므로 어떤 경우에도 병합 가능하다
꼭 써야 하는 패키지가 정책에 없다	대체·제거 가능성과 지정 승인자의 예외 검토 경로	주석 생성이 곧 예외 신청이나 승인이다

Active와 Evaluate를 구분하되 다른 보호 규칙을 지우지 않기

공식 개념 문서의 설명에 따르면, 라이선스 준수 결과를 요구하는 Active 모드 ruleset은 비준수 의존성을 도입하는 PR을 위반 해결 전까지 차단한다. 같은 조건을 둔 Evaluate 모드는 검사를 실행하고 주석을 달지만, 그 ruleset 자체로 병합을 차단하지는 않는다.

단, 주석 해결을 요구하는 별도 브랜치 보호 규칙은 라이선스 검사의 주석도 추적한다. Evaluate에서 생긴 주석도 그 보호의 대상이다. 따라서 “Evaluate 자체는 차단하지 않는다”는 정확한 문장을 “이 PR은 반드시 병합된다”로 넓혀 읽으면 진단을 그르친다. 화면의 결과를 해석할 때는 라이선스 ruleset의 모드와 다른 병합 조건을 함께 기록하는 편이 낫다.

두 모드 모두 라이선스 준수 조건을 둔 경우의 비교다. Evaluate 자체의 비차단을 PR 전체의 병합 보장으로 확대하면 안 된다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/supply-chain-security/open-source-license-compliance.

예를 들어 어떤 팀이 Evaluate로 정책 영향을 살펴보는 중이라고 가정하자. 라이선스 주석이 생겼고 병합이 막혔다면, 우선 주석 해결 요구가 별도로 걸려 있는지 확인할 수 있다. 이는 문서가 허용하는 가상 진단 사례이며, 이 글을 위해 특정 저장소의 설정을 바꾸거나 차단을 재현한 것은 아니다. 다른 검사나 보호 규칙도 있을 수 있으므로 라이선스 주석만 보고 모든 병합 실패의 원인을 단정하지 않는다.

비용·권한·대상 범위를 먼저 점검하기

기능의 정식 제공 대상은 데이터 레지던시 환경을 포함한 GitHub Enterprise Cloud다. 저장소에서 라이선스 정책을 강제하려면 해당 저장소에 GitHub Code Security 라이선스가 필요하다. 일반적인 무료 저장소 모두에 자동 적용된다고 이해하면 안 된다. 이번 근거에는 별도 가격표나 호출당 비용이 없으므로, 금액이나 무료 사용 가능 여부를 추정하지 않는다. 도입 판단의 첫 줄에는 기업 계약과 저장소의 Code Security 적용 여부를 적는 것이 맞다.

정책은 허용할 라이선스를 지정하며, 기본 목록 외에 SPDX 식별자를 수동으로 추가할 수도 있다. 평가는 저장소 의존성 데이터를 사용하고, 의존성 그래프에서 탐지한 전이 의존성도 포함한다. 직접 추가한 패키지 이름만 살펴보는 방식으로 이해해서는 안 된다. 반대로 데이터에 잡히지 않은 부분까지 전부 감사했다고 말할 수도 없다. 탐지된 데이터에 기반한 정책 검사는 법률 검토 전체를 대체하는 보증서가 아니다.

기능의 사용·강제 적용 요건과 데이터 범위를 분리했다. 탐지된 의존성의 정책 검사를 완전한 법률 감사로 볼 수는 없다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/supply-chain-security/open-source-license-compliance.

저장소에 쓰기 권한이 있는 개발자는 유효한 정책과 예외를 조회할 수 있다. 조회할 수 있다는 사실이 예외 승인권을 뜻하지는 않는다. 문서는 Enterprise Open Source License Manager를 예외 검토·승인 역할로 설명한다. 후보 조회를 붙이는 자동화와 정책 수정·예외 승인 자동화는 권한상 별개로 다뤄야 한다는 것이 이 글의 설계 제안이다. 이 제안은 특정 토큰 권한을 시험했다는 주장이 아니다.

비준수 결과가 나오면: 고치기와 승인받기를 분리하기

PR이 의존성을 추가하거나 바꾸면 GitHub는 기준 브랜치와 PR 브랜치의 의존성 변경을 비교하고 정책을 평가한다. 비준수 의존성에는 주석이 달릴 수 있다. 발표가 제시한 해소 방향은 해당 의존성의 제거·교체, 정책 수정, 패키지 예외다. 이 선택지를 모두 “그냥 허용으로 바꾸기”라고 묶어서는 안 된다.

원하는 기능을 다른 의존성으로 구현할 수 있다면 제거·교체를 먼저 검토할 수 있다. 반드시 유지해야 한다면 사용 목적과 필요한 예외를 지정 검토자에게 설명하는 경로가 필요하다. 이는 운영상의 제안이며, 특정 라이선스가 안전하다거나 특정 패키지를 승인해야 한다는 법률 판단은 아니다. 라이선스 식별 결과나 조직 정책의 적절성에 의문이 있으면 담당 검토자와 사실을 확인해야 한다.

주석은 예외 요청을 자동 생성하지 않는다. 대체·제거와 승인된 예외 처리를 구분한 안내로, 에이전트의 정책 우회를 뜻하지 않는다. 출처: docs.github.com/en/enterprise-cloud@latest/code-security/concepts/supply-chain-security/open-source-license-compliance.

특히 라이선스 주석이 생겼다고 예외 요청이 자동으로 생성되는 것은 아니다. 개발자가 코드를 바꾸어 비준수 의존성을 피할 수도 있기 때문이다. 계속 사용하려는 경우에는 추가 정보를 제공하는 흐름을 거쳐 담당 관리자에게 요청이 전달된다. 개발자에게 “주석을 봤다”, “예외를 요청했다”, “예외가 승인됐다”를 구분해 기록하도록 하면, 대기 상태를 승인으로 오인하는 일을 줄이는 데 도움이 된다. 여기서 감소 폭을 측정했다는 뜻은 아니다.

도입 회의에 가져갈 확인 순서

첫째, 대상이 Enterprise Cloud이고 강제 적용할 저장소에 Code Security 라이선스가 있는지 확인한다. 둘째, 해당 저장소에 적용되는 라이선스 정책과 예외를 확인한다. 셋째, 사전 조회 통합의 존재 여부와 PR ruleset 모드를 따로 기록한다. 넷째, Evaluate만으로 설명되지 않는 병합 제한은 주석 해결 등 별도 보호 규칙까지 확인한다. 마지막으로 비준수 결과의 담당자와 대체·제거·예외 요청의 선택 경로를 정한다.

이 순서는 새 기능을 무조건 켜라는 권고가 아니다. 정책 조회, 병합 조건, 예외 승인 사이에서 누가 어떤 결정을 하는지 먼저 분명하게 만들자는 제안이다. 정책 변경 감사 로그는 변경 기록과 외부 기록 시스템의 연계를 검토하는 근거가 될 수 있지만, 이 글에서 외부 시스템 연결을 시험한 것은 아니다. 무인 에이전트에 승인 권한까지 한꺼번에 주는 구성도 권하지 않는다.

확인한 근거와 하지 않은 시험

이 글은 공식 문서에 근거한 설계·진단 안내이며, 실제 기업 저장소에서 API 호출이나 병합 차단을 재현한 시험은 아니다. 원문은 2026년 10월 18일 수집·보존된 본문을 기준으로 읽었으며, 후속 문서가 달라질 수 있다. 글과 그림의 두 관문·모드 비교·적용 범위·예외 경로는 그 근거를 해설하기 위해 직접 구성했다. 실제 제품 화면이나 성능 측정 그래프는 아니다.

사전 조회가 있다면 후보를 고르는 시점에 정책을 참고하도록 설계할 수 있다. 그러나 실제 병합 판단과 예외 승인을 그 조회 하나로 대신해서는 안 된다. 이 구분을 팀의 리뷰 문서에 남기는 것이 이번 발표에서 바로 가져갈 수 있는 실무적 결과다.

원문과 근거 범위

• GitHub 정식 제공 발표 — How it works / What’s new and improved: 제공 대상, PR 검사, 새 API와 감사 로그.
• GitHub 개념 문서 — How pull request enforcement works / Where results appear: Active·Evaluate 경계, 주석 해결 보호, 데이터 범위와 승인 역할.
• 확인한 REST 의존성 그래프 색인: 보존 본문에서 패키지 정책 조회의 구체 호출 규격은 확인하지 못했으며 실행 예제를 제시하지 않았다.