[펌] CIO를 위한「오픈소스 도입 5단계론」

오픈소스 소프트웨어의 가장 큰 매력은 누구나 무료로 사용해 할 수 있고, 애플리케이션 개발 속도를 높일 수 있다는 점이다.

그러나 기업들이 핵심적인 업무용 애플리케이션에 오픈소스 컴포넌트를 도입할 때는 기술지원이 제대로 되는지, 지적재산권 문제에 저촉되지 않는지 확인해야 한다. 포레스터는 이를 위해 IT 고위 관리들이 오픈소스 도입을 결정할 때 참고할 수 있는 간단한 의사결정 프레임워크 ‘오픈소스 도입 절차(adoption funnel)’를 제공한다. 여기에는 구체적인 도입 방법뿐만 아니라 각 과정에서 고려해야 할 추가 위험 요소에 대한 내용도 포함돼 있다.

오픈소스 도입 절차 5단계
다음에 설명하는 5단계 프레임워크를 참고하면 기업의 시스템 환경에 맞춰 오픈소스를 도입했을 때 어떤 장점이 있는지를 짐작할 수 있을 것이다.

1. 다운로드
오픈소스 컴포넌트는 무료로 사용할 수 있다. 업무를 맡은 개발자는 인터넷을 통해 현재까지 개발된 7만개 가량의 컴포넌트를 검색해 필요한 것을 찾아야 하는데, 이들을 이용하면 개발 사이클이 매우 빨라지고 때로는 더 좋은 성능의 애플리케이션을 개발할 수 있다. 이 때 공인된 컴포넌트 목록은 별 도움이 되지 않는다. 개발자들은 오히려 이런 목록과 상관없이 스스로 테스트해 보는 것이 더 낫다고 생각할 것이다.

2. 개발
오픈소스 커뮤니티는 온라인으로 개발자들을 지원한다. 이는 프로젝트 매니저들이 안심할 수 있는 충분한 이유가 되는데, 오픈소스 컴포넌트를 이용하면 개발자들은 온라인 FAQ를 참조할 수 있고, 가끔은 뉴스그룹과 ‘위키’ 포럼을 통해 해당 컴포넌트를 직접 개발한 엔지니어의 도움을 받을 수도 있다. 한 프로젝트 매니저는 “해당 코드를 직접 개발한 사람과 대화를 나눌 수 있어 기술 지원과 개발 결과를 신뢰할 수 있다”라고 말했다.

3. 테스트
개발을 완료한 이후, 향후 애플리케이션을 사용할 기간 동안의 유지 보수 비용을 간과하지 말라. 테스트 단계는 기업 핵심 프로젝트 진행 과정 가운데 돈이 들어가는 단계이기도 하다. 이 단계에서 IT 중역들은 상용 컴포넌트와 독자 개발할 컴포넌트, 오픈소스 컴포넌트 등을 활용해 전체 시스템을 통합, 테스트하고 사후 유지 보수하는데 필요한 전체 비용을 고려해야 한다. 오픈소스 컴포넌트는 독립된 커뮤니티에서 개발도니 것이기 때문에 상용 컴포넌트에 비해 통합이나 업그레이드시 문제가 발생할 가능성이 높기 때문이다.

4. 생산
외부의 서비스 지원을 기다리지 않으려거든 내부 지원팀을 조직하라. 최고기술책임자(CIO)는 개발한 기업 핵심 시스템을 실제 생산에 적용하기 앞서, 기업 소유주에게 이 시스템의 높은 성능과 신뢰성을 증명해야 한다. 이 단계에서 오픈소스는 여러가지 면에서 상용 소프트웨어와 다를 바 없다. CIO는 들은 새벽 2시에 시스템이 다운됐을 때 HP, IBM, 노벨과 같은 상용 오픈소스 업체에게 도움을 요청할 것인지, 아니면 썬마이크로시스템이나 J보스와 같은 컴포넌트 제공업체에 도움을 요청할 것인지, 그것도 아니면 내부의 24시간 지원팀을 둘 것인지를 미리 명확히 해 두어야 한다.

5. 표준
당신이 원하는 것을 얻으려면 커뮤니티에 투자하라. 기업 표준에 따라 오픈소스 컴포넌트를 개발하려면 적어도 향후 5년간은 기술 지원과 경쟁력을 갖춰야 한다. 이를 위해 가장 좋은 방법은 오픈소스 컴포넌트 뒤에 있는 커뮤니티를 지원하는 것이다. 어떻게 하느냐고? 당신 기업의 코드를 제공하거나 MySQL, J보스와 같은 비용을 지불하고 개발을 의뢰하면 된다.

기업들의 조달 계획을 보면 상업적인 판매업체들에 대해서는 매우 잘 확립되어 있지만 오픈소스에 대해서는 임시적이거나 아예 없다. 이러한 IT 기업들은 포레스터의 ‘오픈소스 도입 절차’를 이용해 오픈소스 컴포넌트 선택에 도움을 받을 수 있다. 포레스터는 CIO에게 다음 세가지를 충고한다.

성급하게 오픈소스를 포기하지 말라. 생산 시스템 이외에는 오픈소스를 사용할 수 없도록 다운로드를 차단하는 것은 개발자들에게 한 손을 묶어놓고 일하라는 것과 다를 바 없다. 오픈소스 컴포넌트를 이용해 애플리케이션을 개발하면 시간과 비용을 줄일 수 있기 때문이다. 개발자들 스스로 프로젝트에 가장 적합하다고 생각하는 컴포넌트를 실험하고 배우고 제안할 수 있도록 허용하라.

테스트 단계에서 핵심적인 결정을 마무리하라. 물론 오픈소스 도입 과정에서 논란의 여지가 있거나 위험한 컴포넌트는 배제할 수 있도록 항상 주시해야 한다. 그러나 테스트 단계나 자금 조달 단계에서 주요 결정을 내리는 것이 좋다. 전체 프로젝트 예산을 조성하기 전에 IT 팀들이 일정한 기준에 맞는 라이선스와 품질을 내는지 확인하기 위해, 개발팀에게 새로운 컴포넌트나 오픈소스 컴포넌트 목록을 보존하라고 지시하라.

오픈소스 자문 그룹에게 도입 과정과 의사결정 지원툴을 사용하도록 하라. 오픈소스 컴포넌트와 커뮤니티를 평가하기 위해 개발자와 프로젝트 매니저, 변호사 및 조달 전문가 등으로 이루어진 팀을 조직하라. 수치화된 평가툴을 이용하면 커뮤니티와 상용 기술 지원 서비스의 상태에 대해 평가할 수 있는 객관적인 정보를 얻을 수 있다.

오픈소스 소프트웨어는 저렴한 가격과 높은 품질의 컴포넌트를 통해 상용 소프트웨어 시장을 위협할 것이다. 이 때문에 소프트웨어 업체들은 J보스나 마이SQL과 같은 오픈소스 컴포넌트가 자사의 핵심 시장에 진출하는 것을 매우 불안한 눈길로 바라보고 있다. 이들은 자신들이 통제하지 못하는 시장에 대해서는 오픈소스를 하나의 무기로 사용한다.

예를 들어 SAP는 MySQL을 일상품화하기 위해 MySQL을 지원하고, IBM은 자사가 주도하지 못하는 개발툴 시장을 겨냥해 이클립스 지원이라는 카드를 내밀었다. 그러나 이들 업체들도 결국은 오픈소스 소프트웨어와 어울리는 영업 방법을 찾을 것이다. 다음과 같은 경향이 바로 그런 경우다.

독립 소프트웨어 업체들은 자사 고유의 도입 절차를 확립하기 위해 2중 라이선스 전략을 이용할 것이다. 소프트웨어 라이선스는 이를 어떻게 사용할 것인가에 따라 달라진다. 예를 들어 MySQL의 경우, 개발자들에게는 자유롭게 데이터베이스를 사용할 수 있도록 GPL을 따르고, 애플리케이션을 설치한 기업들에게는 별도의 비용을 받는 상용 라이선스 정책을 사용한다. IBM이나 썬 등도 개발자들이 클라우드스케이프나 넷빈즈와 같은 소프트웨어를 무료로 사용할 수 있도록 하고 있다.

판매업체들은 오픈소스에 대한 흑색선전(scare tactics)을 펼치며 적극적으로 경쟁할 것이다. 실제로 BEA시스템즈, IBM, MS, 오라클을 비롯한 기업들은 자사의 핵심 시장을 보호하기 위해 오픈소스 라이선스가 기술지원과 시스템 통합 측면에서 자사 제품보다 떨어진다고 홍보한다. 따라서 오픈소스를 도입하려는 기업들은 정량적인 평가와 합리적인 결정 과정을 통해 이들 업체들의 주장이 사실인지 아닌지 검토해 보야야 한다.

시스템통합(SI) 업체들은 기업들이 오픈소스 도입의 위험을 줄일 수 있는 서비스를 제공할 것이다. 캡제미나이언스트&영, 일렉트로닉데이터시스템즈 등은 자사 고객들이 오픈소스 컴포넌트를 평가하고 도입을 결정하는 지원 서비스를 시작할 예정이다. 기업들은 이런 전문적인 서비스를 이용할 것이다. 그러나 라이선스 노출이나 코드 분기 등 오픈소스에 관한 복잡한 문제까지 다 해결해 줄 것으로 기대해서는 곤란하다.