공격적이던 코드 리뷰 문화를 바꾼 방법: P-N Rule 도입기

코드 리뷰는 팀의 기술 품질을 지키는 중요한 과정입니다.
하지만 리뷰 방식이 적절하지 않으면, 리뷰 자체가 팀 분위기를 해칠 때도 있습니다.
처음 리뷰 시스템을 도입했을 때가 그랬습니다. 리뷰는 활발했지만 피드백의 어조가 불필요하게 날카롭거나 단정적이었습니다.
의도와는 달리 리뷰 요청자에게 부담을 주고, 리뷰어 역시 조심스럽게 표현해야 하는 상황이 반복됐습니다.

문제의 핵심: “왜?”가 빠진 피드백

리뷰의 내용 자체는 대부분 타당했습니다.
하지만 근거 없이 단정적으로 말하는 표현은 같은 내용이라도 공격적으로 느껴지기 쉬웠습니다.

• “이렇게 하면 안 됩니다.”
• “이 구조는 이상하네요.”
• “이건 전체적으로 고치셔야 합니다.”

코드에 대한 의견인데도, 사람을 지적받는 것처럼 받아들이게 되는 상황이 잦았습니다. 그 결과 리뷰 요청에 부담이 되고, 리뷰 과정도 자연스레 소모적인 일이 되었습니다.

해결을 위한 기준: P-N Rule

이 문제를 해결하기 위해 팀에서는 리뷰 강도와 필요도를 명확히 구분하는 P-N Rule을 도입했습니다. 접두사(P1, P2)를 통해 피드백의 목적과 무게를 분명하게 전달하는 방식입니다.

P1: 반드시 변경이 필요한 사항 (Request changes)

다음과 같은 경우에 사용했습니다.

• 서비스에 오류를 유발할 가능성이 있는 경우
• 시스템 전체에 부정적 영향을 줄 수 있는 경우
• 보안·성능·데이터 무결성과 같은 핵심 요소와 직결되는 경우

P1은 즉각적인 수정이 필요한 만큼, 개발자는 변경 후 재리뷰를 요청해야 합니다.

P2: 권장되는 변경 사항 (Suggestion)

비즈니스 로직에는 직접적인 영향을 주지 않지만, 다음과 같은 개선이 가능한 경우입니다.

• 가독성 향상
• 코드 품질 개선
• 더 나은 패턴이나 일관성 확보

P2는 개발자가 선택적으로 반영할 수 있는 의견입니다.

P3: 그 외 피드백 (Optional)

P1이나 P2에 해당하지 않는 피드백도 많습니다.

• 참고용 코멘트
• 질문
• 의견 교환을 위한 논점 제시

이런 내용들은 별도의 접두사 없이 자연스럽게 남기되, P1/P2와 혼동되지 않도록 명확하게 구분했습니다.

규칙 하나가 만들어낸 변화

P-N Rule은 복잡하지 않은 규칙이지만 적용 이후 팀의 리뷰 문화는 뚜렷하게 개선되었습니다.

1) 리뷰어가 자연스럽게 근거를 설명하게 됨

P1인지 P2인지 구분하기 위해서는 이유가 필요했습니다.
그렇다 보니 리뷰어는 자연스럽게 배경을 설명하게 되었고, 공격적인 표현은 자연스럽게 사라졌습니다.

예)
“이 부분은 concurrency 이슈가 발생할 수 있어 P1입니다.”
“가독성 측면에서는 이 방향이 더 좋아 보여 P2로 제안드립니다.”

2) 리뷰 요청자의 심리적 부담 감소

피드백의 강도가 명확해지니 방어적인 태도가 줄었습니다.
반드시 고쳐야 하는 이유가 있는지(P1), 아니면 선택할 수 있는 개선안인지(P2)가 명확하게 구분되기 때문입니다.
결과적으로 리뷰 과정이 훨씬 건설적으로 변했습니다.

3) 코드 기준이 빠르게 정립됨

P1/P2를 구분하며 논의하는 과정이 반복되면서, 팀 내 기술 기준이 빠르게 정리되었습니다.
새로 합류한 팀원도 리뷰 문화를 이해하는 데 어려움이 줄었습니다.

마무리

P-N Rule은 단순한 규칙이지만, 리뷰 문화를 개선하는 데 충분했습니다.

• 피드백 기준이 명확해지고
• 표현 방식이 부드러워졌으며
• 팀의 기술적 일관성과 사고력이 높아졌습니다

결국 좋은 리뷰는 명확한 기준과 존중을 바탕으로 만들어진다는 사실을 다시 한 번 확인할 수 있었습니다.