코드 리뷰에도 룰이 있다? Pn룰로 리뷰 온도 전달하기

개발자라면 누구나 한 번쯤은 겪어봤을 거예요. 열심히 코드를 작성해서 PR을 올렸는데 리뷰어가 던진 수많은 코멘트에 당황한 적, 있으시죠?

“이건 꼭 수정해야 하는 건가?”, “개인 스타일 차이 아닐까?”, “근데 리뷰어가 고치라 했으니 일단 고치자…”

이런 마음이 들면 어느새 리뷰는 생산적인 토론이 아닌 무조건적인 수정 요청이나 소극적 수용으로 흘러가기 쉬워요.

반대로 리뷰어 입장에서도 어려운 건 마찬가지예요.

“이건 중요한데 너무 강하게 말하면 기분 나쁠까?”, “이건 꼭 반영돼야 하는데…”

이렇듯 코드 리뷰는 결국 사람 간의 커뮤니케이션이라, 애매한 피드백은 리뷰 품질도 낮추고 팀의 개발 문화에도 영향을 미칠 수 있어요. 모두가 바쁜 일정 속에서 “이건 꼭 수정해야 하는가?”에 대한 명확한 의사 전달이 없다면, 리뷰는 그냥 형식적인 절차가 될 수 있어요.

이런 문제를 해결할 수 있는 방법 중 하나가 바로 리뷰 온도, 즉 우선순위를 명확히 전달하는 Pn 룰이에요.

이번 글에서는 제가 회사 팀에서 겪었던 경험을 바탕으로 Pn룰을 도입하게 된 배경, Pn룰의 개념과 예시, 그리고 팀에 Pn룰을 도입한 후 3개월간의 회고를 공유하려고 해요.

Pn룰 도입 배경

최근 제가 속한 팀에서는 PR 병목 현상을 개선하고 리뷰 의사 전달을 명확히 하고자 Pn 룰을 도입했어요. 저희는 하나의 프론트엔드 모노레포를 중심으로 여러 도메인을 동시에 개발하고 있는데, 올해부터 이 모노레포에 많은 프론트엔드 개발자가 투입되면서 PR 수가 급격히 증가했고, 그에 따라 리뷰 속도는 점점 느려졌어요.

PR 하나에 달리는 코멘트 수도 늘어났고, 어떤 피드백이 반드시 반영되어야 하는지, 어떤 건 선택 사항인지를 리뷰어와 작성자 모두 명확히 구분하지 못하는 경우가 발생했죠.

이로 인해 피드백을 둘러싼 불필요한 커뮤니케이션이 오가거나, 리뷰의 "온도" 즉 우선순위를 파악하지 못한 상황이 생겼어요. 저 역시 직접 리뷰어에게 구두로 확인한 적도 있었죠. 결국 이런 문제들이 쌓이면서 리뷰가 지연되고, 처리되지 못한 PR들이 점점 누적되는 PR 병목 현상으로 이어졌어요.

이러한 문제를 해결하고 더 효과적인 코드 리뷰 방식을 찾기 위해 다른 회사들의 코드 리뷰 문화를 조사했어요. 그러던 중 뱅크샐러드 기술 블로그의 "코드 리뷰 in 뱅크샐러드 개발 문화"라는 글을 발견했죠.

이 글에서는 뱅크샐러드 개발 팀이 코드 리뷰 문화 개선을 위한 여러 시도 중 하나로 코드 리뷰의 우선순위를 들어내는 Pn 룰을 소개하고 있었어요. 이 Pn 룰을 통해 코드 리뷰의 우선순위를 명확히 하여 현재 팀의 리뷰 혼선을 줄일 수 있겠다는 생각이 들었죠. 그래서 격주로 열리는 프론트엔드 테크 아고라 시간에 동료들에게 이 Pn 룰을 제안하고 시범적으로 도입하게 되었어요.

Pn 룰의 활용 사례를 좀 더 찾아보니 뱅크샐러드 외에도 우아한형제들, SKT 등 많은 IT 기업들에서 이미 도입하고 있는 규칙 중 하나였어요.

그래서 도입한 Pn 룰은 어떤 것인가?

먼저 이름부터 살펴볼게요.

• P는 Priority(우선순위)의 약자예요.
• n은 우선순위의 레벨(번호)를 의미하는 자연수죠.

즉 코드 리뷰에 명시적으로 P1:, P2:, P3: 같은 우선순위를 붙여서 "이건 반드시 반영되어야 해요", "이건 권장사항이에요.", "이건 선택이에요."와 같은 코드 리뷰의 중요도나 반영 필요도를 명확히 구분하고 전달하기 위한 체계라고 볼 수 있어요.

다만 이 규칙은 공식 표준이 아니라, 팀 상황에 따라 정의되는 일종의 커뮤니케이션 규칙이에요. 참고했던 뱅크샐러드의 Pn 룰은 총 5개의 우선순위로 구분되어 있지만, 제가 속한 팀은 처음 도입하는 상황에서 너무 많은 선택지가 오히려 혼란을 줄 수 있다고 판단해 P1 ~ P3까지 총 3개의 우선순위 구분만 사용하기로 했어요. 그리고 단순 질문을 나타내는 Q를 추가로 포함시켰어요.

Pn 우선순위 설명

P1 ~ P3, Q 규칙의 상세 의미와 Approve 기준은 아래와 같아요.

Pn 룰의 세부 기준은 고정된 것이 아니라, 팀의 상황에 맞게 유연하게 정의해서 사용하면 됩니다.

Pn 룰 예시

실제 React + TypeScript 코드 예시를 바탕으로 P1부터 P3, 그리고 Q에 해당하는 리뷰 코멘트가 어떤 상황에서 쓰일 수 있는지를 살펴볼게요.

PR 코드 예시

// hooks/useCounter.ts
import { useState } from 'react';
 
export function useCounter() {
  const [count, setCount] = useState(0);
 
  const increase = () => {
    count + 1;
  };
 
  const decrement = () => {
    count - 1;
  };
 
  const reset = () => {
    setCount(0);
  };
 
  return { count, increase, decrement, reset };
}

리뷰 코멘트 예시(P1 ~ P3, Q)

P1: 반드시 반영되어야 하는 피드백 (Must)

P1:
현재 `increase`와 `decrement` 함수 내에 `setCount()` 호출이 누락되어 있어 `count + 1`과 `count - 1`에 대한 상태 변경이 반영되지 않고 있어요.
즉,`setCount(count + 1)`과 `setCount(count -1)`로 수정이 필요해요.

P2: 강하게 권장되는 피드백 (Should)

P2: 
`setCount()` 함수 호출 시 에 현재 count 값을 직접 참조하기보다는, React에서 권장하는 `prevState` 콜백 패턴을 사용하는 것은 어떨까요?
특히 비동기 상황이나 상태가 연속적으로 업데이트될 수 있는 경우, `setCount((prev) => prev + 1)` 방식이 버그를 줄이는 데 유리해요.

P3: 선택적으로 반영해도 되는 피드백 (Could)

P3: 
현재 count는 항상 0으로 초기화되는데, 상황에 따라 다른 초기값이 필요할 수도 있으니 `initialValue`를 인자로 받아 설정할 수 있도록 하면 어떨까요?
 
예시 코드
export function useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue);
  ...
}

Q: 설계 의도 질문 및 단순 질문 (Question)

Q:
현재 구조상 count가 음수로 내려갈 수 있는데, 혹시 음수 허용이 의도된 동작일까요?

왜 Pn 룰이 필요한가?

“PR 병목 현상과 Pn 룰 도입 제안”부분에서 이야기 했지만 다시 한번 짚어보면 코드 리뷰의 “온도”, 즉 우선순위가 명확하지 않으면 다음과 같은 문제가 생길 수 있어요.

• PR 작성자 입장에서는
  • “이 리뷰는 꼭 반영해야 하나?”
  • “반영 안 해도 되면 그냥 넘기고 싶은데 괜찮을까?”
• 리뷰어 입장에서는
  • “이건 꼭 수정해야 하는 부분인데 왜 안 고쳤지?”
  • “내 리뷰가 의도보다 너무 더 강하게 느껴지진 않았을까?”
  • “이건 단순 질문인데 수정하라는 무언의 압박을 주는 것처럼 느껴질까?”

이런 해석의 차이가 쌓이면 리뷰의 피로도가 높아지고, 리뷰 대기 중인 PR이 쌓여 결국 PR 병목 현상eh 발생할 수도 있어요. 그래서 이러한 문제들을 해결하기 위해 Pn 룰을 통해 코드 리뷰의 우선순위를 명확히 전달하는 것이죠.

Pn 룰 도입 회고

팀에 Pn 룰을 시범적으로 도입한 지 어느덧 3개월이 지났어요. 얼마 전 회고 시간을 통해 "이 룰이 실제로 도움이 되었는가?"와 "앞으로도 계속 유지할 것인가?"에 대해 팀원들과 함께 이야기를 나눴어요.

결과적으로 팀원 대부분이 "이전보다 의사소통이 훨씬 명확해져서 좋았고, 계속 유지했으면 좋겠다"고 평가했어요. 팀원들의 의견처럼 Pn 룰을 도입한 이후에는 코멘트 앞에 P1:, P2:, P3:처럼 우선순위를 명시함으로써 서로의 의도를 더 빠르고 정확하게 파악할 수 있게 되었어요. 그 결과, 리뷰 병목이 자연스럽게 줄어들었고 리뷰 처리 속도도 향상되었어요. 코드 리뷰 속도가 드라마틱 하게 바뀌었다고 말하긴 어렵지만, 작지만 분명한 긍정적 변화를 팀 전체가 체감할 수 있었어요.

또 하나 논의했던 부분은 Pn의 숫자 범위를 P1 ~ P5로 넓힐지 여부였어요. 결론적으로 P1 ~ P3만으로도 충분하다는 의견이 모였고, 현재 범위를 유지하기로 했어요. 오히려 너무 세분화하면 룰이 복잡해지고 의사 전달력이 떨어질 수 있다는 판단이 컸어요.

정리하자면

• P1 ~ P3만으로도 리뷰 코멘트의 온도 전달이 훨씬 명확해졌어요.
• 서로의 리뷰 의도를 오해하거나 묻는 일이 줄어들었고, 리뷰 병목도 조금 해소됐어요.
• 팀 전체적으로 이 룰을 유지하자는 의견이 많아 지속 적용하기로 했습니다.
• 크게 바뀐 건 아닐지라도, 확실히 리뷰 문화에 긍정적인 변화가 있었어요.

마무리

코드 리뷰는 단순히 잘못된 코드를 지적하는 과정이 아니라, 서로의 관점을 공유하고 함께 더 나은 방향을 찾아가는 협업의 한 방식이라고 생각해요. 그런 점에서 Pn 룰은 리뷰에서 피드백의 우선순위와 의도를 더 잘 전달할 수 있도록 도와준 규칙이였어요.

이 룰을 통해 서로의 리뷰 의도를 오해하는 일이 줄었고, 리뷰 병목도 조금씩 해소되는 긍정적인 흐름을 만들 수 있었어요. 복잡한 규칙 없이도 간단한 체계만으로 리뷰 커뮤니케이션이 더 편해질 수 있다는 걸 느꼈죠.

혹시 여러분도 코드 리뷰를 하면서 "이 코드 리뷰는 꼭 반영하라는 것일까?", "내 리뷰가 너무 날카롭게 느껴질까?" 같은 고민을 해본 적이 있다면, Pn 룰을 가볍게 도입해보는 것만으로도 리뷰 의도와 우선순위를 훨씬 더 명확하게 전달할 수 있을 거예요.

참고 자료

• 뱅크샐러드 블로그 - 코드 리뷰 in 뱅크샐러드 개발 문화
• 우아한 기술 블로그 - 공통시스템개발팀 코드 리뷰 문화 개선 이야기
• DEVOCEAN - 코드 리뷰 문화를 리뷰해 봐요