AI 시대, 코드 리뷰는 어떻게 해야 할까

요즘은 개발자가 아닌 분들도 Claude Code나 Cursor로 끊임없이 무언가를 만들어내고 있습니다. 저도 그렇고요.

그런데 다들 비슷한 지점에서 멈추실 겁니다. AI가 코드를 쫙 뽑아놓고 “적용할까요?”라고 묻는데, 읽어봐도 뭐가 맞고 뭐가 틀린지 모르겠는 거죠. 그래서 그냥 수락을 누릅니다. 잘 돌아가니까요.

그리고 주변에서 들리는 얘기로는 개발자들의 리뷰 시간이 크게 늘었다던데, 그럼 이렇게 리뷰 없이 넘어가도 되는 건지 의문이 들죠.

우선 결론부터 얘기드리자면, 개발자들도 지금 못 하고 있습니다.

개발자 22,000명, 약 4,000개 팀을 추적한 2026년 조사를 보면 코드 리뷰에 쓰는 시간 중앙값이 441.5% 늘었습니다. 아무 리뷰 없이 병합된 코드는 31.3% 늘었고요. 어느 팀도 리뷰 정책을 바꾼 적이 없는데도요. 그냥 밀려드는 양을 감당하지 못하게 된 겁니다.

더 선명한 비교도 있습니다. PR 810만 건을 AI 사용 여부로 갈라서 본 벤치마크인데요. AI로 만든 PR은 크기가 157줄에서 400줄 이상으로 커졌고, 리뷰어가 열어보기까지 약 200분이던 게 16시간 이상으로 늘었습니다. 그리고 30일 안에 병합되는 비율이 84.5%에서 32.7%로 떨어졌습니다. AI로 만든 PR의 3분의 2는 한 달이 지나도 안 들어간다는 뜻이죠.

그러니 목표를 “개발자처럼 완벽하게 읽기”로 잡으면 실패합니다. 개발자들이 주로 하는 예방책들을 실행하는 것이 중요하다고 생각하는데요.

다행히 AI가 틀리는 방식에는 패턴이 있습니다.

하나. 정상 경로는 잘하고, 예외에서 무너집니다.

AI는 학습 데이터에 흔한 걸 잘 만듭니다. “로그인 성공하면 토큰 발급” 같은 정상 흐름은 훌륭해요. 그런데 비밀번호가 틀렸을 때, 네트워크가 끊겼을 때, 값이 비어 있을 때 같은 예외 처리는 데이터에 훨씬 적게 나옵니다. 그래서 거기서 무너집니다.

둘. 물어본 것만 보고 만듭니다.

우리 시스템에 이미 비슷한 기능이 있는지, 예전에 왜 그렇게 정했는지를 AI는 모릅니다. 그래서 똑같은 기능을 또 만듭니다. 실제로 중복 코드 블록이 2023년 대비 81% 늘었고, 2024년은 복사 붙여넣기가 리팩터링을 넘어선 첫 해였다고 합니다.

셋. 그럴듯해 보이는 게 제일 무섭습니다.

컴파일도 되고 테스트도 통과하는데 미묘하게 틀린 경우요. 한 분석에서는 AI 코드에 권한이 잘못 열리는 경로가 사람 코드보다 322% 많았다고 합니다.

그래서 실제로 할 수 있는 게 이런 것들입니다.

1. AI에게 AI를 검토시키세요 — 단, 다른 방에서

같은 대화창에서 “이거 괜찮아?”라고 물으면 자기가 쓴 걸 변호합니다. 새 대화를 열고 코드만 붙여넣은 다음 비판해달라고 하세요. 실무자들이 실제로 쓰는 방법이고, 모델을 아예 다르게 가져가는 분들도 있습니다.

질문은 이런 것들이 좋습니다. 여기서 뭐가 잘못될 수 있나. 이미 있는 기능을 또 만든 건 아닌가. 이 예외는 왜 무시했나.

저는 프로젝트별로, 테스트 할 수 있는 QA 리스트들을 에이전트에게 작성해달라고 하고, 수정사항이 있을 때마다 에이전트에게 검토 요청을 맡깁니다.

특히, ‘Playwright’라는 프레임워크를 추천드립니다.

설치는 어렵지 않습니다. 에이전트에게 ‘Playwright’ 설치해달라고 지시하면 끝이구요. Playwright는 Microsoft가 개발한 프레임워크인데요.

마치 사람이 코드만 보고 문제가 있는지 없는지 판단하는 것보다, 완성된 결과물(구현된 웹사이트 디자인 등등)만으로 문제 추론을 하는 것이 유리하듯이, AI도 똑같습니다.

매번 수정사항이 있을 때마다, QA를 Playwright로 검수해달라고 꼭 지시해보세요. 훨씬 결과물이 좋아지더라구요.

조금 더 부지런한 AI라면, 디자인을 보고 뭔가 소구할 것이 더 있을 때 추가 수정을 할 수도 있습니다.

2. 못 속이는 관문을 두세요

사람 눈보다 확실한 건 기계입니다. 린터, 타입 검사, 테스트를 걸어두면 AI가 그걸 통과할 때까지 알아서 고칩니다. 설정은 한 번만 하면 되고요.

물론, 이건 최소한 코드가 동작하는지, 문법 오류가 없는지에 대한 최소한의 테스트입니다. AI 자원을 쓰지 않고 할 수 있는 최소한의 테스트이죠.

3. GitHub을 쓰세요 — 언제든 되돌릴 수 있게

조금씩 자주 저장하세요. 리뷰가 부실해도 되돌릴 수만 있으면 사고가 아니라 번거로움으로 끝납니다.

그 도구가 GitHub입니다. 개발자들이 쓰는 거라 어렵게 느껴지실 텐데, 오히려 비개발자에게 더 필요합니다. 하는 일은 단순해요. 바뀔 때마다 그 시점을 통째로 저장해두고, 언제든 그때로 돌아갈 수 있게 해줍니다. 무료고요.

Claude Code 같은 도구는 이미 이걸 다룰 줄 압니다. “지금까지 작업 저장해줘”라고 말하면 알아서 해요. 명령어를 외우실 필요가 없습니다.

그리고 이게 리뷰와 직결됩니다. 뭐가 바뀌었는지만 따로 보여주는 화면이 있거든요. 파일 전체를 읽는 게 아니라 추가된 줄과 지워진 줄만 색깔로 표시됩니다. 코드를 읽지 못해도 얼마나 바뀌었는지는 보입니다. 버튼 하나 고쳐달라고 했는데 파일 일곱 개가 알록달록 뜨면, 그게 신호예요. 왜 이만큼 바뀌었는지 물어보시면 됩니다.

다만 두 가지는 조심하셔야 합니다.

저장소는 반드시 비공개(private)로 만드세요. 공개가 기본값인 경우가 있습니다.

그리고 API 키나 비밀번호가 한 번 저장되면 나중에 지워도 기록에는 남습니다. 실제로 자주 일어나는 사고예요. AI가 코드 안에 키를 그대로 박아두는 경우가 있으니, 저장 전에 키처럼 생긴 긴 문자열이 섞여 있는지 한 번 훑어보세요.

그래서 저 같은 경우에는, AI가 읽지 않고 활용할 수 있는 시크릿 파일 (.env)를 활용하거나, GitHub 저장소 또는 AWS에서 제공하는 시크릿 키 저장소 기능을 사용합니다. AI가 읽지 않고, 코드에서만 참조할 수 있도록 하는 구조를 설계하는 것입니다.

아직은 들여다봐야 하는 단계입니다.

AI가 많이 좋아진 건 맞습니다. 저도 매일 쓰고, 없으면 못 하겠다 싶을 때도 많고요. 그런데 전부 맡겨도 되는 단계는 아직 아닙니다. 그렇다고 사람을 추가로 더 쓰기보다는, AI를 쓰는 사람이 조금 더 관심을 갖고 공부를 부지런히 끊임없이 해야 할 단계라고 생각합니다.

앞에서 본 숫자들이 그 얘기였어요. 리뷰 없이 병합되는 코드가 늘어난 건 AI가 좋아져서가 아니라 사람이 감당을 못 하게 돼서였고, AI로 만든 PR의 3분의 2는 한 달이 지나도 안 들어갑니다. 잘 만드는 것과 믿고 맡길 수 있는 것은 아직 다릅니다.

언젠가는 정말 다 맡겨도 되는 날이 오겠지만, 그게 오늘은 아닌 것 같습니다.

#AI #코드리뷰 #바이브코딩 #ClaudeCode #개발