본문으로 건너뛰기
중급

검증 병목

What you'll learn
  • 패턴 보기: AI는 병목을 코드 작성에서 코드 신뢰로 옮겼다 — 그리고 이를 증명하는 업계 데이터
  • AI가 생성한 PR을 리뷰하는 데 유독 비용이 많이 드는 세 가지 힘(볼륨, 컨텍스트 손실, 그럴싸함 편향) 이해
  • 기본 점검, AI 트리아지 및 집중된 인간 판단을 분리하는 3계층 라우팅 학습
  • AGENTS.md / CLAUDE.md + 서비스별 규칙 스택을 사용해 코드베이스 인식 리뷰어 설정
  • 복리 루프 알기 — 월간 규칙 추가가 12주에 걸쳐 팀 취향을 기계 확인 가능한 정책으로 어떻게 전환시키는지

AI 코딩 에이전트를 도입한 첫 해에 거의 모든 팀이 걸리는 패턴이 있다:

Cursor / Copilot / Claude Code가 들어왔다. 피처 브랜치 처리량이 뛰어올랐다. 그런 다음 리뷰 큐가 악화되고, 사이클 타임이 평평해졌고, 그 성과가 어디로 갔는지 아무도 알아낼 수 없었다.

이것이 검증 병목이다. 코드 작성은 결코 코드 배포의 전체 비용이 아니었다 — 코드를 리뷰하고, 신뢰하고, 병합해도 안전한지 결정하는 것이 항상 그랬다. AI는 첫 번째 부분의 가격을 한 자릿수 낮췄고 나머지 시스템은 같은 가격으로 남겨두었다.

한 문장으로 정리한 패턴​

AI는 코드를 신뢰하는 비용을 줄이기 전에 코드를 생산하는 비용을 줄인다. 제약이 옮겨간다. 워크플로우를 함께 옮기지 않으면 파이프 상단의 처리량이 리뷰 단계에서 쌓이기만 한다.

또는, Codacy의 현상 요약에서: "더 많은 코드가 풀 리퀘스트 큐에 도달하고, 더 많은 변경이 검증을 필요로 하며, 위험한 작업을 리뷰하도록 신뢰받는 사람들은 여전히 주당 같은 시간을 가진다."

업계 데이터 (2025–2026)​

이 형태는 여러 독립적인 데이터셋에 걸쳐 나타난다:

신호발견출처
피처 브랜치 처리량AI 도입 팀에서 +59% YoYCodacy (2026)
메인 브랜치 처리량 (중간 팀)−7% YoY, 성공률 **70.8%**로 하락Codacy (2026)
AI 지원 PR의 픽업 타임리뷰어가 시작하기까지 2.47배 더 긴 대기Codacy (2026)
완전 에이전트 PR의 픽업 타임5.3배 더 긴 대기Codacy (2026)
제로 리뷰로 병합되는 PRAI 중심 팀에서 +31%Codacy (2026)
AI 지원 PR의 크기전통적 PR보다 ~18% 더 큼Jellyfish, MetaCTO 인용 (2026)
AI 코드 정확성에 대한 신뢰 (개발자 설문)29% — 역사적 최저Stack Overflow Developer Survey 2025

이 숫자들이 말하지 않는 것에 주목하라. AI가 나쁜 코드를 작성한다고 말하지 않는다. AI 하류의 파이프라인이 AI 생성 변경이 가져오는 볼륨, 크기 및 컨텍스트 손실을 위해 설계되지 않았다고 말한다.

AI 생성 PR이 리뷰하기에 유독 비용이 많이 드는 이유​

세 가지 힘이 쌓인다:

1. 볼륨. 하나의 프롬프트는 하루가 걸리던 것을 생성할 수 있다. 팀이 3배의 PR을 생산하고 있다면, 리뷰 용량은 마법처럼 그와 함께 확장되지 않는다. 큐가 먼저 자라고, 사기가 다음이다.

2. 컨텍스트 손실. 인간 저자는 실패한 접근 방식, "명백한" 수정을 배제한 제약, 거의 변경한 파일을 기억한다. AI 저자는 그중 아무것도 diff에 남기지 않는다. 리뷰어는 의도를 처음부터 재구성해야 한다 — 모든 PR에 대해 — 구현 여정이 커밋 메시지에 없기 때문이다.

3. 그럴싸함 편향. AI 출력은 옳아 보인다. 컨벤션을 따르고, 깔끔하게 형식화하며, 예상되는 라이브러리를 임포트한다. 실패 모드는 페이지에서 뛰어오르는 구문 오류가 아니다 — 주의 깊게 읽을 때만 표면화되는 의도와 동작 사이의 미묘한 불일치다. 그 읽기는 느리고, 큐가 깊을 때 인간이 정확히 건너뛰는 읽기다.

이들을 모두 합치면: 더 많은 PR, 각각이 상속받은 컨텍스트를 덜 가지고, 각각이 같은 크기의 인간 저작 diff보다 더 주의 깊은 읽기를 요구한다. 그것이 병목이다.

이를 수정하는 3계층 라우팅​

Codacy, MetaCTO, Moderne 및 FreeCodeCamp 핸드북에서 반복적으로 나타나는 완화책은 같은 형태다: 인간이 대체 불가능한 것만 인간이 보도록 리뷰를 계층화하라.

Guided walkthrough1 of 3
  1. 형식, 린트, 타입 체크, 보안 스캔, 종속성 정책, 시크릿 스캔, 커버리지 게이트. 리뷰어가 배정되기도 전에 실행된다. 리뷰가 냉기 상태에서 시작될 때 인간의 주의 40%를 먹는 지루하고 기계적인 실패를 차단한다. 여기서 변경이 실패하면 아무에게도 도달하지 않는다.

처음 두 계층은 이전에 눈여겨보았을 diff의 대부분을 차지해야 한다. 세 번째 계층은 큐가 되기를 멈추고 결정이 되기 시작한다.

코드베이스 인식 리뷰어, 구체적으로​

일반 AI 리뷰어는 중요한 하나를 놓친다: 당신의 아키텍처. 팀 전반에 걸쳐 결정화되고 있는 패턴은 리뷰어가 소비할 수 있는 기계 판독 가능한 파일로 제도적 지식을 옮기는 것이다.

project-root/
├── AGENTS.md              # entry point — lean, high-signal
├── CLAUDE.md              # symlink → AGENTS.md
├── .claude/
│   ├── settings.json      # read-only guardrails
│   ├── pr-rules/
│   │   ├── common.md      # rules that apply everywhere
│   │   ├── frontend.md    # per-workspace rules
│   │   └── backend.md
│   └── commands/
│       └── review-pr.md   # the review slash command
├── frontend/AGENTS.md     # architecture, patterns, anti-patterns
└── backend/AGENTS.md      # business rules, contracts, test conventions

이 레이아웃에서 두 가지 설계 선택이 하중을 지탱한다:

  • 하나의 거대한 파일이 아닌 서비스별 AGENTS.md. 긴 명령 목록은 모든 항목에서 저하된 준수를 야기한다 — 모델은 200번째 줄을 지나 훑기 시작한다. 각 파일을 주제당 한 문단으로 유지하고, 세부사항은 링크로 연결하라.
  • 규칙은 열망이 아닌 명령형이다. "컨트롤러는 리포지토리를 호출해서는 안 된다"는 테스트 가능하다. "컨트롤러를 얇게 유지하려고 노력하라"는 동전 던지기다.

다음은 PR이 열리기 전에 로컬에서 실행되는 리뷰 명령의 형태다:

로컬 /review-pr 명령 (Claude Code / 코드베이스 인식 리뷰어)

You are reviewing a pull request against the main branch.

STEPS:
1. Fetch main, compute the merge base with the current branch, and read the full diff.
2. Read the PR title/body for stated intent. If intent is unclear, ask before reviewing.
3. Load rules in order: .claude/pr-rules/common.md, then any workspace-specific rule
 files whose path prefix matches the changed files (e.g. frontend/**, backend/**).
4. Read the nearest AGENTS.md for each changed file's service and note conventions.

OUTPUT — use exactly these sections and nothing else:

## Summary
One paragraph. What changed, and why (as stated in the PR).

## Blocking
Real defects, security issues, or rule violations that must be fixed before merge.
Format: `path:line — <problem>. <suggested fix>.`

## Should fix
Quality issues that would normally get pushback in review but aren't blockers.

## Nice to have
Minor improvements. The author may reasonably ignore these.

## Verified
Things you actively checked and confirmed correct. This section exists so the
human reviewer does not re-check them.

## Rule candidate (optional)
If you saw a recurring pattern this review, suggest ONE new rule for a human to
evaluate for pr-rules/. Do not modify any rule file yourself.

CONSTRAINTS:
- No praise, no manufactured concerns. If nothing is wrong in a section, write "None."
- Cite as `file:line`. No prose descriptions of location.
- You never modify rule files. You never approve or merge.

가드레일: 기본적으로 읽기 전용​

main, 시크릿 또는 워크플로우 파일에 쓰기 접근 권한이 있는 리뷰어 에이전트는 대기 중인 공급망 사건이다. 수렴하고 있는 컨벤션은 다음을 하드 차단하는 .claude/settings.json(또는 사용하는 도구의 동등물)이다:

  • 시크릿: .env*, .npmrc, .pgpass, *.pem, **/credentials.json
  • Git 쓰기 작업: push, commit, rebase, reset --hard — fetch, diff, log 허용
  • PR 변조: PR 생성, 병합 또는 승인. 코멘트는 리뷰어의 출력이 자동으로 게시되기를 원하는 경우에만 허용
  • 워크플로우 / 시크릿 변조: gh workflow run, gh secret, gh variable

리뷰어가 읽기만 할 수 있다면, 손상되거나 환각을 일으키는 에이전트의 최악의 경우는 나쁜 리뷰 코멘트다. 그것은 나쁜 병합보다 훨씬 저렴한 실패 모드다.

위험 기반 라우팅 (모든 것이 같은 리뷰를 받을 자격이 있는 것은 아니다)​

팀이 저지르는 다른 실수는 모든 AI 생성 PR을 동일하게 취급하는 것이다. 위험별로 라우팅하라:

위험 계층예시리뷰
낮음문서 전용 변경, CI가 그린으로 잡은 종속성 패치 범프, 생성된 스냅샷 업데이트계층 1 + AI 트리아지; 둘 다 통과하면 자동 병합
중간격리된 모듈의 피처 코드, 서비스 내 리팩터링계층 1 + AI 트리아지 + 집중된 인간 리뷰어 한 명
높음인증, 결제, 마이그레이션, 서비스 경계를 넘는 코드, 프로덕션 데이터를 건드리는 모든 것계층 1 + AI 트리아지 + 지정된 시니어 리뷰어 + 코딩 전 의도 문서

요점은 리뷰를 줄이는 것이 아니다 — 결과를 바꾸는 곳에 인간 시간을 쓰는 것이다.

PR 분해: 변경을 확인 가능하게 유지하기​

10,000줄의 AI 생성 PR은 의미 있는 의미에서 리뷰 가능하지 않다. 고무 도장을 찍거나 앉아 있다. 워크플로우 조치는 분해를 강제하는 것이다:

  • 명시적 분할 정책으로 PR 크기 제한 (많은 팀이 400–900줄을 선택하며, 생성된 마이그레이션은 제외).
  • 정당하게 더 많은 범위가 필요한 피처를 위한 스택 PR — 각 계층은 확인 가능하며, 전체 세트가 함께 착륙한다.
  • AI가 계획하고, 결정론적 도구가 실행한다. 저장소 전반의 변경의 경우, AI를 계획자(어떤 파일, 어떤 레시피)로 취급하고 결정론적 도구를 실행자(레시피를 모든 곳에서 동일하게 적용)로 취급하라. Morgan Stanley의 규모에서의 OpenRewrite 기반 프로그램은 정확히 이 분할을 사용했다.

복리 루프​

반복되는 리뷰 코멘트는 모두 규칙 후보다. 규칙은 pr-rules/에 들어가고, AI 리뷰어는 다음 PR에서 이를 픽업하며, 그 코멘트는 인간이 다시 쓸 필요가 없다. FreeCodeCamp 핸드북은 타임라인을 다음과 같이 프레임화한다:

  • 1주차: 리뷰어가 팀의 반복되는 사소한 것의 5–10%를 잡는다.
  • 4주차: 규칙 세트가 실제 PR 피드백에서 자라면서 20–30%.
  • 3개월+: 규칙 세트가 기록된 팀 취향으로 성숙했다.

복리가 실제 해자다. 어떤 팀이든 오후에 CodeRabbit이나 Greptile을 설치할 수 있다. 100개의 PR을 pr-rules/에 리뷰 코멘트를 다시 공급하는 데 쓴 팀은 그들의 코드베이스를 아는 AI 리뷰어를 가진다. 그렇지 않은 팀은 일반적인 것을 가진다.

유지 관리 규율은 작지만 협상할 수 없다:

  • 모든 캐치: 올바른 pr-rules/ 파일에 한 줄 쓴다.
  • 매월: 오래된 규칙을 정리한다(피처 제거됨, 패턴 폐기됨).
  • 분기별: 각 서비스별 AGENTS.md를 다시 읽고 표류를 정리한다.

여전히 인간이 필요한 것 (그리고 항상 그럴 것)​

3계층 라우팅은 공격적이지만, 바닥이 있다. 인간은 다음에 대해 대체 불가능하게 남는다:

  • 제품 판단. 이 변경이 존재해야 하는가? AI 리뷰어는 규칙에 대해 측정한다. 전략에 대해 측정할 수 없다.
  • 팀 간 결과. 변경이 격리에서는 올바르게 보이지만 다른 팀 서비스와의 계약을 깨뜨린다.
  • 책임. 이것이 손상된 채로 배포될 때 누군가는 사후 분석을 소유해야 한다. AI는 호출될 수 없다.
  • AI 사각지대 리뷰. 같은 데이터로 훈련된 두 AI는 같은 사각지대를 공유한다. 저자와 리뷰어 둘 다 AI라면, 전체 버그 클래스가 체계적으로 보이지 않게 된다. 인간은 정확히 훈련 세트가 다르기 때문에 이를 본다.

건강한 최종 상태는 "AI가 모든 것을 리뷰한다"가 아니다. *"AI가 노이즈를 정리해서 인간이 인간이 필요한 것을 리뷰하도록 한다"*이다.

정직한 프레이밍​

코딩에서 AI 생산성 이득의 대부분은 실제다. 피처 브랜치 처리량 +59%는 신기루가 아니다. 그러나 파이프 상단의 처리량은 하단 밖의 처리량이 아니며, 배포된 코드의 모든 측정 — 메인 브랜치 병합, 사이클 타임, 결함 이스케이프율 — 은 같은 이야기를 말한다: 제약이 옮겨갔고, 워크플로우를 함께 옮기지 않은 팀은 이득이 리뷰 큐로 사라지는 것을 보았다.

2026년에 AI 코딩 에이전트로 이기고 있는 팀은 가장 많은 코드를 생성하는 팀이 아니다. 생성됨에서 병합됨까지 가장 짧고, 저렴하고, 가장 신뢰받는 경로를 가진 팀이다.

퀴즈​

스스로 점검하기

0/5
  1. 한 팀이 Claude Code를 도입한다. 피처 브랜치 처리량이 60% 뛰지만, 메인 브랜치 처리량과 사이클 타임은 거의 움직이지 않는다. 가장 가능성 있는 설명은?
  2. 왜 AI 생성 코드가 같은 크기의 인간 저작 코드에 비해 리뷰하기에 유독 비용이 많이 드는가?
  3. 3계층 라우팅을 설정하고 있다. AI 리뷰어는 어느 계층에 살아야 하며, 그 일은 무엇인가?
  4. FreeCodeCamp 핸드북과 Codacy는 둘 다 워크플로우의 *복리* 효과를 강조한다. 무엇이 복리로 커지는가?
  5. AI 리뷰어에게 브랜치 푸시, PR 생성 및 pr-rules/ 수정 권한이 있다. 이것이 만드는 구체적인 위험은 무엇인가?

플래시카드​

Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 9

관련​

출처 및 추가 자료​