풀 리퀘스트는 죽었다, 풀 리퀘스트 만세
(gieseanw.wordpress.com)- AI가 코드를 작성하는 시대에 풀 리퀘스트(PR) 리뷰 방식이 근본적으로 바뀌어야 하며, 현재의 리뷰 프로세스는 AI 코딩 워크플로우에 맞지 않음
- 리뷰어가 "왜 이렇게 했나?"라고 질문하면 개발자가 AI에게 다시 물어 답변을 붙여넣는 구조로, 인간이 중개인(middleman) 역할에 머무르는 비효율 발생
- AI의 의사결정 로그(decision log) 를 코드와 함께 소스 컨트롤에 포함시켜, 리뷰어가 맥락을 직접 확인할 수 있어야 함
- 리뷰어 코멘트를 AI가 직접 수신하고 패치와 응답을 자동 생성하는 워크플로우가 GitHub/GitLab 웹훅과 MCP 서버 조합으로 이미 가능
- 설계 문서와 아키텍처 다이어그램도 Markdown이나 Mermaid 같은 LLM 파싱 가능 포맷으로 소스 컨트롤에 포함해야 하며, "컨텍스트가 왕"
AI 시대의 코드 리뷰 문제점
- PR 리뷰 시 질문을 하면 AI가 생성한 듯한 답변이 돌아오는데, 실제로 코드를 작성한 것이 AI이기 때문
- "왜 이 라이브러리를 선택했나?"라는 질문에 인간 개발자가 답할 수 없고, AI에게 다시 질문한 뒤 답변을 복사해 전달하는 구조
- AI 이전에는 개발자(코드 작성자)에게 직접 물었지, 그 매니저에게 묻지 않았으므로 중개인을 제거해야 함
- 코드의 모든 작성자가 리뷰에 참여해야 하며, 리뷰 질문에 대해 별도 AI 에이전트가 사후적으로 이유를 역추론하는 방식은 완전히 잘못된 접근
의사결정 로그의 필요성
- 인간에게 "왜?"라고 물을 때는 PR에 포함되지 않은 내부 사고 과정을 묻는 것
- AI의 chain-of-thought는 외부 감사 가능(externally auditable)하고, AI와의 상호작용 기록도 감사 가능하므로 이 맥락을 리뷰와 소스 컨트롤에 넣어야 함
- PR 제작 과정에서 생성된 모든 토큰을 커밋할 필요는 없으며, Random Labs의 에피소드(episodes) 개념에서 영감을 받아 성공한 도구 호출과 결론의 트랜스크립트만 포함
- 에이전트 스웜(agent swarm) 환경에서도 확장 가능하며, PR 전 단계에서 의사결정 로그를 연결하고 최종 포맷팅을 수행
인라인 코멘트의 한계
- 소스 파일 변경은 코멘트만 수정해도 빌드 파이프라인 재실행(린팅, 컴파일, 테스트)이 필요
- 의사결정 트랜스크립트는 일반적인 인라인 코멘트에 허용되는 분량보다 훨씬 큼
- 기존 코멘트는 코드가 현재 어떻게 동작하는지를 설명하지, 그 결정에 이르기까지의 과정을 설명하지 않음
AI 통합 리뷰 워크플로우
- 리뷰어가 코멘트를 달면 개발자의 AI가 직접 수신하여 패치와 응답을 자동으로 생성할 수 있어야 함
- GitHub/GitLab 웹훅과 MCP 서버 조합으로 현재 이미 구현 가능
- Devin AI나 Claude Code via GitLab Duo와 유사한 방식
- 개발자가 AI에게 먼저 허락을 구하도록 설정하거나, AI가 스스로 판단해 바로 조치하도록 설정 가능
- 인간 개발자도 여전히 자체적으로 코멘트와 수정을 할 수 있음
- 리뷰 코멘트가 몇 시간 혹은 며칠 후에야 반영되거나 아예 반영되지 않는 문제를 크게 줄일 수 있음
리뷰어를 위한 도구 요구사항
- 리뷰어도 코드베이스를 탐색하듯 PR을 AI로 직접 질문하며 검토할 수 있어야 함
- 의사결정 로그가 코드와 함께 체크인되어 있어야 이 목적에 핵심적
- 기존 PR 인터페이스 그대로 사용하면서, 옆에 Codex나 Claude와 대화할 수 있는 창이 IDE 개발 환경처럼 통합되어야 함
- 아직 깔끔한 도구가 없으므로 누군가 만들어 주면 좋겠음
- diff에서 모르는 라이브러리, 낯선 언어, 베스트 프랙티스에 대해 AI와 비공개로 질의응답한 뒤 코드 리뷰 코멘트가 필요한지 판단
- 코멘트가 필요한 경우, 이는 의사결정 로그에 빈 부분(gap) 이 있다는 신호이므로 PR 승인 전에 로그를 업데이트해야 함
설계 문서와 컨텍스트의 중요성
- AI 통합 리뷰에서는 리뷰어가 직접 패치를 제안하는 것도 훨씬 쉬워짐
- 설계 문서, 의사결정 기록(decision records), 아키텍처 다이어그램을 Markdown이나 Mermaid 같은 LLM 파싱 가능 포맷으로 소스 컨트롤에 추가해야 함
- "컨텍스트가 왕(Context is king)"
PR 이 죽은 이유는 PR 그 자체보다는 Vibe coder 들의 방만한 커뮤니케이션 때문인 것 같습니다.
어떤 flow 로 구현했는지, 다른 방법은 뭐가 있었고 왜 채택하지 않았는지, 왜 package.lock 이 바뀌어야 하는지. 전부 먼저 이야기해야하는것들 아닌가?
PR Description에 써놓으면 될 것을 굳이구태어 묻게 만드는 코더들이 죽는 것이 더 나아보이네요.
동감합니다. 과거 PR은 내가 만든 결과물을 내가 책임진다는 느낌이 있었지만,
Vibe coder의 PR은 "내가 뭘 만들었는지도 모르겠고 어쨌든 결과물은 있으니 니가 평가해서 문제점을 찾아라" 같습니다.