에이전트 PR(Pull Request) 금지가 오픈 소스를 구원하지 못하는 이유

거대한 풀 리퀘스트(Pull Request, PR)는 예의에 어긋난다는 것이 암묵적인 규칙입니다. 전통적으로 애자일 (Agile) 팀은 개발자가 로직을 다루기 쉽고 동료들이 실제로 리뷰할 수 있도록 기능을 관리 가능한 단위로 나눕니다. 하지만 에이전트 (Agent)가 도입되면서 상황이 변했습니다. 이제 개발자들은 아주 짧은 시간 안에 엔드 투 엔드 (End-to-end) 기능을 배포하고 있지만, 그 결과물은 종종 열어보는 것조차 의욕을 꺾는, 감당할 수 없는 코드의 벽이 되어 나타납니다. 이러한 "에이전트 PR (Agent-PRs)"은 리뷰어의 눈을 흐릿하게 만들어, 미묘한 논리적 결함을 놓친 채 빠르게 "LGTM (Looks Good To Me)"를 남기게 할 가능성이 매우 높습니다. 이러한 긴장감이 너무 높아진 나머지, 일부 오픈 소스 (Open Source) 유지 관리자들은 에이전트가 작성한 기여를 아예 금지하는 조치를 취하고 있습니다. 풀 리퀘스트 (Pull Request)가 발명되기 전에는 기여자들이 유지 관리자에게 코드 변경 사항을 이메일로 보내거나, 유지 관리자에게 기여자의 저장소(Repository)에서 업데이트를 가져가 달라고 요청하곤 했습니다. 2008년, GitHub은 풀 리퀘스트를 도입하여 팀이 변경 사항을 병합(Merge)하기 전에 제안하고, 토론하고, 리뷰할 수 있는 구조화된 방식을 제공했습니다. 거의 20년 동안 풀 리퀘스트는 완벽한 워크플로 (Workflow)를 제공해 왔습니다. 하지만 이제 협업을 가능하게 했던 바로 그 구조가 AI가 생성하는 속도의 무게를 견디지 못하고 균열이 가고 있습니다. Rémi Verschelde나 Jeff Geerling 같은 저명한 오픈 소스 개발자들은 소셜 미디어를 통해 우려를 표명해 왔습니다. 하지만 그들의 정서만이 유일한 것은 아닙니다. 많은 개발자가 이와 같이 느끼고 있으며, 쏟아지는 기여물에 직면하여 많은 이들이 AI 보조 기여를 완전히 금지함으로써 코드베이스 (Codebase)와 정신 건강을 보호하기 위한 극단적인 조치를 취하기로 결정했습니다.

하지만 더 많은 개발자들이 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 AI를 사용하도록 장려됨에 따라, AI 보조 풀 리퀘스트(AI-assisted pull requests)로부터 도망치는 것은 잠재적으로 가치 있는 기여자들을 위한 문을 닫아 오픈 소스에 해로울 뿐입니다. 제 전 직장 상사인 Angie Jones는 문을 닫는 것이 해결책이 아니라고 주장합니다. 대신, 그녀는 에이전트와 인간 모두를 위한 더 나은 가이드라인을 옹호합니다. 그녀가 맞습니다. 문을 닫는 것은 답이 아니며, 명확한 가이드라인이 한 걸음 전진입니다. 하지만 더 나은 가이드라인이 있더라도 검토 과정은 근본적으로 변하지 않은 채로 남아 있습니다. 관리자들은 여전히 거대한 PR들을 응시하며 에이전트가 무엇을 생성했는지 이해하려고 애쓰고 있습니다. 이 문제를 해결하기 위해 GitHub는 최근 관리자들이 기여 제한(contribution limits)을 설정할 수 있는 기능을 출시했습니다. 이는 외부 기여자에게는 PR 상한선(PR cap)을, 신뢰하는 사람들에게는 허용 목록(allowlist)을 제공합니다. [IMG:N] 많은 관리자들이 이 출시 기능에 대해 기대하고 있지만, PR 상한선은 단기적인 임시방편일 뿐입니다.

저는 이것이 좋은 조치라고 생각하지만, 우리 업계는 코드 리뷰 (Code Review)를 처리하는 방식에 대한 전면적인 개편이 필요하다고 봅니다. 오픈 소스 AI 에이전트 (Agent)인 goose의 유지 관리자 (Maintainer)로서, 저는 2025년과 2026년 동안 수많은 풀 리퀘스트 (Pull Request, PR)를 검토하며 시간을 보냈습니다. 저는 누가 기여할 수 있는지를 제한하고 싶지 않습니다. 저는 모든 사람이 기여할 수 있기를 바랍니다. 목표는 외부 기여자가 에이전트 (Agent)를 사용하여 코드를 작성하더라도, PR의 맥락 (Context)을 빠른 속도로 이해하는 것입니다. 오픈 소스에는 인간이 작성한 작업과 에이전트가 작성한 작업을 모두 지원할 수 있도록 구축된 인프라 (Infrastructure)가 필요합니다. 제가 Entire에 합류한 이유는 우리의 신념이 일치했기 때문입니다. 즉, 우리는 오픈 소스의 구조적 붕괴를 해결해야 한다는 것입니다. 현재 우리는 에이전트가 지원한 코드 변경 사항 뒤에 숨겨진 맥락을 포착하는 기록 시스템 (System of Record)을 제공하는 CLI를 구축했습니다. 이 기록은 저장되며, 이는 우리 업계가 다음과 같은 방향으로 나아가는 데 도움을 줄 수 있는 새로운 개발자 도구 시대의 기준점 역할을 합니다:

• 코드 리뷰 (Code Review)에서 의도 리뷰 (Intent Review)로의 전환: 이는 리뷰어가 500줄의 구문 (Syntax)을 분석하는 대신, 프롬프트 (Prompt), 세션 기록 (Session Transcript), 그리고 주요 결정 뒤에 있는 추론 (Reasoning)을 조사함으로써 의도 (Intent)부터 파악하기 시작함을 의미합니다. 이를 통해 리뷰어는 해결되고 있는 문제와 그 과정에서 올바른 호출 (Calls)이 이루어졌는지에 집중할 수 있습니다.
• '이유(Why)'를 검색할 수 있는 능력: 개발자와 유지 관리자 (Maintainer)는 왜 변경 사항이 특정 방식으로 이루어졌는지 물을 수 있으며, 에이전트 세션 맥락 (Agent Session Context)에서 직접 도출된 답변을 받을 수 있습니다.
• AI 네이티브 속도 (AI-native Velocity)를 위한 인프라: 오픈 소스 커뮤니티는 트래픽의 무게에 짓눌리거나 플랫폼 중단을 일으키지 않으면서, 인간과 에이전트의 방대한 기여량을 지원할 수 있는 토대가 필요합니다.

우리가 구축하고 있는 것의 전체 범위를 탐색하려면, 우리의 비전에 대해 읽어보고 우리가 어디로 향하고 있는지 더 자세히 알아볼 수 있습니다. 오픈 소스는 혁신이 일어나는 곳입니다. 대기업들이 수천 개의 오픈 소스 의존성 (Dependencies)에 의존하며 번창할 수 있는 것도 바로 이 때문입니다.

하지만 두려움이나 피로감 때문에 외부 기여 (External contributions)를 차단한다면, 커뮤니티는 사라지고 생태계는 정체될 위험에 처하게 됩니다. 개발자들은 에이전트 (Agents) 덕분에 기여할 수 있다는 자신감을 얻었으며, 진심으로 기여하는 것에 열광하고 있습니다. 우리는 AI 네이티브 라이프사이클 (AI-native lifecycle)을 위해 설계된 인프라를 구축함으로써 이러한 모멘텀 (Momentum)을 수용해야 합니다.