우리가 알던 오픈소스는 죽어가고 있습니다

AI 요약

글쓴이는 2011년 GitHub 계정을 만들고, 오픈소스 프로젝트를 통해 코드를 배우며 개발자로 성장했습니다. 2014년에는 Node.js 라이브러리의 오류를 고친 PR과 파일 대부분을 정리한 PR을 보냈습니다. 처음 보는 유지관리자는 다음 날 두 PR을 모두 병합했습니다. 글쓴이에게 그 경험은 코드 변경을 받아들였다는 사실을 넘어, 커뮤니티에 환영받고 함께 일할 사람으로 인정받았다는 뜻이었습니다.

기여를 알아보던 신호가 흐려졌습니다

글쓴이는 오픈소스의 가치를 라이선스나 다운로드 수보다 사람 사이의 교류에서 찾습니다. 낯선 사람이 버그를 고치고, 이슈에서 API 설계를 논의하고, 유지관리자가 기여자의 작업을 검토하는 과정이 인터넷의 소프트웨어를 만들었다고 봅니다. 하지만 이제는 낯선 사람이 보낸 PR을 선의의 기여로 여기기 어려워졌습니다. Ladybird를 이끄는 Andreas Kling은 큰 패치가 큰 노력을 보여준다는 전제가 더는 통하지 않는다고 말했습니다. AI 에이전트가 코드를 빠르게 생성하는 상황에서는 패치의 규모만으로 기여자의 의도와 수고를 가늠할 수 없습니다.

인기 저장소에서는 PR이 올라오자마자 AI 리뷰 봇, 미리보기 배포 봇, 변경 내용을 설명하는 봇이 차례로 댓글을 달기도 합니다. 사람이 작성한 PR이라도 생성된 글에 묻혀 실제 대화가 뒤로 밀립니다. 존재하지 않는 문제를 고치는 PR, 자신감은 넘치지만 틀린 코드를 대량으로 바꾸는 PR, 실제처럼 보이지만 환각에 근거한 보안 제보도 늘었다고 글쓴이는 설명합니다. 유지관리자는 기여의 질을 확인하는 데 시간을 쓰고, 잘못된 기여를 거절하는 설명까지 맡습니다.

유지관리자는 외부 기여를 제한하고 있습니다

글쓴이는 프로젝트별 대응 사례를 열거합니다. curl은 제보 중 실제 버그 비율이 5% 아래로 떨어지자 금전적 버그 바운티를 끝냈습니다. tldraw는 외부 PR을 자동으로 닫기 시작했고, Ghostty는 저품질 AI 기여가 열 배 이상 늘었다는 Mitchell Hashimoto의 설명과 함께 AI 정책을 강화했습니다. Python 프로젝트 다수를 운영하던 Jazzband는 생성된 PR과 이슈가 몰리는 상황을 이유로 운영을 중단했습니다.

OpenJDK는 리뷰 부담을 위험 요인으로 들며 LLM 생성 기여를 금지했습니다. Ladybird는 공개 PR을 받지 않기로 했고, Godot은 사람이 작성한 코드만 허용하며 자율 에이전트를 금지했습니다. COSMIC은 PR의 코드와 주석, 설명에 LLM 생성물이 없다는 확인을 요구합니다. Sindre Sorhus도 자신의 모든 저장소에서 외부 PR을 막았습니다. Hono 역시 외부 기여자의 PR을 비활성화했습니다. Hono는 과거 외부 기여자가 만든 RegExpRouter로 성장했지만, 유지관리자 Yusuke Wada는 이제 PR을 받기 어렵다고 밝혔습니다.

GitHub도 PR을 제한하는 기능을 추가했습니다. GitHub는 생성 비용은 낮아졌지만 리뷰 비용은 그대로라고 설명했습니다. 이어 사용자별 공개 PR 수 제한, 이슈 작성자 제한, 스팸 PR 보관 기능 등을 내놓았습니다. 글쓴이는 GitHub에서 Codeberg나 자체 Forgejo·Gitea 인스턴스로 옮기는 프로젝트가 늘면 이슈와 기록, 참여자가 여러 곳으로 흩어져 새 기여자가 프로젝트를 발견하기 어려워질 수 있다고 우려합니다.

기여 비용은 유지관리자에게 옮겨갑니다

글쓴이는 자신도 매일 AI로 코드를 작성하고 검토하며, 이 글의 메모를 정리하는 데도 AI의 도움을 받았다고 밝힙니다. AI 사용을 멈추라고 주장하는 대신, 생성 비용을 거의 0으로 여기는 관행을 문제 삼습니다. PR을 만드는 데 10초가 걸리고 제대로 검토하는 데 30분이 든다면, 요청자가 맡았던 수고를 이미 바쁜 자원봉사 유지관리자에게 넘긴 셈입니다. AI는 기여를 저렴하게 만들었지만 유지관리 비용을 낮추지는 않았고, 오히려 높였습니다.

AI PR 금지는 저품질 자동 기여뿐 아니라 AI를 활용해 좋은 테스트를 작성한 사람도 막는 거친 대응입니다. 정직한 공개에 기대거나 제대로 작동하지 않는 탐지에 의존해야 한다는 한계도 있습니다. 글쓴이는 해결책을 제시하지 않습니다. 초대받은 사람만 기여하는 작고 신뢰도 높은 커뮤니티가 오픈소스의 다음 모습일 수 있다고 말하면서도, 예전처럼 처음 보는 사람이 PR 하나로 프로젝트에 들어오는 길이 사라지면 잃는 것이 있다고 아쉬워합니다.

Lobsters 반응

• @kornel — 오픈소스는 유지관리자에게 성가신 일이 됐지만, 아이러니하게도 에이전트 코딩은 최종 사용자에게 오픈소스를 더 유용하게 만들었습니다. 프로그래머가 아닌 사람에게 오픈소스의 이점은 예전엔 대부분 간접적이거나 이론적이었습니다. 소프트웨어를 직접 바꾸려면 프로그래밍을 배우는 데 큰 시간과 노력이 들고, 버그를 피하거나 기능을 조금 바꾸고 싶은 사람에게는 큰 장벽이었기 때문입니다. 이제 사용자는 “Claude, 고쳐줘”라고 말하면 됩니다. 한 사람만 쓰는 용도라면 대체로 충분히 잘 작동합니다.
• @landon — “GitHub 덕분에 모두가 마침내 한 방에 모인 것 같았습니다.” 그걸 기능이 아니라 버그라고 믿는 사람들도 있습니다.
  • @flockofbirbs — 우리는 광장 하나로 모두를 모을 수 없다는 사실을 계속해서 배울 운명인 것 같습니다.
• @nickmonad — “하지만 GitHub를 떠나는 프로젝트마다 이슈와 기록, 사람들을 다른 곳으로 가져갑니다. 새 계정을 또 만들고, 찾아볼 곳도 하나 늘어납니다. 점점 더 파편화되고 다음 낯선 사람이 프로젝트를 발견할 가능성도 낮아집니다.” 저는 개인적으로 GitHub의 ‘발견’ 기능을 거의 쓰지 않았습니다. 지난 10년 동안 프로필 피드를 훑다가 흥미로운 저장소를 한두 개 발견한 정도입니다. 대개는 이런 외부 사이트에서 발견하거나, 이미 보고 있던 저장소의 댓글에서 다른 곳으로 연결되는 링크를 따라갑니다. 발견 경로가 사라질 것 같지는 않습니다. 다른 도메인으로 가는 링크 하나일 뿐입니다. 계정을 새로 만들어야 하는 점은 조금 번거롭지만, 저라면 GitHub를 떠나지 않을 이유로 삼지는 않겠습니다. “작고 신뢰할 수 있는 모임, 소스는 공개하되 기여는 초대받은 사람만 하는 형태”로 향할 수 있습니다. 어쩌면 괜찮을지도 모릅니다. 제가 존재할 수 없었던 과거 인터넷을 그리워하는 걸 수도 있습니다. 저는 오픈소스를 사랑하고 좋은 소프트웨어를 만드는 힘을 믿습니다. 어떤 종류의 소프트웨어는 반드시 오픈소스여야 합니다. 다만 모든 기여가 원래 저장소로 돌아가야 한다는 생각은 어느 순간 지나치게 강조됐다고 봅니다. 오픈소스의 목적은 의존하는 소프트웨어를 이해하고 수정할 수 있게 하는 것이었습니다. 유지관리자가 기여를 검토해 주리라는 보장은 없었습니다. 글쓴이가 기여를 당연시한다고 생각하지는 않습니다. 하지만 실제로 그런 태도를 보이는 사람도 있고, 그 관계는 늘 이상하게 느껴졌습니다. 포크는 재작성과 마찬가지로 처음부터 고려 대상에서 빠지곤 했습니다. 때로는 그런 선택이 필요하고 좋은 결과를 낳기도 합니다. 협업을 장려해야 하지만, 소유권과 거절할 권리도 그만큼, 때로는 더 중요합니다.
  • @siru — 비밀번호 관리자가 점점 보편화되면서 새 계정을 만드는 부담은 제게는 줄어들었습니다. 서버가 침해됐을 때 유출될 수 있는 이메일 주소를 쓰지 않아도 된다면, 비밀번호 관리자에 로그인 정보를 하나 더 등록하는 건 별로 신경 쓰이지 않습니다. 다시 로그인할 때 자동으로 입력되기도 합니다. 그래서 여러 작은 Git 저장소 서비스로 분산하는 일이 더는 큰 문제가 아닌 것 같습니다.
  • @k749gtnc9l3w — 저는 GitHub의 프로젝트 검색은 사용해 봤습니다. 저장소가 저렴한 VPS에서 제공할 수 있는 정적 Web 1.0 사이트와 링크 모음으로 이동한다면, 웹 전반의 저장소를 검색 색인으로 모으는 작업도 다시 이뤄질 수 있습니다. 과거에도 그런 작업이 여러 번 처음부터 시작됐습니다.
• @evert — 직접 쓴 PR만 받는 쪽으로 가고 있습니다. LLM을 쓸 생각이라면, 제 설계 감각으로 제가 직접 생성할 수 있게 제대로 된 명세를 주세요.
  • @FeepingCreature — 좋은 명세를 만드는 방법은 LLM으로 코드를 짠 다음 diff에서 명세를 역으로 뽑는 일이 되겠네요.
  • @k749gtnc9l3w — 좋은 명세를 쓰려면 시스템을 한 번 구현하고, 버린 뒤 명세에 맞춰 다시 구현해야 한다는 옛말이 떠오릅니다. 어쩌면 이 방식이 강제되는 방법론이 될지도 모르겠습니다.
• @thath — 직장에서 오픈소스 프로젝트 운영을 돕고 있습니다. 올해 LLM 사용 정책을 명확히 하는 등 조정할 일은 있었지만, 저희는 LLM 사용을 허용했습니다. 이제는 LLM으로 만든 기여도 품질이 괜찮고 환영받는, 만족스러운 균형에 도달하는 것 같습니다. 커뮤니티는 정기적으로 온라인 모임도 열어 새로운 관계를 만들고 이어갑니다. 오픈소스가 이런 방향으로 가는 걸까요? PR을 만드는 일보다 진정한 인간 관계에 더 큰 가치를 두는 쪽으로요?

원문: jross.me / 번역·요약: Trawling