작은 PR 원칙이 무너진 이유
오랫동안 백엔드 개발 팀에서 금과옥조처럼 여겨온 원칙이 있다. "PR은 작게 유지하라." 리뷰어가 집중할 수 있고, 머지 충돌도 줄어들며, 롤백도 쉬워진다는 논리였다. 그런데 인시던트 관리 플랫폼 Rootly가 이 원칙을 공식적으로 폐기했다고 발표했다. 이유는 단순하다. 코드 리뷰의 경제학 자체가 달라졌기 때문이다.
Rootly가 지적한 핵심은 PR 크기(라인 수)라는 지표가 품질이나 위험도를 제대로 반영하지 못한다는 점이다. 100줄짜리 PR이라도 핵심 결제 로직을 건드린다면 위험하고, 1,000줄짜리 PR이라도 독립적인 유틸리티 모듈 추가라면 상대적으로 안전하다. 라인 수는 편의상의 프록시 지표였을 뿐, 본질적인 안전 지표가 아니었던 것이다.
블래스트 레디어스 중심으로의 전환
Rootly가 대안으로 제시한 개념은 블래스트 레디어스(blast radius), 즉 변경이 실패했을 때 얼마나 넓은 범위에 영향을 미치는가이다. 이 관점에서 코드 리뷰의 핵심 질문은 "이 PR이 몇 줄인가?"가 아니라 "이 변경이 터졌을 때 어디까지 망가지는가?"로 바뀐다.
실무적으로 이 전환은 다음과 같은 체크리스트를 의미한다.
- 피처 플래그(feature flag)로 격리되어 있는가? 변경 사항을 특정 사용자 또는 환경에만 노출할 수 있어야 한다.
- 롤백 경로가 명확한가? 데이터 마이그레이션, 외부 API 계약 변경 등 롤백이 불가능한 요소가 포함되어 있는지 확인한다.
- 영향 범위가 서비스 경계 내에 한정되는가? 다운스트림 시스템에 전파되는 변경인지 여부가 중요하다.
// 피처 플래그로 블래스트 레디어스를 제한하는 예시
if (featureFlags.isEnabled("new-payment-flow", userId)) {
return newPaymentService.process(request);
}
return legacyPaymentService.process(request);
위처럼 피처 플래그로 감싼 변경은 PR 크기와 무관하게 블래스트 레디어스를 최소화할 수 있다.
실무에서 이 원칙을 어떻게 적용할 것인가
PR 리뷰 문화를 바꾸는 것은 쉽지 않다. 특히 "작은 PR"은 이미 많은 팀에서 코드 리뷰 가이드라인에 명문화되어 있기 때문이다. 그러나 Rootly의 사례는 지표(metric)보다 의도(intent)에 집중해야 한다는 교훈을 준다.
실질적인 전환 방법으로는, PR 템플릿에 라인 수 대신 "이 변경의 롤백 전략은 무엇인가", "영향을 받는 서비스/모듈은 어디인가" 같은 항목을 추가하는 것이 효과적이다. 또한 피처 플래그 인프라가 갖춰져 있지 않다면, 대규모 변경을 안전하게 배포하기 위한 전제 조건으로 이를 먼저 구축하는 것이 우선순위가 된다.
# 배포 체크리스트 예시 (PR 설명에 포함)
blast_radius:
affected_services: [payment-service]
downstream_impact: none
rollback_strategy: feature-flag-disable
data_migration: false
정리
- PR 크기(라인 수)는 위험도의 프록시 지표일 뿐이며, 블래스트 레디어스가 더 실질적인 평가 기준이다.
- 피처 플래그와 롤백 가능성이 확보된 변경은 크기와 무관하게 안전하게 배포할 수 있다.
- PR 리뷰 프로세스를 개선할 때 라인 수 제한보다 영향 범위와 격리 전략을 체크하는 방향으로 전환을 검토하라.