코드 리뷰를 어떻게 하는 게 좋을까?

안녕하세요. SmartStudio 이경일 입니다.

요즘엔 문화가 좋다고 자부하는 IT 개발 조직에서 개발 문화 이야기를 할 때 빠지지 않는 이야기 중 하나는 코드 리뷰 같습니다.

이 글은 ‘코드 리뷰를 어떻게 하면 좀 더 잘 할 수 있을까?’라는 주제로 제가 고민하고 생각했던 내용을 정리해 봤습니다. 코드 리뷰를 하시는 분들께 도움이 되었으면 좋겠습니다.

코드 리뷰는 꼭 필요할까요?

우리 팀은 코드 리뷰 문화가 정말 좋습니다.

정말인가요?

개발 문화로서 코드 리뷰는 개발 조직의 문화를 측정할 수 있는 빠질 수 없는 척도 중 하나로 현실적으로 코드 리뷰를 하지 않는 조직이 아직도 더 많기 때문에 그 조직의 개발 문화를 파악하는 좋은 척도로서 받아들여지고 있습니다.

출처: http://asciiville.com

그저 그냥저냥 코드 리뷰를 한다고 해서
정말 좋은 개발 문화라고 말할 수 있을까요?

코드 리뷰는 왜 하는 것일까요?

Bus Factor라는 용어가 있습니다. 일종의 하이 리스크를 측정하는 용어 중 하나로, 같이 프로젝트를 하는 팀원 중 한 명이 버스에 치여서 병원에 입원(사망을)을 해서 프로젝트에 참여하지 못했을 때 그 프로젝트에 위기가 오느냐 오지 않느냐를 측정하는 위험도 수치를 말합니다.

출처: Ganesh Shankar Medium

Bus Factor가 낮다는 이야기는 프로젝트 내 특정인에게 모든 정보가 많이 쏠려 있고 공유가 잘되지 않는다는 이야기로 프로젝트 진행의 리스크가 매우 높아지게 됩니다.

조직에서 Bus Factor 값을 높이기 위해서 하는 활동 중 하나가 코드 리뷰라고 이야기는 합니다만…

우리가 Git 협업 도구의 Pull Request를 통해 보는 코드는
일부 코드의 조각일 뿐이다.

우리가 Pull Request로 진행하는 단편적인 코드 리뷰는 많이 부족합니다.

Pull Request 진행 시 보이는 코드의 조각

코드 리뷰를 진행할 때는 전체적인 맥락을 봐야 하는데 Pull Request의 경우 코드의 조각만 보이기 때문에 전체적인 구조를 파악하기에는 매우 부족합니다.

이런 경우 거의 Coding Convention 종류의 코드 리뷰만 진행이 되기도 합니다.

코드 리뷰는 버그를 사전에 차단하기 위해서 진행한다.

코드 리뷰는 버그를 사전에 차단할 수 있긴 합니다.
저도 지금까지 코드 리뷰를 통해서 버그를 사전에 차단해 본 사례가 몇몇 있습니다만 흔한 상황은 아닙니다.

사실 별로 큰 영향은 없습니다.

일반적으로 Pull Request를 통해 Git 협업 도구로 코드 리뷰를 하곤 합니다.

위에서 이야기했던 것처럼 Pull Request의 코드 리뷰의 경우 코드의 조각을 리뷰하는데 이 정도로 보이는 버그라면 정말 치명적이거나, 황당한 실수일 가능성이 높습니다. (이것도 큰 의미가 있겠지만요…)

코드 리뷰는 때로는 제품 출시의 병목이 됩니다.

조직에 따라 다르지만 어떤 Repository의 경우에는 리뷰어 2명이 승인을 해야만 소스를 머지 할 수 있는 제약조건이 존재하긴 합니다.

개발자는 항상 바쁩니다. 만약 팀원들이 지금 다들 엄청 바쁘다면 어떻게 될까요?

Pull Request의 승인이 느려지게 되면 제품 출시가 그만큼 느려지게 된다는 소리로 제품의 빠른 출시가 장점인 MSA 방식에서도 좋은 방식이 아닙니다.

의미 없는 승인.

일단 Pull Request가 올라오면 영혼 없이 무조건 LGTM!! 하며 승인을 누르게 되는 케이스도 생깁니다.

물론 오랜 시간 같이 일해서 신뢰하기에 발생하는 케이스도 있다고 생각합니다.

하지만 코드의 조각을 보다 보면 전체적인 그림을 보기 힘드니 단면적인 코드만 보고 문제없다고 생각하고 승인을 누르곤 하죠.

가끔 싸움도 납니다.

개발자들은 때때로 본인이 작성한 코드에 몰입을 하게 되고 코드와 나를 일체화 시키곤 합니다. 따라서 Pull Request에서 코드에 관한 의견이 본인에 관한 공격이나 비판이라고 여길 수도 있습니다.

이때 자기주장이 강한 개발자라면 마치 커뮤니티에서 키보드 배틀을 하듯 계속 핑퐁이 오고 가게 됩니다. (저는 코멘트 100개 이상까지 봤습니다.)

그렇게 한 Pull Request에 코멘트가 수십 개 달리게 되며 리뷰를 계속 길어지고 제품은 출시가 안되며 외부에서는 계속 제품 출시에 관한 압력이 오게 됩니다.

코로나로 인한 리모트 워크도 영향은 있지만 Pull Request는 보통 온라인으로 코드 리뷰가 진행되기 때문에 사람의 감정이 전달되지 않습니다. 따라서 서로 오해가 깊어지기도 합니다.

코드 리뷰의 목적은 무엇일까요?

지금까지 코드 리뷰를 통한 단점이나 부작용들을 생각해 봤는데 이제는 코드 리뷰의 원래 목적에 관해서 생각해 보는 시간을 갖도록 하겠습니다.

개발자의 성장

코드 리뷰하고자 하는 대상을 코드가 아닌 동료 개발자의 성장으로 시선을 돌려보는 건 어떨까요?

내가 이 코드 리뷰를 해주면 내 동료가 몰랐던 것을 하나 더 알게 되고 이로 인해 동료가 더 성장을 할 수 있으며 동료의 성장은 팀의 성장으로 이어진다고 생각한다면?

코드 리뷰를 작성하는 마음가짐 자체가 달라지게 되고 같이 성장하기 위한 도구로서 코드 리뷰를 활용하게 됩니다.

좋은 코드를 짜기 위함

좋은 코드를 작성하기 싫어하는 개발자도 있을까요?

있긴 있군요… (출처: 네이버 책)

다들 좋은 코드를 좋아하고 코드 리뷰의 목적은 더 효율적이고 가독성이 좋은 코드를 짜기 위함이라고 생각합니다.

저는 실제로 코드 리뷰를 할 때 ‘과연 이 코드의 가독성이 좋은가?’를 가장 먼저 생각합니다. 가독성이 높은 코드는 나중에 문제가 생겼을 때도 쉽게 읽혀서 문제에 대응하기 쉽고 확장하기에도 편합니다.

다들 본인이 작성한 코드라도 일주일만 지나면 ‘아니 이거 누가 이렇게 작성한 거야?’라는 경험이 한 번쯤 있으실 것이라 생각됩니다. 이럴 때를 대비하는 것이죠.

코드 리뷰를 잘하는 방법은 무엇일까요?

Coding Convention 은 자동화하자.

코드 리뷰를 잘 하지 못하는 조직의 코드 리뷰는 대부분의 리뷰가 Coding Convention을 지적하는 데 사용됩니다. 따라서 Coding Convention은 Formatter를 이용해서 자동으로 맞추도록 하는 편이 효율적입니다.

질문을 하자.

코드 리뷰를 통해서 모르는 것을 알아가는 것이 가장 큰 코드 리뷰의 소득이라고 생각합니다. 내가 전에 모르고 있던 API를 하나 더 아는 것만 해도 엄청 큰 코드 리뷰의 소득일 수 있습니다.

질문을 통해 서로 간에 소통하고 발전하는 것이 진정한 코드 리뷰가 아닐지 생각해 봅니다.

질문을 받은 사람도 해당 질문의 답을 하기 전에 한 번 더 찾아보기 때문에 (정확한 답변을 해야 하니) 답변자에게도 도움이 됩니다.

코멘트가 너무 많이 달리지 않도록 한다.

한 Pull Request에 리뷰어들의 코멘트가 너무 많이 달려서 코드 리뷰가 길어진다면 서로 간의 의견이 충돌한다는 이야기입니다.

저는 어떤 조직에서 신입 주니어 개발자가 올린 Pull Request에 시니어 개발자들 간의 피 튀기는 혈전을 목격한 적이 있는데요. (코멘트가 100개가 넘어감)

이런 케이스가 발생하면 Pull Request를 올린 당사자 뿐만 아니라 이걸 지켜보는 다른 팀원들도 내 Pull Request에도 저렇게 코멘트가 달리면 어쩌지라는 두려움에 코드 변경에 소극적이 됩니다.

이렇게 서로 의견이 충돌을 한다면 다음과 같은 방법을 사용하도록 합시다.

  • 만나서 코드 리뷰를 대면으로 진행하면서 의견을 맞춘다.
  • 대면이 힘들면 Zoom이나 Intellij의 Code With Me 등의 툴을 이용한다.
  • 그래도 조율이 힘들면 코드를 부분부분 쪼개서 의견을 맞추는 시도를 한다.
  • 마지막으로 상급자에게 중재를 요청한다.

간단한 선물을 준비하자.

선물이라고 해서 물질적인 것은 아닙니다. (물질적인 게 더 좋겠네요…)
Pull Reqeust가 올라오면 ‘이런 부분은 이렇게 하면 더 좋을 거 같아요’라고 말하며 간단한 Sample 코드를 제공하는 것이 코드 리뷰에 많은 도움이 됩니다.

하지만 길어지면 오히려 역효과가 발생합니다. 가급적 짧게 작성하는 편이 좋으며 길어지면 ‘그냥 니가 작성하세요’라고 하고 싶어질 때가 있습니다.

간단한 건 그냥 넘어가는 건 어떨까요?

간단한 건 꼭 승인을 거치지 않고 Self 머지를 할 수 있도록 하는 것은 어떨까요?

코드 리뷰는 해당 Pull Request를 올린 작성자의 판단으로 꼭 필요할 경우만 리뷰어를 설정해서 코드 리뷰를 받는 것으로 하면 코드 리뷰의 양도 줄어들고 더욱 업무에 집중할 수 있습니다.

감정이 상하지 않도록 합시다.

온라인에서는 감정이 전달되지 않기 때문에 표현을 조심스럽게 사용하는 편이 좋습니다. 만약 오프라인 출근 상황이었다면 감정을 전달할 여러 가지 방법이 있기 때문에 문제가 없지만 리모트 워크에서는 문제가 발생할 가능성이 있습니다.

이모지를 사용해 볼까요?

출처: Emoji cheat sheet

Emoji cheat sheet에 마크다운을 이용해 사용 가능한 많은 이모지가 있습니다. 내 감정을 상대방에게 효과적으로 전달하는 좋은 방법 중 하나가 이 이모지 사용이 아닐까 싶습니다.

칭찬을 먼저 합시다.

일단 코드를 작성하느라 수고한 동료에게 먼저 고생했다고 한마디 하면서 긍정적으로 시작을 해 봅시다.

예시
– 고생하셨어요.
– 잘하셨어요.
– 좋아지고 있네요.

부담을 주지 맙시다.

코드 리뷰는 과외가 아닙니다. 리뷰어가 리뷰를 해준 내용을 반드시 반영을 해야 한다는 강제성은 없습니다.

NIT(Nitpicking) 등을 사용해서 ‘지금도 문제가 없지만 이런 식으로 개선하면 더 좋을 거 같아요’ 정도의 코멘트로 동료 개발자에 발전에 도움이 되도록 부담 없이 코드 리뷰 코멘트를 남겨보는 것도 좋은 방법입니다.

  • NIT(Nitpicking)은 중요하지 않은 코멘트로 이걸 꼭 처리하지 않아도 코드를 머지 할 수 있다는 의미로 사용됩니다.
  • 좋은 코드 리뷰는 코멘트로 작성한 코드 리뷰의 사항이 중요하지 않은 경우를 명확하게 코드 작성자에게 알려줘야 하기 때문에 사용하는 것을 권장합니다.

TestCase를 더 잘 짜도록 노력합시다.

코드 리뷰 내용을 적용할 때 가장 부담스러운 부분 중 하나는 이미 작업이 끝나서 제대로 동작하는 코드에 리뷰 내용을 다시 적용해야 한다는 것입니다. 코드 수정 전에 정상적으로 동작한 코드가 수정후에도 과연 정상적으로 동작할까라는 부담감 때문이라고 생각합니다.

이미 잘 동작하는데 또 수정해야 하니 부담스러울 수 있죠. 이럴 때 TestCase를 잘 작성해 놨다면 그 부담을 덜 수 있어 리뷰 내용을 적용하기가 더 쉽습니다.

한 번에 한 가지 기능씩 Pull Request를 올립시다.

가급적 작게 리뷰를 받는 편이 리뷰어에게 더 부담이 적습니다. 한 번에 여러 가지 기능을 만들어서 리뷰를 요청하면 놓치는 부분이 있을 수 있기 때문에 코드 리뷰를 하기 편한 단위로 Pull Request를 올리도록 합시다.

해결사가 아니라 조언자가 되도록 합시다.

코드 리뷰에서 너무 공격적인 어투나 본인의 지식을 자랑하지 맙시다.
예를 들어 “이 코드는 이 부분이 잘못되었어요.“라는 리뷰는 좋지 않습니다.
이 부분은 이런 문제가 있을 가능성이 있네요. 이런 방법으로 한번 체크해 보는 건 어떨까요?“라는 식의 조언을 통한 부드러운 코드 리뷰를 이끌어 봅시다.

코드 Push 전에 리뷰를 받아봅시다.

대량의 코드 커밋이나 정말 중요한 로직의 경우 코드 Push 전에 동료에게 사전 리뷰를 요청합니다.
이 리뷰는 Zoom이나 Intellij의 Code With Me 등 온라인 페어 코딩 도구를 이용해서 진행하는 것이 좋습니다.

이미 코드를 다 작성해서 Push를 했는데 방향성이 잘못되었을 경우 되돌리기가 쉽지 않기 때문에 중간중간 혹은 시작 전에 같이 화상으로 Sample 코드나 구조를 보면서 방향을 잡고 시작하는 것도 좋은 방법입니다.

이런 방식을 Pre Commit Code Review라고 합니다.

서로 (사적으로) 친하게 지내면 좋습니다.

하루에 집에서 자는 시간 말고 가장 많은 시간을 보내는 사람이 바로 같은 팀원, 옆자리 동료입니다. 공적으로 아닌 사적으로 친해지면 조금 더 유연한 코드 리뷰를 진행할 수 있지 않을까요?

마지막으로…

  • 좋은 코드란 무엇인지 동료들과 공감대를 형성하자
  • Coding Convention은 자동으로 확인할 수 있는 Formatter를 사용하자
  • 코드 리뷰는 적극적인 이모지 사용 등으로 유하게 작성하자
  • 리뷰어가 리뷰하기 쉽도록 Pull Request는 작은 단위로 올리자
  • TestCase를 작성하여 마음의 안정을 찾자
  • Pre Commit Code Review를 활용해 보자
  • 서로 배려하고 친해지자

정도로 정리할 수 있겠네요.

지금까지 긴 저의 개인적인 생각을 읽어주셔서 감사합니다.
이 글이 여러분의 좀 더 원활한 코드 리뷰에 도움이 되었으면 좋겠습니다.
감사합니다.

이경일 | Cell TF
이경일 | Cell TF

특출나진 않지만 다방면으로 경험하고 새로운 것을 시도하는 것을 취미로 즐기는 잡부 개발자