여러분이 알고 계신 코드 리뷰 규칙이 있으신가요? 개발자들 사이에서 가장 일반적으로 널리 알려진 코드 리뷰 규칙이라고 한다면, 아마도 뱅크샐러드에서 제시한 Pn 룰이 아닐까 생각합니다. 우아한형제들, 당근마켓 같은 큰 규모의 회사에서도 해당 규칙을 적용했다는 사례가 있거든요.
다만 저 같은 경우는 Pn 룰을 사용하고 있지 않습니다. 대신, 제가 2019년부터 유목민(?)마냥 다니는 팀에 전파시키는 코드 리뷰 규칙이 있습니다. 바로 이모지 기반의 코드 리뷰 방식 입니다.
사실 이러한 방식이 기존에 없던 완전히 새로운 규칙은 아닙니다. 마이크로소프트를 비롯해 일부 해외 회사에서는 이모지 기반의 코드 리뷰를 적용한 사례가 있습니다. 다만 국내에서는 코드 리뷰 규칙을 검색하면 Pn 룰 외에는 다른 규칙을 찾기 어려웠습니다.
널리 알리고 싶어서 리포지토리도 팠다. 스타 좀 눌러주세요…
그래서 저는 제가 사용 중인 코드 리뷰 규칙을 한국에도 더 널리 소개하고 싶었습니다. 그런 의미에서 코드 리뷰 규칙을 오픈소스로 만들어 공개했고, 이를 소개하고자 오늘의 포스트를 작성하게 되었습니다.
이번 포스트를 통해 이모지 기반의 코드 리뷰 규칙이 궁금하신 분 들께 도움이 되었으면 좋겠습니다.
아래에서 설명하는 내용은 cremoji의 깃허브 저장소에서도 확인하실 수 있습니다.
cremoji
do your code review with emoji!
우선 제가 설명할 이모지 기반의 코드 리뷰 규칙은 cremoji(크리모지) 라는 이름을 붙였습니다. 이 네이밍은 Code Review with Emoji 의 줄임말로, git 커밋의 성격을 이모지로 분류하는 gitmoji 로부터 영감을 받았습니다.
도입 배경
코드 리뷰 시 달리는 코멘트의 성격을 명시적으로 구분하여, 리뷰어와 리뷰이의 혼란을 줄이자.
코드 리뷰는 코드를 검토받고자 하는 리뷰이(reviewee), 그리고 코드를 검토하는 리뷰어(reviewer) 가 서로 커뮤니케이션하며 진행됩니다. 이를 통해 팀 내 코드베이스의 품질을 일정 수준 이상으로 유지하고, 개발자 간의 지식 공유를 할 수 있으며 미처 생각하지 못한 버그를 배포 전에 찾아낼 수 있습니다.
다만 이것은 이상적인 경우이고, 실제로 업무를 하다 보면 코드 리뷰를 남기거나 반영하기 부담스러운 경우를 종종 만납니다.
- 리뷰어와 리뷰이가 각자 효율적이라고 생각하는 코드가 다를 수 있음
- 배경 지식의 차이로 인해 서로의 코드를 이해하지 못할 수 있음
- 리뷰어가 남긴 리뷰를 리뷰이는 공격적이라고 느낄 수 있음
- 리뷰이의 방어적 태도로 인해 리뷰어가 리뷰를 달기 부담스러움
- 자신이 남긴 코드 리뷰가 리뷰이에게 상처를 줄까 걱정됨
이러한 문제가 발생하는 원인은 결국 코드 리뷰가 텍스트를 기반으로 의견을 주고받기 때문입니다. 똑같은 내용을 전달하더라도 오프라인으로 만나 얼굴을 보며 하는 대화보다 텍스트로만 전달되는 코드 리뷰는 감정이나 의도가 불분명하게 전달된다는 점에서 더욱 냉소적이고 공격적으로 받아들여질 수 있죠.
이 때문에 코드 리뷰에 참여하는 개발자들이 갖추어야 할 태도에 대해서도 포스트를 작성하기도 했었는데요, 저는 이것보다 조금 더 시스템적 방법으로 문제를 해결할 수는 없을까 생각했습니다.
그러다가 코드 리뷰 시 작성하는 코멘트의 성격을 명시적으로 구분한다면 불필요한 감정 소모를 줄이고 의견을 효과적으로 전달할 수 있겠다고 생각했고, 이모지 기반의 코드 리뷰 규칙인 cremoji를 도입했습니다.
적용 방법
코멘트 작성 시 이모지 작성 후 한 칸 띄우고 내용 작성
리뷰어는 사전에 정의된 이모지를 코멘트의 제일 앞에 붙여서 코드 리뷰를 남기면 됩니다. 그러면 리뷰이는 해당 코멘트의 성격을 이해하고 적절한 대응을 할 수 있습니다.
이모지 목록
코드 리뷰 상황에서 만나게 되는 상황의 다섯 가지 유형을 표준화했다
사실 사용할 이모지의 목록은 딱히 정해진 표준이 없기 때문에 팀이나 조직 구성원들이 자유롭게 정할 수 있습니다. 다만 cremoji에서는 코드 리뷰에서 자주 맞닥뜨리는 상황을 고려하여 다음과 같은 다섯 개의 이모지를 제안합니다.
따봉 (👍)
코드 리뷰에서 칭찬을 아끼지 말자
따봉(:+1:)은 리뷰어가 리뷰이의 코드에서 칭찬의 의견을 남기고 싶을 때 사용합니다.
코드 리뷰 과정에서 부족한 부분을 찾아내는 것도 중요하지만, 잘한 부분에 대해 칭찬을 적극적으로 남기는 것도 중요합니다. 따봉 이모지는 이러한 칭찬의 의견을 남기기 위해 사용됩니다. 사소한 것이라도 좋으니 여러분의 동료에게 칭찬을 아끼지 말고 표현해 주세요!
느낌표 (❗)
느낌표는 수정이 반드시 필요한 경우에 사용하고 근거를 명확히 설명한다
느낌표(:exclamation:)는 리뷰어가 리뷰이에게 필수적으로 코드 수정을 요청할 때 사용합니다.
필수적인 수정을 요청하는 경우로는 다음과 같은 예시들이 있을 것 같은데요.
- 기획에서 의도한 것과 다른 결과를 일으키는 코드인 경우
- 성능이나 보안 상 명백히 개선이 가능한 코드인 경우
- 규칙으로 정해진 팀 컨벤션을 따르지 않는 코드인 경우
즉, 이 코드는 문제를 일으키는 것이 확실하거나 팀에서 추구하는 가치와 일치하지 않는 경우에만 사용합니다. 따라서 느낌표 코멘트를 작성하는 경우라면 리뷰어는 링크나 레퍼런스를 통해 이렇게 의견을 남긴 근거를 명확히 설명할 수 있어야 합니다.
그러므로 리뷰어가 리뷰를 제출할 때 느낌표 코멘트가 하나라도 포함되어 있다면 Request changes 로 제출을 해야 합니다.
물음표 (❓)
물음표(:question:)는 리뷰어가 리뷰이의 코드에서 이해하기 어려운 부분을 질문할 때 사용합니다.
리뷰어와 리뷰이는 경력, 기술 스택, 문제에 대한 맥락 이해도와 같이 다양한 요소에 의해 배경 지식이 다를 수 있습니다. 이러한 이유로 리뷰어가 리뷰이의 코드를 이해하기 어려운 부분이 있을 수 있는데요, 이런 경우에는 물음표 코멘트를 남겨서 리뷰이에게 질문을 하거나 불명확한 부분에 대한 추가 설명을 요구할 수 있습니다. 물론 이때 리뷰어는 질문의 의도와 이유를 명확히 설명해야 하겠죠.
만약 물음표 코멘트에 대한 답변이 리뷰 결과에 영향을 주지 않는다면, 바로 Approve 로 제출해도 됩니다.
하지만 답변의 결과가 리뷰 결과에도 영향을 주는 경우라면, 답변을 듣기 전에는 먼저 Comment 상태로 제출합니다. 만약 답변의 내용이 추가 수정을 필요로 한다면 느낌표 코멘트를 덧붙이면서 Request changes 를 제출합니다. 그 외의 경우에는 Approve 를 제출하여 궁금증이 해소되었다는 의견을 명확히 남기는 것이 좋습니다.
알약 (💊)
알약(:pill:)은 리뷰어가 리뷰이의 코드에서 개선된 방법을 제안하지만 그것의 반영이 필수까지는 아닐 때 사용합니다. 구글의 코드 리뷰 가이드에서는 이러한 행위를 NIT(nitpick, 트집 잡기) 라는 용어로 부르기도 하죠.
내가 생각하기엔 이게 더 나은 것 같지만 선택은 너의 몫으로 넘기겠다
제가 NIT 이모지를 알약으로 고른 이유는… 사실 영화 매트릭스의 패러디입니다. 리뷰어가 더 낫다고 생각하는 방법을 제안하지만, 그것을 반영할지는 리뷰이의 판단에 맡긴다는 것이죠.
Pn 룰에서는 이러한 반영 강조 레벨을 다섯 단계로 나누지만, cremoji에서는 제안 반영 여부를 온전히 리뷰이의 판단에 맡깁니다. 만약 필수적인 수정이 필요한 경우는 느낌표 코멘트를 사용하면 되고, 의견을 좀 더 들어보고 결정하고 싶은 경우에는 물음표 코멘트를 사용하면 됩니다. 리뷰이는 알약 코멘트에 대해서만 제안을 반영할지 말지 결정하면 됩니다.
따라서 리뷰어가 리뷰를 제출할 때, 알약 코멘트가 있더라도 Approve 를 해야 합니다.
말풍선 (💬)
말풍선(:speech_balloon:)은 이전에 언급된 경우 외에 리뷰어가 단순히 개인의 감상이나 의견, 여담을 남거나 공유하고 싶을 때 사용합니다.
리뷰 과정에서 잡담 같은 것을 남길 때 사용해도 되고, 내가 이 코드를 보고 떠오른 생각을 혼잣말하듯이 남길 때 사용합니다.
따라서 말풍선 코멘트는 리뷰 제출 상태에는 어떠한 영향도 주지 않아야 합니다.
코드 리뷰 제출
리뷰에서 작성한 코멘트 종류에 따라 내 의견 상태를 명확히 표시할 수 있다
리뷰어가 코드 리뷰를 제출할 때 앞서 작성한 코멘트 종류에 따라 내 의견 상태를 명확히 표시할 수 있습니다.
- Comment: 질문 코멘트의 답변이 리뷰 결과에 영향을 주는 경우로, 답변을 듣기 전까지 의견 표명을 보류할 때 사용합니다.
- Request changes: 느낌표 코멘트가 하나라도 포함되어 있다면 Request changes 로 제출합니다.
- Approve : 위의 경우가 아니라면 Approve 로 제출합니다.
권장 사항
지금까지 간단한 cremoji의 규칙에 대해 설명했는데요, 이 규칙을 사용할 때 권장되는 사항에 대해 알아보겠습니다.
자주 쓰는 답변
깃허브 개인 프로필 페이지에 가면 자주 쓰는 답변을 등록할 수 있다
위의 이모지를 입력하기 위해 매번 :이모지: 를 찾아 입력하는 것은 너무 번거로운 일입니다. 그래서 깃허브에서 제공하는 자주 쓰는 답변 기능에 이모지를 등록해두고 사용하는 것을 권장합니다.
저 같은 경우 제목에는 간단한 식별 문자를, 본문에는 이모지를 입력해 두고 사용하고 있는데요, 이렇게 하면 아래처럼 사용할 수 있습니다.
코드 리뷰 시 코멘트 입력창 우측 상단에 보면 saved replies 버튼이 보이는데, 이 버튼을 클릭하면…
이렇게 이모지 선택 창이 나타납니다. 클릭 시 자동으로 이모지가 입력되니 편리하게 사용할 수 있습니다.
이모지 개수 제한
gitmoji에서 사용하는 이모지의 일부. 종류가 너무 많아서 찾아봐야 할 때가 많다는 게 흠이다.
팀과 조직의 상황에 따라 이모지를 자유롭게 추가하고 편집해 사용하는 것은 가능합니다만, 너무 많은 이모지를 사용하면 오히려 혼란을 야기할 있다는 점을 유의해야 합니다.
인지과학에 따르면 우리가 뇌에서 단기 기억할 수 있는 정보의 양은 두 개에서 여섯 개 사이밖에 되지 않는다고 합니다. 따라서 cremoji를 처음 도입할 때에는 다섯 개의 이모지로 시작하는 것을 권장하며, 추후 필요에 따라 추가하거나 수정하는 것이 좋습니다.
적용 후기
요약표
저는 cremoji를 5년째 사용 중인데 꽤 만족하며 사용하고 있습니다. 규칙도 간단하고, 도입한 이후로 코드 리뷰 과정에서 모호함과 불필요한 감정 소모가 많이 줄었음을 느꼈거든요.
리뷰이 입장이 된 경우에서는 리뷰어의 의견이 명확하게 명시되어 있어서 오해나 혼란의 여지가 많이 줄었습니다. 느낌표가 아니라면 제안의 반영 여부가 나에게 달려있기 때문에 리뷰 반영에 대한 모호함과 부담도 적어졌습니다.
반대로 리뷰어 입장에서는 기준에 맞게 내 의견을 구조적으로 전달할 수 있다는 점, 이모지를 사용함으로써 리뷰이에게 더 쉽게 의견을 전달할 수 있다는 점이 좋았습니다.
단점이라고 한다면… 매 코멘트마다 이모지를 고르는 약간의 번거로움(?)이 있다는 것, 그리고 이모지를 사용하는 것이 익숙하지 않은 사람들에게는 적응 기간이 필요하다는 점이 있을 것 같네요.
하지만 이러한 단점에도 불구하고 만약 팀에 코드 리뷰 규칙이 없는 경우에는 한 번 시도해 보는 것을 추천드립니다. 관심이 있으신 분이라면 cremoji의 깃허브 저장소를 방문해 한 번 팀원들에게 공유해 보세요!
