AI가 코드를 빠르게 생성하면 리뷰도 빠르게 통과시키고 싶은 충동이 생긴다. 그 충동을 따라가면 어떻게 되는가? LLM에 코드 리뷰를 맡겼을 때 30개 지적이 돌아오고, 그 중 절반이 중복이며, 일부는 서로 모순된다. 자동화로 아낀 시간보다 결과물을 추려내는 데 더 많은 시간을 쓰게 된다. AI가 빠를수록 파이프라인 설계가 먼저여야 한다는 주장은 이 지점에서 출발한다.
단일 패스 리뷰의 구조적 한계
dev.to에 공개된 '6-Layer AI Code Audit Pipeline' 사례는 문제를 명확하게 진단한다. LLM에게 코드 전체를 한 번에 리뷰시키면 스코프 경계가 없기 때문에 보안, 버그, 스타일, 성능이 뒤섞인 결과가 나온다. 해결책은 에이전트를 늘리는 게 아니라 각 에이전트의 담당 범위를 비중첩으로 분리하는 것이다. 코드 품질 에이전트는 타입 안전성과 DRY, 복잡도를 본다. 그러나 보안과 런타임 버그는 명시적으로 보지 않는다. 보안 에이전트는 OWASP Top 10, 인젝션, 시크릿을 전담한다. 버그 스캐너는 Null 참조와 레이스 컨디션을 잡되 보안 취약점에는 손대지 않는다. 이 '하지 않는 것' 목록이 중복 제거의 핵심이다. 200파일 규모 파이썬 코드베이스 기준으로 6개 에이전트가 반환하는 40~50개 원시 발견 사항이 중복 제거 후 15~20개로 줄고, 그 중 P1 크리티컬은 2~3개에 불과하다. 출력이 줄어야 리뷰가 실행 가능해진다.
AI로 AI를 감시하는 것의 함정
여기서 냉정하게 짚어야 할 지점이 있다. 6개 에이전트를 병렬로 돌리고 아키텍트 리뷰 게이트까지 추가하는 방식은 효율적으로 보이지만, 'AI로 AI를 고치겠다'는 반사 반응과 한 발짝 차이다. dev.to의 'The Most Powerful Developer in the Room Has Never Heard of SOLID'는 이 구조를 정면으로 문제 삼는다. 비결정성을 더 많은 비결정성으로 고칠 수는 없다. AI 에이전트는 코드베이스의 아키텍처 결정 이력을 기억하지 못한다. 여섯 달 전에 팀이 내린 결정, 특정 패턴을 금지한 이유, 예외로 문서화된 규칙을 모른다. 겉으로 맞아 보이는 코드를 생성하면서 아키텍처를 조용히 위반한다. 스택을 쌓는다고 신뢰도가 높아지지 않는다. 프롬프트로 거버넌스를 구현하는 것은 거버넌스가 아니라 불안정한 계약자와의 협상이다.
결정론적 레이어가 필요한 이유
그렇다면 비결정성을 어떻게 다루는가. 답은 AI 레이어 위나 주변에 결정론적 시스템을 두는 것이다. CORE 프레임워크가 제안하는 구조가 이 원칙을 명확히 보여준다. AI의 출력은 제안(proposal)이지 실행(execution)이 아니다. 파일시스템에 닿기 전에 인간이 작성한 컨스티튜션—아키텍처 표준, 의존성 계약, 네이밍 컨벤션—을 통과해야 한다. 위반이 발생하면 실행이 멈춘다. 감사 추적은 로그에서 추론하는 게 아니라 검증 가능한 행으로 물질화된다. 6-Layer 파이프라인에서 아키텍트 리뷰 게이트(Step 6)가 APPROVED/REVISE/BLOCKED 판정을 내리는 구조도 같은 맥락이다. AI가 틀릴 수 있다는 전제 위에 시스템을 설계하는 것이다.
스펙이 파이프라인의 입력을 결정한다
파이프라인 구조만큼 중요한 것이 파이프라인에 무엇을 넣는가다. dev.to의 'I Refused to Write Specs Until Claude Code Generated Wrong Code Three Times'는 스펙 없이 프롬프트만으로 개발하는 방식의 실패를 직접적으로 보여준다. 멤버 할인과 프로모 코드를 처리하는 체크아웃 기능을 구현할 때, 명확한 제약 없이 프롬프트만 던지면 AI는 쿠폰에 쿠폰을 적용하는 로직을 세 번 연속 생성했다. OpenAPI 문서 작성에 15분을 투자하고 Gherkin 시나리오 세 개를 추가했더니 구현의 80%가 첫 시도에 맞게 나왔다. 스펙을 쓰는 행위 자체가 '쿠폰이 할인 대상 품목이 될 수 없다'는 모호성을 YAML 단계에서 죽인다. 모호한 스펙은 AI가 빠를수록 더 빨리 잘못된 방향으로 달린다.
세 레이어의 조합
세 소스를 종합하면 실무에서 작동하는 AI 코드 리뷰 파이프라인은 세 레이어의 순서가 중요하다. 첫째, 스펙 선행: OpenAPI와 Gherkin으로 제약과 경계를 먼저 문서화한다. 둘째, 스코프 분리 리뷰: 비중첩 에이전트가 각자의 전담 영역만 검사하고 중복 없는 발견 사항을 생성한다. 셋째, 결정론적 게이트: AI 출력이 인간이 정의한 컨스티튜션을 통과해야만 코드베이스에 반영된다. 이 순서를 건너뛰면 앞선 단계의 부재가 뒤 단계의 노이즈로 증폭된다.
팀에 당장 적용 가능한 출발점
세 레이어를 한 번에 구축하기는 어렵다. 현실적인 시작점은 있다. 신규 엔드포인트에는 OpenAPI 스펙을 CLAUDE.md와 함께 주는 것부터 시작한다. 기존 코드베이스에는 보안 에이전트 하나를 먼저 붙이고 스코프를 명시적으로 제한한다. 아키텍트 리뷰 게이트는 초기에 사람이 담당해도 된다. 중요한 것은 AI가 '무엇을 보지 않는지'를 먼저 정의하는 습관이다. 스코프를 정하지 않은 리뷰는 빠를수록 노이즈도 빠르다.
전망
AI 코딩 도구가 성숙해질수록 코드 생성 속도는 계속 빨라질 것이다. 그 속도를 받쳐줄 리뷰 파이프라인 설계 역량이 팀의 실질적인 차별점이 된다. 도구를 고르는 것보다 레이어를 나누는 것, 프롬프트를 다듬는 것보다 스코프를 정의하는 것이 먼저다. AI는 설계된 시스템 안에서만 신뢰할 수 있다.