![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
오픈 소스 소프트웨어를 이용하면 기업가와 기술자가 혁신적인 솔루션을 시장에 내놓을 수 있다. 이 기사에서는 3,650만 달러에 매각된 신생 기업을 설립할 때 오픈 소스 소프트웨어를 왜 사용했는지 그리고 어떻게 사용했는지에 관해 살펴본다.
필자는 전 세계적으로 분산된 최초의 비디오 프로덕션 플랫폼이 되도록 StudioNow를 설립했다. StudioNow에서는 비디오 예술가, 편집자, 그래픽 예술가, 성우 및 Yellow Pages, Citysearch® 및 음악 레이블과 같은 고객의 컨텐츠를 창작할 기타 창조적인 유형의 예술가를 연결한다. StudioNow의 웹 사이트와 클라우드 기반 전달 및 인코딩 변환 플랫폼을 통해 비디오 프로덕션의 규모를 조정할 수 있게 되었고 개별 비디오에 소요되는 비용을 낮출 수 있었다.
StudioNow의 초창기에 필자와 필자의 동료는 새로운 기술 세트를 늘리고 배울 수 있는 가장 좋은 방법을 사용하고 결정할 기술을 결정해야 했다. 또한, 문제점을 제거하고 정보를 이용하여 아키텍처적 의사결정을 하는 데 적응해야 했다. 이러한 경험을 통해 오픈 소스 기술을 사용하면 비즈니스를 개발하는 데 엄청난 이점을 누릴 수 있다는 사실을 배웠다. 결과가 다를 수도 있지만, 프로젝트에서 오픈 소스를 사용하기로 고려하고 있는 경우에는 다음과 같은 것을 고려하는 것이 좋다.
- 커뮤니티의 강점과 깊이를 기반으로 기술을 선택한다.
- 채택한 소프트웨어와 관련된 커뮤니티에 참여한다.
- 규모를 조정할 경우에는 클라우드를 고려한다. (기술적으로는 오픈 소스가 아니라고 해도 많은 오픈 소스가 인프라에 대한 이러한 접근 방식과 관련이 있다.)
- GPL(General Public License)을 회피한다.
새로운 기술 스택으로 솔루션을 구축하기는 어렵지만, 전체 회사를 앞서 언급한 기술을 중심으로 구축하면 완전히 새로운 결과를 얻을 수 있다. 채택할 플랫폼을 선택하는 일은 초기에 결정해야 하는 전략적인 과제였다. 잘못된 선택은 성공과 실패를 가름하는 척도였다. 또한, 기술이 너무 난해하면 바람직하지 못한 선택으로 인해 기술을 습득하는 데 어려움이 있을 수도 있다. 게다가 커뮤니티가 부족하거나 존재하지 않는 경우에는 기술을 신속하게 배울 수 없게 된다. 주변 기능보다는 핵심 기능을 집중적으로 구현하는 데 도움이 되는 즉시 사용 가능한 도구는 무엇이 있을까?
Microsoft® .NET과 C#뿐만 아니라 Oracle과 Java™ 기술을 의미하는 엔터프라이즈 소프트웨어의 배경에서 주로 나오듯이 분명한 사실은 무엇인가 다른 것을 선택해야 했다는 점이다. 라이센싱을 하고 라이센싱 준수를 관리하는 데 비용을 들이려고 하는 사람은 아무도 없었으므로 결국은 Ruby와 Ruby on Rails 또는 Python과 Django 사이에서 결정해야 했다. 이러한 오픈 소스는 일반적으로 웹 애플리케이션을 빌드하는 데 잘 맞는 오픈 소스이었으므로 이러한 두 가지 오픈 소스를 사용하기로 결정했다.
2006년 초에 공동 설립자이자 CTO인 Adam Solesby가 이 두 가지 플랫폼을 평가하여 의사결정을 했을 때 필자는 StudioNow에서 야간 작업을 하고 있었다. 그는 두 가지 핵심 요인 때문에 Django를 선택했다. 우선, Python 언어는 단지 미적으로만 좋아 보였다. 그러나 중요한 점은 Python과 Django의 문서와 커뮤니티가 강력하다는 사실이었다. 문제점이 설명된 문서를 읽고 예제를 찾기가 분명히 수월했다. 이점은 채택할 기술을 결정하는 데 중요한 요인이었다. 온라인 문서인 Dive into Python 책과 Freenode에 있는 #django IRC(Internet Relay Chat) 채널 그리고 Python 및 Django 관련 문서(참고자료 참조)로 인해 기술을 습득하기가 수월했다.
각 오픈 소스 프로젝트(커뮤니티는 어느 정도 프로젝트를 중심으로 되어 있음)에는 명시적이거나 이해되는 특정 규칙 세트가 있다. 오픈 소스를 성공적으로 사용하려면 다음과 같은 사항을 중요하게 고려해야 한다.
- 도움을 다시 돌려주겠다는 태도로 커뮤니티에 접근한다.
- 커뮤니티에 있는 사람들은 자발적으로 도움을 주고 있는 것이지, 도움을 줄 의무가 있는 것은 아니라는 점을 이해한다.
- 스스로 해답을 찾으려고 노력한다. 무엇인가 명확하지 못한 부분이 있고 확인하는 데 시간이 많이 걸리는 경우에는 블로그 포스트, 문서 FAQ 작성 등의 형태로 커뮤니티에 자신의 지식을 기여하여 다음 사람이 같은 노력을 하지 않아도 되게 한다.
- 초기에 커뮤니티의 사회적 규범을 정하려고 노력하고 이단자가 되지 말고 커뮤니티의 구성원과 동화되도록 한다. 해당 커뮤니티가 이메일 목록이나 IRC 채널 중 어느 것으로 자주 의사소통을 하나? 이 두 가지 수단을 모두 사용할 수도 있으며 각각 다양한 특성을 갖고 있다.
- 긍정적이도록 하자.
StudioNow가 설립된 초창기에는 비디오의 인코딩 방식을 변환하는 방법을 많이 알지 못했다. 필자는 검토 프로세스용 웹 사이트에서 재생하기 위해 계속해서 비디오를 습득하여 Sorenson FLV 형식으로 내보내고 있었다. 비용을 줄이기 위해 그리고 편집자들이 스스로 작업을 소싱했을 때보다 더 적은 비용이 드는 프로젝트를 맡는 것이 가치가 있다는 점을 편집자들에게 확신시키기 위해서는 편집자들이 하기 싫어하는 비창조적인 반복적 작업을 해야 하는 부담을 더 많이 떠 맡아야 했다. 판매에 유리했던 점은 고객이 대상 형식을 신경 쓰지 않아도 된다는 점이었다.
볼륨이 많아지기 전까지 초기에는 이 모델을 유지할 수 있었다. 수동으로 내보내기를 수행할 전일제 직원과 많은 워크스테이션이 있었다. 이외에도 편집자로부터 사무실로 원시 업로드를 다운로드하고 인코딩 방식을 변환한 후, 클라이언트와 고객이 검토할 수 있게 다시 프로젝트 페이지에 업로드하는 프로세스를 반자동화하는 데 도움이 되는 임시 스크립트가 일부 있었다.
이 프로세스의 규모가 조정되지 않을 것이라는 점과 가능한 자본금을 많이 보존하면서 이러한 문제점을 해결해야 했다는 사실은 처음부터 분명했다. 자금을 조달할 수 있는 다음 시점이 언제나 불확실했기 때문에 자금을 유용하게 사용해야 했다.
2006년 중반에도 여전히 AWS(Amazon Web Services)는 비교적 새로운 서비스였다. 처음에는 회사가 성장함에 따라 비용을 지불하게 될 저렴한 무제한 스토리지를 확보할 수 있는 Amazon S3(Amazon Simple Storage Service)에 매력을 느꼈다. 결국에는 코로케이션된 비교적 오래된 두 대의 서버로 전체 사이트(웹 사이트 및 비디오 파일 호스팅)를 호스팅했다. 인코딩 변환 작업의 규모를 조정해야 한다는 사실을 알았지만 웹 서버의 부족한 하드 공간을 채우는데 신경 쓰지 않아도 된다는 점이 가장 중요하게 작용했다.
사내에 있는 인코딩 방식 변환 솔루션을 사용하여 Amazon S3에 변환 코드를 저장하고 API를 통해 웹 사이트를 호출하여 해당 위치를 기록하기로 결정했다. 이 솔루션은 인코딩 방식 변환 작업의 규모를 조정해야 하는 문제점을 파악할 수 있는 시간을 다소 벌어주었다.
필자는 자체 Python 인터페이스를 작성하여 Amazon S3 API와 상호 작용하기 위한 작업을 시작했다. 그러나 Mitch Garnaat의 boto 프로젝트(참고자료 참조)를 바로 발견했다. Mitch의 직접적인 도움으로 생산성이 상당히 증가했다. 이 라이브러리 자체가 StudioNow의 시간과 노력을 절약하는 데 중요한 역할을 했지만, boto 사용자와 개발자로 구성된 커뮤니티가 이 새로운 형태의 아키텍팅 기술 솔루션을 이해하는 데 많은 도움이 되었다. 어떤 점에서는 boto 프로젝트에 참여한 것은 오픈 소스 소프트웨어보다는 오픈 아키텍처와 더 관련이 있었다.
이러한 협력적인 경험 덕택에 필자는 Amazon EC2(Amazon Elastic Compute Cloud)를 사용하여, 비디오의 단일 코덱 변환을 수행하는 사내의 제한된 방식을 확장 가능한 인코딩 플랫폼으로 변환할 수 있었다. 현재, 이 플랫폼에서는 다양한 대상 디바이스와 플랫폼에 맞는 다양한 크기와 코덱의 수많은 비디오의 인코딩 방식을 단일 비디오 렌디션을 인코딩하는 데 걸리는 시간과 동일한 시간에 변환할 수 있다.
과거에는 당사 COO의 제안에 따라 Java 기반 폐쇄형 소스 솔루션을 사용하는 것을 고려했다. 이 기술은 동일한 인코딩 방식 변환 서비스를 포스트 프로덕션 하우스에 제공한 입증된 기술이었다. 또한, 이 기술은 현명하고 신중한 권장사항이었지만, 하드웨어를 구입하고, 데이터 센터 공간을 빌드하거나 임대하고, 소프트웨어 라이센스를 확보하고, 하드웨어를 관리할 직원을 추가로 고용하려면 상당한 자본을 투자해야 했다. 그러나 이 기술은 적어도 단기간에 규모를 확장할 수 있을 거라고 여겨졌던 솔루션이었다.
이 불확실한 솔루션에 자본을 투자하기 전에, boto 커뮤니티에 대한 경험과 "사용한 만큼 지불"하는 계약을 감안하여 클라우드 기반 솔루션을 추진하기로 결정했다.
그 당시 비슷한 일을 수행하고 있는 다른 사람들은 거의 없었지만 참고할 만한 사례는 충분했다. boto 라이브러리에는 요청 시 노드를 시작할 수 있는 인터페이스가
있었다. Amazon에서는 당사에서 필요했던 컴퓨팅 자원(상당히 많은 시간을 유휴 상태로 보내는 항상 실행 중인 시스템 대신, 온 디맨드형 수평적 컴퓨팅 자원)을
적절한 가격에 제공했었다.
Mitch는 Apple iPod에서 재생할 비디오의 인코딩 방식을 FFmpeg을 사용하여 변환하는 과정을 보여주는 기사를 작성한 적이 있었다.
따라서 필자는 이미지를 부팅하고, 인코딩 방식을 변환할 대상 비디오 파일을 입력 받고, 이미 빌드한 API를 작동하고, 그 결과를 Amazon S3에 저장하고
스스로 종료하는 프로토타입을 빌드해야 했다. 몇 주 안에 이러한 작업을 완료하고 나자, AWS와 오픈 소스 소프트웨어를 기반으로 솔루션을 빌드하는 데 자신감이
생겼다. 또한, 플랫폼을 훨씬 더 많이 제어할 수 있게 되었다. 따라서 FFmpeg 및 비디오 인코딩 방식 변환과 같은 핵심 기술을 습득하는 데
집중할 수 있었다. 또한, 소프트웨어 제품의 벤더에 의존하거나 실제 하드웨어 또는 예산에 제한되지 않게 되었다. 프로젝트당 컴퓨팅 및 스토리지 자원의 비용을
정확하게 알게 되었으며 이러한 비용을 가격 책정에 반영할 수 있었다.
이 플랫폼을 빌드하는 과정에서 중요한 부분은 비디오 인코딩 방식의 변환과 이러한 작업을 수행하는 데 필요한 기본적인 도구인 FFmpeg에 관해
배우는 것이었다. 필자는 이 프로젝트가 boto와 같은 순수한 Python 라이브러리보다 훨씬 더 기술적이고 혼란스럽다는 것을 발견했다. 비디오 코덱은 때로는
낯설고 이질적인 것이었기 때문에, 도구 자체나 도구에서 사용되는 라이브러리 또는 일반적인 비디오 스펙을 이해하는 데 문제점이 있는지 확신할 수 없었다.
필자는 Freenode IRC 채널 #ffmpeg에 매달려서 문서를 읽었으며 심지어 C로 작성된 소스 코드를 연구하기도 했다. 이 IRC 채널에서 많은 도움을 얻었지만,
이 IRC 채널은 해당 문서를 읽거나 연구하여 독자적으로 해답을 찾을 수도 있는 질문을 하는 사람들에게는 그다지 관대하지 않았다.
처음에는 이점이 두려웠지만, 나중에는 이점이 무례함보다 노력을 더 보호한다고 단정했다. 이 커뮤니티의 사회적 규범은 먼저 FAQ와 문서에서 해답을 찾아야 하며,
해당 채널에서 질문을 하는 경우에는 관련된 유용한 정보나 컨텍스트를 이용하여 질문을 해야 하는 것처럼 보였다. 필자가 이러한 사회적 규범을 배운 후에는
질문에 대한 대답을 성공적으로 얻을 수 있었다.
초기 창업 과정에 참여한 모든 사람들이 고대하던 그 날이 왔을 때, 누구인가 당사를 인수할 의사를 표명해 왔다. 초기 흥분 상태가 가라앉은 후, 일련의 자산 실사가 진행되었다. 그 중에는 StudioNow를 빌드하는 데 사용했거나 사용 중인 소프트웨어의 라이센스를 검증하는 작업이 있었다. AOL의 변호사는 특히, 사용 중인 GPL 관련 코드가 있는지를 자세하게 추적했다. GPL에는 모든 GPL 코드로부터 파생된 결과는 그 소스 코드를 배포함과 동시에 GPL을 수반해야 한다는 조항이 있다. 게다가 GPL 라이센스가 있는 라이브러리에 대한 링크(정적 또는 동적 링크)가 이 라이센스의 "바이러스적" 특성을 나타나게 하는지가 매우 모호하다.
대부분은 아무런 문제가 없었다. 그러나 당사는 라이브러리가 링크된 FFmpeg을 사용하고 있었으며, 이는 LGPL(Lesser General Public License) 대신 GPL이
시행 중이었음을 의미한다.
소스 코드를 재배포하거나 수정하지 않았으며 단지 컴파일된 바이너리를 사용하여 비디오의 인코딩 방식을 변경했지만, 이러한 문제점을 해결할 수 있는
방안을 찾아야만 했다. 다행히도 당사의 인코딩 방식 변환 서비스에서는 GPL이 필요한 코드를 사용하고 있지 않았기 때문에 단지 다른 컴파일 플래그를 사용하여
FFmpeg 2진 파일을 다시 새로 컴파일했다.
오픈 소스 소프트웨어를 사용하는 시장에 솔루션을 성공적으로 내놓는 것은 단지 무료 소스 코드를 사용하는 것 이상이다. 오픈 소스 소프트웨어는 생태계이자 커뮤니티이다. 관심이 있는 다양한 커뮤니티에 참여하여 능동적인 구성원이 되면 많은 것을 얻을 수 있다. 더욱이 오픈 소스 소프트웨어의 사용상 특성으로 인해, 프로젝트에 다시 많은 것을 기여하게 된다. 마지막으로 오픈 소스 소프트웨어의 라이센스는 나중에 중요해질 수 있으므로 사용하는 다양한 오픈 소스 소프트웨어의 라이센스에 주의하도록 한다.
오픈 소스 소프트웨어를 기반으로 새로운 모험적 비즈니스를 구축하는 자유와 기쁨을 누리자!
교육
-
Dive into Python(Mark Pilgrim): Python이 잘 소개되어 있는 이 책을 읽어보자.
- Discover Python(developerWorks 2006): 변수, 컨테이너 오브젝트 및 복합 명령문을 포함하여, 초보 Python 프로그래머에게 필요한 주제를 논의하는
이 기사 시리즈를 탐구하자.
- Safari 온라인 서점: 이 온라인 서점을 방문하여 특정 기술과 관련된 참고자료를 찾아보자.
- 관심 이벤트: IBM 오픈 소스 개발자에게 유익한 컨퍼런스, 기술 박람회, 웹 캐스트 및 기타 행사를 확인하고 참여하자.
- developerWorks 오픈 소스 영역: 오픈 소스 기술을 사용하여 개발하고 이러한 기술을 IBM 제품과 함께 사용하는 데 도움이 되는 광범위한 사용법 정보,
도구 및 프로젝트 업데이트를 찾아보자.
제품 및 기술
- FFmpeg: 오디오와 비디오를 기록하고, 변환 및 스트리밍하는 데 필요한 크로스 플랫폼 솔루션에 관해 자세히 배우자.
- Boto: AWS 인터페이스를 제공하는 이 Python 패키지의 기본 소스 코드 저장소를 확인하자.
- Django: 이 상위 레벨 Python 웹 프레임워크에 관해 자세히 배우자.
- Pinax: Django를 기반으로 빌드된 이 플랫폼에 관한 정보를 확인하자.
- IBM 시험판 소프트웨어: 다운로드하거나 DVD로 이용할 수 있는 IBM 시험판 소프트웨어를 사용하여 차기 오픈 소스 개발 프로젝트를 강화하자.
토론
- developerWorks 커뮤니티: 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
- Real world open source: 오픈 소스에 초점을 맞춘 이 developerWorks 커뮤니티 그룹을 빌드하는 데 도움을 주자.
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그