풀 리퀘스트의 환상: AI 시대, 왜 PR은 개발자에게 애물단지로 취급 받게 되었나?
(flamehaven.substack.com)전체 요지
- “PR 제도 자체의 사망선고”가 아니라, AI 시대에 PR이‘이해 전달 장치’로 더 이상 작동하지 않는 현실을 다룸.
- 핵심 문제는 코드 품질 이전에, 코드와 함께 해야 할 맥락·의도·판단이 PR을 통해 전달되지 않는 상태가 커지게 된 것.
- 결론적으로 PR의 본질은 여전히 유효하지만, 운영 방식(게이트 조건)을 바꾸지 않으면 방어선 역할을 못 하게 됨.
1. 문제 제기: PR은 왜 흔들리는가
- PR 실패 원인을 “리뷰어가 게을러져서”로 보면 문제를 잘못 본 것.
- 실제 원인은 PR Review가 더 이상 이해 전달을 하지못하는 현상이 누적. 즉, 리뷰어(개발자)가 PR의 의도와 맥락을 이해 못함.
- AI는 PR 생성 비용을 급격히 낮추지만, 기존 비대칭(생성은 빠름, 검토는 느림) 을 증폭시킴.
2. PR의 원래 역할: 코드 승인 절차가 아니라 책임 이전의 계약
- PR은 단순히 코드 문법/테스트 통과를 보는 절차가 아니었음.
- 작성자는 “왜 이렇게 만들었는지 설명할 수 있음”을 암묵적으로 약속하는 구조였음.
- 리뷰어는 코드 자체뿐 아니라 그 뒤의 판단과 설계 의도까지 검토하는 역할.
- 즉 머지(Merge)버튼은 단순 코드 승인 버튼이 아니라, 팀이 그 변경의 책임을 함께 지겠다는 사회적 합의 결정이었음.
3. 기존에도 게이트는 이미 취약했음
- 오픈소스는 원래부터 PR 구조의 취약점을 가장 크게 드러내는 환경이었음.
- 유지보수자의 정신적, 육체적 피로, 맥락의 격차, 기여자 다양성 등으로 인해 PR이 형식적 승인으로 흐르기 쉬운 구조였음.
- xz Utils 백도어 사태는 자동화 실패라기보다, 번아웃된 인간 게이트가 공격 표면이 되는 방식을 보여준 사례.
즉 AI 이전에도 PR 게이트는 fragile(취약)했으며, 이미 한계 신호가 누적되고 있었음.- xz Utils 백도어 사태: 2년이 넘는 장기간 신뢰를 구축한 기여자가 PR을 통해 백도어를 삽입한 오픈소스 공급망 공격 사건.
4. AI가 만든 변화: PR 홍수와 리뷰 비대칭의 폭발
- AI 코딩 도구로 인해 PR 생성 속도와 양이 급증.
- 반면 리뷰는 여전히 사람의 시간·집중력·맥락 이해에 의존.
- 결과적으로 더 많은 코드, 더 큰 PR, 더 긴 리뷰 시간, 더 많은 incident로 이어지는 패턴이 나타남.
- 이는 “생산성 향상” 자체를 부정하는 것이 아니라, 거버넌스 없이 가속만 생긴 상태가 오히려 독이 될 수 있음을 경고.
5. 더 깊은 문제: 동작하지만 아무도 설명 못 하는 코드
- AI 코드의 위험은 “바로 깨지는 코드”만이 아님
- 테스트 통과·컴파일 성공 이후에도, 왜 그렇게 작성됐는지 설명이 비어 있는 코드가 쌓이는 것이 더 큰 문제.
- 시간이 지나 장애가 나면 팀은 수정을 하는 것이 아니라, 의도 없는 코드를 추측하며 해석하게 됨.
- 이는 일반적인 버그와 달리, 설계 판단의 흔적/책임 주체가 없는 상태라는 점에서 더 위험.
6. 숨은 핵심 개념: 정보 공백을 AI가 그럴듯하게 메움
- AI는 모르는 것을 드러내기보다, 그럴듯한 코드로 빈칸을 메우는 경향이 있음.
- 문제는 이 빈칸(숨겨진 가정, 미확인 제약)이 PR 단계에서 잘 보이지 않는다는 점.
- 그래서 “코드가 돌아감/문서가 그럴듯함/체크 통과함”만으로는 안전성을 보장할 수 없게됨.
- 결국 PR 게이트에서 확인해야 할 것은 컴파일 여부가 아니라, 이 변경의 reasoning(왜/무엇을/어떤 제약 하에)이 존재하는지 검수가 필요.
7. OpenClaw 사례가 보여준 것: PR이 감당 못 하는 규모와 속도
- 글은 OpenClaw가 PR 붕괴 현상이 압축 재생된 대표적 사례로 언급.
- OpenClaw(초기명 Clawdbot)는 Peter Steinberger가 2025년 11월경 시작한 개인 성격의 실험/플레이그라운드 프로젝트였음.
- 짧은 기간(약 10주) 동안 폭발적으로 성장하며 대규모 사용자·기여·외부 관심이 몰렸음.
- 그 과정에서 보안 이슈, 악성 스킬/기여, 검토 부담 증가가 겹치며 개인/소규모 유지보수 체계가 감당하기 어려운 상태에 놓임.
- 그는 이후(2026년 2월) 프로젝트 관련 회고를 남기며, 더 안전하게 만들기 위해 더 많은 구조·리소스·최신 연구 접근이 필요함을 언급
- 그리고 프로젝트를 넘기고 OpenAI로 합류(이직)함.
- 글은 이 지점을 개인 비판이 아니라, “뛰어난 프로토타입 성공”과 “안전한 범용 인프라 운영” 사이의 간극을 보여주는 장면으로 해석
- 또한, 핵심은 구현 실수 1건보다, 기여 규모·속도·의도 다양성이 인간 검토 능력을 초과한 구조로 봄.
- 유지보수자가 보안 개선을 계속해도, 노출 속도와 수습 속도는 같은 경주가 아니었음.
- 즉 실패 원인은 “못 만들어서”가 아니라, 원래 개인/로컬 신뢰 모델로 설계된 게이트가 글로벌 규모를 못 버틴 것.
8. GitHub 설정 변경의 의미: 기능 추가가 아니라 경고 신호
- GitHub가 2026년 2월 13일 PR 비활성화 옵션기능을 추가함을 공식 발표.
- 하지만 저자는 이를 단순히 편의 기능추가로 보기보다 “일부 저장소에서 PR 자체가 운영 리스크가 된 현실”에 대한 조용한 인정으로 해석.
- 즉 플랫폼도 더 이상 “PR은 항상 선”이라는 전제를 유지하기 어려워졌다는 신호로 해석할 필요성이 있음을 강조.
9. 글의 실질 결론: PR을 버리자는 것이 아니라, 게이트를 다시 정의해야함.
- AI 코드 도구 개발을 중단하자는 주장이 아님.
- 오히려 질문은 “AI를 쓰느냐”가 아니라, "작동하는 게이트" 없이 쓸 것이냐임.
- 필요한 것은 규칙 나열보다, 설명 가능성·설계 선행·미확인 사항 명시·유지보수자 거절 권한·추적성 확보 같은 운영 원칙.
- 이유를 추적할 수 없는 PR은 팀이 소유하는 지적 자산이 아니라, 팀을 지배할 부채가 됨이라는 점.
10. 한 줄 정리
- PR의 목적은 코드 통과가 아니라, 이해와 책임을 함께 넘기는 것.
- AI 시대의 핵심 질문: “코드가 돌아가나?”보다, “이 코드를 설명할 수 있나?”
- 이 질문이 생산성의 장애물이 아니라, 소프트웨어의 마지막 방어선을 지키는 최소 조건