인더스트리 인사이더의 이번 기사에서는 오프타로스의 콘텐츠 관리 리더인 시쓰 고트립이 '오픈소스 콘텐츠 관리 시스템의 선택 방법'에 대해 설명한다.
고트립은 15개의 오픈소스 프로젝트를 요약하고 오픈소스 CMS와 상용 소프트웨어 선택 사이의 차이점을 설명한 '콘텐츠 관리 문제와 오픈소스 솔루션' 백서의 저자이다.
오픈소스 소프트웨어에서 소스코드만 개방돼 있는 것이 아니다.
오픈소스는 개방된 형태로 이뤄진다. 사용자 메일 리스트 등의 통신 수단에 가입하면 소프트웨어 개발에서 다른 사람들의 움직임, 어느 기능이 좋은지, 어느 기능의 개발이 필요한지를 파악하기가 쉽다. 프로젝트 로드맵 혹은 공개된 버그 리스트를 읽으면 프로젝트의 방향, 추진 주체, 팀의 조직력 등에 대해 알 수 있게 된다. 또한 개발 그룹의 개성과 사회적 관계에 대해서도 알 수 있다.
먼저 사업 방향성 따라 선택 범위 축소
저장된 문서를 읽어 내려가면서 대답이 오지 않은 질문과 대답이 온 질문에 주목하라. 몇몇 사람이 활발하게 대답을 올리는 것은 주축 인력 한 명이 빠져나가도 그 공동체가 생존할 수 있는 강인함을 나타내는 것이다. 또한 대답의 내용에 주목하라. 문서를 참조하는 것은 문서의 존재를 나타내기 때문에 좋은 징조다! 단계별 사용법이 길게 설명되어 있는 것은 문서가 충분하지 않거나 문서 개발을 위한 절차가 제대로 개발되어 있지 않다는 것을 의미한다. 또한 코드 베이스가 활발하게 유지 관리되는 것이 아니라 사용자가 항상 편법을 찾아야 함을 의미한다. 예를 들어, "x 라는 라인을 코멘트로 아웃시키고 다음 코드를 추가하라"라는 설명이 되어 있다는 것은 누구도 수정된 코드를 패치하지 않고 있다는 사실을 의미한다.
개발 가이드와 관행을 검토하거나 기술 인력이 검토하도록 하라. 잘 관리되는 프로젝트들은 기능 로드맵이 있으며 분명히 정의된 출시 절차가 있고 코드 표준이 있으며 추가된 부분이 코드 베이스의 다른 부분을 훼손하지 않는지 자동으로 검사하는 관행을 사용한다. 개발자 사이트를 살펴보면 어떤 기능이 출시되고 어떤 테스트가 수행되는지에 대해 개발 공동체가 어떻게 결정을 내리는지 분명하게 알 수 있다.
버그 추적 시스템을 훑어 내려가면 소프트웨어가 얼마나 활발하게 테스트되는지 그리고 얼마나 효율적으로 문제가 해결되고 있는지를 알 수 있다. 버그 추적 시스템에 많은 문제가 있다고 해서 나쁘다고 볼 일은 아니다. 오히려 해당 소프트웨어를 개선시키기 위해 공동체와 협력하는 사용자가 존재한다는 의미가 된다. 이슈의 내용을 살펴보라. 버그 추적 시스템은 또한 소프트웨어의 진화 방향을 시사하는 개선 요청들을 기록하는데 사용되기도 한다.
가장 중요한 것은 소프트웨어를 실제 사용해 보는 것이다. 많은 경우 데모를 위해서 소프트웨어를 설치할 필요가 없다.
웹 사이트 www.opensourcecms.com에 가면 드루팔, 맘보, 줌라를 포함하는 70개가 넘는 오픈소스 LAMP 기반의 CMS 데모 버전이 있다. eZ 퍼블리시, 레냐, phpBB는 이 사이트에서 수행되는 데모 소프트웨어를 제공한다. 소프트웨어를 사용하면서 그 과정에서 실제 사용자를 동참시켜라. 이들도 소프트웨어를 사용해 보도록 하고 무엇이 바뀌기를 원하는지 그리고 그러한 사항이 얼마나 중요한지 목록을 만들어라. 이러한 시험적 사용에 있어서 그들에게 오너쉽을 부여하라. 그렇게 함으로써 이들이 솔루션에 투자하고 수용성을 높일 수 있을 것이다.
절약한 돈 제대로 활용하기
나는 가능하다면 상용 소프트웨어 평가에 있어서 동일한 권고안을 적용할 것이라는 점을 지적해야 되겠다. 그러나 소프트웨어 업체들은 기술의 배경, 기술지원이 얼마나 좋은지, 어떻게 조직이 변화에 대응하는지 노출시키지 않는다.
사실 CMS 이니셔티브의 성공이나 실패에 있어서 기술이 최대 요소는 아니다. CMS 의 성공은 콘텐츠 이전, 사업관행 개선, 수용의 달성에 의존적이다. 라이센스 비용과 상이한 지원 옵션이 없다면 솔루션에 대한 투자는 CMS 이니셔티브의 성공에 가장 큰 영향을 끼치는 요소들로 분리될 수 있다.
요구사항을 더 잘 이해하기 위해 프로토타입 개발, 프로젝트 관리, 사업관행 개선, 콘텐츠 이전, 사용자 교육 등에 더 많은 시간과 돈을 사용할 수 있다. 스텝 투의 제임스 로버트슨은 ‘CMS 구축에 있어서 지출 패턴’라는 글에서 구현은 CMS 프로젝트에 있어서 단지 최초의 3가지 단계에 불과하다고 적고 있다.
구현 단계 뒤에는 데이터 이전, 교육, 솔루션 전파, 그리고 개선기능 (연기되거나 솔루션이 전개됐을 때 실현되는 요구사항)을 포함하는 수용 단계가 따른다. 로버트슨은 이 두 가지 단계에 대해 시간과 노력에 대해 실현성있는 기대치를 갖도록 권장한다. 수용 단계는 최대 12달 동안 지속되며 그 후에는 지속적인 개선활동이 따른다.
솔루션이 일단 전개되고 나면 진화하도록 놔둬야 한다. 만약 이해당사자가 프로젝트의 초기 단계에 관여한다면 아마도 이들은 애플리케이션의 오너쉽을 갖고 있다고 느끼며 자신들의 사업관행에 애플리케이션을 어떻게 적용할지 이해하고 난 후 개선방향에 대해 생각하게 될 것이다. 이들 사용자에게 애플리케이션의 발전 잠재력을 이해시키면 이들은 최초 버전의 범위에 대해 덜 완고한 입장을 보이게 될 것이다.
오픈소스 소프트웨어는 더 많은 지원 옵션 (상용, 컨설팅, 공동체)을 제공하기 때문에 조직의 지원 필요성에 대해 고민해봐야 한다. 정책이나 습관에 따라 많은 업체들은 항상 지원 계약을 구입한다. 일부의 경우 기술지원이 자주 요청되는 경우 이러한 투자는 정당화 된다. 그러나 소프트웨어가 사람의 개입없이 잘 운영되는 경우 혹은 기업이 기술을 이해하고 있는 경험 많은 기술자를 보유하고 있는 경우 가입형태의 지원 패키지는 의미가 떨어진다. 개발자들은 지식 베이스나 개방형 검색 엔진에 접근하여 전화나 이메일 기반 지원보다 더 빠르고 유용한 답을 얻는 경우가 많다.
만약 상용 소프트웨어 형태의 지원이 바람직하다면 오픈소스 프로젝트를 호스팅하는 회사 혹은스파이크소스나 소스랩스와 같은 서드파티가 이를 제공할 수 있다. 솔루션 전개를 도운 시스템 통합회사는 사용 횟수 기반에서 가입 기반에 이르는 다양한 지원 모델을 제공할 수 있다.
지원은 어떻게?
구축된 시스템을 지원하는 경우 공동체에 무엇을 되돌려 줄지도 고민해야 된다. 스스로 사용하기 위해 개발한 코드를 반드시 돌려줄 필요는 없지만 그렇게 하는 것이 오히려 스스로에게 도움이 될 것이다. 간단한 판단 기준은 만약 유지관리비용이 독점관리에 의한 경쟁상 이점을 능가한다면 코드를 돌려주는 것이 좋다.
코드를 돌려주면 많은 좋은 일들이 생길 수 잇다. 코드는 정말 훌륭한 프로그래머들에 의해 리뷰된다. 코드는 핵심 애플리케이션의 일부가 되기 때문에 업그레이드를 하는 경우 걱정할 필요가 줄어든다. 또한 단신이 공헌한 부분은 새로운 기능으로 성장할 잠재력이 있어서 당신에게 유용할 것이다. 애플리케이션은 개선되며 더 많은 사용자를 끌어들이기 때문에 미래가 약속된다.
오픈소스 CMS 소프트웨어는 일반적 문제에 대해 직접적인 솔루션을 찾는 기업들에게 매력적인 선택이 될 수 있다. 그러나 소프트웨어 선택에 관한 전통적인 방법은 상용 소프트웨어에 비해 오픈소스를 평가할 때 도움을 많이 주지 못한다. 사실 오픈소스 CMS 소프트웨어의 다양성과 범위의 광범위함이 결합돼 가능성의 검토는 지루하고 방향성을 잃게 되기가 쉽다.
방향감각을 찾기 위해서는 사업관련 문제에 집중하고 다른 회사가 유사한 문제 해결을 위해 어떤 방식을 사용했는지 검토하라. 다양한 옵션으로 범위를 축소했다면 오픈소스의 개방적 속성으로 인해 상용 소프트웨어에서는 가능하지 않았던 수준으로 오픈소스 소프트웨어에 대해 속속들이 알 수 있다. 이러한 장점을 잘 활용하면 오픈소스는 당신 회사의 이니셔티브가 갖는 위험도를 낮추며 회사와 함께 성장할 수 있는 솔루션을 제공할 수 있다.@
**필자 약력**
시쓰 고트립은 IT 서비스 업체 오프타로스의 콘텐츠 관리 리더이다. 그는 다양한 소프트웨어를 사용해 수많은 콘텐츠 관리 프로젝트를 수행했다. 고트립은 CM 프로페셔널의 멤버이다.
원문링크
http://www.zdnet.co.kr/builder/man/etc/0,39031658,39143938,00.htm