정책을 차단하지 않고 적용하는 방법 (Hotfixes)

Source: Dev.to

핫픽스의 특성

• 긴급 – 이미 프로덕션에 영향을 미치고 있음.
• 작음 – 시스템을 재설계하는 것이 아니라 출혈을 멈추는 것이 목표.
• 고위험 – 압박 속에서 라이브 시스템을 건드림.
• 고영향 – 한 줄의 변경이라도 수천, 수백만 명의 사용자에게 영향을 줄 수 있음.

많은 팀이 여전히 수 주간의 컨텍스트가 필요한 대규모 기능 PR에 동일한 규칙을 적용하고, 새벽 2시의 한 줄 프로덕션 수정을 사고 상황에서 진행한다. 이 불일치는 마찰을 만들고 결국 정책 위반으로 이어진다.

“체크 건너뛰기 태그” 안티패턴

대부분의 조직이 이 고통을 겪으며 흔히 사용하는 우회 방법이 skip-ci, emergency, hotfix와 같은 수동 태그를 도입해 필수 체크를 비활성화하는 것이다. 이러한 태그는 보통 선임 엔지니어에게만 알려진 비공식 관행이다.

문서상으로는 속도가 빨라 보이지만, 실제로는 정책이 조용히 침식되는 현상이다.

체크를 건너뛰는 것이 일상이 되면:

• 책임감이 감소
• 감사가 어려워짐
• 보안 팀이 CI 신호에 대한 신뢰를 잃음
• “긴급”이 예외가 아니라 습관이 됨

문제는 속도를 원하는 것이 아니라, 태그가 가드레일을 재구성하지 못하고 오히려 제거한다는 점이다.

2단계 파이프라인 체크

현대 엔지니어링 시스템은 Git 기반 워크플로우에 의존하며, 심지어 핫픽스도 필수 체크가 적용된 Pull Request(PR)를 통해 흐른다. 긴급 수정을 차단하지 않기 위해 많은 조직이 검증을 두 단계로 나눈다:

Pre‑merge Checks

빠르고 가벼운 체크로, 변경 사항이 즉시 테스트를 깨뜨리거나 기본 정책을 위반하지 않는지 확인한다.

Pre‑checkin

Pre‑merge Checks가 통과하면 개발자는 Pre‑checkin 단계로 진행한다. Pre‑checkin이 성공하면 PR이 자동으로 머지되어 수동 지연 없이도 모든 핫픽스가 통제되고 감사 가능한 경로를 따르게 된다.

대부분의 기업에서 변경을 머지하려면 Pre‑merge checks와 Pre‑checkin checks 두 가지를 모두 통과해야 한다. 핫픽스의 경우 Pre‑merge checks를 Rulesets 혹은 branch protection rules를 활용해 더 신뢰성 있게 만들 수 있다.

좋은 핫픽스 Ruleset 예시

• Pull request는 여전히 필수(직접 푸시 금지)
• 적고 빠른 필수 체크(유닛, 스모크, 시크릿 스캔)
• 승인 필요하지만 on‑call / 릴리즈 담당자에게만 제한
• 강제 푸시 여전히 차단
• 우회 권한은 매우 소수 그룹에만 부여되고, 항상 로그에 기록