코드 리뷰를 끝내는 법 — Ankit Jain과 Aviator

메타데이터

• 원문 제목: How to Kill the Code Review — Ankit Jain, Aviator
• URL: https://www.youtube.com/watch?v=YgEv7IQzGdM
• 날짜: 2026-08-18
• 채널: aiDotEngineer
• 발표자: Ankit Jain, Aviator 공동 창립자
• 콘텐츠 유형: YouTube 기술 심층 다이제스트
• 주요 주제: AI 코딩 에이전트, 코드 리뷰, 정렬(Alignment), 의미론적 정확성(Semantic Accuracy), 검증(Verification)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코드 리뷰를 없앤다는 것은 사람을 검토 과정에서 제거하는 일이 아니라, 사람이 읽어야 할 대상을 코드 diff에서 의도·아키텍처·검증 증거로 옮기는 일이다.==

• 코드 생산량이 폭증하면서 줄 단위 리뷰는 이미 병목이 되었고, 실제로 많은 변경 사항이 리뷰 없이 병합되고 있다.
• AI가 코드를 만들고 AI가 코드를 리뷰하는 상황에서 사람이 GitHub UI의 diff를 대충 훑는 방식은 잘못된 설정이다.
• 반복되는 코드 리뷰 피드백은 AI 슬롭 레지스트리(AI slop registry, 이하 AI 슬롯 레지스터)로 체계화해 의미론적 정확성을 자동 검증해야 한다.
• 팀 협업에서 코드 리뷰의 가장 중요한 기능은 버그 검출만이 아니라 지식 공유, 멘토링, 아키텍처 피드백, 온보딩을 통한 정렬(alignment)이다.
• 세션에서 발생한 사용자 결정과 의도를 승인 기준(acceptance criteria)으로 바꾸고, AI 슬롯 레지스터와 결합해 테스트 계획(test plan)과 검증 증거를 만든다.

Ankit은 몇 달 전 LinkedIn에 작성한 ‘코드 리뷰를 없애는 방법’ 글에서 5단계 신뢰 모델(five-layer trust model)을 제시했다. 이 모델의 목표는 코드에 신뢰를 층층이 쌓아 줄 단위 검토 없이도 병합할 수 있게 만드는 것이었다. 그는 당시 모델에서 맞힌 부분도 있고 틀린 부분도 있었다고 인정하며, 이번 발표에서는 각 레이어 자체보다 그 논의에서 도출된 개념을 더 깊이 살펴본다.

1. 코드 리뷰가 더 이상 확장되지 않는 이유

코드 작성은 빨라졌지만 리뷰 능력과 리뷰 프로세스는 같은 속도로 확장되지 않아, 병목이 코딩에서 검토로 이동했다.

1.1. 코드 생산량과 리뷰 병목

1. 코드 양이 매일 증가한다

   1. 더 많은 코드가 생산되면서 사람이 모든 변경 사항을 줄 단위로 읽고 따라잡기 어려워졌다.
   2. “언제 줄 단위 코드 읽기를 멈출 것인가?”라는 질문에 대해 Ankit은 이미 사람들이 리뷰를 멈춘 상태라고 말한다. 공식 프로세스가 남아 있어도 실제 검토의 깊이는 낮아졌다는 뜻이다.

2. 코드 churn과 사고가 함께 늘어난다

   1. 발표에서 제시한 수치는 861% code churn이다. 코드가 훨씬 더 많이 생산되고 있다는 지표로 제시됐다.
   2. incident-to-PR 비율도 증가하고 있다. 리뷰를 하고 있어도 사고를 막는 효과가 약해지고 있다는 의미다.
   3. 리뷰의 중앙값 소요 시간(median review time)은 계속 늘고 있다.

3. 병목이 코딩에서 리뷰로 옮겨갔다

   1. AI로 코딩 자체가 사실상 해결된 것처럼 보이자 모든 작업이 리뷰 단계에서 멈춘다.
   2. 팀은 과거보다 리뷰를 기다리는 데 4배(4x) 더 많은 시간을 쓰고 있다.
   3. 그 결과 오늘날 변경 사항의 30% 이상이 리뷰를 전혀 거치지 않고 병합된다.

1.2. AI 리뷰를 GitHub UI에 가둬두는 문제

1. AI가 작성하고 AI가 리뷰하는 반복 루프

   1. 대부분의 개발자가 어떤 형태로든 AI 리뷰를 사용하고 있다.
   2. GitHub를 열면 두세 개의 AI 코딩 에이전트가 코드를 리뷰하고, 리뷰 결과가 사용자 또는 다른 에이전트에게 돌아가며, 수정과 재검토가 반복된다.
   3. 이런 루프에서 사람은 어디에 있는지 불분명해진다. 사람이 실제 결정을 내리기보다 “AI가 검토했으니 대부분 찾았겠지”라고 생각하며 결과를 훑고 병합하기 쉽다.

2. 사람이 읽지 않는 AI 리뷰는 잘못 구성된 시스템이다

   1. AI가 리뷰하고 아무도 읽지 않는다면 사람의 역할을 없앤 것이 아니라, 검토 시스템을 잘못 설계한 것이다.
   2. 사람이 계속 코드 diff를 대충 확인하는 방식은 AI 시대의 코드 생산 속도와 맞지 않는다.
   3. 사람은 자동화가 놓칠 수 있는 의도, 맥락, 설계 선택, 팀의 합의를 검토하는 쪽으로 이동해야 한다.

2. 코드 리뷰의 본질은 버그 검출을 넘어선다

코드 리뷰는 비교적 최근에 정착한 절차이며, 팀 개발에서 가장 중요한 산출물은 줄 단위 피드백이 아니라 정렬이다.

2.1. 코드 리뷰의 역사와 전통적 목적

1. 코드 리뷰는 오래된 관행이 아니다

   1. Ankit은 공식적인 코드 리뷰가 정착한 시점을 대략 15~20년 전으로 본다.
   2. Google은 2006년 사내에서 Mondrian을 출시했고, 이를 계기로 공식 코드 리뷰를 하나의 개발 관행으로 만들었다.
   3. 반면 초기 Windows 버전은 코드 리뷰 없이 만들어졌다는 사례를 들어, 리뷰가 소프트웨어 개발의 영원한 전제는 아니었다고 환기한다.

2. 전통적으로 코드 리뷰는 여러 품질 문제를 다룬다

   1. 버그를 잡는다.
   2. 팀의 코딩 관례(convention)를 이해하고 일관성을 맞춘다.
   3. 보안 문제를 식별한다.
   4. 그러나 이것만으로 코드 리뷰의 전체 가치를 설명할 수 없다.

2.2. 리뷰의 숨은 기능: alignment

1. 정렬은 5단계 신뢰 모델에서 빠졌던 요소다

   1. Ankit이 몇 달 전 제시한 모델은 코드에 신뢰를 쌓는 과정을 다뤘지만, 이번 논의에서 정렬(alignment)이 빠져 있었다는 점을 발견했다.
   2. 정렬은 팀 구성원이 무엇을 만들고 왜 그렇게 만들었는지에 대해 같은 이해를 갖는 상태다.

2. 팀의 코드 리뷰는 지식 공유 장치다

   1. 지식 공유(knowledge sharing)는 리뷰의 핵심 역할이다.
   2. 멘토링(mentorship)을 통해 주니어 엔지니어가 더 나은 판단을 배우게 한다.
   3. 아키텍처 피드백(architectural feedback), 온보딩(onboarding), 협업(collaboration)을 가능하게 한다.
   4. 이 기능은 단순히 버그를 찾는 자동화 도구로 대체할 수 없다.

3. 대상은 팀 개발자다

   1. 혼자 하는 프로젝트나 vibe coding으로 완전히 개인적인 작업을 한다면 이 논의의 일부가 적용되지 않을 수 있다.
   2. 그러나 대부분의 개발자는 팀에서 협업한다.
   3. 아무도 코드를 보지 않는 완전한 dark factory나 orchestrator에서 일하는 것이 아니라면, 팀은 지식 공유와 정렬을 유지해야 한다.
   4. Ankit은 정렬이 릴리스(release)에서 가장 중요한 측면이라고 강조한다.

4. 자동화할 수 있는 것과 지켜야 할 것을 분리한다

   1. 의미론적 정확성(semantic accuracy)은 더 나은 도구로 높일 수 있다.
   2. 정렬은 자동화 과정에서 사라지면 안 되며 반드시 살아남아야 한다.
   3. 따라서 더 나은 모델은 코드 한 줄씩 읽는 데만 의존하지 않고, 사람의 의도와 팀의 합의를 보존해야 한다.

3. Spec-driven 개발의 장점과 한계

명세를 먼저 쓰고 에이전트에게 구현을 맡기는 방식은 유용하지만, 피드백 루프와 LLM의 비결정성을 다루지 못하면 일상적인 개발에 부족하다.

3.1. Spec-driven 개발은 새로운 waterfall이 될 수 있다

1. 기본 흐름

   1. 모든 세부 사항을 포함한 spec을 작성한다.
   2. spec을 에이전트에 전달한다.
   3. 에이전트가 코드를 생성한다.
   4. 결과를 검증한다.

2. 1970년대 waterfall과 같은 구조

   1. 요구사항(requirements)을 정한다.
   2. 명세(specification)를 작성한다.
   3. 구현(implementation)한다.
   4. 마지막에 검증(verification)한다.
   5. 이 흐름에는 구현 중 발견된 사실이 앞 단계로 돌아가는 피드백 루프가 없다.

3. 명세가 완벽할 수 없다는 현실

   1. 명세는 다른 모든 사항을 파악하기 전에 작성된다.
   2. 실제 구현을 진행해야만 드러나는 문제와 선택지가 있다.
   3. spec-driven 방식에서는 이미 spec이 끝났다고 간주하기 때문에 구현 중 발견한 문제를 spec에 되돌려 반영하기 어렵다.

3.2. LLM의 비결정성이 만드는 차이

1. 에이전트와의 상호작용은 필수적인 피드백 루프다

   1. Cloud Code, Codex, Cursor 등 어떤 도구를 쓰든 사람은 코딩 세션에서 에이전트와 상호작용한다.
   2. 사용자가 에이전트에게 계속 질문하고 수정 지시를 내리는 이유는 spec에 명확하지 않은 부분이 남아 있기 때문이다.
   3. 구현하면서 더 많은 이슈가 발견되므로, 사람과 에이전트 사이의 대화 자체가 의도를 구체화한다.

2. LLM은 결정론적이지 않다

   1. spec이 완성되면 코드가 결정론적으로 나올 것이라고 기대하지만 LLM은 스스로 결정을 내린다.
   2. 같은 명세라도 구현 과정에서 다른 판단과 결과가 나올 수 있다.
   3. 따라서 spec-driven 개발은 좋은 방법론이지만 일상적인 소프트웨어 개발의 모든 상황을 포괄하지 못한다.

3. 앞으로 가져갈 핵심은 intent다

   1. spec-driven 개발에서 버릴 것은 피드백 루프가 없는 순차적 구조다.
   2. 가져갈 것은 무엇을 만들려 했는지에 대한 intent를 명시적으로 보존하는 일이다.

4. 의도는 문서가 아니라 개발 세션 전체에 흩어져 있다

실제 구현 결정을 담고 있는 것은 최종 spec 하나가 아니라 Jira, PRD, 프롬프트, 그리고 에이전트와 주고받은 대화다.

4.1. intent가 존재하는 여러 위치

1. Jira 티켓

   1. Jira 티켓은 무엇을 하려는지, 즉 목표(goal)를 표현한다.
   2. 하지만 목표만으로는 구현 과정에서 필요한 모든 결정을 담을 수 없다.

2. PRD(Product Requirements Document)

   1. PRD에는 더 구체적인 세부사항과 계획이 들어간다.
   2. 제품 요구사항을 정리하는 중요한 의도 저장소이지만 실제 구현 중의 모든 판단을 포함하지는 않는다.

3. 오늘의 프롬프트

   1. 실제 결정은 프롬프트와 에이전트 세션에서 이뤄진다.
   2. 처음에는 Jira 티켓을 보고 시작해도, 에이전트와 왕복 대화를 하며 사용자 결정이 계속 추가된다.
   3. 지금의 개발 프로세스는 변경 사항을 만들고 PR을 생성한 뒤, 그 프롬프트와 대화를 버린다.
   4. 그 결과 가장 중요한 의도와 의사결정의 맥락이 최종 코드와 함께 보존되지 않는다.

4.2. 세션을 기록해야 하는 이유

1. 사용자 결정이 협업의 핵심 산출물이다

   1. 단순한 작업이라도 에이전트는 질문을 멈추고 사용자에게 결정을 요구한다.
   2. 어떤 방향을 선택했는지, 무엇을 시도했고 무엇을 거부했는지가 협업의 실제 내용이다.
   3. 이 결정을 저장해야 리뷰가 단순한 문법 검사가 아니라 의도 확인이 된다.

2. 의도는 교육과 성장에도 연결된다

   1. 세션에서 나온 결정이 리뷰를 더 가치 있게 만든다.
   2. 주니어 엔지니어에게 시간이 지나며 더 나은 판단을 하는 법을 가르치는 자료가 된다.
   3. 이러한 판단 능력이 오늘날 소프트웨어 엔지니어를 가치 있게 만드는 요소다.

5. 의미론적 정확성을 AI 슬롯 레지스터로 자동화한다

정렬만으로는 충분하지 않다. 코드에 버그가 남거나 반복되는 품질 문제가 생기지 않도록, 사람이 반복해서 남긴 리뷰 피드백을 실행 가능한 규칙으로 전환해야 한다.

5.1. AI 리뷰의 한계와 semantic accuracy

1. “코드에 버그가 있으면 누가 찾는가?”라는 반론

   1. 정렬의 중요성을 인정해도 코드에 버그가 생길 수 있다.
   2. LLM은 의미론적 정확성을 항상 잘 보장하지 못한다.
   3. AI 에이전트 리뷰어 역시 완벽하지 않다.

2. 반복되는 리뷰 피드백을 데이터로 본다

   1. 사람이 수동으로 코드를 리뷰할 때 같은 문제를 계속 반복해서 발견한다.
   2. 동일한 문제에 매번 새로운 리뷰 코멘트를 작성하는 것은 사람의 시간을 낭비한다.
   3. 반복되는 개념을 포착해 체계화하면 리뷰 피드백을 자동으로 식별할 수 있다.

5.2. AI slop registry / AI 슬롯 레지스터의 작동 방식

1. 반복 문제를 레지스트리로 codify한다

   1. 리뷰에서 반복되는 문제를 AI 슬롯 레지스터(AI slop registry)에 기록한다.
   2. 레지스터는 어떤 패턴이 잘못된 구현인지, 어떤 관례를 지켜야 하는지, 어떤 의미론적 오류를 찾아야 하는지를 담는다.
   3. 한 번 체계화된 항목은 다음 PR부터 자동 식별 대상이 된다.

2. 리뷰 경험이 시스템을 학습시킨다

   1. 몇 차례 같은 패턴을 등록하면 시간이 지나며 학습하는 시스템이 만들어진다.
   2. 이는 기존 표준 LLM 위에 사람이 제공한 리뷰 경험을 추가로 학습시키는 것과 비슷하다.
   3. 인간이 반복해서 제공한 피드백이 AI 기반 리뷰 시스템의 더 나은 결과로 축적된다.

3. 반복 코멘트는 guardrail이 된다

   1. 반복되는 모든 리뷰 코멘트는 다시 수동으로 검토하지 않아도 되는 안전장치(guardrail)로 바뀐다.
   2. 자동화는 semantic accuracy를 담당하고, 사람은 정렬과 설계 결정을 담당한다.

6. 정렬과 의미론적 정확성을 하나의 검증 루프로 결합한다

리뷰의 두 반쪽은 정렬과 의미론적 정확성이다. 세션의 의도를 기준으로 테스트 계획을 만들고, 레지스트리와 결정론적 검증을 결합하면 코드 diff 대신 동작 증거를 검토할 수 있다.

6.1. 통합 파이프라인

1. 세션에서 사용자 응답을 수집한다

   1. 에이전트와의 대화에서 사용자 응답과 결정을 추출한다.
   2. 이 응답이 구현이 만족해야 할 승인 기준(acceptance criteria)의 원천이 된다.

2. 승인 기준과 AI 슬롯 레지스터를 결합한다

   1. acceptance criteria는 사용자 의도와 기능 요구사항을 표현한다.
   2. AI 슬롯 레지스터는 반복적인 의미론적 오류와 품질 규칙을 표현한다.
   3. 두 가지를 계속 관리하고 결합하면 테스트 계획(test plan)이 생성된다.

3. 검증 시스템이 테스트 계획을 실행한다

   1. 시스템은 미리보기(preview) 환경을 띄운다.
   2. 테스트 계획을 바탕으로 처음부터 끝까지 실제 동작을 확인한다.
   3. 코드가 보기에는 맞아도 실제로 작동하는지를 검증한다.

6.2. 바뀌는 review surface

1. 검토 대상이 코드가 아니라 증거가 된다

   1. 리뷰어는 코드를 한 줄씩 읽는 대신 의도가 무엇이었는지 확인한다.
   2. 의도에 정의된 기능을 실제로 구현했는지 확인한다.
   3. 실제 동작이 acceptance criteria의 요구사항을 충족했는지 검증 결과를 본다.

2. 사람의 설계 논의는 사라지지 않는다

   1. 아키텍처 결정과 논쟁은 여전히 필요하다.
   2. 다만 논의의 표면이 코드 줄 단위에서 한 단계 위인 아키텍처와 의도로 이동한다.
   3. 데이터 모델을 어떻게 만들었는지, 서비스들이 서로 어떻게 상호작용하는지 등을 논의한다.
   4. 협업에 중요한 설계 판단은 사람이 직접 확인하고, 실행 여부는 검증 시스템이 증거로 보완한다.

7. 사용자 결정에서 실시간 테스트 계획으로

사람은 테스트 계획의 거버넌스와 의도를 검토하고, LLM은 계획의 생성·유지와 반복 검증을 보조한다.

7.1. acceptance criteria와 invariant

1. 세션의 결정이 acceptance criteria가 된다

   1. 에이전트가 질문을 던지고 사용자가 선택한 답은 구현 의도를 드러낸다.
   2. 이 결정들을 acceptance criteria로 변환하면 “무엇이 완료인가?”를 명확히 표현할 수 있다.
   3. LLM은 세션의 사용자 결정을 구조화된 기준으로 바꾸는 데 활용할 수 있다.

2. 테스트 계획을 생성한다

   1. 사용자 결정에서 acceptance criteria를 만들고, AI 슬롯 레지스터의 반복 규칙을 함께 적용한다.
   2. 기준(criteria)과 불변식(invariant)이 테스트 계획을 구성한다.
   3. 테스트 계획 생성은 늘 고통스러운 작업이므로 LLM을 활용할 가치가 크다.

3. 새 기능마다 테스트를 수동 유지하지 않는다

   1. 검증 시스템은 테스트 계획을 받아 preview에서 실행한다.
   2. 새 기능을 만들 때 모든 테스트를 사람이 별도로 유지하는 대신 테스트를 실시간으로 생성할 수 있다.
   3. 테스트 계획의 생성과 유지라는 번거로운 작업을 LLM이 보조한다.

7.2. 사람이 검토할 것은 test plan이다

1. human-in-the-loop의 역할

   1. 사람의 역할은 거버넌스(governance)와 리뷰다.
   2. 사람은 구현 코드가 아니라 테스트 계획이 의도와 맞는지 검토한다.
   3. 리뷰어가 확인해야 하는 것은 어떤 행위를 허용하고 어떤 동작을 막을 것인지다.

2. TDD에서 BDD 쪽으로 이동한다

   1. 테스트 주도 개발(Test-Driven Development, TDD)이 등장한 지 20년 이상 지났다.
   2. 이 구조는 전통적인 TDD보다 행동 주도 개발(Behavior-Driven Development, BDD)에 더 가깝다.
   3. 테스트 계획이 자연어로 작성되므로 제품 관리자와 디자이너도 함께 읽고 참여할 수 있다.
   4. 모든 참여자가 영어로 적힌 행동 기준을 공유하고 논의할 수 있다.

3. 결정론적 검증으로 결과를 판정한다

   1. 테스트 기준이 충족됐는지를 결정론적 검증(deterministic verification)이 확인한다.
   2. LLM의 추론에 모든 판정을 맡기지 않고, 확인 가능한 조건은 결정론적 시스템으로 처리한다.

8. 결정론적 시스템과 LLM의 균형

완벽하게 결정론적인 시스템을 만들려 하지 말고, 결정론적으로 확인할 수 있는 부분과 LLM이 필요한 부분을 나눠야 한다.

8.1. “가능한 곳에서는 결정론적, 필요한 곳에서는 LLM”

1. 완벽함이 목표가 아니다

   1. 시스템은 모든 것을 완벽하게 처리하도록 설계될 필요가 없다.
   2. 결정론적으로 할 수 있는 부분은 결정론적으로 처리한다.
   3. 결정론적으로 표현할 수 없는 부분은 LLM을 사용한다.

2. LLM은 fallback이다

   1. 모든 시스템을 100% 결정론적 시스템으로 만들 수는 없다.
   2. 결정론적 검증이 실패하거나 명확한 규칙으로 표현할 수 없는 경우 LLM을 fallback으로 사용한다.
   3. 이 방식은 결정론의 신뢰성과 LLM의 유연성을 결합한다.

8.2. 웹 애플리케이션의 결제 폼 사례

1. 행동 변화에 대한 테스트 계획

   1. 웹 애플리케이션에 새 결제 폼(payment form)을 도입한다고 가정한다.
   2. 시스템은 어떤 행동이 바뀌어야 하는지에 대한 테스트 계획을 만든다.
   3. 검증 질문은 결제 시스템이 어떻게 바뀌었는지, 기준에 맞는 동작이 구현됐는지를 확인하는 것이다.

2. 에이전트가 실제 앱을 탐색한다

   1. AI 에이전트가 애플리케이션을 브라우징한다.
   2. 폼을 직접 채운다.
   3. 결과 화면을 스크린샷으로 캡처해 증거를 만든다.
   4. 데이터베이스 스냅샷도 함께 수집한다.

3. 증거 기반 검증

   1. 스크린샷과 데이터베이스 스냅샷을 사용해 acceptance criteria가 충족됐는지 판정한다.
   2. 스크린샷 테스트와 자막에서 “sand flying”으로 들리는 에이전트 기반 탐색·실행 테스트는 LLM 에이전트가 수행할 수 있다.
   3. 리뷰어는 코드 diff가 아니라 실제 화면과 데이터 상태라는 더 단단한 증거를 보고 동작에 대한 신뢰를 쌓는다.

9. 세션에서 의도와 증거를 추출하는 원칙

테스트 계획은 완성된 코드에서 역으로 추측하지 말고 개발 세션에서 직접 만들어야 한다. 같은 에이전트가 구현과 검증 계획을 모두 만들어서는 안 된다.

9.1. 리뷰어는 intent와 decision을 검토한다

1. 검토 대상의 구체적 변화

   1. 리뷰어는 diff가 아니라 intent를 검토한다.
   2. 무엇을 만들기로 했는지 확인한다.
   3. 무엇을 시도했고 무엇을 거부했는지 확인한다.
   4. 세션에서 나온 이러한 결정을 모두 기록한다.

2. 세션에서 추출하는 것이 핵심이다

   1. 의도와 테스트 계획을 코드에서 추출하면 이미 구현된 결과를 정당화하는 방향으로 흐를 수 있다.
   2. Ankit은 전날 Dex가 이야기한 문제를 언급한다. 코드를 만든 동일한 에이전트가 테스트 계획까지 만들면 실제 문제를 잡아낼 계획을 만들 가능성이 낮다.
   3. 구현 에이전트가 만든 코드만 보고 검증 계획을 만들면 자기 결과에 편향된 검증이 된다.
   4. 따라서 세션의 사용자 질문·응답·거절·선택을 별도로 사용해 테스트 계획을 만들어야 한다.

3. 아키텍처 논의는 한 단계 위에서 진행한다

   1. 데이터 모델의 구성 방식을 논의한다.
   2. 서비스 사이의 상호작용을 논의한다.
   3. 줄 단위 검토보다 협업에 훨씬 중요한 아키텍처 대화를 나눈다.
   4. 마지막으로 검증 과정에서 수집된 모든 증거를 확인한다.

10. 실천 과제와 도입 비용

AI 슬롯 레지스터는 한 번에 완성되는 기능이 아니라, 과거 리뷰를 채굴해 반복 규칙을 쌓아가는 운영 체계다.

10.1. 마지막 1,000개 리뷰 코멘트 채굴

1. 구체적인 homework

   1. 최근 1,000개 코드 리뷰 코멘트를 가져온다.
   2. 그중 반복되는 항목을 찾아 AI 슬롯 레지스터를 만든다.
   3. 어떤 코멘트가 여러 PR에서 반복되는지 분류한다.

2. 반복 규칙은 PR마다 누적된다

   1. 코드 리뷰 코멘트의 상당수는 계속 반복해서 남기는 내용이다.
   2. 이 반복은 merge PR이 누적될 때마다 복리처럼 쌓인다.
   3. 어떤 항목을 레지스터로 등록하면 이후에는 같은 코멘트를 매번 다시 작성할 필요가 없다.

3. 사람의 협업을 보존하면서 품질을 codify한다

   1. 반복되는 베스트 프랙티스를 코드화한다.
   2. semantic accuracy를 높인다.
   3. 동시에 리뷰의 협업 기능과 정렬을 잃지 않는다.

10.2. J-curve와 초기 고통

1. 처음에는 비용이 발생한다

   1. 도입 효과는 J-curve를 따른다.
   2. 초기 레지스트리를 만드는 데 시간이 들고, 실제 고통은 분명히 존재한다.
   3. 처음부터 자동화 효과가 즉시 나타나는 것은 아니다.

2. 반복 축적이 비용을 상쇄한다

   1. 초기 투자 뒤에는 등록된 규칙이 반복 리뷰를 대신한다.
   2. 누적 PR이 많아질수록 같은 코멘트를 다시 쓰지 않는 효과가 커진다.
   3. Ankit은 이 문제를 해결하기 위한 자사 제품을 사용해 보라고 권한다.

11. Aviator Verify와 최종 메시지

Aviator는 정렬과 의미론적 정확성을 함께 다루는 검증 시스템 Verify를 파일럿 중이며, 초기 설계 파트너를 모집하고 있다.

11.1. 제품이 결합하려는 두 축

1. Verify 파일럿

   1. 새 제품의 이름은 Verify다.
   2. 몇몇 회사와 함께 새로운 검증 시스템을 파일럿하고 있다.
   3. 초기 설계 파트너(early design partners)로 참여해 달라고 요청한다.

2. 검증 시스템의 구성

   1. 정렬 측면을 보존한다.
   2. 도구와 기능으로 semantic accuracy를 감지한다.
   3. AI 슬롯 레지스터를 사용해 반복적인 의미 오류와 품질 문제를 포착한다.

11.2. 결론

1. 코드 리뷰는 코드만 보는 일이 아니다

   1. 코드 리뷰의 본질은 줄 단위 diff의 승인 여부가 아니라 팀의 정렬을 확보하는 일이다.
   2. 도구는 semantic accuracy를 자동화하고, 테스트 계획과 증거를 생성할 수 있다.
   3. 사람은 의도, 사용자 결정, 아키텍처, 거버넌스, 협업을 검토해야 한다.

2. 기억해야 할 한 문장

   1. “코드 리뷰는 코드 리뷰에 관한 것이 아니라, 정렬(alignment)을 얻는 일이다.”
   2. 이를 위해 개발 세션을 보존하고, acceptance criteria를 만들며, AI 슬롯 레지스터로 반복 문제를 자동화해야 한다.

주요 발언 모음

“코드 리뷰를 없애는 방법을 이야기해 보겠습니다. 모두가 좋아하는 주제입니다.”

“AI가 리뷰하고 아무도 읽지 않는다면, 우리가 잘못된 것을 구성한 것입니다.”

“코드 리뷰는 버그를 잡는 일만이 아니라 정렬에 관한 일이기도 합니다.”

“의도는 명세에만 존재하지 않습니다. Jira 티켓, PRD, 그리고 오늘날에는 무엇보다 프롬프트 안에 존재합니다.”

“반복되는 모든 코멘트는 다시 리뷰할 필요가 없는 안전장치가 됩니다.”

“가능한 곳에서는 결정론적으로, 필요한 곳에서는 LLM으로 처리해야 합니다.”

“리뷰어는 diff가 아니라 intent를 검토합니다.”

“코드 리뷰는 코드 리뷰에 관한 것이 아니라 정렬을 얻는 일입니다.”

핵심 데이터 & 수치

• 861% code churn: 코드 생산량이 크게 증가했다는 맥락에서 제시된 발표 수치다.
• 4배(4x): 코드 작성보다 리뷰를 기다리는 데 쓰는 시간이 과거보다 네 배 늘었다는 주장이다.
• 30% 이상: 리뷰 없이 병합되는 변경 사항의 비율이다.
• 2006년: Google이 Mondrian을 사내에 출시하고 공식 코드 리뷰를 정착시킨 시점으로 언급됐다.
• 15~20년: 공식 코드 리뷰 관행이 정착한 대략적인 역사적 기간이다.
• 20년 이상: 테스트 주도 개발(TDD)이 등장한 뒤 지난 시간으로 언급됐다.
• 1,000개: AI 슬롯 레지스터를 만들기 위해 채굴해 볼 최근 코드 리뷰 코멘트 수다.
• J-curve: 레지스트리 도입 초기에는 비용과 고통이 커지지만, 반복 규칙이 누적되며 투자 효과가 커지는 양상이다.

결론 및 시사점

1. 줄 단위 코드 리뷰는 코드 생산량과 AI 에이전트의 속도를 감당하지 못하므로, 리뷰 표면을 바꿔야 한다.
2. 사람의 검토를 없애는 것이 아니라 사람이 검토할 대상을 diff에서 intent, architecture, evidence로 이동시켜야 한다.
3. Jira 티켓과 PRD만으로는 실제 구현 의도를 보존할 수 없으며, 에이전트 세션의 프롬프트와 사용자 결정을 저장해야 한다.
4. 세션에서 나온 결정은 acceptance criteria로 변환하고 AI 슬롯 레지스터와 연결해 테스트 계획을 만든다.
5. 결정론적 검증은 명확한 조건을 판정하고, LLM은 결정론으로 표현할 수 없는 부분의 fallback이 되어야 한다.
6. 테스트 계획은 자연어로 공유할 수 있으므로 개발자뿐 아니라 제품 관리자와 디자이너도 검토에 참여할 수 있다.
7. 최근 1,000개 리뷰 코멘트를 채굴하면 팀의 반복 피드백을 자동화할 초기 레지스트리를 만들 수 있다.
8. 초기 레지스트리 구축에는 비용이 들지만 규칙이 누적될수록 같은 코멘트를 반복하지 않는 효과가 커진다.
9. 자동화가 semantic accuracy를 담당하더라도 지식 공유, 멘토링, 아키텍처 논의, 온보딩이라는 alignment 기능은 사람과 팀이 유지해야 한다.
10. 코드 리뷰를 끝내는 가장 현실적인 정의는 리뷰를 제거하는 것이 아니라, 더 높은 수준의 의도와 증거를 검토하는 것이다.

핵심 요약 (20줄)

코드 생산량은 매일 늘어나지만 사람이 줄 단위로 모든 변경을 읽는 능력은 늘지 않는다. 발표에서 제시된 861% code churn은 리뷰 부담이 이미 기존 프로세스의 한계를 넘었다는 신호다. 리뷰 대기 시간은 과거보다 네 배 늘었고 변경 사항의 30% 이상은 리뷰 없이 병합된다. AI가 코드를 작성하고 AI가 리뷰하는데 사람이 GitHub diff를 대충 훑는 구조는 잘못된 검토 설계다. 코드 리뷰의 가치는 버그와 보안 문제를 찾는 데서 끝나지 않고 팀의 정렬을 만드는 데 있다. 정렬은 지식 공유, 멘토링, 아키텍처 피드백, 온보딩, 협업을 통해 릴리스의 품질을 지탱한다. spec-driven 개발은 요구사항과 명세 뒤에 구현과 검증을 배치해 waterfall의 피드백 부재를 되풀이할 수 있다. LLM은 결정론적이지 않으므로 실제 구현 중 발견한 문제와 사용자 결정을 명세에 되돌려야 한다. 구현 의도는 Jira 티켓과 PRD뿐 아니라 에이전트와 주고받은 프롬프트와 세션에 들어 있다. PR을 만든 뒤 프롬프트와 대화를 버리면 가장 중요한 설계 맥락과 사용자 결정이 사라진다. 반복되는 리뷰 코멘트는 AI 슬롭 레지스트리 또는 AI 슬롯 레지스터로 체계화할 수 있다. 레지스터에 쌓인 반복 규칙은 다음 PR에서 자동으로 식별되는 의미론적 안전장치가 된다. 세션의 사용자 응답은 acceptance criteria가 되고 AI 슬롯 레지스터와 결합해 테스트 계획을 만든다. 검증 시스템은 preview를 띄우고 테스트 계획을 실행해 코드가 실제로 동작하는지 확인한다. 사람은 코드가 아니라 의도, 아키텍처 결정, 테스트 계획, 검증 증거를 검토해야 한다. 새 결제 폼은 에이전트가 실제 앱을 탐색하고 폼을 채우며 스크린샷과 데이터베이스 스냅샷으로 검증할 수 있다. 가능한 조건은 결정론적으로 판정하고 표현하기 어려운 부분은 LLM을 fallback으로 사용해야 한다. 최근 1,000개 리뷰 코멘트를 채굴하면 반복되는 팀 베스트 프랙티스를 레지스터로 만들 수 있다. 레지스트리 구축 초기에는 J-curve의 고통이 있지만 반복 코멘트를 없애는 효과가 누적된다. 코드 리뷰를 끝내는 방법은 사람을 제거하는 것이 아니라 검토 대상을 diff에서 alignment와 evidence로 바꾸는 것이다.