SR3. 개발 내용 크로스 점검이 중요한 까닭

지속가능한 기술력 핵심은 ‘코드 리뷰’
개발자 떠나도 제품 연속성 유지 가능

342호 (2022년 04월 Issue 1)

Article at a Glance

많은 기업이 박차를 가하는 디지털 트랜스포메이션에는 탄탄한 엔지니어링 기술력이 뒷받침돼야 한다. 뛰어난 기술력의 핵심은 결국 코드다. 글로벌 IT 기업뿐만 아니라 네이버, 카카오 등 국내 IT 대기업에서는 더 나은 코드를 만들기 위한 코드 리뷰 활동이 필수 프로세스로 자리 잡았다. 코드 리뷰의 주요 장점은 다음과 같다.

1. 제품 개발 과정에서의 노하우를 동료 개발자로부터 전수받을 수 있다.

2. 제품의 맥락을 공유할 수 있어 중요한 지식과 노하우를 가진 특정 개발자들이 회사나 팀을 떠나도 제품의 연속성을 유지할 수 있다.

3. 더 많은 개발자가 코드 전반에 대해 이해하고 있어 예기치 못한 장애가 발생했을 때 더 빠르게 대응할 수 있다.

4. 자신의 작업 내용에 대해 잘 알고 있는 동료들과 팀에 대한 신뢰와 안정감이 높아진다.



2021년 10월 KT 통신망 장애가 발생했다. 이 장애로 약 1시간 동안 KT 이용자들이 인터넷과 유무선망을 사용할 수 없었다. 그야말로 전국이 패닉에 빠졌다. 일부 식당에서는 포스(POS, 판매 시점 정보 관리 시스템) 단말기가 작동하지 않아 카드 결제를 못하고 실내 시설 입장 시 QR 체크를 못하는 등 일상생활에서 많은 불편을 겪었다.

KT가 발표한 공식 사고 원인은 ‘EXIT’1 명령어를 빠뜨린 실수였다. 이 작은 실수는 전국의 통신 대란으로 번졌다. 백업 시스템 미비, 사전 테스트 부재, 사용자가 많은 낮 시간대 작업 등 피해를 키운 여러 요인이 있었을 것이다. 개발자 입장에서는 그중에서도 장애의 핵심 원인이었던 코드 실수 부분이 안타깝게 다가왔다. 개발자는 분명 컴퓨터와 가장 가까이에서 소통하는 사람이지만 컴퓨터가 아니다. 실수를 하기 마련이다. 작업 전 함께 일하는 동료들과 코드 리뷰(Code Review)를 제대로 했다면 사고를 막을 수 있지 않았을까?

정보기술(IT) 없는 비즈니스는 이제 상상하기 어려운 시대다. 많은 기업이 박차를 가하는 디지털 트랜스포메이션에는 탄탄한 엔지니어링 기술력이 뒷받침돼야 한다. 뛰어난 기술력의 핵심은 결국 코드다. 직접적이고 에러 처리가 잘돼 있으며 군더더기 없이 깔끔한 클린 코드(Clean code)는 비즈니스 요구 사항을 잘 쌓아 올릴 수 있는 바탕이 된다. 클린 코드가 곧 제품의 품질로 연결되는 셈이다. 그리고 이 클린 코드를 만들기 위한 활동 중 하나가 바로 코드 리뷰다.

글로벌 IT 기업뿐만 아니라 네이버, 카카오 등 국내 IT 대기업에서는 이미 코드 리뷰가 필수 프로세스로 자리 잡았다. 우아한형제들, 토스 등 빠르게 성장하는 스타트업 역시 각 회사의 코드 리뷰 문화를 소개하며 코드 리뷰 활동을 자사 홍보 수단으로 활용하기도 한다. 많은 개발자가 좋은 코드 리뷰 문화가 있는 곳에서 일하고 싶다고 손꼽을 정도로 코드 리뷰는 좋은 회사의 지표로 자리매김하고 있다.

047


코드 리뷰란 무엇인가

코드 리뷰란 개발자의 작업물을 한 명 또는 여러 명의 개발자가 점검하는 활동이다. 더 나은 클린 코드를 만들기 위해 함께 코드를 점검하고 개선하는 것이다. 프로젝트 시작에 앞서 제안서를 검토하고 시뮬레이션 결과를 확인하듯 코드를 실제 제품에 반영하기 전 작업 코드를 함께 살펴보는 활동으로 개발자 협업의 한 방법이다.

코드 리뷰의 구체적인 과정은 다음과 같다. 먼저 코드 작성자는 코드 리뷰 도구를 이용해 코드 변경 내용과 작업 내역을 정리해 동료 개발자 혹은 작업 관련자들에게 코드 리뷰를 요청한다. 요청받은 리뷰어는 코드 작업 내용을 검토한 뒤 피드백을 준다. 코드 작성자는 이를 반영해 다시 리뷰를 받는다. 한 명 혹은 여러 명의 리뷰어가 코드 리뷰를 승인(approval)하면 작업 내용은 소프트웨어 제품의 코드 베이스(Code Base)2 로 병합되고 배포(release) 과정을 거쳐 제품의 일부로 자리 잡는다.

048


코드 리뷰의 효과는 오랜 기간에 거쳐 증명됐다. 코드 리뷰는 1976년 마이클 페이건(Michael Fagan) 당시 IBM 개발 매니저(Product development manager)가 연구한 ‘설계와 코드 검증(Design and code inspection)’3 이라는 논문에서 처음 발표된 것으로 알려져 있다. 페이건 검사(Fegan inspection)는 소스 코드 내의 결함을 찾기 위해 복수의 참여자가 여러 단계의 검증 절차를 진행하는 방식으로 이뤄졌다. 이 검증 절차를 통해 결함률을 낮춰 개발 비용을 절감하고 제품의 품질도 높아진 것으로 나타났다.

소프트웨어 업계의 구루인 스티브 맥코넬(Steve McConnell)이 쓴 『코드 컴플리트(Code Complete)』에서도 다음과 같이 코드 리뷰의 효과를 설명한다.

“소프트웨어 테스트만으로는 효과가 제한적이다. 평균적으로 유닛 테스트4 로는 25%, 기능 테스트5 로 35%, 통합 테스트6 를 통해서는 45%의 결함을 감지할 수 있었다. 하지만 디자인 및 코드 검증을 통해서는 평균적으로 55∼60%의 효율을 이끌어 낼 수 있었다.”

“코드 리뷰가 도입되기 전에는 코드 한 줄의 유지•보수 변경 사항 중 55%가 오류였다. 하지만 리뷰가 도입된 후 변경 사항 중 단 2%만이 오류로 발견됐다.”

“같은 그룹 내 11개 프로그램이 개발됐다. 그중 5개는 코드 리뷰 없이, 6개는 리뷰와 함께 진행됐다. 리뷰가 없었던 5개 프로그램에서는 코드 100줄당 평균 4.5개의 오류가 발견됐다. 리뷰가 진행된 6개 프로그램에서는 코드 100줄당 0.82개의 오류가 발생했다. 리뷰를 통해 오류가 80% 이상 감소한 것이다.”

이처럼 코드 리뷰를 하면 잠재된 오류를 조기 발견하고 코드의 개선 가능성을 검토해 소프트웨어의 품질을 높일 수 있다. 이런 이유로 글로벌 IT 기업은 코드 리뷰를 일찍이 도입했다. 자유로운 조직 문화의 대명사 구글은 코드 리뷰만큼은 꼼꼼하고 체계적인 절차로 진행하기로 유명하다. 실제로 사내의 코드 리뷰 가이드 문서7 를 대외적으로 공개해 코드 리뷰 문화를 모든 개발자에게 장려하고 있다. 마이크로소프트 역시 개발자 75%가 매일 코드 리뷰를 진행하는 등 코드 개발뿐만 아니라 코드 리뷰도 주요 업무로 삼고 있다.8

메타(구 페이스북)에서는 코드 리뷰 승인을 받지 못하면 작업한 코드가 제품에 반영되지 않는다. 즉, 제품 출시를 위해서는 코드 리뷰가 필수인 셈이다. 또한 신규 입사자들은 코드 리뷰와 함께 메타 개발자로서 첫걸음을 내딛는다. 신규 입사자들은 메타에서 사용되는 기술과 시스템에 대한 교육 과정인 부트 캠프에 참여하는데 이 과정에서 실제 제품과 관련된 다양한 이슈를 선임 개발자들과 함께 코드 리뷰하며 해결해 나간다.9

코드 리뷰를 통해 신규 입사자는 거대한 코드 구조에 익숙해질 수 있다. 또한 다양한 팀의 개발자들과 소통하며 해당 팀의 구성원들은 누구인지, 나와 맞는 팀인지 등을 미리 알아볼 수 있으며 부트캠프가 끝날 때쯤 인터뷰를 통해 합류할 팀을 선택한다. 이처럼 코드 리뷰는 소프트웨어 제품의 결함을 찾는 것뿐만 아니라 신규 입사자 온보딩, 개발자 성장 등 다양한 목적으로 진행되고 있다.

왜 코드 리뷰를 해야 하는가

개발 환경과 도구의 눈부신 발전으로 코드 리뷰 방식 또한 진화하고 있다. 최근에는 코드 리뷰 도구에서 제공하는 기능을 통해 오타나 작은 오류들은 미리 확인할 수 있다. 또 테스트 자동화로 사람의 개입 없이 수많은 테스트 사례를 실행해보고 결과 리포트까지 정리해 주는 도구들도 개발됐다. 이를 통해 기업은 시간과 노력을 크게 절약하면서 제품의 품질까지 높일 수 있게 됐다.

이처럼 자동화로 코드 결함을 찾을 수 있다면 개발자가 직접 하는 코드 리뷰는 더 이상 필요 없는 걸까? 그렇지 않다. 코드 리뷰의 필요성과 중요성은 오히려 커지는 추세다.

050


1. 빨리 가는 유일한 방법은 제대로 가는 것이다

시장 변화가 가속화되면서 기업은 빠르게 변화를 받아들이고 더 많은 기회를 찾기 위해 도전을 이어가고 있다. 특히 코로나 팬데믹 이후 IT 업계는 호황을 누리고 있다. 비대면의 일상화로 이커머스 시장은 어느 때보다도 빠르게 성장하고 있고 국내 웹툰과 웹소설은 글로벌 시장을 단번에 휘어잡고 있다. 기업들은 공격적으로 개발자를 채용하며 더 큰 도약을 준비하는 모습이다.

늘어난 개발자만큼 소프트웨어 역시 빠르게 성장하고 있을까? 프로그래머 로버트 마틴(Robert Martin)이 쓴 책 『클린 아키텍처(Clean Architecture)』는 클린 코드에 대한 고민 없이 그저 개발 인력만을 늘리는 상황이 기업에 어떤 위기를 가져 오는지 이야기한다. [그림 2]는 소프트웨어 제품의 주요 출시 때마다의 생산성과 코드 라인당 비용을 보여주는 익명의 회사 데이터다. 이 회사는 새로운 출시 때마다 개발자를 지속적으로 채용했다. 초기에는 늘어나는 개발자 수만큼 생산성이 증가한다. 하지만 생산성이 어느 수준에 이르자 개발자 수가 많아져도 생산성이 크게 늘지 않고 오히려 코드당 비용이 가파르게 증가한다. 이런 추세로는 비즈니스가 오래갈 수 없다. 급격한 비용 상승은 미래 수익을 고갈시키고 코드 한 줄을 추가하는 데도 큰 압박이 돼 결국 작은 기능 하나를 추가하는 데도 비싼 값을 치러야 하는 순간이 올 것이다.

레고 블록으로 1층짜리 집을 짓는다고 생각해보자. 방 하나를 더 만들고 싶으면 블록을 가져와 방을 하나 더 추가하면 된다. 하지만 5층을 쌓은 다음에서야 방 하나를 더 만들라는 요구 사항이 들어온다면 어떨까? 게다가 같이 블록으로 집을 짓던 작업자가 상의 없이 먼저 벽을 만드는 바람에 모든 벽에 창문이 없다는 것을 뒤늦게 발견했다. 그 와중에 또 다른 작업자는 6층을 쌓아버렸다. 빠르게 6층짜리 레고 건물을 쌓았지만 제대로 만들었다고 볼 수 없는 것이다. 새로운 요구 사항을 반영하지 못하고 잘못 구현된 결과물을 되돌리기 위해 결국 더 많은 시간과 리소스를 사용해야 한다.

이처럼 코드 리뷰는 함께 블록을 쌓아가는 과정과 같다. 다음에 어떤 모양의 블록을 쌓을지, 그리고 그 변화가 알맞은 방향인지를 끊임없이 소통하며 함께 작업하는 것이다. 미래에 벌어질 수 있는 문제들을 함께 고민해보고 미리 대비할 수 있게 해준다.

2. 점점 길어지는 코드의 수명

요즘 개발자들은 한 회사에 오래 머물러 있지 않는다. 새로운 도전을 위해 팀을 옮기거나 이직을 한다. 네이버, 카카오, 엔씨소프트 등 국내 IT 대기업의 평균 근속 연수는 6년 미만이다.10 이에 반해 네이버 검색 서비스는 1998년, 카카오톡 서비스는 2010년부터 10년 넘게 유지되고 있다. 소프트웨어 제품의 수명이 개발자들의 근속 연수보다 긴 셈이다.

중요한 지식과 노하우를 가진 특정 개발자들이 회사나 팀을 떠나게 된다면 그 어떤 장애보다도 더 큰 타격일 것이다. 개발자가 떠나더라도 코드는 반드시 유지돼야 한다. 코드 리뷰의 큰 장점 중 하나는 제품의 맥락(context)을 자연스럽게 공유할 수 있다는 점이다. 자신이 작업하지 않았어도 다른 개발자의 작업물을 보는 것만으로 제품의 기능과 흐름을 자연스럽게 익힐 수 있다. 이처럼 코드 리뷰는 지식 경영(knowledge management) 측면에서도 중요한 수단이다. 개발자가 떠나도 제품의 연속성을 유지하기 위해 코드 리뷰는 선택이 아닌 필수로 자리매김하고 있다.

코드 리뷰의 장점

1. 자연스러운 제품의 맥락 공유

최근 소프트웨어 제품들은 너무 크고 복잡해 개발자 한 명이 모든 작업을 다 하는 것은 불가능에 가까워졌다. 인터넷 쇼핑몰 내 제품 추천 화면을 상상해보자. 보이는 화면 뒤에는 추천을 위해 데이터를 모으는 기능, 데이터를 정제하는 작업, 추천 알고리즘 기능, 개인마다 각각의 다른 추천 제품을 알려주는 기능 등 복잡한 맥락이 숨어 있다. 각 분야 전문 개발자들과의 협업이 필수적인 환경인 셈이다.

과거에는 개발자라고 하면 컴퓨터 앞에서 큰 헤드셋을 끼고 모니터를 바라보며 홀로 개발 작업에 몰두한 모습을 흔히 상상했다. 하지만 최근 개발자들이 일하는 IT 기업 사무실과 코워킹 스페이스를 보면 칸막이를 없앤 개방된 공간으로 탈바꿈하고 있다. 경계를 허물고 소통을 장려하는 것이다.

코드 리뷰는 개발자들의 소통 방식이다. 자신이 가진 지식과 만들어낸 작업물을 동료들과 공유함으로써 정보가 끊임없이 흘러가도록 만들어준다. 제품 콘텍스트와 노하우가 코드 리뷰라는 물줄기를 통해 개발자들에게 퍼져나가는 것이다.

2. 동료로부터 배우는 현업 노하우

바야흐로 코딩 교육 전성시대다. SNS에서 ‘네카라쿠배당11 개발자 취업’을 내건 교육 광고를 심심치 않게 볼 수 있다. 서점에는 수많은 개발•기술 서적이 즐비하다. 개발자 입문의 턱은 계속 낮아지고 있다. 하지만 제품의 기능이 많아지고 더 많은 사용자를 소화하며 제품 규모가 커지다 보면 책에서는 볼 수 없었던 수많은 문제가 나타난다.

사용자가 끊임없이 접속하는 가운데 서비스 중단 없이 기능 추가 및 개선 작업이 필요하다고 가정해보자. 이렇게 서비스를 중단하지 않은 채 하는 중요한 작업을 ‘달리는 자동차의 바퀴를 교체하는 일’에 비유하기도 한다. 멈추지 않고 어느 정도의 속도로 달리면서 바퀴를 빼야 하는지 등 학원과 책을 통해서는 절대 배울 수 없는 노하우가 필요한 일이다.

코드 리뷰를 하면 제품을 개발하며 겪어온 노하우를 자연스레 전수할 수 있다. 코드 리뷰란 제품을 직접 만들고 있는 사람들이 주고받는 피드백 과정이기 때문이다. 자신이 해보지 못한 경험과 이를 통한 노하우를 현업 개발자의 코드 리뷰를 통해 전수받을 수 있다.

3. 안정감과 팀워크

처음 코드 리뷰를 시작하는 사람들이 가장 많이 힘들어하는 부분은 바로 부끄러움이다. 자신이 작업한 코드에 혹시 눈치채지 못한 실수가 있거나 동료들이 그걸 보고 비웃지 않을까 하는 막연한 두려움에 코드 리뷰 활동을 부담스러워하기도 한다. 하지만 정말 큰 서비스 장애나 문제를 겪어본 사람들은 알 것이다. 자신만 알고 있는 코드에 잠재된 문제가 나중에 서비스 장애로 돌아와 오히려 더 큰 비용을 지불해야 할 때 그 압박감은 이루 말로 다 표현할 수 없다. 더 많은 개발자가 코드 전반에 대해 이해하고 있으면 예기치 못한 장애가 발생했을 때 훨씬 더 빠르게 대응할 수 있다. 또 자신의 작업 내용을 잘 알고 있는 동료들이 사무실에 있기에 훨씬 가벼운 마음으로 휴가를 떠날 수도 있다.

코드 리뷰에 대한 오해

개발자 커리어 플랫폼 프로그래머스가 2020년 12월 개발자 5595명을 대상으로 조사한 결과12 경력 개발자들이 팀에 가장 도입하고 싶은 것으로 코드 리뷰가 3위, 도입 후 가장 후회한 것 역시 4위로 모두 상위 답변에 올랐다. 조사 결과는 많은 개발자가 코드 리뷰에 대한 환상을 가지고 도입했다가 씁쓸한 실패를 경험했음을 보여준다. 코드 리뷰를 제대로 이해하고 도입해야 이런 낭패를 막을 수 있다.

052


코드 리뷰 오해 1

코드 리뷰를 하면 코드가 완벽해진다

코드 리뷰는 더 나은 코드를 만들기 위한 활동이다. 하지만 세상에 완벽한 코드는 없다. 더 나은 코드만 있을 뿐이다. 완벽한 코드에 집착하다 보면 개발 진행 속도 역시 영향을 받게 된다. 구글이 공개한 코드 리뷰 가이드라인 ‘The Standard of Code Review’는 다음과 같이 이야기한다.

“우리 제품을 기다리고 있는 수많은 고객이 있다. 원하는 기능을 제대로 구현하고 문제가 없는 것으로 확인되면 거기에서 코드 리뷰는 끝내야 한다.”

아무리 좋은 코드라도 필요한 순간에 활용되지 못하면 그저 문자 조각에 불과하다. 코드 리뷰 기회는 단 한 번이 아니다. 협업 활동인 만큼 함께 일하는 시간이 모두 코드 리뷰를 할 수 있는 시간이다. ‘천 리 길도 한 걸음부터’라는 말처럼 완벽을 추구하기보다 한 단계씩 개선해 나가는 것을 목표로 코드 리뷰를 해야 한다.

코드 리뷰 오해 2

리뷰 승인은 함께 책임지는 것이다

코드 리뷰는 책임을 묻기 위해 하는 활동이 아니다. 따라서 코드 리뷰를 승인하는 것 역시 책임을 지겠다는 뜻으로 받아들여서는 안 된다. 책임 소재를 묻는 순간 리뷰어도 쉽게 코드 리뷰 승인을 할 수 없게 된다. 리뷰어로 지정되는 것조차 부담이 될 수 있다. 코드 작성자 입장에서도 리뷰를 요청했는데 아무런 답이 없거나 사소한 지적을 받는 데 일주일을 허비한다면 코드 리뷰에 대해 좋지 않은 경험만 쌓는 꼴이다. 따라서 코드 리뷰를 통해 함께 작업물을 만들어 나간다는 주인의식을 도모하는 데 방점을 찍어야 한다. 코드로 인해 문제가 생겨도 책임을 묻기보다 함께 개선해 나가는 것이 옳다.

코드 리뷰 오해 3

시니어가 주니어를 가르치기 위한 목적이다

코드 리뷰의 장점 중 하나는 팀 평균 수준을 높일 수 있다는 점이다. 코드 리뷰를 통해 다른 개발자들의 코드를 많이 읽고 자신이 작성한 코드에 대해 바로 피드백받을 수 있다. 더 나은 품질의 코드를 작성하는 방법을 책이나 다른 예제를 통해서가 아닌 실제 일터에서 현장감 있게 배울 수 있는 것이다.

하지만 이 배움은 장점 중 하나일 뿐이다. 코드 리뷰의 목적은 시니어가 주니어를 가르치는 것이 아니다. 일방향적인 리뷰는 마치 숙제 검사를 하듯 압박감을 줄 수 있다. 주니어 개발자에게 자칫 불편한 경험이 될 수 있는 것이다. 주니어 입장에서는 리뷰를 하며 의견이 있더라도 ‘아직 나의 부족한 실력으로 감히 의견을 내도 되는 걸까?’ ‘내가 남의 작업물을 함부로 건드는 것은 아닐까?’ 같은 두려움이 생길 수 있다. 시니어 역시 가르쳐야 한다는 부담을 느낄 수 있다. 다시 강조하지만 코드 리뷰는 코드를 통한 개발자들의 소통이다. 일방향적이어서는 안 된다. 서로 주고받아야 소통이다.

코드 리뷰를 어떻게 도입할 것인가

코드 리뷰란 코드를 통한 소통이자 건강한 코드를 만들기 위한 개발자들의 문화 그 자체다. 참여자 모두가 진심으로 공감하지 않는다면 코드 리뷰는 그저 숙제에 불과하며 제품 개발의 병목이 될 뿐이다. 구성원들의 공감 아래 코드 리뷰를 도입하려면 어떻게 해야 할까?

1. 작게 시작하기

코드 리뷰는 혼자보다는 함께할 때 시너지를 발휘한다. 코드 리뷰에 대한 구성원들의 공감대가 필요한 이유다. 공감대는 한순간에 만들기 어렵다. 따라서 팀 전체가 코드 리뷰를 시작하기보다 마음 맞는 개발자들끼리 먼저 시작하는 것이 좋다. 꼭 리뷰를 잘하거나 기술 역량이 뛰어난 개발자부터 시작할 필요는 없다. 코드를 통해 소통을 잘하거나 피드백을 주고받길 원하는 개발자가 주도적으로 이끄는 것이 좋다. 이때 코드 리뷰를 주도하는 개발자가 “고생하셨습니다” “덕분에 문제를 미리 제거할 수 있었어요” 등 격려와 칭찬을 아끼지 않고 참여자들에게 끊임없이 동기를 부여해야 한다. 서로 격려하며 함께 일하는 재미를 북돋우는 것이다. 또 코드 리뷰를 통해 자신의 실수를 팀원들에게 드러냄으로써 팀에 대한 신뢰와 안정감도 쌓아 나갈 수 있다.

코드 리뷰 도입이 실패하는 원인은 다양하다. 구성원들의 공감이 부족하거나 함께 리뷰할 적절한 팀원이 없을 수도 혹은 촉박한 마감 일정 때문에 시간적 여유가 없을 수도 있다. 코드 리뷰를 도입했다가 중단하는 경우도 있다. 하지만 리뷰를 통한 신뢰와 안정감을 한 번이라도 경험한 개발자라면 분명 다시 코드 리뷰를 시작하려 할 것이다. 따라서 코드 리뷰 도입에 실패했더라도 누구라도 언제든 다시 손들고 시작할 수 있는 환경을 조성하는 것도 중요하다.

2. 고무 오리 디버깅(Rubber Duck Debugging)13

모든 개발팀이 코드 리뷰를 할 수 있는 여건이 되는 건 아니다. 팀원 자체가 없을 수 있고 시간과 리소스가 허락되지 않을 수도 있다. 이때는 혼자 코드 리뷰를 시작해볼 수 있다. 책 『실용주의 프로그래머』에 소개된 고무 오리 디버깅 기법이 유용하다. 프로그래밍 중 문제가 잘 해결되지 않을 때 고무 오리에게 설명하는 간단한 방법이다. 책의 저자인 프로그래머 데이비드 토머스와 대학 시절 함께 일한 연구 조교가 작은 노란색 고무 오리를 들고 다니며 코딩할 때마다 자신의 단말기 위에 올려놓은 데서 유래했다. 문제가 잘 풀리지 않을 때 오리를 올려놓고 대화를 나누듯 문제를 차근차근 설명한 것이다. 고무 오리가 없다면 곰 인형이나 화분도 좋다. 혼자 코드를 살피며 당연히 여기고 지나갈 것을 입 밖으로 이야기하다 보면 문제에 대한 새로운 통찰을 불현듯 얻을 수 있다.

혼자 코드 리뷰를 할 때도 다른 개발자에게 설명하듯 자신이 작성한 코드를 스스로 회고하고 개선 방법이 있다면 메모를 남겨두는 게 좋다. 이렇게 리뷰가 하나씩 쌓이면 시간이 지난 뒤 톡톡한 효과를 볼 것이다. 특히 “내가 왜 이렇게 코드를 짰더라?” 하고 의문이 생길 때 코드 리뷰 내용을 복기하면 도움이 된다. 이렇게 회사나 제품뿐만 아니라 스스로에게 큰 도움이 됐을 때 진정한 코드 리뷰의 힘과 재미를 느낄 수 있을 것이다.

3. 온라인 코드 리뷰: 풀 리퀘스트(Pull Request)14

온라인 코드 리뷰는 현업 개발자들 사이에서 가장 널리 쓰이는 방법이다. 네이버, 카카오 등 테크 기업은 소프트웨어 제품 코드를 개발자 개개인의 컴퓨터가 아닌 형상 관리 도구를 사용해 관리한다. 형상 관리 도구란 개발 및 유지•보수 과정에서 발생하는 코드, 문서 등 각종 결과물의 변경 사항을 체계적으로 관리하는 도구를 뜻한다. 형상 관리 도구를 통해 제품의 기반이 되는 베이스 코드(Base Code)를 변경하거나 버전별로 관리하고 개발자들은 이 베이스 코드를 복사해 각자의 컴퓨터에서 작업을 진행한다. 작업 후 코드 풀 리퀘스트를 통해 베이스 코드와 변경 내용의 비교 및 리뷰를 진행한다.

056


풀 리퀘스트를 통한 코드 리뷰 과정은 다음과 같다. 리뷰 요청자는 진행한 작업 내용, 코드 변경점과 코드 리뷰 전에 확인돼야 하는 체크리스트 내용을 함께 올린다. 그리고 원하는 사람을 리뷰어로 등록한다. 리뷰어로는 함께 일하는 동료 혹은 코드 관리자를 지정할 수 있다. 리뷰어는 작업 내용에 대한 의견을 주거나 리뷰 요청자와 질문을 주고받을 수도 있다. 피드백을 주고 이를 반영하는 과정이 오간 뒤 모두가 만족할 만한 수준으로 작업이 정리되면 코드를 최종 승인해 풀 리퀘스트가 마무리가 된다.

온라인 코드 리뷰의 가장 큰 장점은 시간과 장소의 구애를 받지 않는다는 점이다. 또 피드백 내용을 따로 정리하지 않아도 기록이 남기 때문에 추후 코드 변경점과 관련한 논의 내용을 찾아보기 쉽다. 하지만 온라인 코드 리뷰 시 문자로만 소통하기 때문에 오해가 생기지 않도록 주의해야 한다. 이를테면 리뷰어가 “이건 왜 이렇게 작업했나요?”라고 질문했다고 가정해보자. 정말 궁금해서 한 질문일 수 있지만 리뷰를 받는 입장에서는 공격적으로 느낄 수 있다.

메타 재직 당시 동료들과 온라인 코드 리뷰에서 사용하지 말아야 할 것들에 대해 이야기한 적 있다.

055


영어로 예를 들었지만 큰 맥락에서는 한국어도 동일할 것이다. 코드 뒤에 사람이 있고 그 사람이 나와 함께 일하는 동료임을 생각하며 오해가 생기지 않도록 주의해야 한다.

4.오프라인 코드 리뷰:
짝 프로그래밍(Pair Programming)

짝 프로그래밍은 한 명이 키보드로 직접 코드를 작성하고 상대방은 함께 앉아 그 코드를 보며 리뷰하는 방식으로 대표적인 오프라인 코드 리뷰 방법이다. 한 공간에 있기 때문에 작업에 더 집중하고 함께 브레인스토밍하며 떠오르는 생각을 공유하고 바로 다듬을 수 있다는 장점이 있다. 또 리뷰 요청과 피드백 및 반영이 바로 이뤄지기 때문에 훨씬 빠른 속도로 리뷰를 진행할 수 있다. 글로 물어보기 어려운 사소한 질문도 쉽게 오갈 수 있다.

온라인 코드 리뷰 도구들은 대부분 코드 변경 내용에 대해서만 보여주기 때문에 프로그램 설계와 같은 큰 그림을 보기 어렵다는 단점이 있다. 짝 프로그래밍을 하면 두 작업자가 함께 코드를 분석할 뿐만 아니라 설계 단계에서부터 이야기를 많이 나눌 수 있기 때문에 더 많은 부분을 리뷰할 수 있다.

코드 리뷰의 형식과 방법은 구성원들의 성향과 팀 상황을 고려해 정해야 한다. 일반적으로 빠른 피드백이 필요하다면 오프라인, 각자 작업할 시간이 더 필요하다면 온라인 코드 리뷰 방식이 적합하다.

코드 리뷰 시 주의할 점

1. 사람이 아닌 코드를 리뷰하라

많은 개발자가 자신이 작업한 코드와 자기 자신을 동일시하기도 한다. 어떻게 하면 더 나은 코드를 짤 수 있을까 여러 번 고민한 끝에 나온 결과물이기 때문이다. 무엇보다 자기 손으로 직접 만든 결과물이기에 수정 요청이나 안 좋은 피드백을 받았을 때 자기도 모르게 방어적으로 변하기 마련이다. 그러나 코드 리뷰의 핵심은 코드 결함과 개선점을 찾아나가는 과정이라는 점이다. 문제가 발견되는 것은 당연하다. 코드 리뷰에서 발견된 문제는 코드의 문제점이지 개인의 문제로 치부해서는 안 된다.

057


리뷰어 역시 코드 리뷰의 목표는 코드 개선에 있음을 잊지 말아야 한다. 코드에 중점을 두고 소프트웨어 제품의 스펙, 성능 등과 연결 지어 피드백해야 한다. 지식을 과시하거나 남을 부끄럽게 만드는 “이건 왜 이렇게 작성했어요?” 같은 피드백은 제품 개선에 아무런 도움이 되지 않는다.

코드 작성자와 리뷰어 모두 코드와 사람을 분리해 생각하고 객관적으로 피드백을 주고받아야 한다. 개인적인 감정이 아닌 타당한 근거를 토대로 피드백을 주고받을 때 설득력 있는 코드 리뷰를 진행할 수 있다.

2. 존경과 신뢰, 그리고 인내로 대하라

코드 리뷰 대상은 코드이지만 리뷰를 주고받는 주체는 결국 사람이다. 누구나 성장의 시간이 필요하다. 아무리 연차가 오래된 사람이라도 새로운 팀에 합류하면 제품에 대해 잘 모를 수밖에 없다. 그러므로 모든 사람을 존중하고 배려하는 자세로 코드 리뷰에 참여해야 한다. 자신 역시도 동료들에게 인내를 청하는 순간이 올 수 있음을 기억하자.

3. 세상에 변치 않는 것은 모든 것이 변한다는 사실뿐이다

같은 코드와 기능도 다양한 시각으로 볼 수 있다. 과거 자신에게는 불가피한 선택이었지만 나중에 합류한 동료 눈에는 그 외에 가능했던 더 나은 선택지가 보일 수 있다. 제품이 오랫동안 운영되다 보면 ‘원래 그런 것’들이 생겨난다. 이렇다 할 이유 없이 전임자가 만들어 놨다는 이유만으로 그대로 흘러가는 것들 말이다. 코드 리뷰를 통해 새로운 의견이 나오거나 개선점이 있다면 열린 마음으로 변화를 받아들일 수 있어야 한다.

4. 작게, 그리고 자주 리뷰하라

개발자들 사이에서는 “코드 리뷰의 검토 크기가 크면(검토할 게 많으면) 리뷰가 없고 작으면(검토할 게 적으면) 리뷰가 많다”라는 말이 오르내린다. 코드 리뷰를 오랫동안 지속하기 위해서는 리뷰 요청자와 리뷰어 모두에게 부담이 없어야 한다. 코드 변경 내용이 너무 많으면 리뷰어는 코드를 살펴보기도 전에 리뷰 양에 압도당할 수 있다. 리뷰 시간 역시 길어질 수 있다. 이런 큰 변경은 리뷰 요청자와 리뷰어 모두를 지치게 한다. 구성원들이 최대한 가볍고 편하게 변화를 받아들이도록 하려면 코드 변경 내용을 작게, 그리고 자주 공유해야 한다.

058


결국, 협업

기업 입장에서 코드 리뷰는 소프트웨어 제품을 지속하고 제품 관련 노하우를 축적하는 방식이다. 제품 관점에서 코드 리뷰는 더 견고하고 올바른 설계로 나아가는 방법이며 개발자 입장에서는 협업을 통한 심리적 안정감과 주인 의식을 기르고 성장할 수 있는 기회이기도 하다. 이 중에서 무엇보다 중요한 코드 리뷰의 핵심은 ‘협업’이다.

스포츠에 비유하자면 컬링에서 스톤을 잘 던지는 것뿐만 아니라 얼음 표면을 닦는 스위핑으로 스톤 방향을 잡아주는 것 역시 중요하다. 처음 던진 스톤에 문제가 생기더라도 다음 차례에서 다시 기회를 잡으면 된다. 소프트웨어도 마찬가지다. 코드에 잠재된 문제가 있을 수 있다. 하지만 조금 틀어진 각도는 동료들과 코드 리뷰를 통해 소통하며 함께 바로잡으면 된다. 동료들과 함께라면 할 수 있다.


서지연 네이버 클로바 AI 엔지니어 seojeee@gmail.com
필자는 다음커뮤니케이션, 카카오, 메타에서 소프트웨어 엔지니어로 근무했고 지금은 네이버 클로바에서 얼굴 인식 관련 AI 서비스를 만들고 있다. 다양한 분야의 개발자를 소개하는 개발 문화 팟캐스트 ‘나는 프로그래머다’ 진행자로 활동했고 다수 국내외 테크 콘퍼런스에서 코드 리뷰, 개발자 커리어 등 개발자 문화와 성장에 대해 발표했다. 건강한 협업과 개발 문화에 관심이 많다.
동아비즈니스리뷰 350호 Smart Worcation 2022년 08월 Issue 1 목차보기