오픈소스 프로젝트가 리더를 잃으면 생기는 일

Ryan Dahl이 Node.js에서 물러났을 때 프로젝트는 살아남았지만, 거버넌스를 재편하고 포크(io.js)를 거치고 다시 합치는 과정을 거쳐 안정을 찾기까지 몇 년이 걸렸습니다. Guido van Rossum이 Python의 BDFL('Benevolent Dictator For Life', 종신 자애로운 독재자) 자리에서 물러났을 때도 커뮤니티는 몇 달 동안 거버넌스 모델을 두고 논쟁하다가 결국 steering council을 두는 쪽으로 정리했습니다. Deno 프로젝트가 리더십 문제에 직면했을 때는 그 런타임에 베팅했던 모든 개발자에게 파장이 미쳤습니다.

이런 일은 드문 사건이 아닙니다. 오픈소스 개발의 구조적 특성이죠. 대부분의 주요 오픈소스 프로젝트는 극소수의 사람, 종종 한 사람에게 의존하는데, 사용자들은 그 정도를 생각보다 잘 모릅니다. 그 사람이 떠나거나 번아웃되거나 우선순위를 바꾸거나 논란이 될 결정을 내리면, 아무리 GitHub 스타가 많아도 프로젝트는 존재를 위협받는 위기에 처합니다.

버스 팩터 문제

'버스 팩터(bus factor)', 즉 프로젝트가 무너지기 전에 버스에 치여야 하는 사람 수는 대부분의 오픈소스 프로젝트에서 암울할 만큼 낮습니다. 2015년 연구에 따르면 npm 패키지의 60% 이상이 관리자가 한 명뿐이었습니다. 최근 중요한 오픈소스 인프라를 분석한 자료에서도, 다운스트림 의존성이 수백만 개에 달하는 많은 프로젝트가 한두 사람이 보통 무보수 취미 삼아 유지보수하고 있었습니다.

이건 가설이 아닙니다. 인터넷 암호화 트래픽 대부분을 보호하던 OpenSSL은 Heartbleed가 발견됐을 때 주로 여가 시간에 일하는 두 사람이 유지보수하고 있었습니다. 11줄짜리 간단한 npm 패키지 left-pad는 작성자가 삭제하자 수천 개의 빌드가 깨졌습니다. 주당 2,500만 번 넘게 다운로드되는 core-js는 한 개발자가 관리하는데, 그는 공개적으로 먹고살기도 빠듯하다고 밝힌 적이 있습니다.

패턴은 일관됩니다. 열정 있는 개인이 중요한 프로젝트를 시작하고, 사용자가 늘고, 수백만 명이 의존하는 인프라가 되지만, 유지보수 부담은 여전히 그 한두 사람에게 남아 있습니다. 프로젝트의 중요성은 기하급수적으로 커지는데, 그를 떠받치는 지원은 그렇지 못하죠.

거버넌스 모델과 그 트레이드오프

오픈소스 프로젝트는 거버넌스를 몇 가지 방식으로 운영하며, 각각 예측 가능한 장단점과 실패 패턴이 있습니다.

BDFL 모델

한 사람이 최종 결정을 내리는 방식입니다. Python(Guido van Rossum), Linux(Linus Torvalds), Ruby(Matz)처럼 가장 성공한 프로젝트 상당수에는 취향과 판단력으로 프로젝트의 모습을 만드는 강한 기술 리더가 있습니다. 장점은 분명합니다. 방향이 뚜렷하고 비전이 일관되며 의사결정이 빠릅니다. BDFL은 맞지 않는 기능에 '아니오'라고 말할 수 있고, 덕분에 프로젝트가 중심을 잃지 않습니다.

실패 패턴도 똑같이 분명합니다. BDFL이 떠났는데 승계 계획이 없는 경우입니다. Guido가 수십 년간 커뮤니티를 키웠음에도 그가 물러난 뒤 Python의 전환은 순탄치 않았습니다. 커뮤니티 참여도가 낮은 프로젝트는 BDFL이 자리를 뜨면 그대로 사라지는 경우가 많습니다.

재단 모델

Apache, Eclipse, Linux Foundation 같은 프로젝트는 비영리 재단 아래에서 technical steering committee, committer 선거, 의사결정 절차 같은 공식 거버넌스 구조를 갖춥니다. 구조가 유지되기 때문에 개인이 떠나도 프로젝트가 살아남으며, 제도적 연속성이 생깁니다.

대신 관료주의와 정치적 역학이 따라옵니다. 재단 거버넌스는 느리고 논쟁적이며, 기업 이해관계에 포획되기도 합니다. BDFL 중심 프로젝트의 민첩함과 비교하면 위원회 절차가 답답하다고 느끼는 개발자도 있습니다. 최악의 경우는 기술적 가치보다 조직 정치가 더 중요해진 재단입니다.

기업 스폰서 모델

React(Meta), Go(Google), Rust(원래 Mozilla였고 지금은 자체 재단), TypeScript(Microsoft)처럼 많은 주요 프로젝트는 핵심 메인테이너를 고용한 기업이 후원합니다. 자금 문제를 해결해 주는 방식이죠. 메인테이너는 보수를 받고 풀타임으로 일할 수 있으며, 프로젝트는 기업의 엔지니어링 자원을 활용할 수 있습니다.

문제는 방향 일치입니다. 기업의 우선순위는 바뀝니다. Mozilla는 Rust 팀을 정리해고했고, Google도 사업 초점이 옮겨가자 오픈소스 프로젝트의 우선순위를 낮추고 투자를 줄였습니다. 기업의 전략적 이익이 커뮤니티의 이익과 어긋나면 마찰은 피할 수 없습니다. 최근 기업 후원 프로젝트들이 라이선스를 바꾸는 흐름(Redis, Terraform, Elastic)은 이 모델이 얼마나 위태로울 수 있는지 잘 보여줍니다.

건강한 포크라는 것

포크, 즉 프로젝트의 경쟁 사본을 만드는 일은 보통 실패의 신호로 취급됩니다. 하지만 오픈소스에서 포크는 사실상 최후의 안전밸브입니다. 리더십이 실패하면 포크 덕분에 커뮤니티는 원래 메인테이너에 기대지 않고 계속 나아갈 수 있습니다.

Node.js를 포크한 io.js는 Node를 더 개방적인 거버넌스와 빠른 릴리스 주기 쪽으로 밀어붙였습니다. 두 프로젝트가 다시 합쳐졌을 때 Node는 더 나아져 있었죠. OpenOffice.org에서 갈라져 나온 LibreOffice는 Sun/Oracle의 식어 가는 관심에서 프로젝트를 구해냈습니다. Oracle이 인수한 뒤 MySQL에서 포크된 MariaDB는 지금도 커뮤니티 주도의 대안으로 자리 잡고 있습니다.

최근에는 라이선스 변경이 생산적인 포크를 낳기도 했습니다. Elastic이 Elasticsearch 라이선스를 바꾸자 Amazon은 OpenSearch로 포크했습니다. HashiCorp이 Terraform 라이선스를 바꾸자 커뮤니티는 Linux Foundation 산하에서 OpenTofu로 포크했습니다. 이런 포크가 생기는 이유는, 포크할 권리가 프로젝트 리더십을 견제하는 커뮤니티의 궁극적 장치이기 때문입니다.

핵심은 포크가 코드뿐 아니라 커뮤니티까지 깔끔하게 나뉠 때 가장 잘 작동한다는 점입니다. 활발한 메인테이너와 커뮤니티의 지지를 받는 포크는 번창하지만, 좌절한 개발자 한 명이 만든 포크를 아무도 따라가지 않으면 혼란만 남습니다.

번아웃의 소용돌이

대부분의 오픈소스 리더십 위기는 극적인 퇴장으로 시작하지 않습니다. 이슈, 풀 리퀘스트, 기능 요청, 당연하다는 듯 요구하는 사용자의 무게에 눌려 메인테이너의 역량과 열정이 천천히 닳는 번아웃에서 시작합니다.

흐름은 예측 가능합니다. 메인테이너가 쓸모 있는 무언가를 만듭니다. 사용자가 몰려옵니다. 버그 리포트, 기능 요청, 지원 질문, 요구 사항이 따라옵니다. 책임감을 느낀 메인테이너는 모든 것에 답하려 합니다. 양이 역량을 넘어서면 알림을 보기가 두려워집니다. 답변은 느려지고, 그다음엔 퉁명스러워지고, 결국 아예 사라집니다. 결국 그들은 자리를 떠나고, 프로젝트는 기술적으로는 살아 있지만 실제로는 버려진 좀비 유지보수 상태에 들어갑니다.

오픈소스 메인테이너의 번아웃은 개인의 실패가 아닙니다. 구조적인 문제입니다. 프로젝트는 유한한 사람들의 시간과 관심을 무한히 요구하고, 그 요구를 관리할 장치는 내장되어 있지 않습니다.

몇몇 메인테이너는 대처 방법을 찾았습니다. 응답 시간에 엄격한 경계를 두거나, 트리아지를 커뮤니티 멤버에게 맡기거나, GitHub Sponsors나 Open Collective로 유지보수비를 받거나, 아예 느린 응답 속도를 받아들이는 식입니다. 하지만 이런 방법은 끝없이 연결되어 있어야 한다는 압박에 의식적으로 저항해야 하고, 이는 많은 오픈소스 커뮤니티의 문화와 어긋납니다.

건강한 승계는 어떤 모습일까

리더십 교체를 잘 해낸 프로젝트가 몇 있고, 이들은 공통된 패턴을 보입니다.

• 코드만이 아니라 지식도 분산되어 있다. 프로젝트의 '부족 지식(tribal knowledge)', 즉 왜 특정 결정을 내렸는지, 어떤 대안을 검토했는지, 설계 원칙이 무엇인지는 한 사람의 머릿속이 아니라 문서로 남아 있습니다. Architecture Decision Records(ADR)와 상세한 RFC가 이 역할을 합니다.
• 커밋 권한과 릴리스 권한을 가진 사람이 여럿이다. 릴리스를 낼 수 있는 사람이 한 명뿐이면 그 사람이 단일 장애점입니다. 건강한 프로젝트는 독립적으로 새 버전을 릴리스할 수 있는 사람이 최소 3~5명은 됩니다.
• 거버넌스 문서가 명시되어 있다. 결정은 어떻게 내려지나요? 누가 무엇에 권한을 갖나요? 새 메인테이너는 어떻게 추가되나요? 위기 전에 이 질문에 답해 둔 프로젝트가 즉흥적으로 대응하는 프로젝트보다 승계를 잘합니다.
• 갑작스러운 이탈이 아니라 점진적인 전환이다. 가장 좋은 리더십 전환은 물러나는 리더가 몇 달에 걸쳐 의도적으로 관여를 줄이고, 후계자를 멘토링하며 권한을 명시적으로 넘길 때 일어납니다. 갑작스러운 이탈은 좋은 의도였더라도 공백을 만듭니다.
• 재정적으로 지속 가능하다. 재단, 기업 후원, 커뮤니티 펀딩 등으로 안정적인 자금이 있는 프로젝트는 교체 과정을 더 잘 버팁니다. 새 메인테이너에게 시간을 보상할 수 있기 때문입니다. 보수 없는 풀타임 업무를 떠안으라고 하는 건 설득하기 어려운 제안입니다.

사용자와 기업이 해야 할 일

비즈니스가 오픈소스 소프트웨어에 의존한다면, 그리고 대부분은 그렇습니다, 여러분이 의존하는 프로젝트의 건강에는 이해관계가 있습니다. 몇 가지 실용적인 단계가 있습니다.

1. 의존성의 버스 팩터를 점검하라. 스택에 있는 핵심 오픈소스 프로젝트를 살펴보세요. 활동 중인 메인테이너는 몇 명인가요? 마지막 릴리스는 언제였나요? 보안 이슈는 얼마나 빨리 처리되나요? 메인테이너가 한 명이고 6개월 된 보안 취약점이 방치된 프로젝트는 여러분이 알고 있어야 할 위험입니다.
2. 쓰는 것에 대가를 지불하라. 프로젝트가 비즈니스에 중요하다면 후원으로 자금 지원에 참여하세요. GitHub Sponsors, Open Collective, Tidelift가 이런 수단을 제공합니다. 메인테이너에게 지원하는 비용은, 핵심 의존성이 유지보수되지 않게 되는 비용에 비하면 사소합니다.
3. 업스트림에 기여하라. 버그 수정, 문서 개선, 이슈 트리아지는 메인테이너의 부담을 줄이고 팀이 코드베이스에 익숙해지게 합니다. 프로젝트에 새 메인테이너가 필요해질 때 여러분이 바로 나설 수 있는 위치에 있게 됩니다.
4. 비상 계획을 세워 두라. 핵심 의존성이 버려진다면 어떻게 할지 미리 알아 두세요. 직접 포크해서 유지보수할 수 있나요? 옮겨 갈 수 있는 대안이 있나요? 이 질문에 답할 시간은 그게 필요해지기 전입니다.

오픈소스 거버넌스는 화려한 일이 아닙니다. 헤드라인을 만들지도, GitHub 스타를 불러오지도 않죠. 그런데 창립자가 떠난 뒤에도 살아남는 프로젝트와 그렇지 못한 프로젝트를 가르는 차이는 거의 항상 거버넌스입니다. 결정을 문서화하고, 권한을 나누고, 승계를 계획하는 지루하고 구조적인 작업이죠. 오래가는 프로젝트는 소프트웨어만 만든 것이 아니라 제도를 만든 프로젝트입니다.