환영합니다!

HTML은 구조적인 문서를 만든다.

HTML과 콘텐트

웹이 정보의 공유를 원활하게 하기 위해 만들어졌다는 점 때문에, HTML을 비롯하여 웹 브라우저에서 구동되는 마크업 언어들은 기본적으로 텍스트 포맷으로 작성된다. 이는 MS Word나 한글 파일과 같은 바이너리 형식과는 달리 대단히 개방적이기 때문에 어떤 플랫폼이나 프로그램에서도 읽어들이기 쉽다는 장점을 갖고 있다. 물론, 브라우저라는 해석기가 이 HTML 파일을 좀 더 보기 좋게 담아주기는 하지만, HTML 파일은 기본적으로 간단한 텍스트 편집기 만으로도 그 내용을 읽어낼 수 있다는 뜻이다.

웹 사이트에서 콘텐트란 말 그대로 페이지에 담아야할 내용이다. 이는 문서 형태를 정하는 서식이나 문서에 관한 정보를 말하는 것이 아니라, 사용자에게 전달되어야할 내용 그 자체를 말하는 것이다. 이러한 콘텐트의 형식에는 텍스트나 이미지 등이 있으며 이를 좀 더 세분화하면 일반 텍스트와 표, 이미지, 멀티미디어 등이 있겠다.

HTML 문서는 이런 콘텐트를 좀 더 구조적으로 작성할 수 있도록 만들어진 언어인 것이다. 따라서 콘텐트를 직접 담는 부분(Body)이 아닌 곳에서는 문서 자체에 대한 정보나, 콘텐트의 서식에 관한 것들을 지정할 수 있도록 만들어져있다. 똑같은 문서를 작성하는 도구지만 HTML이 MS Word와 다른 이유는 파일 포맷만이 아니라, 그것이 포함하는 정보의 내용이 다르기 때문이다.

Word와 같은 워드프로세서 프로그램들은 일반적으로 콘텐트만이 아니라 콘텐트의 형태를 정의하는 서식 정보를 함께 포함하여 파일로 저장하게 된다. 그러나 HTML은 기본적으로 콘텐트의 내용만을 저장하며, 서식 정보 등은 외부 파일을 참조하도록 만들어져 있는 것이다. 만약 HTML을 Word와 같은 도구로 사용해 본다면 그 기능에 얼마나 제약이 있는지 쉽게 알 수 있을 것이다.

물론, 낮은 버전의 HTML에서는 서식을 지정하는 속성을 태그에 사용할 수 있도록 하기도 했다. 하지만 그것은 W3C에서 표준안을 제작할 때 의도했던 바라고 하기 보다는, 좀 더 새로운 방향으로 확장을 꾀했던 브라우저 제조사들의 무분별한 확대 해석 때문이라고 할 수 있다. 실제로 서식을 직접적으로 지정하는 몇몇 태그들은 W3C의 아이디어가 아니라 브라우저 제조사에서 만들어졌으며, 이를 사용자들이 더 많이 사용하게 되면서 표준안에 포함되게 되었던 경우라 할 수 있다.

이렇게 탄생한 태그나 속성들 때문에, 문서를 제작한 사람들은 처음의 의도와는 다르게 브라우저마다 문서가 다르게 보이는 결과에 부딪힐 수밖에 없었다. 새로운 기술과 시장 지배에 대한 욕심이 오히려 사용자의 선택권을 제한하거나 사용성을 떨어뜨려 버린 것이다. 실제로 현존하는 여러 브라우저들은 똑같은 HTML 문서를 처리하는데 서로 다른 방법을 사용하고 있다.

문서가 구조적이어야 하는 이유

문서 제목은 그 문서가 담고 있는 정보가 어떤 내용인지를 독자가 손쉽게 파악할 수 있도록 도와준다. 일반적으로 대제목이 소제목보다 크게 표시되는 이유는 강조의 정도에 따라 어떤 것이 더 많은 부분을 포함하고 있는지를 관습적으로 설명할 수 있기 때문이다. 이런 이유에서 소제목이 대제목을 포함하는 것은 말이 안되는 일이 된다.

이렇듯 상위 요소와 하위 요소의 등급을 확실히 하고, 해당 요소에 포함되는 내용을 명확하게 구분해서 정리하는 것이 바로 구조화라 할 수 있다. 문서 구조화를 통해서 얻을 수 있는 이점은 무엇이 있을까?

인식의 용이

앞서 설명한 바와 같이 내용의 상하 등급이 분명하면, 이를 읽는 사람들도 좀 더 손쉽게 내용을 파악할 수 있게된다. 내용과 내용 사이의 구별이 쉬워지는 것은 말할 것도 없고, 어떤 것이 중요한지 아닌지를 더 알기 쉬워지는 것이다.

재활용 가능한 데이터로써 콘텐트

웹 사이트의 콘텐트란 파일 형식의 데이터로 볼 수도 있다. 이는 HTML 파일이 단순히 문서 형태로 사람의 눈에 인지되기 위한 존재만이 아니라, 가공을 통하여 프로그램 간에 주고 받을 수 있는 데이터로 사용될 수도 있는 것이다. 이 때 파일 내의 정보가 잘 짜여진 구조를 가지고 있다면, 단순히 파일 단위의 데이터가 아니라 태그를 통해 구별할 수 있는 작은 단위의 정보를 활용할 수도 있게 될 것이다.

검색의 효율성 제고

우리가 검색 엔진을 이용할 때에는 특정 키워드나 몇 개의 키워드를 조합하여 결과를 얻곤 한다. 많은 검색엔진이 그렇지만 이 때 나오는 검색 결과를 보다보면 그 키워드가 페이지의 제목인 경우보다 내용 중의 일부분, 그것도 문장 중에 연속된 형태로 나오는 경우보다 떨어져있는 단어를 각각 찾아주는 경우를 더 많이 볼 수 있다. 이는 검색 엔진이 문서 전체를 검색해서 해당하는 키워드가 있는 경우를 모두 찾아내기 때문이다.

만약 검색엔진이 페이지를 처음부터 끝까지 찾는 것이 아니라 제목 중심으로 검색을 해준다면 어떨까? 앞서 이야기한 바와 같이, 문서의 제목이란 문서가 담고 있는 내용을 압축적으로 전달해준다. 문서의 시작점부터 끝점까지를 다 읽는 것과, 제목만 먼저 읽는 것 중에 무엇이 더 빠를지는 명확하다. 어쩌면, 해당 키워드와 비슷한 의미의 단어가 사용된 제목을 찾아줄 여유도 생기지 않을까?

구조를 만드는 방법

꼭 HTML 형식이 아니라고 하더라도 여러분은 많은 문서를 작성하고 있을 것이다. 아마 Word 프로그램으로 문서를 만든다고 생각하면 이해가 쉬울 것이다. 처음부터 끝까지 똑같은 글자 크기로 줄한번 바꾸지 않고 쓰는 문서란 이미 다른 사람에게 회람할 수 있는 형태가 아닐 것이다. 마찬가지로, 문단의 내용이 변경될 때는 단락을 바꾸고, 내용이 다른 것을 다루기 시작할 때는 다음 내용의 제목을 먼저 써주고 다음 단락을 쓰면 된다.

이렇게 문서를 작성하다보면 우리가 일반적으로 트리 구조라고 부르는 형태가 전체적으로 만들어진다. 문서 전체를 대표하는 모든 내용은 상위 요소를 가지게 되는 하위 요소의 형태가 되는 것이다. 이렇게 문서를 구조화 하는 형태를 DOM(Document Object Model)이라고도 하며 이를 잘 지키는 것은 스타일시트나 스크립트를 활용할 때에도 매우 중요한 역할을 한다.

이를 그림으로 표현하면 위와 같은 형태가 되며, 이를 태그를 이용하면 아래 그림처럼 만들 수 있다. 내용 칸에는 필요에 따라 다양한 태그를 이용하여 여러 내용을 넣을 수도 있고, 내용간의 구별을 위해 구분자를 사용할 수도 있다.

구체적인 내용을 다루는 태그 안에는 강조나 첨삭, 설명을 위한 태그들이 사용될 수 있으며 이는 사용자가 내용을 이해하는데 도움을 줄 수 있다. 필요한 속성을 적절히 사용하는 것 역시 마찬가지로 내용의 이해에 도움이 된다.

» 내용전체보기

XHTML, CSS, 혹은 웹표준 관련 책 이야기.

이미 많은 분들이 소개한바 있는 실용예제로 배우는 웹표준이나 웹 2.0을 이끄는 방탄웹 같은 책처럼 최근에 웹표준 관련한 책들이 제법 출간되었다. 아마 많은 분들이 이미 갖고 계시리라 생각하지만 나 역시 이 두 권은 이미 갖고 있는 책이기도 한데, 처음 실용 예제로 배우는 웹표준 출간 소식에 얼마나 기뻤는지!

아마 많은 분들이 이미 알고계신 책이라 생각하지만, 앞서 언급한 주황색과 파란색 책 외에 다른 책 한권을 소개할까 한다. 앞의 두 권이 이미 HTML이나 CSS에 대한 이해가 있는 사람들을 대상으로 한 책이라면, 지금 소개하는 책은 초보가 읽어도 큰 무리가 없는 책이 아닐까 한다.

• Head First HTML with CSS & XHTML - 웹2.0 시대의 웹표준 학습법
• by 엘리자베스 프리먼
• 한빛미디어 2006-05-31
• ISBN 8979144105

우선 이 책은 우리 나라 사람들이 좋아할만한 편집 스타일이 아닐지도 모른다. 책을 펼쳐보면 마치 잡지 같아서, 좀 산만한 감이 없지 않다. 또 전문적이라고 하기에는 아주 기초적인 내용부터 다루고 있어서, 이미 스스로의 기술 수준에 자신하는 사람들이 읽기에는 초반부가 좀 지루할지도 모르겠다.

하지만, HTML의 기초부터 시작한 이야기는 어떻게 하는 것이 웹 표준을 지켜서 웹페이지를 만드는 방법인지를 차근차근 설명하고 있다. 혹시라도, 자신이 다 아는 내용이라고 페이지를 쉽게 넘기지 않기를 바란다. 조금만 자세히 보면, 좀 더 새롭거나 놓치고 있었던 부분이 보인다.

이 책으로 회사에서 8주짜리 커리큘럼을 짜서 세미나를 진행한 적이 있는데, 참여자의 반응이나 결과가 나름 좋았던 것으로 기억한다. 우선은 내용이 어렵지 않아서 혼자서 해당 챕터를 읽어오는데 큰 무리가 없었고, 발제자가 준비한 내용으로 속을 더 채우기에 적당했던 것이다.

지금 출간을 준비 중인 책들도 있다. CDK 첫번째 모임에서 만박님께서도 말씀하셨지만 CSS Mastery(나는 원서를 구입한지 얼마 안됐는데 번역판이 출간 예정이라 좀 억울하다)나 nmind님이 번역하시고 현석님이 감수하셔서 이제 출간을 준비 중인 웹표준 교과서 같은 책들은 정말 기대된다.

흠… 이젠 국내에서 저술된 책이 나오기만 기다리면 되는건가?

웹. 넌 뭐냐?

웹에 대한 이상한 생각. 문서 구조에 대하여.

사실 웹표준이라는 걸 익히고 사용한지 좀 됐다고는 하지만 뭔가 정답을 찾지 못해서 헤매고 있는 건 아닐까 하는 불안함이 여전히 있다. CSS Hack도 그렇지만, IE의 나쁜 버릇을 고쳐주는 여러 가지 방법은 계속 나오고 있는데, 업무가 바쁘다는 이유로 익숙한 방식으로 계속 작업하게 되고, 이건 정체되어있는 건 아닌가 하는 걱정을 만든다.

딱 꼬집어 말하진 못해도 하루에 다섯번쯤은 지금 내가 옳은 방법을 사용하고 있는지에 대해 자문하게 된다. 어쨌든 지금의 내 생각을 조금 정리해보자면.

웹은 정보를 효율적으로 전달하고 관리할 수 있는 방법으로써 고안되었다.

일단 웹이 고안되기 이전에는 모든 정보의 저장 수단이 문서라고 봐도 무방할 정도가 아니었을까 하는 점이 웹에 대한 내 생각의 시작이다. 물론, 웹이 생기기 이전에도 컴퓨터는 있었고, 플로피 디스크 등의 저장 매체도 있었지만 그것은 결국 용적의 측면에서 대대적인 확장이었을 뿐이고 전달 방식(종이뭉치를 우편으로 보내고 받아야했던, 그래서 어쩌면 유행이 지난 소식을 주고 받게되던)에 따르는 시간적-공간적 제약에 묶여있는 것은 종이와 마찬가지였다. 인터넷이라는 수단이 생기고 웹이라는 채널이 열리면서 이런 시공의 제약이 사라졌다고 보는 것이다.

그 처음이 바로 HTML이었고, 이는 표준 문서 처리 포맷인 SGML에 서 출발하지 않았던가. 그래서 나는 일반 문서와 웹문서의 구조적인 차이는 없다고 본다. 사람이 정리해내는 문서의 작성 방식이란 제목과 내용으로 구별되는 형태로 내용 중에는 그림이나 표, 일단의 목록이 들어갈 수도 있다. 내 생각에 웹이 일반 문서에 비해 좋은 점은 바로 하이퍼링크라는 기능적인 측면이 생겼다는 점이 아닐까 한다. 네트워크의 이점을 잘 살린 방식이기도 하고, 이를 통해 화면상에서 단일 문서를 뛰어넘을 수 있는 수단이 우리 손에 들어왔다고 생각한다.

물론, HTML에선 메타데이터라는 것도 굉장히 중요하다. 이를 통해 표준적인 문서 처리가 가능한 것이고 사람 뿐만 아니라 기계가 인식하고 처리하기 쉬울테니. 하지만, 사람이 만든 모든 것은 사람이라는 존재를 중심에 두고 시작하지 않을까.

문서의 구조 : 문서에 제목을 쓰는 건 당연한건가?

그렇다면 제목에 차등(Level)을 주는 것 역시 너무나 당연한 것이다. 대제목이 있으면 중제목, 소제목도 있다. 일반적으로 대제목과 중제목의 관계는 상하 종속적이며, 중제목간의 관계는 수평적 관계다. 이를 전체적으로 도식화해보면 피라미드 구조를 띄게 되는데, 논리적으로 표현되는 문서는 대개 이 틀을 벗어나지 않는다. 그리고, 이 제목 아래에서 어떤 것에 대한 설명을 하기 위한 표현 방법은 매우 다양해진다.

예를 들자면, 사전처럼 어떤 단어를 설명하기 위해서 dl이라는 태그가 고안되었으리라 짐작할 수 있다. 하지만 사전의 종류나 편집자에 따라서, 또 단어 자체의 특징(다의어 같은)에 따라서 설명에 할애하는 분량이 크게 달라질 수도 있다. 어쩌면 그 단어를 설명하기 위해 여러 가지 뜻을 나열(li)하거나, 여러 단락(p)으로 이루어진 긴 설명 문장이 들어가거나, 예문(blockquote)이 있어야만 설명이 가능한 경우도 있을 것이다.

순수하게 정보를 구조화하고 배치한다는 점에서 나는 문서와 웹페이지를 대입하곤 한다. 그래서 사이트를 한권에 책에 대입해보기도 한다. 네비게이션을 책의 목차와 함께, 대개는 왼쪽 상단에 배치되는 사이트 로고는 책의 제목과 함께 슬쩍 놓아본다.

내가 이런 방식에 주목하게 된 이유는 글씨 크기를 CSS 등으로 제어하지 않고 헤딩 태그를 사용했을 때 표시되는 제목의 글씨 크기 때문인데, h1부터 h3까지는 일반 글씨보다 크게 나오고, h4는 같은 크기에 굵게, h5~h6은 더 작게 나오기 때문이다. 이는 HTML이 만들어질 때 제목이 사용될 수 있는 곳을 생각해서 고안한 것이라 추측해봤다. 그래서 메뉴 구조상에서 각 페이지에 사용할 제목 레벨을 정하고, 정보를 배치해 실제 사이트 작업에 들어간 적이 있다.

사실 이런 기준으로 두가지 포맷을 대입한다면 h6까지 있는 헤딩 태그는 모자란 감이 없지 않다. 그것은 단일 문서인 경우와 하나의 주제를 가진 여러 문서의 묶음일 경우의 차이 때문인데, 묶음일 경우는 그 묶음에 제목이 부여되어 있는가 하는 점이 중요해지기 때문이다. 묶음의 제목(책 제목 같은)이 존재한다면, 각각의 문서는 논리적으로 따지자면 중제목부터 시작해야 한다. 결과적으로 페이지의 기준점을 어디에 두는지가 중요해진다.

Semantic markup. 그 장미빛 미래, 하지만…

그 동안 사이트를 제작해온 경험에 비추어 보면, 제목은 있지만 구조는 없는 경우도 왕왕 발생한다. 예를 들자면, 제목보다 강조되는(특히 시각적으로) 내용이 있는 경우라던가, 같은 형식의 내용이 표시되어야 함에도 불구하고 틀이 달라져버린다거나… 심지어는 전체 구조에서 봤을 때 문서마다 제목 레벨이 달라지는 경우가 그렇다.

지금 시점에 Semantic markup이라는 걸 많은 사람들에게 인식시키기는 꽤 어려워 보인다. Semantic이라는 단어의 가치를 인식 못하는 사람들에게 그것은 단지 중요하지 않은 것 중 하나일 뿐이니까.
우리 나라에서 웹사이트란 이쁘고 깔끔하고 화려하고. 그러면 된다. 플래시만으로 만들어진 사이트라던가, 엉뚱하게 확장되는 메뉴구조를 가진 사이트라거나. 그래도 된다.

정리하기 어려운 사이트가 너무 많다.
아 정말 쓰다보니 글이 꼬인다… 논리적인 구조고 뭐고 사람들의 생각을 나름대로의 실험성이라고 인정해버릴까?

[푸념 하나]
아… 일단은 이런 글을 써버렸는데.
과연 시간이 지나서 정답이라는 무언가가 무엇인지 정확히 알게될 날은 올까?

[푸념 둘]
젠장.