[기고]오픈소스로 여행해보려는 창업가를 위한 안내서

가. 첫번째 이야기: 창업하지 마세요

오픈소스 기반의 창업을 하는 것은, 비공개 소프트웨어를 개발하는 창업 이나 오픈소스를 사용한 온라인 서비스 구축 창업을 하는 것과는 근본적으로 다른 부분들이 몇 가지 있습니다. 일반적으로 소프트웨어를 개발하여 판매하거나 온라인 서비스를 만들 때 공통적으로 필요한 일들을 적어 봅시다.

• 소프트웨어(또는 온라인 서비스) 를 설계합니다.
• 협업을 바탕으로 소프트웨어를 개발합니다.
  1. 회사의 목표에 따라 솔루션의 로드맵을 결정합니다.
  2. 내부 QA 팀을 통해 검증합니다.
• 소프트웨어(또는 온라인 서비스)를 배포합니다.
  1. 앱이라면 버전업을 기준으로 하는 배포가 될 수도 있고
  2. 온라인 서비스라면 점진적 배포가 될 수도 있을 것입니다.

만약 내가 만드는 소프트웨어가 오픈소스라면, 이렇게 될 것입니다.

• 소프트웨어를 설계합니다.
  1. 설계 과정이 대개 공개된 공간에서 이루어집니다. RFC형태일 수도 있고, discussion 형태일 수도 있습니다.
  2. 설계부터 이루어지는 경우보다는, 실제 사용되며 받은 피드백들을 기반으로 설계가 이루어지는 경우가 많습니다.
• 협업을 바탕으로 소프트웨어를 개발합니다.
  1. 로드맵을 회사가 세우기도 하지만, 외부 기여에 의해 새로운 기능들이 제안되거나 추가되기도 합니다.
  2. PR을 받고, 리뷰를 진행합니다. 공개 CI/CD 도구를 붙입니다.²⁾
• 소프트웨어를 배포합니다.
  1. 일반적으로 버전업을 기준으로 하는 배포가 이루어지고,
  2. 만약 오픈소스를 만들면서 클라우드 사업을 하는 경우 (뒤에서 설명하겠습니다)에는 점진적 배포도 이루어집니다.
  3. 버전업이 매우 빠릅니다.

위와 같이 미묘한 차이들이 있지만, 가장 근본적인 차이점은 배포 일정과 계획의 유동성이 커뮤니티적 요소에 의해 크게 좌우되고 변동된다는 점입니다.³⁾ 만약 내가 오픈소스 문화에 익숙하고, 다양한 활동을 이미 해 본 경우라면 오픈소스 기반의 창업을 시작할 수 있을 것입니다. 위에서 설명한 과정을 구현하는데 어려움이 없을테니까요. 그런데 만약 오픈소스에 대한 경험이 없이 오픈소스 기반의 창업을 시작하려고 하신다면, 하지 마세요. 백종원의 골목식당에만 빌런들이 있는 것이 아닙니다. 여러분도 얼마든지 될 수 있습니다.

만약 그래도 오픈소스 기반의 창업을 꼭 해야 한다면, 우선 오픈소스를 두어가지 만들어 보시거나, 다른 오픈소스에 기여하면서 절차들을 꼭 구경해 보시기 바랍니다. 대표는 그런걸 몰라도 되지 않나고요? 그럴 수도 있겠죠. 하지만 그런 경우라면 오픈소스를 주 아이템으로 창업하는 것보다 더 쉬운 창업하는 길들이 다양합니다. 굳이 오픈소스 소프트웨어 개발 기반의 창업을 하실 필요는 없습니다.

나. 두번째 이야기: 시작할 때 최대의 적은 윈도우

오픈소스 개발 회사의 대표가 되면 가장 괴로운 점은, 팀에서 윈도우 관련 작업을 전담하게 된다는 부분입니다. 대부분의 오픈소스 개발 환경이 리눅스 또는 맥오에스였기 때문에, 여러분의 동료들은 윈도우를 만지고 싶어하지 않을 것입니다. 전담하게 될 작업을 조금 더 정확하게 표현하면, Active X들과 끝없이 깔리는 '보안 프로그램'들과의 전투입니다. (전 창업 후에 윈도우 게임을 다 끊었습니다. 윈도우 화면만 보면 가슴이 아픕니다...)

대한민국에서 사업을 하기 위해 만나는 거의 모든 플랫폼은 창업자가 32비트 윈도우를 쓴다는 가정을 하고 만들어져 있는듯 보입니다. 그래도 최근에는 많이 나아지긴 했지만, 윈도우 PC 한 대는 꼭 안고 가신다는 자세가 필요합니다. 심지어 많은 거래 기업들의 사이트는 여전히 인터넷 익스플로러 11을 요구하기도 합니다. 오픈소스 개발자들에겐 사람에 따라 큰 허들이죠.

나중에 회사가 커지면 윈도우를 사랑하시는 분들도 함께 사업을 하게 되시며, 다른 분들이 윈도우로 하는 일의 많은 부분을 대신 담당해주시게 될겁니다. 하지만 오픈소스 기반의 스타트업 초창기에 대표의 권위는 그 괴로운 Active X를 다룬다는 부분에서 나옵니다. 아 대표는 아무나 하는게 아니구나... 하고요.

그래서, 창업을 할 때 처음 사야 하는 컴퓨터는 맥북프로가 아니라 인텔 NUC입니다.⁴⁾

다. 세번째 이야기: 팀 구성하기

저는 운이 좋게도 오랫동안 오픈소스를 하며 만난 분들과 창업하게 되는 경험을 누렸습니다. 서로의 기술적 배경이나, 관심사, 생각을 어느정도 공유하는 공동창업자들이었죠. 그래서 소프트웨어의 오픈소스화를 포함한 중요한 몇가지 결정을 내려야 할 때 복잡한 합의 과정을 거칠 필요가 없었습니다. 오픈소스의 경우 철학을 공유하는 부분이 내부적인 원동력에 큰 영향을 끼칩니다.

오픈소스 기반의 스타트업이 무엇을 하고 싶은지 보려면 그 회사의 오픈소스 소프트웨어를 보면 됩니다. 회사의 철학은 비전의 형태로 정의되고, 실체화 및 체감이 어렵습니다. 그러나 소프트웨어는 목적을 달성하기 위한 기능의 집합이라 그 자체가 목적성을 강하게 띕니다. 오픈소스는 지식의 공개 및 지식의 공유, 기술의 일반화 측면에서 공공성이 있는 활동입니다. 목적성이 명확한 소프트웨어의 특징이 공공성에 기반한 오픈소스 운동과 만나 만들어지는 오픈소스 소프트웨어는 그래서 개발자들에게 굉장히 직접적인 철학적 보상을 가져다 줍니다.

이러한 감정적 보상은 스타트업이 성장하고 궤도에 올라가기까지의 힘든 기간을 이겨낼 수 있는 요소가 됩니다. 반면, 철학에 기반한 감정적 보상이 없는 오픈소스 스타트업은 창업 초기의 험난한 길을 헤쳐 나가기가 일반 회사보다 훨씬 더 힘이 듭니다. 오픈소스 소프트웨어 기반의 수익 모델은 첫 이윤 창출 시점이 일반적으로 다른 스타트업들에 비해 늦기 때문입니다. 결국 팀이 와해될 가능성이 높아집니다.⁵⁾

라. 네번째 이야기: 오픈소스는 자동화로 시작해서 문서화로 끝납니다.

오픈소스 소프트웨어를 개발할 때는 어느순간부터 자동화가 엄청나게 중요해졌습니다. 불특정 다수로부터 코드 기여를 받고 리뷰 과정을 통해 통합하는 과정은, 책임을 부여받은 직원들로부터 작성된 코드를 리뷰하는 것보다 몇가지 면에서 더 복잡하기 때문입니다.

• 소프트웨어가 복잡할수록, 기술 문서 및 설계 문서가 중요해집니다. 오픈소스 소프트웨어의 경우 발표 주기가 짧기 때문에, 회사 규모를 막론하고 문서 갱신의 속도가 코드 갱신 속도보다 느립니다.
• 코드를 빌드하기 위한 환경이 다양합니다. 기여자가 코드를 개발하기 위해서 준비하는 환경은 천차만별이라, 딱 맞춰진 개발 환경을 제공 또는 제시하면 되는 비공개 소프트웨어에 비해 개발환경 구축을 제시하는 과정이 복잡합니다.
• 저작권 문제가 있습니다. 오픈소스 소프트웨어는 다양한 종류의 라이선스로 구성되어 있으며, 또한 수많은 다른 오픈소스 소프트웨어에 기반하여 만들어집니다. 소프트웨어의 라이선스를 결정하기 위해서는 우리 소프트웨어가 의존하는 다른 오픈소스 라이선스들과 충돌이 있는지 검토해야 합니다. 또한, 외부로부터 기여를 받을 때는 이후 라이선스 변경 등의 상황이 발생할 때를 대비하여 CLA (contributor license agreement)를 취득하는 것을 권장합니다.⁶⁾

위와 같이 오픈소스 소프트웨어를 개발할 때 추가로 발생하는 문제들이 있죠. 이러한 문제들을 사람이 해결하지 않도록 하는 시스템을 만드는 과정이 중요합니다.

• 충분한 내용을 제공하는 README를 준비해야 합니다.
  1. 코드 테스트, 코드 빌드 과정에 대한 내용을 제공합니다.
  2. 오픈소스 라이선스 문서로의 링크 및 OSI 의 해당 라이선스로의 링크를 제공합니다.
• 라이선스 문제를 미리 체크하고, 이후에 발생할 수 있는 여지를 줄입니다.
  1. 라이선스 충돌 문제를 확인하는 다양한 도구들을 활용합니다.
  2. 모든 기여에 대한 CLA를 확보하기 위한 자동화 도구를 도입합니다.
• 문서화를 사람이 다 해야 한다는 생각을 버려야 합니다.
• 코드 주석 기반의 자동 문서화 시스템을 만듭니다.
  1. JavaDoc, JSDoc, ReST, Markdown 등 다양한 문서 포맷중 프로젝트의 성격에 따라 고른 포맷으로 코드 주석 작성을 의무화합니다.
  2. 코드 주석 기반의 린팅 도구 등을 이용한 타입체커를 구현하고, 기여를 받는 단계에서 가급적이면 자동으로 체크하도록 구성합니다.
  3. 코드 기반의 자동 문서 빌더와 함께 이를 게시하는 오픈소스 문서 서비스를 활용합니다.
• 하지만 결국 사람이 작성해야 하는 사용자 문서들이 있습니다.
  1. 코드 기반 문서에 더하여 실제 개발자 및 사용자가 이용할 수 있는 매뉴얼을 작성합니다.
  2. 수동 문서의 경우, 문서 저장소 운영을 통해 문서작성에 기여를 받을 수 있도록 구성합니다.
• 다국어 지원 소프트웨어 및 문서의 경우 자동화 서비스 또는 도구들을 이용합니다.
  1. 초벌 번역을 기계 번역을 이용하여 처리해주는 여러 도구들 및 서비스들을 연동합니다.
  2. 다국어 데이터의 변경 사항에 대한 리뷰어 시스템을 운영합니다.

위의 내용이 창업과 무슨 관계인지 잘 모르겠다고 느껴지시는 분들이 있으시다면, 첫번째 이야기를 다시 읽어보시고 네 번째 이야기를 다시 한 번 읽어주시기 바랍니다.

마. 다섯번째 이야기: 좋은 오픈소스 소프트웨어와 좋은 회사 사이의 함정

오픈소스 소프트웨어를 만드는 사업을 하는 것엔 여러가지 리스크가 있습니다.

우선, 오픈소스 소프트웨어를 공개한다는 것은 사실상 회사의 지적 재산에 대한 접근 권한을 주는 것입니다. 만약 오픈소스 소프트웨어가 충분히 뛰어나다면 복제 이슈가 따라옵니다. 어떻게든 피해갈 수가 없게 됩니다. 괜찮아 보이면 복제를 하거나, 상표를 바꾸어 제품을 만들거나, 기능 리스트를 보고 비슷하게 따라 구현하는 경우들을 많이 접하게 될 것입니다.

그럼 이런 경우를 어떻게 막아야 할까요? 위의 기술 복제 문제가 오픈소스 소프트웨어 역사의 처음 2/3의 기간동안 오픈소스 소프트웨어가 기업들에게 광범위하게 퍼지는 것을 막는 요인이었습니다. 그럼 지금은 어째서 오픈소스 소프트웨어를 개발하고 사업을 영위하는 기업들이 압도적으로 많아졌을까요?

첫번째 이유는 기술의 복잡도가 높아졌기 때문입니다. 간단하게 요약하면, 복잡해서 봐도 모른다는 점입니다. 그리고 어차피 공개되어 있다면 그냥 가져와서 쓰고 크레딧을 명기하는 것이 익숙한 분위기가 되었기 때문이기도 합니다. 회사의 소프트웨어를 오픈소스로 공개했을 때의 장점이 이 두 변화의 교차점에서 생겨납니다. ‘리버스 엔지니어링으로 다시 만들기엔 복잡한 소프트웨어+가져와서 사용하는 것의 편의성’ 이 두가지가 만나 오픈소스 기반 기업들이 생겨날 수 있는 토대가 되었습니다. 오픈소스 소프트웨어는 사용자층을 쉽게 늘릴 수 있습니다. 초기 사용자 확보는 피드백을 통한 소프트웨어의 고도화에 큰 도움이 됩니다. 그 중 일부 사용자들은 오픈소스를 진지하게 솔루션으로 사용하려고 할 것입니다. 그 사용자들은 이후 엔터프라이즈 솔루션 사업을 시작할 때 첫 고객이 됩니다.

기술 기반 기업인 경우엔 추가적으로 누릴 수 있는 장점이 있습니다. 회사의 기술력을 내세우기 가장 쉬운 방법이 오픈소스 소프트웨어를 공개하는 것입니다. 다른 회사나 투자사, 수요처가 개발사의 기술력을 검증하는데 소스코드보다 확실한 방법은 없을 것입니다. 또한 해외 진출에도 도움을 주게 되는데요, 해외에 따로 홍보 조직을 두기 어려운 스타트업의 입장에서는 코드가 알아서 홍보를 해 주는 도움을 받을 수가 있습니다.

위의 장점을 누리려면 전제 조건이 하나 있습니다. 개발한 오픈소스 소프트웨어가 압도적인 면이 있어야 한다는 점입니다. 기술, 편의성, 이식성, 문서, 생태계의 크기 등 어떤 것도 좋습니다. 베껴 만드는 것 보다 그냥 쓰는게 이득이라는 생각을 갖게 만들거나, 베낄 시도를 포기하게 만드는 점이 있어야 합니다.

두번째 이유는 전통적인 소프트웨어 판매방식이 아닌 다른 방식의 수입원들이 생기고 있기 때문입니다. 그 중 하나는 증가하는 온라인 서비스 기반의 창업입니다. 회사의 실제 가치의 발생이 직접 개발한 오픈소스 소프트웨어 자체에서 오는 것이 아니라, 그에 바탕한 온라인 서비스에서 생겨나는 경우가 많아졌습니다. 온라인 서비스 회사들이 서비스 개발 과정에서 개발한 수많은 소프트웨어를 오픈소스로 공개하기도 하고, 반대로 오픈소스 기반 회사들이 자체적인 클라우드 기반 온라인 서비스⁷⁾를 운영하며 수익 모델을 만들고 있습니다.

엔터프라이즈 솔루션과 관리를 결합한 구독형 모델의 수요도 증가하고 있습니다. 소프트웨어의 발전 속도가 빨라져서, 한 번 구매하고 기간 제한 없이 사용하는 소프트웨어 판매 방식이 변화하는 수요의 요구를 따라갈 수 없게 되었습니다. 이미 상당수의 소프트웨어 개발사들은 구독 모델로 소프트웨어 판매 정책을 변경하고 있으며, 자체 온라인 서비스와의 결합을 통해 지속적인 발전을 전달하는 과정 자체를 소프트웨어 사업 모델의 일부로 만들고 있습니다. 빠른 배포 주기와 발전을 적용하는 오픈소스 소프트웨어 개발 과정은 특히 이러한 구독 모델과 잘 어울리며, 대규모 사전 테스트를 통해 사용자의 피드백을 받아 적정 기능을 개발하고 구독 서비스에 반영할 수 있다는 장점이 있습니다.

그럼 이제 문제점을 이야기 해 봅시다. 오픈소스 소프트웨어를 공개한다는 것은 사실상 회사의 지적 재산에 대한 접근 권한을 주는 것이라고 말씀 드렸습니다. 그리고 많은 오픈소스 소프트웨어 기반 회사들이 클라우드 기반 온라인 서비스를 수익 모델로 만들고 있습니다. 그런데 최근에 이 수익모델이 다양한 방법으로 위협받고 있습니다. 퍼블릭 클라우드 업체들이 오픈소스를 직접 서비스 하면서 프리라이딩하는 경우들이 발생하고 있죠⁸⁾ . 심지어 직접 포크하여 자체 솔루션화를 해 버리는 식으로 오픈소스 소프트웨어 기반 회사들의 수익 모델을 차단하는 경우들이 늘어나고 있습니다.⁹⁾

클라우드 SaaS¹⁰⁾나 온라인 서비스 운영을 주 수입원으로 삼는 오픈소스 기반 회사들이 많아지고 있다는 점은, 반대로 말하면 오픈소스 소프트웨어를 패키지로 만들어 판매하는 모델의 한계가 있다는 말이기도 합니다. 클라우드 SaaS 기반의 사업은 어느 정도 이상의 스케일부터 의미가 있는 매출이 됩니다. 그 때까지 생존할 수 있는지를 가늠하고, 어떤 식으로 수익 모델은 변경해 나갈 것인지를 고려해 두는 것이 필요합니다. 또한 바로 앞에서 말씀드린 것과 같이, 퍼블릭 클라우드에서 오픈소스를 포크하여 자체 서비스로 만들어 버릴 가능성에 대한 대비도 필요합니다.¹¹⁾

이러한 경우를 보호해 주는 것 또한 오픈소스 라이선스입니다. 피해를 최소화하기 위해서는 다양한 가능성을 모두 생각해 본 후 적절한 오픈소스 라이선스를 선택해야 합니다. 서비스 구축을 위해 사용할 때 소스 코드를 강제하는 라이선스를 적용하거나, 사용자층에 따라 비상업/상업적 목적성에 따른 이중 라이선스를 적용할 수도 있습니다. 제약이 거의 없는 일부 라이선스를 제외한 대부분의 오픈소스 라이선스는 적대적 포크를 시도한 곳에서 일어나는 혁신을 자사의 오픈소스로 역으로 가져올 수도 있게 허용합니다.

다른 방법은 오픈소스인 부분과 비 오픈소스인 부분을 분리하는 것입니다. 대부분의 기능은 오픈소스로 제공하되, 엔터프라이즈 플랫폼에서만 요구되는 기능들은 별도의 모듈, 라이브러리 또는 플러그인으로 제공하는 방식입니다. 이 경우 오픈소스 프로그램의 동작과 비 오픈소스 모듈의 동작 사이의 관계를 고려한 라이선스를 선택해야 합니다. 비 오픈소스 모듈의 독립성 및 독자 실행 등의 여러 조건들에 제약을 거는 여러 라이선스들이 있습니다. 회사가 공개하고 싶은 부분과 독자적으로 가져가고 싶은 부분을 분리할 계획이 있다면 라이선스를 초기에 잘 선택하는 것이 중요합니다.

바. 마지막 이야기: 그래도 오픈소스로 사업을 하고 싶으시다면

여기까지 읽으신 많은 분들은 오픈소스로 사업하는 것이 그냥 소스를 공개하는 것보다 훨씬 복잡하며, 고려해야 할 점도 많다는 것을 이해하셨을 것입니다. 그럼에도 불구하고 여전히 오픈소스 소프트웨어를 만들고 그 기반의 패키지나 SaaS, 클라우드를 운영하고 싶으시다면 아래의 몇 가지 질문들에 대해 생각하고 답을 내어 봅시다.

• 창업을 통해 개발하려는 소프트웨어 및 서비스가 꼭 오픈소스여야 하는가?
• 만약 오픈소스여야 한다면 그 이유는 무엇인가? 철학인가, 이득인가?
• 오픈소스가 주요 제품이 된다면 그걸 통해 어떠한 방식의 매출을 만들것인가?
• 창업을 통해 만들 오픈소스가 창업할 회사보다 오래갈 수 있을 것이라고 생각하는가?
• 오픈소스 소프트웨어 가로채기를 우리는 어떻게 막을 것인가?
• 오픈소스 가로채기를 당해도 경쟁력을 유지할 방법을 준비해 두었는가?

스스로 충분히 답을 내었다면, 그 다음은 창업가의 몫입니다. :)

신정규 대표   現 래블업(주) 대표 https://www.lablup.com/