AI가 짠 코드 리뷰하는 법 — 겉보기 멀쩡한데 틀린 코드 잡는 6단계

AI가 코드를 짜주면 얼핏 돌아가서 그대로 커밋하고 넘어가기 쉽습니다. 문제는 겉보기 멀쩡한 코드일수록 경계값이나 타임존에서 조용히 어긋나, 몇 주 뒤 디버깅 비용으로 몇 배 돌아온다는 점입니다. AI로 코드를 짜고 그 결과를 직접 리뷰하며 겪어보니, 오차 대부분은 모델이 아니라 사람의 검증 습관에서 새어 나갔습니다. 이 순서대로 가면 AI 코드에서 놓치기 쉬운 오류를 6단계로 걸러내는 흐름이 손에 잡힙니다.

1. AI 코드에서 진짜 위험한 건 "겉보기 멀쩡한 코드"

AI 코드 리뷰에서 사람들이 먼저 걱정하는 건 컴파일 에러나 대놓고 안 도는 코드입니다. 그런 건 실행 한 번이면 걸립니다. 진짜 위험한 건 데모 데이터로는 멀쩡히 돌아가는데, 특정 입력에서만 틀리는 코드입니다. 리뷰 없이 통과되면 프로덕션에서야 드러납니다.

이 글은 AI에게 코딩 제대로 시키는 법 — 프롬프트를 '스펙'으로 쓰는 5가지의 후속입니다. 앞 글이 AI에게 잘 시키는 입력을 다뤘다면, 여기는 나온 결과물을 어떻게 검증하는 출력 쪽입니다. 스펙으로 헛짓을 줄였다면, 남은 오차는 리뷰로 잡는 순서입니다.

 

AI 생성 코드는 사람이 짠 코드보다 더 그럴듯하게 틀립니다. 변수명도 깔끔하고 주석도 붙어 있어 "잘 짰네" 하고 넘기기 쉽죠. 그래서 AI 코드 리뷰는 신뢰가 아니라 의심에서 출발합니다.

2. AI 코드가 자주 숨기는 함정 유형

AI가 자주 틀리는 자리는 대체로 정해져 있습니다. 아래 표로 점검 포인트를 정리했습니다.

함정 유형	왜 AI가 자주 틀리나	리뷰 때 볼 곳	자동 검증 방법
null·undefined	입력이 항상 존재한다고 가정	외부 응답·옵셔널 필드 접근부	타입체크(strict)·옵셔널 체이닝
타임존·날짜 경계	학습 데이터가 로컬 기준이 많음	new Date()·자정 경계 계산	UTC 고정 + 경계값 테스트
off-by-one 경계값	반복문 끝 인덱스 처리에 약함	<= vs <, 배열 마지막·빈 배열	경계 케이스 단위 테스트
숨은 가정	정렬·중복 없음을 암묵 전제	"항상 정렬돼 있음" 같은 전제	property 기반 테스트
가짜 라이브러리	존재하지 않는 패키지를 지어냄	import 목록·설치 안 된 이름	설치 전 레지스트리 확인
하드코딩 시크릿	예시 값으로 키·토큰을 박아둠	상수·URL·헤더의 문자열	시크릿 스캐너(pre-commit)

가장 자주 데인 건 타임존 경계입니다. AI는 "마감일이 지났는가" 같은 비교를 로컬 자정 기준으로 짜는데, 로컬 테스트는 다 통과하다 UTC 서버에 올리는 순간 하루가 밀리죠. off-by-one도 비슷해서, 예시 배열은 잘 돌지만 빈 배열이나 원소 1개를 넣으면 그제야 갈라집니다.

3. 리뷰의 핵심 질문 — "왜 이렇게 짰나" 되묻기

AI 코드 검증에서 가장 효율 좋은 도구는 정적 분석기가 아니라 질문입니다. 코드 조각마다 "왜 이 방식이지"를 되물으면, AI가 근거 없이 채운 자리가 드러납니다. 근거를 못 대는 코드가 대개 나중에 터지는 코드입니다.

 

AI가 짠 코드는 신뢰할 수 없는 입력으로 취급하는 편이 안전합니다. 사용자 입력을 검증 없이 믿지 않듯 AI 출력도 같은 등급으로 의심하는 거죠. 특히 AI는 해피패스 편향이 있어, "정상 흐름"만 먼저 완성하고 예외·실패 경로는 비워두기 일쑤입니다.

 

그래서 리뷰는 실패 경로부터 봅니다. 네트워크가 죽으면, 응답이 비면, 값이 음수면 어떻게 되는가. 정상 케이스는 어차피 눈에 들어오니, 시선을 비정상 입력 쪽에 먼저 두는 것이 실전 감각입니다.

4. 가짜 라이브러리·패키지 환각 걸러내기

AI 코드 리뷰에서 놓치기 쉬운 새 위험이 패키지 환각(slopsquatting)입니다. AI가 존재하지 않는 패키지 이름을 그럴듯하게 지어내고, 공격자가 그 이름으로 악성 패키지를 미리 올려두면, 무심코 설치하는 순간 공급망 공격이 됩니다. 이런 환각은 재현성이 있어 노려지기 쉽습니다.

 

리서치에 따르면 패키지 환각 비율은 오픈소스 모델에서 최대 20%대까지, 상용 모델은 한 자릿수(약 5%) 수준으로 보고됩니다(2026-08 기준, Snyk·CSA 리서치). 최신 모델도 4~6%대는 나올 수 있어, 규모와 무관하게 import는 그냥 믿으면 안 됩니다.

 

점검은 단순합니다. AI가 새 라이브러리를 끌어왔다면 설치 전에 세 가지를 봅니다. 레지스트리에 실존하는가, 최근 유지보수되고 다운로드가 정상인가, 알려진 취약점이 없는가. 이름이 익숙한 인기 패키지와 한 글자 다르면 특히 의심합니다. 공급망 각도의 실제 사고 흐름은 Vercel 침해 사고 분석에서 정리한 적이 있습니다.

5. 사람 눈 대신 자동 검증 붙이기

사람 눈은 반복에 약합니다. 같은 함정을 매번 손으로 잡는 대신, 앞 글에서 스펙의 한 축으로 강조한 검증을 파이프라인으로 내리는 편이 낫습니다. AI 코드 검증에서 사람이 할 일은 "무엇을 검증할지" 정하는 것이고, 실행은 도구에 맡깁니다.

• 타입체크: TypeScript strict, mypy 같은 정적 타입으로 null·undefined 상당수를 컴파일 단계에서 거릅니다.
• 테스트: 경계값(빈 배열·0·최댓값·타임존 경계)을 케이스로 고정하면, off-by-one과 날짜 경계가 재발해도 CI가 잡습니다.
• 정적 분석·린터: 미사용 변수, 안 잡힌 예외, 위험 패턴을 자동 표시합니다.
• 시크릿 스캐너: pre-commit 훅으로 하드코딩된 키·토큰을 커밋 전에 막습니다.

상용 AI 코드 리뷰 도구를 PR에 붙여 1차로 훑게 하는 것도 방법입니다. 다만 도구는 사람 리뷰를 대신하는 게 아니라 앞단을 걸러주는 역할이고, "이 로직이 요구사항과 맞는가"는 여전히 사람 몫입니다.

6. 실전 — 내가 AI 코드를 보는 6단계 순서

매번 즉흥으로 보면 빠뜨립니다. 저는 AI 코드 리뷰를 아래 6단계 순서로 고정해두고 위에서부터 내려갑니다.

1. 왜 이렇게 짰나 되묻기 — 의도와 대안을 설명하게 시킵니다. 근거 없는 코드를 먼저 걸러냅니다.
2. import·패키지 실존 확인 — 새로 끌어온 의존성을 레지스트리·유지보수·취약점으로 검증합니다.
3. 경계값 훑기 — null, 빈 배열, 0, 최댓값, 자정 경계를 손으로 대입해 봅니다.
4. 숨은 가정 찾기 — "항상 정렬돼 있다·항상 존재한다" 같은 암묵 전제를 드러냅니다.
5. 실패 경로 확인 — 에러·예외·타임아웃 처리가 비어 있는지 봅니다.
6. 자동 검증에 태우기 — 타입체크·테스트·정적 분석·시크릿 스캔을 통과시킵니다.

증상: AI가 만든 마감일 비교 로직이 로컬 테스트는 전부 통과했는데, 배포 후 일부 사용자에게만 마감이 하루 일찍 걸렸습니다.

원인: new Date()를 로컬 타임존 기준 자정으로 계산했는데, 서버는 UTC였습니다. AI가 같은 타임존이라는 해피패스만 가정한 결과였습니다.

해결: 날짜 경계를 UTC로 고정하고, 자정 직전·직후를 경계값 테스트로 추가했습니다. 이후 3단계 '경계값 훑기'에 타임존 경계를 고정 항목으로 넣었습니다.

정답이 하나는 아닙니다. 혼자 프로토타입을 빠르게 돌리는 단계면 1·3·6단계만으로도 충분하고, 팀 코드베이스에 병합하는 코드라면 6단계를 다 거치는 편이 안전합니다. 관건은 순서를 고정해 매번 같은 자리를 보는 것입니다.

Q&A — 자주 보는 질문 3개

Q. AI 코드 리뷰를 상용 도구에만 맡기면 안 되나요?
도구는 앞단을 걸러줄 뿐, "요구사항과 맞는가"는 판단하지 못합니다. 함정 유형 표를 기준으로 사람이 마지막에 한 번 훑는 편이 안전합니다.

Q. 매번 6단계를 다 도는 건 과하지 않나요?
코드 성격에 따라 다릅니다. 버리는 프로토타입이면 1·3·6만, 병합되는 코드면 전 단계를 권합니다. 순서를 고정해두면 실제 소요 시간은 생각보다 짧습니다.

Q. 패키지 환각은 정말 자주 일어나나요?
2026-08 기준 리서치에서 상용 모델도 한 자릿수 비율로 보고됩니다. 낮아 보여도 재현성이 있어 노려지므로, 새 import는 설치 전에 실존 여부부터 확인하는 게 맞습니다.

---

관련 글

• Claude Code 활용법 정리 — 망치는 습관 3개와 살리는 습관 7개
• Claude Code 서브에이전트 실전 배치 — 역할 분리부터 병렬 3~5개 스윗스팟까지
• 카파시 CLAUDE.md — GitHub 10만 스타 받은 65줄 파일 정리

설치 환경: Windows 11, Node.js v24, TypeScript strict, Claude Code + Gemini CLI 병행