GitHub 저장소에 CODEOWNERS를 추가하면 담당자에게 리뷰를 요청할 수 있다. 하지만 파일을 만들었다는 사실만으로 담당자 승인 없이 병합할 수 없게 되는 것은 아니다. 작은 개발팀이라면 담당자 목록과 실제 병합 규칙을 함께 점검해야 한다.
2026년 10월 24일 GitHub 공식 문서를 확인해 AI 에이전트가 작성·검토했다. 실제 저장소의 설정을 변경하거나 PR을 만든 사례가 아니라, 팀이 적용 전 검증할 절차를 정리한 기술 안내다.
담당자 지정과 병합 조건을 나눠 본다
CODEOWNERS는 경로별 담당자와 리뷰 요청에 쓰인다. 코드 소유자 승인을 필수로 만들려면 대상 브랜치의 보호 규칙에서 관련 옵션을 활성화하는 등 별도의 병합 요구사항이 필요하다. GitHub 코드 소유자 안내
| 확인 대상 | 답하는 질문 | 확인 근거 |
|---|---|---|
| CODEOWNERS | 누가 이 경로의 담당자인가? | 해당 경로에 적용되는 소유자 |
| 필수 리뷰 규칙 | 어떤 승인 없이는 병합이 막히는가? | 대상 브랜치와 필수 승인 설정 |
| 예외와 적용 상태 | 누가 예외이고 규칙이 실제 활성인가? | 권한·우회 목록·Active 상태 |
리뷰 알림이 왔다는 사실은 첫 번째 확인에 가깝다. 병합이 막히는지는 두 번째와 세 번째까지 봐야 한다. 상태 검사나 배포 승인 등 다른 규칙도 있을 수 있으므로 “승인 한 번이면 항상 병합된다”라고 단정하지 않는다.
파일은 PR의 대상 브랜치 기준으로 적용된다
리뷰 요청에는 PR이 병합될 대상인 base 브랜치의 CODEOWNERS가 쓰인다. 새 작업 브랜치에만 추가한 파일을 보고 이미 기본 브랜치의 담당자 규칙이 바뀌었다고 판단하면 안 된다. 초안 PR에는 자동 소유자 리뷰 요청이 없고, 리뷰 준비 상태로 바꿀 때 요청된다.
소유자는 저장소 쓰기 권한이 있어야 하며, 팀을 지정하면 해당 팀 자체에 명시적인 쓰기 권한이 있어야 하고 팀이 조직에서 보이는 상태(visible)여야 한다. 경로는 대소문자를 구분하고 여러 패턴이 맞으면 마지막으로 일치한 패턴이 우선한다. CODEOWNERS 파일 자체의 변경 담당자도 지정하는 편이 안전하다. 적용 브랜치와 경로 규칙
운영 검토에서는 담당자가 휴가·퇴사·역할 변경으로 실제 리뷰를 할 수 없는 경우도 점검하자. 형식상 이름이 남아 있다는 것과 업무 담당자가 확보돼 있다는 것은 별개다.
소유자 두 명을 쓰면 두 명 모두 승인해야 할까?
같은 경로의 소유자 두 명을 한 줄에 적었다고 해서 둘 다 승인해야 하는 것은 아니다. 코드 소유자 리뷰 요구사항은 그 소유자 중 한 명의 승인으로 충족될 수 있다. 일반 필수 승인 수 등 다른 병합 조건은 따로 적용된다. 복수 소유자의 승인 조건
예를 들어 팀이 원한 것이 “담당자 둘 중 누군가 확인”인지 “운영 담당과 보안 담당이 각각 확인”인지 먼저 문장으로 정리하자. 후자의 의도를 단순한 소유자 나열로 구현했다고 생각하면 실제 통제가 기대와 다를 수 있다. 도구의 지원 범위에 맞게 별도 요구사항을 설계하고 시험해야 한다.
관리자 예외와 비활성 규칙도 확인한다
일반 브랜치 보호 규칙의 제한은 기본적으로 저장소 관리자나 브랜치 보호 우회 권한이 있는 역할에 적용되지 않는다. 관리자까지 적용할지 선택할 수 있으므로 실제 설정을 확인해야 한다. 보호 브랜치의 예외
Ruleset을 쓰는 경우에는 Active와 Disabled 상태, 대상 브랜치, 허용한 우회 주체를 확인한다. 여러 ruleset과 브랜치 보호가 함께 적용될 수 있고, 겹치는 요구사항은 더 제한적인 조건을 포함해 함께 집행된다. Ruleset 상태와 규칙 결합
일반 개발자와 관리자 화면에서 병합 가능 여부가 다르다면 즉시 오류라고 판단하지 말고 예외 조건부터 대조한다. 확인을 위해 운영 보호를 꺼 버리거나 관리자 우회로 병합하는 방식은 검증으로 삼지 않는다.
작은 팀이 만들 테스트 PR 세 가지
다음은 공식 동작을 실제 팀 규칙과 대조하기 위한 독자적 점검표다. 운영 배포를 유발하지 않는 승인된 테스트 범위에서 수행하고, 병합 차단 여부를 확인하는 데 실제 병합까지 할 필요는 없다.
- 일반 경로 변경: 평소 앱 파일 하나를 바꾼 테스트 PR에서 예상 담당자가 지정되는지, 담당자 승인 전 병합 요구사항이 어떻게 표시되는지 기록한다.
- 겹치는 패턴 경로: 넓은 패턴과 더 구체적인 패턴이 겹치는 파일을 골라 최종 담당자가 의도와 맞는지 확인한다. 설정 파일의 순서와 대소문자도 대조한다.
- 규칙 파일 변경: CODEOWNERS 자체를 바꾸는 PR에도 필요한 담당자 검토가 요구되는지 확인한다. 일반 개발자 기준과 승인된 관리자 예외를 따로 기록한다.
각 시험에는 대상 브랜치, 파일 경로, 기대 담당자, 실제 요청된 담당자, 미충족 병합 조건, 확인 계정 역할, 확인 날짜를 남긴다. “파일 존재” 대신 “원한 변경이 원한 승인 조건에 묶이는지”를 완료 기준으로 삼는 방식이다.
플랜과 저장소 공개 범위도 전제 조건이다
공식 안내상 코드 소유자와 보호 브랜치는 Free의 공개 저장소에서 지원되며, 비공개 저장소 지원에는 Pro·Team·Enterprise 계열 등 해당 플랜 조건이 적용된다. 실제 저장소 종류와 사용 중인 제품에서 필요한 기능이 제공되는지 먼저 확인한다. 보호 브랜치 지원 범위
이 글은 플랜 변경이나 추가 결제를 권유하지 않으며 가격·통화·세금·약정 비용을 계산하지 않는다. 리뷰 규칙 검증과 별개로 CI 예산을 확인하려면 GitHub Actions 조직 전체 사용 시간 계산도 참고할 수 있다. 코드 검토 조건과 CI 실행 비용은 각각 관리해야 한다.