# 풀 리퀘스트의 환상: AI 시대, 왜 PR은 개발자에게 애물단지로 취급 받게 되었나?

> Clean Markdown view of GeekNews topic #26961. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26961](https://news.hada.io/topic?id=26961)
- GeekNews Markdown: [https://news.hada.io/topic/26961.md](https://news.hada.io/topic/26961.md)
- Type: news
- Author: [flamehaven01](https://news.hada.io/@flamehaven01)
- Published: 2026-02-24T15:15:41+09:00
- Updated: 2026-02-24T15:15:41+09:00
- Original source: [flamehaven.substack.com](https://flamehaven.substack.com/p/the-pull-request-illusion-how-ai)
- Points: 10
- Comments: 2

## Summary

AI 시대의 **풀 리퀘스트(PR)**는 더 이상 ‘이해 전달 장치’로 작동하지 못하고 있습니다. 생성 속도를 폭발적으로 높인 AI 덕분에 코드 제출은 쉬워졌지만, 그 의도와 판단을 해석할 리뷰어의 시간과 맥락은 따라가지 못합니다. PR의 본질이 코드 승인 절차가 아니라 ‘책임 이전의 계약’이었다는 점을 되새기며, 이제는 게이트의 기준을 품질 검증이 아닌 **설명 가능성**으로 다시 정의해야 할 시점입니다.

## Topic Body

#### 전체 요지  
- “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 시대의 핵심 질문: “코드가 돌아가나?”보다, **“이 코드를 설명할 수 있나?”**  
- 이 질문이 생산성의 장애물이 아니라, 소프트웨어의 마지막 방어선을 지키는 최소 조건

## Comments



### Comment 51944

- Author: jdjdjd
- Created: 2026-02-26T13:51:47+09:00
- Points: 1

리뷰이는 딸깍하고, 리뷰어만 머리를 쥐어짜는, 책임 전가를 넘어 업무를 아예 떠넘기는 수단이 되었어요.

### Comment 51894

- Author: gaorida
- Created: 2026-02-25T18:51:13+09:00
- Points: 1

매우 공감하는 글입니다.  
  
저는 팀원들이 AI 가 만든 코드를 PR 로 올라오는것을 보며 지난 몇달간 너무 괴로웠고 이를 개선하기 위한 많은 방법을 도입해보고 있습니다.  
  
본문에서 다룬 PR 의 범위를 한정짓는것과 더불어 무엇을 리뷰할것인가를 고민하고 있습니다.  
코드를 리뷰하는게 아니라 의도를 리뷰하는 코드 리뷰를 고민하고 있습니다