9일 동안 449건. 인간 최고 리뷰어의 63배 속도. 숫자만 보면 AI 코드 리뷰 자동화는 명백한 승리처럼 보인다. 하지만 이 실험을 직접 설계하고 돌린 개발자 Alexey Pelykh는 커뮤니티로부터 "AI 쓰레기를 멈춰라"는 말을 들어야 했다. 그리고 같은 시기, AI 개발 생태계를 떠받치는 LiteLLM 패키지가 공급망 공격에 뚫렸다. 두 사건은 별개처럼 보이지만, 같은 질문을 가리킨다. AI 도구를 파이프라인에 넣을 때, 우리는 무엇을 검증하고 있는가?
449건 실험이 드러낸 진짜 숫자
Odoo 커뮤니티(OCA)의 6개 저장소에서 28%의 PR이 단 한 번도 리뷰를 받지 못했다. 984건은 리뷰 없이 병합됐고, 471건은 봇이 닫았다. Pelykh는 이 공백을 Claude Code로 채우기로 했다. 결과는 하루 49.9건, 9일 합산 112시간 분량의 리뷰 작업이었다.
문제는 품질 측정 방식에서 시작됐다. AI에게 자기 리뷰를 자체 평가시켰더니 98.6% 유효라는 결과가 나왔다. 그는 이 숫자를 즉시 버렸다. 대신 40개의 독립 검증 인스턴스를 돌려 실제 PR diff와 대조했다. 보정된 수치는 68.9% 완전 유효, 22.0% 부분 유효, 7.5% 고무도장(내용 없는 승인), 0.9% 무효였다. 자체 평가와 독립 검증 사이의 30포인트 갭—이것이 이 실험의 핵심 발견이다.
AI가 실제로 잡아낸 것도 있다. 포털 sudo 우회, 공개 인증 엔드포인트의 크로스 레코드 토큰 노출, getattr 트래버설 등 6건의 보안 취약점이 실제 코드에서 발견됐다. 사람 리뷰어 2~3명이 승인한 PR에서도 루프 내 return True 버그와 or→and 로직 회귀가 잡혔다. 반면 AI는 이미 수개월 전 커뮤니티 합의로 제거된 기능을 "누락"이라며 지적하기도 했고, 18.0 마이그레이션 PR에 16.0 버전의 존재하지 않는 변수명을 언급하기도 했다.
품질 곡선도 눈여겨봐야 한다. 초기 저장소에서 34%였던 완전 유효율이 중반 작업에서 87%까지 올라갔다가, 볼륨을 밀어붙이자 다시 70%로 내려갔다. 볼륨 피로는 AI 파이프라인에도 실재한다. 속도를 최대로 올리면 품질이 깎인다는 단순한 진실이 데이터로 확인된 것이다.
공급망 공격이 AI 인프라를 직접 겨냥했다
같은 시기에 터진 LiteLLM 공급망 공격은 다른 차원의 경고다. 월 9700만 다운로드의 AI 게이트웨이 LiteLLM이 PyPI를 통해 악성 버전을 배포했다. 공격 경로는 교과서적이었다. 공격자 그룹 TeamPCP가 CI/CD 파이프라인에서 사용하는 Trivy GitHub Action의 Git 태그를 변조했고, LiteLLM이 버전을 고정하지 않은 채 이를 실행하면서 PyPI 퍼블리시 토큰이 탈취됐다. 이후 두 개의 악성 버전이 수 시간 동안 PyPI에 올라왔다.
pip install litellm 한 줄이면 충분했다. SSH 키, 클라우드 자격 증명, Kubernetes 시크릿, API 키, 데이터베이스 패스워드가 RSA 암호화된 채 외부 도메인으로 빠져나갔다. 특히 1.82.8 버전의 .pth 파일은 Python 시작 시 자동 실행되기 때문에 명시적 임포트조차 필요 없었다. 공격이 외부로 드러난 건 포크 폭탄 버그 덕분이었다—1만1천 개 이상의 Python 프로세스가 생성되며 시스템이 멈추지 않았다면, 이 공격은 훨씬 오래 숨어 있었을 것이다.
dev.to의 사건 분석과 GeekNews의 분 단위 대응 기록에 따르면, 이 공격을 실시간으로 탐지하고 분석하는 데 Claude Code가 핵심 역할을 했다. 비보안 전문가가 악성 코드 구조를 분석하고, 신고 경로를 파악하고, PyPI 보안팀에 보고하는 전 과정을 AI가 단계별로 안내했다. 보고 후 PyPI가 패키지를 격리하기까지 걸린 시간은 30분이었다.
AI-First 파이프라인이 먼저 잠가야 할 두 개의 문
두 사건을 나란히 놓으면 AI 코드 리뷰 자동화 도입 시 챙겨야 할 리스크의 양면이 선명해진다.
품질 함정: AI의 자체 평가를 믿지 말 것. 98.6%와 68.9%의 차이가 그 증거다. 독립 검증 레이어를 파이프라인에 명시적으로 설계해야 한다. 볼륨을 높이면 품질이 깎인다는 사실도 운영 정책에 반영해야 한다—AI 리뷰를 '빠르게 많이'가 아니라 '충분히 느리게, 검증과 함께'로 설계하는 것이 핵심이다.
보안 함정: AI 코드 리뷰 파이프라인 자체가 공격 대상이 될 수 있다. Claude Code, LiteLLM, Trivy 같은 AI 인프라 컴포넌트는 CI/CD 환경 변수와 자격 증명에 직접 접근한다. 의존성 버전 고정, .pth 파일 같은 비표준 실행 경로 모니터링, AI 게이트웨이의 격리 배포—이 세 가지는 선택이 아니라 기본값이 되어야 한다.
그래서 도입할 것인가, 말 것인가
AI 코드 리뷰 자동화를 도입하지 말자는 결론이 아니다. 138개의 PR이 처음으로 리뷰를 받았다는 사실, AI가 사람 리뷰어 셋이 놓친 보안 취약점을 잡아냈다는 사실은 무시할 수 없다. 문제는 도입 여부가 아니라 어떻게 도입하는가다.
실험 데이터가 제안하는 운영 원칙은 세 가지다. 첫째, AI 리뷰는 인간 리뷰를 대체하는 게 아니라 커버리지 공백을 메우는 용도로 포지셔닝하라. 둘째, 자체 평가 루프를 파이프라인 지표로 쓰지 말고 독립 검증을 별도 단계로 구성하라. 셋째, AI 도구 자체의 공급망 보안을 코드 품질만큼 진지하게 다뤄라—버전 고정, 격리 환경, 자격 증명 분리는 AI 파이프라인의 기본 위생이다.
AI 코드 리뷰가 '속도'를 약속한다면, 팀의 숙제는 그 속도를 '신뢰할 수 있는 속도'로 만드는 구조를 짜는 것이다. 검증 레이어 없는 자동화는 빠른 실수를 더 빠르게 만들 뿐이고, 보안이 빠진 AI 인프라는 공격자에게 더 넓은 진입로를 내어준다. 두 사건이 동시에 터진 건 우연이 아니다—AI 도구가 팀 워크플로우의 중심에 들어올수록, 그 도구가 만들어내는 취약점도 중심부에 자리를 잡는다.