AI를 활용하여 코드 리뷰 준비 시간을 절반으로 줄이는 방법 (단계별)

코드 리뷰는 겉보기에는 수동적인 작업처럼 보이지만, 실제로는 많은 정신적 컨텍스트 스위칭을 요구하는 일입니다. 파일 사이를 오가며 의도를 재구성하고, 작성자가 발견하지 못한 문제를 찾아내려고 노력해야 합니다. 저는 PR(Pull Request)을 열기 전에 AI를 첫 번째 검토 단계로 사용하기 시작했고, 이는 실제로 중요한 리뷰에 쓸 수 있는 정신적 여유 공간을 크게 변화시켰습니다. 제가 사용하는 정확한 워크플로우는 다음과 같습니다. 모든 내용은 복사-붙여넣기가 가능합니다.

1단계: diff를 컨텍스트로 로드하기

다른 작업을 하기 전에, 브랜치에서 원본 diff를 가져옵니다:
git diff main...feature/my-branch > /tmp/review_diff.txt

그런 다음 제가 선택한 AI 도구(저는 컨텍스트 길이에 따라 Claude 또는 GPT-4를 사용합니다)를 열고 diff를 붙여넣습니다. 아직 아무것도 묻지 마세요. 먼저 컨텍스트만 로드하세요.

opy-paste prompt: 이 diff를 기반으로 다음을 식별하세요:

1. 처리되거나 테스트되지 않은 입력 엣지 케이스(Input edge cases)
2. 흡수되거나 무시되는 것으로 보이는 모든 오류 경로(error paths)
3. 잠재적인 경쟁 조건(race conditions) 또는 상태 변경 문제(state mutation issues)
4. 누락된 테스트 커버리지 (어떤 함수나 분기에 구체적으로 명시할 것)
   가장 중요한 것은 '인간 리뷰어가 첫 번째 검토에서 놓칠 수 있는 것'입니다. 이것이 없으면 피상적인 피드백을 받습니다. 이것이 있으면, 빠져나가기 쉬운 문제들을 얻게 됩니다.
   단계 4: 팀의 패턴과 일관성 확인 (Run a consistency check against your team's patterns)
   만약 코드베이스에 컨벤션(규칙)이 있다면 — 명명 규칙(naming), 오류 처리 스타일(error handling style), 로깅 패턴(logging patterns) 등 — 대표적인 스니펫을 diff와 함께 붙여넣고 다음과 같이 요청할 수 있습니다: [기존 코드 스니펫]의 스타일과 패턴을 [새로운 diff]와 비교해 주세요. 명명 규칙, 오류 처리 또는 로깅 접근 방식에서 일관성 없는 점이 있다면 나열하세요. 스타일적 선호도는 플래그하지 마세요 — 이미 존재하는 코드에 확립된 패턴으로부터 벗어난 경우만 지적하세요. 이렇게 해야 AI가 멋대로 행동하여 단순히 학습 선호도와 맞지 않는 완벽하게 유효한 코드를 플래그하는 것을 방지할 수 있습니다.
   단계 5: 리뷰 코멘트 초안 생성 (Generate your review comment drafts)
   실제 문제를 식별했다면, AI는 실제 코멘트를 작성하는 데 유용합니다 — 특히 민감한 피드백의 경우:
   다음 문제에 대한 코드 리뷰 코멘트를 남기고 싶습니다: [문제 설명]. 직접적이고 구체적이며, 위험을 설명하고, 수정 방안을 제안하거나 명확히 하는 질문을 포함하는 코멘트를 작성해 주세요. 어조(Tone):

건설적이고, 동료 간의 (peer-to-peer). 저는 이런 내용을 거의 그대로 붙여넣지 않지만, 이 내용 덕분에 80% 정도는 진행되고 너무 모호하거나 실수로 가혹한 댓글을 작성하는 것을 막아줍니다. 실제로 이 워크플로우가 어떻게 작동하는지 말씀드리자면, GitHub에서 PR(Pull Request)을 열기 전에 약 10분 정도 걸립니다. 저는 다음 내용들을 준비합니다: 변경 사항에 대한 정신적 모델 (mental model of the change), 깊이 있게 살펴볼 특정 항목 목록 (shortlist of specific things to probe), 까다로운 피드백을 위한 초안 댓글 (draft comments for the tricky feedback). 이렇게 하면 리뷰 자체가 더 빠르고 품질이 높아집니다. 방향 설정(orientation)에 시간을 낭비하는 것이 아니라, 판단(judgment)에 시간을 할애하게 됩니다. 몇 가지 주의사항이 있습니다. AI는 존재하지 않는 문제를 환각적으로 만들어낼 수 있습니다 (hallucinate issues that don't exist). 출력물을 판결문으로 보기보다는 검증할 체크리스트로 취급하세요. 독점 코드를 공개 AI 엔드포인트에 절대 붙여넣지 마세요. 로컬 모델이나 조직에서 승인한 도구를 사용하세요. 이 워크플로우는 스택(stack)에 맞춰 프롬프트를 더 많이 조정할수록 개선됩니다. 만약 이런 종류의 프롬프트 중, 스탠드업 준비, 아키텍처 리뷰, 디버깅 세션 등 워크플로우별로 정리된 것이 더 필요하다면, 제가 가장 자주 사용하는 것들을 포함하는 프롬프트 플레이북을 만들었으니 여기에서 확인해 보세요.