풀 리퀘스트는 죽었다, 풀 리퀘스트 만세
(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은 "내가 뭘 만들었는지도 모르겠고 어쨌든 결과물은 있으니 니가 평가해서 문제점을 찾아라" 같습니다.
PR 하나에 파일이 500개씩 바뀌는데, 제출한 사람은 30분 안에 리뷰 해주지 않았다고 불만이 많네요. 설명란에는 대여섯줄 적어주고 땡이니, 그냥 이거 믿고 승인 해줘야 하나...?
테스트 다 했지?
네
그래 잘 하자