오픈 소스 메인테이너들이 AI 생성 Pull Request로 인해 고통받고 있습니다. 다음은 기업 팀 차례입니다.

이 기사는 Signadot에서 읽을 수 있습니다.

오픈 소스 생태계에서 무언가 망가지고 있으며, 이는 조직 내에 코딩 에이전트 (Coding Agents) 도입을 추진하는 모든 엔지니어링 리더들에게 경종을 울려야 할 문제입니다.

지난 1년 동안 오픈 소스 메인테이너 (Maintainers)들은 저품질의 AI 생성 Pull Request (PR) 홍수에 압도되어 왔습니다. 터무니없는 설명이 붙은 장황한 변경 사항들, 질문을 받았을 때 제출자가 설명하지 못하는 기여(Contributions), 겉보기에는 그럴싸해 보이지만 리뷰 과정에서 무너지는 코드들이 쏟아지고 있습니다.

잘 알려진 Python 프로젝트 생태계인 Jazzband 컬렉티브는 올해 완전히 운영을 중단해야 했습니다. 해당 프로젝트의 리드 메인테이너는 지속 불가능한 수준의 AI 생성 스팸 PR 및 이슈(Issues)를 주요 원인으로 꼽았습니다.

다른 프로젝트들도 동일한 압박을 느끼고 있습니다. Godot 게임 엔진을 유지 관리하는 Remi Verschelde는 AI 슬롭 (AI slop, AI가 생성한 저품질 콘텐츠)을 분류(Triaging)하는 작업이 진을 빼고 사기를 저하시킨다고 설명했습니다. curl의 창시자인 Daniel Stenberg는 버그 바운티 (Bug bounty) 프로그램이 저노력 AI 제출물들의 자석이 되었기 때문에 프로그램을 취소했습니다.

패턴은 일관적입니다. 메인테이너들은 결코 제출되지 않았어야 할 코드를 평가하는 데 불균형적으로 많은 시간을 소비하고 있으며, 이는 진정한 기여를 밀어내고 번아웃 (Burnout)을 가속화하고 있습니다.

이것은 단지 오픈 소스만의 문제가 아닙니다. 이는 기업 엔지니어링 팀에 닥쳐올 미래의 예고편이며, 대부분의 기업은 이에 대한 준비가 되어 있지 않습니다.

아무도 대비하지 않는 비대칭성

핵심 문제는 처리량의 비대칭성 (Throughput asymmetry)입니다. AI 코딩 에이전트 (AI coding agents)는 코드 생성을 극적으로 더 저렴하고 빠르게 만들었습니다. 에이전트와 함께 작업하는 개발자는 하루에 5개, 6개 또는 그 이상의 Pull Request를 생성할 수 있습니다.

코딩 에이전트 (coding agent)를 처음 사용하는 비기술직 팀원도 단 몇 분 만에 작동하는 것처럼 보이는 코드를 생성할 수 있습니다. 하지만 그 코드를 검토(review), 검증(validation), 통합(integration)하는 과정은 전혀 빨라지지 않았습니다. 무보수 자원봉사 메인테이너 (maintainer)의 60%가 이미 이를 따라가는 데 어려움을 겪고 있습니다. 이제 그 규모가 배가되었습니다.

“AI 코딩 에이전트는 코드 생성을 극적으로 저렴하고 빠르게 만들었습니다… 하지만 그 코드를 검토, 검증, 통합하는 과정은 전혀 빨라지지 않았습니다.”

오픈 소스 메인테이너들은 자신들의 저장소 (repository)가 전 세계에 공개되어 있기 때문에 이러한 비대칭성을 가장 극단적인 형태로 경험합니다. 누구나 공개된 GitHub 이슈 (issue)를 에이전트에 지정하여 단 몇 초 만에 그럴싸해 보이는 풀 리퀘스트 (pull request)를 생성할 수 있습니다.

한 기여자가 표현했듯이, 만약 그것이 정말로 메인테이너들이 원하는 것이었다면 그들은 스스로 그것을 할 수 있었을 것입니다. 기여의 가치는 결코 코드 그 자체에만 있지 않았습니다. 그 이면에 담긴 이해, 그것을 검증하는 테스트 (testing), 그리고 그것을 형성하는 인간의 판단 (human judgment)에 있었습니다.

기업 팀 (Enterprise teams) 또한 기업의 장벽 뒤에서 동일한 구조적 문제에 직면해 있습니다. 조직이 코딩 에이전트 도입을 의무화할 때, 그들은 파이프라인 (pipeline)의 한쪽 끝은 가속화하면서 다른 한쪽은 변하지 않은 채로 남겨둡니다. 검토자 (reviewer)는 해당 코드가 실제로 작동하는지, 올바르게 통합되는지, 예외 상황 (edge cases)을 처리하는지, 그리고 회귀 (regressions)를 유발하지 않는지를 결정해야 하는 모든 부담을 떠안게 됩니다. Agoda의 연구에 따르면, 숙련된 개발자들은 AI 도구를 사용할 때 실제로 19% 더 느려졌는데, 이는 주로 연구자들이 '이해 부채 (comprehension debt)'라고 설명한 현상 때문이었습니다. 이는 AI가 생성한 코드가 축적됨에 따라 개발자들이 시간이 지날수록 자신의 코드베이스 (codebase)를 이해하는 정도가 낮아지는 현상을 말합니다. 470개의 오픈 소스 풀 리퀘스트를 분석한 CodeRabbit 분석에 따르면, AI가 공동 작성한 풀 리퀘스트에서는 인간이 전적으로 작성한 풀 리퀘스트보다 약 1.7배 더 많은 이슈 (issues)가 발견되었습니다.

이 수학적 계산은 검토자(reviewer)에게 유리하게 작용하지 않습니다. 그리고 복잡성이 증가할수록 수치는 더욱 악화됩니다.

AI 보조 리뷰(AI-assisted review)가 충분하지 않은 이유

AI가 생성한 코드의 급증에 대한 자연스러운 대응은 코드 리뷰를 위해 AI 에이전트(AI agents)를 배치하는 것입니다. 풀 리퀘스트(pull requests)를 요약하고, 이슈를 표시하며, 품질을 평가하는 도구들이 빠르게 확산되고 있습니다. 단순한 변경 사항의 경우, 이러한 도구들로 충분할 수도 있습니다. AI 리뷰어는 스타일 위반을 잡아내고, 안티 패턴(anti-patterns)을 발견하며, 한 줄씩 훑어보는 인간보다 더 빠르게 명백한 버그를 찾아낼 수 있습니다.

하지만 수십 개의 상호 의존적인 서비스가 있는 클라우드 네이티브 분산 시스템(cloud-native distributed systems)의 경우, AI 보조 리뷰는 기존의 CI 파이프라인(CI pipelines)과 동일한 벽에 부딪힙니다. 두 방식 모두 해당 변경 사항이 문맥(context) 내에서 실제로 작동하는지 알려줄 수 없기 때문입니다. 하나의 서비스에 대한 수정 사항은 고립된 상태에서는 올바르게 보일 수 있지만, 하위 의존성(downstream dependency)과의 계약(contract)을 조용히 깨뜨릴 수 있습니다. 에이전트가 생성한 리팩터링(refactor)은 실제 트래픽 패턴 하에서만 나타나는 레이스 컨디션(race condition)을 유발할 수도 있습니다.

이러한 문제들은 프로덕션(production)과 유사한 환경에서 코드를 실행하는 것을 요구하며, 인간이든 AI 기반이든 그 어떤 정적 분석(static analysis)도 이를 대체할 수 없습니다.

“검증 병목 현상(validation bottleneck)은 대부분의 팀이 깨닫는 것보다 더 이른 단계, 즉 코드가 작성된 시점과 리뷰어가 이를 확신을 가지고 평가할 수 있는 시점 사이의 간극에 존재합니다.”

검증 병목 현상은 대부분의 팀이 깨닫는 것보다 더 이른 단계, 즉 코드가 작성된 시점과 리뷰어가 이를 확신을 가지고 평가할 수 있는 시점 사이의 간극에 존재합니다. 만약 개발자가 하루에 6개의 풀 리퀘스트를 생성하고 각 리퀘스트마다 30분 이상의 수동 검증이 필요하다면, 그들은 소프트웨어를 구축하기보다 배포 대기열(deployment queue)을 관리하는 데 대부분의 시간을 소비하게 됩니다. 에이전트는 작성을 빠르게 만들었습니다. AI 리뷰는 분류(triage)를 빠르게 만들었습니다. 하지만 그 이후의 모든 하류(downstream) 과정은 여전히 느린 상태로 남아 있습니다.

오픈 소스 위기가 실제로 우리에게 말해주는 것

오픈 소스 저장소(repositories)는 누가 기여하는지 통제할 수 없기 때문에, AI로 가속화된 코드 생성(code generation)의 여과되지 않은 온전한 힘을 경험하고 있습니다. 메인테이너(Maintainers)들은 더 엄격한 기여자 정책, 평판 시스템, Pull Request(PR)를 차단하거나 필터링하는 플랫폼 도구 등을 혼합하여 대응해 왔으며, 어떤 경우에는 단순히 프로젝트를 종료하기도 했습니다.

기업 팀은 누가 코드를 제출하는지에 대해 더 많은 통제권을 가지고 있지만, 제출한 사람이 그 코드를 이해하고 있는지에 대한 가시성(visibility)은 더 낮습니다. 내부 개발자나 비기술적 팀원이 에이전트(agent)를 통해 생성한 PR은 리뷰 대기열(review queue)에서 시니어 엔지니어가 정성스럽게 작성한 변경 사항과 똑같아 보입니다. 추가적인 맥락(context) 없이는 리뷰어가 이 둘을 구분하거나, 코드가 주장하는 대로 작동하는지 빠르게 검증(validate)할 방법이 없습니다.

이 위기에 대한 오픈 소스의 대응은 시사하는 바가 큽니다. 폭풍을 견뎌내고 있는 프로젝트들은 단순히 정책을 추가하는 것에 그치지 않습니다. 그들은 입증의 부담을 다시 기여자에게 돌리는 메커니즘에 투자하고 있습니다. 즉, 리뷰어에게 코드가 작동하지 않음을 증명하라고 요구하는 대신, 코드가 작동한다는 것을 증명하도록 요구하는 것입니다.

기업은 어떻게 대응해야 하는가

코드 생성(code generation)과 코드 검증(code validation) 사이의 간극을 메워야 합니다. 모든 Pull Request는 단순한 주장(claim)이 아니라, 그것이 작동한다는 증거와 함께 도착해야 합니다.

첫째, 검증(validation)은 개발 루프(development loop) 안으로 이동해야 합니다. 개발자와 에이전트는 PR이 열리기도 전에 실제 서비스 의존성(dependencies)에 대해 변경 사항을 검증할 수 있는, 격리된 프로덕션 유사 환경(production-like environments)에 접근할 수 있어야 합니다. 리뷰는 작동하는 코드의 증거와 함께 시작되어야 합니다.

둘째, 리뷰 프로세스(review process)가 진화해야 합니다. 에이전트(agents)가 시간당 수천 줄의 코드를 생성할 때, 한 줄씩 검토하는 방식은 확장성(scale)을 갖출 수 없습니다. 이제는 코드를 검사하는 것에서 동작의 증거를 평가하는 것으로 전환해야 합니다. 해당 변경 사항이 현실적인 서비스 상호작용(service interactions) 환경에서 제대로 작동했는가? 동작이 명세(specification)와 일치하는가? 를 확인해야 합니다.

셋째, 조직은 AI가 생성한 코드를 초안(draft material)으로 취급해야 합니다. 이는 AI가 작성한 변경 사항에 태그를 달고, 결함률(defect rates)을 별도로 추적하며, 제출자가 코드를 완전히 이해하지 못할 수도 있다는 점을 고려한 리뷰 워크플로우(review workflows)를 구축해야 함을 의미합니다.

마지막으로, 책임(accountability)을 AI에 외주 줄 수는 없습니다. 에이전트를 가이드하는 엔지니어는 배포되는 결과물에 대해 여전히 책임을 집니다. 이는 엔지니어가 리뷰어에게 문제 발견을 의존하기보다, 확신을 가지고 PR(Pull Request)을 제출할 수 있도록 개발 루프(development loop) 내에서 에이전트가 생성한 코드를 검증할 수 있는 도구를 제공해야 함을 의미합니다.

경고는 이미 시작되었습니다

오픈 소스 저장소(repos)는 카나리아(canary)와 같습니다. 오픈 소스의 개방성은 저렴한 코드 생성의 모든 외부 효과(externality)를 가장 먼저, 그리고 가장 눈에 띄게 흡수한다는 것을 의미합니다. 하지만 근본적인 문제, 즉 코드를 생성하는 속도와 이를 검증하는 속도 사이의 불균형은 오픈 소스만의 문제가 아닙니다. 이는 구조적인 문제입니다.

에이전트가 생성한 결과물을 검증할 인프라에 동일하게 투자하지 않은 채 코딩 에이전트에 막대한 투자를 하는 기업 조직은, 일을 만드는 속도는 빨라지지만 일을 끝내는 속도는 전혀 빨라지지 않는 파이프라인을 구축하고 있는 것입니다. PR은 쌓여갈 것이고, 리뷰 시간은 늘어날 것이며, 결함률은 치솟을 것입니다. 에이전트의 결과물을 리뷰하는 임무를 맡은 엔지니어들은 오늘날 오픈 소스 메인테이너들이 겪고 있는 것과 동일한 이유로 번아웃(burnout)을 겪게 될 것입니다.

이 격차를 줄이기 위한 도구들은 부분적으로 존재합니다. 격리된 프리뷰 환경(preview environments), 자동화된 엔드 투 엔드 검증(end-to-end validation), 더 스마트한 리뷰 워크플로우, 그리고 에이전트가 생성한 변경 사항에 대한 더 나은 관측성(observability)은 모두 해결 가능한 문제입니다. Signadot과 같은 솔루션은 코드가 리뷰어에게 도달하기 전에 실제 서비스 의존성(service dependencies)을 바탕으로 변경 사항을 검증할 수 있도록 이미 팀들을 돕고 있습니다.

문제는 기업들이 오픈 소스 메인테이너(open-source maintainers)들이 실시간으로 우리에게 가르쳐주고 있는 교훈을 배울 것인가, 아니면 스스로 고통을 느낄 때까지 기다렸다가 유능한 엔지니어와 경쟁 우위를 잃는 위험을 감수할 것인가 하는 점입니다. 백로그(backlog)가 감당할 수 없는 수준이 되기 전에 이러한 역량에 투자하는 것이, 코딩 에이전트(coding agents)로부터 이득을 얻는 팀과 위기에 처한 팀을 가르는 핵심적인 차별화 요소가 될 것입니다.