AI 시대에 쏟아지는 PR 병목, 어떻게 해결해야 할까요?

URL: https://www.youtube.com/watch?v=8DRjkp_X8yY
날짜: 2026-10-01
채널: Tech Bridge
영상 ID: 8DRjkp_X8yY
원제: Fixing the PR Bottleneck — Matt Pocock, AIHero
발표자: Matt Pocock, AIHero 창립자·TypeScript 교육자
발표 행사: AI Engineer Paris 2026, Coding Agents & Software Factories 트랙
영상 길이: 약 22분 32초
원본 게시 메타데이터: 2026-09-30T04:40:18-07:00 (YouTube 페이지 메타데이터)
수집 메모: 원본 Tech Bridge 영상은 회원 전용이라 yt-dlp 자동자막 요청이 차단되었다. 동일 발표의 공개 설명·발표 기록·전문 전사 자료를 교차 확인해 시간순 논지와 사례를 복원했다.

---

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

==AI 에이전트가 PR을 만드는 속도는 폭발적으로 높였지만, 검토할 만한 PR을 만드는 속도는 거의 높이지 못했다. 병목을 해결하려면 코드를 더 빨리 생성하는 대신 PR 주변에 자동 체크, 자동 리뷰, 위험 기반 인간 리뷰라는 세 겹의 브레이크를 설계해야 한다.==

• 에이전트가 이슈·지원 티켓·관측 신호를 받아 사람 없이 작업을 시작하는 소프트웨어 팩토리가 만들어지고 있다.
• 브레이크 없는 팩토리는 품질 낮은 PR을 쏟아내는 ‘슬롭 캐논(slop cannon)’이 되며, 나쁜 코드베이스는 다음 에이전트의 작업 환경이 된다.
• 자동 체크는 싸지만 구현을 재진술하는 테스트, 소스 구조만 보는 테스트, 과도한 모킹처럼 거짓 신호를 낼 수 있다.
• 딥 모듈, 구현·리뷰 컨텍스트 분리, 자체 코딩 규약, 직접 수정하는 리뷰 에이전트가 품질을 높인다.
• 인간은 모든 PR을 같은 깊이로 읽을 필요가 없고, 되돌릴 수 없는 일방향 문과 큰 blast radius를 가진 변경에 집중해야 한다.

PR의 처리량을 늘리는 일은 곧 검토 수요를 늘리는 일이다. 따라서 속도는 생성 단계의 시간만으로 측정할 수 없다. 자동화된 품질 게이트를 통과한 깨끗한 산출물이 인간에게 도착하고, 인간의 반복적인 지적이 다음 PR의 체크·규약·환경으로 축적될 때 비로소 전체 흐름의 속도가 빨라진다.

1. PR 병목이 에이전트 시대에 증폭되는 이유

PR은 AI 이전에도 조직의 병목이었다. 검토받지 못한 PR이 쌓이고, 누군가가 변경의 의도와 안전성을 확인해야만 다음 단계로 넘어갈 수 있었다. 에이전트는 이 오래된 병목 위로 코드 변경의 공급량을 훨씬 빠르게 밀어 넣는다.

1.1. 소프트웨어 팩토리의 의미

1. 사람이 모든 작업을 시작하던 모델의 변화

   1. 전통적인 흐름에서는 사람이 티켓을 읽고, 작업을 선택하고, 에이전트나 개발자에게 구현을 지시한다.
   2. 소프트웨어 팩토리에서는 작업의 시작 일부를 에이전트에게 위임한다. 사람은 모든 PR의 첫 단추를 직접 끼우지 않아도 된다.

2. 결정론적 신호가 에이전트를 호출하는 방식

   1. Jev 같은 분류 도구가 버그 신고를 분류한 뒤 버그 수정이나 재현 절차 작성 작업으로 변환할 수 있다.
   2. PlanetScale에서 느린 데이터베이스 쿼리 리포트를 내보내면 그 신호가 별도의 에이전트 워크플로를 자동으로 시작할 수 있다.
   3. 이 작업들은 사람이 프롬프트를 입력해서 시작하는 것이 아니라 결정론적 코드와 이벤트에 의해 발화된다.

1.2. 가속만 하면 ‘슬롭 캐논’이 된다

1. 검토 능력을 초과하는 공급량

   1. 에이전트는 PR을 여는 일을 쉽게 만들지만, 검토할 가치가 있는 PR을 만드는 일은 조금만 쉽게 만든다.
   2. 생성량만 계속 키우면 사람이 읽을 수 없는 저품질 PR이 쌓이고, 팩토리는 ‘슬롭 캐논’처럼 작동한다.

2. 코드베이스가 에이전트의 실행 환경이라는 관점

   1. 에이전트는 코드를 일회성 결과물로만 소비하지 않고, 다음 작업의 탐색·추론·수정 환경으로 사용한다.
   2. 코드가 중복되고 경계가 흐리며 테스트가 거짓 신호를 내면 그 환경에서 수행하는 다음 작업도 나빠진다.
   3. 따라서 개발자 경험(DX)에 들였던 설계·도구·피드백의 엄격함을 에이전트 경험(AX)에도 적용해야 한다.

2. 세 겹의 브레이크로 PR 흐름을 제어하기

PR 속도를 높이는 핵심은 사람에게 모든 검사를 맡기는 것이 아니라 비용이 싼 앞단에서 품질을 걸러 인간 판단을 더 가치 있는 곳에 쓰게 만드는 것이다.

2.1. 자동 체크·자동 리뷰·인간 리뷰

1. 첫 번째 층: 결정론적 자동 체크

   1. 린터, 테스트, 타입 체크, 코드 품질 지표처럼 같은 입력에 매번 같은 방식으로 반응하는 장치다.
   2. 이 계열의 기법은 오래전부터 존재했고, 사람의 판단이나 에이전트 토큰이 아니라 CPU 사이클을 주로 소비한다.
   3. 비용이 낮으므로 저장소에 여러 겹의 체크를 쌓을 수 있으며, 변경 때마다 실행하는 것이 합리적이다.

2. 두 번째 층: 자동 리뷰

   1. 별도의 에이전트가 테스트가 직접 확인하지 못한 문제와 코드베이스 전체의 구조를 살핀다.
   2. 결정론적 체크가 통과했다는 사실만으로는 동작의 의도와 변경의 품질을 증명할 수 없으므로, 자동 리뷰는 앞단 체크의 거짓말을 찾는 역할을 한다.

3. 세 번째 층: 인간 리뷰

   1. 사람이 PR의 위험도, 의도, 제품·운영 맥락, 되돌릴 수 있는지를 판단한다.
   2. 앞의 두 층이 저품질 변경과 반복적인 지적을 줄이면 인간 리뷰는 더 짧고 선택적으로 수행할 수 있다.

2.2. 비용 곡선과 품질의 관계

1. 자동 체크는 CPU만 추가로 사용하므로 많이 실행해도 상대적으로 싸다.
2. 버그를 잡아 에이전트가 수정 토큰을 더 쓰게 되더라도, 출시 후 사람이 원인을 추적하는 비용보다 저렴할 수 있다.
3. 자동 리뷰는 토큰을 소비하므로 체크보다 비싸지만 사람의 검토 시간을 줄여주는 중간 단계다.
4. 인간 리뷰는 가장 비싼 자원이며, 목표는 인간을 완전히 제거하는 것이 아니라 사람에게 도착하는 PR의 질을 높여 개입 횟수와 깊이를 줄이는 것이다.

3. 자동 체크가 거짓말하는 세 가지 방식

초록색 CI는 병합 가능성의 증명서가 아니다. 자동 체크는 코드가 실제로 의도한 행동을 하는지 확인하지 않고도 통과할 수 있으며, 자동 리뷰와 인간 리뷰는 이 거짓 신호를 감지하는 거짓말 탐지기여야 한다.

3.1. 구현을 되풀이하는 동어반복 테스트

1. 상수 자체를 다시 선언하는 테스트

   1. 게시물 길이 제한을 x_post_character_limit = 280으로 정의했을 때, 테스트가 단순히 “이 상수는 280이다”라고 주장할 수 있다.
   2. 이 테스트는 사용자가 실제로 280자 제한을 경험하는지 확인하지 않고 구현값을 그대로 재진술한다.

2. 구조에 과도하게 결합되는 문제

   1. 제한값을 바꾸거나 상수 이름을 바꾸면 기능의 외부 행동이 유지되어도 테스트가 깨진다.
   2. 테스트가 동작이 아니라 코드의 현재 모양에 결합되어 있어 리팩터링을 방해하고, 실제 회귀를 놓칠 수 있다.
   3. 발표자는 당시 Opus 5가 이런 동어반복 테스트에 지나치게 빠지는 경향을 보였다고 설명한다.

3.2. 실행하지 않고 소스 구조만 검사하는 테스트

1. UI 순서를 문자열로 확인하는 사례

   1. 상세 페이지에서 content_plan 다음에 videos 섹션이 표시되는지 확인해야 하는 상황을 가정한다.
   2. 잘못된 테스트는 실제 UI를 렌더링하지 않고 소스 파일을 메모리에 읽어 두 문자열의 위치만 비교한다.

2. 거짓 실패와 거짓 안심

   1. 소스 파일의 작성 순서만 바뀌어도 화면의 실제 행동과 무관하게 테스트가 실패한다.
   2. 반대로 추상화 계층이 달라져 문자열 비교가 의도한 행동을 포착하지 못하면 CI는 초록색이어도 사용자가 보는 UI는 틀릴 수 있다.

3.3. 실패할 수 없게 만든 과도한 모킹

1. AudioContext 사례

   1. useAudioBoost 훅이 브라우저의 AudioContext API를 사용한다고 가정한다.
   2. 테스트가 실제 API를 호출하는 대신 몇 가지 더미 메서드만 가진 모킹 객체를 넣으면 테스트는 쉽게 통과한다.

2. 모킹이 숨기는 생산 환경의 오류

   1. 실제 AudioContext에는 테스트용 가짜 객체가 재현하지 않는 복잡한 오류 모드와 특정 조건의 실패가 존재한다.
   2. 모킹이 너무 강하면 테스트는 원래 잡아야 할 오류를 만날 기회 자체를 잃는다.
   3. 이 문제는 에이전트가 악의적으로 테스트를 속이는 현상이 아니다. 주어진 지시를 구현 세부사항에 맞춰 수행하면서 실제 동작을 실행하지 않는 것이 핵심이다.

3.4. ‘에이전트를 막기’보다 체크를 속이기 어렵게 설계하기

1. 나쁜 테스트를 쓰지 말라고 에이전트에게 훈계하는 것만으로는 충분하지 않다.
2. 구현 세부사항을 복사하면 통과하는 테스트가 아니라, 실제 행동을 실행해야만 통과할 수 있는 경계를 설계해야 한다.
3. 이 문제는 프롬프트의 문제가 아니라 코드베이스 설계와 자동 체크의 검증력 문제다.

4. 딥 모듈로 행동 중심 테스트를 강제하기

자동 체크의 질은 테스트 문구만이 아니라 테스트가 접하는 코드 구조에 의해 결정된다. 복잡성을 작은 인터페이스 뒤에 숨기면 에이전트가 내부 구조를 훔쳐보지 않고 행동을 검사하게 만들 수 있다.

4.1. 딥 모듈과 얕은 모듈의 대비

1. 딥 모듈(Deep Module)

   1. 큰 구현과 복잡한 동작을 작은 인터페이스 뒤에 숨긴다.
   2. 호출자는 단순한 함수나 몇 개의 진입점만 사용하면서 큰 가치를 얻는다.
   3. 구현의 많은 부분이 감춰지므로 내부 이름·파일 배치·세부 함수에 결합된 테스트가 줄어든다.

2. 얕은 모듈

   1. 인터페이스가 크고 함수가 많지만 각 함수가 제공하는 기능은 작다.
   2. 호출자와 테스트가 구현 세부사항에 직접 손을 뻗기 쉬워 구조 민감 테스트와 중복 로직이 늘어난다.

4.2. 코드베이스 디자인 스킬의 실제 역할

1. improve-codebase-architecture 계열의 스킬은 이상하게 작성된 바이브 코딩 코드베이스에서도 모듈을 더 깊게 만들 기회를 찾는다.
2. 여러 컴포넌트에 같은 복합 가시성 규칙이 손으로 반복되어 있고 공통 이름이나 단위 테스트가 없다면, 규칙을 visibility-predicates.ts 같은 이름 있는 모듈로 추출한다.
3. 하나의 작은 인터페이스를 세 곳의 호출 지점이 공유하게 만들면 중복이 줄고, 규칙을 독립적으로 테스트할 수 있다.
4. 스킬은 변경 전·후의 중복과 개선 기회를 HTML 문서로 보여주어 팀이 제안된 구조를 확인하고 실제 구현으로 옮기게 한다.

4.3. 팀과 에이전트를 위한 공통 설계 언어

1. 코드베이스 구조를 설명하는 방법은 많고, 서로 다른 접근이 모두 DDD라는 이름으로 불리기도 한다.
2. 팀이 에이전트와 같은 기준으로 논의하려면 locality, leverage, seam 같은 공통 용어가 필요하다.
3. Locality는 관련 코드가 한 장소에 얼마나 잘 모여 있는지, 한 모듈의 작은 변경이 전체에 어떻게 파급되는지를 뜻한다.
4. Leverage는 작은 인터페이스 호출 하나가 호출자에게 얼마나 큰 가치를 제공하는지를 뜻한다.
5. Seam은 코드를 분리하고 대체·검증할 수 있는 경계다.
6. 이 언어는 사람에게만 유용한 것이 아니라, 에이전트가 어디에서 정보를 찾고 어느 경계를 통해 변경해야 하는지 알려주는 설계 가이드가 된다.

5. 구현과 리뷰의 컨텍스트를 분리하기

좋은 코드를 한 번의 에이전트 호출에서 모두 만들어내려는 욕심은 구현 에이전트의 컨텍스트를 과부하한다. “먼저 작동하게 만들기”와 “규약에 맞게 좋게 만들기”를 서로 다른 에이전트·컨텍스트의 두 단계로 분리해야 한다.

5.1. 구현 에이전트는 이미 과부하 상태다

1. 구현 에이전트는 변경할 파일과 주변 맥락을 탐색해야 한다.
2. 코드를 수정하고 필요한 파일을 업데이트해야 한다.
3. 자동 체크를 실행하고 실패 원인을 디버깅하며 실제로 동작하는지 검증해야 한다.
4. 여기에 모든 코딩 규약과 아키텍처 원칙까지 한 번에 적용하라고 하면, 하나의 컨텍스트 창이 감당해야 할 일이 너무 많아진다.

5.2. 리뷰 에이전트는 별도의 여유를 갖는다

1. 리뷰 에이전트는 구현을 새로 하지 않고, 디버깅도 하지 않으며, diff와 저장소의 맥락을 조사해 품질을 판정한다.
2. 구현 에이전트가 과부하되어 있는 반면 리뷰 작업은 상대적으로 언더로드 상태이므로, 리뷰 에이전트에 더 많은 규약을 제공해도 성능이 떨어지지 않는다.
3. 구현 에이전트가 한 컨텍스트에서 최소한 작동하는 상태를 만들고, 리뷰 에이전트가 다른 컨텍스트에서 리팩터링하는 흐름은 TDD의 red-green-refactor와 유사하다.

5.3. 코딩 규약은 전용 파일에 둔다

1. 코딩 규약을 전역 지시문이나 AGENTS.md에 무조건 넣으면 구현 작업의 중요한 탐색 정보가 규칙에 묻힐 수 있다.
2. 저장소의 coding-standards.md에 팀의 실제 규칙을 적고, 코드 리뷰 에이전트가 diff와 함께 읽게 한다.
3. 이 분리는 구현 에이전트가 “작동하는 변화”에 집중하고 리뷰 에이전트가 “좋은 변화”와 규약 준수에 집중하게 한다.

6. 범용 리뷰 봇이 아닌 팀 고유의 리뷰어 만들기

자동 리뷰를 외부 서비스에 전부 맡기는 접근에는 오탐과 범위 불일치 문제가 있다. 리뷰 품질은 팀의 반복되는 실수와 실제 기준을 축적하는 방향으로 진화해야 한다.

6.1. 범용 리뷰의 두 가지 실패

1. 모든 버그와 보안 문제를 찾는 범용 리뷰어는 너무 추상적이어서 현재 유스케이스와 무관한 경고를 많이 낸다.
2. 반대로 TypeScript 문제를 전부 잡도록 구체화하면 Rust 같은 다른 언어를 쓰는 팀에는 쓸 수 없게 된다.
3. Cursor BugBot, CodeRabbit 같은 서비스가 유용할 수 있어도, 조직의 실제 규약과 맥락을 자동으로 완전히 알 수는 없다.

6.2. 규약을 조직의 자산으로 축적하기

1. 팀에서 반복되는 리뷰 지적을 coding-standards.md에 추가한다.
2. 리뷰 에이전트가 해당 기준을 적용하고, 발견한 문제는 가능한 한 직접 수정해 커밋한다.
3. 자체 리뷰어는 조직의 코드 스타일·아키텍처·제품 위험을 반영하면서 시간이 갈수록 오탐을 줄인다.

6.3. 리뷰 에이전트는 댓글보다 커밋을 남긴다

1. 리뷰 봇이 PR에 장황한 댓글만 남기면 인간은 모든 댓글을 읽고 어떤 것을 수정할지 다시 판단해야 한다.
2. 리뷰 에이전트가 확실한 문제를 직접 고쳐 커밋하면 사람은 정리된 결과물을 검토할 수 있다.
3. 질문이나 불확실한 판단만 댓글로 남기고, 기본 동작은 지적이 아니라 수정이어야 한다.
4. 구현 에이전트에게 한 번에 완벽한 결과를 강요하는 대신, 구현과 리뷰를 순차적인 협업으로 설계하는 편이 더 안정적이다.

7. 인간이 빠르게 판단할 수 있는 PR 만들기

자동 체크와 자동 리뷰를 통과한 뒤에도 인간은 PR의 위험과 의도를 빠르게 파악해야 한다. 모든 PR에 같은 깊이의 주의를 투입하는 대신, 정보 밀도가 높은 형식으로 중요도를 분류해야 한다.

7.1. 일방향 문과 양방향 문

1. 양방향 문(two-way door)

   1. 병합 후 문제가 생겨도 되돌리기 쉬운 변경이다.
   2. 소프트웨어의 많은 변경은 리버트할 수 있으므로 간단한 확인으로 충분할 수 있다.
   3. 소프트웨어가 토목 공학보다 유리한 점은 실수를 코드 리버트로 되돌릴 수 있다는 것이다.

2. 일방향 문(one-way door)

   1. 실패했을 때 결과를 원상 복구하기 어렵거나 비용이 매우 큰 변경이다.
   2. 코드 몇 줄만 바뀌어도 6만 명에게 잘못된 이메일을 보내는 변경은 일방향 문이다.
   3. 고비용 데이터 마이그레이션, 데이터 손실, 되돌릴 수 없는 외부 영향도 일방향 문으로 취급해야 한다.
   4. 일방향 문은 자동화가 통과했더라도 사람이 깊고 신중하게 검토해야 한다.

7.2. blast radius와 merge danger

1. 변경이 실패할 수 있는 지점과 실패 시 손상의 심각도를 blast radius로 표현한다.
2. PR 하단에 merge danger 요약을 두면 변경의 되돌림 가능성과 영향 범위를 한눈에 보여줄 수 있다.
3. “양방향 문이며 영향 범위가 국소적”이라는 정보가 보이면 리뷰어는 시간을 많이 쓰지 않고 통과시킬 수 있다.
4. 반대로 일방향 문이거나 영향 범위가 넓다는 요약이 보이면 앞단 체크가 모두 통과해도 인간의 주의를 집중한다.

7.3. 텍스트 대신 의도와 흐름을 시각화하기

1. PR의 목적을 긴 설명만으로 전달하는 대신 의사코드로 변경 전·후의 핵심 흐름을 보여준다.
2. show me 계열의 human-layer 스킬은 텍스트를 줄이고 Mermaid·UML·간단한 시각 요약을 생성한다.
3. 예를 들어 CLI에 새 명령 하나와 두 개의 플래그가 추가되었다는 사실을 그림으로 표시하면 리뷰어가 “무엇이 왜 바뀌었는가”를 빠르게 이해한다.
4. 시각화의 목표는 예쁜 문서를 만드는 것이 아니라 Why를 파악하는 시간을 줄이는 것이다.

8. Retro로 인간 리뷰를 복리로 만들기

인간 리뷰가 한 PR의 품질을 고치는 데서 끝나면 같은 지적이 반복된다. 리뷰는 코드를 만든 시스템과 에이전트의 작업 환경을 개선하는 입력이어야 한다.

8.1. 같은 리뷰 댓글을 두 번 쓰지 않는 원칙

1. 에이전트가 여러 PR에서 같은 실수를 반복하면 사람이 매번 같은 지적을 남기는 것은 시스템의 실패다.
2. 반복 지적은 결정론적 체크, 코딩 규약, 탐색 포인터, 도구 출력 형식 중 하나로 변환되어야 한다.
3. 인간 리뷰어는 현재 diff뿐 아니라 그 diff를 만들어낸 프롬프트·스킬·지시 파일·도구의 품질까지 살펴야 한다.

8.2. Retro 스킬의 입력과 산출물

1. 단일 에이전트 세션을 넣어 해당 작업의 문제를 분석할 수 있다.
2. PR과 그 PR을 만든 세션을 함께 넣어 구현·리뷰·수정의 연결을 볼 수 있다.
3. 지난 일주일의 PR과 리뷰를 묶어 반복 패턴을 찾을 수도 있다.
4. 결과로 다음 PR의 자동 체크 제안, coding-standards.md 업데이트 제안, 리뷰 프로세스 개선안을 만든다.

8.3. 코드 외 환경까지 개선하기

1. 에이전트가 정보를 찾기 어려워했던 지점을 찾아 AGENTS.md에 navigation pointer를 추가할 수 있다.
2. 세션에서 사용하는 도구를 더 토큰 효율적인 도구로 바꿀 수 있는지 점검한다.
3. 지나치게 길거나 중복된 steering 파일과 스킬의 bloat가 모델의 주의를 분산시키는지도 확인한다.
4. 이 개선들은 외부에서 디버깅하기 어려운 에이전트 작업 환경을 직접 관찰하게 해주므로, 예상보다 많은 문제를 발견할 수 있다.

주요 발언 모음

“Agents make it trivial to open a PR. They make it only slightly easier to open one worth reviewing.”
에이전트는 PR을 여는 일을 쉽게 만들지만, 검토할 가치가 있는 PR을 만드는 일은 조금만 쉽게 만든다.

“Code is the environment your agent operates in.”
코드는 에이전트가 작동하는 환경이다.

“Green CI does not mean ready to merge.”
초록색 CI가 곧 병합 준비 완료를 의미하지는 않는다.

“The default should be commits.”
리뷰 에이전트의 기본 동작은 댓글이 아니라 커밋이어야 한다.

“You really don't need to review every single two-way door. Every single one-way door, you do.”
모든 양방향 문을 빠짐없이 리뷰할 필요는 없지만, 모든 일방향 문은 리뷰해야 한다.

핵심 데이터 & 수치

• 약 22분 32초: YouTube 페이지의 lengthSeconds 메타데이터 기준 영상 길이다.
• 세 겹의 브레이크: 결정론적 자동 체크 → 에이전트 자동 리뷰 → 위험 기반 인간 리뷰의 순서다.
• 280자: 구현 상수와 같은 값을 그대로 확인하는 동어반복 테스트의 예시다.
• 6만 명: 작은 코드 변경처럼 보여도 대량 이메일을 잘못 발송하면 일방향 문이 될 수 있음을 보여주는 영향 범위 사례다.
• 세 가지 거짓 체크: 동어반복 테스트, 소스 구조에 민감한 테스트, 과도한 모킹으로 실패할 수 없게 된 테스트다.
• 세 가지 설계 용어: locality, leverage, seam은 코드 구조와 에이전트의 탐색·변경 경계를 논의하기 위한 공통 언어다.
• 세 가지 Retro 입력 범위: 단일 세션, PR과 세션의 조합, 일주일치 PR·리뷰 묶음이다.

결론 및 시사점

1. AI 시대의 개발 속도는 PR 생성량이 아니라 검토 가능한 변화가 안전하게 흐르는 속도로 측정해야 한다.
2. 소프트웨어 팩토리는 작업을 자동으로 시작할수록 강해지지만, 품질 브레이크가 없으면 산출량이 기술 부채와 검토 부채로 바뀐다.
3. 값싼 결정론적 체크를 최대한 많이 쌓되, 그 체크가 거짓말할 수 있다는 전제를 자동 리뷰와 인간 리뷰에 반영해야 한다.
4. 테스트가 구현 세부사항에 결합되지 않도록 딥 모듈과 작은 인터페이스를 설계하고, 에이전트가 그 경계를 통해 행동을 검증하게 해야 한다.
5. 구현 에이전트에는 탐색·수정·디버깅을 맡기고, 코딩 규약 적용과 리팩터링은 별도의 리뷰 에이전트에 맡기는 편이 컨텍스트를 효율적으로 사용한다.
6. 범용 봇의 경고를 쌓기보다 팀의 반복 실수를 자체 규약과 자체 리뷰어에 축적해야 한다.
7. 리뷰 에이전트는 사람이 처리해야 할 댓글을 늘리지 말고, 확실한 문제를 직접 수정해 깨끗한 커밋을 만들어야 한다.
8. PR에는 일방향·양방향 문, blast radius, merge danger를 명시해 인간의 주의력을 위험에 비례해 배분해야 한다.
9. 의사코드와 다이어그램은 변경의 Why를 빠르게 전달해 인간 리뷰를 짧게 만든다.
10. 인간의 리뷰는 단일 PR 수정으로 끝나지 않고 자동 체크·코딩 규약·탐색 포인터·도구·스킬의 개선으로 이어져야 한다.
11. 궁극적인 목표는 인간 리뷰를 없애는 것이 아니라, 양방향 문 리뷰는 가볍게 하고 일방향 문 리뷰는 확실하게 만드는 것이다.

핵심 요약 (20줄)

AI 에이전트는 PR을 여는 속도를 크게 높였지만 검토 가능한 PR을 만드는 속도는 조금만 높였다.

사람이 시작하지 않아도 이슈 분류기와 느린 쿼리 감시가 에이전트 작업을 자동으로 발화하는 소프트웨어 팩토리가 만들어진다.

브레이크 없는 소프트웨어 팩토리는 검토할 수 없는 저품질 PR을 쏟아내는 슬롭 캐논이 된다.

코드베이스는 에이전트가 작동하는 환경이므로 나쁜 구조는 다음 에이전트 작업의 품질까지 악화시킨다.

PR 병목의 해법은 생성 속도를 더 높이는 것이 아니라 PR 주변의 품질·검토 프로세스를 고치는 데 있다.

첫 번째 방어층은 린터·테스트·타입 검사·품질 지표로 구성된 값싼 결정론적 자동 체크다.

두 번째 방어층은 테스트가 놓친 문제와 코드베이스 전체 구조를 살피는 자동 리뷰 에이전트다.

세 번째 방어층은 위험과 의도를 판단하는 인간 리뷰이며 앞선 두 층이 사람의 검토 시간을 줄인다.

초록색 CI는 병합 가능성을 보장하지 않으며 자동 체크와 리뷰는 서로의 거짓말을 찾아야 한다.

구현을 그대로 재선언하는 동어반복 테스트는 동작이 아니라 상수와 내부 구조를 검증한다.

소스 파일에서 문자열 위치만 비교하는 구조 민감 테스트는 실제 UI 동작을 실행하지 않아 잘못된 신호를 낸다.

AudioContext 같은 실제 API를 과도하게 모킹하면 테스트가 본 production 오류를 영원히 드러내지 못한다.

에이전트가 나쁜 테스트를 일부러 쓰는 것이 아니라 지시를 구현 세부사항에 맞춰 수행하는 것이 문제의 핵심이다.

복잡한 동작을 작은 인터페이스 뒤에 숨기는 딥 모듈은 구현 변경에 강하고 행동 중심 테스트를 유도한다.

locality·leverage·seam이라는 공통 언어는 팀과 에이전트가 코드 구조를 일관되게 논의하게 만든다.

구현 에이전트는 탐색·수정·디버깅만으로 과부하되므로 코딩 규약은 별도 리뷰 에이전트의 맥락으로 분리해야 한다.

리뷰 에이전트는 coding-standards.md를 읽고 구현 에이전트와 다른 컨텍스트에서 동작해야 한다.

범용 리뷰 서비스 대신 팀의 반복 실수를 축적한 자체 규약과 리뷰어를 구축해야 오탐을 줄일 수 있다.

리뷰 에이전트는 장황한 댓글을 남기기보다 발견한 문제를 직접 커밋해 사람에게 깨끗한 결과물을 넘겨야 한다.

되돌릴 수 있는 양방향 문은 가볍게 보고 대량 이메일·고비용 마이그레이션·데이터 손실 같은 일방향 문은 깊게 검토해야 한다.

PR에는 merge danger와 blast radius를 적고 의도를 의사코드·Mermaid·UML로 보여주며 회고 결과를 다음 체크와 규약에 반영해야 한다.

---

📁 Obsidian: /Users/flowkater/Obsidian/flowkater/flowkater/Study/YouTube다이제스트/2026-10-01-Tech Bridge-8DRjkp_X8yY.md