코드리뷰를 백그라운드로 돌릴 수 있게 되면서 습관이 하나 생겼습니다. 리뷰를 띄워놓고, 결과를 기다리는 동안 놀지 않는 것입니다. 어차피 몇 분 걸리니까 그 사이에 다른 걸 고칩니다.
질문 하나 드리겠습니다. 그 "다른 것"이 지금 리뷰 중인 파일이면 어떻게 됩니까?
리뷰어가 먼저 말했습니다
2026-08-25, Plotta 작업에서 그렇게 했습니다. 리뷰 에이전트를 띄우고, 대기 시간에 같은 파일들을 계속 다듬었습니다. 그리고 돌아온 리뷰 결과 안에 이런 내용이 있었습니다 — 리뷰 도중에 파일이 바뀌었다.
리뷰어가 지적한 항목 중 두 건은 이미 고쳐져 있었습니다. 제가 그 사이에 고친 것들입니다.
여기서 문제가 생깁니다. 남은 지적들은 어느 시점의 코드에 대한 것입니까? 리뷰가 파일을 읽은 순간의 코드일 텐데, 그 코드는 이제 디스크에 없습니다. 결과를 정리하면서 "이건 어느 상태 기준"이라고 따로 적어야 했습니다. 리뷰 결과에 각주를 다는 작업이 추가로 생긴 겁니다.
왜 이게 단순한 낭비 이상인가
세 가지가 겹칩니다.
결과의 기준점이 사라집니다. 리뷰는 스냅샷에 대한 판정입니다. 스냅샷이 없으면 판정을 어디에 적용할지가 모호해집니다.
되돌릴 위험이 생깁니다. 이미 고친 지적을 "반영"하려고 다시 손대면, 방금 만든 더 나은 코드를 리뷰어가 본 옛 코드 기준으로 되돌릴 수 있습니다. 이게 제일 조용한 사고입니다 — diff만 보면 정상 작업처럼 보입니다.
리뷰어의 작업도 버려집니다. 이미 고쳐진 것을 읽고 분석한 몫은 그대로 낭비입니다.
여기서 당신이라면?
리뷰가 5분 걸린다고 합시다. 선택지가 둘입니다.
- 그 5분을 아까워하며 같은 파일을 계속 고친다.
- 트리를 얼려두고, 5분을 리뷰 범위 밖 일에 쓴다.
1번은 5분을 벌고 그 뒤에 정리 비용을 냅니다. 저는 그 정리 비용이 5분보다 컸습니다.
그래서 정한 절차
리뷰를 띄우기 전에 커밋합니다. 리뷰 대상이 명확한 스냅샷이 되고, 결과가 오면 그 커밋 위에 얹으면 됩니다.
리뷰 대상 파일은 결과가 올 때까지 손대지 않습니다. 이게 규칙의 전부입니다.
대기 시간은 리뷰 범위 밖 작업으로 씁니다. 실제로 쓸 게 많습니다.
- 릴리스 노트 작성
- 스토어 심사 상태 조회
- 빌드 산출물 준비
- 메모리·문서 정리
전부 리뷰가 읽는 파일을 건드리지 않으면서 진짜로 진행되는 일입니다.
리뷰 반영으로 코드가 바뀌면 그 전에 만든 빌드는 폐기합니다. 이건 놓치기 쉽습니다. 같은 세션에서 아카이브하고 업로드까지 해뒀다면, 리뷰를 반영한 뒤에는 다시 만들어 다시 올려야 합니다. iOS라면 빌드 번호를 새로 뽑아야 합니다. 안 그러면 심사에 올라가 있는 바이너리는 리뷰 이전 코드입니다.
자가진단 3개
- 지금 백그라운드 리뷰가 돌고 있다면, 그 리뷰가 읽는 파일 목록을 말할 수 있습니까?
- 리뷰를 띄우기 직전에
git status가 깨끗했습니까? 아니라면 결과는 커밋되지 않은 어떤 상태에 대한 것입니다. - 리뷰 반영 후, 이전에 올려둔 빌드가 남아 있지 않습니까?
솔직한 부분
이 규칙이 답답한 건 사실입니다. 백그라운드로 돌리는 이유가 병렬로 일하려는 것인데, "그 파일은 만지지 마라"는 병렬성을 깎습니다.
그런데 실제로 깎이는 건 생각보다 적습니다. 한 세션에서 할 일이 리뷰 대상 파일 편집 하나뿐인 경우는 드뭅니다. 릴리스 준비, 상태 확인, 문서 작업은 항상 밀려 있습니다. 병렬로 못 하는 게 아니라 같은 파일에 대해 병렬로 못 하는 것입니다.
같은 계열의 사고를 다른 형태로도 겪었습니다 — 여러 세션이 같은 작업 트리를 공유하면, 내가 만지지 않은 파일이 내 커밋에 실려 나갑니다. 공유 자원이 트리일 때 생기는 문제는 늘 "누가 언제 보았는가"로 돌아옵니다.
지금 딱 하나만 확인해 보세요. 다음에 리뷰를 띄울 때, 띄우기 전에 커밋하고 그 파일들을 결과가 올 때까지 열지 않아 보시기 바랍니다. 각주를 안 달아도 되는 리뷰 결과가 어떤 건지 느낌이 다릅니다.