Claude Code 코드 리뷰, 좋아 보인다는 답변보다 최신 수정본을 먼저 확인할까요?

핵심 요약 (TL;DR)

리뷰에 긍정적인 문장이 보이면 마음이 놓입니다. 하지만 그 답변이 내가 방금 고친 코드에 대한 것인지부터 확인해야 합니다. 한국 시간 10월 21일 공개된 Claude Code 2.1.305는 리뷰 도중 여러 번 수정본을 올리면 최신 커밋을 검토하지 못하던 경우와, 이전의 중요한 지적이 남아 있는데 재검토가 긍정적인 표현으로 시작하던 문제를 수정했습니다.[1]

이번 릴리스에서는 무엇이 달라졌나요?

공식 변경 기록의 Code Review 항목은 두 가지를 명시합니다. 먼저 하나의 풀 리퀘스트를 검토하는 동안 여러 푸시가 이어졌을 때, 가장 최근 커밋을 놓치는 경우를 수정했습니다. 또 앞선 검토의 차단 사유가 아직 열려 있다면 재검토 첫머리에 LGTM이라는 표현을 쓰지 않도록 바꿨습니다.[1]

LGTM은 대체로 ‘좋아 보인다’는 뜻으로 쓰이는 검토 표현입니다. 여기서 중요한 것은 문구 자체보다 읽는 사람이 받아들이는 완료의 느낌입니다. 이번 변경은 특정 검토 동작과 표현의 수정이지, 모든 코드가 안전하다는 보증이나 모든 지적이 자동으로 해결된다는 발표는 아닙니다. 이 글 역시 릴리스 해설이며 실제 오류를 재현한 보고서는 아닙니다.

첫 앱에서는 왜 검토 대상이 헷갈릴까요?

문의 화면을 만든다고 생각해 보세요. 처음에는 빈 입력을 막도록 요청했다가, 이어서 이메일 형식과 중복 제출 처리까지 바꿀 수 있습니다. 첫 수정본을 검토하는 사이 다음 수정본이 올라오면, 같은 화면을 다룬 답변이라도 실제로 읽은 코드는 서로 다를 수 있습니다.

이 예시는 특정 사고가 아니라 점검을 위한 가정입니다. AI에게 검토를 맡길 때는 ‘이 앱 봐 주세요’보다 어떤 변경까지 포함해야 하는지 알려 주세요. 저장소를 사용한다면 현재 커밋을 기준으로 삼고, 리뷰 결과에 적힌 대상과 맞는지 확인하는 방식이 좋습니다. 리뷰 후 코드를 또 바꿨다면 그 변경까지 검토됐다고 자동으로 이어 생각하지 않는 것이 핵심입니다.

해결했다는 답변은 어떻게 확인하면 좋을까요?

앞선 지적을 별도 목록으로 남겨 보세요. 무엇이 문제였는지, 어떤 수정으로 해결하려 했는지, 실제로 확인한 행동이 무엇인지를 함께 적습니다. 예를 들어 ‘중복 제출 가능’이라는 지적에는 버튼을 빠르게 연속으로 눌렀을 때 접수 결과가 중복되지 않는지 시험한 기록을 연결할 수 있습니다.

이 절차는 제품이 제공한다고 발표한 기능이 아니라 독자를 위한 검수 제안입니다. AI가 지적을 이해했다고 답한 것과 동작이 달라졌다는 증거를 구분하기 위한 장치입니다. 테스트 환경의 무해한 자료로 재현하고, 실제 고객에게 접수 메시지가 나가는 흐름은 분리해 두세요.

배포 전에 어떤 기록을 남기면 충분할까요?

작은 프로젝트라면 검토한 커밋, 남은 지적, 실행한 테스트, 배포할 버전을 한곳에 적는 것부터 시작하셔도 좋습니다. 확인하지 못한 항목은 ‘문제 없음’ 대신 ‘미확인’으로 남겨 두세요. 보기 좋은 총평보다 이 짧은 기록이 다음 작업자의 판단을 더 정확하게 돕습니다.

배포 직전 버전이 리뷰 대상과 같다는 확인도 필요합니다. 다르다면 변경 범위를 다시 살펴보세요. 코드 리뷰를 여러 번 받는 일보다, 어느 결과가 어느 코드에 붙어 있는지 설명할 수 있는 상태가 중요합니다.

FAQ: 이번 버전으로 바꾸면 리뷰만 보고 배포해도 되나요?

아닙니다. 공식 기록은 특정 누락과 표현을 수정했다고 밝힐 뿐, 실행 테스트나 사람의 배포 판단을 대체한다고 말하지 않습니다.[1] 기능 검증은 별도 단계로 남겨 주세요.

FAQ: 긍정적인 답변이면 이전 지적도 닫힌 것 아닌가요?

그렇게 가정하지 않는 편이 좋습니다. 이번 변경 자체가 미해결 지적과 긍정적인 첫 문장이 함께 나타날 수 있었음을 보여 줍니다.[1] 총평보다 개별 지적의 상태와 수정 근거를 다시 읽어 보시길 권합니다.

출처
[1] https://github.com/anthropics/claude-code/releases/tag/v2.1.305
관찰: 2026-10-22 KST