라인웍스의 개발 문화 – (2) 코드 리뷰

2021.12.15

이번 글은 라인웍스의 개발 조직의 관점에서  코드 리뷰를 하는 이유와 개발 조직이 얻은 성과를 소개하고, 다른 개발조직에서도 참고 할 수 있도록 코드 리뷰 과정과 사례도 함께 공유합니다. 개인의 입장에서 코드 리뷰를 어떻게 해야 하는지에 대한 글은 코드 리뷰를 대하는 개발자의 자세 글을 참고하시기 바랍니다.

코드 리뷰가 필요한 이유

라인웍스의 제품들의 기능은 (앞의 Code Coverage 관련 글에서도 언급했듯이) 주로 큰 데이터를 다룹니다. 그 뿐 아니라 분석의 내용이 아주 복잡해 이를 코드로 옮기는 것이 쉽지 않고, 분석 결과가 어떻게 나올지도 예상하기가 어렵습니다. 테스트 코드를 통해 코드가 정상적으로 실행된다는 것을 보장한다고 해도, 데이터에 따라서 예외적인 경우에 올바른 결과를 내지 못하는 경우도 있습니다.

이러한 이유 때문에 코드 리뷰에 많은 시간을 할애하고, 최대한 많은 인원이 리뷰를 하도록 독려하고 있습니다.

코드 리뷰를 통해 얻는 것

우리는 코드 리뷰를 통해 제품의 품질과 팀워크라는 두 가지 이득을 얻었습니다.

제품의 품질

코드 리뷰를 하면 예상하지 못한 버그나 요구사항과 다르게 구현된 실수를 조기에 발견할 수 있어 제품의 전체적인 퀄리티가 상승합니다. 코드 컨벤션 준수 여부를 확인하고, 가독성 있는 코드에 대한 논의를 하게 되며 전체적으로 편리하게 유지 보수할 수 있는 코드를 구성할 수 있습니다. 더 나아가서, 재사용 가능한 함수, 모듈에 대한 서로 간의 의견이 활발하게 오고가며 더 좋은 퀄리티의 코드로 발전할 수 있습니다.

팀워크

코드 리뷰는 팀워크를 기르는데 도움을 줍니다. 주니어 개발자들도 시니어 개발자의 코드를 리뷰하며 자유롭게 의견을 제시할 수 있고, 시니어 개발자도 자신의 노하우를 구체적인 사례를 통해 전달할 수 있습니다. 기술적인 지식에 대해서 질문과 답변을 통해 공유하며 함께 일하는 팀의 일원이라는 느낌을 받을 수 있습니다. 또한, 모두가 코드에 관여하게 해주기 때문에, 버그가 생겨도 한 사람의 실수가 아닌 팀의 실수라는 인식을 가지게 됩니다.

코드 리뷰 프로세스

라인웍스는 GitHub의 Pull Request 기능을 활용하여 코드 리뷰를 진행하고 있습니다.

코드 리뷰를 진행하는 프로세스는 다음과 같습니다. 팀원이 늘어날수록 이런 프로세스가 있다는 것을 팀원들에게 인지시키고 따르게 하는 것이 중요합니다.

  • 이슈 생성 및 개발
    • 우선 GitHub에 이슈를 만들고 이슈 단위로 Branch를 만들어 개발을 진행합니다.
  • Pull request 생성
    • 개발과 테스트가 완료되면 완료되면 코드를 푸시하고, GitHub Repository에서 Pull request를 생성합니다.
  • 리뷰어 지정
    • Pull request 요청자는 리뷰어를 선택합니다.
    • 대부분의 경우, 같은 포지션의 인원을 모두 추가해 요청하게 됩니다.
  • 리뷰
    • 리뷰 요청을 받은 리뷰어는 코드를 리뷰하고 코멘트를 남깁니다.
    • 승인(Approve), 코멘트(Comment), 변경 요청(Request Change) 중 선택해 코드를 머지해도 될지에 대한 의견을 남깁니다.
  • 리뷰 반영
    • 요청자는 리뷰 코멘트를 확인하고 이를 반영하여 코드를 수정합니다.
    • 반영하지 않을 것이라면 코멘트의 코멘트로 왜 지금 반영하지 않는지에 대한 설명을 남깁니다.
  • 리뷰 재요청
    • 리뷰를 반영하여 수정했다면, 해당 리뷰를 남긴 리뷰어에게 다시 리뷰를 요청합니다.
    • 이후 ‘리뷰’ 순서로 돌아가 반복합니다.
  • 머지
    • 리뷰가 완료되고 승인을 받았다면 코드를 머지합니다.

하지만 실제 업무에 위의 프로세스를 적용하다 보면, 다음과 같은 예외 상황과 어려움이 발생할 수 있습니다.

  • 당장 수정해서 적용해야 하는 상황에 빠르게 리뷰가 가능한 사람이 없을 때 어떻게 해야 할지
  • 리뷰 코멘트가 많이 달렸지만 이슈 처리의 마감 시간은 얼마 남지 않았을 때, 어떤 것부터 처리해야 할지

이를 더 효율적으로 처리하기 위해 라인웍스에서는 어떤 방법을 사용하고 있는지 공유하려고 합니다.

코드 리뷰 프로세스의 보완책 1: 자율성

라인웍스에서는 리뷰 프로세스에서 개발자 개인에게 많은 자유를 부여합니다. 자신이 요청한 Pull request에 대해서 자신이 직접 판단하여 누구의 리뷰가 필요할지, 어떤 리뷰를 반영해야 할지를 결정합니다.

실제 예:

  • 간단한 수정을 리뷰 없이 임의로 머지한 예
  • 작업 의존성이 걸려 빠른 업무 진행을 위해 리뷰 없이 임의로 머지한 예
  • 같은 프로젝트이지만 PR에 따라 지정한 리뷰어가 다른 경우

코드 리뷰 프로세스의 보완책 2: 우선순위를 표현하는 Pn룰

GitHub을 이용한 리뷰는 글만을 통해서 전달되기 때문에 의도를 충분히 설명해주지 않으면 리뷰어의 의도가 제대로 전달되지 않아 오해가 생길 수 있습니다. 이러한 이유 때문에, 리뷰어의 의도를 좀 더 잘 나타내기 위해 Pn룰이라는 우선순위 규칙을 도입했습니다. 이 규칙은 뱅크샐러드의 개발 블로그 글(코드 리뷰 in 뱅크샐러드 개발 문화)을 보고 리뷰를 더 수월하게 만들어주는 좋은 규칙이라고 생각해 도입하게 되었습니다.

간단히 설명하면 리뷰 코멘트 앞에 P1 ~ P5로 우선순위를 표현해주는 것입니다.

P1은 반드시 수정해야 하는 내용으로, 처리해야 하는 우선순위가 높은 내용을 작성합니다. 이후 단계적으로 처리 우선순위가 낮은 내용을 작성하고, 마지막 P5에는 단순한, 질문, 칭찬, 감탄 등 수정하지 않아도 되는 내용을 작성합니다. 라인웍스에서 사용하고 있는 규칙에 대한 상세한 내용은 개발 그룹의 GitHub Repository Wiki에 정리 되어 있습니다. 참고하시기 바랍니다.

사용 예

  • 확실한 버그 발견
  • 읽기 쉬운 코드, 효율적인 코드에 대한 논의
  • 코드 작성 의도에 대한 질문

개발 그룹의 코드 리뷰에서 시작한 Pn룰은 회사 전체의 문화가 되어가고 있습니다. 다른 글에서 규칙에 대해서 더 상세하게 설명하겠습니다 

마치며

라인웍스의 개발 조직에서 진행하고 있는 코드 리뷰에 대해 이야기했습니다. 라인웍스는 성장하고 있는 조직인만큼 커져가는 조직 규모에 대응하여 적절한 프로세스를 만들고자 힘쓰고 있습니다. 최근에는 일관된 리뷰 프로세스를 운영하면서 예외 상황에도 대처할 수 있는 방법을 조합하는데 집중했지만, 앞으로도 모두의 의견을 통해 더 나은 코드 리뷰 문화를 만들어갈 것입니다.

함께 좋은 개발 문화를 만들어 나가실 분들을 모십니다. 자세한 사항은 라인웍스 채용 페이지를 참고하세요!

Jungwoo Chae

Engineer

Jungwoo Chae