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

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

다음 블로그, script태그와 embed태그 가능

언제부터 된 건지는 모르겠지만, 다음 블로그에 script태그와 embed태그가 HTML 모드에서 쓸 수 있군요. iframe태그는 아직 사용가능하지 않습니다.

따라서, 다음 블로그에 Google AdSenseGoogle Video 혹은 YouTube의 동영상을 넣을 수가 있게 되었네요.

테스트 해 본 결과로는 iframe 태그는 막혀있습니다. 블로그 도움말을 참조해 봤는데, 태그부분의 글이 원래 없었는지는 몰라도 관련 글이 없다고 나오더군요.

업데이트 때 실수로 빠진 것인지, 아니면 원래 쓸 수 있었던 것인지는 알 수 없네요. 초창기 런칭했을 당시에는 안되었던 것 같은데, 제가 오해를 했던 것일 수도 있고…

올블로그가 삭제된 DB 복구를 도와준다

서비스하고 있는 웹사이트가 어떤 이유에서건 모두 날라갔다면 가장 빨리 복구하는 방법은 역시 Google의 캐쉬를 이용하는 것입니다. 제가 컨설팅을 해주는 웹사이트인 김영우 나이트댄스의 하드가 복구불능상태가 되었을 때 그런 방법을 써본 적이 있는데 크지 않은 웹사이트라서 그런지 정확히 3일만에 복구한 적이 있습니다. 물론 회원 DB같은 것은 복구를 못했지만, 이정도만으로도 많은 도움이 되더군요.

ez2web.com의 뉴크님은 그 방법을 자세히 소개해주었는데, 공교롭게도 올블로그의 CEO인 하늘님의 코멘트가 눈에 띱니다.

ez2web 인용:

# 하늘이 2006.06.04 EDIT
올블로그에 가입하신지 오래되셨고, RSS가 전문공개였다면, 올블로그를 통해서도 찾으실 수 있습니다. 🙂 도움센터로 문의주시면 도와드리고 있어요.

만약 날라간 웹사이트가 블로그라면 스킨은 Google 캐쉬로 복구하고 DB는 올블로그에 부탁하는 것도 좋은 방법일 듯 합니다.

이런 식으로 상상하면, 올블로그에 쌓인 자료를 이용해서 여러가지 블로그 툴로 변환파일을 만들어 주는 것도 좋은 서비스가 될 것 같네요. 특히 기업 블로그일 경우 상용으로도 손색이 없어보입니다.

robots.txt 지켜야 되는 것인가 말아도 되는 것인가

유행이 지난 이야기지만 구글과 네이버를 적대적 관계로 볼 때 자주 나오는 이야기가 robots.txt을 이용해서 외부 검색을 못하게 하기 때문에 구글이 한국에서 힘이 없는 것이다 라는 말입니다. 그 내용을 아는 개발자가 IT관계자들도 robots.txt를 지켜도 그만 안지키면 어쩔 수 없는 것으로 생각을 하고 있습니다.
그 내용을 다른 각도에서 보도록 할 필요도 있습니다.

일반적으로 저작물의 복제행위는 특별한 저작권표시가 없으면 하면 안되는 행위입니다. 음악이나 영화와 마찬가지로 자신이 만든 컨텐츠는 설사 인터넷에 올렸다 손 치더라도 남이 복제를 하면 안되는 것이죠. 그것은 마우스로 긁어가는 것과 프로그램이 긁어가는 것의 차이는 전혀 없습니다. 둘 다 안됩니다. 상업적으로 쓰건 그렇지 않건간에 복제하는 행위 자체는 엄연히 불법입니다.

그럼 생각해 보도록 하죠. 네이버나 구글의 크롤링이라고 하는 다시 말하면 웹사이트들의 페이지들을 긁어가는 행위는 명백한 저작권침해가 됩니다. 설사 검색결과에서 관련된 문장 세줄정도만 보여준다고 해도 서버에는 모든 페이지들이 저장되어 있기 때문에 복사 자체가 불가능하다는 뜻 되겠습니다.

쉽게 말하자면 이렇습니다. 얼마전부터 한창 문제가 되는 노래 저작권과 저작인접권에 관한 문제를 문화관광부의 답변을 토대로 말하자면, 복제불가능하게 비상업적으로 듣는다 하더라도 하드디스크에 노래를 복제하는 행위 자체가 불법이 되기 때문에 어떤 형태로건 서비스를 할 때에는 저작권자와 인접권자의 허락을 받게 되어 있습니다. 그것은 웹사이트에도 동일하게 적용됩니다. 즉, 내가 쓴 글을 검색회사들이 가져갈 권리는 내가 따로 검색회사들에게 주어야 한다는 것입니다. 그 통로가 바로 robots.txt라는 것이죠.

저작권자는 자신의 웹사이트에 robots.txt를 만들어 놓음으로서 다른 회사들이 복제하지 못하게 할 수 있습니다. 그렇기 때문에 검색회사들이 복제를 해서 검색서비스를 일반인에게 제공하는 것이 법적으로 가능하게 되는 것입니다.

얼마전 엠파스에서 열린검색이라는 서비스를 오픈했습니다. 과감하게 robots.txt도 무시한채 네이버의 지식인과 열린게시판이라고 해서 유명한 포럼들의 글을 복제해서 검색서비스를 하고 있습니다. 참으로 위험하기 짝이 없는 서비스임에도 불구하고 누구도 이의를 제기하지 않고 있습니다.

확실한 것은 남의 저작물을 이용하는 데 있어서 저작권자의 허락을 받는 것은 저작자가 할 일이 아니라 이용하는 자가 할 일이라는 것입니다. 그 것이 인터넷에서만 특별하게 저작권자가 robots.txt라는 것을 이용해서 거부의사를 밝히는 것이죠. 만약 모든 회사들이 robots.txt라는 것을 지키지 않고 모든 웹사이트들의 컨텐츠 복제를 시도한다면 인터넷에서 검색서비스는 할 수 없게 됩니다.

저작권 보호를 위한다면 인터넷에 올리지 않으면 되는 것이 아니냐? 라고 이야기 할 수도 있겠지만, 현행 저작권법하에서는 위에도 말한 바와 같이 그것은 글을 올린 사람이 해결해야 할 문제가 아니라 사용하는 쪽이 해결해야 할 문제입니다.

한국의 법원은 아직까지 징벌적 배상 판결을 내리지 않기 때문에 만약 비상업적으로 저작물을 사용할 때 보통은 상업적으로 이용했을 경우를 예로 들어 사용비만을 배상하라는 판결을 합니다. 하지만, 검색서비스는 확실히 상업서비스입니다. 엄청난 광고가 나오는 페이지들이 비상업이라고 말할 수는 없겠지요.

robots.txt이라는 간단한 룰이 그냥 생긴 것이 아닙니다. 그 것을 지키지 않은 엠파스도 지켜도 그만 안지켜도 그만인 것은 더더욱 아닙니다. 인터넷에서 검색서비스는 네티즌들의 암묵적인 합의가 있었기에 가능한 것이죠. 네티즌들이 거부할 수 있는 단 한개의 권리를 지켜주지 않는다면 악의적인 사용자에 의한 소송을 피할 길이 없게 되고 현재의 음원서비스처럼 닭싸움이 될 가능성도 있습니다.

웹사이트에 동영상 삽입하기

웹사이트에 동영상을 올리는 방법은 매우 간단합니다. 문제가 되는 것은 동영상 파일이 인터넷에 연결된 어떤 서버에 업로드 되어 있어야 한다는 점입니다.

일반적으로 인터넷 공간을 이용하기 위해서는 돈을 지불해야 합니다. 무료로 공간을 제공하는 업체가 있지만, 동영상을 올릴 정도의 공간은 만들어 주지 않고, 설사 공간을 제공한다고 해도 자신의 웹사이트에 올리지 못하게 하는 경우도 많습니다.

미국의 경우는 동영상만을 전문으로 업로드하고 사용자 웹사이트에서 소개할 수 있는 서비스가 여럿 존재합니다. 그 서비스들은 대부분 무료이며, 전문적인 서비스를 할 때만 돈을 지불하게 됩니다.

구글비디오 이용하기

동영상을 서버에 올리고 손쉽게 이용할 수 있는 사이트가 바로 구글비디오입니다. 구글비디오는 파일을 구글서버에 올리기만 하면 개인 웹사이트나 블로그에서 그 동영상을 보여줄 수 있는 코드를 제공해 줍니다.

이 방법에 대해서 자세히 알고 싶으신 분은 “구글비디오를 이용해서 블로그에 동영상 넣기“를 참조하세요.

개인 서버 이용하기

개인적으로 소유한 또는 빌린 서버를 이용할 수 있는 분은 그 곳에 동영상 파일을 올려 주소를 일정한 형식에 맞춰서 글에 첨부하기만 하면 됩니다.

아래의 코드는 마이크로소프트에서 제공하는 파이어폭스와 익스플로러 동시에 지원되는 코드입니다. “주소”라고 쓰여진 곳을 동영상 주소로 바꾸어 넣어보세요.

<OBJECT ID="MediaPlayer1" width=176 height=144
classid="CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95"
CODEBASE="http://activex.microsoft.com/activex/controls/mplayer/en/nsmp2inf.cab#Version=6,4,5,715"
standby="Loading Microsoft® Windows® Media Player components..."
type="application/x-oleobject">
<PARAM NAME="AutoStart" VALUE="True">
<PARAM NAME="FileName" VALUE="주소">
<PARAM NAME="ShowControls" VALUE="False">
<PARAM NAME="ShowStatusBar" VALUE="False">
<EMBED type="application/x-mplayer2"
pluginspage="http://www.microsoft.com/Windows/MediaPlayer/"
src="주소" mce_src="주소"
name="MediaPlayer1"
width=176
height=144
autostart=1
showcontrols=0>
</EMBED>
</OBJECT>
<a href="http://servername/path/your-file.asx" mce_href="http://servername/path/your-file.asx">Start the streaming media presentation in the stand-alone Player.</a>

검색엔진들의 도메인 관리는 누구누구?

절대 끊기면 안되는 사이트인 검색엔진들의 도메인 관리 회사는 어디인가? 한번쯤은 궁금해 할 만한 것이지만, 일일히 알아보기에는 무척이나 귀찮을 것입니다.
자, 한번 알아볼까요?

구글닷컴(google.com)

구글의 도메인 관리 회사는 MarkMonitor.com 입니다. 마크모니터라는 회사는 도메인 등록만을 하는 기업이 아니라, 온라인 상의 브랜드 관리, 웹사이트를 이용한 사기 방지 등도 같이 제공합니다.

Created on…………..: 1997-Sep-15.
Expires on…………..: 2011-Sep-14.
Record last updated on..: 2005-Jul-25 20:14:20.
NS3.GOOGLE.COM
NS4.GOOGLE.COM
NS1.GOOGLE.COM
NS2.GOOGLE.COM

구글 코알(google.co.kr)

구글 한국도메인은 후이즈에서 등록했군요. 2006년 7월 28일이 사용종료일입니다. 눈뜨고 기다려보는 것도 재밌겠군요 🙂

등록일 : 1999. 07. 28.
최근 정보 변경일 : 2005. 01. 18.
사용 종료일 : 2006. 07. 28.
1차 네임서버 정보 : ns.google.com
2차 네임서버 정보 : hedns1.google.com

야후닷컴(yahoo.com)

야후닷컴도 구글과 마찬가지로 마크모니터에서 관리합니다.

Created on…………..: 1995-Jan-18.
Expires on…………..: 2012-Jan-19.
Record last updated on..: 2005-Aug-11 15:05:12.
NS4.YAHOO.COM
NS5.YAHOO.COM
NS1.YAHOO.COM
NS2.YAHOO.COM
NS3.YAHOO.COM

야후 코알(yahoo.co.kr)

역시 구글코알과 마찬가지로 후이즈군요. 역시 2006년 10월 15일까지입니다. 🙂

Registered Date : 1997. 06. 04.
Last updated Date : 2004. 12. 23.
Expiration Date : 2006. 10. 15.
Host Name : ns1.yahoo.com
Host Name : ns5.yahoo.com
Host Name : ns3.yahoo.com
Host Name : ns4.yahoo.com
Host Name : ns6.yahoo.com

다음 커뮤니케이션(daum.net)

다음의 도메인은 넷피아에서 관리를 하는군요. 이상한 것은 넷피아 공식 홈페이지에는 도메인 서비스가 나와있지 않군요.

Record created on……..: 05-Mar-1996 EDT.
Record expires on……..: 06-Mar-2006 EDT.
Record last updated on…: 22-Jul-2005 EDT.
NS.DAUM.NET
NS2.DAUM.NET
NS3.DAUM.NET
NS4.DAUM.NET 211.115.116.251
NS5.DAUM.NET 211.172.253.240

NHN(naver.com)

네이버로 알려진 NHN의 도메인관리는 역사와 전통의 가비아군요.

Record created on SEPTEMBER 12, 1997
Record expires on SEPTEMBER 11, 2013
Record last updated on JULY 23, 2004
NS2.NAVER.COM
NS1.NAVER.COM

엠파스(empas.com)

엠파스도 마찬가지로 가비아입니다. 엠파스는 예전 사명이 지식발전소라서 그런지 네임서버가 nis.kppn.com인데, 사명이 바뀌고 회사 공식 웹사이트도 바뀌었는데 네임서버는 만지지 않고 있군요. 불안해서 그런지… 🙂

Record created on APRIL 26, 1999
Record expires on APRIL 26, 2008
Record last updated on MARCH 26, 2004
NIS.KPPN.COM
NIS.KPPINC.COM

재미있는 사실은 많은 회사가 네임서버를 다섯대를 운영하는데 반해서 네이버와 엠파스는 두개만을 운영하고 있네요. 확률적으로 두대 전부 망가지는 경우는 없겠지만, 회사 철학과 관련이 있을 듯 하군요.

네임서버에 대해서는 다음에 다뤄보도록 하겠습니다. 재미있을 것 같지만… =3=3=3