오픈 소스 프로젝트에서 기여자를 어떻게 육성하는지, 그리고 Zig 프로젝트가 AI 기반 기여를 금지하는 이유를 설명합니다.
개인 웹사이트
소개 • Twitter • Twitch • YouTube • GitHub
2026년 4월 29일 • 6분 읽기 • 작성자 Loris Cro
몬티 홀을 플레이할 때는 항상 문을 바꿔야 한다
Zig Software Foundation에서 일하는 동안 나는 소프트웨어에 관해 많은 흥미로운 것들을 배울 기회를 얻고 있다. 오늘 내가 공유하고 싶은 것은, 기여자를 끌어들일 만큼 충분히 큰 모든 오픈 소스 프로젝트에 중요한 이해의 한 조각이다.
오픈 소스 개발에는 미묘한 장단점의 집합이 따르며, 나쁜 점은 아주 많기 때문에 그것을 감당해야 하는 대신, 좋은 점을 잘 활용해서 이를 상쇄하는 것은 당신에게 달려 있다.
무엇보다도 오픈 소스는 많은 비즈니스 모델과 양립할 수 없고, 가치 있는 무언가를 무료로 내줘야 한다는 생각에 기반한다. 물론 무언가를 무료로 내주는 대가로, 당신 역시 무료로 무언가를 얻는데, 대부분은 코드 기여의 형태다.
불행히도 그러한 기여들(이제부터는 PR이라고 부르자)은 청구서를 대신 내주지 않을 뿐만 아니라, 그 자체가 추가 노동과 마찰의 원천인 경우가 많다. 실제로는 유지보수자가 직접 어떤 변경을 구현하는 편이, PR 작성자와 함께 그 코드를 병합 가능한 상태로 만들기 위해 작업하는 것보다 덜 힘드는 경우가 꽤 흔하다.
지금까지 말한 내용을 바탕으로 보면 오픈 소스 개발은 꽤 형편없는 거래처럼 보인다. 그럼에도 나는 대부분의 대안적 개발 모델보다 훨씬 더 저렴한 비용으로 더 높은 품질의 제품을 만들어낼 잠재력이 있다고 굳게 믿는다. 단지 오픈 소스 게임을 잘하게 되면 된다. 이 주제 전반에 대해서는 이미 글을 쓴 적이 있지만, 오늘은 한 가지 특정한 측면에 집중하려고 한다. 바로 기여자 포커다.
성공한 오픈 소스 프로젝트에서는 결국 자신이 처리할 수 있는 양보다 더 많은 PR을 받기 시작하는 시점에 도달한다. 지금까지 언급한 바를 보면 작업 대비 수익을 극대화하기 위해 불완전한 PR은 받지 않는 것이 타당해 보일 수 있지만, Zig 프로젝트에서는 그렇게 하지 않는다. 대신 새로운 기여자가 자신의 작업을 프로젝트에 넣을 수 있도록, 거기까지 가는 데 약간의 도움이 필요하더라도 최선을 다해 돕는다. 우리는 이것이 단지 “옳은” 일이기 때문만이 아니라, 현명한 일이기도 하기 때문에 그렇게 한다.
오픈 소스 프로젝트에 기여하는 것은 반복 게임이며, 기여자가 프로젝트에 가져올 수 있는 가치의 대부분은 뒤의 반복들에 있다. 다시 말해, 처음에는 새로운 기여자를 온보딩하기 위해 약간의 에너지를 투자한다. 즉, 판돈을 건다. 그리고 나중에 그 관계가, 기여자가 더 신뢰받고 더 생산적인 사람이 됨에 따라 당신에게 보답하기 시작하기를 바란다.
내가 이것을 “기여자 포커”라고 부르는 이유는, 실제 카드 게임에 대해 사람들이 말하듯 “카드가 아니라 사람을 상대로 플레이한다”는 점과 같기 때문이다. 기여자 포커에서는 첫 번째 PR의 내용에 베팅하는 것이 아니라, 기여자에게 베팅한다.
이 역학을 명시적으로 이해하고 있었기 때문에 Zig 프로젝트는 시간이 지나며 엄청난 양의 가치를 얻을 수 있었다. 컴파일러 툴체인을 처음부터 구축하는 것은 범위가 엄청나게 크기 때문에, 기여자들의 상당한 도움 없이는 커버하는 것이 불가능했을 것이다.
Ryan Liptak 같은 기여자들 덕분에 이제 Zig 사용자들은 Zig가 Windows 리소스 스크립트(.rc) 파일을 컴파일할 수 있기 때문에 Windows에서 실행 파일 아이콘 설정(그리고 그 이상)이라는 사치를 누릴 수 있다.
또 다른 눈에 띄는 예는 Frank Denis의 기여들이다. 그가 std.crypto에서 해낸 작업에 금전적 가치를 매기려면 어디서부터 시작해야 할지조차 모르겠다.
Zig의 초기에는 모든 새로운 기여자에게 투자하는 것이 가능했지만, 이제 프로젝트는 들어오는 PR의 양이 핵심 기여자들이 기여자 포커를 하기 위해 사용할 수 있는 에너지의 양을 훨씬 초과할 정도로 성장했다.
실제로 이는 좋은 PR이 오랜 기간 리뷰되지 않은 채 남아 있었던 사례들이 있었다는 뜻이며, 그 결과 가치 있는 기여자들이 Zig에 기여하는 데 흥미를 잃었을 가능성도 있다.
이 점은 우리의 연간 재무 보고서에서 언급한 바 있으며, 더 중요하게는 우리가 적극적으로 인식하고 있는 문제이고, 앞으로 해결하거나(혹은 적어도 완화하거나) 싶어 하는 문제다.
불행히도 이것은 본질적으로 다루기 어려운 문제일 뿐 아니라, AI가 상황을 더 악화시켰다.
Zig 프로젝트가 왜 AI 기여를 금지하는지에 대해 많은 추측이 있었지만, 이제 기여자 포커의 중요성을 이해했다면 우리가 왜 그렇게 하는지 쉽게 알 수 있다.
기여자가 영향력 있는 작업을 제공하려면 코드베이스와 문제 영역에 익숙해야 하고, 핵심 팀이 그 사람을 신뢰할 수 있어야 한다. 즉, CI만 통과하는 우연한 해법을 제출한 것이 아니라 최적의 접근을 추구하기 위해 자신의 PR이 도입하는 모든 변경 사항을 충분히 숙고했다고 믿을 수 있어야 한다.
추가로, 더 신뢰받는 사람이 되어 가는 과정의 일부로서, 기여자는 자신의 코드가 병합된 이후에도 한동안 자신이 제출한 코드에 대해 책임질 것으로 기대된다. 완벽한 사람은 없고, 때로는 나중에 문제가 발견되기도 한다. 어떻게 방향을 수정할지 결정하기 위한 후속 논의 역시, 특정 문제 영역에 대해 상당한 통찰을 쌓아온 엔지니어들과 반복적인 관계를 맺는 것이 왜 가치 있는지 보여주는 또 다른 예다.
이 점이 중요한 이유는 Zig의 사용자들 역시 가능한 한 좋은 언어와 툴체인을 제공해 주기를 바라며 Zig Software Foundation에 판돈을 걸고 있기 때문이다.
불행히도 LLM 기반 기여의 현실은 우리에게 대체로 부정적이었다. 환각으로 가득한, 아무 가치도 없는 치고 빠지는 PR들 때문에 배경 잡음이 늘어났고(그런 것들은 컴파일조차 되지 않았고, CI를 통과하는 것은 더더욱 아니었다), 처음 보내는 PR이 1만 줄에 달하는 황당한 경우도 있었다. 그 사이에는 겉보기에는 멀쩡해 보이는 PR도 많이 있었고, 그중 일부는 명시적으로 LLM을 사용하지 않았다고 주장하기까지 했지만, 후속 논의에 들어가자마자 작성자가 몰래 LLM에 의존하고 있으며 그 실수투성이 답변을 우리에게 그대로 되뇌고 있다는 것이 즉시 분명해졌다.
분명히 하자면, 여기서 말하고자 하는 요점은 우리가 이것이 AI의 전부라고 믿는다는 것이 아니다. 우리는 그렇게 생각하지 않는다. 이것은 분명 도구의 오용이지만, 동시에 우리 프로젝트에서 LLM 기반 기여의 압도적 다수가 실제로 보였던 모습이기도 하다.
따라서 이론적으로는 LLM을 사용하면서도 유효한 기여자가 될 수 있다고 하더라도, 기여자 포커의 관점에서 보면 이런 위험 요소를 드러내지 않는 다른 기여자들의 거대한 풀이 있는 상황에서 우리가 LLM 사용자에게 판돈을 거는 것은 그저 비합리적이다.
기여가 LLM에서 왔는지 아닌지를 아는 것은 불가능하다고 지적한 사람들은 이 정책의 요점을 완전히 놓쳤고, 기여자 포커를 분명 이해하지 못하고 있다.
우리에게 있어 기여자들이 시스템적 사고를 향상시키고, 능력 있고 신뢰받으며 생산적인 다른 엔지니어들과 상호작용할 수 있는 매력적인 생태계를 제공하는 능력은 우리 비즈니스 모델의 핵심적인 측면이다.
내가 이전에도 언급했듯, Zig는 프로젝트를 둘러싼 기술적, 사회적, 비즈니스 관리 문제들을 고민하는 데 엄청난 노력을 기울이기 때문에 체급 자금 규모를 훨씬 뛰어넘는 성과를 낼 수 있다.
기여자 포커는 우리 전략의 핵심적인 부분이며, 프로젝트의 최선의 이익을 위해 우리가 이 게임을 효과적으로 플레이하는 능력을 방해하는 모든 것에 맞서야 한다. 그렇다고 해도, 우리는 아직 해결되지 않은 문제가 많다는 점을 알고 있고, 더 많은 통찰을 얻어 감에 따라 우리의 정책을 조정할 계획이다.
우리가 성공하도록 돕고 싶다면, Zig Software Foundation에 소액의 월간 기부를 고려해 달라.
