코드리뷰란 좋은 코드를 작성하기 위해 서로가 논의하는 과정이다.
시니어 개발자들 사이에서 코드리뷰에 대한 호불호는 상당히 극단적으로 나뉘는 편이다.
전 회사에서 같이 일하던 시니어는 코드리뷰를 상당히 좋지 않게 생각하였다.
오늘은 그가 코드리뷰를 싫어하던 이유와 그로 인해 코드리뷰 없는 n년을 보내며 느꼈던 단점을 되돌아보며,
내가 코드리뷰를 좋아하는 이유와 코드리뷰때 중요하게 생각하게 하는 부분들을 공유하는 글을 적어본다.
서론
코드리뷰가 싫었던 그의 얘기
1년 정도 혼자 꾸려가던 개발팀에 새 개발자를 구하면서 내가 원하던 부분은 '개발에 대해 열정이 있고' '함께 페어프로그래밍이나 코드리뷰를 할 흥미가 있는' 개발자로, 이런 부분이 충족된다면 주니어여도 상관없다고 생각했었다.
그러던 중 대표를 통해 새로 오게 된 시니어 개발자는 나와 경력차이가 5배 이상 났다.
원래 임베디드 개발자로 오랜기간 일하다가 개인적 사유로 스타트업으로 이직하며 풀스택을 하게 되신 분이었고 명목상 '면접'인 첫 미팅자리를 가지게 되었다.
첫 만남에서 내가 원하던 조건에 관해 은근슬쩍 얘기가 나오자 그는 바로 손사레를 쳤다.
그리고 아주 짧은 시간 그가 코드리뷰를 싫어하는 이유를 풀어놨다.
1. 실력차이가 나는 사람간의 코드리뷰는 일방적이다.
앞서 말했듯이 함께 일했던 시니어는 나와 상당히 경력차이가 많이났다.
그는 실력차이가 나는 사람간에 코드리뷰를 진행하게 되면 경력이 더 긴쪽에서 짧은 쪽에 일방적으로 피드백을 하는 구조가 될 수 밖에 없다고 말했다.
그러나 사람은 익숙해도 항상 새롭게 깨달을 수 있는 부분이 있는 것이다.
코드의 해석이나 언어의 개념에 대해 사람의 주관이 들어갈 수 밖에 없는 부분이 있기 때문에 나는 경력차이가 있는 경우에도 서로 배울 수 있는 부분이 있다고 생각한다.
필자는 C언어 기초강의를 각각 다른 사람에게 5번이나 들었음에도 들을 때마다 생각해볼만한 부분이 있었다.
코드리뷰 측면에서 낮은 연차의 개발자가 경력이 많은 개발자를 상대로 할 수 있는 리뷰 내용이나 피드백이 상대적으로 빈약할 수는 있어도 실수가 있는 부분이 필터링 될 수도 있고, 저연차가 고연차의 코드를 봄으로써 팀 전체의 개발 실력이 향상되는 효과도 있다.
2. 코드리뷰로 인해 구현시간을 빼앗긴다.
모든 기업이 그렇겠지만 특히 스타트업이란 개발 기한에 쫓기는 경우가 많다.
빠른 MVP로 소비자의 반응을 살펴 빠르게 변모하는게 스타트업의 주요 로직이기 때문이다.
단순히 당면한 이슈들을 쳐내는데에는 코드리뷰로 소모되는 시간이 아깝게 느껴질 수 있다.
그러나 코드리뷰를 통해 실수를 줄이고 코드의 퀄리티를 향상함으로써 유지보수가 더 용이해지고 장기적으로 봤을 때 코드에 들이는 시간이 줄어들 수 있다.
3. 코드리뷰 시 알아야하는 도메인이 많아진다.
얘기를 할 때 서로 백엔드와 프론트로 업무를 나누기로 얘기가 됐는데, 코드리뷰를 하게되면 서로 작업하지 않는 부분의 코드도 파악해야하는 부분이 있고 본인은 프론트엔드 업무를 하기 싫으셨기에 업무가 확실히 분리되었으면 한다고 하셨다.
그러나 전 회사는 퇴사할 때까지 개발자 수가 많이 늘진 않았다. 결과적으로 그도 백엔드와 프론트를 둘 다 하게되었고, 나도 백엔드와 프론트, 앱을 전부 관리하게 되었다. 그 와중에 업무가 분담되어 특정 서비스 특정 플랫폼에 장애가 생기면 휴가 중에도 담당자가 무조건 업무를 봐야했고, 그 와중에 백엔드도 Node, Python으로 다양화되고 프론트로 Vue, React로 나뉘어 관리의 피로도가 하늘을 찔렀다. 언어를 통일하고 평시에 코드리뷰를 진행했더라면 서로 관리하는 서비스에 유사시에 훨씬 도움이 되었으리라는 점은 자명하다.
코드리뷰가 없을때 느꼈던 단점
내가 코드리뷰를 좋아하는 이유
위에 코멘트로 이미 내가 느꼈던 단점과 코드리뷰의 장점을 일부 설명했지만 다시 한번 정리해봤다.
1. 반복되는 문제점
코드에는 개인의 스타일이 들어가기 마련이다.
코드의 품질과 무관한 스타일도 있지만, 다른 사람과 비교하여 나쁘다는 걸 알기 전까지 반복해서 쓰는 안 좋은 습관도 분명 있기 마련이다.
예를 들어 나는 ~~~ 이런 안좋은 습관이 있었는데 코드리뷰를 통해 고쳤다. < 여기 뭐쓰죠
코드리뷰에는 서로의 코드 습관을 돌아보고 더 좋은 코드를 위한 논의를 통해 좋은 코드를 쓸 수 있는 힘을 얻는 효과가 있다. 개인의 개발실력 향상에 도움이 된다는 것이다. 이는 개인에게만 이점으로 작용하지 않고 팀 차원에서도 유지보수 공수를 줄이는 효과가 있다.
2. 통일성 없는 코드
1에서 얘기했듯 코드에는 개인의 스타일이 들어가기 마련이다.
다수로 구성된 개발팀에서 각기 코드를 작성하다보면 한 서비스의 코드인데도 중구난방이 되는 경우가 부지기수다. 코드의 다양성은 변수 및 함수 네이밍 같은 사소한 것부터 디렉토리의 구조 및 디펜던시 사용기준처럼 프로젝트 구성 단위에서까지 보여질 수 있다.
일반적으로 이를 해소하기 위해 각 팀마다 코드 컨벤션이 존재하고, 코드 포맷팅 툴과 린터가 존재하지만 그러한 것들이 모든걸 마법처럼 다 해결해주는 것은 아니다.
프로젝트의 초기 구성에서 포맷팅과 린팅 룰이 모두 세부적으로 짜여져 있는 회사가 얼마나 있을까?
이 때 그러한 부분에서 협의점을 찾고 규칙을 세우는 과정도 코드리뷰를 통해 이뤄질 수 있다.
그렇게 팀 내 규칙을 세부화해가면서 전체적 코드에 통일성을 갖게되면 직접 작업한 코드가 아니더라도 팀 내 누군가가 손대기 더 쉬운 코드가 되는 것이다.
3. 너무 높은 개인의 책임
서론에서 '코드리뷰란 좋은 코드를 작성하기 위해 서로가 논의하는 과정이다'라고 얘기했다.
이 문장에서 중요한 점은 '서로' 코드에 관여한다는 점이다.
코드리뷰없이 단독으로 작성되어 배포되는 코드는 별다른 검수과정을 거치지 않기에 실수가 발생할 확률이 더 높고, 안티패턴으로 짜여진 코드더라도 문제의식 없이 사용될 수 있다.
이 때 그러한 실수나 안티패턴으로 인해 서비스에 오류나 장애가 발생한다면 그것은 코드를 작성한 혼자만의 책임이 된다.
QA과정을 통해 프로덕션에서 장애가 발생하는 것을 막을 수는 있겠지만, 개발자 입장에선 오류 발생 제보 자체가 심리적 피로가 된다.
꼭 오류나 장애로 이어지지 않더라도, 리뷰를 거치지 않는 경우 잠깐 신경을 못쓰는 것만으로도 코드의 품질이 낮아지기 쉽다. 이는 곧 유지보수 공수의 증가로 이어지고 본인의 코드 혹은 팀 내 다른 개발자의 코드를 리팩토링 하게 될 때에 해야될 업무의 크기가 크게 늘어나게 된다.
코드리뷰할때 생각하는 것
코드리뷰를 약 반년간 진행하며 중요하게 생각했던 부분을 글로 정리해봤다. 어찌됐든 코드리뷰를 진행하며 아직 멱살잡는 일도 없었고 개인적으로 도움도 많이 받았다고 생각이 들어 개인의 관점을 공유해본다.
1. 누구라도 수정할 수 있는 코드, 코드의 가독성
누구라도 수정할 수 있는 코드란 어떤 것일까?
한마디로 정의하자면 나는 '가독성이 좋은 코드'라고 말하고 싶다.
그럼 코드의 가독성은 어떨 때 좋아질까?
- 디렉토리 구조가 팀 내에서 주로 사용하는 구조로 되어있다. (디렉토리 규칙)
- 함수와 변수의 이름에 이미 그 의미가 들어있고 이름을 구성하는 단어들이 팀 내에서 해당 의미를 위해 많이 쓰는 단어들로 구성되어있다. (네이밍 규칙)
- 내부 로직이 너무 복잡한 함수나 여러 단계로 구성된 함수는 서브 함수로 쪼갠다. (함수 쪼개기)
등등 다양한 포인트가 있을 것이다.
어떠한 절대적 기준이 있는게 아니라 주관적 느낌이기 때문에 팀원간에 합의가 필요한 부분이다. 가독성이 좋은 코드는 직접 작업한 코드가 아니더라도, 혹은 직접 작업한 코드더라도 다시 봤을 때 코드를 파악하기 쉽다. 이런 코드는 유지보수가 비교적 용이하고 코드에 오류가 있더라도 쉽게 찾아낼 수 있다.
복잡한 코드는 코드의 문제를 파악하기 어렵게 만들어 유지보수 공수를 늘리고 다른 개발자가 코드에 조인하기도 어렵게 만든다.
이러한 점을 의식하여 코드리뷰를 할 때에 내가 보기에 가독성이 떨어진다고 생각되는 부분들을 얘기해서 팀 안에서 합의를 도출하고 그러한 합의점에 따라 통일성 있는 코드가 되도록 하자.
2. 통일성 있는 코드, 통일성 있는 코드리뷰
사람마다 코드를 작성할 때 중요하다고 생각하는 부분이 다를 수 있다.
그러나 개인의 선호만 반영한다면 작업자마다 너무 다른 코드가 나올 수 있다. 개인의 개성이 담기는건 좋지만 한 프로젝트 내에서 스타일이 너무 다를 경우 위에서 말한 코드의 가독성이 저해될 수 밖에 없다. 그렇게 되지 않도록 다양한 면에서 어느정도 팀의 컨벤션을 정해서 코드를 작성하는 것을 권장한다.
코드뿐만 아니라 코드리뷰를 할 때에도 통일성이 필요하다. A라는 PR에서는 컴포넌트 렌더링 시 삼항연산자를 쓰도록 리뷰했다가 B라는 PR에서는 논리연산자(&&)를 통해 렌더링하도록 리뷰하면 리뷰를 받는 입장에서는 리뷰에 일관성이 없다고 느낄 수 있다. 리뷰하기 전 구현방식이 갈릴 수 있는 로직이라면 스스로의 마음 속에서 충분한 근거를 찾아 선호방식을 결정한 뒤 리뷰하도록 하자.
3. 리뷰는 대화이다
코드리뷰를 할 때 이런 코멘트를 달아도 될까? 하는 고민을 해본 적이 있는가? 필자는 있다.
특히 나보다 경력이 높거나 코딩실력이 뛰어나다고 생각되는 개발자의 코드에 리뷰를 달 때는 더 조심스러워 지는 부분이 있을거라고 생각한다.
하지만 코드리뷰는 그저 '논의' 과정이다. 이 말인 즉슨 하는 말의 모두가 진실일 필요는 없다는 것이다. 이러이러한 방향이 더 좋지 않나요? 하고 코멘트를 다는 행위는 코드 작성자에게 그 부분에 대해 한번 더 생각해볼 수 있는 환기점을 주는 효과를 가진다. 실제로 그 방향이 더 좋거나 좋지 않더라도 코드를 선택하는 이유를 더 명확하게 하는 계기가 될 것이다. 코드를 단 입장에서도 원 작성자의 답에 따라 깨달음을 얻는 부분이 있을 수 있다.
또한 방향 제시가 아닌 그저 궁금증을 해소하는 코멘트도 괜찮다. 팀원 전체적으로 의문이 없는 코드는 더 좋은 코드가 될 것이고, 당장 이 코드에 도움이 되는게 아니더라도 내 지식의 증가가 추후 팀 코드의 방향성 통일에 도움이 된다는 긍정적 효과가 있다는걸 기억하고 열심히 얘기를 나누도록 하자.
코드리뷰를 받는 입장에서도, 설령 고연차의 피드백 멘션이 있더라도 모두 그렇습니다 하고 받아들일 필요는 없다. 본인이 납득할 수 있는 선까지 충분히 얘기를 나눈 후 더 좋은 코드라는걸 납득할 때 수정하거나 수정하지 않거나 하면 되는 부분이다. 리뷰를 받고 더 나은 코드가 되었다고 느낀다면 감사하는 마음을 표현하도록 하자.
4. 코드엔 정답이 없다 - 평가 X
코드엔 맞는 코드, 틀린 코드가 없다. '정답에 가까운' 코드가 있을 뿐이다. 이 얘기를 하는 이유는 코드리뷰를 할 때 '당연히 이렇게 해야지'라는 마음으로 해서는 안된다는 것이다.
인터넷의 많은 코드리뷰 후일담에서 서로 감정이 상하고 멱살을 잡는다는 얘기는 99프로 리뷰어나 피리뷰어의 태도의 문제일 것이다. '이 로직을 어떻게 이런식으로 짜?'라는 생각을 하는 순간 당신은 이미 감정싸움 유발자가 된다. 모든 코드는 그 코드를 짤 때 해당 개발자의 생각이 들어가있다. 만약 코드가 좋지 않다고 생각이 되더라도 코드에 대한 평가는 내려두고, 코드에 대해 안 좋다고 생각한 이유를 얘기하며 피리뷰어가 해당 코드를 그렇게 구현한 이유를 묻도록 하자. 안 좋다고 생각한 코드도 나름의 근거가 있을 수 있고, 혹은 해당 작업을 진행할 때 피리뷰어가 생각하지 못한 상황이 있을 수도 있다. 코드리뷰는 더 좋은 코드를 만들기 위해 서로 의견을 모으는 과정이지 남의 코드를 평가하는 과정이 아님을 명심하자.
마인드셋을 갖췄더라도 언어습관도 되돌아볼 필요가 있다. 리뷰코멘트를 작성할 때의 말투가 너무 거침없지는 않은지, 근거를 설명하지 않고 얘기하지 않는지 코멘트를 전송하기 전 작성 내용을 제 3자의 입장에서 한번 돌아보고 달도록 하자. 공격적으로 비춰질 수 있는 언어습관은 본인의 선량한 의도를 곡해받게 만들 수 있다.
5. 코드가 잘못됐지 내가 잘못된건 아니다
코드리뷰 진행 시 리뷰받는 내용이 너무 많으면 내 코드가 이렇게 개선해야 될 부분이 많구나 하고 기분이 다운될 수 있다. 그러나 코드가 잘못됐지 내가 잘못된 건 아니다. 리뷰를 하는 입장에서는 리뷰할 내용이 많으면 상대의 기분에 영향이 있을 수 있다는 걸 감안하고 말투를 더 조심스럽게 하는 노력이 필요하고 리뷰를 받는 입장에서는 피드백이 많고 간혹 내가 정말 잘못 작업한 부분이 있더라도 같은 실수를 하지 않는 방향으로 긍정적 마음을 갖도록 하자.
마무리하며
코드리뷰를 할 때는 내가 이 코드에 관여함으로써 책임이 발생한다는 생각으로
코드리뷰를 받을 때는 코드 작성에 도움을 받아서 감사하지만 결국 책임은 내가 져야한다는 생각으로 그렇게 하고 있는데 사실 나도 코드리뷰는 저년차라 잘하고 있는지 모르겠지만 개인적으로 도움이 많이 되었다 생각이 들어서 처음 코드리뷰를 하는 사람들에게 조금 도움이 될까 하고 글을 적어봤다.
이 글을 우리팀 막내 주니어님에게 바친다 ^.^
