개발자의 코드리뷰는 상명하복이 아니다.

면접관으로 들어가면 꼭 하는 질문들이 여러 개가 있다.

그중 하나는 어떤 개발조직이었으면 한다거나, 꼭 있었으면 하는 문화가 있는지? 이다.

여러 가지 답변을 듣지만, 항상 나오는 주제는 (좋은) 코드리뷰를 받고 싶다. 이다.


  1. 코드 리뷰는 받는 게 아니다


1명의 개발자를 뽑기 위해 정말 수많은 개발자들과의 면접을 진행을 한다.

정말 운이 좋게도, 좋은 개발자들과 많이 일하게 되었고, 그렇게 나도 여러 사람들과 성장해 나가면서 내가 얻고 전파하려고 했던 것을 글로 써보고자 해서 이 글을 쓰게 됐다.


위의 소제목처럼 보이는 것이 무슨 말인가 싶기도 할 것이다.

"코드 리뷰는 주는 것과 받는 거지 않아? 무슨 이상한 소리야?"


물론 맞다. 형식적으로는 맞다.

그전에, 다른 이야기를 해보고 이야기를 이어 나가보자


  1. 도대체 정석이 뭔데?


과연 개발에 답이라는 게 있기는 한 걸까?.

여러 서적에서 말하는 일명, 클린 코드, 좋은 패턴, 멋진 아키텍처. 이것들을 부정하지 않고 따르려 한다. 

근데 과연 그게 정석일까를 말해보고 싶다.

이 패턴이 답이다, 이 아키텍처가 답이다. 라고 명확히 말할 수는 없다고 나는 생각하고, 도메인에 따라서, 상황에 따라서 답을 찾는 것이 좋은 개발자, 좋은 개발조직이라고 나는 생각한다.


여기서 중요한 것은 상황에 따라서라는 표현 같다. 이 말을 자칫 잘못 이해하면, 클린 코드를 위해, 좋은 아키텍처를 위해서 노력을 하지 말라고 이해할 수도 있는데, 절대 그런 말이 아니다.


남들이 하는 방식대로, 바보상자 보듯이 따라 하지 말라는 것이다.


회사의 개발조직 안에는 그 조직만의 최소한 하나의 개발 콘셉트가 있어야 한다.

가독성에 미쳐있거나, 문제 해결에 미쳐있거나, 그 외이거나

그러다 보면 그 콘셉트에 맞춰서 개발 스타일이 있어야 하고, 그거에 따른 조직원 간의 협의가 있어야 한다.


  1. 이해 -> 납득 -> 공감 (이납공)


이 콘셉트가 코드 리뷰의 시작이라고 나는 생각한다.

회사에 처음 들어가던, 이직을 했건 한 번쯤은 겪어본 상황 중 하나는 오 내 스타일과는 다른데? 혹은 뭔가 좀 이상한데 일 것이다.

본인은 처음 겪어보는 코드 스타일이라던가, 다른 아키텍처를 갖고 있다던가이다.


처음 그 조직에서 코드를 작성하고 코드 리뷰를 받으면 수많은 코멘트가 달리기도 하고, 어쩌면 자리로 찾아와 얘기를 하기도 한다.

자, 이제 본격적인 코드 리뷰이다.


내 방식이 당연히 틀릴 수 있고, 다른 좋은 코드리뷰 방식이 있을 수 있으니까, 이 글에서 어떤 코드리뷰가 나쁘다, 죄악이다 이런 말은 하지 않겠다. 지극히 주관적인 나의 글이니까.


코드 리뷰에서 리뷰이는 3가지 단계를 거치고 나서야 코드에 반영해야만 한다.

한 단계단계마다 치열하게 싸우고, 토론하고 논의해야만 한다.


첫 번째, 이해

단어 그대로 이해를 해야 한다. 리뷰어가 남긴 리뷰가 도대체 어떤 의도를 가지고 남긴 글인지, 이 리뷰가 어떤 의미를 내포하고 있는지를 이해해야 한다.

단순히 "아 이런 뜻이구나"의 수준이 아닌, 리뷰어의 의도 자체를 알기 위해 치열하게 논의해야 한다.

이 단계에서 몇 번의 핑퐁이 있든 간에, 이해가 되지 않으면 다음 단계들은 시도 조차 될 수가 없다.


두 번째, 납득

두 번째 단계는 리뷰어의 말이 걸리는 부분 없이 목 넘김이 깔끔하게 되어야 한다.

보통 이 부분을 설명할 때는 이렇게 얘기한다.

"어떤 이유에서 이런 리뷰를 남겼고, 배경도 이해가 될 때".


이해가 되는 것과 납득이 되는 것은 천지차이이기 때문에 보통 이 두 번째 단계에서 수많은 핑퐁이 오가게 된다.

"그래 네가 이렇게 남긴 의도도 알겠고, 다 알겠는데 나는 납득이 잘 안 되네, 다른 방식이 더 좋지 않을까?"

그러다 보니 이 부분에서는 이제 리뷰어가 남긴 의도와는 다른 방향으로 얘기가 많이 오가게 되고, 리뷰어가 본인의 리뷰를 리젝 하기도 하는 경우가 많아진다.


이 부분이 코드리뷰의 묘미이고, 상명하복이 아니라는 제목을 지은 이유이기도 하다.

왠지 모를 찝찝함, 애초에 작업에 대한 의구심, 프로젝트 자체의 아키텍처에 대한 아쉬움이 오기도 한다.

굉장히 어렵고 불편한 단계이다. 얘기가 잘 안 통하다 싶으면 서로 얼굴을 붉히기도 할 테고, 진짜 말도 안 되게 짧은 코드로 한나절을 얘기하기도 한다.

그렇지만 개발자는 단순히 코딩을 하는 게 아니라, 문제를 해결하는 사람이고 성장을 원하는 사람이기 때문에 견뎌야 한다.


세 번째, 공감

이 단계는 스무스하게 넘어갈 것 같지만, 이 단계 또한 험난하다

바로, 내가 다음에 같은 상황 혹은 비슷한 상황에서 리뷰어가 된다면 이렇게 남길 것 같다,라는 공감이 되어야 한다. 마치 자신의 생각처럼 남들에게 이 코드를 설명할 수 있어야 한다.


만약 코드리뷰를 다 받고, 이납공도 다 됐다고 생각해서 수정하여 올렸는데 같은 부분에서 다시 리뷰가 올라온다? 그러면 리뷰어가 일부러 다른 부분에 챌린지를 주었거나, 이납공이 안된 경우가 대부분이다.

이럴 경우 리뷰어와 리뷰이는 모두 어떤 부분에서 서로 의사소통에 미스가 났는지, 무엇이 싱크가 어긋났는지를 얘기해봐야 하는 상황일 것 같다.


코드리뷰는 상명하복이 아니다.

본래 제목으로 끝맺음을 해보고자 한다.

위에서 말했던 것과 같이 나는 이납공이 되지 않으면 리뷰이가 코드를 수정하면 안 된다고 생각한다.

리뷰어가 윗사람이건, 신입이건 간에 상관없이 모두 이납공이 되어야지만 코드를 수정을 하건, Merge를 하건 해야 한다.

그러면서 수많은 대화가 오가고, 토론이 오가야 하고 개발조직의 싱크를 맞춰가야지만 문제 해결이라는 본연의 업무를 원활히, 그리고 능히 할 수 있다고 나는 생각한다.


다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2024년 2월 17일 오전 12:41

조회 237

댓글 0

    함께 읽은 게시물

    자신의 장단점을 알고 계신가요? 여러분은 AI보다 어떤 점이 나은가요?

    자신의 장단점을 알고 계신가요? 여러분은 AI보다 어떤 점이 나은가요? 제 개발 경력이 6년쯤 되었을 때, 서울에 있는 서비스 회사에 이력서를 합격했습니다. 개발을 좀 더 잘 해보고 싶다는 생각에 지원했던 곳이었죠. 면접 순서는 경력면접 - 기술면접 - 대표면접

    ... 더 보기

    [개발자가 꼭 봐야 할 책 - 데이터 중심 애플리케이션 설계]

    Distributed Systems 전문이라 가볍게 읽을 수 있는 책을 찾다가 지난 주말 읽어보고 데이터 중심 설계 "기본기"를 다질 수 있는 정보가 많은 책을 추천합니다. 책 이름은 "Designing Data-Intensive Applications" (한국어: 데이터 중심 애플리케이션 설계)입니다. 예전에 잠깐 소개한 책은 (지난 글 참고) 이 책의 챕터 3을 좀 더 깊게 파고드는 책이고, 데이터 베이스 설계를 하는 엔지니어가 아닌 사람이 읽기에는 조금 거리감이 느껴졌지만, 이 책은 소프트웨어를 설계하는 사람이라면 ... 더 보기

     • 

    저장 179 • 조회 9,883


    오늘의 탐라는 “ChatGPT 쓰셨던데 그러고도 개발자입니까?” 인가..

    ... 더 보기

    오픈소스 쓰셨던데 그러고도 개발자입니까?

    www.haruair.com

    오픈소스 쓰셨던데 그러고도 개발자입니까?

    조회 541


    앞으로의 코테는 설명을 주고 코드를 짜라고 하는 것이 아니라, 코드를 주고 설명을 하라는 것이 유효할 것이다.


    내 경우는 이미 그렇게 하고 있는데, 요구사항을 주고 개발을 요청. 결과물이 요구사항대로 개발이 잘 되었다면, 다음 단계로 제출한 코드를 리뷰하며 설명을 요청한다.


    ... 더 보기

     • 

    댓글 1 • 저장 20 • 조회 2,918


    제가 쓰고 있는 책의 표지가 나왔어요!

    ... 더 보기

     • 

    댓글 1 • 조회 1,317


    사람들이 요즘 AI, ChatGPT에게 의존하여 사고력이 저하되고 있다는 이야기가 많이 나온다.


    두뇌 발달에 안 좋으니, 80년대에 계산기 쓰지마라, 90년대에 컴퓨터 쓰지마라, 2000년대에 엑셀 팡션 쓰지마라, 2010년에 스마트폰 쓰지마라는 말과 같다는 생각이다.


    ... 더 보기

     • 

    저장 2 • 조회 957