과장 없이 실질적인 AI 코드 리뷰 (AI Code Review Without the Theatre)

우리 팀에서 LLM 기반의 코드 리뷰를 운영한 지 3개월이 지났습니다. 솔직한 소견을 말씀드리자면, 우리가 잘못된 사용법을 버렸기 때문에 비로소 버그가 포함된 코드가 배포되는 것을 막을 수 있었습니다.

대부분의 팀이 AI 코드 리뷰를 할 때 저지르는 실수와, 실제로 효과를 볼 수 있는 방법을 공유합니다.

잘못된 방식 (모두가 처음 시도하는 방식)

PR(Pull Request) 내용을 Claude나 ChatGPT에 붙여넣고 "이 코드를 리뷰해줘"라고 요청합니다. 그러면 다음과 같은 일반적이고 뻔한 조언들이 쏟아집니다: "에러 핸들링(error handling)을 추가하는 것을 고려하세요. 변수 이름을 더 설명적으로 만드세요. Docstring을 추가하세요."

쓸모없습니다. 당신의 코드에는 이미 그런 것들이 있거나, 혹은 당신은 그런 것에 관심이 없습니다.

문제는 무엇일까요? AI에게 컨텍스트(context)를 제공하지 않고 있다는 점입니다. 이는 마치 누군가에게 코드를 보여주면서 손으로 코드의 절반을 가리고 있는 것과 같습니다.

실제로 효과가 있는 방식

1. 스타일이 아닌 동작(Behavior) 중심으로 리뷰하기

"이 코드를 리뷰해줘" 대신 다음과 같이 질문하세요: "다음 입력값들을 사용할 때 이 함수를 망가뜨릴 수 있는 요소는 무엇인가요: [예시]?"

// 예전에 했던 방식
"이 결제 처리 함수를 리뷰해줘"

...

무엇을 찾아야 할지 알려주었기 때문에, AI는 실제로 문제를 찾아낼 것입니다.

2. 전체 파일이 아닌 실제 디프(Diff)를 리뷰하기

전체가 아닌 변경된 부분만 보여주세요:

- 기존: const price = item.price * quantity;
+ 변경: const price = Math.max(0, item.price * quantity);

그런 다음 질문하세요: "이 변경사항이 환불 시 음수 가격을 올바르게 처리하나요?"

컨텍스트가 전부입니다. 구체적인 질문이 포함된 50줄의 디프(diff)가 500줄짜리 파일 전체 리뷰보다 훨씬 낫습니다.

3. 일반적인 코드가 아닌 당신의 스택(Stack)에 맞춰 리뷰하기

당신에게 중요한 사항을 알려주세요:

"우리는 이것을 서버리스(serverless) 환경에서 실행합니다 (콜드 스타트(cold starts)가 중요합니다). 
우리의 p99 레이턴시(latency) SLA는 200ms입니다. 
승인 없이 외부 의존성(external dependencies)을 사용할 수 없습니다.
...

이제 AI는 당신의 제약 사항을 알고 있기 때문에 실제로 도움이 됩니다.

우리 팀의 실제 사례

사례 1: 데이터베이스 쿼리 (Database Query)

나쁜 예: "이 SQL 쿼리를 리뷰해줘"
좋은 예: "이 쿼리는 최신순으로 사용자 댓글을 가져옵니다. 우리는 5,000만 개의 댓글을 보유하고 있으며 사용자 ID는 무작위입니다. 이 쿼리가 느려질까요? 어떤 인덱스(index)를 추가하면 좋을까요?"

AI는 우리가 인덱싱된 정렬 (indexed sort)을 사용하는 대신 포스트 필터 (post-filter) 방식으로 정렬하고 있다는 점을 포착했습니다. 🎯

예시 2: React 컴포넌트 (React Component)

나쁜 예: "이 폼 컴포넌트를 리뷰해줘"
좋은 예: "사용자들이 이 폼에 타이핑할 때 느리다고 불평합니다. 여기 컴포넌트가 있습니다. 어디에서 불필요한 리렌더링 (re-rendering)이 발생할 수 있을까요?"

세 개의 불필요한 상태 업데이트 (state updates)를 찾아냈습니다. 하나를 수정하여 키 입력 (keystroke) 시 200ms를 절약했습니다. 🎯

예시 3: API 엔드포인트 (API Endpoint)

나쁜 예: "이 엔드포인트를 리뷰해줘"
좋은 예: "이 엔드포인트는 파일 업로드 (최대 50MB)를 처리합니다. 메모리 스파이크 (memory spikes) 문제가 발생해 왔습니다. 이 코드가 파일 전체를 메모리에 유지하고 있나요?"

유지하고 있었습니다. 우리는 이를 수정했습니다. 🎯

모든 것을 바꾸는 단 하나의 규칙

모든 권장 사항에 대해 그 근거를 설명하라고 요구하세요.

"이것이 문제가 되는 이유는 다음과 같습니다: [설명]. 수정하는 방법은 다음과 같습니다: [수정]. 그 수정이 중요한 이유는 다음과 같습니다: [영향]."

게으른 AI 리뷰는 "에러 핸들링 (error handling)을 고려하세요"라고 말하고 끝낼 것입니다. AI가 정당성을 입증하도록 강제하세요. 만약 AI가 당신의 특정 사례에서 왜 그것이 중요한지 설명하지 못한다면, 무시하세요.

이를 더 쉽게 만들어주는 도구들

• GitHub Copilot PR review – 워크플로에 내장되어 있으며 문맥 (context)을 이해합니다.
• Continue.dev – Claude/Copilot을 에디터로 가져와 코드를 작성하면서 리뷰할 수 있습니다.
• 커스텀 도구 (Custom tools) – 우리는 PR 디프 (diff)를 가져와 우리의 제약 사항을 추가한 뒤 Claude API에 전달하는 작은 스크립트를 만들었습니다. 설정하는 데 2분밖에 걸리지 않습니다.

도구에 대해 너무 깊이 고민하지 마세요. 셸 스크립트 (Shell script) + Claude API 조합도 작동합니다. CLI 도구도 작동합니다. 유료 서비스도 작동합니다. 하나를 골라 실제로 사용하세요.

이것이 아닌 것

AI 코드 리뷰는 인간을 대체하는 것이 아닙니다. 그것은 필터 (filter)입니다.

인간의 리뷰는 여전히 다음을 위한 것입니다: 아키텍처 결정 (architecture decisions), API 설계 (API design), 거시적인 관점의 우려 사항.
AI 리뷰는 다음을 위한 것입니다: 어처구니없는 버그 (silly bugs), 놓친 엣지 케이스 (edge cases), 성능 관련 함정 (performance gotchas), 문맥 특화 문제.

기계가 잘하는 일은 기계가 하게 두세요. 인간은 인간이 잘하는 일을 하게 두세요.

다음 단계

작게 시작하세요. 여러분의 PR(Pull Request)에서 발생하는 짜증 나는 문제 하나(메모리 누수 (memory leaks), SQL N+1 문제, 누락된 예외 케이스 (missing edge cases) 등)를 골라 AI에게 그것을 집중적으로 찾아내라고 구체적으로 요청하세요. AI가 특정 대상을 찾기 시작할 때 무엇을 발견하는지 보면 깜짝 놀랄 것입니다.

그다음 확장하세요. 다른 애플리케이션, 다른 관심사로 넓혀가면 됩니다.

즐거운 리뷰 되시길 바랍니다.