Young Blog

| HTML

W3C 스펙 문서 읽는 법

원문: How to Read W3C Specs, J.David Eisenberg, 2001년 9월 28일

W3C에서 하는 일은 모든 웹 기술에 대한 스펙 제정입니다. 웹 디자이너로 일을 한 경험이 있다면 W3C 사이트를 방문한 적이 있을 것입니다. 아마 XHTML 사용법에 대한 궁금증이 생겨서 방문했을 수도 있고, XSL 포매팅 객체 혹은 SVG에 대한 궁금증을 해결하기 위해서 였을수도 있죠.

아무튼 뭔가에 대해 알아보기 위해 관련 스펙 문서를 읽다 보면, 십중팔구 엄청난 혼란에 빠지면서 포기하게 될 것입니다. “이건… 도대체 누구 읽으라고 만들어 놓은 걸까?” 이런 생각과 함께 말이죠. 그런데 말입니다, 스펙 문서에 대한 아주 중요한 사실 하나만 알고 있다면 읽을 수 있습니다.

스펙 문서는 사용자 설명서가 아닙니다.

성경은 해석해야 할 대상이지, 읽으라고 쓰여진 것이 아니다. - 출처 미상

우리가 사용자 설명서나 참고 도움말을 읽는 이유는 특정 문제에 대한 답을 구하기 위해서 입니다. 기술을 사용하고 싶기 때문에 읽는 것이죠. 아쉽게도 W3C 스펙 문서는 그러라고 만든게 아닙니다. “요구사항(스펙)”의 존재 목적은 누가 이 기술을 구현할 것인가, 어떤 기능이 반드시 들어야 하는가, 그리고 어떻게 구현할 것인가에 대해 프로그래머에게 알려주기 위함입니다.

이 차이는 마치 자동차 사용 설명서와 수리 설명서 사이의 관계와 같습니다. 윈드쉴드 와이퍼의 블레이드를 교체하려면 사용 설명서를 읽어 보아야 합니다. 만약 엉뚱하게 수리 설명서를 선택한다면, 블레이드의 면적과 장착 부분에 대한 친절한 설명을 보실 수 있습니다. 그럼 이렇게 알게 된 와이퍼에 대한 정보를 가지고 스스로 교체해보는 수 밖에 없겠죠.

여러분이 만약 아주 최근에 나온 기술을 사용하고 있다면, 해당 기술에 대한 사용자 참고 문서를 어디에서도 찾을 수 없는 경우가 있습니다. 이럴 때 볼 수 있는 문서라고는 오직 기술 명세서 뿐이죠. 이런 일이 발생할 것을 대비하는 차원에서, 스펙 읽는 법을 익혀두는 일은 생활 필수품 목록에 들어가야 합니다. 사치품이 아니죠.

스펙 문서의 구조

수리 설명서 안에 도표에서 사용한 축약어와 범례 안내문이 들어있는 것과 마찬가지로, 대부분의 W3C 스펙 문서에는 문서 자체에 대해 설명해 주는 부분이 존재합니다. 예를 들어, HTML과 CSS 스펙의 첫번째 절을 보면 문서의 전체 구성 방식과 읽는 법에 대해 꽤 괜찮은 정보를 얻을 수 있습니다.

지혜로운 자들을 위한 단어

나는 뭔가를 정의내리는 행위가 싫다. - 벤저민 디즈레일리(Benjamin Disraeli, 영국 정치가)

수리 설명서는 독자들과 허물없고 신선한 대화를 위해 쓴 글이기 보다는 정확성을 우선으로 두고 쓴 글입니다. 이와 비슷하게, W3C 스펙 문서에서는 일본의 가부키 연극마냥 의례적인 형식성을 중요하게 여깁니다. 스펙을 읽다보면 아래의 단어들을 쉽게 보실 수 있습니다.

  • 규범적인(normative): “이 절은 규범적인 내용을 포함하고 있습니다(this section is normative)”라는 말은 지금부터 보게 될 해당 절은 이 기능을 구현하고자 하는 사람들이 마땅히 따라야 하는 사항에 대해 자세히 설명하는 내용을 담고 있다는 뜻입니다. 이와는 반대로, 정보성(informative)인 내용을 담고 있는 절들은 주로 예시와 설명으로 구성되어 있습니다.
  • 유저 에이전트(user agent): 사용자들이 특정 기술을 사용하고자 할 때 그 매개체로 사용하는 프로그램을 뜻하는, 뭔가 있어보이는 단어입니다. HTML을 사용하려면 브라우저를 통해야 하는데, 이 때 브라우저가 유저 에이전트가 됩니다. SVG의 경우에는 Batik과 같은 프로그램이나 Adobe의 SVG 뷰어와 같은 플러그인을 유저 에이전트라고 일컬을 수 있습니다.
  • RFC(Request for Comment): ‘의견 바람’이라는 뜻으로, 인터넷 표준 및 신기술에 대해 서술한 메모 모음입니다.
  • 조동사(helping verbs): RFC2119를 따르는 스펙에서는 일부 조동사들이 문장에서 중요한 역할을 맡고 있습니다. 정의 사항에 must(반드시 ~해야 함)가 들어 있다면 이 사항은 무조건적으로 구현에 포함이 되어야 합니다. must not(반드시 ~하지 말아야 함)은 해당 정의사항은 무조건적으로 금지되어야 함을 나타냅니다. should(~해야 할 것임)는 해당 기능을 꼭 구현하지 않아도 됨을 의미합니다. 그러나 아주 타당한 이유가 있지 않은 이상 해당 기능은 구현하기를 권장합니다. 반대로 should not(~하지 않아도 됨)이 포함되어 있는 경우에는 아주 납득할 만한 이유가 있지 않은 이상 해당 기능을 구현에서 제외해야 합니다.

훑어보기

마르타 고모에게: 코끼리에 대한 책 잘 받았어요. 제가 코끼리에 대해 궁금했던 것 그 이상으로 많은 내용을 담고 있네요. - 한 아이의 감사 편지

스펙 문서의 모든 단어를 하나하나 다 읽고 있을 필요는 없습니다. 지금 보고 있는 부분이 HTML 태그는 코빼기도 안보이고 난해한 법률 용어나 컴퓨터 공학적인 말들로 아주 장황하게 가득차 있다면, 그냥 짧게 훑어보고 지나가는 걸로 충분할 가능성이 높습니다.

아래 나오는 XSL:FO 스펙 문서와 같은 내용을 보게 된다면 고민할 것도 없이 넘겨버려도 됩니다. (사실 이 스펙만을 놓고 보면, 사용자 관점에서 쓸모 있는 부분은 6장이 지나서야 겨우 볼 수 있습니다.)

4.2.5 축적(stacking) 제약: 이 절에서는 영역 안에서의 블럭 축적과 인라인 축적 제약 사항에 대해 정의합니다. 이 제약 사항들은 순차적인 관계에 의해 정의됩니다. 예를 들어, A와 B가 축적 제약 상황 안에 놓여있다고 한다면, 이는 반드시 … 저기 근데 왜 아직도 읽고 계시는거죠?

이와는 반대로 속도를 낮춰 천천히 읽어야 할 때도 있습니다. 삽화를 보고 있다면 같이 붙어 있는 주석과 참고 사항도 놓치지 말아야 합니다. 대부분의 경우 이 요소들 역시 중요한 정보를 제공합니다. 예시가 들어있는 절을 보고 있다면, 천천히 주의를 기울여서 읽어주세요.

네임스페이스

XML의 세상에서 네임스페이스(namespace)의 역할은 한 문서 내에 서로 다른 종류의 마크업이 공존하도록 하는 방법을 제공하는 것입니다. 예를 들어, HTML 문서 안에서 Math 마크업 언어도 사용하고 싶다면, 별도의 선언 몇 개를 문서의 최상단 요소에 선언한 다음 Math 마크업 요소를 표기할 때 ml:이라는 접두사를 같이 사용합니다.

예시 문서 안에서 찾을 수 있는 네임스페이스 접두어는 모두 사용하는 편이 안전합니다. 만약 특정 XML 기술이 어째서 “네임스페이스 주의(namespace-aware)”라는 경고를 지니고 있을까에 대한 논쟁이 길게 이어지고 있는 장면을 마주한다면, 그냥 조용히 넘어가시는 편이 나을 겁니다.

BNF 읽는 법 배우기

BNF는 Backus Naur Form(배커스-나우르 표기법) 혹은 Backus Normal Form의 약자입니다. 컴퓨터 언어 문법을 간결하게 쓸 수 있게 해주는 표기법으로 지금까지 쭉 사용되어 왔으며 아마 앞으로도 영원히 사용되지 않을까 싶습니다. 스펙 문서별로 각자의 기호에 맞추어 다르게 변형한 BNF를 사용중이지만, 그 내부를 들여다 보면 모두 일반적인 문장을 상징적인 형태로 변형시켜 놓은 것에 불과합니다. 샌드위치의 구성 요소에 대한 다음 설명을 예로 들어 봅시다.

샌드위치는 얇게 자른 식빵 위에 머스타드 혹은 마요네즈를 바르고 기호에 따라 양상추나 토마토 한 조각을 올린 뒤 볼로냐, 살라미, 혹은 햄을 두조각에서 네조각 넣은 후 (꼭 한 종류의 햄만 넣지 말고 입맛에 따라 다양한 조합을 해도 됩니다.) 치즈 한두장을 올리고 맨 위에 다시 식빵을 올려서 완성합니다.

이 문장은 다음과 같이 옮길 수 있습니다.

샌드위치 ::= 최하단 식빵 [ 머스타드 | 마요네즈 ] 양상추? 토마토? [ 볼로냐 | 살라미 | 햄 ] {2,4} 치즈+ 최상단 식빵

샌드위치에 대한 정의를 이루는 구성요소들이 공백으로 구분되어 순서대로 나열되어 있습니다. 같은 그룹에 속하는 요소들은 대괄호로 묶여져 있고 그룹 내에서 선택적인 값들은 싱글 파이프로 구분되어 있습니다.

만약 특정 값 뒤에 물음표가 붙어 있다면, 그 값은 “하나만 쓰거나 아예 쓰지 말아야” 합니다. 만약 덧셈 기호가 뒤에 붙어있다면 “하나 이상” 쓸 수 있습니다. 별표가 붙는다면 “0개 이상”이고 소괄호 안에 숫자가 적혀 있다면 값 반복 횟수의 최솟값과 최댓값을 뜻하는 것입니다.

대괄호를 제외한 다른 괄호 안에 요소가 들어가 있다면 그 의미는 좀 더 복잡해 집니다. “color”와 같은 평범한 요소가 <과 >로 묶일 때도 있고, 고정 요소가 인용 부호로 묶일 때도 있습니다.

문서 타입 정의(Document Type Definition, DTD) 읽는 법 배우기

사용할 HTML이나 XHTML 버전을 브라우저에게 알려주기 위해 <!DOCTYPE ...> 선언문을 문서에 넣는다는 사실을 알고 있었나요? 이 선언문은 문서 타입 선언, 일명 DTD라는 명칭을 가지고 있으며 문서 안에서 유효한 요소 결합 방식을 정의내리기 위해 사용합니다.

DTD 읽는 법을 배우는 것은 어렵지만 불가능한 일은 아닙니다. 오히려 DTD는 특정 마크업 언어를 사용할 때 구문론적으로 옳은 용법에 대해 판가름 내리는 절대적인 잣대로 사용되고 있으므로, 배울 만한 가치가 있습니다.

DTD 읽는 법을 전부 설명하는 것은 이 글의 주제를 훨씬 뛰어넘으므로 이에 대해 더 알아보고 싶다면 엘리자베스 카스트로가 쓴 ‘월드 와이드 웹을 위한 XML’ 책을 참고하거나 에릭 레이가 쓴 글인 ‘XML 배우기’를 참고하시기 바랍니다. 다음은 DTD 안에서 봤을 법한 간략한 예시 구문입니다.

1
2
3
4
<!ENTITY %fontstyle "(tt | i | b)"> 
<!ENTITY %inline "(#PCDATA | %fontstyle;)"> 
<!ELEMENT div (p | %inline;)+> 
<!ATTLIST div align (left | right | center) #IMPLIED>

평범한 문장으로 바꾸어 쓴다면 위의 예시의 의미는 다음과 같습니다.

폰트 스타일 요소로는 <code>, <i>, <b>가 있습니다. 인라인 요소는 텍스트 혹은 폰트 스타일 요소로 이루어져 있습니다. <div>는 하나 이상의 <p> 혹은 인라인 요소를 순서와 상관없이 지닐 수 있습니다. <div>는 옵션으로 align 속성을 가질 수 있으며 그 값으로는 left, center, right가 있습니다.

IDL은 한 귀로 듣고 흘려버리고, 바인딩에 귀 기울여 보자(IDLE PAST IDL, BE BOUND BY BINDINGS)

자바스크립트로 HTML 문서를 조작하듯이, SVG나 SMIL과 같은 일부 XML 기술을 사용한다면 사용자는 동적인 문서 제어 프로그램을 작성할 수 있습니다. 이러한 기술들의 스펙 문서에는 문서 객체 모델(DOM)에 대한 스크립트 언어의 작동 방식을 설명하는 절이 있는데, IDL(Interface Definition Language, 인터페이스 정의 언어)를 사용하여 인터페이스를 소개합니다.

IDL은 유저 에이전트가 프로그래밍 환경에 대해 손쉽게 접근할 수 있도록 관련 정보를 제공해주는 일반적인 표기법입니다. IDL은 프로그래밍 언어가 아니라, 간결하게 인터페이스를 기술할 수 있는 표기법입니다. 알아두면 유용하기는 하지만, IDL 인터페이스에 대한 정의는 아마 여러분이 원하던 내용이 아닐 것입니다.

프로그래밍 언어 선택에 따라 원하는 것이 살짝 달라지긴 하지만, 아마도 여러분이 찾고 싶은 내용은 자바 바인딩(bindings) 혹은 ECMAScript 바인딩에 대한 것일 확률이 높습니다.

바인딩은 스크립트 내에서 사용 가능한 객체, 프로퍼티, 메소드의 리스트를 가르키는 예쁘장한 단어입니다. ECMAScript는 유럽 컴퓨터 제조업자 협회 표준 버전 자바스크립트(the European Computer Manufacturer’s Association standard version of Javascript)를 뜻하는 약자입니다.

펄이나 파이썬과 같은 다른 언어를 사용하고 있다면, Comprehensive Perl Archive Network나 Python XML Special Interest Group과 같은 다른 라이브러리를 찾아보세요.

요약

  1. W3C 스펙 문서는 기능을 구현하는 사람들을 위한 것이지, 최종 사용자를 위한 것이 아닙니다.
  2. 많은 스펙 문서에는 문서의 구성 방식과 읽는 법에 대한 내용을 담고 있는 절이 포함되어 있습니다.
  3. 스펙 문서에서 사용하는 용어에 대해 알아둡니다
  4. 모든 내용을 다 읽을 필요가 없음을 기억합니다. 꼭 봐야 할 내용이 아니면 빠르게 훑고 넘깁니다.
  5. 네임스페이스에 대한 논쟁은 피합니다.
  6. BNF 읽는 법을 익혀둡니다. 많은 곳에서 사용하기 때문이죠.
  7. 구문과 관련된 궁금증을 해결하기 위해 DTD 읽는 법을 익혀둡니다.
  8. 스크립트 작성이 가능한 기술을 사용중이라면, 그것과 관련된 정보는 바인딩에서 찾아볼 수 있습니다.

인내심을 가지고 꾸준하게 W3C 스펙 문서를 대하다 보면, 문서에서 얻을 수 있는 정보의 양이 얼마나 많은지 아마 보고 깜짝 놀라게 될 날이 올 것입니다.

Comments