<div id="readability-page-1" class="page"><article>
        <p>지난 번 글에 이어 이번 글에서는 필자가 속한 조직에서 필자가 입사했을 때 당시의 시점에서부터 현재까지 코드 리뷰 과정에서의 고민과 변화들을 이야기해보도록 하겠다.</p>
<p>코드 리뷰를 처음 도입하는 회사들은 Github의 PR(Pull Request) 리뷰에서 시작하게 되는 경우가 많다. 하지만 처음에는 어떤 식으로 리뷰를 해야하는지 잘 모르기 때문에 로직적으로 결함이 있는지, 컨벤션은 준수되었는지와 같은 코드 스타일을 주로 본다. 필자가 입사 했을 때 당시에도 주로 코드 스타일이나 로직에 대한 부분의 피드백이 중점적이었다. 그리고 테스트 코드를 도입한지 얼마 안된 상황이었다.</p>
<p><img src="https://wonderer80.github.io/images/code_review_pyramid_kor.png" alt="code review pyramid" title="리뷰를 개선시켜나가는 하나의 기준점으로 잡아보자"></p>
<p>백엔드 개발자들끼리 비교적 활발하게 리뷰를 해주는 상황이긴 했지만 각자가 다른 팀에서 바쁘게 일을 하고 있는 상황이다보니 해당 PR의 목적을 이해하기보단 코드 자체에 집중할 수밖에 없는 상황이었다. 그래도 다행이었던 점은 회사에서 오랫동안 근무하며 넓은 범위를 이해하고 있는 개발자들이 많이 있었다는 점이었다. 그들은 별도의 설명이 없어도 코드의 히스토리를 잘 알고 있었기에 자세한 설명이 없어도 비교적 수월하게 리뷰를 진행할 수 있는 장점이 있었다.</p>
<p>하지만 최근에 입사한 분들은 코드만 가지고 피드백 할 수 있는 부분에 한계가 있었으며 필자처럼 Python/Django 개발 경험이 없던 개발자 입장에서는 더더욱 기여를 할 수 있는 부분이 거의 없었다. 또한 과거에 필자가 코드 리뷰를 하면서 느꼈던 큰 한계점 중에 하나가 있었는데 바로 설계에 대한 부분이었다. 데이터 모델링이나 API Spec 설계 같은 경우 코드 전체적으로 중요한 영향을 끼치며 한번 결정되면 추후에 바꾸기가 쉽지 않다. 그럼에도 불구하고 코드 리뷰 단계에서 관련하여 개선 피드백이 나와도 반영하기가 쉽지 않다. 왜냐하면 설계가 바뀌면 이미 작성된 코드의 상당 부분을 재작성해야하는 경우가 생기며 리뷰를 받는 시점에서는 이미 릴리즈를 앞둔 경우가 많기 때문이다. 누군가는 리뷰 과정에서 개선점이 발견되면 당연히 수정되어야 하는 것 아니냐고 생각할 수도 있다. 사실 필자도 그렇게 생각했다. 하지만 릴리즈 시점은 여러 이해가 얽혀있는 경우가 많으며, 개발자 개인이 그런 압박을 견디면서 릴리즈를 미루기는 쉽지가 않다. 실제로 많은 부분이 수정을 해야하기 때문에 비효율이 발생된다. 이런 상황이 반복되다보면 오히려 거대한 레거시가 금방 쌓이게 되고 피드백은 단순하고 큰 가치 없는 내용이 주를 이루게 된다. </p>
<h2 id="테크스펙-도입"><a href="#테크스펙-도입" title="테크스펙 도입"></a>테크스펙 도입</h2><p>이런 여러가지 문제를 해소하기 위한 방안으로 코딩을 하기 전에 테크 스펙을 작성하고 리뷰를 하는 과정을 두게 되었다. 테크 스펙의 내용은 극히 일부의 내용을 제외하고는 기술 독립적이며, 목적이나 의도, 기획 내용 등이 같이 기재되어 있기 때문에 개발자라면 누구나 이해하고 리뷰할 수 있다. 또한 개발의 초기 시점에 진행되기 때문에 설계가 변경되더라도 비용이 적게 든다. 오히려 코드가 없기 떄문에 설계나 의도 그 자체에 더 집중할 수 있게 된다. 이것을 통해서 어떤 문제를 해결하고자 했는지 구성원들의 공감대가 있었기 때문에 어찌보면 번거로울수도 있는 과정이 하나 더 생겼음에도 불구하고 모두가 열심히 참여해주었다.</p>
<p><img src="https://wonderer80.github.io/images/tech_spec.png" alt="테크 스펙" title="설계가 잘되면 그 뒤 개발은 쉽다"></p>
<h2 id="명시적-리뷰어"><a href="#명시적-리뷰어" title="명시적 리뷰어"></a>명시적 리뷰어</h2><p>초기에는 백엔드 개발자가 몇명 없었고 동시에 진행되는 업무도 많지 않았기 때문에 별도의 리뷰어를 지정하지 않아도 어느 정도 리뷰가 진행되었지만 인원이 늘어나기 시작하면서 생성되는 PR이 많아지니 리뷰가 밀리거나 방치되는 상황이 발생되었다. 리뷰의 중요성에 대해 설명을 하는 것만으로는 부족했다. 명시적으로 리뷰어를 지정하는 것이 좋겠다는 판단이 들었지만 어떻게 지정해야할지 고민이었다. 그 와중에 팀원 분의 아이디어로 리뷰 마니또 라는 제도를 시작하게 되었다. 리뷰 마니또는 본인이 속하지 않은 도메인의 개발자 중에서 랜덤으로 뽑게 되는데 한달동안 본인의 리뷰 요청을 전담해주게 된다. 리뷰는 기본적으로 자신의 속한 도메인 내의 개발자 1명 이상과 리뷰 마니또가 해주게 되는데 리뷰 마니또는 본인이 속한 도메인이 아니기 때문에 이해하기 어려운 코드나 문서를 더 잘 인지하고 피드백할 수 있게 된다.</p>
<p><img src="https://wonderer80.github.io/images/review_manito.png" alt="리뷰 마니또" title="맘편히 리뷰 요청할 수 있는 동료"></p>
<h2 id="피드백-중요도-표기"><a href="#피드백-중요도-표기" title="피드백 중요도 표기"></a>피드백 중요도 표기</h2><p>코드 리뷰를 진행할 때 남기는 댓글이 모호하게 느껴질 때가 있다고 생각이 드는 경우가 많았다. 그냥 참고하라는 이야기인지, 꼭 반영이 되었으면 하는 내용인지, 리뷰를 하는 사람이 어느 정도의 중요성을 가지고 말했는지 애매할 때가 있다. 리뷰를 하는 과정에서 조심스럽게 전달하다보니 그런 경우가 생기는 것이겠지만 한편으로는 비효율적으로 느껴질 때도 많았다. 이런 부분을 좀 더 명확하게 하고 싶어서 중요도를 달 수 있도록 정의했다. github saved reply 기능을 이용하여 리뷰하는 과정에서 편리하게 중요도를 선택해서 남길 수 있게 하였다. L1에서 L3까지는 반드시 합의를 통해서 resolve가 되어야 하며 L4, L5나 반드시 반영하지 않아도 머지할 수 있도록 구분해두었다.</p>
<p><img src="https://wonderer80.github.io/images/review_comment.png" alt="Code Review시 말머리 가이드" title="Level별로 중요도가 나눠진다"></p>
<h2 id="JIRA-Workflow와-통합"><a href="#JIRA-Workflow와-통합" title="JIRA Workflow와 통합"></a>JIRA Workflow와 통합</h2><p>리뷰 요청 방식도 여러번 개선되었다. 요청 시 필요한 정보들이 추가되고 슬랙 워크플로우 기능을 이용해서 템플릿을 제공했다. 근데 요청되는 리뷰가 많아지니 슬랙으로는 내가 요청 받은 리뷰를 확인하는 것이 점점 어려워졌다. 업무에서 JIRA를 활용하고 있으니 자연스럽게 workflow를 연동하자는 의견이 나왔다. 현재는 리뷰 요청하는 과정을 JIRA의 워크플로우와 통합하여 JIRA에 리뷰 관련 정보를 기입하고 상태를 변경하면 자동으로 슬랙으로 발송된다. 또한 리뷰용 지라 대시보드 구성을 통해서 현재 진행되고 있는 전체 리뷰 상황과 나에게 할당된 리뷰도 볼 수 있게 되었다.</p>
<p><img src="https://wonderer80.github.io/images/review_jira.png" alt="JIRA와 리뷰 연동" title="지라이슈가 리뷰상태가 되면 자동으로 슬랙이 발송된다"></p>
<h2 id="지속적인-개선이-중요하다"><a href="#지속적인-개선이-중요하다" title="지속적인 개선이 중요하다"></a>지속적인 개선이 중요하다</h2><p>그 외에도 자세하게 기술하지 않은 수많은 개선사항이 있었고 필자는 여전히 개선해야할 부분이 있다고 생각한다. 필자가 이 글에서 결국 전달하고 싶었던 부분은 우리가 현재 어떤 것을 하고 있는가를 얘기하는 것이 아니다. 오히려 맹목적으로 다른 조직이 하는 것을 그대로 따라하는 것을 경계하라고 하고 싶다. 핵심은 우리가 수행하고 있는 프로세스의 목적을 이해하고 지속적으로 개선해나가는 과정이다. 또한 그러한 과정은 특정 한두명이 하는 것이 아니라 구성원들의 참여로 이루어지도록 해야한다. 리더는 구성원들이 이런 의견을 자유롭게 내고 실행할 수 있는 환경을 마련해주는 역할을 해야하고, 혹시나 원래의 목적을 잃고 관습적으로 실행하고 있는 부분은 없는지 살펴야 한다.</p>
<p>다른 조직들의 리뷰 문화나 프로세스를 보면 우리가 하는 것은 보잘것없고 부족해보일 수도 있다. 하지만 정말 부끄러워해야하는 것은 그저 원래 해왔으니까, 남들도 다 하니까 따라 하는 모습일 것이다. 특정 한명의 이상과 역량이 아무리 높을지라도 결국 조직은 구성원들의 평균 수준에 수렴한다. 변화가 한순간에 이루어질 것이라고 기대하는 것은 환상이다. 구성원들과 함께 걸어가며 성장해야 진정한 변화를 이룰 수 있다. 이 글을 통해 코드 리뷰와 관련해서 우리가 지금 관습적으로 하고 있는 것은 없는지 한번 살펴보고, 아이디어를 얻어 가셨으면 하는 바람이다. </p>

    </article></div>

wonderland

지난 번 글에 이어 이번 글에서는 필자가 속한 조직에서 필자가 입사했을 때 당시의 시점에서부터 현재까지 코드 리뷰 과정에서의 고민과 변화들을 이야기해보도록 하겠다.
코드 리뷰를 처음 도입하는 회사들은 Github의 PR(Pull Request) 리뷰에서 시작하게 되는 경우가 많다. 하지만 처음에는 어떤 식으로 리뷰를 해야하는지 잘 모르기 때문에 로직적으로 결함이 있는지, 컨벤션은 준수되었는지와 같은 코드 스타일을 주로 본다. 필자가 입사 했을 때 당시에도 주로 코드 스타일이나 로직에 대한 부분의 피드백이 중점적이었다. 그리고 테스트 코드를 도입한지 얼마 안된 상황이었다.
백엔드 개발자들끼리 비교적 활발하게 리뷰를 해주는 상황이긴 했지만 각자가 다른 팀에서 바쁘게 일을 하고 있는 상황이다보니 해당 PR의 목적을 이해하기보단 코드 자체에 집중할 수밖에 없는 상황이었다. 그래도 다행이었던 점은 회사에서 오랫동안 근무하며 넓은 범위를 이해하고 있는 개발자들이 많이 있었다는 점이었다. 그들은 별도의 설명이 없어도 코드의 히스토리를 잘 알고 있었기에 자세한 설명이 없어도 비교적 수월하게 리뷰를 진행할 수 있는 장점이 있었다.
하지만 최근에 입사한 분들은 코드만 가지고 피드백 할 수 있는 부분에 한계가 있었으며 필자처럼 Python/Django 개발 경험이 없던 개발자 입장에서는 더더욱 기여를 할 수 있는 부분이 거의 없었다. 또한 과거에 필자가 코드 리뷰를 하면서 느꼈던 큰 한계점 중에 하나가 있었는데 바로 설계에 대한 부분이었다. 데이터 모델링이나 API Spec 설계 같은 경우 코드 전체적으로 중요한 영향을 끼치며 한번 결정되면 추후에 바꾸기가 쉽지 않다. 그럼에도 불구하고 코드 리뷰 단계에서 관련하여 개선 피드백이 나와도 반영하기가 쉽지 않다. 왜냐하면 설계가 바뀌면 이미 작성된 코드의 상당 부분을 재작성해야하는 경우가 생기며 리뷰를 받는 시점에서는 이미 릴리즈를 앞둔 경우가 많기 때문이다. 누군가는 리뷰 과정에서 개선점이 발견되면 당연히 수정되어야 하는 것 아니냐고 생각할 수도 있다. 사실 필자도 그렇게 생각했다. 하지만 릴리즈 시점은 여러 이해가 얽혀있는 경우가 많으며, 개발자 개인이 그런 압박을 견디면서 릴리즈를 미루기는 쉽지가 않다. 실제로 많은 부분이 수정을 해야하기 때문에 비효율이 발생된다. 이런 상황이 반복되다보면 오히려 거대한 레거시가 금방 쌓이게 되고 피드백은 단순하고 큰 가치 없는 내용이 주를 이루게 된다. 
테크스펙 도입
이런 여러가지 문제를 해소하기 위한 방안으로 코딩을 하기 전에 테크 스펙을 작성하고 리뷰를 하는 과정을 두게 되었다. 테크 스펙의 내용은 극히 일부의 내용을 제외하고는 기술 독립적이며, 목적이나 의도, 기획 내용 등이 같이 기재되어 있기 때문에 개발자라면 누구나 이해하고 리뷰할 수 있다. 또한 개발의 초기 시점에 진행되기 때문에 설계가 변경되더라도 비용이 적게 든다. 오히려 코드가 없기 떄문에 설계나 의도 그 자체에 더 집중할 수 있게 된다. 이것을 통해서 어떤 문제를 해결하고자 했는지 구성원들의 공감대가 있었기 때문에 어찌보면 번거로울수도 있는 과정이 하나 더 생겼음에도 불구하고 모두가 열심히 참여해주었다.
명시적 리뷰어
초기에는 백엔드 개발자가 몇명 없었고 동시에 진행되는 업무도 많지 않았기 때문에 별도의 리뷰어를 지정하지 않아도 어느 정도 리뷰가 진행되었지만 인원이 늘어나기 시작하면서 생성되는 PR이 많아지니 리뷰가 밀리거나 방치되는 상황이 발생되었다. 리뷰의 중요성에 대해 설명을 하는 것만으로는 부족했다. 명시적으로 리뷰어를 지정하는 것이 좋겠다는 판단이 들었지만 어떻게 지정해야할지 고민이었다. 그 와중에 팀원 분의 아이디어로 리뷰 마니또 라는 제도를 시작하게 되었다. 리뷰 마니또는 본인이 속하지 않은 도메인의 개발자 중에서 랜덤으로 뽑게 되는데 한달동안 본인의 리뷰 요청을 전담해주게 된다. 리뷰는 기본적으로 자신의 속한 도메인 내의 개발자 1명 이상과 리뷰 마니또가 해주게 되는데 리뷰 마니또는 본인이 속한 도메인이 아니기 때문에 이해하기 어려운 코드나 문서를 더 잘 인지하고 피드백할 수 있게 된다.
피드백 중요도 표기
코드 리뷰를 진행할 때 남기는 댓글이 모호하게 느껴질 때가 있다고 생각이 드는 경우가 많았다. 그냥 참고하라는 이야기인지, 꼭 반영이 되었으면 하는 내용인지, 리뷰를 하는 사람이 어느 정도의 중요성을 가지고 말했는지 애매할 때가 있다. 리뷰를 하는 과정에서 조심스럽게 전달하다보니 그런 경우가 생기는 것이겠지만 한편으로는 비효율적으로 느껴질 때도 많았다. 이런 부분을 좀 더 명확하게 하고 싶어서 중요도를 달 수 있도록 정의했다. github saved reply 기능을 이용하여 리뷰하는 과정에서 편리하게 중요도를 선택해서 남길 수 있게 하였다. L1에서 L3까지는 반드시 합의를 통해서 resolve가 되어야 하며 L4, L5나 반드시 반영하지 않아도 머지할 수 있도록 구분해두었다.
JIRA Workflow와 통합
리뷰 요청 방식도 여러번 개선되었다. 요청 시 필요한 정보들이 추가되고 슬랙 워크플로우 기능을 이용해서 템플릿을 제공했다. 근데 요청되는 리뷰가 많아지니 슬랙으로는 내가 요청 받은 리뷰를 확인하는 것이 점점 어려워졌다. 업무에서 JIRA를 활용하고 있으니 자연스럽게 workflow를 연동하자는 의견이 나왔다. 현재는 리뷰 요청하는 과정을 JIRA의 워크플로우와 통합하여 JIRA에 리뷰 관련 정보를 기입하고 상태를 변경하면 자동으로 슬랙으로 발송된다. 또한 리뷰용 지라 대시보드 구성을 통해서 현재 진행되고 있는 전체 리뷰 상황과 나에게 할당된 리뷰도 볼 수 있게 되었다.
지속적인 개선이 중요하다
그 외에도 자세하게 기술하지 않은 수많은 개선사항이 있었고 필자는 여전히 개선해야할 부분이 있다고 생각한다. 필자가 이 글에서 결국 전달하고 싶었던 부분은 우리가 현재 어떤 것을 하고 있는가를 얘기하는 것이 아니다. 오히려 맹목적으로 다른 조직이 하는 것을 그대로 따라하는 것을 경계하라고 하고 싶다. 핵심은 우리가 수행하고 있는 프로세스의 목적을 이해하고 지속적으로 개선해나가는 과정이다. 또한 그러한 과정은 특정 한두명이 하는 것이 아니라 구성원들의 참여로 이루어지도록 해야한다. 리더는 구성원들이 이런 의견을 자유롭게 내고 실행할 수 있는 환경을 마련해주는 역할을 해야하고, 혹시나 원래의 목적을 잃고 관습적으로 실행하고 있는 부분은 없는지 살펴야 한다.
다른 조직들의 리뷰 문화나 프로세스를 보면 우리가 하는 것은 보잘것없고 부족해보일 수도 있다. 하지만 정말 부끄러워해야하는 것은 그저 원래 해왔으니까, 남들도 다 하니까 따라 하는 모습일 것이다. 특정 한명의 이상과 역량이 아무리 높을지라도 결국 조직은 구성원들의 평균 수준에 수렴한다. 변화가 한순간에 이루어질 것이라고 기대하는 것은 환상이다. 구성원들과 함께 걸어가며 성장해야 진정한 변화를 이룰 수 있다. 이 글을 통해 코드 리뷰와 관련해서 우리가 지금 관습적으로 하고 있는 것은 없는지 한번 살펴보고, 아이디어를 얻어 가셨으면 하는 바람이다.

코드 리뷰 개선해나기기

댓글