오픈소스를 꿈꾸는 혁신가를 위한 안내서 🚀

Sungho KIM

2021.08.04 | Open Source

full

1. 오픈소스 소프트웨어(OSS) 현황

최근 많은 기업과 단체가 OSS에 주목하고 있습니다. OSS 개발이 소규모 단체나 개인에 의해 주도되었던 과거와 달리, 최근의 OSS 개발 트렌드는 거대 IT 기업이 주도하고 있습니다. 특히, AI와 ML 분야에서 거대 IT 기업들은 오픈소스 라이브러리 개발에 적극적으로 나서고 있습니다.

fifty

Google이 주도한 kubernetes는 기업 주도 오픈소스의 가장 성공적인 사례 중 하나이고, MS와 같이 반-오픈소스 성향이 강했던 기업들도 OSS 개발에 착수하여 점점 더 많은 소프트웨어가 오픈소스로 개발되고 있습니다. MS는 Github을, IBM은 Redhat을 인수하며 상대적으로 보수적이라고 알려진 거대 IT 기업들까지도 오픈소스에 강력한 의지를 보이고 있습니다.

하지만 OSS 개발에 대한 관심이 높아지고 있음에도 불구하고, 기존에 OSS를 기반으로 사업을 진행해 온 많은 기업들이 어려움을 호소하고 있는 것 또한 사실입니다.

ML2는 해당 포스팅을 통해 오픈소스 도입이 기업활동에 어떠한 효과를 발휘하는지 확인하고자 합니다. 따라서, 오픈소스 도입 형태에 따른 기업 전략상 유불리를 파악하고 이러한 현상이 발생하는 원인에 대해서 분석합니다.

이를 위해 우선적으로 상업적 오픈소스(COSS) 기업들의 현황을 확인하고 COSS 기업들이 어려움을 겪는 원인을 오픈소스의 특성에 기반하여 설명합니다. 이를 통해서 오픈소스가 기업에 불리하게 작용하는 상황과 원인에 대한 답변을 얻을 수 있을 것입니다.

오픈소스 채택이 기업 활동에 불리하게 작용하는 케이스도 존재하지만, 오픈소스를 통해 혁신을 주도하고 있는 케이스도 분명히 존재합니다. 앞서 설명한 빅테크 기업 주도의 오픈소스 개발은 오픈소스의 긍정적인 측면에 기반한 현상으로 파악됩니다. 따라서 오픈소스 도입이 긍정적인 효과를 가져오는 케이스를 분석하여 오픈소스의 강점을 확인합니다.

이어지는 글에서 다루겠지만, 오픈소스의 강점은 대부분 강력한 커뮤니티에서 발휘됩니다. 따라서 성공적인 오픈소스 개발을 위해서는 성공적인 커뮤니티를 구축하는 것이 필수적입니다. 이에, ML2는 성공적인 오픈소스 커뮤니티의 조건에 대해 다루는 연구를 소개하며 오픈소스 개발을 시도하는 기업들이 참고해야 할 사항들에 대해서도 확인합니다.

결론적으로, 이번 포스팅의 목표는 오픈소스가 기업 활동에 미칠 수 있는 긍정적인 영향과 부정적인 영향을 확인하고 성공적인 오픈소스 프로젝트 진행을 위한 요건을 살펴봄으로써 오픈소스 개발, 혹은 채택을 시도하는 기업들에게 압축적인 인사이트를 제공하는 것입니다.

2. 오픈소스의 비즈니스의 난점

해당 챕터에서는 상업용 오픈소스 기반 비즈니스를 수행하는 기업들이 마주할 수 있는 난점에 대해 분석합니다. 오픈소스와 관련된 주요한 문제점들은, 일반적으로 사업 극초창기보다는 투자 유치 이후 수익성을 추구해야 하는 단계에서 발생합니다.

2.1 경쟁우위 및 차별화 문제

2.1.1 COSS Segmentation

우선, 시장 내 경쟁 상황에 대한 명료한 그림을 얻기 위해 COSS가 속해 있는 시장을 세분화하여 분류하고, 세분화된 시장을 기준으로 경쟁 기업을 파악합니다. 시장 세분화 기준은 정통부 '글로벌 상용 SW 백서'에 제시된 산업 분류 기준을 활용하였습니다. 또한 분석 대상 선정에는 COSS Media의 COSS INDEX를 사용하였습니다.

IBM에 의하면 IT Infrastructure는 아래와 같은 Components를 가집니다.1

full

위 자료들을 요약하면, 시장에서 COSS로 분류되는 OSS는 거의 모두 IT Infrastructure 영역에 속해 있음을 알 수 있습니다. 따라서 COSS의 경쟁기업은 IT Infrastructure 제품을 제공하는 기업 전반입니다. 사업 영역에 따라 Local한 경쟁자들이 존재하지만 COSS가 사업을 확장하게 되면 결국 IT Infrastructure 영역 전반을 아우르는 빅테크 기업들과 경쟁하게 됩니다.

문제는, IT Infrastructure 영역에서 빅테크 기업들과 직접적으로 경쟁하는 것이 COSS 기업들에게 굉장히 큰 위협으로 다가온다는 것입니다.

경쟁우위 및 차별화 문제는 COSS의 핵심 소스코드(Core)가 오픈 라이선스를 채택하고 있기 때문에 발생합니다. 소프트웨어가 오픈 라이선스를 채택하고 있는 한, OSS 자체는 시장에 판매되는 제품이 될 수 없습니다.

때문에 상당수 COSS는 자사의 OSS를 더 잘 쓰기 위한 managed service, 혹은 add-on 모듈을 제공하여 수익을 창출합니다. 물론 이러한 부가 기능들은 proprietary로 개발되고, 따라서 유료로 제공될 수 있습니다. 결국 소비자들이 비용을 지불하고 사용하는 '제품'은 이미 공개된 Core가 아니라 managed service입니다.

이처럼 Core와 수익원을 분리하는 BM이 Open-core BM입니다. Open-core BM은 소프트웨어의 핵심이 되는 core 모듈을 오픈소스로 개발하고, core를 더 잘 활용할 수 있게 하는 추가 기능은 독점 소프트웨어 형태로 제공하여 수익을 창출합니다. 추가 기능은 앞서 언급한 것처럼 managed service, 혹은 add-on 모듈의 형태로 제공됩니다. Open-core BM은 시장에서 가장 성공적인 BM으로 여겨졌고, 시장에 진출하여 매출을 올리는 COSS 기업 대부분이 Open-core BM을 채택하고 있습니다. 실제로 앞서 확인한 COSS index에 의하면 시장에 진출한 49개의 COSS 기업 중 44개의 기업(90%)이 open-core BM을 채택하고 있습니다.

Open-core BM은 '우리 소프트웨어를 가장 잘 제공할 수 있는 것은 우리 회사이다.' 라는 가정하에 성립합니다. 이러한 가정은 COSS가 처음 시장에 진출하여 수익을 창출할 때부터 거의 당연하게 여겨져 왔고 open-core BM의 근거가 되어 왔습니다.

하지만 Open-core BM의 근거가 되어온 편리한 가정은 앞서 언급한 것처럼 IT 공룡들에 의해 위협받고 있습니다. COSS 개발사들은 더 이상 자사 소프트웨어를 제공하는 최고의 vendor가 아닐 수도 있습니다.

클라우드 서비스를 통해 IT Infrastructure 시장 전반에 막대한 영향력을 확보한 빅테크 기업들은 On-premise에서 클라우드로 시장 구조를 개편해나감과 동시에 기존 COSS vendor들이 제공해 오던 managed service를 자사의 클라우드 플랫폼에 통합해 나가기 시작했습니다.

클라우드 업체는 큰 비용을 들이지 않고 COSS의 방대한 이용자 커뮤니티와 기능을 흡수하면서 COSS의 파이를 침식해 나가고 있습니다. 클라우드 업체 측에서 막대한 개척 비용을 지출하지 않아도 되는 것은 COSS의 core가 오픈소스이기 때문입니다.

일반적으로, 시장에 선제적으로 진출한 기업은 정보 장벽을 통해 후발 주자의 진입을 자연스럽게 차단할 수 있습니다.2 기존 기술을 사용하던 기업이 다른 기술로 전환할 경우 정보 장벽으로 인해 추가적인 비용을 지불해야 하고, 결과적으로 새로운 기술을 적용하는 기업은 소수에 불과하기 때문입니다. 후발 주자가 시장에 진출하기 위해서는 후발 주자의 제품이 제공하는 혜택이 정보 장벽으로 인해 지불해야 하는 비용보다 커야 합니다.

정보 장벽이 발생시키는 비용이 후발 주자에게만 전가되기 때문에 시장에 먼저 진출하여 점유율을 확보한 기업들은 정보 장벽 덕분에 경쟁에 있어 어느 정도 유리한 입지를 선점한다고 볼 수 있습니다.

하지만 상당수의 COSS는 적절한 정보 장벽을 형성하지 못하고 있는 것으로 보입니다. 클라우드 업체는 이미 노출된 core의 소스를 가져와서 자사의 플랫폼에 적당히 이식하기만 하면 됩니다. COSS 업체 측에서는 클라우드 업체의 이러한 행태를 '노천 채굴'이라고 비난하지만, 이러한 시도를 실질적으로 저지할 마땅한 수단이 없는 것이 현실입니다.

이러한 현상은 MongoDB Case에서 뚜렷하게 관측됩니다.

2.1.2 MongoDB Case

fifty

대형 클라우드 업체의 Software as a Service(SaaS)로 인해 기존 오픈소스 기반 비즈니스를 진행하던 기업들은 기존 비즈니스 모델을 전면적으로 수정해야 하는 상황에 놓여 있습니다.

MongoDB의 비즈니스 모델은 소스코드를 무료로 제공하고, 소스코드를 이용한 개발과 운영에 필요한 관련 서비스(Managed Service)를 유료로 제공하여 수익을 창출하는 Open-core 모델입니다. MongoDB의 Atlas는 이러한 비즈니스 모델의 일환이자 주된 수익원입니다.

Amazon의 AWS, Google의 GCP와 같은 클라우드 업체는 MongoDB Core를 기반으로 자체적인 SaaS를 구축하여 제공해 왔습니다. 클라우드 업체의 이러한 움직임은 MongoDB의 Cash-cow인 Atlas의 수익성 악화를 초래했습니다.

이에 MongoDB는 2018년 10월, 자사 소프트웨어의 라이선스를 AGPL 라이선스에서 AGPL 기반 SSPL 라이선스로 변경했습니다. 클라우드 업체가 오픈소스를 활용하기만 하고 소스코드에 기여하지 않는다는 것이 라이선스 변경의 표면적인 이유였지만, 실질적으로는 클라우드 업체의 SaaS로 인한 자사 서비스의 수익성 악화를 개선하고자 하는 움직임으로 분석할 수 있을 것입니다.

Core의 소스코드를 제한 없이 활용할 수 있었던 AGPL 라이선스와는 달리 SSPL 라이선스는 클라우드 업체가 MongoDB를 SaaS로 제공하는 것을 제한합니다. SSPL이 적용된 MongoDB는 다른 영역에서는 이전과 동일한 이용을 보장하지만, 클라우드 업체에서 MongoDB를 SaaS로 제공하고자 할 경우 MongoDB가 적용된 소프트웨어 전체의 소스코드를 공개해야 합니다.

AWS는 이에 대응하기 위해 2019년 1월, DocumentDB를 출시합니다. DocumentDB는 MongoDB의 소스코드를 직접적으로 사용하지는 않지만 MongoDB API에 대한 호출을 지원하고 Atlas와 유사한 경험을 제공합니다. 또한 MongoDB의 소스코드를 직접 사용하지 않기 때문에 SSPL의 SaaS 관련 조항을 회피하면서 기존 서비스를 그대로 제공할 수 있습니다.

클라우드 업체에서 제공하는 SaaS는 클라우드와 통합된 소비자 경험을 제공하여 소비자들에게 오히려 더 나은 benefit을 제공할 수 있습니다. 이러한 외부 요인들로 인해 MongoDB는 소프트웨어 자체의 가파른 성장에도 불구하고 수익성이 악화되는 아이러니한 상황에 처해있습니다.

2.1.3 결론

결론적으로, IT Infrastructure 분야의 거의 모든 COSS는 일정 규모 이상으로 성장한 이후에는 빅테크 기업과의 협업, 혹은 경쟁이라는 양자택일 상황에 놓이게 됩니다. 운이 좋을 경우 빅테크 기업의 플랫폼 서비스 위에서 서비스를 제공하며 수익을 창출할 수 있겠지만 결국 플랫폼 서비스가 절대적인 권력을 가집니다. 이러한 권력 구조에 불만이 있는 사업자는 독자적인 비즈니스를 전개할 수도 있겠지만 이 또한 대등한 경쟁을 기대하기는 어렵습니다.

이를테면, IT Infrastructure 분야의 COSS들은 AWS 위에서 AWS보다 나은 서비스를 제공해야 하는 난해한 상황에 놓여있는 것입니다. 이는 오픈소스 커뮤니티와 COSS 기업들에게 달갑지 않은 상황이겠지만, 상당수의 COSS는 이러한 상황에 대한 적절한 해결책을 제시하지 못하고 있는 것 같습니다.

해당 케이스는 OSS와 비즈니스를 동일시하는 것이 전략적으로 굉장히 큰 리스크를 동반할 수 있음을 시사합니다. 완전히 공개된 소프트웨어를 바탕으로 사업을 전개하게 될 경우, 신규 진입자에 대한 저항성이 굉장히 떨어질 수밖에 없습니다. 이는 기업이 오픈소스 기반 비즈니스를 계획하고 있을 경우 반드시 고려해야 하는 문제입니다.

오픈소스 기반 비즈니스를 계획하는 창업자, 혹은 기업은 OSS의 기술력과 고객층이 사업적 경쟁 우위로 이어질 것이라는 나이브한 가정을 버려야 합니다. 물론 기술적 성취를 위해 오픈소스 개발을 진행할 경우에는 이러한 문제가 크게 중요하지 않을 수도 있지만, OSS로부터 직접적인 수익을 기대하는 경우에는 OSS와 어느 정도 거리를 두는 별개의 BM을 강구해야 할 것입니다.

2.2 제한적 비즈니스 모델

2.2.1 Mapbox Case

fifty

해당 케이스를 다루기에 앞서 Mapbox의 라이선스 변경에 대한 상황을 간략하게 정리한 포스팅을 먼저 소개하고자 합니다.

Mapbox gl is no longer open source

위 포스팅을 요약하면, 지도 관련 기능을 제공하던 Mapbox GL JS가 BSD 라이선스를 포기하고 2.0 버전부터는 proprietary license로 전환하였으며 커뮤니티는 이러한 결정에 반발하며 비슷한 기능을 제공하는 MapLibre GL로 이주하는 등의 방법을 강구하고 있다는 내용입니다.

오픈소스 프로젝트였던 Mapbox가 갑작스럽게 라이선스 변경이라는 초강수를 둔 것에는 외부 투자자들의 압력이 어느 정도 작용한 것으로 보입니다. Mapbox 디자이너 Saman Bemel Benrud는 자신의 트위터에서 Mapbox가 VC의 투자에만 의존하지 않는, 지속 가능한 BM을 확보하기 위해 이러한 결정을 내렸다고 밝혔습니다.

Disruption by undercutting costs via VC subsidies is still a thriving business model, and it just creates unsustainable products while destroying the thing that existed before. Mapbox is trying to become sustainable, finally, and I’m here for it.

Mapbox 특성상 수익을 창출하기 위해서는 API 이용에 비용을 부과해야 할 필요성이 있었는데, BSD 라이선스 하에서는 이러한 BM을 확보하는 것이 불가능했기 때문입니다. Mapbox의 핵심적인 라이브러리인 Mapbox-gl-js는 기존에도 API 과금을 통해서 어느 정도의 수익을 창출하고 있었지만, BSD 라이선스를 채택하고 있었기 때문에 기존 코드를 fork 하는 것만으로도 과금을 손쉽게 회피할 수 있었습니다. 따라서 Mapbox는 본격적인 API 기반 구독형 BM을 구축하는 과정에서 자연스럽게 Mapbox-gl-js의 라이선스를 proprietary license로 전환하게 됩니다.

Mapbox와 비슷한 BM을 바탕으로 사업을 전개하는 COSS case는 plotly가 존재합니다. plotly는 데이터 시각화 기능을 제공하는 오픈소스 라이브러리입니다. 라이선스를 변경한 Mapbox와 달리 plotly는 여전히 core 모듈을 MIT license로 제공할 뿐만 아니라, API 호출도 무료로 제공하고 있습니다. 하지만 API를 활용한 시각화 및 분석을 편리하게 진행하기 위해서는 plotly의 SaaS 구독 서비스를 이용해야 합니다. 이는 MongoDB와 비슷한 BM을 채택하고 있다고 볼 수 있습니다.

Mapbox는 서비스 특성상 plotly와 같은 SaaS에 대한 수요가 제한되었고, 따라서 API 호출에 직접적으로 비용을 부과하기 위해 라이선스 변경을 감행한 것으로 보입니다.

Mapbox의 경우, 오픈소스를 통해 폭넓은 사용자층과 기술적 완성도를 확보하는 데는 성공했지만 오픈소스를 유지하면서 투자자들의 요구를 충족시킬 만한 매출을 제공할 수 있는 BM을 구축하는 것은 어렵다고 판단한 것 같습니다.

오픈소스의 경쟁우위는 강력한 커뮤니티에 기반한 혁신에서 비롯됩니다. 이러한 강점을 포기한 Mapbox의 비즈니스가 과연 순탄하게 진행될 수 있을지는 조금 더 지켜봐야 할 것 같습니다.

2.2.2 결론

오픈소스 프로젝트 자체를 직접적으로 사업화하는 것이 일반적인 독점 라이선스에 비해 어렵다는 것은 부정하기 어렵습니다. 소프트웨어 자체를 상품으로 볼 수 있는 독점 소프트웨어와 달리 오픈소스 소프트웨어는 프로젝트와 관련된 서비스 제공을 통해서만 수익 창출이 가능하기 때문입니다.

이 때문에 오픈소스 프로젝트의 기술적 성공과 사업적 성공은 어느 정도 맥락을 같이하지만, 기술적 성공이 사업적 성공을 무조건 보장하지는 않습니다. 이는 경쟁우위 및 차별화 문제 챕터에서 언급한 문제점과도 맥을 같이합니다.

3. 오픈소스의 강점

앞서 설명한 단점들에도 불구하고, 오픈소스가 강력한 혁신 방법론이라는 사실은 분명합니다. 서두에서 언급한 대기업의 오픈소스 참여 움직임은 이러한 맥락에서 이해될 수 있습니다. 오픈소스는 커뮤니티에 기반하여 혁신을 창출하는 강력한 방법론이고, 소프트웨어를 이용하는 이용자 입장에서도 분명한 강점을 가집니다.

3.1 혁신 모델로서의 강점

커뮤니티 기반 혁신 관점에서 오픈소스는 기술과 아이디어를 발전시키고 혁신하는데 특화되어 있습니다. 이는 새로운 기술을 빠르게 발전시키고자 하는 기업, 혹은 개인에게 유용하게 작용할 수 있는 강점입니다.

특히 기업은 오픈소스를 활용하여 개발을 진행함으로써 새롭게 주목받는 기술 영역에 대한 발전을 촉진하고 다양한 시장 수요를 파악하는데 전략적 이점을 취할 수 있을 것으로 기대됩니다.

3.1.1 Private-Collective Innovation Model

오픈소스는 경제적 관점에서 봤을 때 '프로세스 혁신' 모델의 일종으로 분류할 수 있습니다.

혁신 모델이란, 조직 혹은 집단의 혁신을 효과적으로 촉진하기 위한 방법론입니다. 혁신 모델은 개인이 생산하는 가치(goods)에 대한 소유권과 보상 방법에 따라 Private Investment 모델과 Collective action 모델로 구분됩니다.

Private Investment 모델에서는 개인이 창출하는 아이디어에 대한 소유권을 인정하고 보상합니다. 이 모델은 개개인의 아이디어에 대한 소유권을 인정하고 보상한다면 보상에 대한 동기로 인해 혁신이 촉진될 것이라고 가정합니다. 즉, 이 모델은 기여 동기를 통해 혁신을 촉진하고자 합니다.

반면, Collective action 모델에서 개개인이 창출한 아이디어는 특정 개인에게 귀속되지 않습니다. 이 모델에서는 개인의 아이디어가 커뮤니티에 공개되어 공공재로 취급된다면, 아이디어(혹은 지식, 가치) 사이의 시너지 효과로 인해 혁신이 촉진될 것이라고 가정합니다. 즉, 협업 동기를 핵심적인 동기로 놓습니다.

결론적으로 두 모델은 각각 협업 동기의 부재, 기여 동기의 부재로 인해 대규모 협업을 효과적으로 촉진시키는 방법을 명확하게 제시하지 못하였습니다. 각 모델의 한계를 보완하기 위해 절충적인 방안들이 시도되었지만 문제에 대한 근본적인 해결책은 아니었습니다.

Eric von Hippel, Georg von Krogh(2003)의 연구*3*는 혁신 모델로서 오픈소스가 갖는 강점을 구체화합니다. 위 논문에 의하면 오픈소스는 Private Investment 모델의 기여 동기와 Collective action 모델의 협업 동기를 적절하게 결합하는 'Private-Collective Innovation Model'의 형태를 취합니다.

Private-Collective Innovation Model에서 중요한 과제는, 협업 동기를 파괴하지 않으면서도 집단에 기여하는 개개인에게 적절한 인센티브를 제공할 수 있어야 한다는 것입니다. 여기서 '적절하다'는 것은, 코드를 공개할 때 발생하는 기회비용을 초과하는 정도의 인센티브를 의미합니다.

오픈소스는 Selective Incentive와 강력한 커뮤니티를 통해 이러한 과제에 대한 훌륭한 답변을 제시합니다. Selective Incentive란, 프로젝트의 기여자에게만 주어지는 긍정적 인센티브를 의미합니다. 이는 Private Investment 모델이 제공하는 개인적인 보상과 비슷합니다. 하지만 Private-Collective Innovation Model에서 주어지는 인센티브는 Private Investment 모델에 비해 비물질적인 형태로 주어지는 경우가 많습니다.

논문에서는 오픈소스 기여를 통해 기여자가 얻을 수 있는 Selective Incentive를 다음과 같이 제시합니다.

기여 과정에서의 학습
사용자로서의 편의(Scratching itchy)
커뮤니티에서의 인정

이러한 인센티브는 free rider에게는 주어지지 않고 오픈소스에 기여한 기여자에게만 선택적으로 주어집니다. Selective Incentive는 직접적인 monetary 인센티브를 제공하지는 않지만, 노동 시장에서 자신의 가치를 향상시킴으로써 잠재적으로 더 큰 편익을 제공할 수 있습니다.

이때, Selective Incentive를 극대화하는 것은 '해커 문화에 기반한 강력한 커뮤니티'입니다. 해커 문화의 특성은 다음과 같이 요약됩니다.

자유로운 분위기에서
새로움과 자기 발전을 추구하고
커뮤니티 내의 인정을 중시한다.

해커 문화 에 기반한 강력한 커뮤니티에서, 능력 있는 개발자(Core 개발자)는 신규 진입자와 기여자들의 학습을 효과적으로 보조하고 프로젝트를 부스팅합니다. 또한, 많은 기여자가 존재할수록 자신이 필요해서 기여한 코드의 완성도가 높아집니다. 마지막으로, 커뮤니티가 강력할수록 커뮤니티가 기여자들에게 제공하는 소속감과 인정의 강도는 커집니다.

해커 문화에 기반한 Selective Incentive를 통해 오픈소스는 이용자 수요를 효과적으로 반영하면서 자유롭고 확산적인 혁신을 수행할 수 있습니다.

정리하면, 오픈소스는 새로운 아이디어를 바탕으로 혁신을 창출하는 효과적인 프레임워크입니다. 최근에는 의욕적인 개인, 단체뿐만 아니라 기업들도 혁신 모델로서의 오픈소스에 주목하여 다양한 목적으로 오픈소스 기반 개발에 참여하고 있습니다.

3.1.2 Openpilot Case

eighty

CommaAI-DeepDrive 커뮤니티 사이에서 발생한 상호작용은 오픈소스 개발 과정에서 커뮤니티의 힘을 보여주는 대표적인 예시가 될 수 있습니다. CommaAI는 'Openpilot'이라는 오픈소스 자율주행 프로젝트를 진행하는 기업입니다.

CommaAI는 설립 초기, 자체 수집한 데이터를 바탕으로 학습을 진행하여 초기 형태의 자율주행 소프트웨어를 만들어 냅니다. 하지만 CommaAI는 전통적인 자율주행 플레이어들과 달리 소규모 기업이었습니다. 따라서 여타 프로젝트와 비교했을 때 데이터 측면에서도, 개발 역량 측면에서도 굉장히 부족할 수밖에 없었습니다.

하지만 CommaAI는 기발한 방안을 고안합니다. CommaAI가 주목한 프로젝트는 대형 자율주행 프로젝트가 아니었습니다. CommaAI는 오히려 비슷한 위치에서 취미 수준으로 개발되고 있던 여러 자율주행 프로젝트에 주목합니다.4 대표적인 프로젝트는 오픈소스 자율주행 프로젝트인 DeepDrive였습니다. DeepDrive는 당시 유명한 시뮬레이션 게임인 GTA 5를 활용한 자율주행 프로젝트를 진행하고 있었습니다.

데이터셋에서 확인할 수 있듯이, 취미 수준에서 개발되던 프로젝트들은 완성차 업체의 다듬어진 프로젝트들이 신경 쓰지 않는 분야에 주목합니다. CommaAI는 자체 수집한 데이터를 공개함으로서 취미 프로젝트에 활용할 수 있게 했고, 취미 프로젝트를 진행하던 열정적인 개발자들은 CommaAI가 공개한 주행 데이터를 활용해 자체적인 모델 구축을 진행합니다. 더 나아가서, CommaAI의 주행 모델을 다양한 오픈소스 프로젝트 위에서 구동할 수 있게 합니다.

이를 통해 CommaAI가 얻은 것은 두 가지입니다. 우선, 자율주행에 열정을 가진 재야의 고수들을 CommaAI의 커뮤니티에 편입시키는 데 성공합니다. 또한 다양한 프로젝트 간의 상호작용을 통해 CommaAI의 모델과 데이터를 검증하고, 가상 환경에서 수십만번 이상의 시뮬레이션을 자발적으로 발생하도록 하는 데 성공합니다.

결과적으로 CommaAI의 Openpilot은 2020년 컨슈머리포트 발표에서 대형 완성차 업계의 오토파일럿을 모두 제치고 소비자 만족도 1위에 선정됩니다.5 Openpilot이 github에 처음 공개된 것이 2017년임을 고려했을 때, 이는 놀라운 성취입니다. 이는 완전자율형 오토파일럿이 아닌 ADAS(운전자 보조 시스템) 부문의 성과이긴 하지만 자율주행 업계의 리더로 주목받고 있는 모빌아이 또한 ADAS에서 시작했다는 점을 고려했을 때, Openpilot의 성과는 충분히 유의미하다고 평가될 수 있습니다.

위 사례에서 확인할 수 있듯이, 오픈소스는 혁신에 있어 예상하기 어려울 정도의 시너지 효과를 발휘하곤 합니다. 이는 오픈소스가 갖는 '혁신 모델'로서의 특성에서 기인한다고 분석됩니다.

3.2 제품(Software)으로서의 강점

앞서 확인한 혁신 모델로서의 강점은 오픈소스 프로젝트를 직접 주도하고 개발하고자 하는 기업들에게 유용하게 작용할 수 있는 특성입니다. 즉, 오픈소스라는 '방법론'의 강점이었습니다.

이에 비해, 단순 이용자 입장에서는 상술한 강점을 직접적으로 체감하기는 쉽지 않습니다. 이용자들이 OSS를 채택하고자 하는 유인은 혁신 모델로서의 강점보다는 OSS가 갖는 제품으로서의 강점에서 기인한다고 보는 것이 적합할 듯합니다. 이용자들은 방법론으로서의 강점보다는 제품 자체로서의 강점에 주목합니다. 제품(소프트웨어)으로서의 강점은 일반적인 독점 소프트웨어와 비교했을 때 두드러집니다.

제품으로서의 강점은 오픈소스 개발 기업, 오픈소스 이용 기업, 그리고 일반 이용자들에게까지 공통적으로 작용합니다. 오픈소스 프로젝트를 직접 개발하고 이를 바탕으로 사업을 전개하고자 하는 COSS 사업자들에게는 OSS가 이용자, 즉 잠재 고객들에게 부가적인 benefit을 제공한다는 점에서 유의미합니다.

또한 기업은 오픈소스를 직접 개발하지 않고, 기존 OSS를 '활용' 하여 사업을 전개할 수도 있습니다. 오픈소스를 활용하여 독자적인 소프트웨어를 개발하고자 하는 기업 입장에서는, OSS 채택을 통해 제품 개발 비용을 절감하고 개발 프로세스를 간략화하는 등 다양한 이점을 누릴 수 있습니다.

다음 챕터에서는 OSS가 독점 소프트웨어에 비해 강점을 가지는 구체적인 요인들에 대해 확인합니다.

3.2.1 구체적인 차별화 요인

현 Amazon Principal product manager 'Casson'과 전 Google Trust, Strategy & Engineering Principal인 'Ryan'은 2006년 연구에서 OSS가 독점 소프트웨어와 차별화될 수 있는 요인들을 아래와 같이 제시합니다.6

Security
Affordability
Transparency
Perpetuity
Interoperability
Localization(Customization)

해당 연구에서는 오픈소스 소프트웨어 채택이 위와 같은 특성을 가짐으로써, 기업들에게 정책적(전략적) 이점을 제공할 수 있다고 주장합니다. 다만 논문상의 설명이 다소 추상적이기 때문에 조금 더 구체적인 설명을 제시하고자 합니다.

대표적인 COSS 기업 Redhat은 이용자들이 독점 소프트웨어가 아닌 OSS를 채택해야 이유를 더 구체적으로 제시합니다. 7

동료 평가: 소스 코드에 누구나 액세스할 수 있으며 오픈소스 커뮤니티 자체도 활발하기 때문에, 오픈소스 코드는 동료 프로그래머에 의해 적극적으로 검토 및 개선될 수 있습니다. 침체 상태에 놓인 비공개 코드보다 훨씬 살아 있는 코드라고 간주할 수 있을 것입니다.
투명성: 오픈소스를 사용하면 해당 코드에서 어떤 종류의 데이터가 어디로 이동했는지, 어떤 변경 사항이 있었는지 정확하게 파악해야 하는 경우 벤더에 의존할 필요 없이 직접 이를 확인 및 추적할 수 있습니다.
안정성: 독점 코드의 경우 해당 코드의 업데이트, 패치, 작업을 제어하는 단일 작성자 또는 기업에 의존해야 합니다. 오픈소스 코드는 활발한 오픈소스 커뮤니티를 통해 지속적으로 업데이트되므로 오래 지속되고 오픈 표준과 동료 평가를 통해 테스트 역시 적절한 방식으로 자주 이루어집니다.
유연성: 오픈소스는 수정을 강조하므로, 오픈소스 코드를 사용해 자신의 비즈니스 또는 커뮤니티에서 겪고 있는 고유한 문제를 해결할 수 있습니다. 해당 코드를 특정한 방식으로만 사용해야 한다는 법이 없으므로, 새로운 솔루션을 구현할 때 커뮤니티의 도움을 받고 동료 프로그래머에게 검토받을 수도 있습니다.
비용 절감: 오픈소스 코드 자체가 무료입니다. Red Hat과 같은 기업을 활용하는 경우 지원 서비스, 보안 강화, 상호 운용성 관리와 같은 부분에 비용을 지불하게 됩니다.
벤더 종속성 없음: 오픈소스 코드를 언제 어디에든 가져가 원하는 목적으로 사용할 수 있으므로 사용자 중심의 자유를 누릴 수 있습니다.
오픈 협업: 활발한 오픈소스 커뮤니티 덕분에 하나의 관심 그룹 또는 기업에 의존하지 않고 다양한 지원, 리소스, 관점을 접할 수 있습니다.

이처럼 OSS는 오픈소스 채택을 고려하는 이용자들에게 강력한 이점을 제공할 수 있습니다. 다음 챕터에서는 상술한 강점을 바탕으로 비즈니스를 전개한 스타트업 'HYPERCONNECT' 케이스를 확인합니다. 이를 통해 OSS 채택이 비즈니스에 이점을 제공하는 실질적인 사례를 제시하고자 합니다.

3.2.2 HYPERCONNECT Case

eighty

Azar와 Hakuna live로 알려진 HYPERCONNECT(이하 HC)는 오픈소스를 제품 개발에 적극적으로 활용하여 신규 소프트웨어 개발 비용을 획기적으로 절감합니다. 해당 케이스에서는 오픈소스의 유연성과 경제성(비용 절감), 그리고 벤더 종속성 없음이라는 강점이 확인됩니다. 본격적인 분석에 앞서 HC가 개발한 소프트웨어에 대해 간략하게 살펴봅니다.

우선, Azar는 WebRTC*8* 를 이용한 실시간 영상 커뮤니케이션 어플리케이션입니다. 이는 인터넷 이용자들 사이에서 인기를 끌었던 '랜덤 채팅'에 영상 커뮤니케이션 기능을 도입한 형태의 서비스로 볼 수 있습니다. Azar는 대화 상대 선택 기능을 유료로 제공하여 수익을 창출하는 BM을 채택하고 있으며, 전체 이용자의 90% 이상이 해외 이용자로, 해외 시장에서 좋은 반응과 성장세를 보이고 있습니다.

Hakuna Live는 라이브 스트리밍 어플리케이션입니다. 기존 스트리밍 서비스들의 시청자들은 채팅을 통해서만 소통할 수 있었던 반면, Hakuna Live는 시청자들이 직접 영상을 통해 소통할 수 있는 기능을 제공합니다. Hakuna Live의 주 수익원은 인앱 donation 수수료로, 2020년 한국 구글플레이 비게임앱 수익 2위를 기록하기도 했습니다. 해당 어플리케이션 또한 WebRTC를 기반으로 제작되었습니다. 부가적으로는 WebRTC를 활용한 기업용 영상 미팅 솔루션과 영상 처리 관련 AI 기술을 연구하고 있습니다.

주목할 만한 사항은, HC가 개발하는 거의 모든 서비스와 소프트웨어에 WebRTC라는 오픈소스 라이브러리를 적극적으로 활용하고 있다는 점입니다. WebRTC (Web Real-Time Communication)는 웹 브라우저 간에 플러그인의 도움 없이 서로 통신할 수 있도록 설계된 API입니다. 이는 W3C에서 제시된 초안이며, 음성 통화, 영상 통화, P2P 파일 공유 등으로 활용될 수 있습니다.

HC는 WebRTC 테크 스타트업 초기에 요구되는 막대한 R&D 비용을 획기적으로 절감한 것으로 보입니다. 또한 초기 Azar 개발 과정에서 확보한 WebRTC 개발 노하우를 활용하여 다른 소프트웨어 개발에 적극적으로 활용함으로써 기반 기술에 대한 추가적인 투자를 최소화하며 새로운 소프트웨어 상품을 시장에 출시할 수 있었습니다.

결과적으로, 수익성 문제로 많은 어려움을 겪는 대부분의 스타트업과는 달리 HC는 2019년 이후 지속적인 흑자를 기록하고 있습니다. 많은 테크 유니콘들이 대부분 적자에서 벗어나지 못하고 있음을 고려했을 때 이는 고무적인 성과입니다. HC case에서 특기할 만한 점은, 대부분의 스타트업이 사업 초기 발생하는 막대한 출혈을 투자로 보충하며 R&D를 수행하는 반면 HC는 설립 첫해인 2014년부터 영업이익을 창출해 왔다는 점입니다.9

이러한 성과가 전적으로 오픈소스 채택에 의한 것이라고 할 수는 없을 것입니다. 하지만 오픈소스의 유연성과 경제성이 서비스 구축에 요구되는 개발 비용과 운영 비용을 줄이는 데 상당히 기여했을 것으로 추측됩니다.

4. 오픈소스 커뮤니티

3.1에서 언급한 것처럼, 오픈소스 커뮤니티는 오픈소스라는 방법론이 성립할 수 있게 하는 핵심적인 요소입니다. 오픈소스 커뮤니티의 구성원들은 소스코드를 향상시키고, 소스코드를 이용하며, 나아가서는 열정적인 evangelist로서 커뮤니티 확장에도 기여하곤 합니다. 따라서 성공적인 커뮤니티를 구축하는것은 성공적인 오픈소스 프로젝트를 진행하기 위한 필요충분조건이라고 해도 과언이 아닙니다.

이어지는 챕터에서는 성공적인 오픈소스 커뮤니티의 조건에 대해 확인하고, 오픈소스 프로젝트가 성장하고 사업화되는 과정에서 흔히 제기되는 커뮤니티의 동기 부여 문제에 대해서 탐구합니다.

4.1 Factors affecting the success of Open Source Software

4.1.1 Success of Open Source Software

본격적인 분석에 앞서, '성공적인' OSS에 대해 정의할 필요가 있습니다. 혹자는 Pytorch와 같이 기술 발전에 크게 기여하고 있는 프로젝트를 성공적이라고 주장할 수 있을 것이고, 또 누군가는 MongoDB와 같이 높은 매출과 시가 총액을 보여주는 프로젝트를 성공했다고 주장할 것입니다.

'Factors affecting the success of Open Source Software'논문*10* 에서는 오픈소스의 '성공'을 Market Success와 Technical Success로 구분합니다. Market Success는 OSS의 다운로드 횟수, Technical Success는 프로젝트에서 발생한 commit 발생 빈도를 기준으로 규정합니다.

해석하면 Market Success는 OSS가 얼마나 많은 이용자를 확보하고 있는지, Technical Success는 OSS 개발이 얼마나 활발하게 진행되고 있는지를 기준으로 측정됩니다. 이용자와 개발자는 오픈소스 커뮤니티를 이루는 핵심적인 요소이기 때문에 두 지표에 기여하는 요인을 오픈소스 커뮤니티의 성공에 기여하는 요인으로 유추할 수 있을 것입니다.

이때, 주의해야 할 것은 논문에서 언급하는 Market Success가 상업적 성공을 의미하는 것은 아니라는 점입니다. 앞선 케이스들에서 확인한 것처럼 오픈소스 프로젝트의 이용자 수는 기업이 투자를 유치하고 사업을 확장하는 데 있어서 중요한 요소로 작용할 수 있지만, 사업의 수익성과 직결되는 요소는 아닙니다. 따라서 논문에서 이야기하는 오픈소스의 'Market Success'는 수익성 있는 사업을 위한 필요조건이지만 충분조건은 아닙니다.

사실, COSS의 수익성에 대한 결론을 내리기에는 관련된 연구와 논의가 부족한 실정입니다. 오픈소스를 활용하는 전략의 양상과 기업의 상황에 따라 그 양상이 매우 다르게 나타나기에 일반화된 결론을 도출하는 것은 유보하는 것이 옳다고 판단하였습니다.

그럼에도 Technical Success와 Market Success에 기여하는 요인들을 선정함으로써 오픈소스 프로젝트와 커뮤니티를 활성화하기 위한 최소한의 요건을 확보할 수 있을 것으로 기대하며 해당 연구를 소개합니다.

4.1.2 Paper review

리뷰는 핵심적인 요소에 대한 설명과 결론 위주로 간략하게 진행하고자 합니다. 해당 논문에서는 성공에 영향을 주는 요인을 크게 내재적 요인과 외재적 요인으로 구분합니다.

외재적 요인은 다시 license type, user base, developer base, language translations, responsibility assignment로 구분되고 내재적 요인은 complexity, modularity로 구분됩니다.

각 요인은 코드 외적인 요인인지, 혹은 코드 외적인 요인인지에 따라 분류됩니다. 좀 더 쉽게 이야기하면, 내재적 요인은 프로젝트를 이루는 코드 자체의 특성이고 외재적 요인은 오픈소스 커뮤니티 특성에 대한 요인입니다.

ninety

위 도표에서 확인할 수 있는 것처럼, 논문에서는 각 요인들과 성공의 상관관계에 대한 가설을 설정하고 이를 검증하고자 합니다. 결과 확인에 앞서 각 요인들에 대해 간략하게 설명합니다.

Extrinsic Cues

License Type - 라이선스 타입이 제한적인가?
User Base - 이전 버전과 비교했을 때, 많은 이용자들이 현재 버전을 지속적으로 이용하고 있는가?
Developer Base - 이전 버전과 비교했을 때, 많은 개발자들이 현재 버전을 지속적으로 개발하고 있는가?
Lang. Translations - 오픈소스 프로젝트가 얼마나 많은 언어로 번역되었는가?
Responsibilty Assignment - 개발자들에게 책임감을 부여할 수 있는 구조가 마련되어 있는가?

Intrinsic Cues

Complexity - 구조적인 복잡성이 높은가?
Modularity - 분업이 가능하도록 모듈화가 진행되어 있는가?

각 요인들에 대한 가설 검정 결과는 다음과 같습니다.

full

위 결과에서 T값들은 오픈소스 개발 초기, 중기를 거쳐 연구 진행 시점까지의 단계를 4단계로 나눈 시계열을 의미합니다. t1은 최초의 버전이고, t2는 프로젝트가 시작된 지 3개월 이내의 기간입니다. t3은 최초 버전 이후 6개월에서 9개월이 경과한 기간이며, 마지막으로 t4는 9개월 이후의 기간을 의미합니다.

해당 결과에서 주목해야 할 부분은 H3, 즉 user base와 developer base 요인과 관련된 가설입니다. 논문의 저자 또한 H3 가설을 설명하기 위해 가장 많은 분량을 할애하기도 했습니다.

사실 H3 가설을 제외한 다른 가설들의 검정 결과는 너무 당연하거나 유의미한 상관관계를 보여주지 못했습니다. 예를 들어, intrinsic cues의 경우에는 코드가 잘 모듈화되고 가독성 있는 구조를 가지면 기여가 증가한다는, 직관적으로 추측 가능한 결과를 제공합니다. 이러한 요인들은 분명히 중요하지만, 이에 대해 구체적으로 다루는 것은 큰 의미가 없다고 생각되기에 실질적인 의미를 도출할 수 있는 일부 요인들을 중점적으로 확인하고자 합니다.

H3a 가설부터 확인해 보면, user base는 t2와 t3에서 어떤 가설들보다 강력한 market success와의 상관관계를 갖고 t4에서는 이전 단계에 비해 조금 낮아진 상관관계를 가집니다. 연구에서는 이러한 현상을 diffusion sigmoidal curve로 설명합니다.

eighty

Rogers(1995)의 혁신 확산 이론에 따르면 새로운 제품이나 기술 전파는 위와 같은 sigmoidal curve의 형태로 진행됩니다. 시장에 출시된 제품이나 기술은 서서히 증가하다가 급격한 성장기를 맞고 이후 다시 성장이 둔화되는 추세를 보입니다. User base는 활성 이용자를 의미하기 때문에 위 curve에서 adopters와 같은 의미로 해석될 수 있습니다.

해석 결과를 위 curve에 대입해 보면 t2와 t3는 각각 'a'와 'b'를 의미하고, 이후 t4 단계는 성장이 다시 완만해지는 단계를 의미합니다. 이를 통해 오픈소스 프로젝트의 확산 주기가 sigmoidal curve의 패턴을 어느 정도 따를 것이라고 추측할 수 있습니다.

오픈소스 프로젝트를 sigmoidal curve로 설명할 수 있다고 가정했을 때 전략적으로 가장 중요한 과제는 'critical mass'를 최대한 빨리 확보하는 것입니다.

Critical mass란 위 cycle이 작동할 수 있을 만한 최소한의 adopters를 의미합니다(Schoder, 2000). Critical mass에 도달하지 못하면 이용자 수는 굉장히 천천히 늘어나기 때문에 제품의 성공은 보장되지 않습니다. 또한 일단 crital mass를 충족시키고 나면 adopters들은 기존의 제품을 계속 이용합니다. 간략하게 정리하면, critical mass를 최대한 빨리 충족시키는 프로젝트가 시장의 adopters를 흡수하고 유지할 수 있는 winner-takes-all 구조를 가집니다.

연구는 프로젝트 초기에 적절한 라이선스를 설정하고 관심도와 활동성을 높게 유지함으로써 critical mass를 빠르게 확보할 수 있을 것이라고 제안합니다.

H3b와 H3c 가설 또한 또한 흥미로운 결과를 보여줍니다.

두 가설은 각각 t1과 t2, 즉 프로젝트 초기에 굉장히 프로젝트 성공과 높은 상관관계를 보였습니다. 하지만 초기 단계 이후에는 오히려 프로젝트 성공과 음의 상관관계를 보이거나 무의미한 관계성을 보입니다. 이는 더 많은 개발자가 더 좋은 성과를 도출할 것이라는 일반적인 예측과는 상반되는 결과입니다. 연구에서는 이러한 현상이 나타나는 이유로 두 가지를 제시합니다.

우선, 프로젝트 진행에 따라 개발자 커뮤니티의 열정이 저하되는 경향성이 있습니다. 오픈소스 프로젝트 초창기에는 '가려운 곳을 긁기 위해서' 프로젝트 설립자 중심으로 활발한 기여가 이루어집니다(Raymond, 2001). 하지만 프로젝트가 성장함에 따라 새로운 개발자들이 유입되고, 이들은 초기 개발자들에 비해 낮은 수준의 개발 의욕을 보입니다.

또한 개발자 집단이 확대될수록 이들을 조율하고 관리하는 데 더 많은 자원을 투입해야 합니다. 코드 개발 이외의 활동에 자원이 투입됨에 따라 프로젝트 전반의 활동성은 저하됩니다. 또한 확대된 개발자 집단에서는 개발의 목적성이 일치되기 어렵기 때문에 forking 등으로 인해 개발 역량이 분산되기도 합니다.

종합하면, 오픈소스 프로젝트가 성공하기 위해서는 초창기에 열정적인 개발자 집단의 활동을 중심으로 확고한 이용자 층을 구축해야 합니다. 초기 단계를 넘어선 이후에는 오픈소스 개발자 커뮤니티에게 초기와 같은 수준의 동기부여를 제공하는 것은 훨씬 어려운 과제였고, 이후에는 코드 자체의 품질이 오픈소스 커뮤니티의 성공과 높은 상관관계를 보였습니다.

이후 단계에서 코드의 품질을 향상시키는 것은 결국 초기에 확보한 개발자 집단의 성과와도 연결됩니다. 결국 오픈소스 프로젝트의 성패는 초기에 열성적인 개발자군을 확보하는 것에 상당부분 좌우된다고 볼 수 있습니다. 이는 앞서 설명했던 오픈소스 커뮤니티의 중요성과도 일맥상통합니다.

4.2 오픈소스 커뮤니티의 중요성

4.2.1 오픈소스의 사업화와 커뮤니티의 붕괴

근본적인 문제는 사업화를 추구하면서 오픈소스의 기초적인 전제를 유지할 수 있을 것인가에 대한 물음입니다. 많은 오픈소스 프로젝트들은 사업화 과정에서 오픈소스의 기초적인 전제를 잃어갑니다. 자유로운 개발과 자유로운 이용, 그리고 이에 기반한 커뮤니티는 오픈소스를 규정하는 근본적인 선언과도 같습니다. 이러한 요소들이 전제되지 않고서는 앞서 설명한 혁신 모델로서의 강점이 전혀 발휘될 수 없습니다.

하지만 많은 기업들은 고객 수요 충족을 위해(아이러니하게도), 혹은 수익 창출을 위해 이러한 대전제들을 파괴하곤 합니다. 기업은 프로젝트의 라이선스를 변경하거나, 프로젝트의 일부 기능을 유료화함으로써 오픈소스 프로젝트를 사실상 사유화하곤 합니다.

이로 인해 제기되는 대표적인 문제점으로는 커뮤니티의 개발 의욕 상실입니다. 이런 식으로 사유화된 프로젝트들은 더 이상 스스로의 '가려운 곳'을 긁어주지 못합니다. 또한 기업에 소속되지 않은 개발자들은 자신이 개발한 코드가 기업의 수익 창출에 기여하고 있음에도 불구하고 기여분에 대한 보상을 받을 수 없습니다.

이로 인해 자발적인 커뮤니티는 개발 의욕을 잃고, 기업 소속 개발자들이 주도하는 형태로 개발이 진행되는 케이스를 꽤 많이 발견할 수 있었습니다. 이렇게 될 경우, 오픈소스는 상술한 커뮤니티의 강점을 누리기 힘들어집니다.

해당 사례를 구체화하기 위해서 아쉽게도 MongoDB의 사례를 한 번 더 살펴봐야 할 것 같습니다.

4.2.2 MongoDB Case

2020년 MongoDB financial report에 의하면*11*, MongoDB의 적자 폭이 지속적으로 확대되고 있는 것을 확인할 수 있습니다. 지출에서 가장 큰 비중을 차지하는 것은 흥미롭게도 stock based compensation 항목입니다. 이는 일종의 인건비 항목인데, 추가적인 사업 확장에 대한 정보를 공시하지 않은 MongoDB가 이러한 급격한 인건비 상승을 보인 것은 의구심이 드는 부분입니다.

MongoDB의 경우 매년 서비스 매출이 빠르게 성장하고 있지만 비용의 증가 폭이 매출 성장에 비해서 훨씬 높게 나타나고 있습니다. 이러한 비용 상승에는 빅테크 기업들과의 경쟁으로 인한 압력도 분명히 작용했을테지만, 이번 챕터에서는 비용 상승의 원인을 커뮤니티 붕괴의 관점에서 분석하고자 합니다.

현재 MongoDB core에 대한 외부 기여는 거의 없는 상태입니다. 실제로 MongoDB의 CEO인 Dev Ittycheria는 인터뷰에서*12* "금전적 보상을 고려하지 않는 개발자 집단을 대부분의 오픈소스 커뮤니티에서 찾아보기 힘들다"고 언급합니다. 이는 MongoDB가 처한 현재 상황을 압축적으로 보여줍니다. MongoDB CEO가 이야기한 것처럼, MongoDB 뿐만 아니라 많은 COSS 프로젝트가 금전적 보상 이외에 개발자들을 동기부여 할 수 있는 확실한 benefit을 제공하지 못하고 있습니다. 따라서 MongoDB와 같은 많은 COSS 기업들은 개발자를 직접 채용하여 소프트웨어를 개발합니다.

일반적으로 오픈소스를 규정하는 것이 다양한 개발자들에 의한 자유로운 기여와 오픈된 커뮤니티임을 고려했을 때, 이는 일반적인 오픈소스 프로젝트로 분류하기에는 어려움이 있습니다.

오픈소스가 물론 라이선스로 정의되기는 하지만, 자유로운 기여와 자유로운 이용이 오픈소스 기반 혁신의 핵심적인 전제라는 것을 고려했을 때, 현재 상황으로서는 프로젝트가 이미 사유화되었다고 봐도 무방합니다. 이처럼 커뮤니티가 자생적으로 작동하지 않을 경우 기업은 결국 사내 인력으로 개발을 진행해야 합니다. 이는 사실상 독점 소프트웨어의 개발 형태와 크게 다르지 않습니다. 단지 소비자 입장에서 약간의 차이가 존재할 뿐입니다.

기술기업의 특성상 지속적으로 혁신해야 하고, 빅테크의 진출로 인해 혁신에 대한 압력은 더욱 거세지고 있습니다. 하지만 프로젝트가 사유화되고 오픈소스의 특성을 잃어버리면서 개발자들을 동기부여 하기 위한 비용이 급격하게 증가하게 됩니다. 더 많은 개발자를 고용해야 하고 더 많은 비용을 지출해야 혁신 압력이라는 런닝머신에서 미끄러지지 않을 수 있습니다.

이처럼 오픈소스의 기초적인 동기와 전제를 잃어버린 상황을 MongoDB의 재정 악화 원인 중 하나로 지목할 수 있을 것 같습니다. 해당 케이스와 달리 사업 확장에도 불구하고 오픈소스의 초기 정신을 계승하며 훌륭한 비즈니스를 수행하고 있는 오픈소스 기업도 존재합니다.

4.2.3 Wordpress Case

fifty

Wordpress(이하 WP)는 사업과 프로젝트를 훌륭하게 분리하고, 철저한 모듈화를 통해 대규모 프로젝트로 진행된 이후에도 오히려 개발자 커뮤니티를 활성화시킨 대표적인 사례입니다.

WP core의 핵심 개발자들은 대부분 독자적인 모듈을 개발하여 판매하는 독립 개발자들입니다. 이는 MongoDB, Docker와 같은 대규모 오픈소스 프로젝트들이 사업화된 이후 사실상 모기업의 직원들에 의해 개발되고 있는 것과 극명한 대비를 이룹니다.

WP core의 개발자들은 WP에 호환되는 모듈을 개발하여 독립적으로 수익을 창출할 수 있고, 자신들의 모듈이 더 편리하게 이용될 수 있도록 core에 기여합니다. 이는 4.1에서 언급한 '가려운 곳을 긁어주는' 개발 양상과도 유사합니다. WP는 대규모 프로젝트로 성장했지만, 모듈화를 통해 커뮤니티 개발자들의 개발 의욕을 여전히 높은 수준으로 유지하고 있으며 모듈을 거래하는 데 있어 core 차원에서 별도의 수수료를 부과하지도 않기 때문에 성과 분배 논란에서 상대적으로 자유롭습니다.

그렇다면 WP는 과연 어떻게 커뮤니티를 훼손하지 않으면서도 수익을 창출할 수 있을까요? 이에 대한 해답은 WP의 모회사인 Automattic의 사업에서 확인할 수 있습니다.

굉장히 다양한 비즈니스를 진행하고 있어 링크로 대체합니다.

정리하면 Automattic은 WP를 활용하여 웹 컨텐츠 관리 영역 전반에서 다양한 비즈니스를 진행하고 있음을 알 수 있습니다. Automattic의 대표적인 WP기반 비즈니스 중 하나는 WP 전자상거래 플러그인인 'WooCommerce' 입니다. WooCommerce는 전자상거래 플랫폼 시장에서 32% 점유율을 보유하며 가장 큰 market share를 확보하고 있습니다.

이처럼 WP는 core 자체를 수익원으로 삼기보다는 core를 다방면으로 사업화하고 WP 기반 모듈을 직접 개발하고 판매함으로써 수익을 창출합니다. Core는 여전히 오픈소스이고, 커뮤니티의 개발자들 또한 WP와 관련된 비즈니스를 수행할 수 있는 권리가 보장됩니다.

사업과 프로젝트의 구조적인 분리를 통해 커뮤니티를 활성화시키고, 오픈소스의 장점을 그대로 가져가는 WP의 전략은 사업화 과정에서 어려움을 겪는 오픈소스 기업들에게 시사하는 바가 큽니다.

5. 결론

위 포스팅을 요약하면, '오픈소스는 훌륭한 제품이자 방법론이지만, 오픈소스만으로 사업을 진행하는 것에는 한계가 존재한다.'로 요약될 수 있습니다.

오픈소스는 커뮤니티 기반 혁신 방법론으로서 기존 개발 방법론과 차별화되는 강점을 갖고, 제품으로서도 독점 소프트웨어들에 비해 확고한 경쟁우위를 갖는 측면이 존재합니다. 하지만 이러한 강점들은 사업화를 진행하는 과정에서 오히려 기업측에 불리하게 작용할 수 있습니다.

커뮤니티 기반 혁신이라는 강점은 사업화 과정에서 오픈소스의 강점을 유지하기 어렵다는 문제가 존재하고, 제품으로서의 강점은 기업 입장에서 BM을 제한하고 수익성을 약화시키는 요인으로 작용할 수 있습니다.

결론적으로, 오픈소스 프로젝트와 비즈니스를 동일시해서는 안 됩니다. 오픈소스와 상업화의 전제가 많은 영역에서 충돌하기 때문에 둘을 종속적인 관점에서 파악하는 것은 바람직하지 않아 보입니다. 특히 프로젝트 자체를 사업화하려는 시도는 어려움을 마주할 가능성이 높습니다. 따라서 오픈소스 프로젝트 기반 사업화(COSS)를 시도하는 기업, 혹은 스타트업은 앞서 언급한 위협들에 대한 전략을 강구해야 할 것입니다. WP 사례와 같이 사업과 프로젝트를 분리해서 접근하는 전략은 대표적인 예시가 될 수 있을 것입니다.

COSS의 미래가 불투명한 상황에서 오픈소스 기반 사업화를 시도하는 기업들에게 매력적인 선택지 중 하나는 제품으로서의 오픈소스에 주목하는 것입니다. 기업은 오픈소스를 제품으로서 채택하고 활용함으로써 오픈소스의 강점은 가져가고, 오픈소스 비즈니스의 난점은 회피할 수 있습니다. 이 과정에서 기업은 오픈소스 프로젝트의 accelerator이자 중요한 contibutor가 될 수 있고, 되어야 합니다.

또한 초기 투자 유치가 절실한 테크 스타트업의 경우 초기 아이디어 발전과 검증 수단으로서 오픈소스를 채택할 수도 있을 것입니다. 오픈소스는 아이디어를 발전시키는 최고의 수단 중 하나이며, 기술력을 증명하기 위한 검증의 수단이기도 합니다. Openpilot은 아이디어 발전 수단으로서의 오픈소스에 대한 훌륭한 예시입니다. 물론 해외 빅테크 기업의 오픈소스 개발 참여 또한 아이디어 발전을 위한 대표적인 예시가 될 수 있습니다.

이처럼 오픈소스는 어떠한 강점을 어떻게 활용하는가에 따라 기업활동에 득이 될수도, 실이 될수도 있습니다. 오픈소스를 활용하고자 하는 기업은 이러한 측면을 분명히 고려하여 오픈소스를 기업활동의 어떤 부분에 활용할 것인가를 명확히 해야 할 것입니다.

스터디 자료 조사 과정에서 느낀 점은 국내에서는 아직 오픈소스와 오픈소스 기반 비즈니스에 대한 연구 및 논의가 활발히 이뤄지지 않고 있었다는 점입니다. 유수의 대기업들조차도 오픈소스 프로젝트 개발에는 큰 관심을 보이지 않았습니다. 이는 해외 빅테크 기업들이 오픈소스 개발에 적극적으로 참여하고 있는 것과는 대조됩니다.

앞선 케이스에서 다룬 것처럼, 오픈소스는 점차 확대되고 전문화되는 IT 생태계에서 분명히 차별화되는 특징들을 가지고 있습니다. 훌륭한 오픈소스 프로젝트와 커뮤니티를 구축하고, 나아가서 사업화를 진행하는 것에는 많은 장벽이 존재하지만 어느 때 보다 혁신이 강조되는 현 상황에서 오픈소스는 기업이 마주한, 혹은 마주할 과제들을 해결하기 위한 가치있는 수단이기도 합니다.

이상으로, 오픈소스의 잠재력을 이해하고 새로운 시도를 꿈꾸는 기업과 혁신가들에게 작은 도움이 되었기를 바라며 글을 마칩니다.