'탐욕도 동력!'··· 돈 벌어주는 오픈소스의 비밀

InfoWorld
초창기 오픈소스 소프트웨어는 공공의 복지를 위한 성스러운 선물처럼 보였다. 프로그래머들은 열심히 일한 노동의 대가를 누구든 원하는 사람들에게 나눠줬다. 그리고 모두가 이런 순수한 자선의 행위로부터 혜택을 입을 수 있었다.

하지만 시간이 지나면서 기업들은 돈을 벌면서도 소프트웨어를 공짜로 제공할 수 있다는 사실을 깨달아갔다. 사실 이 현실을 진정한 오픈소스 지지자들은 이미 알고 있으며, 일각에서는 이미 그런 의도로 오픈소스 소프트웨어를 제공하기 시작했다.

리차드 스톨먼은 사용자들이 코드를 수정하고 그 결과물을 배포할 수 있는 한, 기업들이 원하는 것은 무엇이든 할 수 있다는 생각을 받아들였다.

많은 기업들이 이것을 돈을 벌면서 자신을 구원하는 축복으로 받아들였다. 현명한 사람들은 오픈소스를 이용해 자신의 사업을 확장하고 브랜드를 알리며 영향력을 키울 수 있는 방법을 깨달았다. 오픈소스는 자선이라기 보다는 새로운 종류의 마케팅으로 시장에 진입하기 위한 수단으로 변모해갔다.

여기, 기업들이 오픈소스를 이용해 수익을 얻을 수 있는 9가지 방법이 있다. 이런 접근방식이 순진한 사람들에게는 불편하게 느껴질 수 있겠다. 그러나 대부분이 "선을 행하기 전에 반드시 잘 해야 한다"라는 전제를 따르고 있다. 번창하는 기업이 지원하는 프로젝트는 앞으로 어떻게 될지 알 수 없는 코드 더미보다 훨씬 낫다. 안정성 없는 자유는 사실 그리 큰 가치가 없다.

오픈소스 수익창출 전략 1: 저비용 마케팅으로써의 오픈소스
광고는 돈이 든다. 컨퍼런스는 비용이 많이 든다. 마케팅 예산은 항상 부족하다. 그리고 많은 기업들이 오픈소스를 이러한 활동의 저렴한 대안으로 보고 있다.

제품의 전부 또는 일부를 오픈소스 패키지로 공개하면 해당 제품을 사용할 사용자들을 끌어 모을 수 있다. 제품 스스로가 마케팅 수단이 되어 사용자를 끌어 모으고 고객에게 제품을 유료로 판매할 시점이 되면 판매인력이 발생한다.

이와 관련 MySQL 같은 일부 오픈소스 기업들은 얼마나 많은 사람들이 무료로 제품을 사용하는지에 과도한 관심을 두는 것이 실수라고 전한다.

핵심은 수익이 나머지 제품을 뒷받침하기에 충분하기만 하면 되는 것이다. 제품의 일부일 수 있지만 비용을 지불할 의향이 있는 사람들에게는 중요한 부분이다. 때로는 추가적으로 자신의 소프트웨어를 언제든지 원활하게 사용하고 싶은 기업 고객들을 위한 안정성도 확보할 수 있다. 어떤 기업들은 오픈소스 버전 사용자들로 하여금 홍보를 강제하기도 한다. 이런 사소한 특징들이 오늘날 수천 개는 아니더라도 최소한 수백 개의 기업에 도움이 되고 있다.

오픈소스 수익창출 전략 2: 코드를 공개해 지원 비용 절감
'문제가 있는가? 여기 코드가 있다. 스스로 확인해 보라.'

많은 오픈소스 기업들이 지원을 제공할 때 소스코드(Source Code)를 알려줄 뿐이다. 상업적 기업들은 API의 기능에 관한 복잡한 설명을 제공해야 하지만, 오픈소스 기업들은 해석을 담당하는 API 게이트웨이(Gateway)를 알려주는데 그친다. 누구든 코드를 해석할 수 있으며, 실제로 많은 사람들이 그렇다. 현재 많은 기업들이 소프트웨어에 관한 공개 논의를 통해 코드 옆에 지원 포럼을 운영하고 있다.

잘 정리된 오픈소스 소프트웨어는 관련된 모든 사람들에게 선물일 수 있다. 능력이 있는 고객들은 지원 기술자가 코드를 파헤치기를 기다리기 전에 스스로 자신의 문제를 해결할 수 있다. 지원팀은 코드에 관한 복잡한 설명을 제공하느라 시간을 낭비할 필요가 없다. 활발한 커뮤니티 활동을 통해 모두가 오픈소스를 누릴 수 있다.


오픈소스 수익창출 전략 3: 오픈소스로 개발비용 절감
기업에게는 툴 또는 라이브러리(Library) 또는 구성요소가 필요하다. 자체 개발에는 상당한 비용이 소요될 수 있다.

이미 자신에게 필요한 것의 절반을 완성한 오픈소스가 있다고 상상해 보자. 오픈소스 라이선스는 모든 추가부분을 모두와 공유해야 하기 때문에 누군가를 고용하여 필요한 부분만 추가하는 행위가 멍청해 보일 수 있다.

하지만 이를 통해 개발 비용도 절반으로 줄일 수 있다. 만약 소프트웨어가 사업의 핵심적인 부분이 아니라면 개발 비용을 절감하면서도 사회에 너그러우며 헌신적인 이미지를 심어줄 수 있다.

일부 기업들은 개발자를 고용해 이런 문제를 해결한다. 반면 다른 기업들은 이미 해당 프로젝트에 기여하고 있는 사람들을 상대로 광고한다. 바운티소스(BountySource) 등의 다양한 크라우드펀딩(Crowdfunding) 사이트를 통해 코드를 제공하는 프로그래머들을 후원할 수 있다. 사람은 사라질지라도 그들의 아이디어와 결과물은 남아있게 된다.

상황에 따라 기업들이 오픈소스 코드 기반을 위해 서로 힘을 합쳐 개발 비용을 분담하기도 한다. 모두들 비용을 절감하면서 함께 사용하는 필수적인 툴을 구축할 수 있다. 절감된 비용이 상당할 수 있다. 파트너가 최소한 1명만 있어도 비용은 절반이 된다. 10명이 있다면 비용은 90%나 절감된다.

오픈소스 수익창출 전략 4: 코드를 오픈소스로 제공해 경쟁자를 압박
구글이 안드로이드 OS를 공개했을 때, 애플의 아이폰은 스마트폰 시장의 압도적으로 점유하고 있었다. 안드로이드를 오픈소스 플랫폼으로 제공함으로써 구글은 다른 스마트폰 제조사들과 손쉽게 협력해 앱을 지원할 수 있는 플랫폼을 구축할 수 있었다. 오픈소스 라이선스 덕분에 각 기업은 소스코드에 접근하고 통제력을 갖게 되면서 동등한 파트너로 거듭날 수 있었다. 그들은 구글이 접근을 차단할 수 없다는 것을 알았기 때문에 선택에 대한 안정감을 느꼈다.

이런 공유 과정이 더욱 보편화되고 있다. 오픈스택(OpenStack)은 랙스페이스(Rackspace)가 후원하는 프로젝트로 소규모 클라우드 기업들이 한데 모여 아마존의 지배적인 클라우드보다 더욱 매력적인 보편화된 플랫폼을 제공할 수 있도록 한다.

고객들이 다양한 기업들 중에서 선택을 할 수 있을 뿐 아니라 자체 데이터 센터에 클라우드 툴을 설치할 수 있다. 이와 동일한 기본적인 구조가 모든 클라우드에서 발견되고 있으며, 스크립트(Script)는 어디에서든 동일하게 작동한다.

오픈소스 수익창출 전략 5: 오픈소스를 통해 경쟁자로 발돋움
오픈소스 라이선스를 통해 경쟁을 손쉽게 시작할 수 있다. 새로운 기업을 바닥부터 시작하기 위해 필요한 것은 오직 소스코드 저장소뿐이다. 일단 다운로드해 자신의 디자인을 추가하면 첫 날부터(심지어 몇 분 만에) 바로 경쟁이 시작되는 것이다.

하지만 경쟁자로서 시작하는 것은 노력을 지속하는 것과 크게 다르다. 코드를 다운로드 하는 것은 쉽지만 기본적인 기술을 습득하기 위해서는 수 개월이 소요된다. 진정한 전문가가 되기 위해서는 수 년이 소요될 수 있다. 진정한 경쟁이란 진정한 전문지식을 제공할 수 있는 팀을 구성하는 것이다.

이 때문에 경쟁은 오직 수요가 공급을 크게 상회하는 급성장 영역에서만 나타나고 있는 것이다. 수 년 전 하둡(Hadoop)에 대한 관심이 폭발적으로 증가했을 때, 신생 기업들이 재빠르게 생겨났다. 모두들 동일한 하둡 코어로 시작했지만, 자체적인 특수 부가기능(Add-on)을 제공함으로써 재빨리 특화를 시작했다.

오픈소스 수익창출 전략 6: 오픈소스로 경쟁을 억제
오픈소스 세계의 경쟁은 왕복차선 도로이다. 누구든 진입하여 소스 코드를 사용할 수 있지만, 자신의 혁신 전부를 기부하도록 강제하는 라이선스의 한계에 부딪히게 된다. 새로운 경쟁자가 새로운 것을 발견한다 하더라도, 기존의 경쟁자들이 모든 것을 얻을 수 있다. GPL 등의 인기 라이선스는 모두가 공평하게 공유하도록 강제하고 있다.

이런 공평한 공유 때문에 신생기업이 선두기업이 되는데 어려움이 따른다. 신생기업으로부터의 혁신을 선두기업이 흡수하기 때문이다. 경쟁자로 손쉽게 발돋움 할 수 있는 규칙 때문에 경쟁이 저해되는 것이다.

초기 오픈소스 집단 중 하나인 시그너스(Cygnus)의 창업자 중 한 사람인 마이클 타이맨은 다음과 같은 예언을 한 적이 있다.

"다행히도 오픈소스 모델이 다시금 구제되었다. 경쟁사가 우리가 현재 보유한 우리가 지원하는 소프트웨어의 주요 개발자 또는 유지/보수 전문가로 구성된 100명 이상의 엔지니어를 확보하지 않는 한 그리고 그럴 수 있을 때까지, 진정한 'GNU' 소스로써 우리를 대체할 수는 없다. 그들은 기껏해야 고객들이 비용을 지불할 의향이 있는 기능들을 점진적으로 추가할 수 있을 뿐이다. 하지만 소프트웨어가 오픈소스이기 때문에 그들이 어떤 가치를 추가하던 시그너스도 이를 함께 누릴 수 밖에 없다."

마치 악마 같은 독점자의 말처럼 들리겠지만 여기에도 한계는 있다. 선두기업이 제대로 하지 못하거나 엉뚱하게 투자하거나 쓸데 없는 부가기능에 수익을 낭비하게 되면 신생기업이 그 자리를 빼앗을 수 있다. 불가능한 것이 아니다.

별도의 코드 기반이 존재할 수 있는 정당한 2가지 이유가 있다면 이런 권력 제한의 규칙이 적용되지 않을 이유가 없다. 소프트웨어의 용도가 2가지라면 2개의 집단이 손쉽게 둘 모두에 특화될 수 있다. 서로 다른 차별화된 시장에서는 경쟁이 살아남을 수 있다.


오픈소스 수익창출 전략 7: 오픈소스로 협상
많은 오픈소스 라이선스가 유연하긴 하지만 일부는 점차 엄격해지고 있다. 최근에 공개된 아페로 GPL(Affero GPL ; AGPL)은 코드가 단순히 서버에서 운용된다는 사실만으로도 해당 코드가 공유되어야 한다고 주장하고 있다.

조금 늦게 오픈소스 커뮤니티에 등장한 이 라이선스는 일부 개발자들이 오픈소스 소프트웨어로 이익을 보면서도 자신의 기여분을 공유할 요건을 회피하고 있음을 알아챘기에 등장한 것이다. 그들은 소프트웨어를 "배포하지" 않고 단순히 운용할 뿐이었다.

GPL은 오직 소프트웨어를 "배포"할 경우에만 공유를 강제했다. 그리고 일부 개발자들은 이 요건을 충족시키기 쉽다고 생각했다. 그들은 단지 실험을 진행하거나 무료 서비스를 제공할 뿐이다.

자체적인 개선사항을 공유한다고 해서 불리해지는 것은 아니다. 하지만 이 규칙이 상용 라이선스를 구매하는 비용보다 훨씬 골치 아프다고 말하는 기업들도 많다. 라이선스의 강도는 그들이 제품을 지원하도록 유도하는데 도움이 된다.

최근 AGPL은 NoSQL 데이터 저장소 등 다양한 신생 프로젝트에 인기를 얻고 있다. 몽고DB(MongoDB)의 경우, 자체적인 핵심 툴인 데이터베이스를 위해 이 라이선스를 도입했다. 동시에 이 기업은 사람들이 자사의 핵심 서비스에 연계하도록 더욱 관대한 아파치(Apache) 라이선스를 통해 동기요인을 보호하기로 선택했다.

오픈소스 수익창출 전략 8: 오픈소스로 공유된 표준 수립
모든 기업 및 시장은 고객들을 위해 무엇을 기대할 수 있으며 기업들이 무엇을 구축할지 알 수 있도록 일련의 표준을 마련해야 한다. 오픈소스는 종종 이런 상호운용성 표준을 수립하는데 도움이 된다.

일례로 HTML은 웹 상에서 문서를 작성할 때 사용하는 언어이자 웹 브라우저의 경쟁을 가능하게 하는 필수적인 표준이다. 업계가 HTML을 중심으로 합쳐지면 브라우저 개발사들은 콘텐츠 대신에 기능을 중심으로 혁신과 경쟁을 할 수 있다. 한편, 콘텐츠 제작자는 그들이 생성한 웹 페이지를 사용할 수 있는 모든 브라우저에서 표시할 수 있음을 확신할 수 있다.

오픈소스 툴이 이렇게 발전하는 표준의 중심에 서 있는 경우가 종종 있다. 예를 들어, 모바일 브라우저 시장은 대부분 애플이 개발했지만 구글과 다른 기업들이 도입한 웹키트(WebKit) 렌더링 엔진을 통해 정의된다.

애플이 이 기술을 독자적으로 유지할 수 있었을 것이다. 그러나 그렇게 했다면 아이폰과 다른 스마트폰 사이의 상호운용성 부족으로 인해 일반적인 스마트폰에 맞추어 개발함으로써 활용이 가능한 콘텐츠를 가진 웹 사이트가 더 적었을 것이며, 이로 인해 시장이 정체되었을 것이다. 이것을 오픈소스 툴킷으로 공개하면서 공유된 표준이 성숙될 수 있었다.

오픈소스 수익창출 전략 9: 오픈소스로 미래를 통제
여러 기업들이 직원을 고용해 오픈소스 프로젝트를 진행하고 있다. 때로는 개발에 막대한 자금을 투자한 코드를 기부하기도 한다. 그들은 해당 코드 기반이 발전하는 방식에 영향을 끼치고 싶어하며, 가장 손쉬운 방법은 코드를 기부하는 것이다.

이런 영향은 꾸준하다. 리눅스 등 모든 주요 프로젝트의 기여자들 상당수가 기업을 위해 일하고 있다. 흐름에 참여하길 원하는 기업들이다.

물론, 목표는 자신들의 목적을 위해 오픈소스 코드의 유용성을 유지하는 것이다. 라이브러리 또는 툴이 성장한다면 새로운 기능이 기업의 상용 툴과 호환되지 않을 수 있다. 하지만 해당 기업이 새로운 기능을 대거 개발한다면 필요에 맞는 것들을 찾을 수 있을 것이다. 알토(Alto)의 개발자 앨런 케이가 말했듯 "미래를 예측하는 가장 좋은 방법은 미래를 발명하는 것이다." ciokr@idg.co.kr