코드 리뷰를 없애는 방법: diff 대신 의도를 검증하라

URL: https://www.youtube.com/watch?v=ymj8Ha0oBtU 날짜: 2026-08-19 채널: Tech Bridge 원문 제목: [한글자막] 코드 리뷰를 완전히 없애는 방법: diff 대신 의도를 검증하세요 발표자: Ankit, Aviator 공동 창업자

---

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

==AI가 코드를 만들고 AI가 코드를 검토하는 시대에는 줄 단위 diff 검토를 계속할 이유가 없다. 사람이 맡아야 할 일은 코드의 모든 줄을 읽는 것이 아니라, 무엇을 만들기로 합의했는지(alignment)를 확인하고 그 의도가 실제 동작으로 구현됐다는 증거를 검토하는 것이다.==

• 코드 생산량과 변경량은 사람이 모든 diff를 읽을 수 있는 속도를 이미 넘어섰다.
• 코드 리뷰의 본래 목적은 버그 탐지뿐 아니라 지식 공유, 멘토링, 아키텍처 피드백, 온보딩, 협업을 포함한 팀의 정렬(alignment)이다.
• 정렬은 Jira 티켓, PRD, 특히 에이전트와 주고받은 프롬프트·결정에서 추출하고, 의미적 정확성(semantic accuracy)은 반복되는 리뷰 지적을 AI slop registry와 불변 조건(invariant)으로 체계화할 수 있다.
• 사람은 코드가 아니라 의도, 수용 기준(acceptance criteria), 아키텍처 결정, 검증 증거를 검토하고, 결정론적으로 검증할 수 없는 부분에만 LLM을 보조 수단으로 사용한다.

코드 리뷰를 폐지한다는 말은 협업과 거버넌스를 폐지한다는 뜻이 아니다. 검토 대상을 줄 단위 구현에서 의도와 행동의 일치 여부로 옮긴다는 뜻이다. 세션에서 발생한 질문과 선택을 수용 기준으로 바꾸고, 수용 기준과 반복 지적 레지스트리로 실시간 테스트 계획을 만든 뒤, 프리뷰 환경에서 동작을 검증하면 사람은 훨씬 더 작은 표면에서 더 중요한 판단을 내릴 수 있다.

1. 줄 단위 코드 리뷰가 이미 한계에 도달한 이유

코드 작성 속도를 높이는 데 성공했지만, 그 결과가 리뷰 병목으로 이동했다. 모든 변경을 사람이 읽는 방식은 생산량 증가를 흡수하지 못한다.

1.1. 코드 생산량과 리뷰 부하의 불균형

1. 변경량이 매일 증가한다

   1. 코드 churn의 폭증: 발표자는 코드 churn이 861%에 이르렀다고 제시한다. 정확한 수치의 산정 방식과 무관하게, 핵심은 과거보다 훨씬 많은 코드가 빠르게 생성·수정되고 있다는 점이다.
   2. 사고와 PR의 비율 악화: PR 수에 비해 사고(incident)가 늘고 있다. 리뷰를 하고 있다는 사실만으로 리뷰가 효과적이라는 보장이 사라졌다.

2. 병목이 코딩에서 리뷰로 이동했다

   1. 리뷰 시간 증가: 리뷰에 걸리는 중간 시간(median time)이 계속 길어지고 있으며, 팀은 코드를 작성하는 데 걸리던 시간의 네 배를 리뷰 대기와 처리에 쓰는 상황을 맞고 있다.
   2. 검토 우회의 정상화: 변경의 30% 이상이 아무 리뷰 없이 병합되고 있다. 줄 단위 리뷰를 유지하려는 규칙이 실제 운영에서는 우회되고 있다는 뜻이다.

1.2. AI가 작성하고 AI가 검토하는 UI의 부조리

1. 사람이 형식적인 중계자가 된다

   1. AI 코딩 에이전트가 코드를 만들고, 또 다른 AI 리뷰어가 GitHub에서 코드를 검토한다.
   2. 리뷰 의견은 다시 사용자나 에이전트에게 돌아가고, 에이전트가 수정한 뒤 또 검토하는 왕복이 반복된다.

2. 검토의 실질이 사라진다

   1. 사람은 AI가 대부분의 문제를 찾았을 것이라고 가정하고 diff를 훑어본 다음 병합한다.
   2. AI가 코드를 쓰고 AI가 코드를 검토하는데도 사람이 GitHub UI에서 줄을 읽는다면, 사람의 역할을 올바르게 구성하지 못한 것이다.
   3. AI 리뷰 결과가 인간의 판단을 대체하지 못한다면, 필요한 것은 더 빠른 diff 읽기가 아니라 사람이 확인해야 할 검토 표면 자체의 재설계다.

2. 코드 리뷰의 진짜 목적은 정렬(alignment)이다

코드 리뷰는 버그를 잡는 장치로만 정의할 수 없다. 팀이 같은 문제를 같은 방식으로 이해하고 있는지 확인하는 협업 장치이기도 하다.

2.1. 리뷰가 제공해 온 다섯 가지 팀 기능

1. 의미적 정확성(semantic accuracy)

   1. 코드가 올바르게 동작하는지, 버그가 없는지 확인한다.
   2. 팀의 코딩 관례와 보안 문제를 발견한다.

2. 조직적 정렬과 학습

   1. 지식 공유와 멘토링을 통해 주니어 엔지니어가 더 나은 판단을 배우게 한다.
   2. 아키텍처 피드백을 주고받으며 데이터 모델과 서비스 간 경계를 함께 다듬는다.

3. 협업 기반 형성

   1. 새 구성원이 시스템과 팀의 판단 기준을 익히는 온보딩 통로가 된다.
   2. 팀 구성원이 구현 선택의 배경을 공유하고, 릴리스 전에 무엇을 만들기로 합의했는지 확인하게 한다.

2.2. 자동화할 부분과 반드시 보존할 부분

1. 더 좋은 도구로 자동화할 수 있는 영역

   1. 반복되는 버그·관례·보안 지적은 규칙과 AI 검증으로 체계화할 수 있다.
   2. 테스트 계획의 초안 작성과 수용 기준의 구조화는 LLM에 맡길 수 있다.

2. 사람이 보존해야 하는 정렬

   1. 무엇을 만들지, 어떤 선택을 하고 어떤 선택을 버렸는지에 대한 합의는 단순한 코드 패턴으로 복원하기 어렵다.
   2. 개인 프로젝트나 완전히 자동화된 에이전트 공장에는 적용 범위가 다를 수 있지만, 여러 사람이 함께 일하는 팀에서는 협업과 지식 공유가 사라져서는 안 된다.
   3. 따라서 의미적 정확성은 도구가 담당하더라도 정렬은 살아남아야 하며, 릴리스 판단의 중심은 정렬에 둬야 한다.

3. 명세 중심 개발의 장점과 한계

명세를 먼저 쓰고 에이전트가 구현한 다음 검증하는 방식은 의도를 명시적으로 다룬다는 장점이 있지만, 실제 개발 과정의 피드백 루프를 제거한다.

3.1. spec-driven development가 반복하는 폭포수 모델

1. 일방향 흐름

   1. 요구사항을 적고, 세부 명세를 만든 뒤, 에이전트에게 구현을 시키고 결과를 검증한다.
   2. 1970년대 폭포수 모델의 요구사항 → 명세 → 구현 → 검증 흐름과 같은 구조다.

2. 피드백 루프가 없는 문제

   1. 명세를 작성할 때 아직 발견하지 못한 문제와 모호한 요구가 존재한다.
   2. 구현하는 동안 새로운 문제와 선택지가 드러나지만, 이미 끝난 명세로 돌아가 갱신하지 않는 경우가 많다.
   3. LLM은 결정론적으로 같은 코드를 만들어 주지 않는다. 명세가 완성되면 코드가 결정적으로 나온다는 가정이 깨지므로, day-to-day 개발에 그대로 적용하기 어렵다.

3.2. 대화형 에이전트 개발에서 보존할 핵심은 의도다

1. 명세를 넘어 존재하는 의도

   1. Jira 티켓은 달성할 목표를 표현한다.
   2. PRD는 그 목표를 이루기 위한 세부 계획과 제품 맥락을 제공한다.
   3. 에이전트와의 프롬프트·질문·응답은 실제 결정이 만들어지는 장소다.

2. 프롬프트를 버리는 현재의 문제

   1. 개발자는 Jira 티켓을 보고 시작하지만, 에이전트가 질문을 하면 설명하고, 잘못된 방향을 거절하고, 새 조건을 추가하며 구현을 구체화한다.
   2. 이 과정에서 내려진 사용자 결정이 실제 요구사항을 완성한다.
   3. 현재는 PR을 만들 때 이 프롬프트와 왕복 기록을 버린다. 코드만 남기면 왜 그런 구현을 선택했는지, 어떤 것을 시도했다가 거부했는지 알 수 없다.
   4. 따라서 세션 기록은 버릴 로그가 아니라 정렬과 검증을 위한 1차 요구사항 데이터가 되어야 한다.

4. 의미적 정확성을 AI slop registry로 체계화하기

사람이 반복해서 남기는 동일한 리뷰 지적을 매번 새로 작성하지 말고, 조직의 실행 가능한 규칙으로 누적해야 한다.

4.1. 반복 지적을 레지스트리로 바꾸는 과정

1. 리뷰 경험에서 반복 패턴을 추출한다

   1. 사람이 수동 리뷰를 하며 같은 종류의 문제를 여러 PR에서 계속 발견한다.
   2. 예를 들어 관례 위반, 특정 보안 누락, 반복되는 잘못된 데이터 처리처럼 재사용 가능한 지적을 별도 항목으로 기록한다.

2. AI slop registry를 만든다

   1. AI가 생성한 코드에서 자주 나타나는 문제를 레지스트리에 등록한다.
   2. 레지스트리는 일반적인 LLM 위에 조직의 실제 리뷰 경험을 학습시킨 추가 계층으로 작동한다.
   3. 등록된 지적은 다음 PR부터 자동으로 탐지할 수 있으므로, 사람이 매번 같은 설명을 반복할 필요가 없다.

4.2. 레지스트리가 복리처럼 쌓이는 이유

1. 한 번의 지적을 지속적인 가드레일로 전환한다

   1. 차이(diff)마다 남긴 댓글 하나를 가드레일로 만들면, 같은 문제를 다음 병합에서 다시 수동 검토하지 않아도 된다.
   2. 등록 항목이 늘어날수록 조직의 의미적 정확성 검증 능력이 강해진다.

2. 초기 비용과 J-커브를 감수한다

   1. 기존 리뷰 댓글을 정리하고 레지스트리를 만드는 초반에는 고통과 시간이 든다.
   2. 그러나 매번 반복되던 댓글이 자동 검증으로 바뀌면서 누적 효과가 발생한다.
   3. 발표자는 마지막 1,000개의 리뷰 댓글을 채굴해 반복 가능한 항목부터 AI slop registry로 만들라고 제안한다.

5. 의도에서 테스트 계획과 검증 증거로 이어지는 단일 루프

정렬과 의미적 정확성은 서로 다른 프로젝트가 아니라 같은 리뷰 문제의 두 반쪽이다. 둘을 한 루프로 연결하면 사람이 검토할 표면이 의도와 증거로 바뀐다.

5.1. 세션을 수용 기준으로 변환한다

1. 사용자 응답을 포착한다

   1. 에이전트가 질문한 내용, 사용자가 제공한 조건, 선택한 대안, 거부한 접근법을 세션에서 추출한다.
   2. 단순한 작업이라도 에이전트와 여러 차례 왕복하며 조건이 구체화되므로, 이 결정들이 구현 의도를 이룬다.

2. 수용 기준을 만든다

   1. 세션의 결정과 사용자 의도를 명시적인 acceptance criteria로 정리한다.
   2. LLM은 대화에서 기준을 추출하고 구조화하는 데 활용할 수 있지만, 어떤 기준이 중요한지에 대한 거버넌스와 최종 판단은 사람이 맡는다.
   3. 수용 기준은 제품 관리자·디자이너·엔지니어가 함께 읽을 수 있는 자연어로 작성한다.

5.2. 수용 기준과 불변 조건에서 테스트 계획을 만든다

1. 테스트 계획을 실시간으로 생성한다

   1. 수용 기준과 AI slop registry의 불변 조건(invariant)을 합쳐 변경에 맞는 테스트 계획을 만든다.
   2. 새 기능마다 사람이 테스트 계획을 처음부터 작성하고 지속적으로 유지하는 부담을 줄인다.

2. 테스트 계획을 협업 언어로 만든다

   1. 자연어로 작성된 행동 기준은 코드 구현을 모르는 제품 관리자와 디자이너도 검토할 수 있다.
   2. 이는 20년 넘게 사용된 테스트 주도 개발(TDD)보다 행동 주도 개발(BDD)에 가까운 검토 방식이다.
   3. 수용 기준은 무엇이 동작해야 하는지, 불변 조건은 어떤 안전·품질 규칙이 계속 지켜져야 하는지를 함께 표현한다.

5.3. 프리뷰에서 결정론적 검증과 LLM 검증을 조합한다

1. 검증 시스템이 실행할 일

   1. 변경된 코드를 프리뷰 환경에 띄운다.
   2. 생성된 테스트 계획을 실행해 기능이 엔드투엔드로 실제 동작하는지 확인한다.
   3. 코드가 겉보기에 맞아도 정의된 기능이 실제 사용자 행동으로 이어지는지 검증한다.

2. 결정론적 시스템을 우선한다

   1. 결정론적으로 판별할 수 있는 조건은 고정된 테스트와 명확한 결과로 검증한다.
   2. 모든 시스템을 100% 결정론적으로 만들 수 있다고 가정하지 않는다.
   3. 결정론적 검증이 어려운 부분에 LLM을 fallback으로 사용한다. 핵심 원칙은 “가능한 곳에서는 결정론적으로, 필요한 곳에서는 LLM으로”다.

6. 리뷰 표면을 diff에서 행동 증거로 이동하기

사람은 더 이상 모든 줄을 읽지 않는다. 무엇을 만들겠다고 결정했으며, 그 결정이 구현됐고 실제로 작동한다는 증거를 검토한다.

6.1. 결제 폼 사례로 보는 검증

1. 행동 변화에서 테스트를 생성한다

   1. 웹 애플리케이션에 새로운 결제 폼을 추가한다고 가정한다.
   2. 테스트 계획은 새 폼이 표시되는지, 사용자가 입력할 수 있는지, 결제 시스템 변경이 요구사항과 맞는지를 행동 기준으로 정의한다.

2. 에이전트가 실행 증거를 수집한다

   1. AI 에이전트가 애플리케이션을 브라우징해 폼을 채운다.
   2. 실행 과정의 스크린샷을 캡처하고, 데이터베이스 스냅샷과 함께 조건 충족 여부를 분석한다.
   3. 스크린샷 샘플링은 에이전트가 수행할 수 있지만, 사람이 판단할 수 있는 더 강한 증거 묶음을 남겨야 한다.

6.2. 코드에서 테스트를 추론하면 생기는 자기검증 문제

1. 구현과 테스트가 같은 오류를 공유할 수 있다

   1. 코드를 만든 에이전트가 코드만 보고 테스트 계획도 만들면, 자신의 구현이 가진 맹점을 놓칠 수 있다.
   2. 코드와 테스트가 같은 잘못된 가정을 공유하면 테스트는 문제를 잡지 못하고 통과한다.

2. 세션을 독립적인 의도 원천으로 삼는다

   1. 테스트 계획은 코드가 아니라 세션의 질문과 결정에서 출발해야 한다.
   2. 무엇을 만들려 했는지에 대한 독립적인 기준을 먼저 세우고, 구현이 그 기준을 충족하는지 확인해야 한다.
   3. 이 구조가 코드에 내재한 편향을 줄이고 리뷰어에게 신뢰할 만한 검증 근거를 제공한다.

6.3. 사람이 검토하는 세 가지 증거

1. 의도와 결정

   1. 만들기로 한 기능과 수용 기준이 무엇인지 확인한다.
   2. 시도했다가 거부한 접근법과 최종 선택의 이유를 확인한다.

2. 아키텍처

   1. 데이터 모델이 어떻게 만들어졌는지 검토한다.
   2. 서비스들이 어떻게 상호작용하는지, 경계와 의존성이 설계 의도에 맞는지 논의한다.

3. 동작 증거

   1. 프리뷰 실행 결과, 스크린샷, 데이터베이스 스냅샷, 결정론적 테스트 결과를 확인한다.
   2. 이 증거들이 수용 기준을 충족한다고 말할 수 있을 만큼 충분한지 판단한다.

7. 조직에 적용하는 실행 순서와 제품 방향

이 접근법은 리뷰를 한 번에 자동화하는 마법이 아니라, 사람의 반복 판단을 축적하면서 리뷰의 수준을 올리는 운영 체계다.

7.1. 마지막 1,000개 댓글에서 시작하기

1. 반복 가능한 지적을 분류한다

   1. 최근 리뷰 댓글 1,000개를 모은다.
   2. 여러 PR에서 반복되는 관례·보안·데이터 처리·품질 지적을 식별한다.

2. 레지스트리와 검증을 점진적으로 연결한다

   1. 반복 항목을 AI slop registry에 등록한다.
   2. 새 병합마다 자동 검사하고, 누락이나 오탐을 사람이 보정한다.
   3. 보정 결과를 다시 레지스트리에 반영해 조직의 가드레일을 개선한다.

7.2. 사람의 역할을 거버넌스와 아키텍처로 재배치한다

1. AI가 담당하는 작업

   1. 세션에서 수용 기준을 추출한다.
   2. 수용 기준과 불변 조건으로 테스트 계획을 생성한다.
   3. 프리뷰를 탐색하고 테스트를 실행하며 스크린샷·데이터 스냅샷을 수집한다.

2. 사람이 담당하는 작업

   1. 수용 기준이 제품 의도와 맞는지 승인한다.
   2. 아키텍처 선택과 트레이드오프를 논의한다.
   3. 검증 증거가 충분한지, 팀이 같은 목표를 이해하고 있는지 판단한다.
   4. 반복 지적을 레지스트리에 넣을지, 새로운 가드레일로 승격할지 결정한다.

7.3. Verify의 시범 운영

1. 제품의 목표

   1. Aviator는 Verify라는 새 검증 시스템을 시범 운영하고 있다.
   2. Verify는 세션에서 정렬 정보를 포착하는 측면과 AI를 활용해 의미적 정확성을 검출하는 도구를 결합한다.

2. 초기 설계 파트너 모델

   1. 몇몇 기업과 함께 파일럿을 진행하며 실제 팀의 리뷰·검증 흐름에 맞춘다.
   2. 초기 설계 파트너는 정렬 기준과 자동 검증 능력을 함께 다듬는 역할을 한다.

주요 발언 모음

“When AI reviews and nobody reads, we have configured the wrong thing.”

“Code reviews are not just about code reviews.”

“The most important part is the intent.”

“Every differing comment is now a guardrail that you don't have to review again.”

“LLM where you must, deterministic where you can.”

“If you try to build [the test plan] from the code, you'll end up in the same situation … the test plan will not actually catch issues.”

“Reviewers are reviewing the intent, not the diff.”

“Code is not just about code review. It is about getting the alignment.”

핵심 데이터 & 수치

• 861% 코드 churn: 발표자가 현재 코드 생산·변경량의 폭증을 설명하기 위해 제시한 수치다.
• 약 15~20년: 현대적인 형식적 코드 리뷰의 역사는 오래되지 않았으며, Google이 2006년 내부 도구 Mondrian으로 형식적 리뷰를 정착시킨 사례가 언급된다.
• 4배: 리뷰 대기와 처리에 쓰는 시간이 과거 코딩에 쓰던 시간보다 네 배로 늘었다는 설명이다.
• 30% 이상: 변경의 30% 이상이 리뷰 없이 병합되는 현실을 보여주는 수치다.
• 최근 1,000개 리뷰 댓글: AI slop registry를 만들기 위한 출발점으로 제안된 분석 대상이다.
• 20년 이상: 테스트 주도 개발이 등장한 뒤 충분한 시간이 지났으며, 자연어 행동 기준을 공유하는 방식은 행동 주도 개발에 가깝다는 맥락으로 사용된다.

결론 및 시사점

1. 줄 단위 diff 리뷰는 코드 생산량과 AI 에이전트의 속도를 더 이상 감당하지 못하므로, 리뷰의 대상과 역할을 재정의해야 한다.
2. 자동화의 목표는 사람을 협업에서 제거하는 것이 아니라, 반복 지적과 의미적 정확성 검증을 자동화해 사람이 정렬·아키텍처·거버넌스에 집중하게 하는 것이다.
3. Jira와 PRD만으로는 실제 의도를 다 담지 못하므로, 에이전트와의 세션에서 나온 질문·응답·거부·선택을 보존해야 한다.
4. 세션의 결정은 수용 기준이 되고, 수용 기준과 AI slop registry의 불변 조건은 실시간 테스트 계획으로 변환된다.
5. 프리뷰에서 결정론적 테스트를 우선 실행하고, 결정론적으로 평가하기 어려운 UI·행동은 LLM 에이전트의 브라우징과 스크린샷·데이터 스냅샷으로 보완한다.
6. 코드와 같은 에이전트가 코드에서 테스트를 만들면 자기검증 편향이 생길 수 있으므로, 테스트의 원천은 코드가 아니라 독립적인 세션 의도여야 한다.
7. 조직은 마지막 1,000개 리뷰 댓글을 채굴해 반복 지적을 레지스트리에 등록하는 것부터 시작할 수 있다.
8. 이 과정은 초기에 비용이 크지만, 병합이 쌓일수록 같은 댓글이 가드레일로 재사용되는 J-커브의 복리 효과를 만든다.
9. 최종 리뷰 표면은 diff가 아니라 “무엇을 만들기로 했는가”, “실제로 구현됐는가”, “행동이 수용 기준을 충족한다는 증거가 있는가”가 된다.
10. 코드 리뷰를 없앤다는 결론은 리뷰를 없애는 것이 아니라, 코드 리뷰를 의도 검증과 팀 정렬로 승격한다는 뜻이다.

핵심 요약 (20줄)

1. 코드 생산량이 급증하면서 모든 diff를 사람이 읽는 방식은 리뷰 병목을 만들었다.
2. 리뷰 시간은 늘었고 변경의 30% 이상이 리뷰 없이 병합되는 상황까지 나타났다.
3. AI가 코드를 쓰고 AI가 리뷰하는데 사람이 diff를 훑는 현재의 UI는 역할 배치가 잘못됐다.
4. 코드 리뷰의 목적은 버그 탐지뿐 아니라 지식 공유와 팀 정렬까지 포함한다.
5. 의미적 정확성은 자동화할 수 있지만 팀이 무엇을 만들기로 합의했는지는 보존해야 한다.
6. 명세를 먼저 쓰고 구현하는 방식은 폭포수 모델처럼 피드백 루프를 끊을 수 있다.
7. 실제 의도는 Jira 티켓과 PRD뿐 아니라 에이전트와 주고받은 프롬프트에 담긴다.
8. 세션의 질문과 선택을 버리지 않고 수용 기준으로 변환해야 한다.
9. 반복되는 리뷰 지적은 AI slop registry에 등록해 조직의 가드레일로 만들어야 한다.
10. 한 번 등록한 지적은 이후 병합마다 자동 탐지할 수 있어 리뷰 경험이 복리로 쌓인다.
11. 수용 기준과 불변 조건은 변경에 맞는 테스트 계획을 구성한다.
12. 테스트 계획은 자연어 행동 기준으로 작성해 제품 관리자와 디자이너도 함께 검토할 수 있다.
13. 프리뷰 환경에서 테스트 계획을 실행해 코드가 실제로 엔드투엔드 동작하는지 확인한다.
14. 결정론적으로 검증할 수 있는 조건은 고정된 테스트로 먼저 판별해야 한다.
15. UI 행동처럼 결정론적 검증이 어려운 부분은 LLM 에이전트가 브라우징하고 증거를 수집한다.
16. 결제 폼 사례에서는 입력 과정의 스크린샷과 데이터베이스 스냅샷이 검증 증거가 된다.
17. 코드를 만든 에이전트가 코드만 보고 테스트를 만들면 같은 오류를 공유할 위험이 있다.
18. 사람은 diff보다 의도, 아키텍처 결정, 수용 기준, 검증 증거를 검토해야 한다.
19. 실천의 첫 단계는 최근 1,000개 리뷰 댓글에서 반복 가능한 지적을 채굴하는 일이다.
20. 코드 리뷰를 없앤다는 말은 협업을 없애는 것이 아니라 리뷰를 의도 검증과 정렬로 바꾸는 뜻이다.