리뷰어가 이미 지고 있는 싸움
Faros가 10,000명 이상의 개발자, 1,255개 팀 데이터를 분석한 결과는 냉정하다. AI 도입률이 높은 팀에서 작업 완료량은 21% 늘었고 PR 병합은 98% 증가했다. 그런데 PR 리뷰 시간은 91% 폭증했다. 생산성이 오른 게 아니라 리뷰 병목이 새로운 위기로 자라난 것이다. 500줄짜리 diff를 며칠째 방치하거나, 훑어보고 형식적으로 승인 누르는 장면—당신의 팀에서도 벌어지고 있다면, 이미 이 싸움에서 밀리고 있는 거다.
AI 코드 리뷰 도구도 임시방편일 뿐
여기서 흔히 드는 생각이 'AI로 리뷰를 자동화하면 되지 않나?'다. dev.to에 공개된 CodeLens 사례처럼, Groq API와 llama-3.3-70b를 엮어 SQL 인젝션·메모리 누수·O(n²) 루프를 자동 탐지하고 수정 코드까지 뽑아내는 도구는 이미 만들 수 있다. OpenAI API를 활용한 PR 자동 리뷰어 구현도 어렵지 않다. 프롬프트 엔지니어링으로 BUG·SECURITY·PERFORMANCE를 JSON 구조로 뽑고, 라인 번호 할루시네이션은 코드에 줄 번호를 붙여 넘기는 방식으로 대부분 해결된다.
하지만 솔직하게 짚자. AI가 코드를 쓰고 AI가 리뷰한다면, 그건 승인 게이트를 하나 추가한 것에 불과하다. 같은 맹점을 가진 에이전트가 같은 에이전트의 산출물을 검토하는 구조—가치는 게이트가 아니라 반복 루프 안에 있다. AI 코드 리뷰 도구는 시간을 벌어줄 뿐이며, 근본적인 패러다임 전환 없이는 병목이 한 칸 오른쪽으로 이동하는 것에 그친다.
패러다임 전환: 코드 리뷰 → 의도(Intent) 리뷰
진짜 해법은 인간 체크포인트를 상류(upstream)로 옮기는 것이다. 'How to Remove Code Review'라는 글이 제시하는 핵심 논지가 바로 이것이다. 코드를 읽는 대신 스펙과 수용 기준(Acceptance Criteria)을 리뷰하라.
워터폴 사인오프가 지속적 통합(CI)으로 이동했듯, 이제 리뷰 게이트도 이동한다. 새로운 패러다임에서 스펙이 진실의 원천(source of truth)이 되고, 코드는 스펙의 산출물이다. Human-in-the-loop 승인의 질문이 바뀐다.
"이것을 올바르게 작성했는가?" → "올바른 제약조건으로 올바른 문제를 풀고 있는가?"
가장 가치 있는 인간의 판단은 첫 번째 줄이 생성되기 전에 발휘된다. 500줄짜리 diff가 나온 뒤가 아니라.
다층 신뢰 구조: 스위스 치즈 모델로 설계하라
LLM은 자기 검증에 신뢰할 수 없다. 코드가 타는 중에도 자신 있게 "작동한다"고 답한다. 그래서 검증을 LLM에게 묻는 대신, 검증하는 스크립트를 LLM이 작성하게 해야 한다—판단이 아닌 산출물로 전환이다. 불완전한 필터를 겹겹이 쌓아 구멍이 정렬되지 않도록 하는 스위스 치즈 모델이 실용적인 답이다.
Layer 1 — 다중 옵션 비교: 에이전트 하나에 정답을 요구하지 말고, 세 에이전트가 각자 다른 방식으로 시도하게 한다. 가장 많은 검증 단계를 통과한 것, 가장 작은 diff, 새 의존성을 추가하지 않은 것을 기준으로 자동 순위를 매긴다. 옵션의 비용이 소프트웨어 엔지니어링 역사상 가장 낮은 지금이 이 방식을 쓸 때다.
Layer 2 — 결정론적 가드레일: LLM에게 "됐어?"를 묻는 대신 pass/fail 산출물을 뽑는 검증 단계를 정의한다. 코딩 가이드라인(커스텀 린터), 조직 불변 규칙(하드코딩 자격증명 금지), 도메인 계약(결제 도메인의 Money 타입 강제), 수용 기준—이 네 층이 가드레일 계층 구조를 이룬다. 검증 기준은 코드 작성 전에 정의돼야 한다. 사후에 만들면 이미 구현에 오염된다.
Layer 3 — 인간이 수용 기준을 정의: BDD(Behavior-Driven Development)가 에이전트 시대에 새롭게 유효해진다. 과거에는 스펙 작성이 '추가 작업'처럼 느껴졌지만, 에이전트가 구현을 담당하는 지금은 스펙이 1차 산출물이다. 인간이 스펙을 쓰고, 에이전트가 구현하고, BDD 프레임워크가 검증—실패하지 않는 한 구현 코드를 읽을 필요가 없다.
Layer 4 — 권한 시스템을 아키텍처로: 에이전트가 무엇을 건드릴 수 있는지가 아키텍처 결정이어야 한다. "utils/dates.py의 날짜 파싱 버그 수정" 작업이라면 해당 파일과 테스트 파일만 접근을 허용한다. 인증 로직 수정, DB 스키마 변경, 새 의존성 추가—이런 패턴은 에이전트의 확신도와 무관하게 자동으로 인간 리뷰를 트리거해야 한다.
Layer 5 — 적대적 검증: 하나의 에이전트가 작업하고, 다른 에이전트가 검증—서로를 신뢰하지 않는 것이 핵심이다. 코딩 에이전트는 검증 에이전트가 무엇을 확인할지 모르고, 검증 에이전트는 코드를 수정할 수 없다. 설계상 적대적인 구조다. 더 나아가 세 번째 에이전트가 엣지 케이스와 실패 모드를 겨냥해 파괴를 시도하는 레드팀/블루팀 자동화를 모든 변경에 적용할 수 있다.
팀 리드가 지금 당장 바꿔야 할 것
이 모든 구조를 한 번에 도입할 필요는 없다. 내일 당장 실행 가능한 순서를 제안하면 이렇다.
- 스펙 문서를 먼저 쓰는 문화부터 시작한다. PR을 열기 전에 수용 기준을 한 페이지로 정리하는 것—이게 가장 낮은 비용의 첫 번째 레이어다.
- 결정론적 가드레일을 자동화한다. 하드코딩된 자격증명, API 키, 특정 도메인 타입 위반을 CI에서 자동 차단하는 린터 규칙을 추가한다. AI 코드 리뷰 도구(CodeLens 류)는 이 단계의 보조 수단으로 활용한다.
- 에스컬레이션 트리거를 명문화한다. 어떤 패턴이 인간 리뷰를 강제하는지 팀 문서에 적는다. 에이전트가 확신에 차 있어도 사람이 봐야 하는 영역을 아키텍처 수준에서 규정하는 것이다.
코드 리뷰의 미래: 느린 리뷰 vs. 빠른 롤백
"빠르게 배포하고, 모든 것을 관찰하고, 더 빠르게 되돌린다"—이것이 느린 리뷰 후 프로덕션 디버깅을 대체하는 새 패러다임이다. feature flag, 점진적 롤아웃, 즉시 롤백은 이미 우리 손에 있는 도구다. 리뷰가 있어도 장애는 발생했다. 그 현실을 직시하면 관찰 가능성과 롤백 속도에 투자하는 게 500줄 diff를 훑는 것보다 더 합리적인 품질 전략임을 인정할 수 있다.
기계를 더 많이 읽어서 이기는 게임은 끝났다. 이제 결정이 실제로 중요한 상류에서 기계보다 더 나은 판단을 내리는 것—그게 AI 시대 개발자와 팀 리드의 핵심 역할이다. 코드 리뷰를 없애는 게 아니라, 인간이 가장 잘할 수 있는 자리로 코드 리뷰를 이동시키는 것이다.