외부 코드 기여를 닫는 AI 프로젝트들, 협업의 중심은 어디로 옮겨갈까요

코드를 보내주셔도 받지 않겠습니다

누군가 자신이 쓰는 소프트웨어의 문제를 발견하고, 직접 고쳐서 보내왔다고 생각해 보겠습니다. 프로젝트를 운영하는 사람에게는 반가운 일일 것 같습니다. 문제도 찾고 해결책까지 가져왔으니까요.

그런데 그 수정안을 읽고, 원래 설계와 맞는지 확인하고, 다른 기능에 문제가 생기지 않는지 살피는 데 시간이 많이 든다면 어떨까요. 더구나 운영팀이 자기 AI로 수정안을 만드는 편이 더 익숙하고 검토하기도 쉽다면, 외부에서 완성된 코드를 받는 방식의 이점은 달라질 수 있습니다.

Latent Space에 2026년 9월 1일 실린 Richard MacManus의 PRs NOT Welcome: How Top AI Open Source Projects Are Managing Thousands of Contributors는 이런 변화를 다룹니다. 제목을 풀면, 수많은 기여자를 상대하는 주요 AI 오픈소스 프로젝트들이 왜 외부의 코드 수정 제안을 받지 않으려 하는지를 다룬 글입니다.

여기서 PR은 작성한 코드 변경을 프로젝트에 반영해 달라는 제안입니다. Pull Request의 줄임말입니다. 제안을 받으면 메인테이너, 즉 프로젝트를 지속해서 관리하는 사람이 내용을 검토합니다. 받아들이기로 하면 변경 내용을 정식 코드에 합칩니다. 이를 병합이라고 합니다.

기사가 보여주는 변화는 하나로 묶기보다 구분해서 읽어야 합니다. Vercel의 AI SDK와 Astro는 AI 에이전트가 요청 분류와 문제 해결을 돕는 사례입니다. AI 에이전트는 주어진 목표에 따라 도구를 사용하며 여러 작업을 수행하는 AI를 뜻합니다. Flue와 tldraw는 외부 PR을 자동으로 닫기까지 합니다. 네 프로젝트가 모두 외부 코드 기여를 중단했다는 뜻은 아닙니다.

제가 이 글에서 눈여겨본 것은 외부 기여를 닫는 행동 자체보다, 그 뒤에 있는 질문입니다. 코드를 만드는 일이 쉬워지면, 프로젝트가 사람들에게 가장 필요로 하는 기여는 무엇이 될까요.

수정안이 많아져도 운영자의 일은 줄지 않을 수 있습니다

기사는 외부 PR을 받지 않는 이유 중 하나로 AI가 생성한 기여물의 증가를 듭니다. Flue의 기여 안내는 프로젝트에 깊이 관여하지 않은 채 AI로 만들어 보내는 낮은 품질의 PR을 문제로 지목합니다.

다만 이것을 모든 외부 AI 코드의 품질이 나쁘다는 주장으로 확대할 필요는 없습니다. 본문에는 외부 코드와 내부 에이전트의 코드를 같은 조건에서 비교한 품질 실험이 나오지 않습니다. 더 직접적인 쟁점은 누가 만든 코드를 어떤 맥락에서 검토해야 하는가입니다.

비유하면 이런 상황입니다. 집을 수리하는 사람에게 외부에서 만든 문짝이 계속 도착합니다. 문짝 자체가 잘 만들어졌더라도 문틀에 맞는지, 경첩은 호환되는지, 다른 설비와 충돌하지 않는지 확인해야 합니다. 때로는 문이 잘 닫히지 않는다는 증상과 정확한 치수를 전달받아, 익숙한 작업 방식으로 직접 고치는 편이 수월할 수 있습니다.

코드도 비슷합니다. 완성된 수정안은 검토의 출발점이지만, 그 자체로 프로젝트의 일이 끝났다는 뜻은 아닙니다. 작성자가 들인 시간과 운영자가 절약하는 시간도 반드시 같지는 않습니다.

기사 속 프로젝트들은 이 간격을 줄이려 합니다. 외부에서 들어온 코드를 모두 검토하기보다, 먼저 해결할 문제를 정리하고 자신들이 설정한 에이전트에게 구현을 맡기는 방식입니다.

Vercel이 신뢰하는 것은 특정하게 설정하고 지켜본 에이전트입니다

Vercel의 AI SDK는 AI 기능을 만드는 데 쓰는 개발 도구 모음입니다. 기사에 따르면 이 프로젝트의 npm 주간 다운로드는 2,000만 회를 넘습니다. npm은 개발자가 소프트웨어 꾸러미를 배포하고 내려받는 도구입니다. 다운로드 횟수가 이용자 수와 같지는 않지만, 기사에서는 프로젝트의 규모를 보여주는 배경으로 제시합니다.

그만큼 들어오는 요청도 많았습니다. 기사에 인용된 Vercel의 설명에 따르면, 6월 말까지 열린 이슈는 1,000건을 넘었고 PR은 거의 800건에 이르렀습니다. 이슈는 버그 신고나 개선 요청 등을 기록하는 항목입니다. 운영팀이 처리해야 할 대기 작업이 상당히 쌓여 있었던 셈입니다.

Vercel은 이를 다루기 위해 소프트웨어 팩토리, 즉 여러 에이전트가 개발 작업을 나누어 수행하는 체계를 도입했습니다. 한 에이전트는 신고된 버그가 실제로 발생하는지 재현합니다. 다른 에이전트는 수정합니다. 또 다른 에이전트는 그 수정안을 검토합니다. 기사가 설명하는 일반적인 흐름에서는 마지막에 사람이 결과를 받아 병합합니다.

Vercel 엔지니어 Lars Grammel의 설명에서 중요한 대목은 신뢰가 생기는 방식입니다. 특정한 지시문으로 설정한 에이전트가 특정 종류의 버그를 과거에 잘 고쳐 왔다면, 그 설정을 신뢰하게 된다고 합니다. 지시문은 AI에게 작업 방식과 조건을 알려주는 문장입니다.

저는 이 설명을 어떤 조건에서 어떤 일을 잘하는지 알고 있는 작업 절차를 신뢰한다는 뜻으로 읽었습니다. 같은 AI를 사용하더라도 어떤 맥락을 주고, 어떤 작업을 맡기며, 어떤 검토를 거쳤는지에 따라 운영자의 판단은 달라질 수 있습니다.

외부 기여자가 보낸 코드에는 그 생성 과정에 대한 정보가 충분하지 않을 수 있습니다. 반면 운영팀은 직접 만든 에이전트 작업 절차의 설정과 과거 결과를 더 잘 알고 있습니다. Grammel은 이런 자체 구성이 검토 시간을 줄이는 데 도움이 될 수 있다고 설명합니다. 다만 기사에는 검토 시간이 정확히 얼마나 줄었는지는 제시되지 않습니다.

이 체계를 뒷받침하는 구성도 가볍지만은 않습니다. Grammel은 직접 만든 사용자 화면, 웹 애플리케이션, API, 실행 공간, 샌드박스를 소개합니다. API는 프로그램끼리 요청과 결과를 주고받는 연결 창구입니다. 샌드박스는 코드를 분리해서 실행하는 공간입니다. 시스템은 GitHub와 동기화되며 다른 작업을 자동으로 실행합니다.

투자자라면 이 대목을 살펴봐야겠습니다. 기사 속 사례는 좋은 지시문 하나를 입력하는 수준을 넘어섭니다. 작업을 나누고, 실행 환경을 제공하고, 결과를 다음 단계로 넘기는 운영 체계가 함께 필요합니다. 다만 이런 구성이 있다는 사실만으로 보안이나 신뢰성이 충분히 입증되었다고 보기는 어렵습니다. 기사에는 그 검증 결과가 담겨 있지 않습니다.

25~35%와 70~80%는 각각 무엇을 말할까요

기사에 따르면 Vercel은 소프트웨어 팩토리를 도입한 지 4주 만에, 병합하는 PR의 25~35%를 이 체계가 작성하고 이슈의 70~80%를 닫는다고 밝혔습니다.

두 숫자는 변화의 크기를 보여주지만, 서로 다른 일을 측정합니다.

병합된 PR 중 작성 비중은 정식 코드에 받아들여진 변경 제안 가운데 에이전트 체계가 작성한 몫을 말합니다. 전체 개발 업무의 25~35%가 자동화되었다거나 개발 인력이 그만큼 줄었다는 뜻은 아닙니다. PR마다 크기와 난도가 다를 수 있고, 문제를 정하거나 결과를 검토하는 사람의 일도 남아 있기 때문입니다.

이슈를 닫는 비중도 버그를 모두 수정한 비중과 같다고 단정하기 어렵습니다. 제공된 본문에는 닫힌 이슈의 유형과 처리 사유가 세분화되어 있지 않습니다. 예를 들어 중복 신고를 정리하는 일과 실제 오류를 고쳐 해결하는 일은 모두 대기 작업을 줄일 수 있지만, 같은 작업은 아닙니다. 숫자를 읽을 때 이렇게 구분해야 한다는 뜻이지, Vercel의 실제 처리 내역이 그렇다고 확인된 것은 아닙니다.

이 수치는 기사에 인용된 Vercel의 자체 설명입니다. 제공된 자료에는 독립적인 비교 검증이나 운영 비용, 수정 후 다시 문제가 생긴 비율이 없습니다.

저는 이 결과를 에이전트가 실제 유지보수 과정에 들어와 상당한 작업을 담당한다는 신호로 봅니다. 다만 이 숫자만으로 비용 절감률이나 장기적인 코드 품질까지 판단하지는 않겠습니다.

Astro가 되찾은 것은 매주 무엇을 할지 정하는 여유입니다

웹사이트를 만드는 기본 틀을 제공하는 Astro의 사례는 조금 다른 변화를 보여줍니다. 기사에서는 GitHub의 관심 표시인 스타가 6만 2,000개인 프로젝트로 소개됩니다. 이 수치는 이용자 수나 사업 실적을 뜻하지는 않습니다.

Astro를 만든 Fred Schott는 지난 5년 동안 팀이 처리하는 속도보다 이슈가 들어오는 속도가 더 빨랐다고 설명합니다. 그런데 최근 6개월 사이 상황이 크게 달라졌다고 말합니다.

Astro의 자동화는 들어온 요청을 분류하고, 문제를 재현하고, 봇이 제안한 수정안을 사용자가 확인하도록 돕습니다. 제가 특히 눈여겨본 것은 순서입니다. 운영팀이 살펴보기 전에 사용자에게 수정안 확인을 요청합니다.

문제를 겪은 사람은 실제 사용 환경을 알고 있습니다. 에이전트가 만든 수정안이 그 상황에서도 도움이 되는지 사용자가 먼저 확인한다면, 운영팀은 더 구체적인 정보로 다음 판단을 할 수 있겠지요. 이것은 기사에 나온 절차를 제가 해석한 내용입니다. 사용자 확인이 모든 검토를 대신하거나 모든 오류를 잡는다는 뜻은 아닙니다.

Schott가 묘사하는 결과는 단순히 쌓인 이슈가 줄었다는 데 그치지 않습니다. 팀은 계속 밀린 일을 덜어내는 상태에서 벗어나, 매주 들어온 이슈의 우선순위를 정하는 방식으로 일할 수 있게 되었다고 합니다. 그는 10년이 넘는 오픈소스 경험에서도 보지 못한 변화라고 설명합니다.

계속 쌓이는 편지 더미에서 급한 것만 꺼내 읽다가, 그 주에 도착한 편지를 제때 읽고 무엇에 답할지 정할 수 있게 된 상황에 가깝습니다.

창업팀에는 이 차이가 중요할 수 있습니다. 사용자의 요청을 충분히 읽을 여유가 없으면, 팀의 우선순위는 제품의 방향보다 밀린 일에 끌려갈 수 있습니다. Astro의 설명은 자동화가 그 여유를 되찾는 데 쓰일 수 있음을 보여줍니다. 다만 본문에는 이슈 수가 얼마나 감소했는지, 그 변화가 제품 성과로 어떻게 이어졌는지를 보여주는 구체적인 수치는 없습니다.

Flue와 tldraw는 기여를 받는 입구를 바꿉니다

Astro의 자동 분류 체계는 Schott가 새로운 에이전트 개발 틀인 Flue를 만드는 계기가 되었습니다. Flue에서는 외부 PR을 대하는 방식이 더 급진적입니다.

기사에 따르면 Flue는 외부 PR을 모두 자동으로 닫고, 그 내용을 이슈나 토론으로 옮깁니다. 버그 신고와 수정 제안은 이슈가 됩니다. 기능 요청은 토론이 됩니다.

코드를 보냈다는 이유로 그 코드의 검토가 곧바로 시작되지는 않습니다. 먼저 어떤 문제가 있는지, 그 기능이 필요한지, 프로젝트가 그 일을 할지 논의합니다. 할 일을 결정한 뒤에는 에이전트가 조사, 설계, 구현, 초기 검토를 수행합니다. 기여 안내는 이 과정에서 팀의 전문성과 접근 가능한 최신 수준의 대규모 언어 모델을 활용한다고 설명합니다. 대규모 언어 모델은 글과 코드를 이해하고 생성하는 데 쓰이는 AI 모델입니다.

기사는 이를 잠재적인 요청을 받아 살펴보는 방식에 비유합니다. 저는 사용자가 제안한 문제와 사용자가 작성한 해결책을 각각 살펴보는 구조라고 이해했습니다. 문제에는 동의하더라도 제출된 구현을 그대로 받아들일 의무는 두지 않습니다.

이 구분은 제품을 만드는 팀에도 익숙한 상황입니다. 사용자가 특정 버튼을 추가해 달라고 요청할 때, 팀이 먼저 알아야 할 것은 그 버튼으로 어떤 일을 하려는지일 수 있습니다. 이는 이해를 돕기 위한 비유입니다. Flue의 실제 기능 요청 사례로 제시된 내용은 아닙니다.

그림 도구인 tldraw도 외부 PR을 자동으로 닫습니다. 다만 원문은 tldraw를 소스 코드를 공개하는 source available 프로젝트로 구분해 소개합니다. 여기서는 이 구분을 유지하겠습니다. 제공된 본문에는 구체적인 라이선스 조건이 나오지 않습니다.

tldraw를 만든 Steve Ruiz는 1월에 이 방침을 알렸고, 5개월 뒤 다시 설명했습니다. 그는 토론과 에이전트 활용이 늘어난 개발 방식, 공개 기여를 둘러싼 사회적 관행, 코드 보안을 둘러싼 환경 변화를 이유로 들었습니다.

Ruiz의 설명에는 중요한 조건이 붙습니다. 문제가 충분히 구체적으로 정의되어 있고 에이전트가 코드를 작성할 수 있다면, 외부에서 코드를 받아야 할 필요가 줄어든다고 합니다.

이 조건을 빼고 읽으면 사람이 쓰는 코드나 외부 기여 전체가 불필요해졌다는 결론으로 건너뛰기 쉽습니다. 그러나 문제가 아직 모호하거나 프로젝트의 방향 자체를 함께 고민해야 하는 상황까지 같은 방식으로 다룰 수 있는지는 본문만으로 알 수 없습니다.

기사에는 HashiCorp 공동창업자이자 Ghostty를 만든 Mitchell Hashimoto의 더 강한 전망도 등장합니다. 그는 앞으로 대형 오픈소스 프로젝트들이 외부 기여를 완전히 닫게 될 것이라고 봅니다. 이는 한 개발자의 미래 전망입니다. 기사에 소개된 몇 가지 사례로 오픈소스 전체의 방향이 이미 정해졌다고 단정하기는 어렵습니다.

코드를 받지 않아도 다음 운영자는 자랄 수 있을까요

외부 PR은 전통적으로 코드를 받아들이는 통로이면서 사람을 알아가는 통로였습니다. 기사는 운영자가 코드를 검토하는 과정에서 기여자를 가르치고, 그 사람이 미래의 운영자가 될 수 있을지 살펴보았다고 설명합니다.

이 과정에는 결과물만으로 보기 어려운 정보가 있습니다. 피드백을 어떻게 받아들이는지, 다른 사람의 요구를 얼마나 이해하는지, 문제가 생겼을 때 계속 관여하는지 같은 것들입니다. 기사가 짚은 교육과 관계 형성의 역할을 제가 풀어 보았습니다.

에이전트가 구현과 초기 검토를 맡으면 당장의 운영 부담은 줄어들 수 있습니다. 새 사람이 경험을 쌓고 책임을 넓혀 가는 경로가 약해질 가능성도 있습니다.

Schott도 이 빈자리를 인정합니다. 프로젝트를 계속 좁은 인원으로 운영하다가 그 사람들이 휴가를 가면 어떻게 되느냐는 질문입니다. 자동화가 작업 처리 문제를 완화하더라도, 프로젝트를 함께 책임질 사람을 늘리는 문제까지 저절로 해결하지는 않는다는 뜻으로 읽힙니다.

기사는 이슈와 토론이 대안이 될 수 있다고 제안합니다. 사람들은 대화하면서 서로를 더 잘 알고 신뢰할 수 있습니다. 그 과정에서 배우고, 새로운 운영자가 될 가능성을 보여줄 수도 있다는 이야기입니다.

Ruiz가 남겨두려는 기여도 문제 보고, 토론, 관점, 그리고 프로젝트를 아끼고 돌보는 태도입니다. 저는 마지막 항목이 특히 중요하다고 생각합니다. 한 번의 코드 제출보다 문제가 실제로 해결될 때까지 함께 확인하는 사람이 장기적으로 더 큰 도움이 되는 상황도 있을 것입니다.

다만 토론이 기존의 기여자 성장 경로를 충분히 대신할 수 있는지는 아직 알 수 없습니다. 제공된 자료에는 이런 방식으로 새 운영자가 얼마나 늘었는지를 보여주는 결과가 없습니다. 효율적인 운영 방식으로 보인다는 이유만으로 공동체의 지속성까지 확보되었다고 판단하기는 어렵습니다.

투자자로서 보고 싶은 것은 사람이 끝까지 해결해야 하는 일의 변화입니다

이 글에서 개발자 도구를 만드는 창업자에게 보이는 기회는 비교적 구체적입니다. 신고 내용을 실제 문제로 재현하고, 구현을 이어가고, 수정안을 검토하고, 사용자의 확인을 받아 사람이 결정을 내릴 수 있게 만드는 과정입니다.

Vercel이 별도 화면과 실행 공간을 만들고, Astro가 사용자 확인을 작업 절차에 넣었다는 점은 이런 연결 작업이 중요할 수 있음을 보여줍니다. 코드를 생성한 뒤에도 정식 반영까지 필요한 일이 남아 있기 때문입니다.

저는 이런 제품을 살펴볼 때 다음 질문을 던지고 싶습니다.

• 실제로 해결한 일이 무엇인가요. 닫힌 이슈의 수뿐 아니라 어떤 문제가 어떤 방식으로 해결되었는지 보고 싶습니다.
• 사람의 작업은 어디에서 줄었나요. 초안 작성, 문제 재현, 검토, 사용자와의 확인 과정 가운데 무엇이 달라졌는지 구분하고 싶습니다.
• 운영에 드는 전체 부담은 어떻게 바뀌었나요. 에이전트 실행 비용과 사람이 다시 손보는 일까지 포함해 살펴봐야 합니다.
• 핵심 운영자가 자리를 비워도 프로젝트가 이어지나요. 반복 업무를 처리하는 능력과 책임을 나눌 사람을 키우는 능력을 함께 보고 싶습니다.

이 질문들의 답이 원문에 모두 있는 것은 아닙니다. 기사에 나온 사례를 사업의 지속 가능성으로 연결하기 위해 제가 추가로 확인하고 싶은 항목입니다.

가장 강한 반론도 기사 안에 있습니다. Vercel과 Astro는 자신들의 프로젝트에 맞춰 체계를 만들었습니다. 그렇다면 이런 운영 방식이 확산되어도 독립적인 개발 도구 회사의 큰 시장으로 이어지지 않을 수 있습니다. 팀이 직접 구성하는 편을 선호하거나, 프로젝트마다 필요한 맥락이 너무 다를 가능성도 있습니다.

투자 기회를 이야기하려면 추가 근거가 필요합니다. 다른 팀도 비슷한 문제를 겪는지, 외부 제품을 도입할 이유가 있는지, 각 팀의 맥락을 반영하는 데 얼마나 많은 작업이 드는지 확인해야 합니다. 기사는 에이전트 운영의 필요성을 보여주지만, 특정 사업 모델의 수익성까지 증명하지는 않습니다.

기여의 가치는 해결할 문제를 더 분명하게 만드는 데서 시작될 수 있습니다

이 글을 읽고 나면 외부 PR을 닫는다는 제목이 조금 다르게 보입니다. Flue와 tldraw는 사람의 참여가 들어오는 입구를 문제 보고와 토론 쪽으로 옮기고 있습니다. Vercel과 Astro는 팀이 익숙하게 운영할 수 있는 에이전트 체계로 들어오는 일을 처리합니다.

창업자는 사용자가 겪는 문제를 더 정확히 받아들이고, 해결 여부를 끝까지 확인하는 절차를 설계해야겠지요. 커뮤니티 기여자에게는 완성된 코드 외에도 재현 가능한 설명, 실제 사용 맥락, 수정안 확인이 중요한 기여가 될 수 있다는 뜻입니다. 기사 사례를 읽고 제가 실천에 옮길 부분을 생각해 본 것입니다.

투자자인 저는 코드 작성 능력과 함께 무엇을 만들지 정하고, 제대로 되었는지 확인하며, 계속 책임질 수 있는 능력을 눈여겨보게 됩니다. 에이전트가 구현을 더 많이 맡을수록 이 능력이 중요해질 가능성이 높다고 봅니다.

외부 PR을 닫는 선택이 모든 프로젝트에 적합하다고 생각하지는 않습니다. 운영 효율을 얻는 과정에서 새로운 기여자가 배우고 성장할 통로를 잃는다면, 당장의 편리함이 장기적인 약점이 될 수 있습니다.

제가 이 글에서 가져가는 핵심은 간단합니다. 좋은 협업은 얼마나 많은 코드가 들어왔는지만으로 설명하기 어렵습니다. 중요한 문제가 더 잘 드러나고, 해결 여부를 더 확실히 확인하며, 그 일을 함께 책임질 사람이 계속 생기는지까지 살펴봐야 합니다. AI가 개발의 많은 부분을 맡게 되더라도, 프로젝트를 오래 살아 있게 만드는 일에는 여전히 사람 사이의 이해와 신뢰가 필요할 것 같습니다.