리뷰어에게 PR을 올린 다음에야 사소한 실수를 지적받는 일이 잦았습니다. 함수 인자 순서를 바꾸면서 호출부 하나를 빠뜨렸거나, null이 될 수 있는 값을 강제 언래핑한 부분처럼 코드를 짤 때는 눈에 잘 안 띄지만 diff를 처음부터 끝까지 다시 읽으면 바로 보이는 종류였습니다. 커밋하기 직전에 Claude Code에게 diff만 따로 리뷰시키는 단계를 끼워 넣어서 이 문제를 줄였습니다.
어떤 작업이었나
공유 모듈의 리포지토리 인터페이스에 파라미터를 하나 추가하는 작업이었습니다. 인터페이스, 구현체, 이 인터페이스를 호출하는 여러 화면의 ViewModel까지 손을 대야 했는데, 파일이 여러 개로 흩어져 있다 보니 한 곳에서 인자 순서를 다르게 넘긴 채로 커밋할 뻔했습니다. 컴파일러가 타입까지는 잡아주지만, 같은 타입의 인자 두 개가 순서만 바뀐 경우는 컴파일 에러 없이 그냥 통과합니다.
AI를 어떻게 활용했나
커밋하기 전에 git diff로 나오는 범위만 떼어서 리뷰를 요청했습니다. 전체 코드베이스를 다시 훑게 하면 이번 변경과 무관한 기존 코드까지 지적하느라 정작 봐야 할 부분이 묻혀서, 프롬프트에 "이번 diff에서 바뀐 부분만" 이라는 제약을 명시했습니다.
git diff HEAD를 리뷰해줘. 스타일이나 네이밍처럼 사소한 지적은 하지 말고,
아래 두 가지만 확인해줘:
1. 함수 시그니처가 바뀐 곳에서 호출부가 전부 새 시그니처에 맞게 고쳐졌는지
2. null이 될 수 있는 값을 다루는 부분에서 처리가 빠진 곳이 있는지
문제가 없으면 없다고만 말해줘. 억지로 지적거리를 만들지 마.
이렇게 범위와 관점을 좁혀서 물었더니, ItemDetailViewModel에서 리포지토리 함수를 호출하는 부분 하나가 새로 추가한 파라미터 위치에 기존 파라미터 값을 그대로 넣고 있다는 걸 짚어줬습니다.
// 수정 전 (놓칠 뻔한 부분)
repository.updateItem(itemId, note, note) // 두 번째 note가 실제로는 priority 자리
리뷰 결과를 보고 나서야 시그니처를 바꾼 지점에서 인자 순서를 착각하고 있었다는 걸 알아차렸습니다. IDE 자동완성이 타입만 맞으면 경고를 띄우지 않아서, 코드를 눈으로 다시 읽기 전까지는 발견하기 어려운 종류의 실수였습니다.
처음에 걸렸던 부분
처음에는 "코드 리뷰해줘"라고만 시켰는데, 관점을 지정하지 않으니 변수명이 짧다거나 주석이 없다는 식의 스타일 지적이 대부분이었고, 정작 동작이 바뀌는 지점은 짚어주지 않았습니다. 리뷰 범위를 좁히지 않고 "전체 코드 한번 봐줘"라고 시켰을 때는 이번 변경과 상관없는 다른 파일의 오래된 코드까지 함께 지적해서, 그 중 어떤 게 이번 커밋과 관련 있는 지적인지 가려내는 데 시간이 더 들었습니다.
이후로는 리뷰 대상을 git diff 범위로 명시하고, 확인할 항목을 "시그니처 변경 호출부 정합성", "null 처리 누락"처럼 구체적으로 나열하는 쪽으로 프롬프트를 바꿨습니다. 확인할 항목이 명확할수록 관련 없는 지적이 줄었습니다.
결과와 얻은 팁
- 리뷰 범위를
git diff결과로 좁히면, 이번 변경과 무관한 기존 코드에 대한 지적이 섞이지 않아서 결과를 걸러내는 시간이 줄어듭니다. - "문제 없으면 없다고만 말해줘"처럼 명시하지 않으면, 특별히 지적할 게 없어도 사소한 스타일 의견을 만들어내는 경우가 있었습니다. 억지로 지적하지 말라는 조건을 넣는 편이 실제로 중요한 지적만 남기는 데 도움이 됐습니다.
- 확인할 항목(시그니처 정합성, null 처리, 예외 처리 누락 등)을 구체적으로 나열할수록 관점이 넓은 범용 리뷰보다 실제로 놓친 부분을 더 잘 짚어냈습니다.
- 이 방식은 컴파일러가 못 잡는 종류의 실수(같은 타입 인자의 순서 착각 등)를 걸러내는 데는 유용하지만, 로직 자체가 잘못된 경우까지 항상 잡아내지는 못해서 테스트나 사람 리뷰를 대체하지는 않습니다.