페이지오프: XHTML

레이블이 XHTML인 게시물을 표시합니다. 모든 게시물 표시

2010년 2월 9일 화요일

HTML5 제정과 관련된 질문 답, WHATWG FAQ 문서 한글화

의도했던 것은 아니나 스티브 잡스가 HTML5 이슈를 크게 터뜨려주어 요즘 HTML5에 대한 관심이 지나치게 높아진 요즘 제가 운영중인 클리어보스에서는 WHATWG FAQ 문서를 번역 중에 있었습니다. 2010년 들면서 클리어보스 내에 HTML5 스터디를 꾸리고 공부를 할 마음으로 진행된 것이었는데요. 아직 미흡하긴 하나 그럭저럭 읽기에는 어렵지 않은 문서가 되어 공개하게 되었습니다.

WHATWG FAQ는 HTML5 제정과 관련해서 나온 여러가지 질문들에 대한 답변을 다루고 있는 문서이고, 수시로 업데이트가 되고 있습니다. 따라서 현재 한글화된 문서가 영문 문서와 내용이 달라질 수 있음을 알아주시기 바랍니다. 시일이 다소 지난 후에는 영문서를 먼저 확인해 보시고 업데이트가 되었는지 확인하실 필요가 있을 것입니다.

또, 이 한글화 문서는 일본 문서를 재번역 한 것을 기초로 하고 있습니다. 애초에 스터디 그룹에서 사용될 것이었기 때문에 번역이 좀 더 용이한 일어 문서를 가지고 번역하기 시작했습니다. 혹시 번역된 문서를 재번역한 것이라 믿음이 덜한 분들은 꼭 원문을 읽기를 권해 드립니다.

영어 원문이든 일본어로 번역된 문서를 재번역했든 최대한 원본 글을 유지하고자 했습니다. 하지만 번역의 미숙함과 배경지식의 얕음으로 인해 아마 여러 부분에서 애매모호한 문장들이 있을 것이라고 생각됩니다. 지난주 클리어보스 자체 HTML5 스터디에서 이 문서를 다루었을 때도 이해가 되지 않아 모두들 어리둥절해 한 내용들도 있었으니까요.

일단은 HTML5에 제정과 관련된 여러가지 궁금증을 풀어보고자 그리고 풀어 드리고자 번역을 시도해 봤습니다. 일어를 번역해 주신 윤준님께 감사드리고, 영문 부분을 번역해 주신 아쿠아테라님께도 감사드립니다.

자체 스터디를 통해서 HTML5에 대한 배경 지식이 넓어지면 이 FAQ를 통해서 이안 힉슨의 답변을 좀 더 이해할 수 있을 것이라고 기대해 보고, 그렇게 깨닫게 되면 여러분들께도 함께 공유해 드리도록 하겠습니다.

2008년 6월 4일 수요일

웹표준경진대회 디자인 심사 실시

웹표준경진대회 참가가 완료된 상태에서 오늘부터 디자인 공개심사가 시작되었습니다.

총 18팀(개인 포함)이 참가하였는데 각각의 수고로움이 대단한 것 같았습니다. 일단은 디자인 심사만을 위한 것이기는 하지만 좀 더 많은 사람들이 웹표준과 웹접근성에 대한 관심을 갖고 이해를 높일 수 있는 기회이니 만큼 참가는 하지 않았더라도 심사에는 참여해서 대회의 의미를 살렸으면 좋겠습니다.

심사 기간은 10일까지로, 해당 작품이 소개된 게시물에 추천 댓글을 달아주시면 되고, 중복 추천은 가능하나 하나의 작품에 두번 이상은 한번으로 처리된다고 합니다.

2008년 5월 12일 월요일

form 요소 누구의 것인가?

최근에 제가 참여하고 있는 웹표준스터디모임에서 form 요소와 관련한 내용을 다룬적이 있었습니다.

form 요소가 서버사이드개발자(이하 개발자)들에 의해서 잘못 사용되는 경우와 웹퍼블리셔들이 form 요소를 쉽게 생략하는 문제에 대해서 논의가 있었습니다.

제 생각은 이렇습니다.

첫째로 form 요소는 분명 마크업 요소이고 마땅히 웹퍼블리셔가 사용해야할 태그입니다. 둘째로 내용을 제출하는 폼을 작성했을 경우 그것은 의미적으로 폼에 해당되고, 따라서 웹퍼블리셔는 form 요소를 사용해야 하는 경우에 해당됩니다. (함께 스터디를 하시면서 한 분은 웹개발자가 form 요소를 마음대로 사용하는 것은 오히려 직권남용과 같다! 라고 강하게 말씀하시기까지 했습니다.)

하지만 form 요소가 ASP, JSP, PHP와 같은 서버사이드측 언어와 맞물려 있다보니 많은 경우 웹개발자에게 form 요소를 암묵적으로 위임하여 (웹퍼블리셔는) 이를 생략하는 경우가 있습니다.

적지 않은 시간동안 이러한 관례가 이어지다 보니 요즘은 웹개발자들로부터도 form 요소는 건들지 말아달라는 이야기를 듣기까지 합니다.

이같은 상황에서 현실적인 입장을 보이자면 자연스럽게 웹개발자와의 커뮤니케이션을 강조할 수밖에 없기는 합니다.

웹퍼블리셔와 웹개발자가 프로젝트 기획 단계에서 form 요소 관련 이슈들을 한자리에서 정리하고 HTML 마크업시에는 웹퍼블리셔가 의미에 맞게 form 요소를 작성하고, 개발시에는 웹개발자가 form 요소를 용도에 맞게 사용합니다. 변경시에는 웹퍼블리셔와 다시 또다른 문제가 생기지는 않는지 등 추가적인 이슈에 대한 회의를 가져야 할 것입니다.

화두를 던져놓고 거두어가는 꼴의 글이 되어가는것 같기는 하지만 논의가 너무 깊이 들어가지 않는 범위에서 여러분이라면 어떻게 생각하십니까? 하고 여쭤보고 싶습니다. 자바스크립트를 웹퍼블리셔가 어느정도까지 해야 하는가? 에 대한 고민처럼 form 요소도 웹퍼블리셔가 굳이 작성해야 하는가라고 고민하는 분들이 없지는 않을 것이라고 생각했습니다.

여러분은 form 요소가 웹퍼블리셔의 것이라고 생각하십니까? 아니면 웹개발자에게 위임되어도 좋다고 생각하십니까?

2008년 4월 29일 화요일

웹 표준 경진대회가 열렸습니다.

일전부터 관심을 두고 있었떤 대회인데 무사히 시작될 수 있어서 다행스럽네요.
CDK관계자 분들께서 꽤나 신경쓰시고, 애쓰신 모양입니다. 웹표준이 어느 한 직군만의 책임이 아니니 만큼 웹퍼블리셔분들 뿐 아니라 웹디자이너와 개발자 분들도 많은 관심을 갖고 함께 참여해 주셨으면 합니다.

자세한 정보는 CDK 웹사이트와 웹표준 경진대회 공식 사이트 에서 확인해 보실 수 있습니다.

다음은 자세한 대회 내용입니다.

누군가가 시켜서 만드는 웹, 누구를 위해 만드는 것인지 알 수 없었던 웹은 이제 우리 자신과 보다 많은 사람들을 위해 개선되어 나가야 합니다. 더 많은 사람들이 더 좋은 방법을 이용하여 웹 사이트를 제작하고 사용할 수 있어야 하고, 시대가 이런 점을 이미 요구하기 시작했습니다. 이제는 가르치고 배우는 과정을 넘어 더 많은 사람이 보다 손 쉽게 이용할 수 있는 웹 표준으로 나아가야 할 것입니다. '규칙과 창조의 만남'이라는 슬로건처럼 웹 표준이라는 규칙을 지킴으로써 사이트가 얼마나 창조적으로 유연하게, 얼마나 더 편리해질 수 있는지를 많은 사람들이 알 수 있게 될 것입니다.

CSS Design Korea에서 주최하고, Hosting.kr, 에이콘출판사, 디지털미디어리서치가 후원하는 이번 대회는 2008년 5 월 1일부터 약 한달간 진행되며 2008년 6월 예정인 세번째 웹 표준의 날에 그 대미를 볼 수 있게 됩니다. 우리가 원하는, 모두를 위한 웹을 만들어가려는 이번 행사에 많은 분들의 참여를 기대합니다.

개인 혹은 3인 이내로 구성된 팀

제시된 콘텐츠(인터넷 웹 콘텐츠 접근성 지침)를 웹 페이지로 작성하여 소정의 페이지를 통해 접수

1. 주어진 내용 전체를 사이트의 콘텐츠로 활용해야 합니다.
2. 사이트의 형식은 자유롭게 작성할 수 있습니다. (일반적인 정보 제공 형태의 사이트, 블로그 등)
3. 최소한 1개 이상의 메뉴 형식이 포함되어야 합니다.
4. HTML, CSS, Javascript와 이미지 파일만 허용되며 각각의 고유 확장자를 사용해야 합니다. (.html, .css, .js, jpg, .gif, .png 등)
5. 최종 작업물은 로컬에서 열었을 때 정상 동작할 수 있도록 작성되어야 합니다.
6. 최종 작업물과 스크린샷을 압축하여 참가 신청서에 첨부해야 합니다.

100점기준
Markup(35) / CSS(30) / 디자인(20) / 기타(15)

대상(1팀) : iPod Touch 8Gb + Hosting.co.kr(도메인/호스팅 3년 이용권)
금상(1팀) : iPod Touch 8Gb + Hosting.co.kr(도메인/호스팅 1년 이용권)
은상(2팀) : 웹 표준 완전정복 세트
동상(5팀) : 웹 표준의 교과서

* 입상팀을 제외한 참가자 전원에게 Web Standards day 컵(소량으로 참가 신청순에 의하여 지급 될 수 있습니다. )과 Hosting.co.kr(웹 호스팅 1년 이용권) 지급

2008.5.01~6.01

2008.6.15 (입상시 개별 통보)

DTD 어떻게 읽는지 아세요?

웹표준과 관련된 글들을 올리면서 가장 많이 언급하는 것이 HTML 문서의 DTD이다. 기본적으로 HTML에는 3.2, 4.0, 4.01이 나와 있고, XHTML 1.0과 1.1이 발표되었다. 그런데 HTML 4.01이라고 다 같은 HTML 4.01이 아니고, XHTML 1.0이라고 해서 똑같은 XHTML 1.0이 아니라는데 애로가 있다. 각 버전에는 문법에 대한 엄격성에 따른 DTD가 존재하는데 다음과 같다.

more..

현재 가장 많이 사용되고 있다고 볼 수 있는 DTD를 열거했는데, 크게 보면 HTML 4.01과 XHTML 1.0에 가장 엄격한 문법 준수를 요구하는 Strict, 하위 버전과의 호환성을 보장해주는 Transitional, 프레임셋을 위한 Frameset 타입 세가지로 구성되어 있다. XHTML 1.1에 와서는 의미적으로 Strict 타입만을 지원하며 표기는 위와 같이 한다. 아울러 가까운 미래에 나오게 될 HTML 5 에서는 단순히 <!DOCTYPE html> 라고만 정의하면 그만이게 된다.

DTD는 HTML 문서가 어떠한 구조로 작성되어야 하는지를 명시적으로 정의하는 스펙으로 표준화된 방법을 제안하고 있다. 따라서 우리가 위의 7가지 DTD중 하나를 선택해서 HTML 문서를 작성했다면 해당 DTD가 명시하고 있는 문법 규칙을 올바르게 따라야 오류가 없는 무결한 HTML 문서를 만들수 있게 된다. HTML 문법과 관련된 웹사이트 강좌나 서적이 이미 많이 나와 있고, 완성된 HTML 문서의 유효성 검증(Validation)을 실시해 주는 서비스도 여럿 존재기 때문에 작업에 어려움은 없지만 기왕에 HTML을 다루는 직업을 가졌다면 자신이 사용하는 DTD의 내용을 읽고 이해할 수는 있어야 하지 않을까 하는 생각이 든다. (많은 사람들이 위 DTD를 입맛 따라 골라서 복사해서 붙여놓고 쓸 줄만 알지 어떤 내용인지는 신경쓰지 않는것 같다) 그래서 이 글은 DTD를 읽고 이해하는 방법을 설명하고자 한다.

W3C HTML 4.01 Specification 의 3.3 How to read the HTML DTD 에서 HTML DTD를 어떻게 읽을 것인지를 간단히 설명하고 있다.

주석(Comment)
주석은 한 줄 또는 여러 줄이 될 수 있고, 선언문 내에서 연속된 하이픈(-) 두개를 주석내용의 앞과 뒤에 위치시켜서 쓸 수 있다.
※ XHTML DTD는 선언부 내 하이픈(-) 주석을 사용하고 있지 않다.
파라메터 엔티티(Parameter Entity)
어려운 용어로 정의되어 있는데 파라메터는 매개변수를 말하고, 엔티티는 대체문자를 말한다. 간단히 설명하면 미리 정의된 변수를 대체문자로써 사용하겠다라는 뜻이다. 다시 말해 %attrs;이라는 엔티티에는 이미 style, class, alt, title과 같이 거의 모든 엘리먼트에 포함되는 속성명들을 정의해 놓고 있어서 이후에 정의하는 엘리먼트에서는 단순히 %attrs;이라고만 정의하면 된다라는 의미다. 프로그래밍을 해보신 분이라면 쉽게 이해하실수 있을것 같다. x라는 변수에 숫자 '3'을 미리 기억시켜 놓고, y = x + 2 라는 프로그래밍을 하게 되면 y의 값은 미리 기억된 x의 값 '3'을 불러와 합산을 해서 '5'라는 결과를 보여주는 것과 같다.
엘리먼트(Element)
엘리먼트는 이름과 태그, 컨텐츠 모델(Content Model)로 구성되어 있다. 엘리먼트 이름은 HTML 문서에서 실제로 사용되는 태그의 명칭이 되고, 두번째 나오는 '- O'은 시작태그와 종료태그의 형태를 기술한 것이다. 하이픈(-)일 경우에 태그는 사용되어야 하고, 'O(Omitted)'일 경우에는 생략이 가능하다. 위의 경우에는 시작태그는 필요하고, 종료태그는 생략할 수 있다고 기술한 것이다. 세번째 컨텐츠 모델은 어떤 내용을 갖을 것인가? 하는 것을 기술한다. 위에서는 파라메터 엔티티로 정의된 %inline;과 %flow;가 DT 엘리먼트와 DD 엘리먼트에 각각 기술되어 있고, 괄혹 속에 들어가 있는 것을 볼 수 있다. 또, 애스테리스크(*, 별표)가 붙어 있는 것을 볼 수 있다. 좀 더 쉬운 예를 보자.

<!ELEMENT DL - - (DT | DD)+>

DL 엘리먼트를 정의한 것인데 괄호안에 'DT'와 'DD'가 있고, 플러스(+)표시가 붙어 있다. 당연히 알고 있겠지만 DL 엘리먼트에는 DT 요소와 DD 요소를 자식요소로 가질 수 있고, 한 번 이상 쓰일 수 있는데 그것을 위와 같이 기술한 것이다. 정의된 엘리먼트의 괄호는 내용의 그룹이 되며, 산술 기호는 등장 횟수가 된다. 다음과 같은 기호들이 사용된다.

( ... ) : 그룹 제한
A : 오직 A 하나만 나타날 경우
A+ : A 가 무조건 한 번 이상 나타나는 경우
A? : A 가 생략되거나 한 번 나타나는 경우
A* : A 가 생략되거나 한 번 이상 나타나는 경우
+(A) : A 를 포함할 수 있는 경우
-(A) : A 를 포함할 수 없는 경우
A | B : A 또는 B, 둘 다는 아닐 경우
A , B : A 와 B가 순서대로 나타나는 경우
A & B : A 와 B가 순서없이 모두 나타나는 경우

IMG 요소나 BR 요소와 같이 내용을 포함하지 않는 요소의 경우에는 'EMPTY'라고 정의하고, 문자열 이외의 자식 요소를 포함하지 않는 경우(OPTION 요소)에는 '(#PCDATA)'와 같이 정의한다. 또한, A 엘리먼트와 같이 자식요소에 자신을 포함하지 못하는 경우는

<!ELEMENT A - - (%inline;)* -(A)>

와 같이 정의한다.
애트리뷰트(Attribute)
애트리뷰트를 설명하기 위해서 IMG 요소의 정의 부분을 보겠다.
<!ATTLIST IMG
%attrs;    -- %coreattrs, %i18n, %events --
src %URI;    #REQUIRED -- URI of image to embed --
alt %Text; #REQUIRED -- short description --
longdesc    %URI;    #IMPLIED -- link to long description
(complements alt) --
name    CDATA    #IMPLIED -- name of image for scripting --
height    %Length; #IMPLIED -- override height --
width %Length; #IMPLIED -- override width --
usemap    %URI;    #IMPLIED -- use client-side image map --
ismap (ismap)    #IMPLIED -- use server-side image map --
>

애트리뷰트의 이름과 타입, 디폴트 값을 정의한 것을 볼 수 있다. src 애트리뷰트와 longdesc 애트리뷰트는 미리 정의된 URI 타입으로 되어 있고, alt 애트리뷰트 역시 Text 엔티티로 되어 있음을 볼 수 있다. 애트리뷰트에서 중요한 것은 디폴트 값으로 지정되는 네가지 값인데 다음과 같다.

#REQUIRED : 반드시 정의해야 하는 애트리뷰트이다.
#IMPLIED : 디폴드 값을 사용도구(웹 브라우저 등)가 지정하며, 경우에 따라 부모 엘리먼트로부터 상속 받는다. 반드시 정의하지 않아도 된다.
#FIXED : 값이 일정하여 변경이 없는 애트리뷰트이다. HTML 4.01 의 경우에는 없으나 XHTML의 경우에는 xmlns 애트리뷰트와 xml:space 애트리뷰트가 'http://www.w3.org/1999/xhtml' 값으로 #FIXED 되어 있다.

애트리뷰트 가운데에는 '참'과 '거짓'의 형태로 구분되는 불린(Boolean) 애트리뷰트가 존재하는데 'selected' ,'checked' 와 같은 것들이다.

<!ATTLIST option
%attrs;
selected    (selected) #IMPLIED
disabled    (disabled) #IMPLIED
label %Text; #IMPLIED
value CDATA    #IMPLIED
>

위와 같이 이러한 불린 애트리뷰트는 자신의 이름을 값으로 가질 수 있도록 정의되어 있다. HTML 4.01에서는 불린 애트리뷰트의 약술을 허용하고 있기는 하지만 XHTML 에서는 옮은 표현이 아니기 때문에 가급적 사용하지 않은 것을 추천한다.

나는 예전에 DL 요소의 자식요소인 DT와 DD가 순서대로 나와야 하는가? 에 대한 의문을 가진 적이 있었다. 의미적으로 DT 요소가 나온 후 DD 요소가 나타나는 것이 맞겠지만 실제로는 둘을 바꿔도 오류를 내지 않았기 때문이었고, 레이아웃을 잡기 위해서 임의적으로 포지셔닝을 하다보니 DT 요소와 DD 요소를 서로 바꾸는 것이 더 편할 때가 있었다. 그런데 잘 기억이 나지는 않지만 어떤 서적인가 사이트에서 DT 요소와 DD 요소는 순서대로 나타나야 한다고 되어 있었던 것을 본 적이 있어 혼자 고민했던 적이 있었다. 그리고는 우연히 해당 DTD 문서를 열어보게 되었는데 다음과 같다.

HTML 4.01 : <!ELEMENT DL - - (DT|DD)+ -- definition list -->

XHTML 1.0 : <!ELEMENT dl (dt|dd)+>

위에서 설명했던 내용을 토대로 이해를 해보자. DL 이라는 이름으로 엘리먼트가 정의 되었고, 시작태그와 종료태그를 모두 가져야 하며, DT 요소 또는 DD 요소가 순서에 상관 없이 한 번 이상 나타날 수 있다고 되어 있다. 순서는 문제가 되지 않았다는 것이다.

이렇게 DTD는 불확실한 정보에 대한 확신을 심어줄 수 있는 최고의 레퍼런스이다. 온전하게는 아닐지라도 대략적으로 DTD를 읽고 이해할 수 있는 능력을 키운다면 새로운 마크업 언어를 익히는 일이 두렵지만은 않을 수 있지 않을까- 그런 생각을 끝으로 DTD를 읽는 방법을 정리해 보았다.

덧붙임.

정찬명님께서 제 글을 보신 후 보다 더 자세하고 친절하게 'HTML DTD 읽기' 방법을 정리해 주셨습니다. 꼭 읽어보시길 바라겠습니다.

2008년 4월 28일 월요일

반쪽짜리 웹표준, 눈가리고 어흥 하지 마세요

겨미겨미님의 미투글을 보고 국립국어원의 웹사이트를 방문하게 되었습니다. 접속하자마자 눈에 띄는 것이 우측 상단에 위치한 음성켜기 기능과 화면 확대/축소 기능이었습니다. 이것만 봐도 이 사이트가 시청각 장애인들을 위한 웹접근성을 고려했구나함을 알 수 있었습니다. 하지만 그런 기대는 수초가 채 지나기도 전에 무너지고 맙니다.

음성지원 기능과 화면 확대/축소기능을 지원한다

국립국어원 웹사이트는 시청각 장애인을 위해서 음성지원 기능과 화면 확대/축소 기능을 제공하고 있습니다. 하지만 음성지원을 위해서는 별도의 플러그인을 설치해야 했고, Active-X 로 설치가 되기 때문에 비 윈도우(운영체제) 사용자는 활용할 수 없습니다. 이미 사용자가 스크린리더를 사용하고 있다면 음성이 두번씩 출력되는 문제가 생길수도 있겠습니다. 다행히 이에 대해서는 음성끄기 기능을 지원하고 있습니다. 특별히 아쉬운 점은 '드림보이스'나 '센스리더'와 같은 별도의 스크린리더 제품이 아닌 사이트 자체적으로 지원하는 프로그램임에도 불구하고 게시글등 웹 문서내 텍스트는 읽어주지 않는다는 점입니다. 단순히 링크 정보만 읽어주는 음성지원이라면 시각장애인이 소리를 지를수 없는 안내견을 끌고 다니는 것과 무엇이 다를까 하는 생각이 들었습니다.

또한, 화면 확대/축소 기능은 처음부터 IE용으로 제작되어서 인지 Firefox에서의 활용을 막고 있습니다. Firefox에서는 브라우저 내의 텍스트 확대/축소 기능을 사용할 수도 있지만 대부분의 사용자들이 브라우저의 이러한 기능을 잘 알지 못하고 있고, 기왕에 사이트 내에 확대/축소 기능을 구현했다면 모든 브라우저에서 사용할 수 있게 했다면 좀 더 나은 웹접근성과 사용성을 제공할 수 있었지 않나 하는 아쉬움이 드는 부분입니다.

네이버의 텍스트 확대/축소 기능은 Firefox에서도 제대로 지원된다

더군다나 CSS를 걷어내었을 때 화면은 아래와 같습니다. 헤드라인 제목부터 컨텐츠와, 바닥글 내용까지 다소 논리적이지 못하고, 선형적이지 못한 구성을 가지고 있습니다. 접근성을 제대로 살렸다고 보기 힘든 대목입니다.

마크업의 구조가 논리적으로 선형적이지 못하다.

하단의 '문화부 및 소속기관'의 풀다운메뉴는 과거의 방식대로 마우스 선택으로 옵션창을 열고, 선택과 동시에 사이트를 떠나는 방식을 택하고 있어 키보드를 사용하는 장애인과 일반인들을 위한 접근성 문제를 해결하지 못하고 있기도 합니다.

풀다운메뉴 옆에 [Go] 버튼을 누어 키보드에 대한 접근성을 살린 예

기획단계에서 어느정도 웹접근성에 대한 인식이 있었고 그로 인해 모범이 될만한 기능들을 추가했음에도 웹표준을 따르지 않은 마크업과 개발은 결국 반쪽짜리 사이트를 만들어 버린 예가 될 것 같습니다. 한국어에 대한 훌륭한 컨텐츠를 가지고 있는 이 사이트가 다음 리뉴얼때에는 보다 완벽하게 웹표준을 따라서 웹접근성을 보다 높게 지원하는 사이트가 되기를 희망해 봅니다.

2008년 4월 21일 월요일

개발자님 제발 HTML을 깨트리지 말아주세요

이 글은 서버사이드 개발자님들께서 웹퍼블리셔로부터 받은 HTML문서를 작업하는데 있어서 최소한으로 알아주셨으면 하는 내용을 정리한 것입니다. 일부분 상세히 적지 않고(버전별 요소와 속성의 사용 유무 등) 최대한 쉽게 작성하는데 목적을 두었기 때문에 실 작업시에는 웹퍼블리셔와의 커뮤니케이션과 좀 더 정확한 스펙 문서를 참고해 주시기를 부탁드리겠습니다.

웹표준화와 관련하여 웹퍼블리셔는 정확한 Doctype 선언으로부터 마크업을 시작한다. 그리고 올바른 마크업(well-formed) 검증(validate)으로 작업을 마치게 된다. 하지만 많은 경우 사이트가 오픈했을 때 validate를 통과가 어렵다. 이는 서버사이드 개발자들이 웹퍼블리셔로부터 받은 (X)HTML 문서를 수정(개발을 입히는 작업)하면서 올바르지 않은 요소와 속성을 사용하기 때문인 경우가 많다.

서버사이드 언어인 ASP나 PHP, JSP 등은 문법오류에 대한 관용이 적기 때문에 즉각적으로 에러를 보여준다. 하지만 (X)HTML은 브라우저에 따라 관용적으로 처리되거나, 용납되는 경우가 많아 올바르지 않은 마크업을 하고도 화면이 정상적으로 보이는 경우가 많다. 하지만 이렇게 완성된 사이트는 결코 웹표준 사이트라고 볼 수 없거니와, 웹접근성 또한 보장받을 수 없게 된다.

XHTML 스펙을 살펴보면 잘못된 요소와 속성의 사용을 알 수 있지만 대부분의 경우 서버사이드 개발자들은 과거에 익혔던 HTML 문법만을 기억하고 있으며(그다마 올바르지 않은 문법) 새로운 XHTML에 대한 차이를 잘 알지 못한다.

다음은 W3C의 HTML / XHTML 스펙 문서 목록이다.

다음은 XHTML 기준으로 개발자 역시 함께 알아야 하는 내용들이다.

HTML 문서의 Doctype이 무엇인지 확인한다.

HTML 4.01과 XHTML 1.0 에는 각각 'Strict(가장 엄격)', 'Transitional(전환형)', 'Frameset(프레임셋형)' 세가지 타입이 있다. XHTML 1.1은 'Strict'만을 지원하며, 표기는 XHTML 1.1로만 합니다.

Doctype에 따라 사용 가능한 요소와 속성이 구분되며, CSS에도 영향을 미친다.
Doctype 선언 위에 출력되는 요소나 문자열이 없도록 한다.

DTD는 HTML 문서의 최상단에 선언되어야 한다. 그렇지 않을 경우 일부 브라우저(IE 등)에서 비표준모드(Quirks mode)로 작동하게 된다. 일부 스타일이 제대로 적용되지 못하는 문제가 종종 발생한다.
XHTML일 경우 모든 요소와 속성은 소문자로 작성하며, alt와 title 속성을 제외하고 가능한 모든 속성에는 값을 넣어(대부분 넣지 않아도 에러가 나지는 않으나 alt와 title 속성을 제외하면 특별한 이유 없이 빈 값을 넣는 경우는 드믈다)준다. 또한, 모든 속성값은 반드시 인용부호로 둘러싼다.

validate의 에러를 가장 많이 내는 주범이다.
XHTML일 경우 모든 요소는 반드시 닫아주어야 한다. 특히 <head>..</head>사이의 <meta> 요소 작성시 반드시 닫아주자! 또한, 요소의 위치관계를 정확하게 한다.
<p>내용</p> , <br />, <img src="..." />, <meta ... />, <link rel=".." ... />

(x) <a href="..."><span>링크</a></span>
(o) <a href="..."><span>링크</span></a>
XHTML 1.1일 경우 <a>, <map>, <form>, <img> 요소에서 name 속성이 폐지되어 사용할 수 없다.

id 속성만을 사용한다. 하지만 <form>내 <input> 등 요소에서는 name 속성을 사용할 수 있다.
MIME Type이 'application/xhtml+xml'일 경우 script와 style 요소는 ''를 '<![CDATA['와 ']]>'로 대체한다. 단, 'text/html'일 경우는 과거처럼 주석 방식을 사용한다.

CDATA는 script와 style 내 '<', '>', '&'와 같은 문자를 이스케이프 시키지 않고 그대로 사용할 수 있도록 한다. 또한, Doctype에 관계없이 script요소와 style요소를 </head>와 <body>사이에 삽입하는 경우는 없어야 한다. 되도록 script와 style은 외부 문서로 빼는 것이 좋다.
XHTML 1.1일 경우 다음의 요소들은 사용할 수 없다.

<applet>, <basefont>, <center>, <dir>, <font>, <frame>, <frameset>, <iframe>, <isindex>, <menu>, <noframes>, <s>, <strike>, <u>

특히 , <font>와 <center>, <iframe> 요소는 개발자들이 무분별하게 사용하는 대표 요소인데 Doctype에 따라 사용을 신중히 해야할 필요가 있다. <font>와 <center> 요소는 CSS로 정의할 수 있으며, <iframe>요소는 <object>요소로 대체된다.
XHTML 1.1일 경우 다음의 속성들은 사용할 수 없다. (일부 속성은 XHTML 1.0 Strict 에서도 지원되지 않기 때문에 주의 바랍니다.)

<*> lnag
<a> name, target
<area> traget
<body> background, bgcolor, text, link, vlink, alink
<br> clear
<caption> align
<div> align
<form> name, target
<h1~h6> align
<hr> align, noshade, size, width
<img> align, border, hspace, vspace
<input> align
<legend>align
<li> type, value
<link> target
<map> name
<object> align, border, hsapce, vspace
<ol> compact, start, type
<p> align
<pre> width
<strict> language
<table> align, bgcolor
<td> bgcolor, height, nowrap, width
<th> bgcolor, height, nowrap, width
<tr> bgcolor
<ul> compact, type
가급적 요소에 직접 스타일(inline style)을 정의하지 않는다.

<div style="...">
단, <input>과 <img> 요소 등 개발시 변동이 잦은 요소들에 한해서 inline style로 width와 height를 지정하는 것은 괜찮다고 생각한다. 하지만 저속 인터넷 접속 환경에서는 느린 로딩으로 인해 이미지 요소들이 레이아웃을 잡지 못해 들쑥날쑥하게 전체레이아웃을 깨뜨리는 현상이 발생하기도 하므로 이에 대한 고려가 선행되어야 할 것이다.
요소와 속성내 모든 문자열을 PCDATA(분석 처리된 문자데이터)로 작성한다.

<p>LOVE & GHOST</p> ☞ <p>LOVE &amp; GHOST</p>
<a href="../../list.php?id=bomnun&val=2">링크</a> ☞ <a href="../../list.php?id=bomnun&val=2">링크</a>

* <style>과 <script>요소에서는 <![CDATA[ ... ]]>를 사용해서 문자열을 파싱하지 않고 그대로 사용할 수 있다.
XHTML일 경우 속성은 약술할 수 없다.

<input type="radio" checked /> ☞ <input type="radio" checked="checked" />
Encoding Charset이 무엇인지 확인한다.

HTML 문서는 utf-8인데, 파일 인코딩은 euc-kr인 경우가 종종 있고, 이 경우 한글이 깨져 보이는 가장 큰 이유가 된다. 또한, CSS나 JS 역시 인코딩이 다를 경우 제대로 작동되지 않기도 한다.

세세히 따지면 좀 더 있겠지만 대부분 위의 경우에 해당될 것 같다. 그리고 상위 4개 붉은색으로 표시한 것들이 validate를 통과하지 못하는 대부분의 이유가 된다. 서버사이드 개발자들이 위의 내용을 숙지만 하고 있다면(최소한 DTD의 차이만이라도 알고 있다면) 문법 오류를 최소한으로 줄일 수 있을것 같다.

이 글은 솔직히 서버사이드 개발자들을 '낚기' 위한 글입니다. 위의 내용은 이미 수차례 비슷한 주제의 블로그나 사이트를 통해서 널리 알려져 있는 내용입니다. 결국 복사된 내용의 재탕(웹표준교과서의 내용을 정리했음)이라는 것이지만 그럼에도 불구하고 서버사이드 개발자분들이 한번만이라도 관심 있게 읽어주기를 바라는 마음에 포스팅을 하게 되었습니다.

2008년 4월 5일 토요일

웹 표준 개발 프로세스

웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다. 오페라 역시 'Safari'와 같은 날 Acid3를 통과했고, 모바일 시장(휴대폰, PDA 등에 탑재되는 미니 브라우저 시장)에서의 강세를 이어가고 있다.

바야흐로 2008년은 웹표준의 전환점이 될 것으로 보인다. 그동안 은비까비가 들려주는 옛날 옛적 이야기쯤으로 치부하던 웹 실무자들도 조금씩 관심을 보이기 시작했고, 해야겠다는 생각을 하기 시작했다. 며칠전 사내 웹표준 세미나 이후 계획되어 있던 프로젝트가 곧바로 웹표준 개발로 전환되는 쾌거(!)를 이룬 것이다. 적어도 두시간 가까이 목말라가며 떠들었던 내 작은 수고가 헛되지만은 않았던 것일까.

그런데 바로 고민거리가 생겼다. 해야한다고 이연사 목청 높여~ 외쳤으나 정작 'How?'에 대한 해답을 확실히 주지 못한것이다. 세미나 직후 웹표준 개발로 선회한 프로젝트를 담당하신 기획자분이 내게 왔고, 어떻게 해요... 라고 물으시는데 참 미안해지더라. 지금까지는 웹표준을 위해서 웹퍼블리셔들이나 개발자들이 표준기술을 익혀왔고, 디자이너나 플래셔들에게는 접근성에 대한 이해를 구해왔었다. 하지만 사실 기획자를 통한 개발 프로세스의 적절성 논의에서부터 필요하다면 새로운 개발 프로세스가 필요하지 않을까 하는 생각을 하게 되었다.

한국소프트웨어진흥원에서 발표한 '실전 웹 표준 가이드(2005)'에 보면 마지막 챕터에 표준 개발 프로세스를 자세히 설명하고 있는데 이를 먼저 소개해보고, 김철수님의 웹 표준 개발 후기를 통한 문제점과 개선점 등을 고민해 보겠다.

실전 웹 표준 가이드의 '실전 표준 개발 프로세스'

기존 웹 개발 프로세스는 일반적으로 Waterfall 방식이라고 불리우는 선형적이고 밀어내기식의 프로세르를 따르고 있다.

실전 웹 표준 가이드 p183

쉽게 말해 '기획 → 시안 → 스토리보드 → 디자인 → 코딩 → 프로그래밍/디버깅'으로 이어지는 방식인데 전문적인 지식이 없더라도, 또는 프로젝트가 진행중인 새로운 인력이 투입이 되더라도 별도의 교육이 필요하지 않는 비교적 쉽고 단순한 방법이다. 때문에 웹개발 초기부터 도입이 쉬웠고 아직까지도 크게 변하지 않고 적용되고 있다.

이 방법의 문제는 ① 업무의 병목현상 ② 의존적 스토리보드 ③ HTML문서구조화의 어려움 ④ 개별 역활 중심의 프로세스를 통한 업무 과중을 들 수 있습니다.

업무의 병목현상
Waterfall 방식은 선행 프로세스가 지연될 경우 전체 프로세스의 지연으로 이어진다. 즉, 기획이 늦어지면 디자인과 코딩, 개발이 차례로 늦어지는 문제가 생긴다. 코딩까지 완료된 시점에서 기획이나 디자인이 변경되면 재코딩이 이루어지는 것도 병목현상에 한 몫 하게 된다. 아울러 프로세스상 뒤에 위치한 코딩이나 개발 인력의 프로젝트의 초기 참여율이 낮고, 둘 이상의 프로젝트에 참여하게 되면서 집중도를 낮춰 전체적인 생산성을 떨어뜨리는 경우가 생긴다.
의존적 스토리보드
스토리보드는 웹개발의 시작이고, 밑그림입니다. 그만큼 중요하죠. 문제는 디자이너나 개발자들이 지나치게 스토리보드에 의존적이라는 것입니다.

“스토리보드에는 그에 대한 지시사항이 없는 걸요” - 아주 기본적인 에러확인 로직을
스토리보드에 없다는 이유만으로 개발하지 않은 프로그래머의 반문
“저는 스토리보드에 그려진 대로 그린 것 뿐인데요...” – 디자인이 참신하지 못하다는
지적을 받은 디자이너의 변명
“어째서 스토리보드에 있는 그대로 하지 않았지?” – 발전적 창의성을 적용한
프로그래머/디자이너를 인정하지 않는 기획자의 질책

위의 예는 의존적 스토리보드의 문제점을 제대로 보여주고 있죠. 이로 인해서 기획자는 스토리보드를 수백장씩 상세하게 기술해야만 하는 업무적 과중을 느끼게 됩니다. 웹디자이너에게는 스토리보드를 그대로 Photoshop에 그려내는 '오퍼레이터'와 같은 수동적인 자세를 가지는 것도 문제가 됩니다. 또한, 전체 프로세스를 한 눈에 보여주지 못한 수백장의 스토리보드는 개발자에게 별로 도움이 되지 못합니다.

HTML문서 구조화의 어려움
HTML문서를 코딩하는 일은 관례적으로 웹디자이너의 역활로 지정되어 온 경우가 많습니다. 규모가 커지고, 웹디자이너의 부담을 줄이기 위해서 'HTML코더'라고 불리우는 직군이 생겼지만 상대적으로 낮은 대우와 평가를 받아왔습니다. 때문에 웹디자이너가 코딩을 하든, 웹개발자가 하든, 별도의 코더가 하든 HTML문서가 제대로 '구조화'되지 못하는 문제가 생기게 된 것입니다.
개별 역활 중심의 프로세스를 통한 업무 과중
기획자나 디자이너, 개발중 어느 한 직군(역활)을 중심으로 프로세스를 개선하거나 정리할 수 있습니다.
기획자 중심의 프로세스는
실전 웹 표준 가이드 p191

이 될 것이고, 디자이너 중심의 프로세스는
실전 웹 표준 가이드 p189

이 됩니다. 프로그래머 중심의 프로세스 역시
실전 웹 표준 가이드 p190

의 절차를 갖게 됩니다. 어느경우라도 XHTML 구조화(마크업)와 CSS 디자인이라는 표준 기술 영역을 포함해야 하기 때문에 업무 과중이 문제가 됩니다. 특히 과거처럼 웹디자이너에게 마크업과 CSS디자인을 맡기게 되면, 시각적인 디자인과 논리적인 디자인의 차이로 인해 오히려 좋지 않은 영향을 끼칠 수 있을 것입니다.

웹 표준 가이드에서는 위와 같은 기존 프로세스의 문제점을 지적하고 '웹퍼블리셔 중심의 개선된 모델'을 제안하고 있습니다.

실전 웹 표준 가이드 p193

보기엔 상당히 복잡해 보이지만 단순히 HTML 코딩만을 위해서 'HTML 코더'를 두었던 것과 달리 웹 표준 기술에 대한 전문성을 가진 '웹퍼블리셔'라는 직군을 포함시키면서 기획자나 디자이너, 개발자가 가질 업무의 과중을 덜어냄과 동시에 전체 프로세스의 효율성을 높이고 있다고 볼 수 있습니다.

이제 여기서 실제로 위의 프로세스를 실무에 적용했던 김철수님의 후기를 살펴보겠습니다.

김철수님의 'Storyboard - 표준 스토리보드 구상기'

김철수님은 웹 2.0 에 따른 Ajax 사용등을 고려하면서 새로운 스토리보드의 필요성을 느끼셨다 합니다. 그리고 앞서 소개해 드린 '실천 웹 표준 가이드'의 '웹퍼블리셔 중심의 개발 프로세스'를 받아들여 프로젝트에 적용하는 노력을 해 주셨습니다. 특히 김철수님은 웹퍼블리셔에게 XHTML, CSS, JS와 같은 웹 표준 기술의 전문성과 더불어 프로젝트의 실무적인 조율 능력이 필요함을 지적하고 있습니다. 그리고 다음은 김철수님께서 실제로 적용한 방법이다.

방법은 이러했다. 우선 전체가 모여 프로세스 플로우를 짜기 시작했다. 이때 사실상 전반적인 기획과 분석과 설계가 같이 진행되어서 대략 2개월 정도가 걸렸다. 그 다음에는 컨텐츠 명세서를 간단히 작성하고 곧바로 퍼블리셔를 임명하여 HTML 코딩 작업에 들어갔다. 그 산출로 나온 CSS를 디자이너가 실시간으로 확인하면서 디자인 작업을 했고, 개발자는 DB 개발과 서버 프로그램 개발을 진행했다.

그리고 다음과 같은 문제점들을 나열했습니다.

첫째, 전체가 모여 프로세스 플로우를 맞추는 것이 매우 힘든 일이었다.

둘째, 컨텐츠 명세서를 작성하는 것이 쉽지 않았다.

셋째, 퍼블리셔의 작업을 충분히 해낼 사람이 없었다.

넷째, CSS를 잘 다루는 디자이너가 없었다.

아무래도 새로운 프로세스를 직군별로 설득하고 이해시키는 일이 쉽지 않았을 것이며, 새롭게 등장한 컨텐츠 명세서를 어떻게 해야하는지 기준도 없는 상태에서 진행하기란 쉽지 않았을 것이다. 그리고 웹 표준 기술을 제대로 숙지하고 적용할 수 있는 전문적인 웹퍼블리셔의 부재는 어제 오늘의 문제가 아니고, CSS 디자인과 같은 웹 표준 기술이 요구되는 작업을 디자이너가 하기에는 무리가 있었을 것이다. 이러한 문제가 있었지만 김철수님은 나름의 노하우를 익히셨고 다음과 같이 공개해 주셨다.

하나, 사이트맵 대신 모듈맵을 만든다.

둘, 모듈 단위로 HTML을 작성한다.

셋, 최종사용자의 UX를 먼저 확정한 뒤 서버 프로그램을 시작한다.

넷, 텍스트 기반으로 먼저 만들고 나중에 세세한 디자인 요소를 삽입한다.

다섯, 위키 방식으로 모두가 개발 소스에 접근하여 수정할 수 있도록 한다.

자세한 설명은 김철수님 블로그에서 직접 확인해 볼 수 있는데, 간단히 코멘트를 하자면 전체 프로세스를 모듈화 하는 것이 중요해 보인다. 과거처럼 거대한 프로젝트를 수백장의 스토리보드에 다 담아 내는 것이 아니라, 기능별로 모듈화된 페이지를 고려하고, 그에 맞는 명세서나 차트를 만들어 개발자와 디자이너에게 전달한다. 그리고 텍스트 기반(XHTML 마크업)의 프로토탑입 설계를 함께 진행하여 디자인 이후에 있을 오류를 최소회 시켜야 한다. 또한, 개발 팀원간의 소통을 위한 도구로 '위키(wiki, 누구나 접근하여 쓰고, 지우고, 수정할 수 있는 시스템)'를 제안하고 있다. 제 의견으로는 'Trac' 의 사용을 추천해 드립니다.'Trac'는 '위키'시스템과 '포럼' 형태를 모두 가지고 있고, 버전관리와 연동이 되기 때문에 프로젝트 게시판으로 사용하기 좋은것 같습니다.

개량형 '웹퍼블리셔 중심의 웹 표준 개발 프로세스'

수정된 웹 표준 개발 프로세스

위 표는 '실전 웹 표준 가이드'와 김철수님의 후기를 읽은 뒤에 살짝 고민을 덧붙여 변형을 가해 본 것이다. 가이드에서도 밝혔고, 나 역시 미리 밝혀두는 것이지만 이러한 웹 표준 프로세스라는 것이 아직은 정형화 되어 있지 못하고, 객관적인 장단점이 불분명한 상태이다. 따라서 프로젝트의 성공 여부를 보장해주지 못한다. 다만, 웹 표준을 준수하는 웹 개발을 할라치면 이러한 고민과 적용이 필요하지 않을까 해서 시작된 것이고, 이렇게 나의 의견까지 덧붙이게 된 것이다.

'개량형'이라고는 했지만 '실전 웹 표준 가이드'에서 소개하는 내용과 크게 다르지는 않다. 용어가 일부 변경('코딩' 보다는 '마크업'이라는 용어로, 일부는 김철수님의이 제안하신 것)되었고, 프로세스가 약간은 더 복잡해졌다고 볼 수 있다. (없던 화살표가 생겼다!) 풀어서 서술하자면 다음과 같다.

기획자 : 기획자는 '실전 웹 표준 가이드'에서 제안하는 것과 같이 기획문서를 '프로세스 플로우'와 '컨텐츠 상세화'로 구분하여 작성한다. 차이가 있다면 '프로세스 플로우'와 함께 게시판이나 회원가입/로그인과 같이 모듈화가 가능한 것들에 대한 모듈 명세서 또는 모듈 맵이 함께 작성된다. 그리고 이것은 개발자에게 전달되어 프로젝트 전반에 대한 설계와 프레임 개별 모듈에 대한 설계를 할 수 있도록 한다.
디자이너 : 디자이너는 기획/분석 단계에서 만들어진 아이디어를 통해 시안과 스타일 가이드(문서 또는 준하는 이미지 파일)를 만듭니다. 그리고 기획자의 컨텐츠 상세화 문서(기존의 스토리보드로 생각하면 쉬울것 같다)를 받아 화면 디자인을 시작한다. 여기서 완성된 스토리보드를 가지고 시안을 만들지 않는다는 것은 중요합니다. '실전 웹표준 가이드'나 김철수님이 지적했듯이 상세한 스토리보드는 디자이너의 창의력을 둘러싸는 장벽이 될 위험요소가 있습니다. 때문에 기획/분석 단계에서 나온 아이디어나 컨셉 등 필요한 만큼의 적은 정보만으로 시안을 잡아 디자이너로 하여금 충분히 창의력을 발휘할 수 있도록 해야 합니다.
개발자 : 개발자는 기획/분석 단계에서 나온 아이디어와 컨셉을 통해 기술적 이슈(HTML문서의 DTD, 인코딩, 폼 영역의 ID값 등)에 대한 개발 가이드를 작성하여 퍼블리셔에게 전달합니다. 그리고 기획자로부터 '프로세스 플로우'와 '모듈 맵'을 전달받아 시스템 설계와 모듈 단위의 개발 준비를 시작합니다. 이후 퍼블리셔로부터 마크업이 완료된 XHTML문서를 받아 프로그래밍과 디버깅 작업을 진행합니다.
퍼블리셔 : 퍼블리셔는 기획자로부터 '컨텐츠 상세화 문서' 또는 '페이지 명세서'를 받아 XHTML 마크업을 시작합니다. 이때 개발자로부터 받은 '개발 가이드'를 바탕으로 XHTML 문서의 Doctype 설정, 인코딩 설정, 공통 ID값 등을 결정하거나 적절치 않을시 재논의하여 적용하도록 합니다.(한 번 결정된 Doctype이나 인코딩은 개발 과정에 쉽게 바꾸기가 어려우므로 반드시 확실히 결정을 하고 넘어가도록 합니다.) XHTML 마크업이 완료되면 개발자에게 전달하여 프로그래밍이 진행될 수 있도록 합니다. 이후 디자이너로부터 받은 '스타일 가이드'와 '화면 디자인(PSD 파일)'을 통해 XHTML 문서에 CSS 디자인을 시작합니다. 다음으로 개발자와 소통하며 완료된 페이지를 '퍼블리싱'하면서 CSS 오류 등을 잡아내는 '디버깅' 작업을 진행합니다. 마지막으로 기획자와 함께 '표준화 준수 확인'작업을 하게 되는데 '실전 웹 표준 가이드'에서는 이를 퍼블리셔의 역활로 두었으나 제 경험상 '내가 작업한 것을 내가 테스트 하는 것은 실효성이 적다'였습니다. 다시말해 내 실수를 내가 찾아내는게 쉽지 않았다라는 겁니다. 프로세스대로 디자이너와 개발자가 표준에 맞춘 일정을 따라주었다면 최종적으로 퍼블리셔의 웹 표준 기술(XHTML, CSS, DOM, JS 등)에 의한 크로스 브라우징과 접근성 문제 등이 주요 이슈로 나타날 수 있는데 이를 퍼블리셔 스스로 검증하기란 쉽지 않습니다. 따라서 애초에 기획자에게 책임을 지우는 것이 좋다는 생각을 해봤습니다. 그리고 단계적으로는 최종 단계이긴 하나 기획자는 프로젝트가 진행되는 가운데 지속적으로 디자이너와 개발자, 퍼블리셔가 표준을 준수하고 있는지를 검증해야 합니다.

특별히 부연 설명을 드리고 싶은 것은 위 표에서도 나타나 있듯이 양쪽화살표로 되어 있는 굵은 선 프로세스들입니다. 퍼블리셔를 중심으로 기획자와 퍼블리셔, 디자이너와 퍼블리셔, 개발와 퍼블리셔가 지속적으로 커뮤니케이션을 이루도록 되어 있습니다. 또 한가지 기획자와 퍼블리셔가 같은 색 영역으로 묶여 있음을 보실 수 있습니다.

김철수님도 쓰셨듯이 웹 표준 개발 프로세스에서 기획자와 퍼블리셔의 협력은 굉장히 중요해 보입니다. 1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가 작업을 줄일 수 있습니다.

디자이너가 CSS를 다루지 않는 것도 김철수님의 경우와 다릅니다. HTML이나 CSS도 모르면서 웹을 어떻게 하냐는 소리를 하곤 했지만 사실 웹디자이너에게 전문적인 수준의 XHTML과 CSS를 강요할수만은 없다고 생각합니다. (현실적으로 불가능에 가깝습니다.) 때문에 CSS 디자인 역시 퍼블리셔의 영역 안에서 해결해야 한다고 생각합니다. 실제로도 대부분의 퍼블리셔들이 시멘틱한 마크업과 CSS 작성은 자신들의 영역이라고 생각하면서 공부하고 있습니다.

아울러 개발자들이 텍스트로만 이루어진 XHTML 문서를 통한 개발에 적응할 수 있어야 한다고 봅니다. 개발 영역에서는 MVC모델이라는 것이 확실히 자리잡고 있지만 아직도 많은 경우에 XHTML문서 내에 직접 프로그래밍을 입히는 경우가 많습니다. 이 경우 XHTML문서와 서버측 스크립트 언어, CSS 등이 뒤섞여 유지보수가 매우 어려워질 수 있고, 위의 개발 프로세스도 적용하기 힘들 수 있습니다.

저는 가능하면 현재의 프로세스(Waterfall) 에서 크게 변형을 가하고 싶지는 않았습니다. 갑작스러운 변화는 오히려 효율성 측면에서 마이너스 효과를 가져올 수 있기 때문입니다. 따라서 위 표를 보면 초록색 프로세스를 중심으로 기획자는 기획문서를 만들어서 개발자와 디자이너에게 주고, 디자이너는 퍼블리셔에게 PSD를 주고, 퍼블리셔는 마크업이 완료된 XHTML문서를 건네게끔 되어 있습니다. 이는 기존의 프로세스와 크게 다르지 않습니다. 그러면서도 상호간의 커뮤니티를 강조하고 있고, 전문적인 웹퍼블리셔의 인력 확보에 포커스를 두고자 합니다.(이 부분은 구인이든 교육이든 사내에서 해결을 해야할 것으로 보임) 따라서 디자이너가 어렵게 CSS를 다루지 않아도 되고, 개발자 역시 초기 단계에서 문제가 될 만한 것들을 퍼블리셔와 미리 확실하게 집고 넘어가는 과정을 필수적으로 포함시킴으로써 개발 후에 생길 문제를 최소화 하는데 신경을 썼습니다.

지금까지 웹 표준화 프로젝트를 위한 '웹 표준 개발 프로세스'를 고민해 보았습니다. '실전 웹 표준 가이드'의 제안과 김철수님의 '표준 스토리보드 구상기'는 이미 충분히 좋은 자료가 되고 있습니다. 여기에 저의 부족한 경험과 고민을 덧붙여 약간 변형된 모습까지를 보여드렸습니다. 이미 더 좋은 방법으로 프로젝트를 진행하고 계실 분들도 계실 것이고, 더 나은 생각을 가지신 분들도 계실텐데 저에게 지적과 함께 좋은 의견을 주셨으면 감사하겠습니다.

2008년 1월 25일 금요일

XHTML로 바꾸지 말아야 하는 이유 Top5

시간제로 일하고 있는 경우
가능한 모든 브라우저나 기기에 대한 모든 버전에 맞게 여러 개의 페이지를 만들기를 즐기는 경우
머리 속에서 그냥 무조건 하지 말라고 하는 경우
웹 사업을 그만 두려고 하는 경우
XHTML을 사용할 줄 모르는 경우

<제프리 젤드만의 웹표준 가이드 2ed 발췌>

내가 HTML을 버리고 XHTML로 가고자 하는
이유는 적어도 위 다섯가지에 포함되지 않을 것이라는 확신때문이다.

어제 웹표준가이드(2ed)를 완독했다. 기술서라기 보다는 실무에서 와닿는 이해와 설명이 많은 책이었는데 우리가 웹접근성을 향상시키고, 웹표준화를 배우고, 적용하면서 왜? 왜지? 왜일까? 라고 수없이 물음표를 달았던 것들에 대한 느낌표를 달아주는 책이었지 않나 싶다.

책을 다 읽고 가장 먼저 회사의 기획자 한분께 바로 건네면서 꼭 읽어보시라고 했다.

나와 같은 웹퍼블리셔는 물론이거니와 웹디자이너, 웹개발자, 웹기획자까지
웹에서 손가락을 묻어놓고 먹고사는 모든 사람들은 꼭 한번 읽어봤으면 하는 책임에는 틀림없는것 같다.

-

다만, 급하게 번역을 하여서인지 오타도 더러 보였으며, 문장도 다소간 어색한 부분이 있어 아쉽게 느껴졌다.

페이지오프