초기 오픈소스 도입 시, 메인테이너의 소속을 확인해야 하는 이유

Bro's Sharing
, ,
1

8월 26일 CNCF에서 공개한 프로젝트 거버넌스 가이던스에 참고할 만한 결과가 있었습니다. TOC 의장인 Karena Angell이 72개 프로젝트의 리뷰를 바탕으로 정리한 내용입니다.

sandbox 진입 당시 메인테이너가 여러 조직에 속해 있던 프로젝트의 졸업률은 59.1%, 단일 조직 프로젝트는 28.6%였습니다. 약 2.07배 차이입니다.

프로젝트를 운영하는 메인테이너에게는 외부 참여를 어떻게 늘릴지 검토할 근거가 될 수 있습니다. 저는 도입 기업에서도 이 결과를 함께 살펴볼 필요가 있다고 생각합니다. 기술이 현재 요구사항에 맞는지뿐 아니라, 도입 이후 누가 개발과 유지보수를 이어갈 것인지도 확인해야 하기 때문입니다.

[1] 리뷰에서 확인된 내용

조직 구성에 따른 졸업률 차이 외에도 두 가지 결과가 있었습니다.

먼저, 졸업 프로젝트의 20%에서 졸업 후 거버넌스 집중이 나타났습니다. 해당 프로젝트들은 모두 incubation 단계에서 조직 간 균형 장치가 없었습니다.

운영위원회나 조직별 투표권 조정 장치가 있던 프로젝트는 메인테이너 다양성을 더 오래 유지했습니다. 반면 거버넌스 문서가 잘 갖춰져 있어도 실제 의사결정에 적용되는 장치가 없으면 집중을 막지 못하는 경우가 있었습니다.

다만 조직별 투표권을 제한하는 것과 개발 인력을 여러 조직으로 분산하는 것은 구분해야 합니다. CNCF도 투표권의 균형만으로 메인테이너 구성까지 균형을 이루는 것은 아니라고 설명합니다. 외부 기여자가 리뷰어와 메인테이너로 성장할 수 있는 과정이 함께 필요합니다.

도입 기업에서도 거버넌스 문서의 유무만 확인하기보다는, 실제로 누가 코드를 검토하고 변경 사항을 반영하며 릴리스를 결정하는지 살펴보는 것이 좋겠습니다.

[2] 도입 기업이 메인테이너 소속을 확인해야 하는 이유

GitHub 스타와 다운로드 수는 프로젝트에 대한 관심과 사용 규모를 파악하는 데 도움이 됩니다. 하지만 개발과 유지보수가 특정 회사에 얼마나 의존하는지는 별도로 확인해야 합니다.

메인테이너가 여러 명이어도 모두 같은 회사에 소속되어 있다면, 그 회사의 투자나 사업 방향이 바뀔 때 프로젝트가 영향을 받을 수 있습니다. 회사 이름이 여러 개 있더라도 외부 메인테이너가 실제로 활동하지 않는다면 비슷한 상황일 수 있습니다.

따라서 메인테이너 목록과 소속을 확인한 뒤 최근 활동도 함께 보는 것이 필요합니다. 어떤 조직이 주요 변경 사항을 검토하는지, 릴리스와 보안 대응은 누가 담당하는지까지 확인해야 프로젝트의 운영 구조를 이해할 수 있습니다.

최근 DuckLabs의 AWS 합류도 이 관점에서 살펴볼 수 있습니다.

DuckDB 핵심 개발팀이 있는 DuckLabs는 8월 26일 AWS 합류를 발표했고, 이후 8월 31일 절차가 완료됐다고 밝혔습니다. AWS는 인수 대상이 DuckLabs이며 DuckDB 오픈소스 프로젝트 자체를 인수하는 것은 아니라고 설명했습니다.

DuckDB는 MIT 라이선스를 유지하고, 재단이 핵심 IP를 계속 보유합니다. DuckDB 측은 로드맵과 거버넌스 모델에도 변화가 없다고 발표했습니다. 따라서 이번 인수만으로 프로젝트의 독립성이 훼손됐다고 판단하기는 어렵습니다.

그럼에도 핵심 개발팀이 속한 회사가 AWS의 일원이 됐다는 변화는 도입 기업이 이해하고 있어야 합니다. 라이선스가 유지되더라도 개발 인력을 지원하는 조직은 바뀔 수 있기 때문입니다. 라이선스, IP 보유 주체, 개발팀의 소속과 의사결정 구조를 각각 확인할 필요가 있습니다.

[3] 단일 조직 프로젝트라면 무엇을 준비해야 할까

이 결과가 단일 조직 프로젝트를 피해야 한다는 의미는 아니라고 생각합니다. 초기에는 소수의 개발자나 한 회사가 개발을 주도할 수 있고, 그 기술이 기업의 구체적인 문제를 해결해줄 수도 있습니다.

이 경우에는 조직이 충분히 다양해질 때까지 기다리기보다, 현재 구조에서 필요한 지원을 어떻게 확보할지 검토해야 합니다.

예를 들어 다음과 같은 내용을 도입 전에 협의할 수 있습니다.

  • 보안 이슈와 운영 장애가 발생했을 때 연락할 담당자와 응답 기준

  • 지원 대상 버전과 기능, 수정 및 유지보수의 범위

  • 지원을 중단하거나 범위를 변경할 경우의 사전 통지와 인수인계 방식

  • 기업 내부에서 유지보수하거나 다른 기술로 전환하기 위해 필요한 자료

메인테이너와의 지원 계약은 이런 책임을 구체화하는 방법 중 하나입니다. 다만 계약이 프로젝트 전체의 거버넌스를 대신하는 것은 아닙니다. 계약 상대방이 약속한 지원을 제공할 역량이 있는지, 지원이 끝나더라도 기업에서 운영을 이어갈 수 있는지도 함께 확인해야 합니다.

DuckDB의 경우에도 커뮤니티 지원을 확대하겠다고 발표했지만, 이슈 해결 시한을 보장하지는 않습니다. 기업에서 필요한 대응 수준이 있다면 공개된 지원 정책으로 충분한지 별도로 검토해야 합니다.

클라우드브로가 초기 오픈소스의 사업화 과정에서 중요하게 보는 부분도 이와 연결됩니다. 기업의 기술 검증과 도입 검토를 지원하고, 메인테이너와 기업이 협업할 수 있도록 지원 범위와 책임을 정하는 일입니다.

기업은 필요한 지원을 확보하고, 메인테이너는 그 수익을 바탕으로 개발을 지속할 수 있습니다. 이런 관계를 만들 수 있다면 라이선스를 제한하지 않고도 상용화를 이어갈 수 있을 것이라 생각합니다.

[4] 숫자를 적용할 때의 한계

이번 리뷰의 대상은 졸업·incubation·아카이브 상태의 72개 프로젝트입니다. 현재 sandbox에 남아 있는 프로젝트 전체를 추적한 결과는 아닙니다.

따라서 28.6%를 지금 검토 중인 프로젝트의 성공 확률로 적용하기는 어렵습니다. CNCF 졸업 여부와 기업에서의 도입 성공도 서로 다른 기준입니다. 조직 다양성이 졸업률 차이를 얼마나 직접적으로 설명하는지 역시 공개된 가이던스만으로는 판단하기 어렵습니다.

이 수치는 프로젝트를 평가할 때 추가로 확인할 항목을 정하는 근거로 활용하는 것이 적절하겠습니다.

[5] 역할별로 확인하면 좋을 내용

아키텍트와 기술 검토 담당자라면, 메인테이너의 소속과 실제 활동을 함께 확인하는 것이 좋겠습니다. 주요 코드의 검토와 릴리스 권한이 어디에 집중되어 있는지, 내부에서 유지보수할 수 있는 범위는 어디까지인지 살펴볼 수 있습니다.

조달과 보안 담당자라면, 기업에 필요한 지원 수준을 먼저 정의하고 현재 프로젝트의 지원 정책과 비교해볼 필요가 있습니다. 응답 담당자, 지원 범위, 지원 종료 시의 대응 방식을 구체적으로 협의하는 것이 도움이 됩니다.

초기 프로젝트를 운영하는 메인테이너라면, 현재 제공할 수 있는 지원과 향후 확대할 부분을 구분해 설명하는 것이 좋겠습니다. 기업이 기대하는 책임을 명확히 하고 그에 맞는 비용을 협의하는 과정이 지속적인 개발 기반으로 이어질 수 있습니다.

초기 오픈소스가 기업에 도입되고 오래 사용되려면 기술 검증 이후의 운영과 지원까지 논의가 이어져야 합니다. 메인테이너의 소속과 참여 현황을 확인하는 것이 그 논의를 시작하는 데 도움이 될 것 같습니다.

참고 자료

2개의 좋아요