AI가 짠 코드, 뭘 봐야 하나: 사람 쪽 리뷰 체크리스트 7가지

핵심 요약: AI 코드의 버그는 사람 코드와 분포가 다릅니다. 오타·문법 실수는 거의 없는 대신, 그럴싸하게 틀린 것 — 존재하지 않는 API, 미묘하게 다른 엣지 케이스 처리, 요구사항의 창의적 재해석 — 이 주종입니다. 그래서 리뷰 포인트도 달라야 합니다. 체크 순서: ① 요구사항과 실제 동작의 일치 ② 호출하는 API·함수의 실존 여부 ③ 엣지 케이스·에러 경로 ④ 조용한 가정(하드코딩·기본값) ⑤ 기존 코드와의 중복 ⑥ 테스트가 구현이 아니라 의도를 검증하는지 ⑦ 보안(입력 검증·시크릿). 통과 기준은 하나 — "내가 이 코드를 설명할 수 있는가."

이 글에서 다루는 내용: AI 코드 특유의 결함 패턴, 7가지 체크 항목, 리뷰 시간을 줄이는 요령.

전제: 버그의 분포가 다르다

사람 코드의 결함은 부주의(오타, 빠뜨림)에 몰려 있고, AI 코드의 결함은 확신에 찬 오류에 몰려 있습니다. 컴파일되고, 그럴듯하게 읽히고, 리뷰어의 경계심을 낮추는 코드 — 그래서 "훑어보니 깨끗하네"가 AI 코드 리뷰에서 가장 위험한 문장입니다. 리뷰 도구로 1차를 거르는 것(AI 리뷰 도구 비교)과 별개로, 사람이 봐야 할 지점이 있습니다.

체크리스트 7가지

① 요구사항 대조. 코드가 아니라 지시문을 먼저 다시 읽으세요. AI는 모호한 요구를 조용히 재해석합니다 — "무엇을 시켰나"와 "무엇이 왔나"의 대조가 리뷰의 시작입니다. ② API 실존 확인. 낯선 메서드·옵션이 보이면 문서를 확인하세요. 그럴싸한 이름의 존재하지 않는 API는 여전히 대표 결함입니다. 특히 버전 특정 기능 — 학습 데이터의 구버전 문법이 섞여 나옵니다. ③ 엣지 케이스와 에러 경로. 정상 흐름은 잘 짭니다. 빈 목록, null, 동시성, 실패한 외부 호출에서 뭘 하는지를 보세요. ④ 조용한 가정. 하드코딩된 값, 임의로 정한 기본값, "일단 이렇게" 처리 — diff에서 상수와 조건 경계값만 훑어도 잡힙니다.

⑤ 중복 구현. AI는 기존 유틸을 못 찾으면 새로 만듭니다. 어딘가 있을 법한 기능이 새로 구현돼 있으면 검색부터. ⑥ 테스트의 방향. AI가 테스트까지 짰다면, 그 테스트가 "의도"를 검증하는지 "현재 구현"을 고정하는지 구분하세요. 후자는 리팩토링을 방해하는 족쇄가 됩니다. ⑦ 보안 기본기. 입력 검증, 쿼리 파라미터화, 시크릿 하드코딩(시크릿 글) — 짧은 정규 목록으로 매번.

리뷰 시간을 줄이는 요령

순서를 바꾸면 빨라집니다 — 코드를 위에서 읽지 말고, ①(요구 대조) → diff의 경계값·상수 → 에러 경로 순으로 표적 검사한 뒤에 전체를 읽으세요. 그리고 리뷰에서 두 번 이상 나온 지적은 Rules·AGENTS.md에 규칙으로 승격해서(그 방법) 다음부터는 생성 단계에서 걸러지게 만드는 것 — 리뷰 부담을 줄이는 유일한 구조적 방법입니다.

제 리뷰 습관의 변화

솔직한 고백으로 마무리하면 — 처음엔 AI 코드를 사람 코드보다 대충 봤습니다. 깔끔해 보였으니까요. 그러다 "그럴싸한 존재하지 않는 옵션" 하나가 스테이징까지 간 뒤로 위 체크리스트를 만들었고, 지금은 오히려 사람 코드보다 다른 종류의 집중으로 봅니다. 걸리는 시간은 처음보다 줄었습니다 — 어디를 봐야 하는지 아니까요. AI 코드 리뷰는 더 열심히 하는 게 아니라 다르게 하는 것이라는 게 결론입니다.

자주 묻는 질문 (FAQ)

Q. AI 리뷰 도구가 있는데 사람 리뷰가 왜 필요한가요?

A. 도구는 패턴 결함(보안·스타일·명백한 버그)을 잘 잡고, "요구사항과 다르게 동작"은 요구를 아는 사람만 잡습니다. ①번이 사람 몫으로 남는 이유입니다.

Q. 리뷰할 시간이 없을 만큼 AI가 코드를 많이 만들어요.

A. 생성 속도에 리뷰가 밀리면 작업 단위를 줄이는 게 맞습니다. 리뷰 가능한 크기로 시키는 것도 명세 능력입니다 — 한 번에 34개 파일보다 3번에 나눠 받는 쪽이 총 시간이 적게 드는 경우가 많습니다.

Q. 주니어에게 AI 코드 리뷰를 맡겨도 되나요?

A. 이 체크리스트의 ②③⑦은 주니어에게 좋은 훈련입니다. ①(요구 해석)과 ⑤(코드베이스 지식)는 경험이 필요하므로 페어로 시작하는 것을 권합니다.

한눈에 보는 요약

요구 대조 → API 실존 → 엣지 케이스 → 조용한 가정 → 중복 → 테스트 방향 → 보안. 그리고 반복 지적은 규칙으로 승격. "설명할 수 있는 코드만 머지한다"가 최종 관문입니다.

함께 보면 좋은 글

AI 코드 리뷰 도구 비교
AI 생성 코드의 기술 부채 관리법
AI에게 좋은 작업 명세 쓰는 법

참고 자료

OWASP (보안 체크 기준)