저는 약 1년 동안 코드 리뷰에 AI를 사용해 왔는데, 솔직히 말씀드리면... 괜찮았습니다. 때로는 훌륭했고, 때로는 10분을 완전히 낭비하게 만들기도 했습니다. 실제로 효과가 있는 부분은 다음과 같습니다.

솔직한 진실

AI 코드 리뷰는 만능 해결책이 아닙니다. Claude나 GPT-4가 인간보다 어떤 것들을 더 빠르게 찾아낼 수 있다는 점은 확실합니다. 하지만 이들은 문맥(Context)을 놓치기도 하며, 때로는 사용자의 특정 유스케이스(Use case)를 망가뜨리는 리팩토링(Refactor)을 아주 자신 있게 추천하기도 합니다.

진정한 승리는 리뷰를 위해 AI를 사용해야 할 때와, 그냥 동료에게 커피 한 잔 마시며 PR(Pull Request)을 봐달라고 해야 할 때를 아는 것입니다.

AI가 실제로 탁월한 성능을 보이는 부분

보안 패턴 (Security patterns). AI에게 인증 코드, 권한 확인, SQL 쿼리를 입력해 보세요. 인간이 50번째 PR을 검토한 후 대충 넘어가기 쉬운 이상한 부분들을 잡아낼 것입니다. 저는 지난달 Claude를 사용하여 200줄짜리 인증 모듈에서 세 개의 잠재적인 인젝션 벡터(Injection vector)를 찾아냈습니다. 금요일 오후 5시에 수동 리뷰를 하면서 그것들을 찾아냈을까요? 아니요.

일관성 감사 (Consistency audits). "이것이 우리의 명명 규칙(Naming conventions)과 일치하는가? 에러 핸들링(Error handling)? 반환 타입(Return types)?" 지루하고 기계적인 작업입니다. AI는 이런 작업에 대해 '지루함'을 느끼지 않습니다. 놓치지 않을 것입니다. 빠른 프롬프트(Prompt)를 설정하고 PR에 실행하면 끝입니다.

이상한 코드 설명하기. 우리 모두에게는 뇌를 아프게 하는 레거시 함수(Legacy function)가 하나씩 있습니다. AI에게 그 코드를 설명해 달라고 한 다음, 그것이 무엇을 해야 하는지 설명해 보세요. 종종 그 난장판을 직접 이해하지 않고도 버그를 찾아낼 수 있습니다.

AI가 한계를 보이는 부분

비즈니스 로직 (Business logic). "이 기능에 적합한 접근 방식인가요?" 아닙니다. AI는 여러분의 제품 로드맵, 성능 제약 조건, 또는 왜 이런 이상한 임시방편(Workaround)을 사용하는지 알지 못합니다. 이 부분은 사람이 확인해야 합니다.

아키텍처 결정 (Architecture decisions). 누군가 여러분의 API 구조를 리팩토링하고 있습니다. AI는 여러분의 코드베이스(Codebase)에는 끔찍할 수도 있는 일반적인 베스트 프랙티스(Best practices)를 제공할 것입니다. 좋지 않은 생각입니다.

문맥이 불분명할 때. 만약 PR 설명이 모호하다면, AI는 이를 놓치거나 잘못된 피드백을 자신 있게 줄 것입니다. 이는 문제를 해결하는 대신 문제를 증폭시킵니다.

저의 실제 워크플로우 (Workflow)

1. 아키텍처/비즈니스 로직은 사람이 우선. 프로젝트를 잘 아는 사람의 실제 리뷰가 필요합니다.
2. AI 감사 (Audit) 단계. 사람이 승인한 후, 다음과 같은 프롬프트를 사용하여 Claude로 변경 사항을 검토합니다: "보안 문제, 성능 경고(red flags), 일관성 위반 사항을 확인하세요. 이상한 점이 있으면 표시하세요."
3. 시한폭탄 방지. 만약 AI가 사람이 놓친 부분을 잡아낸다면, 우리는 완벽하게 성공한 것입니다. 그렇지 않더라도 해가 되지 않습니다. 이미 사람의 검토를 거쳤기 때문입니다.

제가 사용하는 템플릿

당신은 코드 변경 사항을 리뷰하고 있습니다. 다음 사항에 집중하세요:
- 보안 문제 (인젝션, 인증 우회, 데이터 노출)
- 성능 경고 (N+1 쿼리, 메모리 누수, 블로킹 작업)
...

실행하는 데 약 30초 정도 걸리며, 무언가를 잡아낸 뒤 바로 다음으로 넘어갑니다.

실제 사례

한 개발자가 우리의 캐싱 계층 (caching layer)을 업데이트한 적이 있습니다. 사람의 리뷰는 괜찮아 보였습니다. 코드는 깔끔했고 로직도 타당했습니다. 하지만 AI는 캐시 무효화 (cache invalidation)가 세 가지 사용자 유형이 아닌 단 한 가지 유형에 대해서만 작동한다는 점을 지적했습니다. 그대로 두었다면 운영 환경 사고 (production incident)가 발생했을 것입니다. 해당 개발자는 나중에 우리에게 고마워했습니다.

또 다른 때는, AI가 그대로 두어도 괜찮은 쿼리를 "최적화"하겠다며 의욕을 보인 적이 있습니다. 저는 그 경고를 무시했습니다. 어차피 사람이 이미 확인했기 때문에 문제없었습니다. 모든 AI 제안이 금광인 것은 아닙니다.

결론

지루하고 컨텍스트 (context)가 낮은 작업에는 AI를 사용하세요. 판단이 필요한 결정은 사람에게 맡기십시오. AI를 오타는 잘 잡아내지만 프로젝트가 실제로 무엇을 하려는지 전혀 모르는, 약간 짜증 나는 동료처럼 대하세요. 사실... 그 정도면 꽤 괜찮은 동료입니다.

만약 AI를 유일한 코드 리뷰 수단으로 사용하고 있다면, 당신은 끔찍한 것을 자신 있게 추천할 수 있는 도구를 신뢰하고 있는 것입니다. 하지만 사람의 리뷰 이후에 안전망 (safety net)으로 사용하는 것이라면? 이야기는 달라집니다. 걱정해야 할 컨텍스트가 훨씬 적기 때문입니다.