01
큐레이터의 판단
바이브 코딩으로 내 AI 시스템의 CLI나 UI를 확장하면 코드를 만드는 속도보다 변경을 검토하는 역량이 병목이 될 수 있다. Matt Pocock은 ‘Fixing the PR Bottleneck’에서 자동 검사, 별도 에이전트 리뷰, 위험에 비례한 인간 리뷰를 세 겹의 브레이크로 제안한다. 이 큐레이션은 그 전략을 내가 소유한 데이터·권한·작업 흐름을 지키며 기능을 더하는 방법으로 읽는다. 리뷰 속도와 품질에 관한 발언은 발표자의 경험과 제안이며, 독립적으로 검증된 측정 결과가 아니다.
02
누구에게 유용한가
에이전트로 자신의 AI 시스템에 CLI·UI·자동화 기능을 직접 더하고 있으며, 생성된 변경의 테스트와 PR 검토를 설계하려는 사람. diff, CI, 에이전트 작업 위임의 기본을 알고 데이터·권한·오류 복구의 책임까지 살펴볼 준비가 있으면 좋다.
03
핵심 내용
04:49 · 녹색 CI가 놓치는 실제 동작 ↗
- Pocock은 구현 상수를 그대로 되풀이하는 테스트, 화면 대신 소스 텍스트의 순서를 검사하는 테스트, 실제 오류 경로를 가짜 객체로 가리는 테스트를 보여 준다. CI가 통과해도 동작을 충분히 확인하지 못할 수 있다는 설명이다.
- 그는 복잡한 구현을 단순한 인터페이스 뒤에 숨기는 깊은 모듈을 제안한다. 에이전트가 내부 구조보다 인터페이스의 동작을 테스트하게 만드는 설계가 도움이 된다는 그의 견해다.
11:32 · 구현과 리뷰의 맥락을 나누기 ↗
- Pocock은 구현 에이전트가 탐색·수정·디버깅에 집중하고, 별도 맥락의 리뷰 에이전트가 diff와 주변 코드, coding-standards.md를 읽게 한다. 먼저 작동하게 만든 뒤 품질을 다듬는 두 단계 전략이다.
- 그는 리뷰어가 명확한 문제를 직접 수정·커밋하고 판단이 필요한 것만 질문으로 남겨야 인간의 일이 줄어든다고 주장한다.
16:31 · 되돌릴 수 있는가, 어디까지 영향을 주는가 ↗
- Pocock은 되돌리기 쉬운 변경과 대량 이메일 발송·데이터 손실·비싼 마이그레이션처럼 되돌리기 어려운 변경을 구분하고, 실패의 영향 범위에 따라 인간의 리뷰 강도를 정하자고 제안한다.
- 변경 이유와 동작을 의사코드나 다이어그램으로 보여 주면 검토자가 이해하는 부담을 줄일 수 있다고 말한다. 이를 담는 PR 설명 스킬은 발표 당시 작업 중이었다.
19:43 · 반복된 지적을 다음 검사의 재료로 ↗
- Pocock은 인간 리뷰가 코드뿐 아니라 코드를 만드는 과정도 검토해야 한다고 본다. 같은 문제를 여러 PR에서 다시 지적하지 않도록 작업 세션과 리뷰를 회고하는 retro 스킬을 소개한다.
- 그의 retro는 자동 검사와 코딩 표준의 보완을 제안하고, 에이전트가 자료를 찾기 쉽게 하는 AGENTS.md의 탐색 포인터, 도구 사용, 비대한 지시 파일도 살핀다. 영상은 이 전략을 소개하며 결함 감소를 입증한 비교 측정은 제시하지 않는다.
04
큐레이터의 해석•제안
- 내 시스템에서는 CLI의 입력·출력과 실패 응답, UI에서 실제로 실행되는 작업을 확인하기를 권한다. 데이터 접근과 권한 오류, 누락된 실패 처리는 재현 가능한 검사로 남기고 사람이 판단할 기준은 문서에 적는다.
- Pocock의 리뷰어 직접 수정 방식을 모든 프로젝트의 기본값으로 받아들일 필요는 없다. 독립성을 유지하려면 읽기 전용 리뷰가 지적을 남기고 구현자가 수정하는 방식도 고려할 수 있다. 수정 결과를 다시 검증하고, 회고로 검증 기준이나 권한을 바꿀 때도 별도로 검토하기를 권한다.
- 내 AI 시스템의 PR에는 복구 방법과 데이터·권한·외부 실행에 미치는 영향을 적기를 권한다. 코드만 되돌려도 이미 보낸 메시지나 삭제한 자료가 복구되지는 않는다는 점을 인간 리뷰의 기준으로 삼는다.
05