오픈소스의 새로운 모델: 풀 리퀘스트는 닫고, 리믹스는 연다

게시일: 2026년 10월 15일 | 원문 작성일: 2026년 10월 15일 | 저자: Geoffrey Huntley | 원문 보기

• • •

역사 이야기부터 잠깐 할게요. 이 에세이가 나온 지 소프트웨어 엔지니어 세대가 두어 번 바뀌었으니, 모두가 대성당(cathedral)이 무엇인지 안다고 가정할 수는 없어요. 바자회(bazaar)는 다들 알 거예요. 매일 GitHub에서 쓰고 있으니까요.

👉 The Cathedral and the Bazaar - Wikipedia

GitHub는 분산되고 열려 있고 스스로 조직되는 오픈소스 프로젝트라는 바자회의 발상을 가져와서, 누구나 풀 리퀘스트로 소스 코드를 살펴보고 기여할 수 있는 워크플로를 만들었어요.

저는 새로운 소프트웨어 개발 모델이 필요하다고 생각해 왔어요. 대성당으로 돌아갈 수는 없어요. 대성당에서는 소수의 비공개 집단이 소스 코드를 만들고, 릴리스를 치밀하게 계획해 드물고 매끈하게 내놓았어요.

하지만 AI가 등장한 지금은 다른 무언가가 필요하다는 게 분명해요. GitHub의 바자회 모델은 AI 이전에도 이미 금이 가고 있었어요. 소비자식 권리 의식이 생겨서, 다들 유지보수자에게 뭔가를 병합해 달라고 졸라 댔어요. 사회 구조에 대한 기이한 기대도 만들었어요. 코드를 공개한 사람은 그 코드를 유지보수할 의무가 있고, 그 일에 대가는 한 푼도 받지 못한다는 기대 말이에요.

그런데 이제 AI가 등장하면서 둑이 완전히 터져 버렸어요.

생성된 코드가 담긴 풀 리퀘스트를 읽어서 뭘 하겠어요? 제가 원하는 건 핵심 아이디어를 읽고 이해하는 것뿐이에요. 좋은 아이디어라면 업스트림에 다시 반영할 수도 있겠지만, 그래야 한다는 기대는 없어야 해요.

오픈소스 소프트웨어가 오픈소스인 이유는, 라이선스가 소프트웨어를 “있는 그대로(as is)” 제공한다고 말하고, 그 “있는 그대로”가 소프트웨어를 리믹스해도 된다는 뜻이기 때문이에요.

원문 보기

다만 지금까지는 소프트웨어를 리믹스하기가 너무 어렵다고 여겨져 왔어요. 실제로는 어렵지 않았어요. 지식의 격차일 뿐이었고, 에이전트가 있는 지금은 그 격차가 사라졌어요. Nix는 오래전부터 있었어요. 며칠 전에 제가 올린 Nix 오버레이 글을 아직 못 봤다면 꼭 읽어 보세요.

👉 the world hasn’t figured out yet that you can literally just fix everything with a Nix overlay

업계에 불확실한 것은 많지만, 거의 13년 동안 확신해 온 게 하나 있어요. Nix는 끔찍한 프로그래밍 언어라는 거예요. 처음 배웠을 때는 똥을 언덕 위로 밀어 올리는 기분이었어요. 학습 절벽(The learning cliff)…

그래서 다른 오픈소스 유지보수자에게 도움이 되길 바라며 하나 제안할게요. 제가 오픈소스 라이선스로 소프트웨어를 공개할 때 지금 이렇게 생각하고 있어요.

• • •

리믹스 모델

• 구조: 분산되고 조합 가능한 구조예요. 아이디어는 하나의 저장소와 한 명의 유지보수자로 모이지 않고, 각자의 오버레이를 통해 퍼져 나가요.
• 워크플로: 소스와 의도를 있는 그대로 제공하는(as-is) 라이선스로 공개해요. 다른 사람은 원하는 변경을 한 번 표현하는 작은 Nix 오버레이를 써서 리믹스하고, 그 파생물(derivation)을 devenv 셸, Docker 이미지, NixOS 시스템과 테스트, CI, 에이전트 샌드박스에서 재사용해요. 포크하거나 갈라진 결과물을 따로 유지보수할 필요가 없어요.
• 핵심 원칙: 패치보다 아이디어예요. 가치 있는 단위는 동작이나 아키텍처의 변화예요. 유지보수자는 그 변화를 반영할지, 다시 구현할지, 무시할지 정해요. 원저자에게는 변경을 검토하고 통합하고 유지보수해야 할 의무가 없어요.
• 사회적 계약: 라이선스가 이미 리믹스를 허용하고 있고, 그렇다고 누군가의 앞으로의 시간을 요구할 권리가 생기지는 않아요. 크레딧과 가시성은 여전히 있을 수 있지만, 지속적인 유지보수 의무는 없어요. 업스트림 반영은 선택이고 신중하게 정하는 일로 남아요.
• 발견: 쓸 만한 변형은 세상에 퍼진 수많은 오버레이로 나타나요. 유지보수자는 원한다면 그중에서 골라 볼 수 있고, 나머지 사람들은 에이전트를 통해 자기 오버레이를 갱신하는 것만으로 아이디어를 가져다 조합할 수 있어요.

예시: 어떤 프로젝트를 쓰는 사용자가 그 프로젝트 안에서 Git의 강제 푸시(force push)를 막고 싶어 해요. 업스트림 프로젝트에 풀 리퀘스트를 올리는 대신, 사용자는 강제 푸시를 거부하도록 Git을 패치하는 오버레이를 만들어요. 이 오버레이는 한 번 정의해 두면 개발 환경, 컨테이너 이미지, 시스템 테스트에 일관되게 적용돼요. 업스트림 프로젝트에 풀 리퀘스트를 보낼 필요가 없어요.

실제로 지금부터 제가 GitHub에 공개하는 모든 코드는 풀 리퀘스트를 끄고, 디스커션(discussions)은 열어 두며, 제 소프트웨어를 리믹스하는 방법에 대한 가이드를 게시하고 유지보수할 거예요.

무한히 커스터마이즈할 수 있으면서도 쓰기 쉬운 소프트웨어. 이것이 표준 관행이 되기를 바랍니다. 오픈소스를 공개하고 큰 프로젝트를 운영하는 데 드는 인지적 부담을 없애면 더 많은 사람이 소프트웨어를 공개할 거예요. 그것도 올바른 방식으로 하면, 세상에 훨씬 더 많은 소프트웨어가 생길 거예요.

GitHub의 네트워크 그래프(network graph)는 생태계의 리믹스를 살펴보기에 아주 좋아요. 에이전트를 돌려서 사람들이 무엇을 하고 있는지 요약하게 할 수도 있어요. 에이전트 루프 안에서 리믹스 아이디어를 탐색하고, 그 결과를 메인 프로젝트에 되돌려 보내는 데도 쓸 수 있어요.

👉 GitHub - ghuntley/nix-demo: 이 아이디어가 실제로 돌아가는 데모예요. Nix 오버레이로 git을 한 번 패치해서 devenv, NixOS VM 테스트, Docker 이미지에서 모두 써요.