코드 리뷰를 받으면서 바뀐 습관 세 가지

처음 코드 리뷰를 받았을 때는 솔직히 좀 쓰렸다. 며칠 붙들고 만든 코드에 코멘트가 열 개쯤 달려 있으면 내가 뭘 잘못 배웠나 싶어진다. 시간이 지나고 나서야 알았다. 코멘트 내용은 매번 달랐는데, 돌아보면 비슷한 이유로 달린 것들이 대부분이었다. 그래서 반복해서 걸린 것들을 습관으로 바꿔 봤다.

올리기 전에 내 diff부터 읽는다

예전에는 기능이 동작하면 바로 PR을 올렸다. 지금은 올리기 전에 GitHub 화면에서 내 PR을 리뷰어처럼 한 번 훑는다. 에디터에서 볼 때는 안 보이던 게 diff로 보면 보인다.

쓰다 만 console.log
이름만 바꾸고 안 지운 주석
이 PR과 상관없는 포맷팅 변경

이 단계에서 내가 먼저 걸러내는 것만 해도 코멘트가 꽤 줄었다. 리뷰어의 시간을 아끼는 것도 있지만, 사실은 내가 덜 민망해서 하는 일이다.

“왜”를 PR 설명에 적는다

리뷰에서 제일 많이 받은 질문은 “이거 왜 이렇게 했어요?”였다. 코드는 무엇을 하는지는 보여주지만 왜 그렇게 했는지는 잘 안 보여준다. 그래서 PR 설명에 이런 식으로 적기 시작했다.

## 변경 이유
목록 API가 느려서 화면에서 한 번에 다 받지 않고 20개씩 받도록 바꿈.

## 고민한 것
- 무한 스크롤 vs 페이지 버튼: 기존 UI가 버튼이라 그대로 유지
- 서버 정렬 기준이 불안정해서 id를 보조 키로 추가

## 봐줬으면 하는 곳
`useUserList.ts` 의 캐시 키 구성이 맞는지

마지막 항목이 은근히 효과가 있다. 리뷰어가 diff 전체를 같은 힘으로 읽는 게 아니라, 내가 불안한 곳에 먼저 눈이 가게 된다. 불안한 부분을 숨기지 않고 먼저 말하면 코멘트도 훨씬 구체적으로 달린다.

PR 크기를 줄인다

한 번은 기능 하나를 통째로 올렸다가 리뷰가 며칠 동안 안 달린 적이 있다. 변경이 너무 커서 다들 나중에 보려고 미뤄 둔 거였다. 그 뒤로는 이렇게 쪼갠다.

리팩터링만 하는 PR (동작 변경 없음)
새 기능의 뼈대 PR
화면 연결 PR

쪼개면 PR 개수는 늘지만 각각은 몇 분 안에 읽힌다. 동작 변경이 없는 리팩터링 PR은 리뷰어도 “이름만 바뀌었네” 하고 빠르게 승인해 준다. 기능 PR에서는 진짜 로직에만 집중할 수 있다.

코멘트를 받는 쪽의 태도

습관 중에 제일 어려웠던 건 코멘트를 받아들이는 방식이었다. 처음에는 코멘트마다 변명을 달고 있었다. “이건 시간이 없어서”라든가 “원래 이랬어서” 같은 말이다. 지금은 이렇게 한다.

맞는 말이면 고치고 “반영했습니다”만 쓴다.
이해가 안 되면 어떤 상황을 걱정하는지 되묻는다.
동의가 안 되면 이유를 한두 줄로 쓰고, 그래도 의견이 갈리면 팀 규칙으로 정한다.

세 번째가 의외로 중요했다. 취향 문제로 PR마다 싸우는 것보다, 한 번 정해서 린트 규칙으로 박아 두는 편이 모두에게 낫다. 따옴표를 어느 쪽으로 쓸지 같은 얘기는 사람이 아니라 도구가 정하게 두는 게 마음 편하다.

정리

코드 리뷰는 내 코드를 평가받는 자리라고만 생각했는데, 지금은 내가 모르는 사고방식을 공짜로 배우는 자리에 가깝다. 같은 코멘트를 두 번 받지 않는 것을 목표로 삼으니 신기하게 리뷰가 덜 무서워졌다. 다음 목표는 내가 남의 PR에 코멘트를 달 때 “왜”까지 같이 적는 것이다. 받아 보니 그게 제일 고마웠다.