한빛출판네트워크

저자: 버나드 골든(Bernard Golden)

18, 19세기 북아메리카 대륙에 미국인들이 자신들의 나라를 세우기 전까지 그곳에 발을 들여놓은 사람들의 무리는 크게 두 집단으로 나뉜다고 볼 수 있다. 첫 번째 무리는 정찰병, 사냥꾼, 탐험가, 모험가들로 구성된 집단으로 그야말로 황금도시 엘도라도를 찾아 신대륙으로 찾아온 무리라고 할 수 있다. 이들의 부를 향한 욕망은 때로는 불안하고 혼란스러워 상황을 법도 통하지 않는 극단으로까지 몰고 가기도 했다. 이처럼 초기엔 무법자들 천지였으나 시간이 흐름에 따라 어느 정도 사회분위기에 질서가 잡히기 시작하자 두 번째 집단이 신대륙에 발을 들여놓기 시작했다. 이들은 농부, 목축업자, 장사꾼들로 이루어진 무리로 열심히 자기 일을 해서 생계를 꾸려나가고자 했기 때문에 안정화된 법질서, 종교, 교육 등을 필요로 했다.

기술 전략에 대한 내용을 다루고 있는 제프리 무어(Geoffrey Moore)의 저서 『Crossing the Chasm』를 보면 이와 같은 현상은 기술채택 주기에도 비슷하게 적용된다고 한다. 소위 말하는, 모험가형 부류에 속하는 첫번째 파도 얼리 어댑터(Early Adopters)와 정착가형 부류에 속하는 두 번째 파도 프래그매티스트(Pragmatists) 부류가 기술 전략에도 똑같이 적용되기 때문이다. 따라서 기술 채택에 있어도 각각의 부류가 요구하는 제품 요구사항은 다를 수 밖에 없다. 얼리 어댑터들은 신기술이 가진 모험을 추구하는 반면 프래그매티스트들은 입증된 기술이 가져다 주는 안정을 추구한다. 분명 무어의 저서는 기술 전략을 다루는 책 중에서는 고전으로 꼽힐만하지만 이 프로세스가 오픈 소스 세계에서도 동일한 의미를 가질 수 있을지는 의문이다.

본 기사에서는 이와 같이 상반된 성향을 지닌 기술 채택자들에 대해 살펴보고, 이들이 오픈 소스 제품에 어떤 반응을 보이는지, 더 구체적으로는 프래그매티스트들이 오픈 소스 사용을 어떻게 받아들이는지에 대해 살펴볼 것이다. 이 외에도 마지막 부분에 가서는 각 조직에 적합한 오픈 소스 전략을 세우는 방법에 대해서도 살펴볼 것이다.

기술 개발 주기

얼리 어댑터(Early Adopter)

얼리 어댑터들은 시장 진입 시간 및 비용을 절약하면서 새로운 서비스를 제공하기 위해 새로운 기술을 사용한다. 이들은 자신의 비즈니스 경쟁력을 강화하기 위한 새로운 제품을 찾아내기 위해 기술 개발에서 눈을 떼지 않는다. 조금이라도 나은 점이 있는 소스와 새로운 것들을 끊임없이 찾아 나선다.

이렇듯 얼리 어댑터들은 개발되자마자 거의 초창기 때에 제품 채택과 사용을 시작하기 때문에 치명적인 단점을 가질 수도 있다. 이런 제품의 기술 제공자들은 대부분 불안한 미래를 가진 영세한 업체라 제대로 된 테스트를 거치지 않았을 경우까지도 염두에 두어야 하기 때문이다. 또한 많은 작업과 다중 설치과정, 애플리케이션 가동 및 실행에 많은 노력을 들여야 하기 때문에 제대로 작동하지 않을 수도 있다. 이밖에도 얼리 어댑터들이 감수해야 할 상황은 더 있다. 빈약한 기술지원, 제대로 문서화된 자료 부족, 참조 커스터머의 부족 등등이다. 하지만 얼리 어댑터들은 자기들이 새로운 기술을 구현하면서 경쟁 우위를 얻게 될 것이라 생각하기 때문에 이와 같은 단점들을 기꺼이 감수한다. 이들은 새로운 제품이나 업적 등에 광분하고 아주 큰 호기심을 보이는 경향이 있다.

프래그매티스트(Pragmatist)

앞서 언급한 얼리 어댑터와는 달리 프래그매티스트들의 기술 구현에 대한 입장과 시선은 확연히 다르다. 이들은 기술이 어느 정도 기반을 잡아 안전하다고 생각될 경우에만 그 기술을 이용한다. 그렇다고 해서 이 무리들이 시장에 전혀 발을 들여놓지 않고 밖에서 구경만 하는 것은 아니다. 단지 신기술을 받아들여야 할 때 기술과 함께 감수해야 할 위험 요소들까지도 기꺼이 받아들이는 않는다는 것 뿐이다. 이들은 문서화, 교육, 기술지원 등과 같은 용어를 비롯하여 이미 친숙하게 잘 알려진, 사용하기 쉬운 제품만을 추구하는 경향이 있다.

이들에게 성공적으로 기술을 판매하려면 일단 기술 제공자는 무어가 지칭한 "완전 제품(Whole Product)"이 무엇인지부터 확실하게 짚고 넘어가야 한다. 완전 제품은 사용하기 쉬워야 하며, 기술 지원 및 튜토리얼 지원이 용이해야 하고, 버그가 거의 없는 안전한 제품이어야 한다. 따라서 일부 프래그매티스들의 직접적인 경쟁자들은 이미 그 기술을 구현하고 있을 수도 있다. 그 결과 이들은 이미 그들이 사용하려는 기술이 잘 동작하고 있다는 사실을 알고 있다. 간단히 말해 프래그매티스 조직은 "이미 다른 회사에서도 많이 사용하고 있기 때문에 안전하다"라는 사고 방식을 가진 무리로 분류할 수 있다.

오픈 소스 세계에서 완전 제품이 나올 수 있을까?

오픈 소스 세계에서 단일 소프트웨어 제공자란 있을 수 없다. 오픈 소스는 제품의 일정 부분에 공헌을 한 개인들의 노고로 개발되기 때문에 문서화도 정말 필요한 부분에 대해서만 최소한의 문서를 가지고 있을 수 있다. 심지어는 지원 단체가 없는 경우도, 물론 컨설팅 조차 없을 수도 있다. 결론적으로 제공 조직이 없기 때문에 부차적으로 이용할 수 있는 서비스가 없게 될 수도 있다는 말이다. 그렇다면 서로 다른 성향을 지닌 고객들이 제품 개발과 배포라는 현실에는 어떻게 반응할 것인가?

얼리 어댑터들은 오픈 소스 제품들을 열광적으로 수용했다. 이들은 항상 초기 단계에 있는 기술 제공자들 즉, 정의 대로라면 자유로운 조직과 함께 작업해왔다. 얼리 어댑터들은 저렴한 비용, 빠른 제품출시 주기, 다음 표준을 빠르게 구현할 수 있다는 점으로 인해 오픈 소스라는 기술로부터 경쟁 우위를 획득할 수 있었다. 특히나 소스 코드를 쉽게 이용할 수 있다는 점으로 인해 얼리 어댑터들은 더욱 오픈 소스에 열광하게 되었다. 구현 중에 문제와 마주치더라도 곧바로 수정할 수 있기 때문에 미숙한 제품 제공자가 업데이트된 제품을 출시하기까지 굳이 기다릴 필요가 없기 때문이다. 그 결과 얼리 어댑터와 오픈 소스는 천생연분의 찰떡 궁합이라고 할 수 밖에 없다.

이에 반해 이제 프래그매티스트들은 오픈 소스에 대한 실제적인 딜레마와 직면하게 되었다. 이제는 각 조직에서도 오픈 소스 솔루션을 충분히 구현하고 있는 단계에 도달했기 때문에 오픈 소스를 수용하는 시장 범위도 어느 정도 충족되는 수준에 이르렀다. 이제는 더 이상 프래그매티스트들도 오픈 소스를 구현을 미뤄두어야 할 이유가 없어졌다는 이야기이다.

이로써, 완전 제품이 가지고 있어야 할 주요 특징들의 그 의미가 일부 퇴색되어 가는 것 같다. 왜냐하면 프래그매티스트들에게 있어 지원 서비스가 없는 기술로 전향하는 것은 꺼림직한 일이기 때문이다. 그렇지만 이제 오픈 소스 없이 그들의 욕구를 충족시켜줄 완전 제품을 과연 어디에서 찾을 수 있겠는가? 이 문제를 해결하기 위해서 프래그매티스트들은 일단 자신들이 속한 조직부터 자세히 살펴본 후 스스로 완전 제품을 만들어야 할 것이다. 이와 같은 일이 아주 힘들어보이긴 하지만 이전에 단일-소스 세계에서 있었던 것보다 오픈 소스로 더 나은 품질의 완전 제품을 만들 수 있기 때문에 그만큼 더 가치있는 일이라고 할 수 있겠다.

오픈 소스 세계에서 완전 제품 만들기

어떻게 하면 프래그매티스트들이 스스로 완전 제품을 만들 수 있을까? 어떻게 하면 오픈 소스를 편안하게 사용할 수 있게 해주는 리소스를 모두 찾아낼 수 있을까? 이 세상에 완전 제품 제공자가 있다고 기대할 수 없기 때문에 프래그매티스트들은 팔을 걷어 부치고, 스스로 하겠다는 자세로 문제에 대해 실제적인 접근 방식을 취해야 할 것이다. 오픈 소스 기술이 가진 서로 다른 특성에 정통한 협력체를 개발해서 필요한 완전 제품을 생성하는데 사용해야 한다. 이들은 자신을 일개 소매상이 아니라 영화 제작자처럼 생각하면서 기술 채택과 관련된 새로운 모델을 사용해야 할 것이다.

영화 제작자들은 배우, 세트 디자이너, 코디네이터 등과 같이 각 분야의 전문가들을 영입함으로써 최종적인 완전 제품을 만든다. 제작자는 제품을 완성하기 위해 이러한 모든 것들을 관리하고 선택할 책임을 지며, 각각의 전문가들은 서로 독립적으로 자신의 영역에 충실하면서 다른 전문가들과 협력하여 일한다.

마찬가지로 프래그매티스들도 필요로 하는 오픈 소스 완전 제품을 만들어 낼 때 교육, 문서화, 지원 작업과 같은 각 분야에서 전문가를 영입하는 접근방식을 취해야 한다. 너무 노력을 많이 들여야 하는 것처럼 보이기도 하지만, 여기에는 이에 상응하는 이익도 있다. 단일 제공자에 전적으로 의지할 때보다 각 분야의 전문가들을 사용하면 더 좋은 완전 제품이 탄생할 수 있다.

전적인 책임을 지는 단일 제공자가 없다는 것이 위험해 보일 수도 있겠지만 실제로 책임이 여러 곳에 분산되어 있는 것이 더 안전하다. "숨구멍이 하나"라는 말의 이면에는 "한 한방에 실패할 수도 있다"는 말이기도 하기 때문이다. 결과적으로 단일 제공자의 손아귀에 완전 제품의 모든 책임을 전가하는 것이 훨씬 더 위험할 수도 있다. 그리고 프래그매티스들은 이런 위험을 되도록이면 피하고 싶어할 것이다.

완전 제품 만들기를 보여주는 두 가지 예제

예를 들어 설명하면 그 개념을 훨씬 더 쉽게 이해할 수 있게 된다. 같은 맥락으로 필자도 완전 제품에 대해 두 가지 예제를 설명함으로써 여러분의 이해를 돕겠다. 첫번째 예제는 신기술을 조직에 어떻게 끌어들일 것인지, 그리고 그 기술을 이용해 어떻게 완전 제품을 어떻게 만들어 낼 수 있을 것인지 대한 간략한 개요이다. 두 번째는 필자의 회사에서 요 근래에 완수한 실무 프로젝트에 대한 설명으로 기술 선택에 필요한 항목과 필요로하는 완전 제품의 요구사항을 지정하는 방법에 대한 것이다.

조직으로 새로운 오픈 소스 기술 도입하기

여러분이 오픈 소스 제품을 조직체 내로 도입해야 할 책임을 맡았다고 가정해보자. 아마도 새로운 시스템 개발, 특히 시스템의 데이터 저장층에 드는 비용을 감소시킬 수 있는 방법에 대해 알아보라는 지시는 이미 받았을 것이다. 다양한 소프트웨어 시스템의 핵심은 관계 데이터베이스에 있다. 시중에는 몇몇 오픈 소스 관계 데이터베이스 대안들이 나와있으며, 여기에는 MySQL도 포함된다. MySQL을 사용하면 시스템 비용을 최소 5천 달러에서 10만 달러 혹은 훨씬 더 많은 액수까지도 절감할 수 있다. 게다가 소프트웨어 자체는 아무런 비용을 치루지 않고서도 자유롭게 무료로 다운받을 수 있다. 그렇지만 어디에서 이 소프트웨어에 대한 문서, 교육 및 지원을 받을 수 있겠는가?

---

참고 도서 MySQL 시스템 관리와 프로그래밍: 자바, PHP, 펄, C, 파이썬, 개정판 원서: Managing & Using MySQL, 2nd Edition 조지 리스, 랜디 제이 야거, 팀 킹, 휴 윌리엄스 상세설명보기 목차보기 샘플챕터보기

---

시중에는 훌륭한 MySQL 책이 몇 권 나와있다. 이와 같은 책들은 제품에 대한 문서로서 튜토리얼이나 레퍼런스 두 가지 모두로 손색없이 활용할 수 있다. 다양한 조직에서 MySQL에 대한 교육을 제공하고 있으며 조직 구성원들에게 제품 사용법을 가르치고 있다. 그 결과 제품에 대한 지원을 제공하는 전문 서비스 회사가 상당수 생기고 있으며 필요에 따라서 특화된 컨설팅 서비스도 제공하고 있다. 오픈 소스 세계에서 지원과 관련한 또 다른 기막힌 리소스는 다른 사용자들의 축적된 경험을 들 수 있다. 메일링 리스트만 잘만 활용하면 수많은 능숙한 MySQL 사용자들의 모니터링, 메일링 리스트에 올라온 질문에 도움을 주는 글 등을 통해 쉽게 얻을 수 있다. 이는 비용을 들이지 않고서 얼마든지 이용할 수 있는 정말 뛰어난 지원 메커니즘이라 할 수 있겠다.

지금 든 예제에서, 관련 데이터베이스 완전 제품을 생성하기 위해 몇몇 제공자들의 서비스는 인용될 수 있다. 완전 제품의 구성 요소로 들어가는 각각의 필요 부분은 전문가들로부터 나온 것이므로 의심의 여지 없이 일반 조직으로부터 나온 유사 제품보다 훨씬 더 좋을 것이다.

프로젝트 실행을 위해 연합체 이용하기

완전 제품을 만드는 새로운 방법을 더 구체적으로 논하기 위해 최근에 필자가 진행했던 프로젝트에서의 경험을 말해보겠다. 우리는 큰 재단의 웹 사이트와 중앙 CRM 시스템을 통합해달라는 의뢰를 받았다. 웹 폼에 있는 유저 인포메이션 인풋이 CRM 데이터베이스 안으로 삽입될 수 있도록 말이다. 몇몇 상이한 아키텍처와 제품에 대해 고려해본 후, 우리는 다음과 같은 아키텍처를 제안하였다. 이 아키텍처는 통합 메커니즘을 위한 웹 서비스로, 유저 데이터를 포함하고 있는 XML 파일 부하량을 전달하는 역할을 한다. 우리는 펄로 통합 메커니즘을 구현하기로 했다. 왜냐하면 오픈 소스인 펄과 같은 제품이 아닌 다른 상업용 제품을 사용할 경우, 프로젝트 전체 비용의 최소 30%정도가 초과될 것이고 이는 예산 초과를 발생시키기 때문이다. 우리의 개발환경은 기본 데이터베이스로 MySQL을 사용하는 아파치 웹 서버를 갖춘 윈도우 XP였으며 제작환경은 윈도우 2000, IIS 웹 서버, 데이터베이스로 MS SQL을 사용하게 될 것이었다.

프로젝트를 진행하면서 우리는 다양한 펄 모듈을 사용했다. XML 부하량에 적합한 몇몇 XML-지향 모듈, 웹 서비스 통합을 위한 SOAP::Lite, 유틸리티 함수를 위한 일부 도움말 모듈 등등… 특히, 이 중에서 우리가 좋아했던 도움말 모듈은 Win32::Guidgen이었다. CRM 시스템이 테이블 키로 32문자 임의-발생 실행자를 사용하기 때문이었다. 이 모듈은 일상적인 쓰기 작업을 엄청나게 절감시켜주는 효과가 있었다.

우리가 사용하는 주요 모듈에 대한 문서화는 일반 출판물로도 나와있었기 때문에 우리는 이를 활용할 수 있었다. 상업용 소프트웨어 회사와 작업할 때 느낀 점은 제품 문서화가 진짜 형편없다는 것이었는데, 잘 쓰여진 튜토리얼과 레퍼런스 매뉴얼까지 있다는 사실은 정말 기쁘기 그지 없는 일이었다. 특히, 개발 환경에서 제품 환경으로 변경하는 시기에 있는 사람들에게는 『Programming the Perl DBI』를 추천하는 바이다. MySQL에서 SQL 서버로 이동하면서 발생하는 각종 문제들을 식별해내는데 이 책은 정말 큰 도움을 주었다.

		Programming the Perl DBI

하지만 도움을 받을 수 있는 문서가 있다고 하더라도 프로젝트를 진행하는 동안 더 세심한 도움을 필요로하는 문제들이 발생했다. 책에는 나와있지 않은 문제들(특히, 기술적 지원이 필요한 문제들)과 씨름해야 했기 때문이다. 여기서 다시 한 번 더 통합 메커니즘으로 펄을 선택한 것이 천만 다행이라는 생각이 들지 않을 수 없었다. 몇몇 메일링 리스트를 통해 우리는 충분한 기술지원을 제공받을 수 있었기 때문이다. 전 세계에 널리 퍼져있는 각 분야의 전문가들로부터 필요한 도움을 받을 수 있었을 뿐만 아니라 모듈을 만든 당사자들로부터 우리의 의문사항에 대한 해답을 직접 받을 수도 있었다.

특히 프로젝트에 속한 구성원들이 CRM 소프트웨어의 문제와 직면했을 때, 오픈 소스와 다른 상업용 소프트웨어 간의 대비는 더 분명하게 드러났다. 설사 누군가가 문제에 관심을 갖는다고 하더라도 기술 지원 조직이 벤더들과 의견을 교환하는 데에는 수 일이 걸리기 때문이다. 설상가상으로 의견교환이 이루어진다고 하더라도 그 내용이 정확한 것이 아닐 때도 있었다. 어쨌든 간에 문제 해결은 하게 되겠지만 이 과정에서 귀중한 프로젝트 수행시간을 허무하게 낭비하는 결과를 초래하게 된다.

어쨌든 프로젝트 통합 작업을 하면서 우리는 좋은 경험을 했다. 새로운 소프트웨어를 사용하면서 발생하게 될 전형적인 문제는 앞서 언급한 완전 제품 연합에서 쉽게 설명되었다. 새로운 소프트웨어를 배우는데 필요한 문서도 나와있고, 작업하면서 발생하는 문제와 기술지원도 얼마든지 이용할 수 있다. 때로는 소프트웨어 저작자로부터 직접적인 소스를 얻을 수도 있다. 이 모든 것들은 오픈 소스 연합에 기반을 둔 완전 제품을 생성함으로써 획득된 것이며, 클라이언트들은 비용대비 효율을 고려해봤을 때 결코 다른 상용 기술과는 비교도 안될 훌륭한 해결책으로부터 혜택을 받을 수 있다.

오픈 소스 전략

그렇다면 이제부터는 조직들이 오픈 소스 전략을 개발하는 방법에 대해 알아보도록 하겠다. 오픈 소스 기반의 프로젝트를 구현할 때, 단일 소스 모델에서 다중 소스 제휴 모델로 전향하려면 어떻게 해야 할까? 어떻게 하면 영화 제작자처럼 많은 일들을 처리할 수 있게 될까?

위와 같은 질문에 대해, 다음의 방법들을 추천하는 바이다.

• 정보를 교환할 수 있는 파트너와 소스가 필요하게 될 것이라는 사실을 인지하라. 오픈 소스 세계를 완전히 이해했다면, 완전 제품을 만들기 위해 여러 가지 요소를 추구해야 한다는 사실을 받아들일 수 있게 될 것이다. 따라서 각 요소들을 식별하고, 요소를 전달할 수 있는 제공자를 선택하기 위해 명시적인 절차를 밝혀놓아야 한다.
• 초기 단계부터 오픈 소스를 사용하는 안내 프로젝트를 만들어보자. 다른 조직에 적용되거나 향후 진행될 큰 프로젝트를 대비해 작은 프로젝트를 실행하면서 얻게 되는 시행착오는 향후 더 큰 프로젝트를 쉽게 진행할 수 있는 주춧돌 역할을 해줄 것이다. 그리고 팀 구성원은 스스로 알아서 일하는 사람으로 선택하자. 프로젝트를 진행하면서 이들은 누구도 해보지 못했던 일들을 처음으로 시작해야 하기 때문에 조직에 꼭 필요한 성공적인 완전 제품을 개발하려면 불확실함 속에서도 실험정신을 갖고 용감히 일을 해낼 사람이 필요하다. 다시 말해, 팀 전체를 얼리 어댑터 고객으로 모시고 이런 상황에서도 편안하게 일 할 수 있는 사람들과 함께 작업해야 한다는 뜻이다.
• 일반적인 팀원 대다수는 이미 잘 만들어진 제품을 원하는 프래그매티스트란 사실을 받아들이자. 팀원들 모두 성공을 바라고 있다는 점에서 오픈 소스와 일반 소프트웨어 프로그램 간에는 차이가 없다. 문서화와 교육은 필수항목이다. 전문 서비스 조직과 메일링 리스트를 통한 지원을 이용할 수 있는지를 팀원들에게 알려주자. 이러한 서비스를 제공하는 측, 다시 말해 협력 파트너들은 앞서 설명한 안내 프로젝트에서 이미 선정되었어야 한다. 그리고 이러한 협력 파트너들을 도움을 받을 수 있는 리소스로 활용하도록 널리 알리도록 한다. 일반 상용제품과 비교해보았을 때, 이런 리소스가 없다면 오픈 소스 제품이 결코 성공할 실마리가 없을 것이다.
• 완전 제품 협력체를 구성하고 있는 멤버들의 수행능력을 평가하라. 과연 그들은 유능하고 언행이 일치하는 사람들인가? 기한을 잘 지키는가? 그들에게 작업을 믿고 맡길 수 있는가? 이들은 완전 제품을 만드는데 결정적인 역할을 맏고 있는 사람들이다. 따라서 완전 제품에 공헌할만한 성과를 올리지 못한다면 더 괜찮은 기술 제공자들을 찾아 나서야 할 것이다.
• 지금 사용하고 있는 오픈 소스 제품의 개발 과정을 계속해서 추적해보자. 새로운 버전이 출시됨에 따라 업데이트된 버전이 설치가 되었는지 그렇지 않은지를 점검하자. 또한 새로운 버전에 대한 문서화 자료를 이용할 수 있는지 확인해보자. 협력 파트너는 새로운 버전을 지원할 준비가 되었는지 알아보고 결정하자. 만약 준비가 안되었다면 협력 구성원을 바꾸어야 하는지, 아니면 새로운 버전으로 전향을 좀 지연해야 할지에 대해서도 알아보자.

결론

고객과 제공자의 관점으로 나누어 생각해보자. 제공자의 경우 무어의 기술채택 주기는 오픈 소스의 도래로 급격하게 변화하였지만 고객측에 있어서는 거의 변한 것이 없다. 일부 조직들은 경쟁 우위를 선점하길 기대하면서 새로운 기술을 적극적으로 도입하는 반면 어떤 조직에서는 부가 서비스를 이용할 수 있을 정도로 기술이 확실하고 사업 성과가 확실해질 때까지 새로운 기술 도입을 망설이기도 한다.

저렴한 비용, 시장 진입 비용, 중대한 사업적 이득을 제공하는 확장성 등등의 요소로 인해 오픈 소스는 얼리 어댑터 고객들에게는 최선의 선택이다. 하지만 프래그매티스트들에게 있어 오픈 소스는 절대 쉬운 선택이 될 수 없다. 오픈 소스의 혜택부터 생각하기 이전에 그들은 기술 획득에 대한 신 모델을 받아들이고 완전 제품으로서 기술에 대한 정보를 주고 받을 수 있는 연합체를 발전시켜야 한다. 이와 같은 절차를 제대로 밟아 나가는 프래그매티스트들만이 오픈 소스를 이용하여 사업적 투자수익율(ROI, return on investment)의 혜택을 누릴 수 있다.