일모리와 웹표준 블로그에 2005년 6월에 게시된 글입니다.
출처 : http://ilmol.com/wp/2005/06/09/25/

테이블(html의 table 을 칭함)은 이제 목적 이상의 일을 할 필요가 사라졌습니다. 그저 단순한 “표” 를 만들기 위해서 제작된 테이블이 레이아웃, 즉 홈페이지 틀을 잡기위해서 쓰이고 있다니. 그리고 그것이 테이블의 맞는 용도처럼 교육되고 있다니 이제는 슬슬 멈추어야 할때라고 봅니다. 특히 XHTML이 개발되어 나오면서 계층형과 같은 구조로 레이아웃은 디자인되며 디자인이 우선이 아닌 그 안의 내용의 구성을 먼저 생각해야하는 개념 자체의 변화가 찾아오고 있습니다. 아니, 예전 html 생성되었을때의 원래의 개념으로 돌리려고 하고 있습니다. 얼마전 XHTML 2.0(이 포스팅이 쓰여지는 현재는 XHTML 1.1) 이 개발되면서 약간의 내용을 볼수 있었습니다. 지금 쓰여지고 있는 모든 개념적인 html이 완전히 변화될듯 만들어 지고 있었습니다. 심지어 DIV만이 레이아웃의 용도가 아닌 SECTION 의 개념도 개발되어 가고 있었습니다. 이대로 가다가는 한국의 웹디자이너, 개발자들은 나중엔 너무나도 큰 공백을 매꾸어야 할 것입니다. 에플과 인텔이 손잡은 일도 그리하고 인터넷 익스플로러 만이 아닌 많은 ‘표준’ 브라우저들이 개발되어 나오면서 이제 한 방법만을, 그리고 한 부류의 소비자, 클라이언트를 겨냥하여 개발하는것은 몇년안에 ‘도박’ 으로 간주 될거 같습니다.

사용전에 개념의 문제

이 시점에서 본론으로 들어가기 전에 다루어야 할 문제가 있습니다. 제가 여러 한국 디자인 홈페이지를 만들어 보고, 보아 왔지만 한국에서 지향하거나 혹은 본의 아니게 지향되어 가고 있는 잘못된 개념이 있습니다. 바로 그 개념의 문제가 바뀌어야 하는데, 제가 잘 설명할수 있을지 모르겠군요.

최대한 말로 설명을 한다면, html은 디자인을 나타내는것이 아니라 문서를 유저들이 더 잘 볼수 있게 디자인 할수 있도록 만들어진 것이라는 겁니다. 문서의 개념이 디자인 보다 먼저 오는거 라는 거죠. 디자인이 먼저라면, 지금당장 html등을 버리고 플래쉬로 나가는게 더 나은 길일겁니다. 하지만 플래쉬가 그리도 멋지게 활용될수 있으며 여러가지 장점들이 있지만, 웹개발자, 클라이언트들에게 100% 다가가지 못하는 이유는 바로 이 ‘문서’ 의 개념을 잘 포옹하지 못하기 때문입니다. 웹페이지들의 궁극적인 목표는 바로 ‘책’ 처럼 되는 것이다 라고 하는데 이 목적을 채우기엔 역부족인거죠. 이전 html 에서도 그것을 잘 충족하지 못하고 오히려 역효과를 낸 것입니다. 해서 이번에 나오는 차기 XHTML은 문서의 개념을 더욱 투명하게 하고 인식을 바로 잡고 쓰기 위하는 목적으로 씌여지는거 같습니다.

문서의 요소로 예를 들어 보겠습니다. 보통 문서를 보면 서론 본론 결론으로 나뉩니다. 그 안에 제목, 문단, 단락 들이 있고, 여러가지 문서의 요소들이 있습니다. 바로 그 요소들을 html이 나타내고 싶은겁니다. 보통 볼수 있는 예로

는 바로 그 문단의 시작과 끝을 나타내어 주는것이고(처음 html 할때 젤 싫었던게 엔터치면 곧바로 에디터가 <p>로 인식을 하는거였네요. 무엇인지 모르니 짜증이 날수 밖에요 ^^) 이렇게 쓰이게 되면 html은 자동으로 알아서 문단이라고 인식해서 그에 맞추어 출력을 해주게 됩니다.(이런 개념을 잘 이해해서 디자인을 하면 <br>(웹표준에서는 <br /> 이 맞습니다)은 거의 쓰지 않게 됩니다 ^^)

이렇게 html의 속성들의 개념을 이해해 가다보면 문서의 틀을 잡아주는것에 대한것, 즉 레이아웃에 대한 속성들도 다루게 되는데 바로 그 문서의 표현을 도와 문단의 너비, 문단의 위치, 모양을 잡아주는 것이 바로 테이블 입니다. DIV 입니다. P(Paragraph, 문단의 첫글자) 속성도 있구요. 아무튼 다시한번 말합니다. 문서의 레이아웃을 돕는 html 속성은 DIV 입니다. ^^ DIVISION의 줄임말로 나누다 라는 뜻을 가진 div 인것이죠. 테이블로 레이아웃 사용은 문법 자체가 틀린것이라는 겁니다.

위의 긴 글을 정리하면서 다시 말하자면, html의 개념이 바르게 인식이 되어 가는데엔 테이블, 단순히 표를 만드는데 쓰인다는 원래의 목적을 찾아주고 레이아웃은 그에 맞는 속성을 쓰는것이 꼭 다루어져야 한다는 것입니다. 단순히 “DIV가 다루기 쉽잖아요” 가 이유가 아닌(실제로도 테이블보다 훨씬 쉽지만) 목적과 개념 자체에서부터 문제가 된다는 것입니다. 아직 뜨끔 안하셨나요? 이제 슬슬 개념뿐만이 아닌 왜 DIV가 테이블보다 나은지 다루어 보겠습니다.

table 보다 다루기가 쉽다

솔직히 예전에는 테이블이 웹페이지 레이아웃, 틀을 잡는데에 쓰일수 밖에 없었습니다. 그만한 틀을 잡아주는 속성이 약했기 때문입니다. 그리고 그 당시에는 그것이 더 편했고, 깔끔했습니다. 규격이 맞지 않아서 줄이고 늘리고 하는것이 더 문제 였으니까요. 하지만 DIV는 레이아웃을 위한 그 목적으로 씌여진 만큼, 그보다 더 다루기 쉽게, 간편하게 발전 되었습니다. 말도 안된다구요?

보통의 홈페이지 레이아웃으로 예를 들어가면서 보겠습니다.

이런 레이아웃을 만들어 보겠습니다.

1. 테이블은

   <table>
     <tr>
       <td></td>
     </tr>
     <tr>
       <td></td>
       <td></td>
      </tr>
    </table>

   이렇게 코딩을 합니다. div를 보겠습니다.

   <div></div>
    <div style="float: left;"></div>
    <div></div>

   별로 차이 안나네요.

2. 그럼 이것에 column 을 2개 더 넣어보겠습니다.

   <table>
     <tr>
       <td colspan=4></td>
     </tr>
     <tr>
       <td></td>
       <td></td>
       <td></td>
       <td></td>
     </tr>
   </table>

   은

   <div></div>
   <div style="float:left;"></div>
   <div style="float:left;"></div>
   <div style="float:left;"></div>
   <div style="float:left;"></div>

   또 약간 비슷합니다.여기서
   이렇게 만들어 볼까요?

3. 그렇다면 이제 슬슬 테이블은 복잡해 집니다.

   <table>
     <tr>
       <td colspan=4></td>
     </tr>
     <tr>
       <td></td>
       <td></td>
       <td></td>
       <td></td>
     </tr>
     <tr>
       <td colspan=4></td>
     </tr>
     <tr>
       <td colspan=4></td>
     </tr>
     <tr>
       <td colspan=4></td>
     </tr>
     <tr>
       <td colspan=4></td>
     </tr>
   </table>

   div를 보겠습니다.

   <div></div>
   <div style="float:left;"></div>
   <div style="float:left;"></div>
   <div style="float:left;"></div>
   <div style="float:left;"></div>
   <div style="clear:both;"></div>
   <div></div>
   <div></div>
   <div></div>

   div는 간단히 끝이 났네요.

클라이언트가 위의 구성중 column이 많다고 빼달라고 요청합니다. 하나를 빼면,,
테이블로 구성한 코드는 저 위의 4라고 써진거 다 3으로 바꾸어야겠죠. 네. ‘찾기’ 기능을 아주 잘 써야겠습니다. 하지만 div는 어떤가요? float:left 는 align:left 와 같습니다. 왼쪽으로 정렬된것들 마구 넣은 후에 빼고 싶은거 빼고나서 다시 정리된 한칸을 넣을때엔 align 이 적용 안되도록 clear:both; 만 넣으면 됩니다. 개발자 분들, 너무나도 차이나는게 보이시는지요?

테이블은 느리다

다른 이유를 보겠습니다. 너무나도 잘 아는 사실이죠. 테이블의 속도 문제도 꽤나 골치 아픈 문제 입니다.

유저들은 아마도 브라우저창 타이틀 부분에는 웹사이트 제목이 떴는데 하얀 바탕으로 아무것도 나오지 않는 경우를 겪어 봤습니다. 요즘이야 워낙에 속도가 빨라지긴 했지만… 그 이유는 테이블의 속도 문제가 있기 때문입니다. 각각의 테이블이 하나하나의 요소로 받아들이기 때문에 그 테이블이 다 읽히기 전까지는 화면에 읽히지 않습니다. 그 이유 때문에 제목창에는 제목이 뜨는데 화면에는 아무것도 들어오지 않는것처럼 보이는 것이죠. 특히 커다란 포털사이트에 이런 경우가 많습니다. 기다림 후에 나타나는 화면은 이미 로딩이 거의 끝난 상태로 나타나게 되죠. 그와 반대로 div를 사용하게 되면, 틀을 잡아주는 것이기에 틀에 잡힌 텍스틀이 이미 뜬 후에 배경이라던지 이미지가 읽혀지게 됩니다. 유저들에겐 기다림의 지루함이 조금이나마 줄어들게 되는 것입니다. 그러므로 속도의 차이는 없는듯 커다랗게 나는것입니다. 예전 야심만만 이라는 프로그램에서 ‘당신에게 가장 긴 1분은 언제였나?’ 라는 질문에 웹사이트가 로딩되는 그 1분이 길었다 라는 대답이 상당히 많았던 것만 봐도 그 ‘약간’ 의 차이가 유저들에게는 얼마나 큰것인지를 알수 있습니다. 구글의 성공에도 1개의 이미지로 승부하는 속도가 커다란 몫을 했었죠.

table은 유지하기 힘들다

속도 뿐만이 아닙니다. 어찌 유지 하렵니까?
속도는 인터넷을 더 빨리 돌려버리면 된다고 해도, ‘유지’ 의 문제는 어쩔수 없습니다. 상상만 해도 울컥 솟아 오릅니다. 테이블 안에 수도 없이 이루어진 그 얽히고 얽힌 그 문제를 어떻게 유지를 할수 있을지. 새 웹마스터가 와서 웹사이트를 유지하려해도 이해할수 없는 수 많은 테이블의 tr, td 들을 그리고 그 안에 들어있는 테이블들을 어떻게 이해를 해서 하는지. 아직도 하고 계신분들에게 경의를 표합니다. 이럴때에 가끔은 프리렌서가 좋다는 생각을 합니다. 이 말도 안되는 것들만 보아도 왜 이렇게 되어야 하는지 궁금할 뿐입니다. div도 사이트가 클수록 유지하기에 복잡하지 않냐 라는 반문을 하신다면 div를 써보지 않으신 분들입니다. 각각의 레이아웃 div에는 이름을 주어서 CSS로 간단히 조절이 가능하기에 각각의 이름들만 알아도 새로운 CSS를 써버려서 내용은 그대로이되 모든 디자인이 바뀌어 버리는 놀라운 일을 할수가 있습니다. ‘스킨’ 의 개념이 보통의 html문서에서 이용되는 것입니다. 이에대해 아시는 분들은 아시지만 젠가든 이라는 곳이 그 예들을 보여줍니다. 내용은 같지만 수많은 유저들이 자신들의 CSS를 제출해 뽑히면 그 사이트의 디자인CSS 파일만을 바꾸어 보여줌으로써 확연히 다른 사이트로 변모하는것을 보면 확실히 이해가 가실겁니다.

CSS3?

이제 곧 나오게 될 CSS3를 살펴보니 레이어들 사이에도 이제 x, y 좌우의 위치 뿐만이 아닌 진정한 케스케이딩, 차곡차곡 쌓인 문서들 처럼 앞, 뒤 의 z 위치를 정할수 있게 되어 있습니다. 아무리 테이블이 레이아웃에 좋다고 우겨도 CSS3가 출시되는 날 부터는 ‘바보’로 취급받게 될것입니다. 투명한 PNG의 사용도 가능케 했으니, 그림자 div 위에 문서 1 div을 놓고, 그 위에 문서 2 div 를 놓고 겹치게 해 놓았다고 생각해 보십시오. 그리고 다음 페이지로 넘어갈때엔 그저 CSS의 Z 속성만 바꾸어 주면 순간에 문서 1이 2의 위에 올라가게 되니, 이거 언제 css3이 출시되나 기다려 지지 않을수가 없습니다.

table은 이제 쉬어야 할때

테이블은 이제 슬슬 좀 쉬어야 할때 입니다. 너무 큰일을 감당케 했습니다. 반대로 원래 그 일을 해야할 div를 너무 놀게했습니다. 위에서 주욱 길게 설명을 했듯이 테이블의 노동착취는 그만하시고 공평한 일자리를 주어야 할 때가 아닐까 생각합니다. 아니 그래야 합니다. 그것이 미래를, 앞을 바라보는 선경지명이겠습니다.

약간은 죄송한 마음이 없잖아 있습니다.
지난번 웹표준 잘못된 문구 에서 “CSS 기반 이라기 보다는 XHTML 기반 이라고 하는게 더 맞다” 라고 하면서 실제적으로 XHTML 에 관한것들이 있지 않아서 “먼소리데?” 라고 하셨으리라 생각됩니다. 오늘도 일하던중에 한번 대충 XHTML 기초 서론 포스팅을 올리겠습니다. 이 서론 포스팅은 약간은 제가 예전에 썼던 “테이블은 이제 그만 쉬어야 할때” 의 후속편으로 보셔도 되겠네요. 이미 많은 분들께서 아시고 계시는 부분이긴 합니다만, 아시는 부분은 복습으로 생각하시기 바랍니다.

일단, 여러곳에서 웹표준 이라는 단어가 부각되면서 테이블보다는 div가 더 편하고 효율성이 높기때문에 쓰고싶으면 쓰라 라는 논쟁도 있고, 도대체 표준의 기준이 어디에서 나와서 대부분이 쓰는 IE를 무시하느냐 라는 논쟁등, 새로운 물결에 대해 혼란스러워 하시거나 거부하시거나 하시는 분들이 아직 많이 계십니다. 대충 기원부터 주욱 큰 그림을 본다면 약간은 도움이 되지 않을까 하네요.

지금 W3C 을 이끌고 있는 Tim Berners-Lee 씨가 처음 SGML 기반으로 html 을 시작했을때에는 서로간의 문서교환이 목적이었습니다. <h1> 은 헤더이고, body는 본문이고 등등의 ‘구조(Structure)’ 와 ‘시멘틱(Sementic)’ 중심의 목적이었습니다만(via Accessible XHTML and CSS Web Sites), 점차 변해갔습니다. html 3.2 html 4 등으로 발전해 가면서 디자인또한 부각이 된 것이죠. 즉 ‘프레젠테이션’과 ‘스타일’로 바뀌어 간 것입니다. <center> 나 <font>, bgcolor 등이 삽입이 되고 그에 따라 많은것들이 순식간에 변해갔습니다. 지금 전세계에서 대부분 사용하고 있는것이 바로 그것입니다. 그리고, 한창 웹에서는 디자인들이 꽃을 피울때 즈음에 SGML을 단순화한 XML 이 나오게 되었습니다. 어제 후니님과의 토론에서 잘 이야기 해 주셨는데 더욱 데이터로써 여러 시스템들 간의 상호교환에 원활한 언어를 개발하게 된 것이죠. 그리고 W3C 에서는 html의 발전에 더이상 기대하지 않았고 다시 원래의 목적으로 돌아가되 스타일과의 문서의 분리로써 들어가는 부분을 충족시키는 XML과 접목된 XHTML 이 탄생하게 되었습니다. 최근은 아닙니다 그때가 1999년이니까요. 이렇게 W3C에서 CSS 채택과 함께 XHTML 의 사용은 문서는 문서대로, 혹은 후니님께서 언급하셨듯이 데이터는 데이터대로, 그리고 프레젠테이션, 혹은 디자인은은 디자인데로의 분리가 가능케해버렸고, 알게모르게 X 를 달고나온 html 의 변신은 새로운 바람을 일으킨 것입니다. 바로 이것이 일모리가 말하는 웹표준 안으로 뛰어 들기의 핵심 이네요. 이제 이 분리는 너무나 많은 이득을 앞세워 커나가고 있습니다. 웹표준 권고안을 떠나서 보더래도 단순히 이 둘이 분리되었다는건 엄청난 이득을 뜻합니다. 접근성, 사용성,데이터 처리등에서 우월해지며, 사이트관리, 감소된 코딩량 등등의 잇점또한 제공해 줍니다. 뭐니뭐니해도, 문서는 문서대로, 디자인은 디자인데로 놀수 있다는거 참 즐겁고행복한 변화이죠. ^^;

엑세시빌리티 Accessibility 라고 하는 접근성은 시각장애자나 특별히 디자인 보다는 내용을 이해코자 하는 이들에게 조금더 친근감있게 다가갈수 있으며, 유저가 원하는데로 디자인의 변화도 가능하며 가독성을 높이기 위해 글자크기의 변화를 준다던지 각각의 시스템에 맞추어 출력하도록 디자인을 설정하며, 사용성은 간결한 코딩과 테이블이 취약했던 로딩의 문제의 개선등으로 빨라진 페이지 사용, 데이터 처리는 구조화에 따른 검색엔진에의 높은 검색률과 함께 홍보, 사이트관리의 효율성은 단순히 디자인만 바꾸어 줌으로해서 내용이 바뀌지 않는 새로운 디자인이나 뉴스, 형식을 출력가능한 여러 잇점들이 따르게 됩니다. 일일히 각각의 잇점의 예를 들지는 않겠지만, 해외 대형사이트들의 XHTML 변화는 여러 멋진 성공 사례들을 보여주고 있다는 말씀은 해드리고 싶네요.

이러한 잇점들을 보면서 W3C 에서 원했던 문서에서 디자인의 추출은 상당히 많은 부분 요즘 한창 일어나고 있는 논쟁들을 잠잠케 합니다. DIV가 TABLE 대신에 쓰는것 뿐 이라는 공식이 아닌 TABLE 은 문서의 한 부분, 이라는 시각으로 바라보게 되니 당연히 디자인으로 쓰일수 없는 것이며 쓰이게 될때에 수많은 장점들을 버리게 되는 것이니, 자연스럽게 테이블을 쉬게 하는것입니다. 그리고, 대부분이 IE 를 쓰고 있는데 왜 IE 에게 화살표를 쏘느냐 라는 질문에는, 저러한 장점들을 살려주지 못하는 브라우저 이기 때문이라고 자신있게 말할수 있기에 그렇다는 겁니다. (그래서 서둘러서 계획에도 없던 IE7의 개발을 마소가 시작했을지도 모르죠) 물론 그 브라우저에만 의존하는 코딩과 기획들이 더 슬프게 하는 요소들이지만 말입니다. 대부분이 표준을 쓰지 않는데 표준이 무슨 의미냐라고 하는 분들도 계시는데, 단순히 표준은 저러한 장점들을 잡아주는 푯대로써 앞으로도 그러할것이고, 원하던 그 반대이건 밀고 들어올 바람임을 잘 의식하신다면 그리 슬픈 시각만이 아닐꺼라 생각이 됩니다. 장애인들에게 더욱높은 접근성을 주며, $$ 절약해주고, 시간절약, 코딩절약을 해준다는데 왜 마다할지는 저도 모르겠습니다.

문서와 프레젠테이션의 분리, 그것은 앞으로 XHTML 의 더욱 세밀하게 분할되어가는데에 있어서 중요한 역할을 할 것입니다. 물론 그만큼 더 CSS도 정교해 지겠네요. 그리고 정교한 만큼 그것을 나타내는데에 브라우저들간의 격차들도 많이 줄어들겠군요. 할수 있는것도 많아지구요. html 이라 하지않고 HTM 이라고만 불렸던 단순함을 벗어버릴 기회이겠습니다. 그리고 그것에대한 인식도 점점 바뀌어 가고, 스터디 그룹들도 많이 생겨야 한다고 생각하네요.

음…

이렇게 장황하게 XHTML 을 시작했습니다. 전에 CSS 기반이라고 하기보다는 XHTML 기반이라고 하라던 그 말을 이제서야 보충할 자리가 마련이 됬을런지 모르겠네요.

일단, Berners-Lee씨의 초기 목적인 구조와 의미를 살리는 예제부터 보고 싶습니다.

의 안은 이렇습니다.

보시다시피 빨간색으로 표기가 되어있습니다. 첫번째 글을 보면서 두번째 빨간색이 그려진 글이 머리속에 그려져야 하겠죠.

• <h1> 은 heading 으로 제목을 나타냅니다. <h1> 이 가장 크고 <h6>가 가장 작습니다. 적절하게 제목 소제목 등을 나누어서 잘 쓰시면 되겠죠. 대신 이 heading 은 <p> 블록 안에 들어가지 않습니다. 마지막은 꼭 닫아줍니다.
  예) <h2> 제목입니다</h2>
• <p> 는 문단으로 </p> 와 같이 쓰입니다.
• <blockquote>은 긴 인용문을 쓸때에 써줍니다. 간단히 문장안에 넣을때는 <q> 를 써줍니다
• <li> 는 리스트들을 나타냅니다. 그냥 순서없는 리스트이냐(<ul>) 혹은 순서대로 나열되는 리스트냐(<ol>) 이냐에 따라서 그 리스트 <li> 를 감싸는것들을 골라씁니다. 그냥 순서없는 <ul> 와 </ul> 사이에 넣고, 순서가 있을경우 <ol> 와 </ol> 안에 넣습니다.
  예) <ul>
  <li> 컴퓨터</li>
  <li>키보드</li>
  </ul>

  그리고 순서있는 것은
  <ol>
  <li> 첫번째 영화 오즈의 마법사</li>
  <li>두번째 영화 이상한 나라의 엘리스</li>
  </ol>

일단 이 정도 안에서도 많은 부분을 써나갈수 있습니다. 계속 XHTML 부분을 올리기로 하지요.