AI 코드 리뷰 안 하면 생기는 일: 불신 96%, 검토 48%

금요일 오후 5시 40분. 에이전트가 만든 PR의 CI가 초록불로 바뀌었다. diff는 600줄, 설명란엔 "Refactor auth flow and fix edge cases" 한 줄. 머지 버튼 위에서 커서가 잠깐 멈춘다. 이 코드를 믿나? 솔직히 아니다. 그래도 누른다.

이 장면이 개인의 게으름이 아니라 업계 평균이라는 데이터가 있다. 코드 품질 도구 회사 Sonar가 2026년 1월 8일 발표한 State of Code Developer Survey(전 세계 개발자 1,100명 이상 응답)에 따르면, 96%가 AI가 만든 코드가 기능적으로 맞다고 완전히 믿지 않는데, 커밋 전에 "항상" 확인한다는 응답은 48%였다. 이 글은 AI 코드 리뷰 안 하면 생기는 일을 겁주려는 글이 아니다. 그 간극이 왜 생기는지, 그리고 어떻게 습관으로 닫는지에 대한 이야기다.

96%와 48% 사이에 쌓이는 것

AWS CTO 베르너 보겔스는 이 간극에 이름을 붙였다. 검증 부채(verification debt). 기술 부채가 "나중에 고칠 코드"라면, 검증 부채는 "아무도 제대로 읽지 않은 채 들어간 코드"다. 같은 조사에서 개발자들은 커밋된 코드의 42%가 AI 도움을 받은 코드라고 답했고, 2027년엔 65%까지 오를 것으로 봤다. 부채의 원금이 매년 불어난다는 뜻이다.

그럼 검토 없이 들어간 AI 코드엔 실제로 뭐가 있을까. 서로 다른 세 기관의 측정을 나란히 놓으면 이렇다.

출처: CodeRabbit State of AI vs Human Code Generation · Veracode 2025 GenAI Code Security Report

핵심은 세 번째 줄이다. "맞아 보인다." 컴파일되고, 테스트도 대충 통과하고, 변수명까지 그럴듯하다. 눈으로 훑으면 걸리지 않는 종류의 결함이라는 얘기다.

게으름이 아니라 비용 문제다

여기서 흔한 처방은 "더 꼼꼼히 보라"다. 그런데 데이터는 다른 쪽을 가리킨다.

Sonar 응답자의 38%는 AI 코드를 리뷰하는 게 동료가 쓴 코드보다 더 힘들다고 답했다. 쉽다는 쪽은 27%. 사람 코드는 작성자에게 "왜 이렇게 했어?"라고 물으면 되지만, AI 코드엔 그 의도를 기억하는 사람이 없다. 리뷰어가 의도까지 역으로 복원해야 한다.

더 불편한 연구도 있다. METR은 2025년 2~6월, 숙련 오픈소스 개발자 16명이 자기 저장소의 실제 과제 246개를 푸는 과정을 무작위 실험으로 쟀다. AI를 쓸 때 작업 시간이 19% 늘었는데, 정작 본인들은 20% 빨라졌다고 느꼈다. 늘어난 시간의 상당 부분은 프롬프트 작성과 AI 출력 검토였다. (METR은 현재 이 결과를 당시 도구 기준의 "역사적" 수치로 표시하고 있으니, 오늘 도구에 그대로 대입하진 말자. 원문)

매 PR마다 도는 3단계 리뷰 루틴

순서가 중요하다. 위에서 아래로 줄 단위로 읽는 방식은 AI 코드에서 가장 비효율적이다. 600줄 중 위험한 곳은 보통 30줄 안쪽이다.

1먼저 볼 곳: 경계부터

diff를 열면 곧바로 이 네 군데만 찾는다. 외부 입력을 받는 곳, 권한을 판단하는 곳, 데이터를 쓰거나 지우는 곳, 네트워크·DB·파일 I/O를 부르는 곳. CodeRabbit 분석에서 AI PR은 보안 이슈가 1.5~2배, 과도한 I/O 같은 성능 문제가 8배 가까이 많았다. 그 결함들이 사는 동네가 바로 여기다. 스타일, 네이밍, 주석은 마지막에. 아니, 린터에 맡겨라.

2테스트가 있는가, 그리고 진짜 실패했었나

테스트 파일이 diff에 없다면 거기서 멈춘다. 있다면 두 가지를 더 본다. 기존 테스트의 기대값이 "통과하도록" 바뀌진 않았는가. 새 테스트가 수정 전 코드에서 실제로 실패하는가. 에이전트는 빨간불을 초록불로 바꾸라는 지시를 테스트를 느슨하게 하는 방식으로도 완수한다.

# PR 브랜치에서: 테스트는 두고 구현(src/)만 main 기준으로 되돌린다
git checkout origin/main -- src/
npm test -- tests/auth.spec.ts   # 여기서 빨간불이어야 정상
git checkout HEAD -- src/        # 원상복구

3왜(why)를 내 말로 세 문장

마지막이 제일 싸고 제일 강력하다. PR 설명을 덮고 "무엇을, 왜, 무엇을 포기했나"를 세 문장으로 써 본다. 막히는 문장이 곧 내가 이해 못 한 부분이다. 쓸 수 없으면 머지하지 않는다. 이 한 가지 규칙만으로도 "나도 모르는 코드가 내 이름으로 들어가는" 일은 거의 사라진다.

루틴을 습관으로 굳히는 장치

의지는 금요일 오후 5시 40분에 가장 약하다. 그래서 루틴을 사람 머리가 아니라 도구에 심어 둔다.

• PR 템플릿에 3칸 고정 — "경계 변경 여부 / 테스트가 수정 전 실패했는가 / 왜 세 문장". 빈칸이면 리뷰 요청 자체를 보내지 않는다.
• AI 리뷰어는 1차 필터로만 — 자동 리뷰 봇이 스타일과 뻔한 버그를 걸러 주면 사람은 2·3단계에 집중할 수 있다. 다만 봇이 승인했다고 3단계를 건너뛰면 검증 부채를 봇에게 떠넘긴 것일 뿐이다.
• diff 크기 상한 — 팀 합의로 400줄 같은 선을 정하고, 넘으면 쪼갠다. 숫자 자체보다 "넘으면 쪼갠다"는 규칙이 있다는 게 중요하다.

한 가지는 짚고 가자. 이 루틴이 AI 코드를 사람 코드만큼 안전하게 만든다는 보장은 없다. 보장하는 건 하나다. 머지된 코드마다 적어도 한 사람은 그 코드가 왜 거기 있는지 설명할 수 있다는 것.

마지막으로, 질문 하나

Sonar CEO 타리크 쇼캣은 이제 가치는 "코드를 쓰는 속도가 아니라 배포하는 자신감"에서 나온다고 했다. 속도는 이미 AI가 줬다. 남은 건 자신감 쪽이다.

지난주 당신이 머지한 AI PR 중 하나를 골라, 지금 PR 설명을 보지 않고 "왜"를 세 문장으로 써 보자. 써진다면 당신은 48% 쪽이다. 안 써진다면, 다음 PR부터 3단계 루틴을 붙여 볼 차례다.