AI 코딩 도구로 속도가 빨라지면 가장 먼저 흐트러지는 게 리뷰 문화입니다. "어차피 AI가 썼으니까"라는 면책 심리가 은근히 올라오고, 그 결과가 몇 주 뒤 장애로 돌아옵니다. 실제 운영 제품에 AI 생성 코드를 매주 올리면서 6개월간 지켜온 다섯 가지 원칙을 공유합니다.
원칙 1 — 테스트를 먼저 요구하라
기능 구현을 맡길 때 "테스트까지 작성하고 통과시킨 뒤 결과를 보여달라"고 지시하세요. Claude Code의 경우 단위 테스트 작성·실행·결과 보고까지 한 세션에서 처리합니다. 테스트가 돌아간다는 것은 코드가 최소 한 번 실행됐다는 증거이고, 이게 없으면 diff만 보고는 진짜 동작하는지 확신할 수 없습니다.
예외는 있습니다. 프로토타입 단계에선 테스트 부담이 오히려 생산성을 죽입니다. 하지만 "운영에 올릴 것"이라는 판단이 서는 순간 테스트는 필수입니다.
원칙 2 — 한 번에 너무 많은 변경을 맡기지 말 것
50개 파일을 한 번에 바꾸면 리뷰가 불가능해집니다. 기능 단위로 쪼개 PR을 작게 유지하세요. AI에게 맡기는 단위도 같습니다. "이 모듈 전체를 리팩토링해줘"보다 "이 파일의 에러 처리 중앙화 먼저"가 훨씬 안전합니다.
제 기준은 "한 PR에 기능 1개, diff 400줄 이하"입니다. 이 기준이 강제되면 AI 생성 코드도 자연스럽게 품질이 올라갑니다.
원칙 3 — 비즈니스 규칙은 반드시 사람이 검증
할인 계산, 권한 체크, 금액 반올림, 세금 적용 같은 "틀리면 돈으로 터지는" 부분은 AI 생성본을 그대로 믿지 마세요. 단위 테스트 + 실제 시나리오 수동 확인이 필수입니다.
예: "VAT 10% 적용" 같은 단순한 요구사항도 AI는 과세 구분(과세/면세/영세) 같은 국내 특수성을 놓칠 수 있습니다. 이런 도메인 특화 룰은 테스트 케이스를 인간이 먼저 정의하고 AI가 구현을 채우게 하는 순서가 안전합니다.
원칙 4 — 시크릿·보안은 코드에 박지 않기
AI가 환경변수 값을 "편의상" 하드코딩해 넣는 사례가 드물지 않습니다. .env의 값이 커밋된 코드에 그대로 들어간 PR을 여러 번 봤습니다.
.env.example만 커밋, 실제 값은 비밀 저장소(1Password, Vault, GitHub Actions Secrets) 사용- 커밋 전
git secrets·gitleaks·trufflehog같은 도구로 자동 검사 - AI에 지시할 때 "시크릿은 절대 코드에 넣지 말고 환경변수 참조만"을 명시
원칙 5 — 설명 가능한 diff만 머지
"왜 이렇게 변경했는지" 스스로 한 문단으로 설명할 수 없다면 아직 머지하지 않습니다. Claude Code에 "이 diff를 3줄로 요약해줘"를 주문하고, 그 요약이 PR 본문이 되게 하세요. 요약이 추상적이거나 뭘 했는지 불분명하면 diff를 다시 읽어야 할 신호입니다.
이 습관의 진짜 효과는 리뷰 품질이 아니라 작성자 본인의 이해도에 있습니다. 설명 못 하는 코드는 3개월 뒤 본인이 수정할 때 가장 고생합니다.
팀에 안착시키는 법
- PR 템플릿에 "AI 사용 여부 + 수동 검증 내용" 체크박스 추가
- 주 1회 15분, 팀원이 최근 쓴 AI 생성 코드 중 1개를 같이 리뷰하는 세션
- 실수한 케이스를 공개적으로 공유 (비난이 아니라 학습 목적)
속도는 도구가 만들고, 품질은 문화가 만듭니다. 팀 컨벤션을 AI 사용에도 동일하게 적용하는 것만으로도 충분합니다. 원칙 다섯 개가 많아 보이지만, 결국 한 문장으로 줄면 "AI도 주니어 동료라고 생각하고 대하라"입니다. 결과물을 믿되 검증하고, 속도를 얻되 기준을 낮추지 않는 태도가 장기적으로 가장 비용이 적게 드는 방식입니다.