처음 이 책을 읽기 전에는 솔직히 아직 나에게는 조금 이른 책이 아닐까라는 생각을 했다.

현재 개발 과정에서 바이브 코딩을 적극적으로 활용하고 있다 보니, 내가 작성하는 코드 중 상당 부분은 AI의 도움을 받아 만들어진다. 그래서 ‘이것을 온전히 내 코드라고 할 수 있을까?’라는 생각도 있었고, 그런 내가 벌써 코드 리뷰에 대해 깊게 고민할 단계인가 싶기도 했다.

오히려 이 책에 관심을 보였던 사람은 함께 일하고 있는 테크리더였다. 서평을 마치면 책을 빌려드리기로 했는데, 책을 읽다 보니 자연스럽게 그분과 나눴던 대화들이 떠올랐다.

다른 사람이 작성한 PR을 보여주면서 내게 “이 글이 이해하기 쉬운지”, “읽기 어렵지는 않은지” 물어본 적이 있었다. 평소에는 꽤 직설적으로 이야기하는 분이지만, 다른 사람에게 의견을 전달할 때는 상대가 상처받지 않도록 나름대로 많은 고민을 하고 있다는 생각도 했었다.

그래서 책을 읽으면서 어느 순간부터는 내가 당장 좋은 리뷰어가 되기 위한 방법뿐만 아니라, 리뷰를 하는 사람은 무엇을 고민하고 있을까를 생각하게 되었다.

코드 리뷰가 단순히 잘못된 코드를 찾아내는 과정이 아니라 서로에게 무언가를 전달하는 과정이라는 점은 이전에도 알고 있었다. 다만 그 전달을 위해 이렇게까지 세밀한 고민이 필요하다고는 생각하지 못했다.

이전에는 코드 리뷰를 위한 여러 정책이나 규칙을 접할 때면 ‘왜 이렇게 복잡하게 일을 처리하는 걸까?’라는 생각이 들기도 했다. 하지만 책에서 리뷰 과정에서 발생할 수 있는 여러 오해와 사례를 접하면서 생각이 조금 달라졌다.

서로 다른 사람이 같은 코드와 글을 바라보는 이상, 작성자의 의도가 언제나 그대로 전달되는 것은 아니다. 리뷰어의 피드백 역시 의도와 다르게 받아들여질 수 있다. 그동안 복잡하다고 생각했던 여러 과정이 사실은 서로의 오해를 줄이고 의도를 조금 더 정확하게 전달하기 위한 장치일 수도 있겠다는 생각이 들었다.

특히 책에 등장하는 다양한 오해의 사례를 읽으면서 코드뿐 아니라 업무에서 보고서를 작성하고 피드백을 받았던 경험들도 많이 떠올랐다.

나는 지금까지 리뷰어보다는 리뷰이의 입장에 있었던 경우가 더 많았다. 그러다 문득 ‘나는 피드백을 받을 때 나도 모르게 방어적인 태도를 취하고 있지는 않았을까?’라는 생각이 들었다.

작성한 코드나 문서에 대한 피드백이라는 것을 머리로는 알고 있으면서도, 때로는 결과물에 대한 의견을 나 자신에 대한 평가처럼 받아들였을지도 모른다. 리뷰 과정에서 발생할 수 있는 오해들을 하나씩 읽다 보니 내가 과거에 받았던 피드백들도 조금 다른 시선으로 돌아보게 됐다.

좋은 코드 리뷰를 만들기 위해서는 리뷰어가 어떻게 이야기하는지도 중요하지만, 리뷰이 역시 상대가 어떤 의도로 피드백을 전달했는지 생각해보는 과정이 필요하다는 점이 인상적이었다.

처음에는 아직 나에게 이른 책이라고 생각했지만, 다 읽고 나니 오히려 리뷰어가 되기 전에 읽어두어서 좋았다는 생각이 들었다.

현재 하나의 제품을 함께 개발하고 있지만 각자가 주로 사용하는 언어와 담당하는 영역이 다르다. 그래서 당장은 다른 개발자의 코드를 내가 직접 리뷰하는 경우가 많지는 않다. 하지만 하나의 서비스를 함께 만들어가는 이상 앞으로도 계속 리뷰이의 위치에만 있지는 않을 것이다.

내가 잘 알고 있는 영역에서는 다른 사람의 작업을 검토하고 의견을 전달하는 리뷰어가 될 수도 있고, 반대로 내가 만든 결과물에 대해 다른 사람의 피드백을 받는 리뷰이가 될 수도 있다. 결국 협업하는 과정에서는 두 역할을 모두 경험하게 될 것 같다.

이 책을 읽으며 좋은 코드 리뷰를 위해 필요한 것이 단순히 코드를 보는 능력만은 아니라는 생각을 하게 됐다. 내가 전달하려는 말이 상대에게 어떻게 받아들여질지 생각하고, 내가 받은 피드백 역시 어떤 의도로 전달됐는지 한 번 더 생각해보는 것. 그런 과정까지 코드 리뷰의 일부일 수 있다.

언젠가 내가 리뷰어로서 더 많은 사람의 코드를 보게 되었을 때 이 책을 다시 읽어보고 싶다. 그때는 지금 리뷰이의 입장에서 읽으며 보였던 것과는 또 다른 부분들이 눈에 들어올 것 같다.