<div id="readability-page-1" class="page"><div id="post-content" itemprop="articleBody"><figure>
    <span>
      <a href="/static/894837106cb21b13b125bbca910f0f96/0047d/cat.jpg" target="_blank" rel="noopener">
    <span></span>
  <img alt="코드 리뷰" title="코드 리뷰" src="https://jeonghwan-kim.github.io/static/894837106cb21b13b125bbca910f0f96/fee13/cat.jpg" sizes="(max-width: 726px) 100vw, 726px" loading="lazy" decoding="async">
  </a>
    </span>
    <figcaption>코드 리뷰</figcaption>
  </figure>
<p>코드 리뷰를 시작하지 일 년이 지났다. 그 전에는 혼자 일하다 보니 다른 사람의 코드를 읽을 일이 없었고, 팀원이 몇 명 있긴 했지만 모두 다른 직군이었다. 재작년부터는 프론트엔드 개발자 여섯 분과 함께 일하면서 비로소 코드 리뷰할 기회가 생겼다.</p>
<p>사실 리뷰에 크게 신경 쓰지 않았다. 지금까지는 별다른 어려움 없이 작업해왔기에 코드 리뷰의 중요성을 실감하지 못했다. 이 팀에 새로 합류하면서 기존의 코드 리뷰 문화를 받아들여야 했고, 처음부터 익숙해지기는 어려웠다. 여러 시행착오를 겪으며 배우는 과정이 지난 1년 남짓이었다.</p>
<p>이제 코드 리뷰가 일상이 되었고, 매일 일정 시간을 할애해 동료의 코드를 리뷰한다. 동료에게 의견을 받아 코드를 수정하고 다시 리뷰를 요청하기도 한다. 매일 아침 '어떤 리뷰가 도착했을까?', '오늘은 어떤 코드를 구경할 수 있을까?'하는 기대감을 안고 출근한다.</p>
<p>그동안 경험한 코드 리뷰의 효과를 몇 가지로 정리해 본다.</p>
<h2 id="컨벤션-협의"><a href="#%EC%BB%A8%EB%B2%A4%EC%85%98-%ED%98%91%EC%9D%98" aria-label="컨벤션 협의 permalink"></a>컨벤션 협의</h2>
<p>일곱 명이 함께 개발하는 프로젝트에서는 다양한 코딩 스타일이 존재한다. 혼자 개발할 때는 문제가 없지만, 여러 사람이 코드를 공유하는 환경에서는 들여쓰기 방식이나 변수 이름을 정하는 규칙 따위의 컨벤션이 중요했다. 코드의 형식이 제각각이면 다른 사람의 의도를 파악하는 데 품이 더 들기 때문이다.</p>
<p>이러한 컨벤션은 하루 아침에 정해지는 것이 아니다. 그동안 에어비앤비 스타일 가이드라인이나 자바스크립트 표준 컨벤션을 따르며 취향 없이 정해진 규칙을 사용했다. 하지만 오래된 제품일수록 이전 동료들이 겪은 시행착오가 린트 룰과 코드 스타일에 반영되어 있다. 이러한 결과물이 나오기까지 코드 리뷰가 <strong>기점</strong>이 되었다.</p>
<p>예를 들어, 코드 리뷰를 하면서 <em>'리스트에서 렌더링할 때 인덱스를 키로 사용해도 괜찮을까?'</em> 라는 의문이 들 수 있다. 리뷰어는 리액트 가이드라인에 따라 아이디 사용을 기대했을 것이고, 반면 작성자는 정적 리스트라 인덱스를 사용해도 괜찮다고 생각했을 것이다. 우리는 코드 리뷰의 쓰레드에서 서로의 생각을 자연스럽게 말하고 논의했다. 필요하다면 이 주제로 회의를 준비해 논의를 확장할 수도 있었다.</p>
<h2 id="경험과-노하우-공유"><a href="#%EA%B2%BD%ED%97%98%EA%B3%BC-%EB%85%B8%ED%95%98%EC%9A%B0-%EA%B3%B5%EC%9C%A0" aria-label="경험과 노하우 공유 permalink"></a>경험과 노하우 공유</h2>
<p>이제 막 합류한 팀원의 코드에서 크로스브라우징 이슈가 발견되었다. 이런 문제는 QA 과정에서 발견될 수도 있지만, 여기서 잡지 못하면 사용자에게까지 영향을 미칠 수 있다. 어플리케이션의 잠재적 버그다. 배포 전에 동료가 리뷰를 통해 자신의 경험을 공유했고, 작성자가 이를 반영한 덕분에 <strong>문제를 예방</strong>할 수 있었다.</p>
<p>또한, 코드베이스가 커질수록 기존 함수나 모듈을 찾지 못하고 중복 코드를 작성하는 경우가 생길 수 있다. 오랫동안 프로젝트를 경험한 동료가 리뷰를 진행한다면 <em>"이전에 XX님이 작성한 모듈과 기능이 겹치는 것 같아요."</em> 같은 짧은 피드백만으로도 중복을 줄일 수 있다. 작성하는 감사한 마음으로 기존 모듈을 활용할 것이고, 이를 통해 코드의 일관성을 유지하면서도 불필요한 반복 작업을 줄일 수 있었다.</p>
<h2 id="라이브러리-사용법-학습"><a href="#%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EC%82%AC%EC%9A%A9%EB%B2%95-%ED%95%99%EC%8A%B5" aria-label="라이브러리 사용법 학습 permalink"></a>라이브러리 사용법 학습</h2>
<p>로대시를 사용하지만, 실제로 활용해 본 함수는 제한적이다. 동료의 코드를 읽다 보면 익숙하지 않은 다양한 로대시 함수를 접하게 된다. flow, compact, difference 같은 함수들이다. 문서를 들추어 보면서 <em>'아, 이런 함수가 있었구나!'</em> 하고 배우게 된다. 이후에 내 코드에도 자연스럽게 활용할 수 있었다.</p>
<p>비교적 늦게 리액트 쿼리를 도입했다. 담당 동료는 도입 과정에서 여러 후보를 비교해 팀원들의 생각을 파악할 목적으로 코드 리뷰를 활용했다. 특정 지면을 리액 쿼리로 만든 1안, SWR로 만든 2안을 작성한 뒤, 두 가지 코드 변경사항을 만들어 리뷰를 요청했다. 우리는 각 안을 분석하고 장단점을 리뷰 형태로 공유했다. 다양한 의견을 얘기했고 이를 취합한 뒤 자신있게 <strong>리액트 쿼리를 팀에 도입</strong>할 수 있었다.</p>
<p>신규 라이브러리를 도입할 때 문서만으로 파악할 수도 있지만, 코드 리뷰를 통해 더 효과적으로 익힐 수 있다. 특이 이미 리액트 쿼리를 경험한 동료가 코드 리뷰에서 적극적으로 자신의 경험을 공유해 주는 것은 큰 자산이 되었다. 예를 들어, 쿼리 키를 관리하는 방법, 옵션 객체의 의미와 정확한 역할 같은 내용은 문서만으로는 이해하기 어려운 부분이었다. 설령 정보를 찾더라도 베스트 프랙티스를 확신하기 어려운 경우가 많다. 하지만 경험자의 피드백은 <strong>실전에서 검증된 확실한 정보</strong>였다. 이를 통해 우리는 더욱 자신 있게 라이브러리를 활용할 수 있었다.</p>
<h2 id="코드-리뷰를-대하는-자세"><a href="#%EC%BD%94%EB%93%9C-%EB%A6%AC%EB%B7%B0%EB%A5%BC-%EB%8C%80%ED%95%98%EB%8A%94-%EC%9E%90%EC%84%B8" aria-label="코드 리뷰를 대하는 자세 permalink"></a>코드 리뷰를 대하는 자세</h2>
<p>코드 리뷰가 불화를 초래할 수 있다는 우려를 담은 글을 본 적이 있다. 직접 리뷰를 하다 보니, 그 말이 완전히 틀린 것만은 아니었다. 리뷰어의 질문이 마치 나를 지적하는 것으로 느껴져 마음이 상하기도 했고, 일이 끝난 후에도 계속 신경이 쓰이는 경우가 있었다.</p>
<p>그렇다면 나도 다른 사람의 코드에 피드백을 줄 때 좀 더 신중할 필요가 있다. <strong>"대인춘풍 지기추상"</strong> 이란 표현처럼, 동료에게는 부드럽고 따뜻한 태도로, 자신에게는 엄격한 자세를 가져야겠다. 너무 짧지 않게, 너무 직설적이지 않게, 최대한 부드럽고 명확하게 의견을 전달해야 한다. 특히 토론 경험이 많지 않은 나에게는 더욱 중요한 일이다. 단순히 내 생각을 말했을 뿐인데 상대방이 기분 나빠했던 경험이 있지 않은가? 하물며 직접 얼굴을 마주하지 않는 온라인 환경에서는 더욱 조심스럽게 표현할 필요가 있다.</p>
<p>리뷰를 받을 때는 좀 더 담담한 태도가 필요하다. 리뷰어도 기본적으로 내 코드가 더 나아지길 바라는 마음에서 피드백을 주는 것이기 때문이다. 다만 표현이 서툴거나 다소 직설적일 수 있을 뿐이다. 또한, "원래 저 사람 스타일이 저렇지." 하고 가볍게 넘기는 여유도 필요하다. 중요한 것은 리뷰어의 말투가 아니라, 내가 만든 <strong>코드에 대한 의견을 얻는 것</strong>이기 때문이다.</p>
<p>아무리 내가 잘못했더라도, 이를 지적받는 것은 불편할 수 있다. 마치 감기약이 쓰듯이 말이다. 하지만 그 불편함을 받아들이고 소화해야만 더 나은 코드를 만들 수 있고, 팀에 더 뜻있게 기여할 수 있을 것이다.</p>
<h2 id="결론"><a href="#%EA%B2%B0%EB%A1%A0" aria-label="결론 permalink"></a>결론</h2>
<p>올해는 어떤 코드 리뷰 문화를 경험하게될지 기대된다. 각자 쌓아온 경험과 노하우를 바탕으로 더욱 탄탄한 개발팀이 되었다. 서로의 의견을 주고받으며, 더욱 가치 있고 재미있는 개발 문화가 만들어지기를 바란다. 코드 리뷰가 단순한 피드백을 넘어, 서로를 성장시키고 더 나은 결과를 만들어가는 과정이 되면 좋겠다.</p></div></div>

코드 리뷰: 협업으로 배우고 성장하기

댓글