포탈을 신문법 테두리로 넣는 것은 가능한가?

포탈의 정의는 Google의 출현으로 더이상 의미가 없지만, 일반적으로 naver.com, daum.net, empas.com, kr.yahoo.com 등 생김새가 포탈같은 경우에 포탈이라고 칭합니다. 원래는 대규모 트래픽을 유발시키는 일종의 허브같은 웹사이트를 말하는 것이었지요.

포탈사이트에서 기자를 편집해서 보여준다고 해서 신문법에 적용을 받게 하기 위한 법안이 제출됨으로 인해서 기자, 포탈 담당자, 교수, 시민단체 등의 발표가 상당히 많아졌습니다. 가장 중요한 부분을 “포탈도 편집을 하지 않느냐?” 하는 것이고, 신문법의 적용을 받는 가장 중요한 부분이 편집권이라고 주장합니다.

법이라는 것이 일반화되지 않으면 여럿이 피곤해 지는 법입니다. 만약 어떤 회사가 미니 포탈을 만들었습니다. 규모도 매우 작고 방문자는 하루 500명 선밖에 안됩니다. 그 곳에서는 신문들을 검토해서 링크를 걸어놓습니다. 그 링크는 자사 사이트로 가지 않고 신문사 사이트로 이동됩니다. 이것이 편집권에 해당할까요?

이미 제목을 쓰고, 링크를 걸어놓는 것은 저작권법 위배가 되지 않는다고 했습니다. 그러면, 이것도 편집이 아닐까요? 자사 사이트에서 보여지는 것과 타사 사이트로 링크로 이동을 시키는 것의 차이가 편집권이냐 아니냐 하는 것에 영향을 미칠까요?

일단 확실한 것은 신문이라는 매체와 웹사이트라는 매체는 전혀 틀리다는데 있습니다. 신문과 비교해서 웹사이트는 영속성이라는 개념이 들어있습니다. 즉, 없어지질 않는다는데 있고, 따라서 편집이라는 개념도 같지 않습니다. 검색엔진은 많은 웹사이트를 편집해서 보여줍니다. 그것도 편집일까요? 신문사 웹사이트만을 보아서 서비스하고 있는 Google News도 편집일까요?

웹과 신문은 동질성보다는 차이점이 훨씬 큽니다. 더군다나 현재의 웹은 단순하지 않습니다. 여러가지 서비스들이 섞여 있고, 그것을 기사가 들어간다고 해서 신문과 동일하게 취급하는 것 자체가 불가능합니다. 마치 컴퓨터에 TV카드를 달고 판매한다고 TV로 취급하는 것과 마찬가지입니다.

포탈을 신문법에 적용시키는 것 보다는 새로운 법안을 내놓는 것은 당연합니다. 왜 포탈을 신문이라는 테두리에 넣으려는 것인지 알 수가 없군요. 새로운 매체에는 당연히 새로운 법률이 필요합니다. 기존 법률에 새로운 매체 내용을 담기 위해서 법안은 쓰레기가 될 것이 뻔합니다. 더군다나 법안을 기준으로 만드는 시행령은 더더욱 쓰레기가 될 것입니다. 가장 중요한 것은 포탈의 정의가 현재 불분명하다는데 있습니다.

포탈들이 신문법에 적용을 받는 것을 왜 두려워 하냐라는 “변희재 런아시아 편집국장”의 말은 잘못 적용된 법의 피해를 한번도 받지 않아본 분이거나 사업을 한번도 해보지 않은 분일 것입니다. 보통 법을 만들고 보자란 부분은 시행령에서 해결한다라는 것은 전혀 믿음이 가질 않습니다. 정부는 일반적으로 관리의 편리성으로 시행령을 만들고, 법적용을 받는 자의 편의를 생각하지 않습니다. 예를 들면 잘못된 “개정 소방법”이 그렇습니다. 일률적으로 2층 이상의 사업장이라면 불연재를 사용해야 한다는 것은 1년 유예기간 후에 단속에 들어가야 하지만, 실제 그것이 불가능하기 때문에 1년 더 연장되었습니다. 시행령은 보통 이런 식이죠.

온라인 뉴스의 경우 신문법 보다는 컨텐츠와 관련된 저작권 문제로 해결을 하는 것이 맞습니다. 그리고, 뉴스를 보여지는 것에 문제가 발생하면 보안적인 시행령이 있으면 되는 것이지, 그것을 억지로 신문법에 맞출 필요가 없습니다.

다른건 차지하고서라도 웹과 신문… 도대체 무슨 공통점이 있습니까?

표준은 어디에나 존재한다. but…

nmind님의 언급처럼 표준이라는 것은 기술적인 것 보다는 약간은 정치적인 면이 있습니다. 시장이 커지면 보통 미국에서부터 표준화 작업이 이루어 집니다. 비영리 단체에서 그러한 일을 하고 있으며, 웹에서는 보통 W3C에서 관련 표준화 작업을 진행합니다.

마이크로소프트에서 만드는 OS도 표준이 존재하고, 비쥬얼 스튜디오에서 지원하는 언어들도 표준이 존재합니다. 심지어는 종교도 표준이 존재합니다.

일반적으로 표준은 처음엔 많이 쓰이는 부분을 묶는 것부터 시작하고, 시간이 지나면 선도적인 권고를 내놓습니다. 지금은 쓰이지 않아도 이렇게 하면 모든 이에게 이롭다는 식입니다. W3C에서 현재의 표준으로 삼는 XHTML1.1+CSS2.0이 과연 모든 이에게 이로울까요?

CSS 레이아웃의 표준

CSS 레이아웃을 만드는 것에 가장 불리한 점은 “쉽지 않다”라는 점입니다. 무슨 이야기냐 하면 W3C에서 제공하는 레퍼런스만을 보고 디자인을 할 수가 없습니다. 즉, 브라우져에 띄우기 전까지는 어떻게 나올지 알 수 없다는 이야기입니다.

즉, 테이블 레이아웃을 적용할 때에는 IE, FireFox, Safari 등의 태그 레퍼런스를 참고하지 않아도 디자인이 가능합니다. 그 이유는 테이블이라고 하는 것은 웹이 처음 생길 때 부터 존재했던 것이기 때문이죠. 하지만, CSS는 여러가지 브라우져가 나온 이후에 생긴 것으로 브라우져마다 적용 방법이 약간씩 틀립니다.

우리는 왜 브라우져 핵을 사용해야 하는가?

저도 과거에 CSS만으로 웹페이지를 구성한 적이 있습니다. 코드와 디자인의 분리는 만드는 입장에서는 꽤나 매력적인 것이 사실입니다. 즉, 코드는 DIV로 쌓여져서 그 자체로 데이터만 넣고, 디자인은 style.css 등의 파일 안에 넣습니다. 디자인을 고칠때에는 style.css파일만 수정합니다. 정말 매력적입니다.

하지만, 오래 지나지 않아서 브라우져 별로 CSS를 적용하는 것이 쉽지 않다는 것을 알게 되었습니다. 그리고, 전혀 불필요하지만 CSS만으로 디자인 할 때 필요한 것, 즉 브라우져 핵을 써야한다는 사실도 알았습니다. 브라우져들이 CSS를 적용을 달리하는데 우리는 한개의 CSS로 둘 다 제대로 나오게 해야 합니다. 프로그래머의 경우는 보통 동일 API를 사용할 수 있는 라이브러리를 만들어서 코딩을 하는데, 하나의 프로그램 코드가 유닉스던 리눅스던 윈도우던 동일한 출력을 보장하게 하는 가장 편한 방법입니다. Google이 Picasa 리눅스 버젼을 만든 방법이 이것입니다.

하지만, CSS는 단순한 상속의 개념은 있지만, 클래스처럼 그것을 자유롭게 활용하기가 구조적으로 불가능합니다. CSS 3.0에서는 해결이 될 것 같지만, 현재는 모든 브라우져에서 동일한 출력을 보장하는 CSS 파일은 불가능합니다.

따라서, 선택은 세가지로 압축됩니다. 브라우져 핵을 이용하거나, 브라우져 별 별도의 CSS를 만들거나 아니면 디자인 자체를 핵이 필요없는 것으로 바꾸거나…

방금 검색을 해서 알아본 두가지 CSS 코드를 소개합니다.

<style type=”text/css”>
#mydiv {
color: blue;
drdoc: “;
drdoc: “”;
color: red;
background: silver;
/*”;/* IE */
font-weight: bold;
}
#nextdiv {
color: red;
}
body {
background: navy;
}
</style>Note: IE will continue parsing after /* IE */

그리고,

<style type=”text/css”>
#mydiv {
color: blue;
/*/*/
drdoc: “;
drdoc: “”;
/* NN4 */
color: red;
background: silver;
/*”;/* IE */
font-weight: bold;
}
#nextdiv {
color: red;
}
body {
background: navy;
}
</style>

이것은 라운드 박스를 구현하는 CSS입니다.

border: 2px solid gray;
-moz-border-radius: 25px;
width: 400px;
height: 200px;
padding: 15px;

브라우져 호환성을 갖게 하기 위한 노력으로 이런 코드는 레퍼런스도 없습니다. 해보고 되면 블로그등에 올려서 전파됩니다. 그러고보니 집단지성이군요.

이 글을 보시는 관계자 분들은 위의 코드를 해석하실 수 있습니까? 만약 전임자가 이런 코드를 넣었다면 수정하실 수 있겠습니까?

CSS로 잘 만든는 것은 무엇을 의미하는가?

CSS가 쉽지 않다는 것은 누구나 알고 있습니다. 보통 CSS가 레이아웃을 잡는데 “잘 만들면” 더 생산적이고 편하고 빠르다라는 말을 하는 분도 있습니다. 물론 실력이 있어서 브라우져 핵을 자유롭게 쓰는 분일 것입니다.

여기서도 문제는 있습니다. 브라우져 핵이 필요한 CSS파일을 누군가는 만들어야 합니다. 프로그래머? 디자이너? 컨텐츠 제작자? 만약 웹디자이너가 한다고 하면 기업에서 면접을 볼 때 브라우져 핵을 하지 못하면 뽑지 말아야 하나요?

XHTML은 1.1버젼에서 HTML4.0과 양립할 수 없습니다. 어떤 해결방법이 있을까요? 전 현실적인 문제로 인해 찾을 수가 없습니다.

난 XHTML1.1+CSS2.0을 반대하는 것이 아니다. 하지만 불편한걸 어쩌나?

CSS를 설명하는 블로그를 보면 보통 팁으로 설명합니다. 브라우져 핵도 마찬가지구요. w3schools.com은 CSS 초기버젼을 잘 설명해 주고 있습니다.

제가 의문을 제기하는 것은 CSS 레이아웃에 한정하는 문제입니다. 어떤 분은 가능하다, 어렵지 않다 라고 합니다. 우리는 CSS로만 레이아웃을 할 때 아래와 같은 기능을 해야 합니다.

1. 모든 브라우져에서 같은 디자인이 출력되어야 한다.
2. 디자이너가 디자인 한 것 그대로가 화면에 나와주어야 한다.
3. CSS는 화면 크기를 변경했을 때 원하지 않는 동작을 하면 안된다.
4. 가로 길이가 %로 정해졌을 때도 3번은 지켜져야 한다.

제 경험으로는 위의 것을 CSS 레이아웃만으로 구현하는 것은 가능은 할 지언정 절대 쉽지 않습니다.

이렇게 되면 하겠다.

아래의 것들이 완벽히 작동된다면 CSS 레이아웃은 사용할 가치가 충분하지 않을까 합니다.

1. 브라우져별 공통의 CSS 레퍼런스가 존재하고, 그것이 제대로 작동된다.
2. 1번이 안된다면 공통 스타일 파일이 존재하고, 파일 레퍼런스만 지키면 대부분 브라우져에서 작동한다.

이 글은 Jay G님의 글에서 반론을 제기받고 답변으로 쓴 글입니다.

링크프라이스 약관 검토

리플라드 애드“는 머천트(광고주)의 웹사이트를 검색해서 광고 효과가 좋은 것들을 피드백을 받아서 효과를 올리는 솔루션입니다. 머천트 모집에 있어서 링크프라이스와의 어필리에이트 계약을 이용하기로 결정하고 링크프라이스의 약관을 검토한 요약을 소개합니다.

이 문서는 일반적으로 링크프라이스의 머천트 광고를 게재할 때 필요한 것으로 어필리에이트의 의무 중 중요한 것들을 검토한 것입니다. 실제 적용을 하기 위해서는 완전한 약관을 검토하세요.
(링크프라이스 공식 웹사이트에서는 약관을 보기 위해서는 회원 가입을 해야 합니다. 따라서, 글쓰는 현재-2006년 6월 14일-의 약관내용을 링크합니다.)

링크프라이스는 온라인 상의 많은 광고 형태를 지원하고 있습니다. 웹사이트 만이 아닌, 툴바 같은 프로그램에도 링크프라이스 솔루션을 사용할 수 있습니다. 이 문서에서는 S/W나 이메일 광고는 검토하지 않고, 웹사이트에 올리는 광고만을 설명합니다.

링크프라이스 어필리에이트에 가입 시 주의해야 할 점

AdSense도 마찬가지지만 어떤 광고 프로그램도 주의해야 할 약관이 있습니다.

  • 서비스에서 얻은 정보를 운영자의 사전 허가 없이 제3자에게 공개 또는 배포하지 마세요.
  • 매출이나 엑션(회원가입 등)이 일어났을 때의 상품이 아닌 클릭(CPC)이나 페이지뷰(CPM)로 광고비를 받는 프로그램은 링크프라이스에서 제공하는 광고와 코드를 이용해야 합니다.
  • 웹사이트 컨셉이 폭력이나 음란하다면 약관위배가 됩니다.
  • 수익이 2만원 이상일 때 1만원 단위로 지급되며, 세금은 원천징수 됩니다.
  • 이메일로 광고를 할 경우 동의한 회원에게만 발송을 해야 하며, 수신거부버튼이 있고, 제목에 내용이 들어가야 하는 등의 요건이 있습니다. 이 부분은 법률도 참고해야 합니다.
  • 광고주의 상표와 관련해서 오해를 일으키거나 자바스크립트로 자동으로 포워딩 등은 허용되지 않습니다.

위의 여섯가지는 중요하다고 생각되는 것을 정리한 것일 뿐입니다. 전체 약관을 읽어보도록 권고합니다.

XHTML, HTML, CSS 그리고 테이블

용어의 혼돈으로 단문으로 쓰는 것이 좋을 것 같아서 차분하게 정리해 봅니다.

사실

1. XHTML1.1+CSS2.0은 현재 표준이라고 불리우지만, 영문으로는 권고라고 한다.

2. XHTML은 HTML의 확장판이며, HTML을 포함하고, XML형식의 모든 언어를 포함하는 구조를 지칭한다.

3. CSS에서 말하는 접근성은 일반적으로 시작장애자나 마우스가 없는 컴퓨터에서 쓸 수 있도록 만든다는 의미의 접근성과는 틀리다. 사람이 대상이 아닌 프로그램이나 기기(device)가 인식하기 쉽도록 한다는 의미이다. 예를 들어서 제목을 H 태그로 쓰면 다른 프로그램은 그 문단이 제목 혹은 중요한 문단이라는 것을 알고 가중치를 부여하는 등의 행위를 할 수 있게 된다.

4. CSS만으로 레이아웃을 하는 것은 어려운 작업이다. 하지만, 불가능한 것은 아니다. 일반적으로 테이블로 디자인 했을 경우 같은 디자인이라도 CSS만으로 만들면 경우에 따라서 뉴스가 된다.

주장

1. 테이블 레이아웃은 생산성 면에서 CSS 레이아웃보다 뛰어나다.

2. 유지 보수 측면에서도 CSS 레이아웃은 테이블 레이아웃보다 나은 점이 없다. 왜냐하면 테이블 레이아웃은 그 자체로 문서와 하나가 되지만, CSS는 보통 별도의 파일에 레이아웃이 스타일만으로 들어가 있기 때문에 다른 사람이 만든 디자인을 분석하는 것은 쉽지 않다. Yahoo!은 선도적으로 XHTML과 CSS만으로 첫페이지를 꾸몄는데, 그 소스를 보고 디자인을 수정하는 것을 상상해보자.

3. XHTML과 CSS레이아웃은 경우에 따라서 양립하기가 쉽지 않다. 왜냐하면 XHTML은 모듈의 결합을 추구하는데, 여기서 모듈이란 컨텐츠 만이 아니라 디자인까지 포함된다. 10가지 모듈이 DIV태그에 쌓어여 존재할 때, 디자인에 따라서 모듈간 감싸는 DIV 태그는 틀리다. 이 말은 CSS파일의 수정 만으로는 디자인 변경이 불가능하다는 의미다. 원래의 XML은 완벽하게 디자인과 문서가 분리된다. 하지만, XHTML은 그렇지 못하다.

4. 경험상 가장 편한 제작방법은 레이아웃을 테이블로 잡고, 각각의 모듈만을 DIV로 감싸는 것이다. 특별한 디자인이 필요할 경우(메뉴나 라운드가 들어간 사각형), 일부러 CSS만으로 디자인 할 필요는 없다. 보통 이런 경우 익스플로러와 사파리, 혹은 파이어폭스 간의 호환성을 맞추기 위해서 많은 시간이 투자되어야 하기 때문이다.

5. 이종기기간 호환성은 환상이다. 마치 컴퓨터를 살 때 CPU 교환이 되어 미래에도 사용할 수 있다고 홍보하는 것과 마찬가지이다. 컴퓨터가 구형이 되면 CPU와 램 확장만으로 원하는 성능을 얻는 것은 사실상 불가능하다. 마찬가지로, 어떤 웹사이트에서 모바일용 웹사이트를 런칭한다고 하면 그것은 새로 제작되어야 한다. 디자인, 프로그램 그리고 비지니스적인 면에서 봐도 마찬가지다.

6. 이종기기간 호환성과는 별개로, 브라우져간 호환성은 매우 중요하다. 특히 돈을 받고 이미지 광고 같은 것이 있을때는 더욱 그렇다. 만약 브라우져간 호환성이 없어서 페이지가 제대로 보이지 않을 때에는 세이클럽처럼 호환성이 없는 브라우져에서 아예 서비스를 하지 말아야 한다.

7. 브라우져간 최고의 호환성은 CSS를 쓰지 않는 것이다. 브라우져 호환성은 익스플로러나 사파리, 파이어폭스 만을 말하는 것이 아니라 각 브라우져 별 버젼 호환성을 포함한다. Google의 검색 첫화면의 소스를 보도록 하자. 테이블 레이아웃이고, XHTML이 아닌 HTML로 제작되어 있다. 현재까지 하휘 호환성은 브라우져별 호환성과 마찬가지로 중요하다.

8. 흔히 말하는 접근성은 CSS로 레이아웃을 잡느냐 테이블로 잡느냐와는 상관이 없다. 보통, 키보드만으로 사용이 가능한지 혹은 800*600의 256컬러로도 제대로 보이는지 등을 말하고, 그것은 디자인 자체와 HTML 코드의 사용에 기인한다.

9. XHTML에서 말하는 표준과 파이어폭스에서 제대로 안보인다 라고 할 때의 표준은 전혀 다른 말이다. 일반적으로 표준이 아니다라고 말 할 때에는 익스플로러에만 있는 Javascript나 태그를 사용하는 것을 지칭한다.

다음 부터는 어이없는 예측

W3C가 HTML, XHTML 그리고 CSS를 포함만 많은 부분에서 권고를 발표하는 것은 제 생각에는 웹페이지 제작자가 참고해야 될 부분이 아니라 브라우져 제작자가 참고해야 할 부분입니다. 연구&개발이 아닌 다음에야 원하는 디자인을 보여주는 것이 목적이 아닐까요?

표준을 따르는 것 자체가 목적이 되면 앞뒤가 바뀌는 것이 아닐까 합니다.

웹표준과 CSS

일모리님은 한국 웹표준의 전도사로서 정확한 지식을 전달하는데 많은 도움을 주고 계신 분입니다. 이 글은 어떤 정보가 다른 쪽으로 해석될 수도 있다는 것을 보여주기 위해서 쓰여졌으며, 모든 내용은 실전에 적용을 해 본 후 나름대로의 느낌을 적은 것임을 먼저 알려드립니다.

웹표준과 CSS은 관계가 없다.

원론적으로 이야기하자면 처음 CSS가 W3C에 권고될 때가 1996년 12월 17일로 정확한 문서의 제목은 “Recommendation: CSS level 1“입니다. 스펙을 보면 느낄 수 있겠지만, 기존 태그를 style로 대체하기 위해서 만들어진 것을 쉽게 알 수 있습니다. 그리고, 태그에 확장성을 가미해서 더 쉽게 디자인 할 수 있는 것도 중요하겠죠. 이 문서로 인해 CSS의 기본 문법이 정해졌습니다. 스타일간 그룹화가 가능하고, 상속도 가능합니다. 하지만, 이 문서에 레이아웃에 대한 것은 전혀 나와있지 않습니다.

현재는 어떨지 몰라도 처음 CSS가 나올때는 더 편하고 쉽게, 그리고 많은 기능을 구조적으로 선언하기 위해서 만들어 졌다는 사실을 알 수 있습니다.

그렇다면 웹표준 이야기가 나올때 왜 CSS라는 것이 나올까요? 일모리 님의 지적대로 정확히 말하자면 CSS가 아니라 XHTML이라고 칭해야 합니다. 즉, CSS+XHTML이 정확한 표준이 되는 것이지요.

위의 말처럼 레이아웃을 체처두고 텍스트 문단만을 HTML 태그 대신 CSS로 적용하면 많은 잇점이 생기게 됩니다. 구조화가 되었기 때문에 간단한 수정은 한줄만 바꾸어도 곧바로 적용이 됩니다.

문제의 핵심 XHTML로의 접근

XHTML은 XML형태로의 HTML을 구현하기 위해서 만들어 졌습니다. 아마도 W3C는 HTML 4를 마지막으로 그 이상은 없으며 XHTML로의 이행을 바랬을지도 모르겠습니다.

의도가 무엇이던간에 XHTML 1.0버젼은 그 자체로 HTML보다 엄격한 규칙이 존재하지만, HTML 4의 재구성버젼이고, 따라서 기존 HTML을 렌더링하는 브라우져에 보여지게 됩니다. 문제가 되는 것은 XHTML 1.1버젼입니다.(XHTML 2.0도 있으나 이 부분은 컴퓨터만이 아닌 많은 디바이스에서 대용량 문서를 구현하는 것도 포함하는 매우 광범위한 문서 기준이므로 생략합니다.) W3C의 행보를 보면 HTML을 XHTML로 흡수하고, 다른 MathML과 같은 태그기반도 흡수하려는 생각으로 보입니다. 당연한 것이 XML의 기본 생각이 모든 데이터에 구조화된 태그를 붙여 상호 연동이 수월하도록 하는데 있습니다. 사실 이 얘기는 매우 오래전부터 논의되어 왔습니다.

XHTML의 실체가 무엇인가?

W3C 인용:

XHTML document type that is based upon the module framework and modules defined in Modularization of XHTML [XHTMLMOD]. The purpose of this document type is to serve as the basis for future extended XHTML ‘family’ document types, and to provide a consistent, forward-looking document type cleanly separated from the deprecated, legacy functionality of HTML 4 [HTML4] that was brought forward into the XHTML 1.0 [XHTML1] document types.

위 내용에서도 알 수 있듯이 XHTML 1.1은 현재 그리고 미래의 모듈 프레임웍을 구현하기 위한 스팩입니다. 즉, CSS는 디자인의 구조화를 위해서 생겨난 것에 비해서 XHTML은 HTML을 XML형식의 프레임웍으로 구현하고, 웹이 아닌 다른 디바이스까지 포함하기 위한 광범위한 스펙이 됩니다.

그렇다면 CSS로 레이아웃을 잡는 것은 갑자기 왜 나온 얘기인가?

CSS와 XHTML 스펙에는 레이아웃에 대한 이야기는 없습니다. 그렇다면 테이블 레이아웃이 표준이 아니라는 이야기는 어디서 나온 이야기일까요?

W3C의 문서 중 “Web Content Accessibility Guidelines 1.0“를 보면 그 답을 알 수 있습니다. 이 문서는 CSS나 XHTML의 권고(사실상 표준이라고 쓰입니다.)와는 틀린 가이드라인입니다. 이 문서에서 테이블 레이아웃에 대해서 다음과 같이 기술하고 있습니다.

W3C 인용:

Using markup improperly — not according to specification — hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it. Furthermore, using presentation markup rather than structural markup to convey structure (e.g., constructing what looks like a table of data with an HTML PRE element) makes it difficult to render a page intelligibly to other devices (refer to the description of difference between content, structure, and presentation).

즉, 테이블 레이아웃은 디자인의 쉽고 어려움과는 전혀 상관없이 프로그램에서 데이터를 알기가 힘들고, PC 이외의 다른 기기에서 렌더(HTML을 실제 이미지로 변환하는 것)의 어려움이 있다는 것입니다. 즉, 코드의 확장성을 염두에 둔 가이드라인이라는 것입니다. XHTML로 디자인을 하면 코드 변경없이 모바일에서도 서비스가 된다고 생각하면 쉽습니다. Google은 모바일용 웹사이트에서 XHTML을 지원하고 있습니다.

실전을 이야기 할 때

위의 글에서 CSS라는 것은 웹표준과는 그다지 상관없고, XHTML과 합쳐질 때 표준이 된다는 사실을 알았습니다. 이제 실전에 적응해 봅시다.

어떤 회사가 웹사이트를 CSS2.0+XHTML1.1 스펙에 맞게 디자인을 했다고 칩니다. 그 회사는 모바일용 웹사이트를 따로 제작하지 않고, 같은 문서에 CSS 파일의 변경만으로 모바일용 웹문서 디자인을 끝냈습니다. 또한, CSS만의 변경으로 시작장애인용 웹사이트를 글씨가 크고, 네비게이션도 크게 디자인했습니다.

위의 이야기는 실제로 일리가 있어 보입니다. 하지만, 실전에서 이렇게 사용되는 경우가 관리가 부담되는 개인 웹사이트 외에 있을까요?

우선 나누어 생각해 보면 모바일은 기본적으로 매우 작은 화면을 갖습니다. 따라서, 한 페이지에 나오는 정보의 양도 매우 적습니다. 웹사이트의 로직 부분도 당연히 틀려져야 합니다. 모바일의 한정적인 정보를 보여주기 위해 웹용으로 제작된 코드를 그대로 사용할 이유가 전혀 없는 것입니다. 즉, 모바일용 웹사이트는 다시 제작되어야 합니다.

시작장애인용 웹사이트도 마찬가지입니다. 시작장애인용 웹사이트를 CSS의 교체만으로 당연히 디자인이 가능합니다. 하지만, HTML 문서를 새로 만드는 것이 훨씬 빠를 것입니다.

위의 글에서 CSS+XHTML 문서를 이용해야 되는 이유는 콘텐츠의 재활용(확장성)에 있다는 것을 W3C문서에서 알 수 있었습니다. 그 말은 내가 만드는 페이지가 다른 디바이스에 나오거나 같은 디바이스라도 다른 디자인이 보여져야 할 때에만 의미가 있다는 말입니다.

XHTML이 디자인과 컨텐츠를 분리해준다?

이 분야의 가장 유명한 모델 중 하나는 MVC(모델,뷰,컨트롤러)패턴입니다. 여기서 디자인과 관계되어있는 뷰, 즉 프리젠테이션 영역에 속합니다. 프리젠테이션은 단순히 어떻게 디자인되느냐가 아니라 사용자에게 어떻게 보여주느냐 하는 것으로 그 둘은 많은 차이를 가지고 있습니다.

비지니스 로직에서 원화로 1000원을 프리젠테이션으로 넘겨주었다고 합시다. 프리젠테이션 영역에서는 1000원을 1,000원으로 표시할 수도 있고, KRW 1000이라고 표시할 수도 있습니다. 즉, 프로젠테이션에는 “조건이 있는 코드”가 들어가야 한다는 의미입니다.

이 이야기는 비지니스 로직과 프리젠테이션 로직의 분리 문제는 개발 정책상의 문제이고, 실제 이런 것들이 필요할 때, CSS의 교체로 리뉴얼을 하는 것 보다는 템플릿을 이용한 리뉴얼이 훨씬 유연한 환경을 제공합니다.

그럼 여기서 주장하는 것은 도대체 무엇?

처음 글을 작성할 때의 의도는 무엇이 올바른 것이냐 하는데 부터 시작했습니다. 그리고, 이런 부분은 정책의 문제이고, 웹표준이라는 것의 실체가 무엇인지 알아야 되는 당위성을 포함합니다. 쉽게 말하면 웹표준을 왜 따라야 하느냐 하는것이죠.

현실적으로 XHTML이 추구하는 방향에 가장 확실하게 부합하는 것은 디바이스 별 디자인이 별도로 들어가는 것입니다. 모바일용 웹페이지 따로, PC용 따로, PDA용 따로… 템플릿을 이용하면 이런 것은 매우 수월하게 만들 수 있습니다. 반면 CSS를 이용해서 제작한다고 하면 대부분 사람이 인정하듯이 쉽지 않은 일이 되어 버립니다. 그리고, 테이블 레이아웃에 중간중간 CSS를 적용하면 가장 빠르고 대부분의 브라우져에서 보여지는 웹사이트 제작이 가능합니다.

부연

일모리님이 지적하신 오페라로 제대로 보여지는 웹사이트 제작이 실질적으로 불가능하다는 이야기는 예전 저의 경험에서 나온 것입니다. 테이블을 쓸 때 전 보통 IE, 파이어폭스, 그리고 오페라에서 테스트를 하곤 했는데, CSS만으로 제작할 때 오페라에서 디자인을 같게 만드는 것이 불가능하게 생각되었기 때문입니다. 이 것은 개인적인 경험입니다.

nmind님이 지적하신 디자인과 컨텐츠의 분리는 그 자체가 중요한 것은 아니라고 생각됩니다. 여러가지 개발 모델들이 있기 때문에 개발팀의 선택에 따라 틀려질 것 같네요. 일반화 시키는 것은 약간 무리가 있어 보이네요.

다만, 테이블 레이아웃을 기술이 없어서 그렇다는 식은 좀 곤란하지 않나 싶습니다. 쉬운 길이 있으면 쉬운 길로 가는 것이 좋아 보이거든요.

웹 2.0시대를 여는 10가지 거대한 변화의 반론

doyoung님은 Channy로 잘 알려진 윤석찬 팀장님의 웹 2.0의 개념을 정리한 10가지 변화를 잘 정리해 주셨습니다. 웹 2.0이라는 말만 나오면 우려되는 바이지만, 기술적인 내용을 너무 정치적으로 몰고 나아간다는 것 같습니다. 이에 반론을 해 봅니다.

1. 웹 표준을 지켜라.

웹표준을 지켜야 하는 이유는 여러가지 브라우져에 제대로 혹은 잘 보이게 하는 가장 편리한 방법이기 때문이지 그 이상도 아닙니다. 그리고, 테이블도 엄연한 표준이지만, 레이아웃을 테이블로 잡는 것은 웹표준이 아니라는 말은 어패가 있습니다.

실제 CSS를 이용한 레이아웃은 테이블에 비해서 수정이 쉽다고 하지만, 아주 간단한 레이아웃이 아닌 약간만 복잡한 레이아웃을 CSS만으로 적용하려 하면 테이블에 비해서 아주 많은 노력이 있어야 합니다. 테이블이 매우 직관적인데 비해서 CSS는 코드 자체만으로 디자인이 머리에 그려지질 않기 때문에 수정이 쉽지도 않습니다. 또한, 테이블에 비해서 CSS는 브라우져마다 약간씩 적용되는 바가 틀리기 때문에(padding이나 margin 등) CSS 핵이라는 전혀 필요없는 코드가 들어가야 합니다.

또한, CSS가 좋다라고 이야기 할 때 흔히 등장하는 이야기로 시작장애인이나 모바일용 웹사이트를 CSS의 수정만으로 만들 수 있다는 말은 일리 있는 말로 들리지만, 상업적 혹은 대형 웹사이트를 제작할 때 경험이 조금이라도 있는 분은 모바일용 웹사이트는 완전히 새로 제작해야 한다는 것을 알 수 있습니다. 이에 대해서는 많은 분량의 글이 요구되므로 차후에 설명하도록 하겠습니다.

CSS를 썼을 때 장점이라고 한다면 코드 자체의 양의 많이 줄어든다는 데 있습니다. 이 것은 꽤 중요한 것으로 포탈사이트의 첫페이지는 이 이유때문에 CSS를 적용하고 있습니다.

2. 모든 브라우저를 지원하라.

이 것은 당연합니다. 하지만 모든 브라우져에 적용할 수 있게 제작하기 위해서는 테이블 베이스의 디자인 밖에는 없습니다. 오페라와 같은 브라우져에서 제대로 보이는 디자인을 CSS로 구현하는 것은 실질적으로 불가능합니다. 아주 간단한 디자인이라면 몰라도…

그리고, 이 부분이 중요한 이유는 또 한가지가 있는데, 광고가 들어가는 웹사이트에서 타브라우져로 보았을때 광고가 제대로 보여지지 않는다면 신뢰도에 큰 문제가 생깁니다. 페이지뷰로 단가가 책정되는 이미지 광고의 경우 보여지지도 않는 광고로 광고주가 광고비를 지급하기 때문입니다. 얼마전까지 야후!의 뉴스페이지 상단 728X90사이즈의 광고가 파이어폭스에서 하단 20픽셀 정도밖에는 보이지 않는 적이 있었습니다. 그것도 꽤 오랫동안…

3. 문자 인코딩을 UTF-8로 바꿔라.

사실 이 문제는 약간 복잡합니다. 유니코드가 어떤 디바이스에서 구현되기 위해서는 방대한 문자 테이블이 저장되어야 하고, 대규모의 폰트가 있어야 합니다. MS에서 제공하는 OS는 대부분 유니코드 폰트(폰트 이름에 Unicode가 포함되어 있음)가 들어있지만, 대부분의 모바일에는 들어있지 않습니다. 즉, 서비스에 따라서 틀려지는 것입니다.

더군다나 UTF-8이라는 문자셋은 EUC-KR보다 훨씬 많은 용량을 잡아먹습니다. EUC-KR은 글자당 2바이트이지만, UTF-8은 최소 3바이트를 잡아먹기 때문에 대체로 1.5배에서 2배까지 차이가 납니다.

UTF-8을 썼을 때의 강력한 잇점은 여러가지 언어로 되어 있는 웹사이트를 가장 손쉽게 제작할 수 있다는 점입니다.

인용한 글에서 지적한, 한글로 된 페이지가 읽히지 않는 것은 또 다른 문제입니다. 인터넷 주소인 URL은 ASCII와 -(Dash)만으로 제작되도록 권고되고 있습니다. 보통 웹사이트 주소를 등록할 때 한글 URL이 등록되지 않는 것과 마찬가지입니다.(이 부분은 퓨니코드라는 것으로 바뀌고 있습니다만…) 즉, 한글로 웹사이트에 올리는 문서를 저장하는 것 자체가 문제인 것이죠. 그리고 이 문제는 OS의 기본 문자셋도 고려해야 하므로 UTF-8로 만들어야 한다는데 이 문제를 거론하는 것 자체가 무리입니다.

하지만, UTF-8로 제작했을 때 많은 잇점이 존재하기 때문에 이 블로그 외 이삼구글에서도 UTF-8이 기본으로 되어 있습니다.

4. 짧고 이해하기 쉬운 주소를 만들어라.

이 문제는 벌써 8년 전부터 처음 인터넷 비지니스가 나온 시대부터 중요한 이슈가 되었던 부분입니다. 지금의 흐름이라고 한다면, 예전에 비해서 URL의 비중은 많은 없어졌습니다. 보통 검색엔진에서 검색 후 클릭을 하기 때문이지요. 저만해도 기억하는 웹사이트 주소는 20개를 넘지 않습니다.

5. 콘텐츠의 유통 방식을 고민하라.

콘텐츠를 유통하는 최고의 방식은 지금 나와있는 모든 컨텐츠 배급 시스템을 이용하고, 네이버 지식인에 광고 홍보성 글을 올리고, 주소를 모두 등록하고, 배너를 교환하는 등 많은 방법이 알려져 있습니다. 정작 중요한 것은 콘텐츠 유통 방식을 고민하는 것이 아니라 콘텐츠의 상업적 유통 방식을 고민하는 것입니다. 그리고, 콘텐츠 유통의 합법적 방법을 찾아야 합니다.

콘텐츠 유통의 대부격인 APPLE은 RSS등을 이용하지 않아도 세계 최고의 배급 시스템을 완비했습니다. 그것도 합법적으로 구현하고 있습니다. 이 부분은 생각처럼 간단한 문제가 아닙니다. 소리바다도 RSS등을 사용하지 않고 한국 최고의 유통 시스템을 만들려 하고 있습니다.

RSS가 컨텐츠를 보거나 듣는 사용자 입장에서는 매력적으로 보일 수도 있습니다. 하지만, 사업자 입장에서는 아직까지 메타 사이트나 포탈 사이트의 광고 수익을 올리는 정도 밖에는 보이질 않습니다.

가장 중요한 것은 콘텐츠 자체의 질에 있습니다. 그리고, 콘텐츠로 영업을 하는 기업은 해당 웹사이트의 소비자 신뢰도를 높이는데 최선을 다해야 합니다. 저의 여러가지 테스트의 결과로 나타나는 공통된 것은 웹사이트 신뢰도가 방문자의 성격을 바꿔놓는다는 것입니다.

6. API를 공개해 사용자들을 끌어들여라.

중요한 것은 API를 공개하는 회사의 데이터 신뢰도 입니다. Google Maps가 최고의 매쉬업 플랫폼이 된 이유는 지도를 무료로 제공하기 때문입니다. 네이버의 OpenAPI가 지지부진한 이유는 OpenAPI를 이용해 받을 수 있는 데이터가 쓸모가 없어서 입니다.

개발자는 기술적으로 API를 공개하건 말건간에 웹사이트에 있는 데이터를 재가공하는데 아무런 어려움이 없습니다. 현재의 한국 포탈들이 정보를 공개하지 않고 있는데 API를 공개하면 뭐에 써먹을 수 있을지 모르겠습니다.

API를 제공하느냐 마느냐 이전에 신뢰할만한 데이터를 가지고 있느냐가 문제의 핵심입니다. 만약 어떤 포탈에서 영어사전을 내용까지 제공하는 API를 제공하기만 하면 1년도 안되어 100개 이상의 매쉬업이 나오리라 확신합니다.

7. 집단지성을 활용하라.

집단지성이라는 말이 나오기 전에 Google은 초창기 때부터 인터넷에 민주주의가 작동된다고 선언했습니다. 지금은 전혀 그 말이 통하질 않습니다. 그것도 오프라인에 비해서 더욱 그렇습니다.

어느 사회나 있는 것이 악질 사용자 들입니다. 온라인에서는 스패머가 그러한데, 이들의 행위 자체는 불법이 아닙니다. 고작해야 회사의 약관을 어긴 정도입니다. 태그, 트랙백 등은 구조상 스패머를 막을 수 있는 방법이 전혀 없습니다. 간단한 스크립트로 한개의 URL에서 수천만개의 페이지를 만들 수 있고, 적절한 태그를 섞어서 만들고, 다른 블로그에 트랙백을 쏜다고 가정해 봅시다.(지금도 매우 흔하게 일어나는 일들입니다.)

Google의 PageRank는 한개의 웹사이트가 1표를 갖는다라는 것으로 출발을 했고(백링크), 그것은 얼마전 대규모의 빅대디로 인해 최근 사용자의 대규모 검색 및 링크 데이터를 이용하는 것으로 바뀌었습니다. 그리고 트러스트 랭크라는 믿을 수 있는 웹사이트를 랭크 10으로 잡고, 백링크로 순위를 메기는 방식이 연구되고 있습니다.

태그라는 것을 유심히 본 사용자는 알겠지만, 자신의 블로그에 태그를 붙이는 것도 공부를 해야 하는 것입니다. 사실 태그라는 것은 신문사 웹사이트에 키워드라는 것으로 오래전부터 구현되어 온 것인데 그것이 블로그로 확장된 것입니다. 신뢰도 없는 태그가 쓸모가 있을까요?

8. 가벼운 플랫폼을 써라.

플랫폼의 선택은 프로젝트에 따라 틀립니다. 만약 동일 프로젝트에 플랫폼을 선택한다면 당연히 최단시간에 최고의 효과를 올릴 수 있는 플랫폼을 선택합니다. 그 이유에서 PHP와 플래쉬 등이 단기간에 최고의 인기를 누리고 있습니다.

9. 더 많은 기능을 제공해라.

AJAX에 대한 미래는 많은 논의가 있었지만, 실제 테스트를 해 보면 현재 나오고 있는 얘기와는 많이 틀리다는 것을 알 수 있습니다.

8번에서도 나왔지만, 어떤 프로젝트에서 중요한 것은 최단시간의 최고의 효과입니다. AJAX는 그 면에선 절대 최선의 선택이 아닙니다. 프로그래머가 AJAX를 익히기 위해서는 매우 많은 시간이 걸립니다. AJAX는 새로운 기술은 아니지만, Google Maps가 나오고 나서야 인정을 받기 시작했습니다. 그리고, 그것을 보고 많은 프로그래머가 AJAX로 코딩을 했지만, 생각처럼 만만치 않다는 것을 경험했습니다. AJAX로 아주 간단하지 않는 프로젝트를 마친다는 것은 매우매우 어려운 일입니다.

AJAX가 어려운 것은 라이브러리라는 것이 존재하지 않는다는데 있습니다. 프로그램이라는 것은 세월이 흘러가면서 어떤 기능에 최적화된 라이브러리가 제공되고, 그것을 클래스라고 하는 것으로 비지니스에 맞춰가면서 완성도를 높입니다. 하지만, AJAX는 최근 Google이 공개한 라이브러리 말고는 쓸만한 것을 찾기가 매우 힘듭니다. Google Maps가 나온지 꽤 오랜 세월이 흘렀지만, 다른 회사에서 구현한 AJAX는 한국에선 개인화 페이지 정도입니다. 그리고, 동일 기능이라면 플래쉬로 구현하는 것이 훨씬 수월할 때도 많습니다.

글에서 인용한 ThinkFree라는 웹기반 오피스는 자바 버추어 머신이라는 프로그램이 OS에 이식이 되어 있어야 쓸 수 있는 것으로(AJAX버젼은 간단한 워드프로세서 버젼에서만 작동됨), 이것은 액티브엑스를 쓰는 것과 별반 차이가 없습니다.

10. 브라우저의 한계를 넘어서라.

서비스로의 프로그램 개념은 오래전부터 나온 것이지만, 최대 소프트웨어 업체인 MS가 그동안 신경을 쓰지 않는 이유는 수익성이 없기 때문입니다. 그래서, 웹기반이던 설치형 기반이던 ASP라는 형식의 서비스를 시도한 기업이 꽤 있었습니다만, 아쉽게도 MS의 우려처럼 수익성의 악화로 현재까지 명맥을 이어온 기업은 소비자를 상대로 한 서비스가 아닌 컴퓨터 A/S 회사에 직접 방문하지 않아도 컴퓨터를 고칠 수 있는 아란타같은 회사의 원격조정 프로그램 정도입니다.

MS가 현재 이 서비스에 관심을 갖는 이유는 Google의 수익성을 본 것이지 그 이상도 이하도 아닙니다. 세계적으로 본다면 소프트웨어 시장보다는 광고 시장이 훨씬 큽니다. 그리고, Google은 웹에서만이 아닌 모든 콘텐츠 전송이 되는 디바이스나 책 같은 매체에도 광고를 전송하는 시스템을 구현하고 있습니다. 이 시장 때문에 MS가 Live.com을 제작하게 된 것입니다.(스티브 발머는 악담으로 유명하지만, 괜찮은 통찰력을 가지고 있는 사람입니다. 이 사람은 서비스에 있어서 수익이라는 것이 얼마나 중요한지 본능적으로 알고 있습니다.)

웹 2.0… 이것저것 갖다 붙인다고 새로운 개념이 나오는 것은 아닙니다.

Update.
위 글은 doyoung님의 글이 아니라 이정환님의 글입니다.

Update 2.
이 글에 대한 웹표준에 관한 글을 일모리님 블로그에 포스팅되었습니다.

더불어 nmind님의 블로그에 웹표준에 대한 오해의 글이 포스팅되었습니다.

이에 대한 답변이 어바웃 웹에 포스팅되었습니다.

Google은 기존의 시장을 파괴한다

철수네 소프트웨어 세상 3 인용:

데스크탑은 그 전략에서 사라지면 절대 안되는 퍼즐 조각이다. 구글의 사업이 집중을 하지 않고 문어발식으로 확장한다는 이야기도 위의 전략을 생각하면 틀린 이야기다. 분명 그들이 보고있는 산봉우리는 하나다. 구글이 하는 갸우뚱한 여러 사업들도 점차 이런 생각들로 설득력을 얻어가고 있는 상황이다. 물론 이런 전략의 부작용으로 지적되는 것이 이로 인해서 비슷한 웹애플리케이션을 만드는 회사들이 경쟁력을 잃고 죽어간다는 것을 들 수 있겠다.

Google의 사업은 광고를 빼면 전략, 전술 모두 없습니다. Google은 사업의 성공은 우연에 있다는 사실을 알고 있습니다. Adwords의 성공은 전적으로 우연인 것입니다.

IT사업의 특징은 고정비가 매우 크다는 것입니다. 즉, 문어발 확장을 한다고 해도 제조업 처럼 비용이 증가하는 것이 아니라는 이야기죠. MS가 문어발 확장을 할 수 밖에 없는 이유도 제품을 개발하던 그렇지 않던 인권비는 나가기 때문입니다. Google의 현재 직원은 이미 6000명을 넘어서고 있습니다. 현대 경영에 있어서 혁신은 회사 내에서는 불가능하기 때문에 많은 인원을 가지고 있다고 해도 소규모 기업의 인수 합병은 멈출 수가 없습니다. 장기적으로 Google도 더이상 인원을 늘릴 수 없게 될 때는 제휴를 하게 되겠지만, 현재 회사 내의 사정으로 문어발 확장을 할 수 밖에 없습니다. 또한, 확장을 할 수 밖에 없는 이유는 어떤 것이 미래의 주된 수익모델이 될지 알 수가 없다는 것입니다.

Google의 전략의 부재를 가장 잘 설명하는 것이 바로 20% 서비스라는 것입니다. 그리고, 많은 서비스들이 Google Product팀에서 나오는 것이 아니라 Google Labs에서 나오고 있습니다. 시험삼아서 만드는 것이 아니라 그것이 Google이라는 회사 시스템입니다. Google은 MS와 닮은 것이 아니라 3M이나 EDS, 비약하면 산업시장 보다는 자본시장에 가깝습니다.

자본시장은 그 특징이 자본의 이동이 매우 자유로우며, 실패한 기업은 살리려 노력하는 것 보다는 그 기업을 파괴하고 새로운 기업에서 이익을 냅니다. 즉, Google은 기업 내에 많은 서비스들을 소유하고 있으며, 그 서비스들이 사용자의 지지를 받으면 발전시켜 나갑니다. 현재까지 서비스 폐쇄라는 것은 나오지 않고 있지만, 미래에 반드시 Google 서비스 중에 많은 부분은 없어질 것입니다. 제 예상으로는 가장 처음 없어질 서비스가 Froogle입니다. Base가 나오면서 그 부분의 흡수 통합이 예상됩니다.

Google이 웹베이스 전문 기업일 수 밖에 없는 이유는 Google의 주수익원이 광고이기 때문이고, 광고는 데이터 자체에서 수익을 내는 것이 아니라 데이터의 흐름에서 수익을 내기 때문입니다. 그리고, 미래에 데이터에서 수익을 내는 것도 가능한데, 그것이 이미 Google Enterprise 제품군에 있고, Google이 가지고 있는 두가지 핵심 기술 즉 스토리지와 검색이 그 사업을 가능케 합니다.

MS의 인터넷 사업부인 MSN은 Google과 많은 부분에서 겹칩니다. 이 상황에서 Google과 MS가 공존한다라는 것은 설득력이 없습니다. MS가 지금처럼 성장하면서 많은 기업들을 파괴해 왔듯이 Google도 많은 기업을 파괴할 것이며, 미래에 MS의 시장을 파괴할 것입니다. Dell의 직판모델이 세계 제1의 제조회사 컴팩을 파괴한 예를 생각해 보면 허무맹랑한 이야기로만 들리지는 않을 것입니다.

작은 기업은 틈새시장을 찾지만, Google은 더이상 작은 기업이 아닙니다. 기존의 시장을 파괴하는 것만이 Google이 성장하는 길이며, 그 길 한복판에 MS가 있습니다. MS 스스로 오피스시장을 파괴하지 않으면 Google이 아니더라도 다른 기업에 의해 파괴당할 것은 피할 수 없을 것입니다.

한국 MP3P를 진단한다고?

킬크로그(killklog) 인용:

하지만 무엇보다 중요한 것은 이들 MP3P 시장의 공급사슬 중, 가장 중요한 소비 콘텐츠에 눈을 돌리는 업체가 없다는 점이다….

기기의 기능 개선과 가격 경쟁만으로 시장에서 살아날 수 없다. 콘텐츠가 답이다. 어서 빨리 MP3P에도 공급과 소비의 현명한 가치사슬이 만들어져야 한다. 콘텐츠를 사슬안에 넣어야만 MP3P는 살 수 있다.

소비 콘텐츠에 눈돌리는 업체가 없다는 말로 한국 MP3P 업체들에게 친절하게 살 길을 알려주고 있는 글입니다. 미안하지만, 이런 논의는 의미가 없습니다.

아이리버로 유명한 레인콤은 벌써 오래전 자사 웹사이트에 영어 강의를 유료로 서비스하고 있습니다. 또한, 펀케잌이라는 자회사를 만들어서 음원을 서비스하고 있지요.

레인콤이 MP3P로 성공할 때 부터 성공 모델은 APPLE이었습니다. 음원을 공급하고 디바이스도 공급해서 안정적인 수익기반을 잡자는 것이었는데, 결과는 아시다시피 상장했을때 벌어놓은 돈 다 까먹고 현재 마지막 퍼팅으로 지상파 DMB가 되는 PMP시장에 올인한 상태입니다. MS와 끈끈한 제휴관계로 인해 국내 언론에 가끔 보도되긴 하지만, 이미 80명을 정리해고한 상태입니다.

펀케잌은 이미 50억의 자본금 전부를 까먹은 상태이고, 레인콤의 지원으로 근근히 버티고 있는 실정입니다. 제대로 서비스를 못해서 그럴 수도 있다고 말하는 분들도 있을 듯 한데…

한국 디지털 음원시장은 5000억의 시장일 것이라고 “예측”되고 있지만, 웹사이트에서 MP3P로 전송되는 시장은 회사들이 전혀 공개하지 않고 있습니다. 아마도 휴대폰 벨소리나 컬러링 시장을 봤을 때 웹사이트에서 판매되는 음악 시장이래봤자 1000억도 안될 것 같고, 그나마 스트리밍으로 월정액으로 듣거나 미니홈피에서 배경음악으로 팔리는 시장까지 뺀다면… 과연 MP3P를 위해서 팔리는 시장이 있을까 합니다.

시장이 커지지 않는 이유는 여러가지 – 말도 안되는 과거의 소리바다 무료화 정책, 유료화를 외치는 기업에 아랑곳하지 않고 콧대만 높이는 저작권 및 인접권 관련 협회들, 시장이 형성될 수 없는 사회를 방치한 정부 – 가 있겠지만, 과연 레인콤이 정말 경영과 기술개발을 잘해 나갔다 할지라도 현재의 어려움을 피해갈 수 있을까요? 게다가 수익이 나던말던 삼성과 LG는 MP3P를 차세대 기기로 육성한다고 덤핑이나 처대고 있고…

한국 기업은 검증된 시스템은 이미 시도를 해 봤습니다. 바보가 아닌 다음에야 성공케이스를 벤치마킹하는 것에 게을리 할 이유가 없죠.

APPLE처럼 못하는 한국 MP3P 업체들을 욕하기 전에 조금이라도 그 회사들이 어떻게 운영했는지 조사해 보는 것도 의미있지 않을까 합니다.

엠파스의 코멘트는 항상 강하다

ETNEWS 전자신문 인용:

엠파스는 다음이나 야후 등 타 사이트의 지식검색는 제외하고 네이버의 검색결과만 중단한 것에 대해 “과거 사용자들의 니즈에 상당한 정확도를 갖고 있었던 네이버 지식IN이 최근 들어 불필요하거나 틀린 정보를 제공하는 사례가 많다고 판단했기 때문”이라고 밝혔다. 엠파스는 “최근에는 전문 게시판과 카페, 블로그 등 과거 지식이 했던 역할을 더 훌륭히 수행하고 있는 대안들이 많기 때문에 굳이 네이버 지식에 의존할 필요는 없다고 생각된다”고 강조했다.

네이버의 지식IN 서비스가 잘못된 정보 혹은 광고 글들이 많다는 것은 하루 이틀만의 일은 아닙니다. 그렇지만, 정말 많은 문답식 정보가 있기 때문에 몇번의 클릭만으로 대부분의 궁금증은 해결될 수 있죠.

그런데, 엠파스 열린검색에서 네이버 지식IN 검색을 중단하면서 위의 코멘트를 남겼는데, 그것이 좀 심하다 싶을 정도입니다.

원래 검색엔진이라는 것은 컨텐츠의 좋고 나쁨을 개인이 판단하지 않습니다. 개인이 판단하는 경우에는 불법적인 컨텐츠 예를 들어서 저작권 위반이나 성인물일 경우에 해당됩니다. 즉, 일단 모으고 어떤 알고리즘에 의해서 양질의 컨텐츠를 상위에 올리는 것이 검색엔진의 핵심 과제입니다.

위의 코멘트는 마치 지식IN을 우리가(엠파스) 믿을 수 없기 때문에 소스에서 제외한다는 식으로 들립니다. 역시 엠파스식 강력 코멘트군요.

여기에 대한 네이버의 코멘트는 1위 업체라 그런지 상당히 점잖습니다.

ETNEWS 전자신문 인용:

이에 대해 NHN(035420)이 운영하는 인터넷포털 네이버는 “그동안 언론을 통해 엠파스의 열린검색이 사용자 데이터베이스를 무단으로 가져가는 것에 대해 유감을 표명해왔고, 최근에도 정식으로 몇 차례 엠파스 측에 이 같은 뜻을 전했다”며 “이번 조치는 이에 따른 결과로 생각된다”고 밝혔다.

똑같은 사건인데도 양사의 코멘트는 전혀 별개의 것으로 보이는군요.

엠파스는 예전부터 약간 도발적인 광고 혹은 보도자료를 사용하고 있고, 그것이 엠파스만의 홍보방법입니다. 그렇지만, 타회사의 신뢰도를 문제삼는 것은 도의적으로 문제가 있지 않나 싶습니다.

코멘트는 그렇다 쳐도 엠파스가 추진하는 일처리 방법은 이해가 갑니다. 어여 힘내서 포탈 3위 달성이라는 대업을 이루어 주세요.

네이버의 수익구조가 불안하다고?

주로 주식에 관련된 업종이나 종사자가 이런 말을 하는 것 같네요. 다음은 아이뉴스24 기사 중의 일부입니다.

급성장하는 온라인 광고 시장에서 NHN의 지배력은 상당기간 유지될 것이지만, 검색과 게임 등 핵심서비스에만 집중하기에는 불안하기 때문이다.

NHN의 수익이 검색과 게임에서만 이루어져 불안하다면,

MS는 윈도우즈와 오피스에서만 수익이 나서 불안하나?
오라클은 DB만 팔아서 불안하나?
삼성은 DRAM과 휴대폰만 수익이 나서 불안하나?
AMD는 CPU에서만 수익이 나서 불안하나?
Google은 광고 수익만 있어서 불안하나?

사업을 다각화하면 다각화했다고 주가 떨어지고, 집중해서 고수익을 올리면 불안하다고 기사 쓰고…

현재의 핵심사업에만 매달리는 것은 향후 사업에 차질이 생길 수 있다는 것은 어느 사업에나 마찬가지. 하지만, 주가 측면에서만 본다면 연구개발비는 기본적으로 당해 비용처리 될텐데… 뭐, 장기적으로 자산으로 잡고 감가상각시킬 수도 있겠지만, 돈이 실제로 나간다는 사실은 변함없을테고…

다음 커뮤니케이션이나 NHN은 사실 최고로 잘하고 있다고 생각되지만, 기자들의 어이없는 추측기사로 위의 회사들이 바보 되는것 같아서 안타깝습니다.