테이블(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는 레이아웃을 위한 그 목적으로 씌여진 만큼, 그보다 더 다루기 쉽게, 간편하게 발전 되었습니다. 말도 안된다구요?
클라이언트가 위의 구성중 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를 너무 놀게했습니다. 위에서 주욱 길게 설명을 했듯이 테이블의 노동착취는 그만하시고 공평한 일자리를 주어야 할 때가 아닐까 생각합니다. 아니 그래야 합니다. 그것이 미래를, 앞을 바라보는 선경지명이겠습니다.