기술 마케팅의 허와 실

김도형 dynaxis@alticast.com 양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다. 2007년 10월 16일

들어가면서

1990년대 후반은 웹과 자바(Java) 등 각종 기술의 등장과 발전으로 떠들썩했던 때였다. 개인적으로 1995년 후반은 자바를 처음 접하고 한창 활발히 기고할 때였는데, 당시 해외 자바 관련 사이트에 가면 하루가 심심치 않았던 기억이 있다. 각종 백서(whitepaper)에, 다양한 분야의 새 API 규격, 새 소프트웨어 릴리스까지 그저 읽고 시도해 보는 것만으로도 즐거웠다. 당시는 어떤 기술이 어떤 문제를 해결할 수 있는지 보다 그저 기술 자체를 아이콘화하고 마케팅 하던 때가 아니었나 한다. 그런 시류 때문인지 당시는 프로그래머로서 기본 소양이나 자신 앞에 놓인 문제를 차치하고 자바, XML처럼 유행하는 기술을 하나라도 더 익히는 것이 미덕처럼 받아들여졌다.
하지만 프로그래밍을 취미로만 할 수야 있겠는가? 결국 할리우드 블록버스터 영화 보듯 앞뒤 안 가리고 기술에 열광하던 분위기도 종말을 고한 것 같다. 대형 서점의 외서 코너에서 소프트웨어 분야의 기본에 해당하는 책들이 자취를 감춘 지도 오래됐지만 그것 못지 않게 각종 회사나 표준화 기관이 마케팅 하던 각종 기술에 대한 책의 인기가 상대적으로 시들해졌다. 그 대신 소프트웨어 공학이나 개발 방법론, 프로젝트 관리 방법 등을 다룬 원론적인 책이나 고전에 해당하는 책으로 관심이 옮겨간 듯 하다.
그럼 이제 눈에 덮인 비늘을 떨고 우리는 기술을 도구로서 냉철하게 바라보고 있는 걸까? 역사는 반복된다는 말처럼 우리는 여전히 기술 마케팅에 속고 우상을 만들고 있다. 이번에는 개인적으로 경험했던 몇 가지 사례를 나눠볼까 한다. 물론 이 과정에서 특정 기술을 다소 희화화하기도 하겠지만 그렇다고 덮어 놓고 기분 나빠하지는 말자. 단지 기술을 원래 가치와 크기로 바라보고 판단하고 활용하자는 것뿐이다.

위로

핵심을 흐리는 마케팅 구호

마케팅을 위해서는 다소 자극적인 문구가 필요하다. 이 때문에 틀린 건 아니지만 사람들에게 다소 다른 뉘앙스를 주는 표현을 쓰기도 한다. 문제는 기술적으로 정확한 판단을 내리기 위한 자료가 마케팅적으로 뒤틀어지기 시작하면 뜻 밖에 많은 사람(심지어 해당 분야 종사자들까지도)이 오판하게 된다는 점이다. 당시 소프트웨어 기술로는 드물게 대대적인 마케팅을 펼친 자바를 차치하더라도 생각 외로 소프트웨어 제품 판촉에는 마케팅 부서의 입김이 있다.
일례로 마이크로소프트의 C#의 unsafe 코드 개념에 얽힌 일화가 있다. C#에서는 unsafe로 선언된 코드 내에서는 C처럼 포인터를 사용할 수 있고 당연하지만 잘못 사용하면 C 프로그램과 마찬가지 문제가 발생한다(하지만 unsafe 개념은 자바의 JNI에 비해 많은 장점이 있다). 이 때문에 개발팀은 “안전하지 않다”라는 의미를 명확하게 전달하기 위해 unsafe라는 용어를 쓰기 원했지만, 마케팅 담당자들은 제품 이미지에 몹시 부정적인 표현 대신 다른 표현을 쓰면 안 되냐고 했단다(http://www.artima.com/intv/choicesP.html). C# 팀은 애매한 용어를 써서 프로그래머를 오도하기보다는 명확한 의미를 전달하는 쪽을 택했다. 물론 “버그 패치”를 “서비스 팩”으로 부르는 회사이니 항상 이렇다는 확신은 안 가지만 말이다.
다른 예로 그 성공에 마케팅의 뒷받침이 절대적이었던 자바는 초기부터 몇몇 모호하지만 자극적인 표현으로 센세이션을 일으키기도 했다. 자바 백서를 본 적이 있는지 모르겠다(http://java.sun.com/docs/white/langenv/Intro.doc2.html). 현재 자바 사이트에 올라와 있는 것은 초기 내용과 별 차이가 없는데, 그 중 특기할 만한 것 몇 가지를 꼽으면 다음과 같다.

• 자바에는 포인터가 없다.
• 자바는 고성능이다.
• 자바는 해석(interpret)되는 언어라 개발 주기가 빨라진다.
• 자바는 멀티쓰레드를 지원한다.

개인적으로는 자바로 실제 프로그래밍을 해 보기 전 “자바에 포인터가 없다”라는 말을 처음 접하고는 소프트웨어 전공자이면서도 “포인터가 없다면 동적 메모리 할당이 없는 것인데, 어떻게 프로그래밍을 하지?”라고 생각을 했다. 그뿐 아니라 당시 뉴스그룹에서 포인터가 없다는 말을 놓고 말도 안 되는 추정을 해 가며 몇몇 사람과 설전을 벌인 적도 있었다. 백서를 자세히 읽어 보면 사실 그리 틀린 말들은 아니지만 자바에는 C 스타일의 포인터가 없을 뿐 실제로는 포인터가 있는 것인데도 말이다.
다른 문구도 마찬가지다. 바이트코드를 실행 전에 정적 분석을 통한 검증으로 실행 중에 검사할 내용을 줄이는 등 해석기로 실행하는 언어치고는 성능을 고려한 설계가 있기는 하지만 사실 당시 자바는 해석기 부분뿐 아니라 API 구현까지 성능 면에서는 악몽에 가까웠다. 또 해석되는 언어라 개발 주기가 빠르다는 말은 언뜻 스크립트 언어나 스몰토크(Smalltalk)처럼 별도로 컴파일 과정이 필요 없는 환경을 연상하게 하지만, 사실은 링크를 뒤로 미룬 부분을 이야기한 것이다. 백서의 해당 부분에서는 C/C++처럼 고친 소스 파일이 의도하지 않게 컴파일 되지 않아 생기는 문제도 언급하고 있지만 사실 자바도 컴파일을 하다 보니 원하는 파일이 컴파일 되지 않아 고생하는 경우가 허다하다.
또 하나의 압권은 마지막 멀티쓰레드 지원 쪽인데 당시 멀게만 느껴지던 멀티쓰레드 프로그래밍이 자바로 인해 일반화된 것은 사실이지만, 사실 자바의 멀티쓰레드 지원은 백서와 달리 그다지 고수준이지도 않고, 언어 차원의 지원이 있는 것도 아니다. 사견이지만 자바는 준비가 되지 못한 프로그래머를 허술한 무기를 들려 멀티쓰레드라는 사악한 용의 소굴로 등을 떠밀었을 뿐이다.

위로

얼핏 그럴싸해 보이지만……

소프트웨어 업계에서 오래 일해 보면 고객의 요구사항을 귀담아 들어야 하지만 액면 그래도 받아들여서는 안 된다는 진리를 깨치게 된다. 고객은 뭐가 불편하다거나 추상적으로 어떤 걸 원하는 지는 이야기할 수 있어도, 자신이 정확히 어떤 것을 필요로 하는지 모르거나 제대로 표현하지 못하는 경우가 허다하기 때문이다. 반대로 각종 기술의 마케팅에 있어서도 얼핏 그럴싸해 보이지만 따져보면 뭔가 이상한 경우가 많다.

웹 기술을 쓰면 콘텐츠까지 생긴다?

유료 디지털 TV에 가입한 사람이 있는지 모르겠다. 위성 방송이나 디지털 케이블(월 이용료 1만 원 이하의 일반 유선 방송이나 아날로그 케이블을 말하는 게 아니다) 서비스를 신청하면 셋톱박스라는 수신 장치가 따라오는데 현재와 다음 프로그램 정보를 보여주기도 하고 게임이나 증권, 은행 업무를 볼 수도 있다. 셋톱박스에 자바가 들어가 있기에 가능한 일이다. 흔히 양방향 TV라고 부르는 이러한 일을 가능하게 하기 위해 2000년대 초에 HTML과 자바 중 어느 것이 나은가에 대한 설전이 있었다.
HTML과 자바스크립트는 주로 마이크로소프트 쪽에서 주창했던 바고 자바는 당연하지만 썬이 주창했었다. 이 때 HTML 쪽의 주장은 HTML을 사용하면 인터넷의 콘텐츠를 그대로 쓸 수 있고, CSS를 사용하면 같은 HTML 콘텐츠를 스타일만 다르게 만들어서 PC와 TV 모두에서 쓸 수 있다는 식이었다. 그럴싸하게 들리지만 잘 가려 들어야 하는 주장이다.
일반적인 웹 사이트는 HTML만으로 만들지 않는다. 최소한 플래시를 사용하고 다른 플러그인을 쓰기도 한다. 최근 플래시가 TV나 휴대전화에도 들어간다고 하지만 성능이 떨어지는 PC에서조차 매끄럽지 못하게 돌아가는 콘텐츠가 있는 마당에 TV, 휴대전화에서 성능, 메모리 문제를 걱정하지 않을 수 없다.
또 브라우저만 달라져도 홍역을 치르는 마당에 표준 잘 따르는 HTML이나 받아 처리할 수 있는 TV나 휴대전화의 브라우저가 그대로 소화할 만한 HTML 페이지가 얼마나 되겠는가? 재사용은 물 건너간다. 아마도 사이트 뒤 단의 데이터베이스 정도를 공유할 수 있을 것이다. 그뿐만이 아니다. 입력 장치가 다르고 화면 해상도가 다르면 콘텐츠도 바뀌어야 한다. 그리고 CSS만 바꿔서 입력 장치가 다르고 화면 크기나 사용 행태가 다른 TV같은 장치에서 매끄럽게 돌아가게 콘텐츠를 만들 수 있다고 치자. 거기에 들어가는 노력이 결코 가볍다고는 생각하지 않는다. 결국 HTML을 사용해 얻을 수 있는 장점은 비교적 풍부한 웹 관련 인력과 도구를 이용해 상대적으로 단순한 콘텐츠를 빨리 만들고 유지, 보수하는 데 있다고 하겠다. 분명한 장점은 있지만 막연한 “재사용” 등의 얼핏 그럴 싸해 보이는 문구로 사용자를 오도해서는 안 될 것이다.
다른 예로 플래시가 있다. 최근 시장이 불붙었지만 플래시는 1990년대 말부터 휴대전화나 TV 쪽으로 진출을 모색해 왔다. 이 경우는 어도비 측의 계산된 오도라기보다는 고객 측에서의 막연한 오해가 있다고 봐야 하는데 대략 다음 같은 것들이다.

• 기존 인터넷의 풍부한 플래시 콘텐츠를 재활용하고 싶다.
• 뭔가 화려한 UI나 화면을 얻고 싶다.

HTML과 비슷한 이유로 단순히 인터넷의 플래시 콘텐츠를 재활용하기는 어렵다. 화면 크기, 입력 장치 등의 차이, 성능, 메모리 등 차이 말이다. 또 막상 인터넷을 뒤져보면 정확히 웹 사이트나 데스크톱 환경에서 띄어내면 별로 유용하지 않은 콘텐츠가 대부분이다. 사이트의 메뉴, 광고가 대부분이고, 그리고 일부 애니메이션이나 게임은 상업적인 이용이 원활한 선은 절대로 아니다. 직접 뒤져 보면 알 수 있다. 공짜는 없는 법이다.
또 뭔가 화려한 UI나 화면을 얻고 싶다고들 하는데 플래시는 원래 하드웨어의 한계를 뛰어넘게 해 주는 마법지팡이는 아니다. 결론적으로 플래시도 저작도구, 관련 써드파티 제품, 비교적 풍부한 저작 가능 인력 등이 장점이라고 해야 할 것이다. 물론 기존 TV, 휴대전화 분야의 다른 솔루션이 제시하지 못했던 해법을 제시하는 것도 장점이라고 해야 하겠지만 말이다.

위로

장치의 한계를 넘어선 천하통일?

요즘 풀 브라우징(full browsing)에 대한 관심이 뜨겁다. 품을 들여 휴대전화에 맞춰 놓은 사이트가 아니라 내가 원하는 사이트 어디에나 접속해 살펴 볼 수 있다면 편리한 것은 사실이다. 문제는 풀 브라우징으로 PC를 위해 맞춰 놓은 웹 사이트를 제대로 볼 수 있다고 생각하는 것이다. 이런 논리는 더 이상 휴대전화, TV에 특화된 콘텐츠를 만들 필요가 없다는 논리적 비약을 만들어내기도 한다.
하지만 따져보자. 당장 화면 크기나 플래시 같은 필수 플러그인 같은 것만 따져도 이는 불가능에 가깝다. 또, 최근 애플의 아이폰처럼 비교적 큰 화면에 확대, 축소가 가능한 인터페이스, 데스크톱에 가까운 OS와 브라우저의 탑재로 더 원활한 브라우징이 가능하기도 했지만, 기왕이면 내 단말 화면 크기와 입력 장치 등에 맞게 사이트가 최적화되어 있는 편이 편하지 않을까? 풀 브라우징은 일반 웹 사이트에 대한 접근성을 높인다는 의미에서 중요하지만 휴대전화나 TV에 특화된 서비스의 종말을 알리는 궁극의 해결책은 아니다.

안 친절한 ‘표준’ 씨

그럼 업계 내에서만 온갖 모호한 뒤틀기가 성행하고 있을까? 의도했던 안 했던 표준화된 기술도 마찬가지다. 그리고 표준이라는 점을 내세워 마케팅적인 뒤틀기가 성행한다. 하지만 소프트웨어 표준이 달고 다니는 문제는 상당히 많다. 표준치고 그럴싸한 백서 하나 없는 경우는 드문데 그 내용을 읽어보면 기존 기술의 온갖 장점만 모아 다 지금까지 업계의 고민을 풀어 놓은 것 같다. 하지만 SVG(Scalable Vector Graphics)로 플래시를 대체하자고 앞장 서온 어도비가 결국 매크로미디어를 인수하고서는 SVG 플레이어를 더 이상 갱신하지 않는 것처럼 표준 소프트웨어 기술이 생각했던 것 같은 효과를 발휘하지 못하는 경우가 허다하다. 일반적으로 소프트웨어 표준이 뭐가 문제인지 살펴 보자.

• 항상 당장 필요한 것보다 더 복잡하다. 모여 앉은 사람들이 걱정하는 내용을 다 주워 담다 보면 아무리 조심해도 필요한 것보다 커진다. 통상 너무 많은 것을 한꺼번에 해결하는 경우 잘못된 해법을 선택하는 경우가 많아진다. 이런 잘못된 해법은 호환성 때문에 표준이 판 갈이되어도 남아 있어야 하는 좀비가 되는 경우가 수두룩하다.
• 요구 사항은 다 해결한 듯하지만 실제 써 보면 뭔가 불편하다. 요즘 소프트웨어 표준은 제정 과정에서 명세 자체를 만드는 데 치우쳐 구현이나 애플리케이션에 대한 실증이 부족해 그런지 뭔가 불편하고 부족한 경우가 많다. 해결하고자 하는 문제에 대한 깊은 이해를 가지고 집중해야 겨우 쓸만한 표준이 나오는데 실제 표준화 과정은 그렇지 않은 경우가 많다.
• 현실과 다른 요구 사항: 표준을 제정하는 사람들은 실제 해당 기술의 사용자가 아닌 경우가 많다. 그러다 보니 머리 속에서 생각해 낸 가상적인 요구 사항이 대폭 반영되는 경우가 많다.
• 뭔가 짜깁기해 놓은 듯하다: 생각 외로 강력한 리더십 없이는 기술에 통일성이 결여될 가능성이 높다.

“위원회 증후군” 때문일까? 그나마 JCP(Java Community Process)를 통해 JSR(Java Specification Request)을 심사해 스펙 리드(spec lead)의 강력한 권한을 통해 소수의 전문가가 특허 등의 복잡한 이슈를 배제하고 작업하는 경우는 많이 나은 편이다. 하지만 개인적으로는 과거의 CORBA, MPEG 규격이나 W3C 표준들은 앞서 언급한 문제점을 보여주는 예를 너무나 많이 가지고 있다고 생각한다. 지난 XML 관련 글에서도 언급한 적 있지만 W3C가 만든 그 많은 규격 중 활발히 쓰는 게 몇 개나 되는가?
2002년에 쓰여진 “SVG On the Rise”라는 글을 읽어 보면 나름 SVG의 장점과 밝은 미래를 이야기하고 있다. 하지만 지금 현재 SVG는 그다지 성공적이지는 못한 것 같다. 유럽에서는 휴대전화에 SVG가 들어가는 경우가 꽤 있고 리눅스 쪽에서도 데스크톱 아이콘이나 테마에 SVG를 쓴다고는 하지만 그 분야에서도 SVG 사용은 꽤 제한적이다.
물론 표준 기술, 특히 W3C처럼 표준에 유료 특허가 파고드는 것을 철저하게 차단하는 경우에는 상당한 장점이 있다. 하지만 표준 기술이 문제를 해결하는 궁극의 솔루션이 아님에도 그렇게 광고되고 있는 경우는 무척 많다.

위로

업계의 지지를 받는 표준으로 제정됐다고 만사 해결?

보통 표준 기술의 장점에 대한 글에는 업계의 지지를 받는 표준이라는 자체를 장점으로 이야기하는 경우가 많다. 하지만, 표준화 기구에서 만든 표준이라도 그 구성원인 회사들조차 적극 구현하고 지지하지 않는 경우가 의외로 많다(구체적인 예도 있지만 민감한 사안이라 함구하련다). 자기가 만들었는데도 말이다. 또 W3C 같은 특별한 경우를 제외하면 표준 기술도 특허 이슈가 있고 오히려 특정 회사 기술을 적절한 돈 내고 쓰는 것이 나을 때가 많다.

표준 기술은 경쟁을 촉발하고 비용을 절감한다?

보통 표준 기술은 솔루션 업체를 많이 내게 되고 그 때문에 경쟁을 촉발해 솔루션 가격을 낮춘다고 하는 논리를 내세워 독점 기술에서 표준 기술로 갈아탈 것을 말하는 경우가 많다. 물론 어떤 경우는 맞지만 소프트웨어 기술의 경우 꼭 그렇지 않은 경우가 많다.
표준이 나오면 너도 나도 구현할 것 같지만 그 복잡도나 낮은 시장 요구로 솔루션 업체가 몇 없는 경우도 허다하다. A/V 코덱을 제외한 최근 MPEG 표준들은 실제 상용 구현이 드문 표준이 허다하다. W3C도 마찬가지다. 아직 SVG 1.1 완전(full) 규격에 맞는 구현이 사실상 없다는 것을 아는지? 이런 의미에서 JCP에서 그나마 규격 완료 조건으로 참조 구현(reference implementation)을 만들도록 강제하고 있는 것은 JCP를 통한 규격이 그나마 나은 이유가 된다.

위로

마치면서

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

막상 글을 적다 보니 이해 관계가 걸려 구체적인 사례 쓰기가 어려운 부분도 많은 것 같다. 핵심은 다음과 같다.

• 기술에 대한 주장 하나하나를 곱씹어 보라.
• 정말 그런지 직접 사례를 찾아 보라.

그럴싸해 보이지만 위와 같이 따져보면 금방 허점을 발견하게 되는 경우가 얼마든지 있다.

위로

[지난 developerWorks Column 보기]