요구사항 엔지니어링에서 역설적인 격언이 하나 있습니다. "고객의 말에 항상 귀를 기울이되 고객을 믿지 말라"는 원칙입니다. 고객은 자신이 무엇을 원하는지 정확히 모른다는 말과도 일맥상통합니다.

유저 인터페이스와 상호작용(interaction)에 대한 전문가인 Alan Copper는 Channel 9과의 인터뷰에서 이런 표현을 쓰더군요.

"사용자(혹은 고객)은 5살짜리 유치원 아이와 같다. 유치원 선생님은 항상 아이들의 말에 귀 기울이고, 아이들에게 이로운 일을 해주고자 한다. 하지만 아이들이 사탕 주세요 과자 주세요 한다고 해서 절대 이 말을 들어주지는 않는다. 다만 이를 통해 아이들이 원하는 바를 파악한다. 바로 배가 고프다는 사실이다."

요구사항을 뽑아내는 것도 같은 과정이라고 얘기합니다. 사용자의 말에 귀 기울이고, 무엇을 원하는지 들어보지만 이 과정은 매우 비판적이어야 한다는 것입니다. 사용자가 시킨 대로 그대로 구현해가면 오히려 실망하는 경우가 많다는 것이죠.

Alan Copper의 인터뷰는 시간 나면 한 번 보시기 바랍니다. 소프트웨어 개발 과정에 있어서 인터액션 디자이너의 중요성이나, 현재 죽음의 행진(death march)라 불리는 소프트웨어 프로젝트 진행 현실에 대해 이런 저런 이야기를 합니다.

기업이 어떤 제품에 가격을 매기면, 소비자는 구매 판단을 하게 됩니다. 이때 구매자가 느끼는 효용이 물건이 가격보다 높으면 물건을 구매하게 되고, 그렇지 않으면 보류하게 됩니다. 가격을 하나로 통일했을 경우에 문제점은 가격이 조금만 더 낮았다면 제품을 구입했을 많은 고객을 놓치는 데 있습니다. 그렇다고 가격을 낮추면, 높은 가격을 주고라도 제품을 구입했을 고객들에게는 싼 값에 판 셈이 되는 문제가 있습니다. 이윤을 극대화하는 가격을 찾는 게 기업 전략에서 가장 어려운 부분 중에 하나였죠.

가격 차별화(price discrimination)은 기업의 이익을 극대화하는 매우 효과적인 방법입니다. 하나의 물건에 서로 가격을 붙여서 고객들에게 최대한의 이윤을 취하는 전략입니다. 대형 마트에서 쿠폰을 발행하는 것도 가격 차별화의 하나입니다. 쿠폰이 없이도 기꺼이 상품을 구매할 소비자들에게는 제값을 받고 팔고, 가격에 민감한 일부 고객들에게는 쿠폰이라는 옵션으로 구매를 유도하는 거죠. 즉 이들은 서로 다른 가격에 같은 물건을 구입하게 되는 것이죠.

또 다른 예제로 미국에서 판매하는 교과서도 가격 차별화 정책을 폅니다. 상대적으로 구매력이 낮은 아시아 지역에는 싼 가격에 책을 내놓고, 구매력이 높은 미국에는 비싼 가격으로 파는 것이죠. 물론 가격 차별화 전략이 가능 하려면, 이 두 구매층 간에는 경계선이 분명해야 합니다. 아시아에서 책을 산 다음에 미국에 가서 대량으로 판매하면 이런 정책이 의미가 없어지기 때문이죠.

소프트웨어 기업도 이런 가격 차별화 정책을 극단적으로 구사해서 독특한 성장 전략을 구사한 곳이 있습니다. 대표적인 곳이 MySQL입니다. MySQL은 일반 공개 배포 버전인 커뮤니티 버전과, 기업용 버전인 엔터프라이즈 버전이 있습니다. 물론 엔터프라이즈 버전이 서비스 측면에서 여러 가지 부가 요소가 있지만, 실제로는 같은 제품을 서로 다른 가격으로 팔고 있는 셈입니다.

이런 가격 차별화 정책은 밑바탕에는 소프트웨어 이중 라이센스(dual license) 모델이 있습니다. 같은 제품에 서로 다른 두 개의 라이센스를 걸어서, 사업 기회를 만드는 전략입니다. MySQL을 다시 예로 들면, 커뮤니티 버전은 일반 사용자들에게 무료로 배포하고 이에 대한 대가로 제품에 대한 피드백과 마케팅 효과, 테스트 등의 간접적인 이득을 얻습니다. 반대로 엔터프라이즈 버전은 상업 라이센스를 적용해 가격을 책정합니다.

앞서 가격 차별화 정책은 반드시 두 구매층이 물리적 혹은 제도적으로 분리되어 있어야 한다고 말씀 드렸는데, MySQL의 가격 차별화 정책은 소프트웨어 이중 라이센스가 이를 가능케 합니다. 커뮤니티 버전의 라이센스는 GPL로 되어 있어서, MySQL을 제품에 탑재(embedding)하고자 하는 고객은 반드시 사유 라이센스를 구매해야 하는 모델이기 때문입니다. 즉 일반 사용자와 임베딩 사용자를 별도로 고객층으로 분리하고, 완전히 다른 가격 정책을 취한 것이죠.

비슷한 방식으로 성공한 기업은 버클리 DB(Berkeley DB)로 유명한 Sleepycat이 있습니다. 임베딩 DB라는 측면에서는 MySQL과 유사한 전략을 취했고요. Mozilla나 QT도 같은 맥락에서 파악할 수 있고요. 이중 라이센스를 이용한 가격 차별화 정책은 앞으로의 소프트웨어 회사가 취할 수 있는 유용한 전략이 아닐까 합니다.

제목을 다소 선정적으로 잡아봤습니다만 웹 표준화에 있어서 W3C의 역할을 폄하하려는 것은 아닙니다. 다만 W3C를 통합 웹 표준 제정의 문제점을 지적하려 합니다.

W3C 표준과 브라우저.

W3C는 웹 관련해서 수많은 표준을 제정하고 있지만 그 중에서 사람들에게 가장 익숙한 표준은 HTML, XHTML, DOM, CSS일 것입니다. 근데 이러한 표준을 구현했다는 대표 브라우저 IE, Firefox, Safari, Opera에서 웹 프로그래밍을 해보면 같은 표준인데도 미묘하게 구현이 다르고, 일부가 누락된 문제 때문에 많은 불편을 겪게 됩니다. 웹 표준 하에서라면 당연히 되어야 할 ‘크로스 브라우저’ 지원이라는 게 고급 프로그래밍 기술이 되어버린 거죠.

지금까지는 비난의 화살이 주로 브라우저 업체들에 맞춰졌던 것이 사실입니다. 표준이 이런데 왜 제대로 다 구현을 안 했느냐는 거죠. 하지만 이런 현실을 놓고 보면 표준화 기구인 W3C의 역할이 제한적임을 알 수 있습니다. 브라우저 업체들이 W3C에 참여해서 표준을 제정하지만, 해당 표준 제정에 같이 참여한 다른 브라우저 업체들에게 강제할 수 없다는 거죠.

사실 어떤 표준화 회의던지, 제품 구현에 대한 생각이 전혀 없이 표준화 회의에 가서 회의부터 한 다음에, 표준이 완성되고 제품 구현에 들어가는 회사는 하나도 없을 것입니다. 표준 제정 이전에 이미 표준안에 대한 생각을 가지고 있고 제품을 시작한 후에 최대한 자기가 생각한 안을 표준에 밀어 넣으려고 싸움을 벌이는 것이 일련의 절차죠. 이 과정에서 각 업체들이 생각했던 초안에 상당한 수정이 생기고, 추가 혹은 누락되는 경우도 생깁니다.

현재 브라우저 간의 호환성 문제를 보면 이런 상황을 잘 알 수 있습니다. 이미 제품은 어느 정도 완성이 된 상태이므로, 표준화 회의에서 나온 내용 중에 수정이나 추가 구현이 힘든 부분은 무시하고 원래 안대로 제품을 출시해버리는 거죠. 당연히 큰 그림에서는 해당 표준을 구현했다고 할 수 있지만, 미묘한 부분들이 서로 맞지 않아 불편함을 겪는 상황이 오게 됩니다.

이런 상황 때문에 DOM 레벨 2 같은 표준은 표준을 다시 여러 개의 작은 표준으로 쪼개고 일부만 구현할 수 있게 했지만, 근본적으로 서로 다른 꿈을 꾸고 있는 브라우저 업체들이 이마저도 일부를 빼먹거나 자기 입맛대로 출시하는 상황은 여전히 반복되고 있습니다.

썬마이크로시스템즈의 JCP 같은 표준화 기구와 비교해 보면, W3C는 표준의 엄격한 준수를 위한 2가지 절차가 빠져있습니다.

1) 참조 구현(Reference Implementation)
2) 테스트킷(Test Kit)

레퍼런스 구현은 해당 표준은 제품으로 구현해 본 시제품을 말합니다. 표준안을 만들고 나서 실제 벤더들이 참조할 수 있도록 시제품을 만들어 보지 않으면 표준 자체가 제대로 된 것인지 검증할 방법이 없는 것이죠. 사용성(usability)이 떨어지거나, 각 구현들이 입맛대로 수정할 수 밖에 없는 상황이 오게 됩니다.

참조 구현보다 더 중요한 것은 테스트킷의 존재와 인증 절차입니다. 표준을 정의했으면 해당 표준을 만족시켰는지 여부를 쉽게 판단할 수 있는 테스트킷이 필요하고, 표준을 구현한 벤더들의 제품은 이 테스트킷을 통과해야만 표준을 구현했다고 공식적으로 말할 수 있는 것입니다. 이런 절차가 있었다면 표준 일부를 빼먹거나 각 벤더들의 필요에 따라 선택적으로 구현하고는, 표준을 준수했다고 말하지는 못하겠죠.

W3C의 구성이나 표준 제정 절차에 대해서 잘 알지는 못하지만, 이런 요소들이 보강될 수 있었다면 조금 더 강력한 표준화 기구가 될 수 있었겠죠. 하지만 지금의 상황을 보면, 이렇게 까지 표준을 강제했다면 과연 웹 표준화 기구라는 게 존재할 수나 있었을까라는 의문이 드는 것도 사실입니다. 표준 구현에 있어서 비교적 자유로운 HTML이 XHTML보다 훨씬 큰 성공을 거둔 부분만 봐도 알 수가 있습니다.

하지만 초기의 자유스러움이 많은 참여를 이끌어내 웹을 발전시켰다면, 강력한 표준 규제로 상생의 길을 여는 것이 현재의 요구 사항이 아닐까 합니다.