AI 코딩 도구가 팀에 퍼지면서 이상한 역설이 생겼다. 코드는 더 빠르게 쌓이는데, 그 코드를 검증하는 속도는 그대로다. 심지어 리뷰어가 AI 생성 코드에서 뭘 봐야 하는지조차 헷갈리기 시작했다. 사람이 짠 코드와 AI가 짠 코드는 '어디서 틀리는가'가 다르기 때문이다. 지금까지 우리가 쌓아온 lint 규칙, SonarQube 설정, PR 체크리스트—그것들이 AI 생성 코드의 결함을 실제로 잡아주고 있는지 다시 따져볼 시점이다.
AI 생성 코드는 다른 방식으로 틀린다
dev.to에 소개된 Open Code Review 프로젝트가 정리한 AI 코드의 대표 결함 유형을 보면 패턴이 보인다. 존재하지 않는 npm 패키지를 import하는 '환각 임포트', 훈련 데이터 컷오프 때문에 2년 전에 deprecated된 API를 그대로 쓰는 '스테일 API', 컨텍스트 윈도우가 잘리면서 생긴 dead code 덩어리들. ESLint도, SonarQube도 이 유형들을 제대로 잡지 못한다. 2024년 연구 기준으로 AI 코딩 어시스턴트가 잘못된 패키지 참조를 생성하는 비율이 약 3.4%인데, 임포트 1,000개짜리 코드베이스라면 런타임에서 조용히 터지는 환각 패키지가 34개라는 뜻이다. 기존 툴체인이 이걸 잡지 못한다면, 품질 게이트를 다시 설계해야 한다.
리뷰 자동화의 현실: GitHub Copilot 8개 레이어
dev.to의 'Mastering Code Reviews with GitHub Copilot' 가이드는 Copilot이 코드 리뷰에 진입할 수 있는 표면을 8개로 분류한다. GitHub.com 네이티브 PR 리뷰, VS Code 선택 리뷰, 커스텀 인스트럭션, 프롬프트 파일, 커스텀 에이전트, MCP 기반 PR 분석, GitHub Actions 코딩 에이전트, Copilot CLI 프리커밋 체크. 여기서 팀 단위로 가장 빠르게 ROI를 낼 수 있는 진입점은 GitHub.com 네이티브 리뷰다. PR 사이드바에서 Copilot을 리뷰어로 지정하거나, 모든 PR에 자동으로 붙도록 설정하면 된다. 추가 설정 없이도 작동하고, 자동화 수준이 높다.
하지만 이 기본 세팅만으로는 팀의 실제 기준을 반영하지 못한다. 핵심은 .github/copilot-code-review-instructions.md에 팀의 리뷰 기준을 자연어로 정의하는 것이다. DB 쿼리는 반드시 파라미터 바인딩, 시크릿은 환경변수에서만, 퍼블릭 메서드는 단위 테스트 필수—이런 룰을 파일에 명시해두면 Copilot이 PR을 분석할 때 이 기준을 적용한다. 일반적인 AI 피드백을 팀 표준에 맞는 피드백으로 바꾸는 가장 빠른 방법이다. 반대로 말하면, 이 파일이 없으면 Copilot은 일반론적 코멘트만 달게 된다.
CI/CD에 AI 전용 품질 게이트 추가하기
Open Code Review는 AI 생성 코드에 특화된 오픈소스 CI/CD 품질 게이트다. L1 레이어는 AI 없이도 돌아가는 정적 분석으로, npm/PyPI 레지스트리를 실제로 조회해 환각 임포트를 탐지하고, AST 기반으로 deprecated API를 잡고, SQL 인젝션 패턴과 과도한 복잡도를 걸러낸다. 전체 스캔이 10초 이내에 끝난다. L2 레이어는 로컬 Ollama 모델을 사용해 파일 간 의미적 일관성과 AI 생성 코드의 신뢰도 점수까지 분석한다. 코드가 외부로 나가지 않는다는 점도 엔터프라이즈 환경에서는 실질적인 장점이다.
GitHub Actions 통합은 간단하다. raye-deng/open-code-review@v1 액션을 파이프라인에 추가하고 threshold를 60으로 설정하면, 점수 미달 PR은 머지가 막힌다. SARIF 포맷 출력을 활성화하면 탐지된 결함이 GitHub Security 탭에 기존 의존성 취약점 알림과 나란히 노출된다. 팀 입장에서는 별도 대시보드를 만들 필요 없이 기존 워크플로우에 자연스럽게 붙는다.
도구보다 중요한 것: 피드백 루프 설계
brunch에 올라온 'Claude Code를 쓰면서 깨달은 3가지'는 도구 설정 레벨 너머의 이야기를 한다. 저자가 정리한 핵심은 세 가지다. 결과물을 요청하기 전에 문제를 먼저 같이 정의할 것, 중요한 논의는 기록 전담 에이전트를 별도로 붙여 맥락을 세션 간에 이어갈 것, 그리고 결과물이 나왔을 때 바로 끝내지 말고 피드백 루프를 3~4회 돌릴 것. 이 인사이트는 코드 리뷰에도 그대로 적용된다. AI 리뷰어가 달아준 코멘트를 수락하거나 닫는 것으로 끝내는 게 아니라, "이 구조에서 나중에 문제가 될 지점이 어디야?"를 다시 물어보는 루프를 설계해야 한다.
테크 리드가 지금 당장 해야 할 설계 결정
세 가지 소스가 수렴하는 실천 포인트는 명확하다. 첫째, Copilot 네이티브 리뷰를 켜되, .github/copilot-code-review-instructions.md로 팀 기준을 주입하라. 기본값으로 두면 효과가 절반이다. 둘째, CI/CD 파이프라인에 AI 생성 코드 전용 품질 게이트를 추가하라. 기존 ESLint와 SonarQube는 환각 임포트와 스테일 API를 잡지 못한다. Open Code Review L1 스캔을 diff 모드로 붙이는 것만으로도 지금 당장 커버리지가 달라진다. 셋째, 인간 리뷰어의 역할을 재정의하라. 기계가 잘 잡는 것(네이밍, deprecated API, 보안 패턴)은 자동화에 맡기고, 인간 리뷰어는 도메인 로직과 아키텍처 판단에 집중해야 한다.
전망: 리뷰 레이어가 표준이 될 것이다
AI 코딩 도구의 확산 속도를 보면, 1~2년 안에 'AI 생성 코드 품질 게이트'는 선택이 아니라 표준 인프라가 될 것이다. 지금 GitHub Copilot이 8개 리뷰 표면을 제공하는 것처럼, 다른 도구들도 자체 검증 레이어를 통합해 나갈 것이다. 문제는 도구가 없어서가 아니라, 팀이 이 레이어들을 어떻게 쌓고 역할을 어떻게 나눌 것인가를 명확히 설계하지 않는 데 있다. AI가 짠 코드를 AI가 리뷰하는 파이프라인을 구성하는 것은 이미 가능하다. 그 파이프라인이 실제로 품질을 올리는지 검증하고, 팀이 신뢰할 수 있는 구조로 유지하는 것—그것이 지금 테크 리드의 진짜 업무다.