주니어 때는 몰랐던, 코드 리뷰에서 진짜 중요한 것

도입

주니어 때는 코드 리뷰라고 하면 일단 스타일 가이드를 지켰는지, 변수명이 컨벤션에 맞는지, 들여쓰기나 네이밍처럼 눈에 바로 보이는 부분부터 확인했습니다. 리뷰 코멘트도 대부분 그런 지적이었고, 그게 꼼꼼한 리뷰라고 생각했습니다. 12년 정도 개발을 하고 나서 돌아보면, 그때는 정작 중요한 걸 놓치고 있었다는 생각이 듭니다.

그때는 왜 스타일부터 봤을까

돌이켜보면 이유는 단순합니다. 스타일 문제는 눈에 바로 보이고, 지적하기도 쉽고, 맞다 틀리다가 명확합니다. 반면 이 코드가 실제로 필요한 요구사항을 충족하는지, 나중에 유지보수할 사람이 이 구조를 보고 의도를 파악할 수 있을지 같은 질문은 훨씬 판단하기 어렵습니다. 판단하기 쉬운 것부터 손이 가는 건 자연스러운 일이었던 것 같습니다.

지금 리뷰할 때 가장 먼저 보는 것

지금은 코드를 열면 가장 먼저 이 변경이 어떤 문제를 풀기 위한 것인지부터 확인합니다. PR 설명이나 커밋 메시지에 그 맥락이 없으면, 코드를 아무리 잘 짰어도 리뷰가 어려워집니다. 왜 이렇게 짰는지 이유가 코드 자체에서 드러나지 않으면, 그 코드는 나중에 다른 사람이(혹은 몇 달 뒤의 본인이) 손댈 때 다시 처음부터 맥락을 복원해야 하기 때문입니다.

그다음으로 보는 건 예외 상황 처리입니다. 정상 흐름은 대부분 잘 짜여 있는데, 네트워크가 끊기거나 값이 비어있거나 동시에 여러 요청이 들어오는 경우처럼 흔치 않은 상황에서 어떻게 동작하는지는 리뷰에서 놓치기 쉬운 부분입니다. 실제로 운영 중 발생한 장애 중 상당수는 이런 예외 케이스 처리 누락에서 시작된 경우가 많았습니다.

마지막으로는 이 변경이 다른 부분에 미치는 영향 범위를 봅니다. 함수 하나를 고쳤을 때 그 함수를 호출하는 다른 곳에서도 똑같이 문제없이 동작하는지, 특히 공용으로 쓰이는 모듈일수록 이 부분을 신경 써서 봅니다. 스타일이 조금 어긋나 있어도 이 세 가지가 명확하면 우선 승인하고, 스타일은 별도로 가볍게 코멘트하는 편입니다.

스타일 지적을 줄이게 된 이유

스타일 문제가 안 중요하다는 뜻은 아닙니다. 다만 스타일은 린터나 포매터 같은 도구로 상당 부분 자동화할 수 있다는 걸 알게 됐습니다. 사람이 굳이 시간을 들여 확인해야 할 부분은, 도구가 잡아낼 수 없는 부분 — 즉 이 코드가 맞는 문제를 풀고 있는지, 예외 상황에 안전한지, 영향 범위를 벗어나지 않는지 같은 것들입니다. 리뷰 시간이 한정되어 있다면, 그 시간을 도구가 못 하는 일에 쓰는 게 맞다고 생각하게 됐습니다.

주의사항 / 흔한 실수

리뷰에서 흔히 하는 실수 중 하나는, 코드를 고치는 방법까지 구체적으로 지시하는 코멘트를 남기는 것입니다. "이렇게 바꾸세요" 대신 "이 부분에서 이런 상황이 발생하면 어떻게 될까요?"처럼 질문 형태로 남기면, 작성자가 스스로 문제를 발견하고 더 나은 해결책을 찾는 경우가 많았습니다. 답을 주기보다 질문을 남기는 편이 결과적으로 더 나은 코드로 이어지는 걸 여러 번 경험했습니다.

또 하나는 리뷰를 너무 늦게 하는 것입니다. PR이 쌓여 있으면 작성자는 다음 작업으로 이미 넘어가 있는 경우가 많고, 그 상태에서 리뷰 코멘트를 받으면 맥락을 다시 불러오는 데 시간이 걸립니다. 가능하면 PR이 올라온 당일에 짧게라도 훑어보는 습관이 전체 흐름을 훨씬 매끄럽게 만듭니다.

마무리

주니어 시절에는 코드가 규칙을 지켰는지를 주로 봤다면, 지금은 이 코드가 어떤 문제를 풀고 있고 예외 상황에 안전한지, 그리고 주변에 어떤 영향을 주는지를 우선으로 봅니다. 스타일은 도구에 맡기고, 사람의 시간은 도구가 못 하는 부분에 쓰는 게 결국 더 효율적인 리뷰라는 걸 시간이 지나면서 알게 되었습니다.

---

[핵심요약] 스타일보다 문제해결·예외처리·영향범위, 리뷰 우선순위 변화