주 브랜치에 어떤 조건을 만족해야 합칠 수 있는지를 저장소 설정으로 강제하는 것.
왜 파이프라인만으로는 부족한가
파이프라인은 검사 결과를 알려 줄 뿐이다. 빨간불이어도 합치기 버튼은 눌린다. 급할 때 한 번 그냥 합치면, 그 다음부터는 그것이 선례가 된다.
보호 규칙이 없는 파이프라인은 권고다. 규칙을 걸어야 비로소 "통과해야 합쳐진다" 가 성립한다.
무엇을 거나
- 필수 상태 체크 — 지정한 워크플로가 성공해야 합칠 수 있다
- 리뷰 승인 수 — 최소 몇 명이 승인해야 하는가
- 최신 상태 요구 — 주 브랜치의 최신 커밋을 반영한 뒤 검사를 통과해야 한다
- 강제 푸시·삭제 금지 — 이력을 되돌리는 것을 막는다
- 관리자에게도 적용 — 이것을 빼면 규칙이 아니라 권장이 된다
최신 상태 요구가 잡는 것
A 와 B 가 각각 통과했는데 합치면 깨지는 경우가 있다. 서로 상대의 변경을 모르고 검사받았기 때문이다. 최신 상태를 요구하면 나중 것이 앞 것을 반영한 뒤 다시 검사받는다.
대신 대기 줄이 생긴다 — 하나 합칠 때마다 나머지가 다시 돌아야 한다. 팀이 크면 이 비용이 커서, 여러 PR 을 묶어 한 번에 검증하는 병합 큐 방식으로 넘어간다.
짧게 사는 브랜치와 짝이다
보호 규칙은 주 브랜치를 지키는 장치이므로, 브랜치가 길게 살면 규칙이 지켜져도 통합 문제는 그대로 남는다. 2주짜리 브랜치가 마지막 날 모든 검사를 통과해 합쳐지면, 그 검사는 2주 만에 처음 돌아 본 것이다.
그래서 실무에서는 셋을 함께 건다.
- 브랜치 수명 제한 — 하루 이틀 안에 합칠 크기로 자른다
- PR 크기 제한 — 리뷰가 가능한 크기여야 리뷰가 실제로 이뤄진다
- 자동 삭제 — 합친 브랜치는 지워 목록이 실제 작업만 남게 한다
코드 소유자 지정
# .github/CODEOWNERS
/infra/** @platform-team
/src/payment/** @payment-team
경로별로 리뷰어를 자동 지정한다. 인프라나 결제처럼 잘못되면 비싼 영역에 해당 팀 승인을 강제하는 용도다. 지식이 있는 사람에게 리뷰가 가도록 만드는 구조적 장치다.
검사는 강제하되 우회로는 남긴다
장애 상황에서 파이프라인이 통째로 멈춰 있으면 긴급 수정도 못 나간다. 그래서 우회 자체를 없애기보다 우회에 흔적이 남게 한다 — 누가 언제 무슨 이유로 규칙을 건너뛰었는지 기록되면, 예외는 남되 습관이 되지는 않는다.
규칙을 너무 조이면 사람들은 규칙을 없애는 대신 규칙을 우회하는 문화를 만든다. 그편이 훨씬 나쁘다.
흔한 함정
paths 필터로 실행을 건너뛰는 워크플로를 필수 체크로 지정하면 PR 이 영원히 대기한다. 건너뛴 검사는 성공이 아니라 결과 없음이라, 조건이 영원히 충족되지 않는다.
우회는 정해져 있다 — 해당 경로가 아니면 즉시 성공하는 더미 잡을 두어, 검사가 항상 결과를 내도록 만든다.
면접 함정
- ❌ "CI 를 붙였으니 품질이 강제된다" → 보호 규칙이 없으면 무시할 수 있다.
- ❌ "관리자는 예외로 두는 게 편하다" → 예외가 있는 규칙은 사고 시점에 정확히 그 경로로 뚫린다.
- ❌ "각 PR 이 통과했으면 합쳐도 안전" → 서로를 모르고 검사받았을 수 있다.