개발자의 코드리뷰는 상명하복이 아니다.
좋은 코드 리뷰를 위해 개발자가 취해야 하는 자세에 대하여
면접관으로 들어가면 꼭 하는 질문들이 여러 개가 있다.
그중 하나는 어떤 개발조직이었으면 한다거나, 꼭 있었으면 하는 문화가 있는지?이다.
여러 가지 답변을 듣지만, 항상 나오는 주제는 (좋은) 코드리뷰를 받고 싶다.
코드 리뷰는 받는 게 아니다
1명의 개발자를 뽑기 위해 정말 수많은 개발자들과의 면접을 진행을 한다.
정말 운이 좋게도, 좋은 개발자들과 많이 일하게 되었고, 그렇게 나도 여러 사람들과 성장해 나가면서 내가 얻고 전파하려고 했던 것을 글로 써보고자 해서 이 글을 쓰게 됐다.
위의 소제목처럼 보이는 것이 무슨 말인가 싶기도 할 것이다.
"코드 리뷰는 주는 것과 받는 거지 않아? 무슨 이상한 소리야?"
물론 맞다. 형식적으로는 맞다.
그전에, 다른 이야기를 해보고 이야기를 이어 나가보자
도대체 정석이 뭔데?
과연 개발에 답이라는 게 있기는 한 걸까?.
여러 서적에서 말하는 일명, 클린 코드, 좋은 패턴, 멋진 아키텍처. 이것들을 부정하지 않고 따르려 한다.
근데 과연 그게 정석일까를 말해보고 싶다.
이 패턴이 답이다, 이 아키텍처가 답이다. 라고 명확히 말할 수는 없다고 나는 생각하고, 도메인에 따라서, 상황에 따라서 답을 찾는 것이 좋은 개발자, 좋은 개발조직이라고 나는 생각한다.
여기서 중요한 것은 상황에 따라서라는 표현 같다. 이 말을 자칫 잘못 이해하면, 클린 코드를 위해, 좋은 아키텍처를 위해서 노력을 하지 말라고 이해할 수도 있는데, 절대 그런 말이 아니다.
남들이 하는 방식대로, 바보상자 보듯이 따라 하지 말라는 것이다.
회사의 개발조직 안에는 그 조직만의 최소한 하나의 개발 콘셉트가 있어야 한다.
가독성에 미쳐있거나, 문제 해결에 미쳐있거나, 그 외이거나
그러다 보면 그 콘셉트에 맞춰서 개발 스타일이 있어야 하고, 그거에 따른 조직원 간의 협의가 있어야 한다.
이해 -> 납득 -> 공감 (이납공)
이 콘셉트가 코드 리뷰의 시작이라고 나는 생각한다.
회사에 처음 들어가던, 이직을 했건 한 번쯤은 겪어본 상황 중 하나는 오 내 스타일과는 다른데? 혹은 뭔가 좀 이상한데 일 것이다.
본인은 처음 겪어보는 코드 스타일이라던가, 다른 아키텍처를 갖고 있다던가이다.
처음 그 조직에서 코드를 작성하고 코드 리뷰를 받으면 수많은 코멘트가 달리기도 하고, 어쩌면 자리로 찾아와 얘기를 하기도 한다.
자, 이제 본격적인 코드 리뷰이다.
내 방식이 당연히 틀릴 수 있고, 다른 좋은 코드리뷰 방식이 있을 수 있으니까, 이 글에서 어떤 코드리뷰가 나쁘다, 죄악이다 이런 말은 하지 않겠다. 지극히 주관적인 나의 글이니까.
코드 리뷰에서 리뷰이는 3가지 단계를 거치고 나서야 코드에 반영해야만 한다.
한 단계단계마다 치열하게 싸우고, 토론하고 논의해야만 한다.
첫 번째, 이해
단어 그대로 이해를 해야 한다. 리뷰어가 남긴 리뷰가 도대체 어떤 의도를 가지고 남긴 글인지, 이 리뷰가 어떤 의미를 내포하고 있는지를 이해해야 한다.
단순히 "아 이런 뜻이구나"의 수준이 아닌, 리뷰어의 의도 자체를 알기 위해 치열하게 논의해야 한다.
이 단계에서 몇 번의 핑퐁이 있든 간에, 이해가 되지 않으면 다음 단계들은 시도 조차 될 수가 없다.
두 번째, 납득
두 번째 단계는 리뷰어의 말이 걸리는 부분 없이 목 넘김이 깔끔하게 되어야 한다.
보통 이 부분을 설명할 때는 이렇게 얘기한다.
"어떤 이유에서 이런 리뷰를 남겼고, 배경도 이해가 될 때".
이해가 되는 것과 납득이 되는 것은 천지차이이기 때문에 보통 이 두 번째 단계에서 수많은 핑퐁이 오가게 된다.
"그래 네가 이렇게 남긴 의도도 알겠고, 다 알겠는데 나는 납득이 잘 안 되네, 다른 방식이 더 좋지 않을까?"
그러다 보니 이 부분에서는 이제 리뷰어가 남긴 의도와는 다른 방향으로 얘기가 많이 오가게 되고, 리뷰어가 본인의 리뷰를 리젝 하기도 하는 경우가 많아진다.
이 부분이 코드리뷰의 묘미이고, 상명하복이 아니라는 제목을 지은 이유이기도 하다.
왠지 모를 찝찝함, 애초에 작업에 대한 의구심, 프로젝트 자체의 아키텍처에 대한 아쉬움이 오기도 한다.
굉장히 어렵고 불편한 단계이다. 얘기가 잘 안 통하다 싶으면 서로 얼굴을 붉히기도 할 테고, 진짜 말도 안 되게 짧은 코드로 한나절을 얘기하기도 한다.
그렇지만 개발자는 단순히 코딩을 하는 게 아니라, 문제를 해결하는 사람이고 성장을 원하는 사람이기 때문에 견뎌야 한다.
세 번째, 공감
이 단계는 스무스하게 넘어갈 것 같지만, 이 단계 또한 험난하다
바로, 내가 다음에 같은 상황 혹은 비슷한 상황에서 리뷰어가 된다면 이렇게 남길 것 같다,라는 공감이 되어야 한다. 마치 자신의 생각처럼 남들에게 이 코드를 설명할 수 있어야 한다.
만약 코드리뷰를 다 받고, 이납공도 다 됐다고 생각해서 수정하여 올렸는데 같은 부분에서 다시 리뷰가 올라온다? 그러면 리뷰어가 일부러 다른 부분에 챌린지를 주었거나, 이납공이 안된 경우가 대부분이다.
이럴 경우 리뷰어와 리뷰이는 모두 어떤 부분에서 서로 의사소통에 미스가 났는지, 무엇이 싱크가 어긋났는지를 얘기해봐야 하는 상황일 것 같다.
코드리뷰는 상명하복이 아니다.
본래 제목으로 끝맺음을 해보고자 한다.
위에서 말했던 것과 같이 나는 이납공이 되지 않으면 리뷰이가 코드를 수정하면 안 된다고 생각한다.
리뷰어가 윗사람이건, 신입이건 간에 상관없이 모두 이납공이 되어야지만 코드를 수정을 하건, Merge를 하건 해야 한다.
그러면서 수많은 대화가 오가고, 토론이 오가야 하고 개발조직의 싱크를 맞춰가야지만 문제 해결이라는 본연의 업무를 원활히, 그리고 능히 할 수 있다고 나는 생각한다.
