[Code Review] RCA 룰 (혹은 Pn 룰)

스뎅(thDeng) on February 18, 2025

코드리뷰 코멘트의 뉘앙스

온라인으로 글을 쓰면서 일을 하다 보면 뉘앙스가 전달되지 않아서 오해를 사거나 의도가 충분한 전달이 되지 않는 경우가 많다. 같은 온라인이어도 글이 아닌 미팅콜을 진행하면 목소리나 표정에서 전달하는 사람의 의도가 보이는 경우가 있는데, 글은 그런 것이 없어서 읽는 사람의 의도대로 읽히게 된다. 전달자의 의도가 아닌 받아들이는 사람의 의도로 전달이 되는 것이다.

코드리뷰에 이런 코멘트가 있다고 생각해 보자.

ID는 왜 문자가 아니라 숫자인가요?

문자여야 하는데 숫자로 잘못 적은 것이라는 뜻인지 그저 숫자인 이유가 궁금해서 물어본 것인지 알기 어렵다.

코드리뷰를 주고 받다 보면 반영해도 좋고 그냥 넘어가도 좋은 내용으로 적거나 사소한 의견이었는데, 있는 시간 없는 시간 다 쪼개서 열과 성을 다해 반영해 주는 것을 보는 경우가 있다. 속으로는 ‘아니 그 정도로 강하게 말한 것은 아닌데..’라고 외치지만.. 또는 반대로 이것은 꼭 반영해 달라고 코멘트를 달았는데, 무시하고 머지하는 경우도 있다.

이런 눈에 보이지 않는 코멘트 강도를 코드리뷰 내용과 함께 적는 방법이 있다.

RCA 룰

R(Request Changes)
- 꼭 반영해 주거나 적극적으로 검토해 주세요
- MR에 R이 하나라도 남아 있으면 머지를 할 수 없음
- Pn룰의 P1, P2에 해당
C(Comment)
- 왠만하면 반영해 주세요
- Pn룰의 P3에 해당
A(Approve)
- 이 부분의 변경사항은 승인이고, 이건 그냥 단순한 의견이에요
- 칭찬도 여기에 해당
- Pn룰의 P4, P5에 해당

예를 들면, 아래처럼 코멘트를 남긴다.

A) ID는 왜 문자가 아니라 숫자인가요?

이 내용은 코드의 변경 사항이나 방향성에는 큰 이견은 없고 그저 궁금해서 물어보는 것임을 느낄 수 있다. 똑같은 의미를 아래처럼 적는다면? 전혀 다른 의미가 된다.

R) ID는 왜 문자가 아니라 숫자인가요?

사실 이건 싸우자는 느낌이고, 제대로 코멘트를 남긴다면 이렇게 쓰지 말고 어떻게 바뀌면 좋겠다거나 다른 표헌으로 말을 다듬는 것이 먼저일 것이다.

현재 팀에서는 이 RCA 방식을 사용한다. 아래에 함께 소개한 Pn룰을 잠깐 시범삼아 사용해 봤는데 각 단계의 의미를 외우는데 어려움이 있었다. 코멘트를 남기며 “이 내용이 P4가 맞나? P5가 맞나?”, 코멘트를 보면서는 “P2가 꼭 반영해 달라는 것이었나? 왠만하면 반영해 달라는 것이었나?” 헷갈린다. 룰이라는 것은 사용하기 쉽고 편해야 자주 쓰게 되고 지키게 되는데, Pn룰은 선택지가 많아서 그런지 단계를 선택하는데 고심을 하게 되고 신경을 많이 쓰게 되어서 불편했다.