브랜치 보호와 CODEOWNERS는 개발 속도를 늦추는 장치가 아니다

핵심 요약

브랜치 보호와 CODEOWNERS는 리뷰 횟수를 늘리는 장치가 아니라 중요한 코드가 승인된 경로와 자동 검사를 거쳐 병합되도록 만드는 변경 통제다. 저장소 중요도에 따라 필수 리뷰, 상태 검사, 최신 커밋 재승인, 서명, 강제 푸시·삭제 제한, 관리자 우회를 계층화해야 한다. CODEOWNERS는 실제 권한과 팀 구조를 반영하고, 매칭되지 않는 경로와 응답하지 않는 소유자를 지속적으로 점검해야 한다.

브랜치 보호가 느리다고 느껴지는 조직을 보면 규칙 자체보다 소유자 부재, 불안정한 CI, 과도한 전역 규칙, 관리자 우회가 문제인 경우가 많다. 모든 저장소에 같은 두 명 리뷰를 요구하면 작은 문서 변경도 막히고, 정작 배포 워크플로·인증·결제 코드에는 해당 분야 검토자가 지정되지 않을 수 있다.

목표는 병합을 어렵게 만드는 것이 아니라 위험한 변경이 혼자, 검증 없이, 기록 없이 운영으로 들어가는 경로를 없애는 것이다.

저장소와 경로를 먼저 등급화한다

등급	예시	권장 통제 방향
핵심 운영	인증, 결제, 권한, 고객 데이터, 배포 플랫폼	필수 소유자 리뷰, 상태 검사, 우회 제한, 강한 감사
일반 운영	고객 기능과 백엔드 서비스	최소 리뷰, 테스트, 직접 푸시 금지
내부 도구	제한된 영향의 자동화·분석	영향에 맞는 리뷰와 비밀 검사
문서·예제	비운영 콘텐츠	가벼운 검사, 공급망·링크 위험 검토
보관 저장소	더 이상 변경하지 않는 코드	읽기 전용, 배포·비밀 제거, 명시적 아카이브

같은 저장소 안에서도 .github/workflows/, 배포 IaC, 인증 미들웨어, 데이터 마이그레이션, 비밀 관리 경로는 더 강한 통제가 필요하다. 저장소 전체 규칙과 경로별 CODEOWNERS를 조합한다.

핵심 브랜치 보호 항목

풀 리퀘스트 필수

기본 브랜치 직접 푸시를 막는다.
최소 승인 수를 위험 등급에 맞게 정한다.
새 커밋이 추가되면 이전 승인을 무효화하거나 마지막 변경을 다시 검토하게 한다.
작성자가 자신의 승인을 충족하지 못하게 한다.
대화 해결과 필수 검토 의견 반영 여부를 명확히 한다.

상태 검사 필수

빌드·단위 테스트뿐 아니라 비밀, 의존성, 정책, IaC 검사를 선택한다.
검사 이름 충돌이나 다른 워크플로의 동일 이름으로 우회되지 않게 출처를 고정한다.
불안정한 검사는 병합 우회 이유가 아니라 안정화 대상이 되게 한다.
검사 결과가 PR의 실제 헤드 커밋에 대한 것인지 확인한다.
외부 포크에서 비밀이 있는 워크플로가 실행되지 않게 한다.

브랜치 변경 제한

강제 푸시와 브랜치 삭제를 기본 금지한다.
관리자·봇·앱 우회를 필요한 범위로 제한한다.
병합 큐 또는 최신 기본 브랜치 검증으로 경합 회귀를 줄인다.
서명 커밋·태그 요구는 키 관리와 자동화 호환성을 함께 검토한다.
규칙 변경과 우회 사용을 감사·경보한다.

CODEOWNERS를 실제 통제로 만드는 법

CODEOWNERS 파일이 존재한다고 리뷰가 보장되는 것은 아니다.

파일 자체를 보호된 경로로 두고 별도 소유자를 지정한다.
넓은 * 규칙 뒤에 민감 경로를 더 구체적으로 선언한다.
실제 쓰기 권한과 리뷰 가능 권한이 있는 팀·사용자를 지정한다.
개인 한 명보다 온콜·업무 팀을 사용하되 책임이 흐려지지 않게 한다.
팀 이름 변경, 퇴사, 조직 이동을 자동 점검한다.
대소문자와 경로 패턴이 실제 파일에 매칭되는지 테스트한다.
생성 코드와 벤더 코드는 변경 원본 또는 업데이트 정책의 소유자를 지정한다.

소유자 지정은 지식 독점을 만들 수 있다. 핵심 경로마다 최소 두 명 이상이 리뷰할 수 있게 하고, 장기 휴가·퇴사 때 대체 경로가 있어야 한다.

권장 CODEOWNERS 구조 예시

# 기본 소유자
*                       @org/platform-reviewers

# 빌드·배포와 저장소 정책
/.github/               @org/platform-security
/infrastructure/        @org/cloud-platform
/CODEOWNERS              @org/platform-security

# 민감한 제품 경로
/src/auth/               @org/identity-team @org/security-reviewers
/src/billing/            @org/payments-team
/db/migrations/          @org/data-platform

실제 팀명과 경로는 조직 구조에 맞춰야 한다. 예시를 복사한 뒤 존재하지 않는 팀을 두면 보호가 된 것처럼 보이면서 리뷰 요청이 전달되지 않는다.

관리자 우회는 비상 절차로 다룬다

관리자 우회를 완전히 없애기 어려운 환경도 있다. 우회가 필요하면 다음 조건을 둔다.

구체적 장애·보안 사건 번호
우회할 저장소·브랜치·검사 범위
승인자와 실행자 분리
자동 만료되는 임시 권한
병합 후 사후 리뷰와 누락 검사 재실행
우회 커밋의 운영 배포·롤백 추적
정기 보고와 반복 원인 개선

“CI가 느려서”, “급해서” 같은 상시 사유로 우회가 반복되면 브랜치 보호는 형식적 통제가 된다. 우회율과 원인을 운영 지표로 관리한다.

실패 모드와 탐지 신호

실패 모드	보이는 증상	확인할 항목
CODEOWNERS 미매칭	민감 파일 변경인데 소유자 리뷰 요청 없음	패턴 테스트와 미매칭 경로 보고가 있는가
소유자 권한 없음	리뷰 요청은 가지만 필수 승인이 되지 않음	팀 가시성·쓰기 권한·멤버십이 유효한가
관리자 상시 우회	필수 검사 실패 상태로 병합 증가	우회 권한·이유·만료·사후 검토가 있는가
검사 이름 충돌	승인되지 않은 워크플로 결과로 통과	필수 검사 출처와 앱을 제한했는가
승인 후 코드 변경	리뷰하지 않은 마지막 커밋이 병합	오래된 승인 무효화가 켜져 있는가
병합 직후 기본 브랜치 실패	PR별 테스트는 통과했지만 조합이 깨짐	최신 브랜치 검증·병합 큐가 있는가
규칙 적용 누락 저장소	새 저장소가 기본 정책 없이 생성	조직 규칙셋·자동 인벤토리가 있는가

예시: 워크플로 파일 변경으로 보호 우회

애플리케이션 코드에는 두 명 리뷰가 필요하지만 .github/workflows/release.yml은 일반 플랫폼 팀만 소유한다고 가정하자. 공격자가 워크플로를 바꿔 테스트 결과를 위조하거나 릴리스 비밀을 외부로 보내면 코드 경로의 CODEOWNERS를 건드리지 않고도 공급망을 침해할 수 있다.

방어는 다음을 포함한다.

워크플로와 저장소 설정을 최고 민감 경로로 분류한다.
보안·플랫폼 소유자의 필수 리뷰를 요구한다.
외부 액션을 변경 불가 참조로 고정한다.
포크·비신뢰 입력에서 릴리스 비밀을 사용하지 않는다.
산출물 단계에서 빌더 신원과 프로비넌스를 검증한다.

마지막 항목은 SLSA 프로비넌스와 연결된다. 소스 보호와 산출물 검증이 함께 있어야 한다.

도입 순서

모든 저장소와 기본 브랜치, 운영 배포 여부를 인벤토리화한다.
핵심 저장소와 민감 경로를 분류한다.
현재 직접 푸시·강제 푸시·우회·실패 검사 병합을 관찰한다.
조직 기본 규칙셋을 일반 운영 저장소에 적용한다.
핵심 경로에 CODEOWNERS와 추가 검사를 붙인다.
CI 불안정과 리뷰 병목을 개선한 뒤 차단을 강화한다.
신규 저장소 생성 시 정책을 자동 적용한다.
분기별로 소유자·우회·미매칭 경로를 검토한다.

운영 지표

운영 저장소 중 보호 규칙 적용률
핵심 경로 중 유효한 CODEOWNERS 매칭률
직접 푸시·강제 푸시·삭제·관리자 우회 건수
필수 검사 실패 상태의 병합 또는 예외 수
리뷰 요청부터 첫 응답·승인까지의 시간
승인 후 변경으로 재검토된 비율
불안정한 필수 검사와 수동 재실행 비율
미소유 팀·퇴사자·권한 없는 소유자 수
브랜치 보호 규칙 변경 이벤트와 승인 기록

속도 지표는 보안 통제를 약화하기 위한 것이 아니라 병목을 정확히 고치기 위해 필요하다. 전체 DevSecOps 흐름과 함께 보는 방법은 DevSecOps 지표는 수정 시간을 봐야 한다에서 다룬다.

검수 체크리스트

기본 브랜치 직접 푸시와 강제 푸시가 금지돼 있는가.
필수 검사가 실제 PR 헤드 커밋과 승인된 워크플로에서 왔는가.
새 커밋 뒤 오래된 승인이 무효화되는가.
CODEOWNERS 파일 자체와 워크플로·IaC·인증 경로가 보호되는가.
모든 소유자 팀이 존재하고 리뷰 권한·대체 인력을 갖는가.
관리자·봇 우회가 최소 범위이며 사용 즉시 경보되는가.
신규·포크·보관 저장소에 맞는 기본 정책이 자동 적용되는가.
규칙 변경과 예외가 티켓·만료·사후 검토를 갖는가.

참고 기준

최종 판단

브랜치 보호와 CODEOWNERS는 리뷰를 많이 받기 위한 제도가 아니라 중요한 변경이 승인된 사람과 검사를 거쳐 추적 가능한 방식으로 들어가게 하는 제품 안정성 장치다. 저장소·경로 위험에 따라 규칙을 계층화하고, 관리자 우회와 CI 불안정을 운영 지표로 관리해야 속도와 통제를 함께 개선할 수 있다.

가장 먼저 할 일은 운영 배포가 가능한 저장소 목록과 민감 경로의 실제 소유자를 대조하는 것이다.