신기술 밀림 속 생존전략 Part 2: 네거티브 전략, FUD |
 |
지난 글에서 우리는 신기술에 대해 잘못된 정보를 퍼트리거나 자신들의 이익을 취하면 그만이라는 식의 신기술 오용 사례들을 살펴보았다. 다행한 일은 최근 다양한 매체를 통해 행해지고 있는 유명 포탈업체의 UCC 광고가 UCC의 본래 의미를 제대로 활용하고 있다는 점이다.
FUD는 Fear(공포), Uncertainty(불확실성), Doubt(의심)로 구성된 단어다. 경쟁 제품에 대한 부정적인 정보를 퍼트리는 마케팅이나 영업전략을 의미한다. 컴퓨터 하드웨어 업계에서 통용되던 말인데 점차 다른 분야에서도 쓰이게 되었다.
FUD 현황
FUD의 본고장은 말할 것도 없지만, 국내 미디어 사이트에서도 FUD에 관한 기사를 찾아보면 스무 건 이상을 만날 수 있다. FUD는 ‘리눅스와 윈도우’, ‘J2EE와 닷넷’과 같이 경쟁구도를 이루는 기술이나 업체 사이에서 오고 간다. 미디어 사이트에 기사 형태로 작성된 것은 구두로 사용되는 FUD 사례에 비하면 매우 미미한 편이다.
그림1. 주요 미디어 사이트의 ‘FUD’ 검색 결과
필자는 특정 프로젝트의 입찰 과정에서 특정 업체의 영업담당자가 발주업체의 인사에게 경쟁업체를 상식 이하로 비하했다는 이야기를 들은 일이 있다. 돈의 논리 앞에서 상도의를 완전히 저버리는 씁쓸한 경우다. 직접 들은 이야기가 아니기 때문에 오히려 와전된 이야기기를 바랄 뿐이다.
최근에 지인 블로그의 글을 통해 국내 유명 솔루션 업체의 행사 소개를 접했다. 행사 중에 유명 오픈소스 제품인 스프링(Spring)과 하이버네이트(Hibernate)가 표준이 아니기 때문에 사용하지 말라는 견해를 밝혔다고 한다. 표면적으로는 옳은 소리로 들리지만 대표적인 FUD 사례다. 왜 이러한 주장이 FUD인가는 설명하기 쉽지 않은 대목이다. 하지만 가장 널리 퍼뜨려지고 있는 FUD의 유형이기 때문에 설명할 필요를 느낀다.
FUD를 이겨내는 안목
이해를 위해 독자들이 프로그래머를 선발하는 역할을 맡았다고 하자. 한 사람은 말하는 됨됨이가 훌륭하고, 기술적으로 해박하다고 느껴진다. 하지만 어떠한 자격증도 갖고 있지 않다. 반면, 다른 한 사람은 기술적인 질문을 했을 때 당황하는 기색을 보이며 제대로 답변을 못하는데 여러 개의 자격증을 갖고 있다. 여러분은 어떤 사람이 적임자라고 보이는가?
표준이라는 말은 권위를 내포하고 있다. 하지만 표준의 용도는 단지 권위만은 아니다. 제품에 있어서 표준의 필요성은 산업 전반의 공정한 경쟁을 위한 것이고, 사용자에게 제품 선택의 폭을 넓혀주는 데 있다. 자바 표준의 경우도 다르지 않다. J2EE의 경우는 오래도록 마이크로소프트의 독점적 기술 환경을 공격했다.
자바 표준을 결정하는 JCP(Java Community Process)는 기술 표준 역할을 하는 스펙(specification)을 결정한다. 스펙의 후보가 되는 JSR(Java Specification Request)이 제출되면 JCP 구성원들에 의해 조정되고 투표에 부쳐져 스펙이 결정된다. 상당히 합리적인 결정방식임에는 틀림없다.
그림2. JCP의 JSR 목록
완벽한 것은 없고, 시간이 흐르면 변화의 대상이 된다. 주로 J2EE 스펙을 구현한 제품으로 이익을 실현하는 업체들이 JCP에 행사하는 영향력이 커졌다. 결국, 특정 업체들이 유리한 방향으로 스펙이 결정되기 시작했다. 독점을 피하기는 했지만, 기술적으로 결함이 있는 스펙이 만들어지기 시작했다.
대표적인 실패 사례로 이야기되고 있는 EJB 엔터티빈(Entity Bean) 모델은 하이버네이트(Hibernate)와 같은 오픈소스 제품 출현의 직접적인 계기가 되고 있다. 스프링(Spring)의 경우는 J2EE 스펙의 다각적인 결함을 보완하는 노하우를 집결한 프레임워크로 등장했다. 스프링의 개발 철학을 담은 Expert One-on-One J2EE Development without EJB는 제목부터가 상당히 도전적이다.
오래도록 J2EE의 심장으로 여겨졌던 EJB를 제거한 J2EE 설계와 구현을 말하고 있다. J2EE산업계를 좌우하는 주요 업체들 주도로 결정된 JCP(Java Community Process)의 총아를 부정하는 표현이다. 저서에 담긴 치밀한 내용이 아니었다면 마녀사냥을 당할만한 도전이다. 다른 의도로 EJB를 음해한 것이 아니라 기술적인 문제점을 지적하고 그 해결책을 제시했다. 그 해결책이라는 것은 종속성을 최대한 제거하고 어떠한 제품이나 컴포넌트와도 유연하게 함께 작동하게 하는 설계 원칙이다. 스프링을 채택하면 어떠한 제품을 사용해도 문제가 없다. 특정 업체의 제품만 골라서 시스템을 구성할 필요가 없어진다.
상용 제품을 판매하는 업체 입장에서는 스프링을 인정하면, 과도한(?) 유연성 탓에 이른바 고객 록인(lock-in)이라고 하는 매력적인 무기를 포기해야 하는 것이다. 스프링의 등장은 JCP의 존재 이유와 맥을 같이 한다. 고객에게 훨씬 폭넓은 선택의 자유를 준다. 하지만 기존 업체들에게는 기득권 상실로 비춰질 수 있는 대목이다.
FUD를 행하는 자, 다른 길을 택하는 자
스프링이 널리 인기를 끌어 개발자 커뮤니티 사이에서 표준 기술-이러한 경우를 디팩토(de facto) 표준이라고 한다-처럼 퍼져나갔다. JCP는 새로운 EJB 스펙인 3.0을 내놓으면서 대대적인 스프링 공격에 들어간다. 아직 별반 기술적으로 우위를 확보하기 힘든 후발주자인 탓에 ‘표준이 아니다’라는 식의 진부한 FUD를 활용하는 경우가 많았다. 하지만 표준이 아니기 때문에 제품 교체가 어려운가? 전혀 반대다. 표준을 준수했다는 업체의 제품을 선택했을 때 오히려 제품 교체의 어려움을 맛보게 된다.
더군다나 하이버네이트가 표준이 아니라는 주장은 도무지 이해가 가지 않는 황당한 발언이다. 썬(Sun)의 Java Persistence API FAQ 페이지에 따르면 Java Persistence API(이하 JPA)를 하이버네이트, 탑링크(TopLink) 및 JDO와 같은 우수한 영속성 관련 기술의 표준화로 설명하고 있다. 하이버네이트는 JPA의 모태가 되는 많은 아이디어를 제공했음은 물론이고, JPA 표준 구현 제품이기도 하다.
그렇다고, JCP를 구성하는 업체들이 FUD를 남발하는 것은 아니다. JCP는 업체가 아닌 개인의 참여를 강화하는 방향을 변모하며 포용력을 키우는 노력을 하고 있다.
EJB의 최대 수혜자 중 하나인 BEA와 같은 업체는 스프링 개발진영과 긴밀하게 협업하여 최상의 산출물을 만들어내려고 노력중이다. 더군다나 이들의 노력의 일환인 피치포크(pitchfork) 프로젝트는 JCP 표준을 준수하는 제품이 될 가능성이 높다.
그림 3. 피치포크 프로젝트에 대한 미디어 보도 내용
선도하는 업체의 입장에서는 경쟁력 있는 기술이 등장하면 적극적으로 수용하는 자세를 보인다. BEA의 경우와 마찬가지로 오라클과 같은 업체도 표준 운운하는 진부한 태도를 보일 리가 만무하다. 그들 스프링이 오픈소스라는 이점을 십분 활용하여 역시 자사의 제품에 포함시켜 시너지를 창출하고 있다.
FUD의 미래
지금까지 대표적인 FUD 사례를 설명했다. 특정 발언만 놓고서 FUD인지 아닌지를 판단하기는 상당히 힘들다. FUD의 등장 배경이 되는 역학 구도나 관련 기술을 통찰력 있게 바라보지 않으면 알 수 없다. 분명한 것은 FUD는 바람직하지 않다는 것이다. 자칫 긴 논쟁으로 이어지면 소모적인 사회적 비용을 낳을 수 있다. 아쉽게도 역사를 통해 예상해 보자면 앞으로도 FUD는 계속될 것이란 점이다.
얼마 전 버스를 타려고 줄을 서 있을 때의 일이다. 서너 명이 줄을 서 있는데 아주머니가 눈치를 살피더니 자연스럽게 줄 앞에서 버스를 탔다. 나서서 그 아주머니를 호되게 비난하고 싶을 정도로 못마땅한 기분이 잠시 들었다. 하지만 그 아주머니도 나와 같이 살고 있는 사회 구성원이다. 인정하고 싶지 않아도 현실이 그렇다. 그렇기에 언젠가 아주머니가 스스로 변화하기를 기대해본다.
맺음말
이번 글에서는 경쟁 기술에 대한 비난으로 이익을 취하려는 FUD에 대해 이야기했다. 소수이기는 해도 지속적으로 FUD를 구사하는 진영이 있어왔다. 기술에 대한 깊이 있는 이해가 없다면 FUD에 쉽게 현혹될 수 있다. 당장 뚜렷한 대응책이 없지만, 합리적인 상식에 기초하여 차분히 대처한다면 큰 문제는 되지 않을 것이다. FUD는 태생적으로 깊이 있는 논리를 갖고 있기 힘들기 때문이다. 다음 호에는 새로운 기술을 어떠한 태도로 받아들여야 하는가를 살펴보도록 한다.
참고 자료
- http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt
- ZDNet Korea
- Expert One-on-One J2EE Design and Development (Programmer to Programmer), Wrox 2002
- Expert One-on-One J2EE Development without EJB, Wrox 2004
- Java Persistence API FAQ
 [지난 Special Issue 보기]
|
안영회 
