최근 수정 시각 : 2023-08-27 02:51:41

코드 리뷰

소프트웨어 관련 정보
{{{#!wiki style="margin: 0px -10px -5px"
{{{#!folding [ 펼치기ㆍ접기 ]
{{{#!wiki style="margin:-5px -2px -12px"
<colbgcolor=#64C3FA,#548FB2> 소프트웨어
<colcolor=#000,#fff> 기능에 따른 구분 시스템 소프트웨어(플랫폼)
응용 소프트웨어
유틸리티
펌웨어
권한에 따른 구분 사유 소프트웨어 프리웨어, 셰어웨어, 애드웨어
오픈 소스, 자유 소프트웨어
직업 프로그래머( 개발자), 분석가, QA, DB Admin, 디자이너
목록 소프트웨어/목록
}}}}}}}}}||

1. 개요2. 누구의 코드를 리뷰하는가3. 코드 리뷰 코멘트4. 코드 리뷰의 에티켓5. 효과6. 관련 문서7. 관련 링크

1. 개요

타인이 작성한 코드를 리뷰하는 것을 말한다. 소프트웨어 개발 프로젝트의 규모가 커지는 경우 한 사람의 프로그래머가 모든 코드를 프로그래밍할 수는 없다. 즉 팀웍을 하게 된다. 이러한 경우 다른 사람이 작성한 코드가 버그가 있거나 하는 경우 전체 소프트웨어의 결함으로 이어질 수 있다. 코드 리뷰는 이를 예방하는 여러 수단 중 하나로서, 코드 리뷰를 하여 버그를 조기에 발견하고 해결한다. 책 쓰는 것에 비유하자면, 저자가 자기가 쓴 책을 다시 한번 읽어보면서 내용이 매끄럽지 못하거나 오탈자가 있으면 이를 고치는 퇴고와 유사하다.
전 세계의 많은 IT 기업에서 코드 리뷰를 기본 룰로서 채택하고 있다. 구글은 작성된 모든 코드가 리뷰를 거치도록 하고 있으며, 마이크로소프트 역시 개발자들에게 실제 코드를 작성하는 시간 50%, 코드를 리뷰하는 시간 50%를 할당하도록 하고 있다. 네카라쿠배로 대표되는 한국의 많은 IT기업 역시 코드리뷰를 활발히 진행하고 있다.
다만 한국 SW시장의 다수를 차지하는 SI 업계에서는 여러 가지 사정으로 인해 코드 리뷰를 하지 않는 경우가 많다. 가장 단순하게는 시간 문제가 크다. 상기하였듯, 코드 리뷰 시간을 코드 작성 시간에 맞먹게 잡을 수 있을정도로 코드 리뷰에는 많은 시간과 정성이 필요하다. 물론 가독성과 성능이 떨어지는 코드가 리뷰 없이 배포되어 추후에 유지보수하는데에 더 많은 코스트가 들 수 있지만, 당장 데드라인이 급하면 코드 리뷰 할 시간이 없는건 당연지사. 따라서, 코드 리뷰는 팀 또는 조직이 코드의 품질에 대해 신경 쓰고 있는지 여부를 알 수 있는 대표적인 수단이며, 많은 개발자들이 '개발 문화가 좋은 곳'의 요소 중 대표적으로 코드 리뷰 진행 여부를 꼽는다.

2. 누구의 코드를 리뷰하는가

당연히 타인이 작성한 코드를 리뷰하는 것이 일반적이지만, 자기가 짠 코드를 리뷰하기도 한다. 소스코드 커밋을 하기 직전에 잘못된 코드를 찾기 위해서이다. 비유하자면, 저자가 자기가 쓴 문단을 출판사에 제출하기 전에 한번 더 퇴고하는 것과 같다.

3. 코드 리뷰 코멘트

코드에서 잘못된 부분에 작은 메모지를 붙이는 것을 코드 리뷰 코멘트라고 부른다. 물론 실제 메모지는 아니고, 여러 코드리뷰 도구에서 제공하는 기능의 형태이다.

일반적으로 코드 리뷰 코멘트는 개발팀 멤버들이 모두 볼 수 있는 공개 메모이다. 따라서 코멘트가 너무 독설적이면 팀 내 분위기를 흉흉하게 만들 수 있다.

4. 코드 리뷰의 에티켓

힘들게 짠 코드를 남이 리뷰할 때의 비판은 언제나 부담스럽고 그 정도에 따라서 불쾌할 수 있다. 코드 리뷰를 한 타인이 본인보다 실력이 더 좋더라도 이러한 느낌은 피할 수 없게 된다. 다음은 코드 리뷰를 할 때의 에티켓이다.
  • 코드 내용만 비판하라. 코드를 짠 사람을 비판하지 말라: 죄는 미워하되 사람은 미워하지 말라와 비슷하다. 예를 들어 의도치 않은 무한 루프가 있는 코드가 발견되면, "여기서 무한 루프가 발생합니다." 이렇게까지만 적자. 괜히 쓸데없이 "너무 실수를 자주 하시는 것 같습니다."라던지 "커밋을 하기 전에 자가 코드리뷰를 한번 더 해보셨으면 좋았을텐데 말입니다." 같은 오지랖을 펼치지 말자. 심지어 직속 상사라 하더라도.
  • 개인 취향은 코드 리뷰 대상이 아니다: 변수 이름, 함수 이름, 조건문 형태 등은 사람마다 다르게 코딩하게 된다. 프로그래머는 개인 성향이 강한 직업이 되기도 하다 보니, 더욱 이러한 특징이 나타나게 된다. 따라서 본인이 짠 코드와 타인이 짠 코드의 스타일이나 코딩 성향이 다르다 하더라도, 즉 개인 취향이 다르다 하더라도, 이를 타인에게 강요하는 것은 바람직하지 못하다. 다만, 다음은 예외적으로 코드 리뷰 대상이 된다.
    • 팀 내에 정해진 코딩 스타일을 거스르는 코드
    • 오타나 문법에 맞지 않는 변수, 함수이름
    • 가독성을 심하게 저하시키는 코드
  • 이해가 잘 되지 않는 코드는 리뷰 대상이다: 내가 누군가의 코드를 잘 읽을 수 있다면, 그것은 코드 읽는 내 실력이 뛰어난 것이 아니라, 그 코드를 짠 사람의 실력이 뛰어난 것임을 잊지 말자. 이해가 잘 되지 않는 코드라면, 코멘트를 남겨서, 당사자가 코드를 알아보기 쉽게 코드를 더 개선하거나 주석 설명을 달게 유도하는 것이 좋다. 다만, 남들은 다 이해하는데 나만 이해하지 못하는 코드였다면 창피할 수 있으며, 이런 코멘트는 "전반적인 코드 퀄리티가 떨어진다" 라는 뜻으로 전해질 수 있으므로 꼼꼼하게 읽어보고 다른 팀원들에게 가볍게 물어보거나 한 뒤에, 어떤 부분이 이해를 어렵게 하는지 개략적으로 파악하여 남기자.
  • 필요한 코드리뷰만 하라: 코드 리뷰의 본연의 목적은, 더 나은 품질의 코드를 유지하는 것임을 잊지 말자. 코드의 품질을 올리는데 전혀 도움되지 못하는데도 불구하고, 그냥 자기가 봤을 때 고쳐야 한다고 생각된다는 이유로 불필요한 코멘트를 남기는 것은 적절하지 못하다. 특히 똥군기 잡는답시고 지나친 코드리뷰 코멘트를 남발하는 상사가 되지는 말자. 또한, 코멘트를 하나도 안 남기면 대충 봤다고 생각할까봐 억지로 수정점을 찾지 말고 "수고하셨습니다", "LGTM(Looks Good To Me)" 등의 한 마디와 함께 Approve 하는 게 좋다.

5. 효과

책을 출판하기 전에 퇴고를 해야 더 나은 책이 되듯이, 당연히 코드 리뷰 또한 버그가 더 적고 더 안정된 프로그램 개발로 이어진다.

코드 리뷰는 인사평가의 힌트가 되기도 한다. 예를 들어 어떤 팀원의 코드를 리뷰하는 것이 유난히 힘들다면, 그 팀원의 코딩 실력은 별로라고 볼 수도 있다.

6. 관련 문서

7. 관련 링크

Google - Code Review Developer Guide
삼성SDS - 글로벌기업은 코드 리뷰를 어떻게 할까요?
카카오 - 효과적인 코드리뷰를 위한 리뷰어의 자세
뱅크샐러드 - 코드 리뷰 in 뱅크샐러드 개발 문화
카카오페이 - 재택근무 환경에서 효율적인 코드 리뷰 방법: 팀 그라운드 룰 정하기
요즘IT - 코드 리뷰가 개발 문화에 미치는 영향