<div id="readability-page-1" class="page"><article>
        <h2 id="코드-리뷰-남들도-다-하더라"><a href="#코드-리뷰-남들도-다-하더라" title="코드 리뷰 남들도 다 하더라"></a>코드 리뷰 남들도 다 하더라</h2><p>코드 리뷰 라는 말이 이제는 개발자라면 누구나 익숙한 관용어가 되었지만, 이 용어가 생소했던 시절이 생각보다 그리 오래 전은 아니다. 과거에는 코드는 작성한 개인의 소유물 처럼 여겨졌고 그렇기에 코드에 대한 비판은 나 자신의 비판으로 여겼기에 누군가가 나의 코드를 보는 것 자체만으로 거부감이 있었던 시기도 있었다. 하지만 최근에는 오히려 코드 리뷰를 하지 않는 조직은 시대에서 뒤쳐지는 것처럼 느껴지는 정도의 분위기가 된 것 같다.</p>
<p>반면 최근에 여러 개발자들과 이야기를 나눠보면 본인이 속한 조직에서 코드 리뷰는 진행 하고 있지만 만족스럽게 느끼는 경우는 많지 않다고 느꼈다. 자주 들었던 이야기들은 ‘각자 다른 영역의 업무를 하고 있다보니 코드에 대한 이해도가 떨어져서 의미있는 리뷰를 받지 못한다’, ‘다들 바빠서 리뷰 할 시간이 없다보니 리뷰과정이 너무 오래 걸린다’, ‘공들여 리뷰 피드백을 했지만 바쁘다는 핑계로 반영이 되지 않아 허탈했다’, ‘의견이 다른 경우 합의를 이루는 과정이 너무 피곤하다’ 같은 내용이 많았던 것 같다. </p>
<p>개인적으로 이런 것들은 코드 리뷰를 통해서 얻고자 하는 것에 대한 구성원들의 공감대 없이 다른 곳에서 하는 것을 그대로 형식적으로 받아들였을 때 생기는 문제라고 생각한다.</p>
<p><img src="https://wonderer80.github.io/images/lgtm.png" alt="LGTM!" title="LGTM이 무슨 뜻인지는 알고 쓰는 거겠지?"></p>
<p>코드리뷰가 잘 이루어지려면 먼저 코드 리뷰를 통해서 우리가 얻고자 하는 것이 무엇인지 명확하게 구성원들이 인지해야 한다. 형식을 따라하는 것이 아니라 우리가 목표하는 바를 잘 달성하고 있는지를 확인할 때 우리의 리뷰 프로세스가 잘 동작하고 있는지 이해할 수 있다. 그리고 우리의 상황에 따라 지속적으로 변화할 수 있어야 한다.</p>
<h2 id="코드-리뷰를-통해서-얻을-수-있는-이점"><a href="#코드-리뷰를-통해서-얻을-수-있는-이점" title="코드 리뷰를 통해서 얻을 수 있는 이점"></a>코드 리뷰를 통해서 얻을 수 있는 이점</h2><p>먼저 구글에서는 코드 리뷰를 통해서 얻는 이점에 대해 다음과 같은 것을 제시하고 있다.</p>
<ul>
<li>코드의 정확성 검증</li>
<li>다른 엔지니어들이 코드의 변경사항을 이해할 수 있는지 확인</li>
<li>코드 베이스들간의 일관성 강화</li>
<li>팀 오너십 촉진</li>
<li>지식 공유 활성화</li>
<li>코드 리뷰에 대한 이력 제공</li>
</ul>
<p>일반적으로 첫번째 ‘코드의 정확성 검증’. 즉, 로직에 결함이 없는지를 가장 중요한 리뷰의 목적으로 생각하는 경우가 많다. 그리고 두번째는 ‘코드 베이스들간의 일관성’, 컨벤션 측면에서 보는 경우들이 많다. 하지만 개인적으로 봤을 때 이 두가지는 코드 리뷰에서 상대적으로 가장 덜 중요한 이점이라고 생각한다. 첫번째는 테스트 코드를 통해서 해소하는 것이 더 바람직하며, 두번째는 CI 와 연동하여 자동으로 체크하는 것이 더 효율적이다.</p>
<p>구글에서도 이 부분을 지적하고 있으며 이 중에서 가장 중요하지만 과소평가된 이점으로는 지식 공유 활성화라고 한다. 지식 공유라는 것이 사람수에 비례해서 잘 이루어질 것으로 기대하는 사람도 있지만, 오히려 일하는 방식의 영향을 많이 받는 것 같다. 1000명이 넘는 개발자가 있는 조직에서도 서로가 무슨 일을 하는지, 어떤 방식으로 개발을 하는지 모르는 경우도 있고 반면에 4-5명밖에 없지만 상호간에 활발하게 지식 공유와 학습이 일어나는 경우도 있다.</p>
<p>또한 개인적으로는 리뷰라는 것을 작성된 코드로 한정하면 리뷰를 통해서 얻을 수 있는 이점이 제약된다고 본다. 뛰어난 개발자는 어려운 코드를 만들어내는 사람이 아니라 할 필요가 없는 일을 하지 않는 사람이다. 이런 것을 판단하려면 요구사항 분석 단계에서부터 이 코드가 어떤 문제를 해결하기 위한 작업이며, 그 문제를 해결하는데 가장 적합한 선택인지를 알 수 있어야 한다.</p>
<h2 id="항상-무엇이든-도입보다-유지와-발전이-더-어렵다"><a href="#항상-무엇이든-도입보다-유지와-발전이-더-어렵다" title="항상 무엇이든 도입보다 유지와 발전이 더 어렵다"></a>항상 무엇이든 도입보다 유지와 발전이 더 어렵다</h2><p>이러한 이해를 바탕으로 처음에 리뷰를 도입하는 시기에는 먼저 구성원들의 공감대와 개선 의지가 필요하다. 처음에 무언가를 시작할 때는 한 사람의 의지만으로 가능할 수 있을지 몰라도 그것을 유지하고 발전시키기 위해서는 구성원 모두의 힘이 필요하다. 구글에서 제시하는 이점을 참고해도 되고 혹은 다른 것이어도 상관없다. 가장 우리가 필요로 하는 것 하나를 딱 찍어서 목표를 정하고, 그로 인한 효능감을 구성원들 스스로 느끼는 것이 중요하다. 단순히 코드 리뷰를 하면 힙한 느낌이고 그렇지 않으면 뒤처지는 느낌인 것 같은 생각으로 시작되어선 오히려 없는 것만 못한 리뷰가 이루어질 수 있다.</p>
<p>단순히 리뷰를 하고 있는지의 여부가 아니라 우리가 원하는 것을 얻기 위한 리뷰를 잘하고 있는지, 우리의 리뷰를 개선하기 위해 어떤 시도를 해보았는지 스스로 돌아볼 필요성이 있다. 다른 조직에서 하고 있는 것들을 그대로 다 따라할 필요가 없다. 우리가 지속적으로 조금씩 나아지고 있는지, 그냥 형식적으로 따라하는 것을 시도하고 변화가 없는지를 점검해보는 것이 중요하다.</p>
<p>필자가 속한 조직에서도 리뷰와 관련해서 지속적인 개선 시도와 발전을 해왔는데, 단순히 현재 시점에 무엇을 하고있는가가 아닌 어떤 과정과 시행착오를 거쳐 발전시켜왔는지에 대한 이야기를 다음 글을 통해서 공유해보도록 하겠다.</p>
<p><strong>참고 자료</strong></p>
<ul>
<li><a target="_blank" rel="noopener" href="https://abseil.io/resources/swe_at_google.2.pdf">Software Engineering at Google</a></li>
</ul>

    </article></div>

wonderland

코드 리뷰 남들도 다 하더라
코드 리뷰 라는 말이 이제는 개발자라면 누구나 익숙한 관용어가 되었지만, 이 용어가 생소했던 시절이 생각보다 그리 오래 전은 아니다. 과거에는 코드는 작성한 개인의 소유물 처럼 여겨졌고 그렇기에 코드에 대한 비판은 나 자신의 비판으로 여겼기에 누군가가 나의 코드를 보는 것 자체만으로 거부감이 있었던 시기도 있었다. 하지만 최근에는 오히려 코드 리뷰를 하지 않는 조직은 시대에서 뒤쳐지는 것처럼 느껴지는 정도의 분위기가 된 것 같다.
반면 최근에 여러 개발자들과 이야기를 나눠보면 본인이 속한 조직에서 코드 리뷰는 진행 하고 있지만 만족스럽게 느끼는 경우는 많지 않다고 느꼈다. 자주 들었던 이야기들은 ‘각자 다른 영역의 업무를 하고 있다보니 코드에 대한 이해도가 떨어져서 의미있는 리뷰를 받지 못한다’, ‘다들 바빠서 리뷰 할 시간이 없다보니 리뷰과정이 너무 오래 걸린다’, ‘공들여 리뷰 피드백을 했지만 바쁘다는 핑계로 반영이 되지 않아 허탈했다’, ‘의견이 다른 경우 합의를 이루는 과정이 너무 피곤하다’ 같은 내용이 많았던 것 같다. 
개인적으로 이런 것들은 코드 리뷰를 통해서 얻고자 하는 것에 대한 구성원들의 공감대 없이 다른 곳에서 하는 것을 그대로 형식적으로 받아들였을 때 생기는 문제라고 생각한다.
코드리뷰가 잘 이루어지려면 먼저 코드 리뷰를 통해서 우리가 얻고자 하는 것이 무엇인지 명확하게 구성원들이 인지해야 한다. 형식을 따라하는 것이 아니라 우리가 목표하는 바를 잘 달성하고 있는지를 확인할 때 우리의 리뷰 프로세스가 잘 동작하고 있는지 이해할 수 있다. 그리고 우리의 상황에 따라 지속적으로 변화할 수 있어야 한다.
코드 리뷰를 통해서 얻을 수 있는 이점
먼저 구글에서는 코드 리뷰를 통해서 얻는 이점에 대해 다음과 같은 것을 제시하고 있다.
코드의 정확성 검증
다른 엔지니어들이 코드의 변경사항을 이해할 수 있는지 확인
코드 베이스들간의 일관성 강화
팀 오너십 촉진
지식 공유 활성화
코드 리뷰에 대한 이력 제공
일반적으로 첫번째 ‘코드의 정확성 검증’. 즉, 로직에 결함이 없는지를 가장 중요한 리뷰의 목적으로 생각하는 경우가 많다. 그리고 두번째는 ‘코드 베이스들간의 일관성’, 컨벤션 측면에서 보는 경우들이 많다. 하지만 개인적으로 봤을 때 이 두가지는 코드 리뷰에서 상대적으로 가장 덜 중요한 이점이라고 생각한다. 첫번째는 테스트 코드를 통해서 해소하는 것이 더 바람직하며, 두번째는 CI 와 연동하여 자동으로 체크하는 것이 더 효율적이다.
구글에서도 이 부분을 지적하고 있으며 이 중에서 가장 중요하지만 과소평가된 이점으로는 지식 공유 활성화라고 한다. 지식 공유라는 것이 사람수에 비례해서 잘 이루어질 것으로 기대하는 사람도 있지만, 오히려 일하는 방식의 영향을 많이 받는 것 같다. 1000명이 넘는 개발자가 있는 조직에서도 서로가 무슨 일을 하는지, 어떤 방식으로 개발을 하는지 모르는 경우도 있고 반면에 4-5명밖에 없지만 상호간에 활발하게 지식 공유와 학습이 일어나는 경우도 있다.
또한 개인적으로는 리뷰라는 것을 작성된 코드로 한정하면 리뷰를 통해서 얻을 수 있는 이점이 제약된다고 본다. 뛰어난 개발자는 어려운 코드를 만들어내는 사람이 아니라 할 필요가 없는 일을 하지 않는 사람이다. 이런 것을 판단하려면 요구사항 분석 단계에서부터 이 코드가 어떤 문제를 해결하기 위한 작업이며, 그 문제를 해결하는데 가장 적합한 선택인지를 알 수 있어야 한다.
항상 무엇이든 도입보다 유지와 발전이 더 어렵다
이러한 이해를 바탕으로 처음에 리뷰를 도입하는 시기에는 먼저 구성원들의 공감대와 개선 의지가 필요하다. 처음에 무언가를 시작할 때는 한 사람의 의지만으로 가능할 수 있을지 몰라도 그것을 유지하고 발전시키기 위해서는 구성원 모두의 힘이 필요하다. 구글에서 제시하는 이점을 참고해도 되고 혹은 다른 것이어도 상관없다. 가장 우리가 필요로 하는 것 하나를 딱 찍어서 목표를 정하고, 그로 인한 효능감을 구성원들 스스로 느끼는 것이 중요하다. 단순히 코드 리뷰를 하면 힙한 느낌이고 그렇지 않으면 뒤처지는 느낌인 것 같은 생각으로 시작되어선 오히려 없는 것만 못한 리뷰가 이루어질 수 있다.
단순히 리뷰를 하고 있는지의 여부가 아니라 우리가 원하는 것을 얻기 위한 리뷰를 잘하고 있는지, 우리의 리뷰를 개선하기 위해 어떤 시도를 해보았는지 스스로 돌아볼 필요성이 있다. 다른 조직에서 하고 있는 것들을 그대로 다 따라할 필요가 없다. 우리가 지속적으로 조금씩 나아지고 있는지, 그냥 형식적으로 따라하는 것을 시도하고 변화가 없는지를 점검해보는 것이 중요하다.
필자가 속한 조직에서도 리뷰와 관련해서 지속적인 개선 시도와 발전을 해왔는데, 단순히 현재 시점에 무엇을 하고있는가가 아닌 어떤 과정과 시행착오를 거쳐 발전시켜왔는지에 대한 이야기를 다음 글을 통해서 공유해보도록 하겠다.
참고 자료
Software Engineering at Google

우린 코드리뷰 잘하고 있을까?

댓글