웹 접근성을 다루는 책이 접근성이 떨어지는군..

라는 생각이 들었지만 봐야 한다는 모종의 개인적 의무감(?)에 구매하였다.

웹 접근성 & 웹 표준 완벽가이드
[원제 : Web Accessibility : Web Standards and Regulatory Compliance]
|짐 대처 외 9인 공저 | 노석준 신승식 현준호 한정민 공역 | 에이콘 (2011)

일단 책의 내용을 이야기 하기전에 개인적인 접근성에 대한 관점을 먼저 밝힌다.
이 책 본문에도

.. 실제로 세 명의 접근성 실천가들이 함께 모였을 때 네 가지 이상의 다른 의견이 있을수 있다.

쓰여 있다.
(Na!를 뭐.. 접근성 실천가라는 것이 아니라..) 이 이야기는 동의하는 바이며 Na!의 관점이 절대적으로 옳다고 주장하지도 않는다.
접근성에 대한 관점중 하나는 신체적 장애에 관심을 갖는 부분이다. WAI(Web Accessibility Initiative )차원의 관점이라 볼 수 있다. 다른 하나는 사용자 환경에 무관한 웹에 대한 접근으로 바라보는 관점이 있다고 생각한다. 이는 W3C Mission에 더 가까운 관점이라 본다. – 이를 광역 접근성 또는 보편적 접근가능성으로 말하기도 한다.
이 책에서는

..즉 ‘모든 사용자’ 측면은 장애인을 위한 접근성의 행복한 부산물이다.

라고 이야기 하고 있지만 Na!는 다르게 생각한다. ‘모든 사용자’에는 이미 장애인이 포함 되어 있으며(‘모든 사용자’와 ‘장애인’을 구분하는것 부터 보편성에대한 모순 아닐까?) ‘모든 사용자’를 위해 올바르게 웹의 정보를 구성하면 자연적으로 장애인들의 접근성도 높아진다고 생각한다. 그래서 “접근성”이란 단어는 좀더 일반 명사처럼 사용하고 신체 장애에대한 접근성은 “장애인 접근성”으로 구분하는게 좋치 않나 하는 의견이다.
좀더 과하게 말한다면 보편적 정보전달을 위해 만들어진 웹 구조에 있어 “접근성”과 “사용성”을 명확히 구분하기는 어렵다고 생각하지만 어떤 특정 대상을 고려하여 구조를 변경하고자 하는 순간부터는 그 분야는 “접근성”보다는 “사용성”쪽으로 중심이 이동한다는 의견이다.

이 책은 관점은 Na!와 달리 전자의 관점을 갖는다. 하지만 이러한 관점차는 수용될수 있는 것이라 본다. 그 이유를 다시 본문의 내용을 인용해 본다면

…. 중요한 것은 접근성 기법은 논란의 여지가 없으며 현재 웹을 통해 적절하게 서비스를 받지 못하고 차단된 아주 많은 사람들에게 도움을 줄것이다.

위의 문장에서 “웹으로 부터의 차단”의 원인요소에 대한 관심과 중심을 어디까지 들 것인가의 차이이며 그를 극복하는 방법은 크게 다르지 않기 때문에 앞서의 관점차이는 다른관점을 갖는다 해도 서로 적대할 필요가 없는 것이다. (세부 기법상에는 논란이 있을 수도 있다고 본다.)

이 책은 이번에 처음 소개되는 책이 아니라 국내에도 번역서가 나온 “웹 액세서 빌리티 : 접근하기 쉬운 웹 사이트 구축하기 – 정보문화사(2003)”의 개정판이다.

개인적으로는 책의 카피는 전번 책이 더 맘에 든다. 이번 책의 서브 카피는 “국가 표준 접근성 지침을 준수하는 웹 콘텐츠 개발”이다. (Na!는 이전판 의 카피가 접근성에 대해 좀더 능동적이라는 느낌이다. – 무정부주의적 성향인가..)

책의 내용에 대해 이야기 하자면.. 일단 이책이 완벽가이드(원제의 직역은” 웹표준과 접근성 규제 준수하기” 같은 느낌이라 더 그렇치만)라는 제목을 달았지만 일단 웹표준(물론 다룬다..)에 대한 완벽가이드를 원한다면 추천해 주고 싶지는 않다. 원제가 이 제목을 달고 있는 책이 있으니 그쪽을 참고하는것이 더 좋다고 본다. 그러나 (장애인) 접근성에 대해 관심이 있다면 매우 심도 깊은 책임이 확실하다. 심도가 깊다는 이야기는 기법상의 이야기 뿐아니라 법규(개인적으로는 법규 때문에 접근성을 구현해야 한다는데는 반대하지만)나 장애인의 사용환경 등등에 대한 이야기들을 포괄한다.

기법상에 있어서는 (HTML로 구성되는)순순 웹 콘텐츠에 대해서는 이전에 많이 출간된 웹표준서적과 크게 다르지 않다고 본다.(사실 달라질 이유도 달라질 수도 없다고 본다.) 그러나 (HTML이 아닌) 웹에 포함된 콘텐츠 플래시, PDF형식을 접근성 높이는 방법에대한 기법 소개는 다른곳에서는 접하지 못한 정보이다.
개인적으로 이 책에서 가장 잘 읽혀졌던 부분은 (솔찍히 이책이 재미있었다고는 말할수 없지 않은… ) [1장 - 웹접근성의 이해]와, [15장 재수정 사례 연구 : 대학 웹사이트 재설계 부분이다.] 이 책이 여러가지 이유로 웹저작들이 잘 읽지혀지지 않는다면 이 두 분분만 짤라서 권해 주고 싶을 정도 였다.

그러나 이 책 역시 아쉬운 점이 있다.
첫 번째는 두꺼운 번역서의 공통된 특징인지 몰라도..(앞의 책과 같이) 책의 시점이 오래됐다 (역시 2006년쯤..) 그러나 먼저 두꺼운책과는 달리 변경부분들은 역자가 주석을 달고 있다.
두 번째는 현지화에 대한 의견이다. 앞서 언급한대로 이책은 신체 장애에 주관점을 두고 접근성을 이야기 하고 있다. 그런이유로 어떤 상황에 대한 스크린 리더의 동작방식을 매우 상세히 설명하고 있다. 하지만 대상은 JAWS와 Window Eyes를 주대상으로 하고있다. 물론 기본적인 부분은 크게 다르지 않겠지만 현지화 개념으로 국내에서 많이 사용되는 제품에 대한 내용을 포함했으면 좋치 않았을까 한다.

마지막으로는 앞서도 언급했듯이 개인적 성향때문이겠지만
너무 법규에 기대는 느낌이 들었다. 책 1장 마지막 부분에 접근성 구현에 참여유도를 하는 방법에 대해 제시 할때 다음과 같은 문장이 나온다.

… 제발 비난, 위협이나 부정적으로 접근하기 보다 긍정적이고 용기를 주는 접근 방법을 사용하라.

이 책 후반에는 각국에서 제기된 접근성와 관한 소송과 이에 따라 웹접근성을 강제하기 위해 법률이 제정된 사례나 동향을 소개 하고 있다. 이런 사례를 보여주는 것은 물론 위협의 목적은 아닐꺼라 생각하며 정보의 접근이라는 것이 다른 기본적인 생활권과 같은 수준으로 올라가고 있음을 소개 시켜 주는 사례라고 생각된다. 그러나 한편으로는 소송과 법률 때문에 접근성을 구현해야 한다는 느낌을 가질수도 있다고 본다. 책의 내용에서 전판과 비교해 볼때도 상업적 비지니스적 이점은 추가된 것이 적지만(이런 사례를 발굴 홍보해야 한다고 생각한다.) 법률과 소송이야기는 매우 많이 추가 됐다.(미국이란 나라가 그런치만..) 접근성이 법률에만 의존하는 것을 반대하는 이유는 다음 문장으로 대신하겠다.

법은 최소한의 도덕이다.

법률로 하한선과 규제는 그어 줄수 있겠지만(이 책에 소개된 사례에서도 접근성을 강제하는 법률이 제정되는 목적이기도 하다.) 더 발전적 방향을 법률로 끌어 주기는 어렵지 않나 생각한다. (- 이 역시 개인적 성향 이다.)

개인적 잡설이 길었지만.. 정리해 보자면.
우선 웹접근성 이란 것 처음으로 접한다면 그닥 권하고 싶지 않다.(이책의 저자도 대상독자를 이미 접근성에 관심있는 사람으로 보고 있다.) 또한 기본적 웹표준 접근성 구현 방법을 알고 싶다해도 권하지 않겠다. (처음 언급한대로 가격이 그닥 접근성이 있는 책은 아니다.) 그리고 그러한 기본적인 정보는 무료로 배표 되고 있다. -한국형 웹 콘텐츠 접근성 지침 2.0

결론적으로 이 책은 접근성을 소개 하고자 하는 것이 아니라 이미 접근성에 대한 개념을 알고 있고 더 깊이 (어떻게 보면 학술, 법률적으로)알아보 싶은 사람들을 위한 책이라고 생각한다.

THE DESIGN OF SITES
고객 중심 웹 기획을 위한 웹사이트 디자인 패턴 107 바이블

비닐 밀봉된 책을 별로 좋아하지 않는데..
강렬한 표지 때문인지 좀 부담되는 가격임에도 불구하고 구매하였다.

The Design of Site 한국어판
[원제  The Design of Sites
: Patterns for Creating Winning Web Sites (2nd Edition)]
| 더글라스 밴 듀인, 제임스 린데이, 제임슨 홍 공저
| Yuna, 정유한, 고태호 공역 | 에이콘 (2011)

비닐 밀봉된 책은 싫어하는데.. 어쨌든
이책의 뒷면의(비닐 밀봉이라 안쪽을 보지 못했다.) 추천사에는

이 책을 참고하면 야후나 구글 같은 대기업처럼 많은 연구인력을 보유하지 않고도 성공 기업이 체득하고 사이트에 적용한 내용을 여러분의 사이트에 동일하게 활용 할 수 있다. – 아이린 오

라고 써있다.
문장 그대로는 아닐꺼라 생각했지만 일단 어느정도 기대감은 있었다.
그리고 내 생각은 맞았다. –;

이 책은 Design영어 단어를 한국어로 디자인이라 읽으면 안되고 설계 / 계획이라 읽는 것이 적합하다. 다시 말해 시각적 디자인에 관한 책이 아니다.
웹사이트를 목적에 따른 분류나 구성요소별로 설계를 위한 항목을 구분하여 설명하고 있다.
책의 구성은 마치 게임북(어렸을때 선택에 따라 책의 순서를 왔다 갔다 하며 보는 만화책 )과 같은 구성이라 아무데나 펼쳐 읽을수 있지만…

책에 대해 감상은 역자 서문에 있는 말을 그대로 인용 할 수 있다.

처음 출간된 시기만 놓고 보면 꽤나 오래된 낡은 책이라고 생각할 수 있습니다. (중략)
너무 뻔한 이야기가 들어 있는 두껍기만 한 책이라고 생각할 수도 있습니다.

“오래된 낡은 책”은 맞는 말이다. 단적인 예로 이 책에 예제로 들어진 사이트의 가장 최신 데이타는 2006년도 이다. 물론 웹에도 시간에 녹슬지 않는 철칙이나 원칙이 존재한다고 믿는다. 하지만 기술은 하루가 다르게 변한다. 이 책에서 이야기하는 사용자 중심의 디자인은 중요한 이야기이지만 그를 기술적으로 설명하는 부분은 좀 심하게 말해 쓸 것이 없다. 기술은 많이 변했기 때문이다.
책의 특징에는 Ajax, 모바일 웹,등을 다루고 있다고 소개하고 있어 마치 최신기술에 대한 추가적 정보가 있을것 같이 이야기 하지만 이것 역시 2006년도의 시점에 그치고 있다. 책의 뒷편의 모바일 웹쪽을 읽어보면 최신 동향이라기 보다는 역사서를 읽는 기분이 들 것이다.
심지어는 기술적인 구현 부분에서는 이전에 잘못 사용된 방법으로 제시하기도 하여 올바른 사전 지식이 없는 독자에게는 잘못된 정보를 제공 할 수도 있다.

오래된 책임은 본문에서도 그대로 들어난다. Flash는 어느회사 제품인가? 웹계에 최근 입문한 사람이면 Adobe라고 말할것이다. 이 책에서 Flash는 Mecro Midea사의 제품이다. (2007년 Adobe가 인수하였다.) 물론 이런건 중요한건 아니지만 본문에서 특정 URL을 직접 처볼것을 유도하는 문장이 있는데 막상 그 URL을 입력하면 이미 사이트가 없는 사이트라면 이런건 좀 주석이라도 달아 주던가 문장을 고치던가 다른 예를 사용했어야 하지 않나 싶다.

“뻔한 이야기”도 역시 맞는 이야기이다. 사실 맞는 말들은 다들 뻔한 이야기이다. 비슷한 분야를 다루는 책중 아예 표지에다 뻔한 이야기라고 써놨고 읽으면서도 그렇다고 생각했지만 개인적으로는 추천해주는 책이 있다.
관련 포스팅 : [도서]ROI(투자수익율)를 높이는 웹사이트

하지만 이 책은 좀 애메하다 . 개인적으로는 맞는 뻔한 이야기를 하는데 중복되는 내용이 많은건 뭐 반복학습의 효과를 노린것이라 생각하지만 (게임북 구성과 함께 책이 두꺼워 지는데 큰 역할을 함 ) 너무 오래된 예시와 잘못된 기술설명을 담고 있어 맞는 뻔한 이야기에 대한 인상까지 떨어트리렸다.

개인적으로 의견은..
만약 잘못된 부분(물론 2006년에는 맞는 지식이었을 수 있다.)을 걸러낼 사전 지식이 있고 5~10년전 웹사이트들이 어떻게 생겼나에 관심이 있다면 모르지만 그렇치 않다면 최근에 나온 다른 책을 보길 권한다. 이 책 가격이면 잘하면 두권도 살 수 있다.

덧 -
책 앞쪽에 “오디언스”라는 단어를 번역하지 않고 그대로 사용하고 있는데 뭔 의미인지 잘 파악이 안된다.. –;

모바일에 대한 관심은 웹 개발 쪽도 예외가 아니다.
아이폰과 안드로이드폰으로 대표되는 모바일기기들은 비교적 성능이 좋은 웹브라우저를 탑재하고 있으며 이를 기반으로 HTML5라 이야기되는 웹기술을 이용하여 모바일 UI를 구현하기 위한 다양한 javascript UI 프레임워크가 발표되었다. 그리고 그러한 프래임 워크중 주목도가 높은 3가지를 소개하는 책이 출간 되었다.

jQTouch, jQuery Mobile, Sencha Touch 프레임워크 활용하기

시작하세요! 모바일 웹개발 | 박종명 저 |위키북스(2011)

웹이란 원래 부터 장치독립적인 정보전달의 수단이다.
그러므로 개인적으로는 “~용 웹” 이란 말 자체가 웹이 가진 본질은 잘 파악하지 못한 용어라고 생각한다.
그러나 현실적으로는 웹에 담긴 정보는 어떤 특정한 형태로 “표현”되어야 하므로 정보를 요청하는 도구의 특성에 따라 좀더 보기좋게 또는 사용하기 편하게 제공해야 하는 요구가 있을것이다.
위의 이야기를 좀더 세분화 하여 기술적으로 이야기 한다면 “~용 HTML의 구성”은 바람직하지 않치만 “~용 CSS”는 유용하다라고 할 수 있겠다.

하지만 이 책에서 소개 하고 있는 도구들이 모바일 UI프레임워크라 불리우는것 처럼 HTML을 UI의 구성을 위해 사용하게 된다. 개인적으로는 HTML은 정보를 구성하는데 집중해야 한다고 생각하며 그것은 모바일에서도 동일하다고 생각한다. 그렇다고 다고 해서 모바일 프래임워크를 반대하는 입장은 아니다.(이미 모바일 UI프레임워크를 이용한 프로젝트 하나를 끝내서 오픈했다.) 정보 구성은 콘텐츠가 있어야 가능한 것 이기 때문에 콘텐츠가 없는 상태에서 의 HTML구성은 배치의 프래임일수 밖에 없기 때문이다. 그리고 모바일이란 좁은 화면의 제약적환경이 역으로 콘텐츠의 배치의 선형화를 강제하는 부분도 있다고 본다. 이런 이유로 어떤 프래임워크는 잘 사용하면 정보구성쪽으로도 좋은 영향을 줄수 있다고 본다.

jQTouch

jQTouch는 간단한 코딩으로 iPhone과 유사한 UI를 생성해 준다. 이 책에서 소개된 프래임 워크중 가장 간단하며 이해하기도 쉽다. (우리팀이 사용한 프래임 워크이기도 하다.) 화면을 구성하는 방법도 기존 웹사이트 개발하는 방식과 동일하게 특정요소에 class를 지정하고 CSS를 이용하여 외형을 구현한다.
다음은 jQTouch에서 화면 하나분을 구성하는 기본 코드이다. (Na!의 블로그에는 되도록 코드는 피하는데.. 내가 몰라서.. )

<div id="home" class="current">
  <div class="toolbar">
    <h1>제목열</h1>
  </div>
    <!--콘텐츠가 들어가는 부분-->
  <div class="info">
    <p>하단부분</p>
  </div>
</div>

앞서 이야기한 바와 같이 jQTouch는 class를 기반으로 작동하므로 “toolbar”나 “info”와 같은 사전에 예약된 class 이름으로 화면구성한다. 그러므로 이 예약 class의 속성을 재지정하면 원하는 디자인으로 쉽게 바꿀수 있다는 장점이 있다.
그러나 jQTouch는 iOS에 최적화 되어 있어 안드로이드에서는 일부기능이 정상적으로 작동하지 않는것 있으며 다른 프래임워크가 폰 화면 사이즈 뿐아니라 탭류의 화면 사이즈도 지원하려 하는데 비하여 jQTouch는 공식적으로도 폰 화면에만 집중하고 있다고 한다.

jQuery mobile

jQuery mobile는 그 이름 처럼 javascript 프래임워크인 jQuery를 기반으로 작성된 mobile 프래임 워크로 jQuery팀이 직접 제작한다고 한다.(물론 jQtouch도 jQuery 기반이다.) 간단히 보기에는 jQTouch와 상당히 유사하게 보이지만 내부적으로는 좀 다른 접근 방법을 가진다. jQuery mobile은 HTML5에 사용자 정의 속성을 위해 추가된 data-*속성을 기반으로 동작한다. 다음은 jQuery mobile에서 화면 하나 분을 구성하는 기본 코드이다.

<div data-role="page" id="page">
  <div data-role="header">
    <h1>제목열</h1>
  </div>
  <div data-role="content">
    <!--콘텐츠가 들어가는 부분-->
  </div>
  <div data-role="footer">
    <h4>하단부분</h4>
  </div>
</div>

페이지를 구한한 코드만을 볼때는 “class”가 “data-*”로 대치된것 외에는 jQTouch와 크가 다를 바 없어 보인다. 그러나 앞에서 이야기 한대로 “data-*”는 HTML5 에서 추가된 사용자 정의 속성을 사용하기 위한 속성으로 화면의 구성과는 무관하다 jQuery mobile은 여기에 지정된 속성값을 조회하여 화면을 구성하기 위한 추가적인 속성 뿐아니라 필요에 따라서는 HTML을 구성 한다.
다음은 위의 코드를 jQuery mobile이 브라우저에 표시하는 실제 코드이다.

<div id="page" data-role="page" data-url="page" class="ui-page ui-body-c ui-page-active">
  <div data-role="header" class="ui-bar-a ui-header" role="banner">
    <h1 class="ui-title" tabindex="0" role="heading" aria-level="1">제목열</h1>
  </div>
  <div data-role="content" class="ui-content" role="main">
    <!--콘텐츠가 들어가는 부분-->
  </div>
  <div data-role="footer" class="ui-bar-a ui-footer" role="contentinfo">
    <h4 class="ui-title" tabindex="0" role="heading" aria-level="1">하단부분</h4>
  </div>
</div>

원래의 코드보다 많은 것이 추가 되었음을 볼수 있다. 위의 예는 페이지 구성의 간단한 예로 속성만 추가 되었으나 구성요소에 따라서는 tag구성자체를 재 생성하는 경우도 많다.
이와 같은 이유로 class 기반의 jQTouch에 비해 임의적인 디자인을 적용하기위해서는 좀 더 학습이 필요하다. 하지만 jQuery mobile은 jQTouch에 비해 많은 기능을 제공할 뿐아니라 Beta로 넘어오면서 (책은 alpha 3를 기준으로 한다.) 반응형 디자인을 이용 탭 디바이스를 지원하기 시작하였다. 지원하는 환경도 iOS 뿐아니라 안드로이드는 물론 삼성의 모바일OS인 바다등 다양한 OS를 지원하고 있으며 드림위버 5.5에서 공식 지원하는등 기대되는 프래임 워크중 하나이다.

jQTouch와 jQueryMobile을 좀더 구조적으로 사용하기

개인적으로 두가지 프래임워크를 테스트 하면서 HTML5기반이라고는 하지만 실질적으로 사용되는 구성은 HTML5답지 못하다고 생각했다. 두가지 프래임 워크 모두 기본적으로 하나의 파일안에서 구역을 나누어 페이지처럼 구성하고(<section>) 각 페이지역할을 하는 부분은 기본적으로 제목열을 하는 부분(<header>)과 실제 콘텐츠 영역(<article>) 하단영역(<footer>)으로 구성된다. 이를 HTML5에서 추가된 정보구조용 태그를 사용하면 좀더 구조적으로 사용할수 있다고 생각한다.
다음은 우리팀이 사용한 jQuery Mobile을 위한 페이지 구성의 기본 코드이다.

<section data-role="page" id="coforwardHome">
  <header data-role="header">
    <h1>제목열</h1>
  </header>
  <article data-role="content">
    <!--콘텐츠가 들어가는 부분-->
  </article>
  <footer data-role="footer">
    <h1>하단 영역</h1>
  </footer>
</section><!-- End of #coforwardHome -->

실재로 jQTouch와 jQueryMobile는 해당 영역을 구성하는 tag의 종류와는 관계 없이 “class”나 “data-*” 속성을 기준으로 작동하므로 반드시 <div>를 쓸 필요는 없다. 위와 같이 HTML5의 구조적 tag를 사용함으로써 정보구조를 강화하면서도 UI프래임워크를 사용할 수 있다.

Sencha Touch

Sencha Touch는 앞서 언급한 두개의 프래임 워크와는 접근 방식이 상이하다. jQTouch와 jQuery mobile이 웹을 위한 모바일 기기에 맞는 UI를 구성해준다면 Sencha Touch는 웹기술을 이용하여 모바일 기기를 위한 UI및 기능을 작성한다는 쪽이 더 어울린다.
Sencha Touch는 ExtJs라는 javascript 프래임워크를 기반으로 한다. jQuery Mobile이 jQuery를 기반으로 하지만 기본적인 구성은 HTML로 하는데 반하여 Sencha Touch는 구성자체를 ExtJs로 한다.(물론 결과적으로는 HTML+CSS코드가 되지만 코딩시에는 한줄도 쓰지 않을수도 있다.)
극단적으로 말해 Sencha Touch의 예제 페이지의 HTML소스보기는 다음과 같다.

<!doctype html>
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title>Kitchen Sink</title>

  <script type="text/javascript" src="../../sencha-touch.js"></script>
  <!-- 기타 javascript link 생략 -->
  <script type="text/javascript" src="src/structure.js"></script>
</head>
<body>
</body>
</html>

코드에서 보는 봐와 같이 일반적인 웹사이트의 구성이라 보기는 어렵다. 또한 지원하는 환경역시 iOS, 안드로이드, 블랙베리의 일부 버전이다.
그러나 Sencha Touch는 독립적인 데이타 처리 규격을 내장하고 있으며 최근에는 차트생성도 지원하는등 어플리케이션 관점에서 본다면 앞의 두 프래임워크보다 확연히 뛰어난 기능을 가지고 있다.
정전식 멀티터치를 지원하는 모바일 기기에서 가능한 이벤트의 지원역시 세 프레임 워크중 가장 뛰어나다. 그러나 일반적인 웹사이트(물론 아주 불가능한것은 아니지만)보다는 역시 PhoneGap등과 사용되어 하이브리드 웹앱을 작성할 목적으로 만들어진 것이라 보인다.
jQuery mobile은 HTML정보를 기초로 프래임워크가 HTML구조를 일부 변경하는 데 반하여 Sencha Touch는 ExtJs가 모든 HTML과 CSS를 생성해 내게 되므로 이를 커스터마이징하는것은 jQuery mobile보다 어려울 것이다.
보수적인 웹의 정보구조의 관점에서 보면 Sencha Touch의 방식이 바람직해 보이지 않을 수도 있다. 그러나 공개된 웹기술로 네이티브가 제공하는 UI와 비교될만큼 멋진 UI를 만들수 있다는 점은 웹기술의 사용범위를 넓힐수 있는 가능성을 보여준다고도 볼 수 있겠다.

책 이야기로 돌아와서..

이 책 “모바일 웹 개발”은 위와 같은 세가지 모바일 UI프레임워크에 대해 비교적 상세히 소개 하고 있다. 모바일 UI 프레임워크의 관심도에 비해 잘 정리된 자료를 찾기는 사실상 힘들었다. Sencha Touch는 비교적 잘 되어 있다 하지만 그역시 언어적 장벽이 있었고 그외는 단편적 정보들이고 결국 하나하나 시행착오를 거쳐야만 어느정도 감을 잡을수 있었다. (적어도 Na!는 그랬다.)

“모바일 웹 개발”은 3가지 주요한 모바일 프래임워크를 소개 함으로 각각의 특성을 파악하고 자신의 과업에 맞는 도구를 선택하는 데 도움이 될수 있다고 생각한다. (개인적으로 좀 일찍 나왔으면 우리 프로젝트의 삽질을 줄일수 있지 않았을까 하는 아쉬움도 있다. )

HTML5 & 웹표준 컨퍼런스 2011
일시 : 2011년 7월 5일(화) ~ 6일(수)
장소 : 강남역 한국과학기술회관 B1F 중회의실
주최 : 플루토 미디어

그리고 어째서, 어떻게 알고, 무슨 기대인지 모르겠지만 주최측에서 Na!에게 하나의 세션 발표를 의뢰해왔다. 의뢰된 주제는 “다양한 디바이스별 웹표준 적용 가이드 및 사례” 였고 coForward PM으로 내 소속과 직위가 표시 되어 있었다. 미루어 생각해 볼 때 아마 하나의 코드로 모바일과 PC를 대응하는 우리 팀 coForward 사이트 때문이것 같다.

사전에 보내준 자료에 강사진을 봤을때..

Na! 낄 수 있는 자리가 아닌것 같은데..

라는 고민이 있었지만 Na!개인과 우리팀에게 기회가 될수 있을것 같다 생각하여 참가하기로 했다.

Na!에게 주어진 시간은 첫날 4번째 세션으로 주최측에서 의뢰한 주제를 기반으로 평소 생각과 우리팀 사이트의 구축 사례를 간단히 소개 했다.

다음은 발표 자료..

안녕하세요? Na!입니다.

언제가 부터 복사해서 그냥 쓰는 자기소개 (정체 되었다는 증거..?)

HTML5 무엇을 위한 변화인가?

HTML5에 대한 관심이 높아져가고 있는건 하나의 흐름이지만 많은 경우 관심의 관점이 좀 좀게 보고 있지 않나 하는 생각이 있었다.
그래서 HTML5 전반에 대해 짚고 시작하고자 하였다.

10년 만에 찾아온 큰 변화

웹의 근간을 이루는 HTML은 1990년대 초반에 세상에 등장하여 2000년까지 10년동안 4번의 큰 버전 업이 있었으며 느슨한 규칙이었던 HTML을 좀더 규격화하려는 XHTML로의 이전을 시도 하였다. XHTML의 시멘틱웹의 이상은 높았으나 XHTML1.0이후 이렇다할 변화가 없이 웹 표준 기술은 정체 되어 있었다
그러나 (표현이 적절한지 모르겠으나..)웹 시장 자체는 웹기술이 정체 되었던 시기에도 빠르게 변화 발전하였다. Web2.0, Ajax, SNS등등.. 웹 시장에서는 웹 표준 기술을 넘어서는 확장과 발전이 이루어 지고 있었다. 이러한 환경에서 시장에 별 관심 없는 웹표준 제정기관인 W3C의 XHTML2.0에 반발하는 몇몇이 WHAT WG를 결성 기존의 HTML을 웹어플리 케이션 관점으로 확장하고자 하는 시도를 시작하였고 많은 브라우저 밴더들이 참가, 결국 W3C도 이러한 흐름을 인정하고 XHTML2.0을 중단 WHAT WG의 스펙을 받아들여 HTML5표준안으로 제정하기로 하였으며. (이건 뒤에서 좀더 이야기 한다.) 어느정도 모습을 갖춰가고 있다.
웹 시장에서는 여러가지가 변화하였지만 웹의 근간을 이루는 HTML의 관점에서는 거의 10년 만에 찾아온 큰 변화라고 할수 있는 것이다.

HTML5 VS Flash?

HTML5를 소개할때 종종 나오는 것 중 하나가 “플러그인 없이~” 라는 이야기이다. 또한 스티브 잡스가 adobe의 Flash를 까면서 HTML5를 Flash의 대치 할 것 처럼 이야기 한 것이 마치 HTML5가 Flash와 경쟁하는 구도처럼 이야기 되는 경향도 있다.
물론 HTML5라 이야기 되는 기술들이 기존에는 플러그인을 이용하여야만 가능했던 기능들을 구현 할 수 있다는 것은 사실이지만 그것이 HTML5의 전부는 아니다.

HTML5라 부르는 것들

사실 요즘 HTML5라는 단어는 마치 몇년 전의 Web2.0과 비슷한 양상을 보인다고 생각한다. 그냥 쉽게 HTML5라고 이야기 하지만 그안에는 상당 수의 독립된 기술들이 포함 되어 있어 차세대 웹기술 전반을 HTML5로 통칭하는 경향이 있는것 같다.
그중에서도 기존 HTML에는 없던 개념인 API들이 주목받고 있으며 CSS3나 SVG처럼 독립된 기술 표준도 HTML5 라는 단어로 총칭되고 있다.

HTML5를 바라보는 시선

HTML5가 다양한 기술을 포함하여 이야기되기 때문인지 HTML5를 바라보는 시선 또한 다양하것 같다.
(요즘은 좀 들어간 의견 같지만..) 일단 완성되지 않았으며 브라우저 지원이 잘 되지 않기 때문에 도입하기는 아직 시기 상조이며 제한적으로 (Webkit 계열이 과점하고 있는) 모바일 브라우저를 대상으로 사용할 수는 있다라는 이야기를 많이들 들어 봤을 것이다. 또한 이러한 특징을 이용하여 모바일용 앱을 HTML5로 작성하는 기술들도 많이 나온 상태이다.
또한 API라는 새로운 개념이 추가되고 이것들이 주목 받으면서 HTML5는 기존 HTML과는 다른 무엇이라고 바라보는 관점도 있는듯하다.

HTML5는 혁명이 아닌 진화

하지만 개인적인 생각은 HTML5는 혁명이 아닌 진화를 선택했다고 생각한다.
앞서 HTML의 발전과정에서 W3C는 XHTML2.0으로의 이행을 추진하고 있었으며 HTML5의 시작은 이에 대하여 다른 생각을 가진 그룹을 통해 시발 되었다.
XHTML2.0는 기존 HTML과의 호환성을 포기하면서 까지 데이터로서 가치 있는 웹를 구성하는 방향을 제시하면서 결국 시멘틱 웹이란 이상을 향해 나가려고 했다.
그에 반해 HTML5는 기존의 HTML과의 호환성을 유지한 체 웹의 기능을 확장하려하였으며 웹 어플리케이션을 지향 한다.
결국 과격한 혁명은 연구소(W3C)의 XHTML2.0이 하고자 하였으며 이를 진압하고 점진적 진화를 택한 것은 시장(웹브라우저 밴더)의 HTML5 였다.
이러한 이유로 웹브라우저 밴더들이 주도적으로 HTML5규격을 만드는 일에 참여하고 있어 브라우저 지원이 하루가 다르게 빠르게 이루어 지고 있다. 반면 자사가 미는 기술을 일단 자사에 브라우저에 먼저 구현하고 표준안으로 제출하여 마치 밴더표준같은 부분들이 생기고 있는 과도기적 현상도 있는것 같다.
이처럼 발전해가는 방법에서 서로 차이가 있었지만 웹를 바라보는 큰 방향은(정보의 보편적 전달) XHTML2.0과 HTML5모두 동일하다고 생각한다.

HTML5 tag

앞서 언급한대로 HTML5란 단어는 기존에 없었던 개념과 독립된 표준을 포괄한 차세대 웹기술의 대명사 처럼 사용되고 있다. 그래서인지 API CSS3등의 기술에 관심이 높은 반면 웹의 뼈대를 이루는 HTML tag들에 대한 관심은 비교적 덜한것 같다.
순수하게 HTML4에서 버전업을 한 것은 HTML5 tag들이다. 이것들이 웹사이트의 기초를 만들고 이 위에 API등을 사용하여 새로운 기능들을 올릴수 있는것 이므로 HTML5 에서도 올바른 tag의 사용은 중요하다

HTML5 에서 추가된 tag

HTML4에서 HTML5로 진화하며 꽤 많은 tag들이 추가 되었다.
추가된 tag의 성격을 본다면 새로운 콘텐츠형태를 표시하기 위한 요소 (<video>, <audio>,<canvas> 등)와 웹 어플리케이션을 위한 기능적 요소(<progress>,<command>,<output> 등)들이 있다.
하지만 가장 많은 부분을 차지 하는것은 정보구조를 구성하기 위한 요소(<section><hgroup><footer> 등)들이다.
정보구조를 구성하기 위한 요소들이 새로운 표현과 기능을 위한 요소들 보다 보여지는 무엇이 없어 흥미가 덜할 수 있겠지만 웹의 목적(보편적 정보전달)를 생각해본다면 그 중요성을 알 수 있을것이다.

HTML5 구조를 이해 하는 브라우저들

HTML5가 진화를 선택했고 표준제정에 브라우저밴더들이 적극적으로 참여 해서인지 HTML5의 지원은 생각보다 빠르게 이루어 지고 있다. 둥근 모서리가 어떤브라우저에서 되고 안되고도 중요하겠지만 여기서는 HTML5가 생성해내는 정보 구조를 브라우저가 어떻게 파악하는지를 이야기 해보자
왼쪽에 있는 소스코드에서 표시되는 텍스트요소는 모두 <h1>이다. 그리고 콘텐츠의 레벨구조는 HTML5의 구조용 태그를 이용하여 구성하였으며 CSS는 전혀 적용하지 않은 상태 이다.
각 브라우저 밴더의 최신 브라우저들은 똑같은 <h1>를 HTML5의 구조용 태그의 구성로 구성된 레벨을 적용하여 서로 다른 크기로 렌더링 한다. 즉 이미 브라우저들은 HTML5의 정보구조을 이해하고 있다는 것이다.
기계와 소프트웨어가 HTML의 콘텐츠 좀 더 구조적으로 이해한다는 것은 정보를 사람의 손을 거치지 않고 응용할수 있는 분야들이 증가 될 수 있다는 것을 의미하며 이는 매우 중요한 변화고 생각한다.

하나의 구조로 다양한 표현 – 1

발표의 주제가 멀티 디바이스 대응가이드인데 HTML에 대한 기본적인 이야기만 한 이유는 사실 그게 다이기 때문이다. 하나의 데이터를 여러형태로 보여주기 위해 가장 중요한것은 HTML의 정보 구조이다. 사실 우리는 이미 그러한 예를 오래전 부터 봐 왔다. CSS Zen Garden – 하나의 HTML에 CSS를 변경하여 전혀 다를 외향을 보여주는 이사이트는 웹표준과 CSS에 관심 있는 사람이라면 한번쯤을 살펴보았을 사이트이다.

하나의 구조로 다양한 표현 -2

CSS Zen Garden이 PC용 브라우저 안에서 다양한 외향을 보여주었다면 CSS3에 추가된 media Query는 기기에 따라 다른 외향을 보여줄수 있도록 해준다.
하지만 이러한 기능역시 전혀 새로운것이 아니다. 이미 CSS에는 PC용 화면이 아닌 다른 매체로의 출력의 형태를 제어 할수 있는 기능이 있었다. media 속성을 이용하여 프린트용 디자인을 지정해주는것과 근본적으로 다를 것이 없는 것이다.
이러한 기능은 미래의 이야기가 아니라 지금 사용될수 있는 기술들이며 media query는 웹저작도구인 드림위버에서는 쉽게 작성하고 확인할수 있는 기능이 이미 탑재 되어 있다.

N-screen 시대와 HTML5

발표의 주재인 멀티디바이스에 관한 이야기를 하고자 하였으나
이 역시 원론적인 이야기가 되었다.
멀티디바이스를 대응 하는 효과적인 방법은 HTML5의 특별한 기능를 이용하는 것이 아니라 장치 운영체제 독립적으로 정보를 전달하고자 만들어진 웹의 기본적인 특징을 이용하는것 이기 때문이다.

웹을 요구하는 것들

한때 PC-TV-Mobile Phone을 연계하는 “3 Screen 전략”이란것이 유행했었다. 하지만 이 전략은 불과 1~2년을 유지 하지 못하였다. iPad로 대표 되는 새로운 형태의 디바이스가 출현하여 “3″라는 숫자가 의미가 없어졌기 때문이다.
이처럼 PC를 벗어나기 시작한 Web은 생각보다 빠르게 진행되고 있다.
앞으로 얼마나 다양한 기기에서 웹(또는 네트워크 상의 정보)를 요구하게 될지 아무도 모르게 되었다. (N-Screen이라 부르고 있지만 Screen도 조만간 다른 단어로 변경되지 않을까 한다. N-media?)
그러므로 하나의 정보를 다양한 형태의 기기에 효율적으로 전달할수 있는 방법을 생각해야 했을 것 이다. 그리고 많은 IT기업들 찾은 해결책은 원래 부터 그러기 위해 존해 했던 웹표준 기술인 것 이다.

N-screen대응에 있어 웹 표준 기술의 이점

다양한 기기를 지원하는데 있어 웹표준 기술이 주목받을 수 있는 이유는 One-Source Multi Use에 있을 것인다. 하지만 Muli Use를 위한 Source를 제작하는데 있어 엄청난 비용이 필요하다면 의미가 없을 것이다. 쉽게 말해 아이폰과 안드로이드를 한번에 지원하기 위한 어떤코드를 만드는데 소모되는 비용이 object C와 java로 각각 개발하는 비용보다 높다면 One-Source Multi Use의 의미가 없다는 이야기이다.
다행이도 웹표준 기술로 멀티 디바이스에 대응하기 위한 방법 새로운 것이아니다.
접근성을 높이고 분리된 구조를 사용하며 콘텐츠에 집중하라 같은 모두 알고 있는 내용인것인다.
(접근성의 대상을 “장애인”에서 “장애인들이 사용하는 도구도”라고 바꾸면 이 글의 내용의 전부이다.)
하지만 우리의 웹 제작 환경은 위의 알고 있는 기술과 방법을 제약적으로만 생각해왔지 않은가 한다. 사실 위의 방법이 효율을 위한 것이며 기회를 만들어 주고 있는 것이다.

사이트 구축의 진행

일반적으로 웹사이트는 사이트의 운영 목적과 사용자의 요구를 분석 통하여 정보구조와 사용절차를 설계하고 이를 특정한 형태로 만들어 지게 된다.
위 그림은 Jesse James Garret의 The Elements of User Experience(2002)라는 책에 실린 도식을 재 구성한 것으로 앞에서 언급한 내용을 잘 표한하고 있다고 생각한다. 특히 웹사이트의 성격을 하이퍼 텍스트로서의 기능과 소프트웨어 인터페이스의 기능을 나누어 설계를 진행하여야 한다는 점은 웹어플리케이션의 성격이 강해지는 HTML5시대에서 더욱 중요한 점이라 할수 있겠다.

설계의 진행방향

사이트의 구축의 진행에서 언급한바와 같이 사이트의 구축은 “목적과 요구분석” > “정보 절차 구축” > “디자인 형태 구성” 순이다.
하지만 우리의 웹 설계과정의 위의 구축 방식과는 좀 양상이 다르다. 하위 단계가 확정되지 않은 상태에서 형태(소위UX)가 결정되고 하위 구성이 이를 맞춰 가는 형태의 설계가 이루어 지곤 한다. 이러한 방법이 정보(contents)가 제공되는 형태(divice)가 한가지일 경우는 별 문제가 없겠지만 N-Screen에 대응하기 위해서는 형태별로 하위 구성을 모두 변경해야 하는 사태가 발생하게 된다.
그러므로 웹사이트의 설계의 절차는 정보구성및 절차설계를 Universal Design적 관점에서 진행하고 그를 웹 표준 기술로 구성하며 그위에 제공 형태를 설계하여야 한다.
이러한 구성은 웹의 정보를 담고 있는 HTML과 기타 형태와 부가적 기능을 담은 요소와는 분리된 구조로 작성하여야 한다.

분리된 구조를 사용하여야 하는 이유

분리된 구조를 사용하는 이유는 무엇일까?
웹사이트에는 그사이트의 목적을 담은 핵심 정보가 있다. 그리고 그정보를 요청하는 기기는 다양화 되가고 있다. 어떤 기기는 핵심정보 이외의 모든것이 무효화 되거나 또는 방해가 되는 경우도 존재 한다. 또 지금은 미미하지만 접속비중이 높아져 새로운기기에(예를 들자면 스마트 TV같은) 더 좋은 인터페이스를 제공해야 할경우도 있을 것 이다. 이때 잘 분리된 구조를 작성된 사이트는 핵심정보의 구성을 크게 변경하지 않고 인터페이스를 구성하는 부분만을 변경하여 제공할 수 있을 것이다.

작업 프로세스 제안 – 시안 위주의 웹 저작 프로세스

앞서와 같은 웹사이트의 구성은 웹저작 프로세스 어느 한곳에서 이루어 지는 것이 아니라 프로세스 전반에 걸처 이루어져야 한다.
핵심정보와 제공형태가 분리되어 다양한 형태로 제공될수 있는 사이트를 작성하기 어려운 이유는 우리나라에서 많이 사용되는 시안 위주의 저작 프로세스에 있다고 생각한다. 이러한 제작 방식이 장점도 존재하기 때문에 많이 사용되겠지만 여기서는 문제점을 주로 짚어 보고자 한다.
많은경우 기획단계에서 주요한 산출물은 스토리보드(라 불리우는 와이어 프레임)이다. 물론 스토리보드는 중요한 설계문서이지만 와이어 프레임 뿐이라면 이는 시안 스케치의 역할이 가장 크다. 그렇기 때문에 시안이 작성되고 나면 와이어 프램임은 설계문서로써의 영향력이 급감 하게 된다. 시안이 나오면 그에 따라 HTML과 CSS구성을 하게 되는데 이때 형태적 요소가 HTML구성에 간섭을 하게 되어 정보구조가 간결하게 되지 않고 완전 분리된 구조가 잘 이루어 지지 않게 된다. 서버 사이드 개발은 앞단의 절차를 기다려야 하며 정보구조와 절차가 완전하지 않은 상태에서 완성된 시안은 변경이 많을수 밖에 없고 그 변경에 따라 프로세스 전반이 재 작업 되는 경우가 많다.

작업 프로세스 제안 (계속) – HTML구성 위주 프로세스 제안

위와 같은 단점을 극복하기 위한 방안으로 개인적으로 HTML구성 위주의 프로세스를 제안해 왔다. 기본적인 흐름은 다음과 같다.
1. 기획안은 화면의 구성보다는 콘텐츠의 중요도와 절차위주로 설계문서를 작성하고 이에 따라 뼈대가 되는 HTML(이하 Core)을 구성함.
2. Core구성을 협업자들과 공유하며 시안작업과 중요 비지니스로직의 서버사이드 개발을 진행함 기획단계에서는 콘텐츠의 중요도가 완성되었으므로 시안은 중요 콘텐츠를 지원되는 형태로 작성될수 있는 가능성이 높으며 디자인상 요구되는 class등은 Core 구성을 해치지 않는 방향으로 추가할 수 있음
3. 비지니스 로직은 시안을 기다리지 않고 Core를 기준으로 작성을 진행하므로 프로세스를 병렬화할 수 있으며 시안의 변경에 크게 좌우되지 않음

이러한 절차을 도입하는데 있어 문제점(?)이라면 웹저작 단계의 특정 분야 뿐아니라 프로젝트 그룹전체가 웹표준에 대한 이해가 필요하다. 이런 사족을 다는 이유는 웹표준이 마치 특정 직군(퍼블리셔라 불리우는..)만 알면 되는 기술처럼 여기는 웹저작자들이 많다고 생각하기 때문이다.

사례소개

앞에 까지 이야기 했던 뻔하고 다아는 이야기가 어떻게 적용 될 수 있는가를 우리팀이 팀사이트를 작성한 사례로 소개 하였다.

사이트 개요

coForward사이트는 간단한 구성의 팀홍보 사이트로 최초 HTML5의 테스트 프로젝트로 시작하였으나 실제 운영하는것으로 변경하였다.
테스트 프로젝트로 시작하였으므로 HTML5를 적용한 정보구성(Outline) CSS3의 동적 효과를 적극도입, canvas등의 신기술도 사용해보기로 했다.
제작 방식은 앞서 언급한 콘텐츠 중심의 제작 프로세스를 적용하여 디자이너 2명과 기획자 1명이 기본업무를 병행하며 약 1달정도의 기간을 작업하였다.

사이트 설계

기획에서는 사이트에 들어갈 콘텐츠를 결정하고 결정된 콘텐츠를 기본으로 뼈대가 되는 core HTML을 구성하였으며 콘텐츠의 성격을 구분하였다.
이 작업에서는 와어프레임은 작성하지 않았으며 위와 같은 내용과 기획자가 원하는 디자인방향 (- 마우스오버로 작동하는 2단계 메뉴는 쓰지 말자. 가급적 텍스트는 텍스트로..) 에 대해 디자이너에게 전달하였다.

페이지 구성과 OUTLINE

앞의 설계문서로 작성된 실제 페이지는 디자인을 위한 추가 요소들이 포함되었었다. 하지만 정보구조는 사이트 설계문서와 달라지지 않았다.
HTML5의 outline을 추출해주는 사이트나 추가 기능으로 확인한 완성된 사이트의 정보 구조는 기획단계의 그것과 일치 한다.

HTML5 적용 교훈

HTML5를 이용하여 사이트를 작성하면서 배운 교훈은 HTML의 구성은 화면 구성이 아니라 콘텐츠를 따라야 한다는 것이다. 이는 이전 버전의 HTML도 동일하지만 HTML5가 되면서 더 중요해지고 Outline이라는 확인 할 수 있는 방법도 생겼다.
또한 HTML5가 웹저작자가 의도하는 정보구성을 명확히 하는 것이 매우 중요 하다는 것이다. 예를 들자면 HTML5 서식요소는 [required]라는 속성이 추가되었다. 이속성은 해당 서식 요소를 반드시 입력해야 한다는 의미이다. 의미가 중요 한것이다. 브라우저가 이를 해석하여 부가적인 폼 검증을 해주는 것는 말 그대로 부가적인 것 이다.
앞서 기계들이 웹에 있는 정보를 이해 할 수 있다는 것이 중요한 부분임을 이야기 하였다. [required]속성은 브라우저의 HTML5의 폼검증을 위해 사용되는 점도 있겠으나 더 중요한것은 해당 서식요소를 반드시 입력하라는 명확한 정보의 구성을 한 것이며 이를 사람이 아닌 기계나 소프트웨어도 이해 한다는 것이다.

모바일 대응 개요

coForward의 모바일 대응 작업은 최초에는 미계획되었던 작업이다. 다시 말해 웹사이트의 구조를 생성할때 모바일이란 기기에 대한 고려가 전혀 없었다는 것이다.
사이트를 제작하고 약 한 달이 지나고 시대가 모바일이 대세니 모바일에 대응해보도록 하자라는 생각으로 역시 기본 업무를 병행하며 진행한 작업이다.
모바일 대응을 위한 몇가지 방안을 생각 해봤지만 결국 CSS3의 media query를 사용하기로 하였다. 이는 신기술의 응용이란 측면도 있지만 가용한 시간내에 할수 있는 가장 빠른 방법이었기 때문이기도 하다.
작업기간은 약 5일정도로 기획 1 / 디자이너 1 이 투입되었으나 기획은 첫날 적용방안 전달과 마지막 검수만 했으므로 실제로는 디자이너가 거의 모든 일을 처리 하였다. 이는 HTML의 변경없이 CSS만 변경했기 때문이다.

모바일 페이지 구성

기본적으로 HTML의 변경이 없으므로 모바일 페이지의 구성은 기본 사이트의 구성과 다르지 않으며 콘텐츠 중복되거나 모바일에 적합치 않다고 생각되는 부분은 제외 하였다. (기획에서 한 일의 전부다.) 특이 할만한 점은 기본 페이지에서는 숨겨저 있던 하단에서 페이지 상단으로 가는 건너뛰기 링크를 모바일 형태에서는 디자인을 적용하여 표시하여 주었다. 이는 상대적으로 긴 모바일 페이지에서 페이지 하단에서 메뉴부분으로 이동하기 위해서는 꽤 많은 스크롤을 해야 하므로 이를 한번에 이동할 수 있게 하기 위해서 이다.
앞서 언급한대로 최초 HTML구성은 모바일에 대한 고려가 전혀 없었다 숨겨진 건너뛰기 링크는 접근성의 관점으로 넣은 것으로 이것이 표시되는 형태가 달라졌을때 사용성을 높여주는 역할을 하게 된 것 이다.
페이지 하단의 내용을 일부만 표시하기 위한 방법으로는 Class의 추가 없이 CSS3의 구조적 선택자를 이용하였다.
생각보다 간단히 진행된 작업이었지만 만약 최초 HTML의 구성이 기본 페이지 구성에 얽메여 있었다면 모바일에 대응하기 위한 작업은 쉽지 않았을 것 이다.

모바일 대응 교훈

모바일 대응 작업을 하면서 얻는 교훈역시 마찮가지이다. HTML의 콘텐츠 위주의 구성은 중요 하다는 것이다. 모바일 대응은 기간도 짧았으며 실제 정량적 작업량을 봐도 관리자 페이지를 제외한 기본 페이지의 CSS가 1487라인 이었던 반면 모바일용 CSS는 864라인으로 꽤 많은 분량이 줄었다. 이렇게 될수 있었던것은 HTML구조가 콘텐츠 위주로 작성되어 콘텐츠 선형화가 잘 이루어 져있기 때문이었다.
작성된 모바일 사이트와 최초 기획단계에서 작성된 Outline을 비교해 본다면 모바일 대응 작업이 빠르게 진행될수 있었던 이유를 알수 있으리라 생각된다.

날개가 된 웹 표준 기술

다 아는 이야기를 꽤 길게 하였는데
하고 싶은 이야기는 마지막 부분이었다.
이 역시 같은 이야기지만 말이다.

웹 표준은 제약인가?

웹 표준과 접근성을 이야기하면 웹 저작자들이 제약 처럼 받아들이는 경우를 많이 봐 왔다. 그런것들중에 대표적인 이야기는

“디자인적 제약 이 따른다.”
“우리나라는 IE가 다인데 안해도 문제 없지 않느냐”
“공공기관도 아닌데 그런걸 꼭 해야 하나”

이런 이야기 들이었다.
지금까지 쭉 이야기 해왔지만 제약하기 위해서가 아니라 그렇게 하는것이 더 효율적이기 때문에 표준 기술이 만들어 지는 것이다.
개인적으로는 웹표준이 제약이 아니라 그동안 웹표준 기술이 우리나라의 웹저작 관행이라는 제약적 환경에 있지 않았나 하는 생각을 한다.

Web on Everything

웹을 요구하는 기기들은 계속늘어 날 것이다.
최근에는 웹기술을 이용하여 다양한 환경에 User Interface로 사용하고자 하는 시도들이 활발히 이루어 지고 있다.
웹표준 기술이 만드는 기회가 점점더 많아지고 있는 것 이다.
또 이야기 하게 되지만 웹표준 기술에 주목하는 현상은 새롭지만 웹표준 기술 자체의 목적은 새로운 것이 아니다.

Web for All, Web on Everything

그 이유는 웹 표준 기술은 원래 그러고자 만들어진 것 이다.
장치 운영체제에 독립적으로 정보를 제공하고자 하는 웹표준 기술의 목적을 이해 한다면 웹 또는 네트워크 상의 정보를 요구하는 기기가 다양해질 수록 그 중요성과 웹의 정보구조(HTML)을 어떻게 구성해야 하는가도 깨닫게 될것이다.

Thank you

2011 웹 접근성 향상 전략 세미나
일시 : 2011년 5월 2일(월) 09:30~17:30
장소 : COEX 컨퍼런스 룸 401호

개인적으로 이번 세미나를 등록하면서 “이번에는 그다지 붐비지는 않겠지”라고 생각했다. 그 이유는 이제 웹 표준과 웹 접근성이란 것이 새로운 이슈는 아니라고 생각하기 때문이다.
이렇게 생각하게 된 큰 이유 중 하나가 바로 정보화 진흥원의 이 행사로 역설적이지만 그동안 지속적으로 열렸던 이 행사로 인해 세미나의 주제가 별로 주목받지 않게 되었다.
또한 월요일이란 점도 그랬다.
각자 판단이야 어떤 형태든 이제는 한번쯤은 들어본 주제의 세미나에 참석하기 위해 한 주를 시작하는 월요일 부터 시간을 쉽게 내줄 조직은 드물지 않을까 하는 생각 때문이었다. (실재로 매번 하는 주제라고 하여 세미나 참석 신청이 거부됐다는 분의 글을 본것 같다.)

개인적으로 몇 년째 참석하고 있는 세미나로 이번 세미나의 주된 내용은 개정된 “웹 콘텐츠 접근성 지침 2.0″에 대한 것 이었으며 예전의 패턴과 같이 오전에는 포괄적이고 전반적인 발표내용으로 진행 되었으며 오후에는 세부적이고 기술적인 내용이 진행되었다.

Na!도 이제 어느정도 접근성에 관한 이야기에 익숙해서져 인지 예전에는 오전 내용보다 오후 내용에 관심이 있고 알게 되는 것도 많았지만 이번에는 오전의 더 많은것을 생각하게 했다. (그렇다고 오후의 내용이 좋치 않았다는 것은 아니다.)

특히나 매번 느낌의 정도가 상승되왔던 기조발표는 이번에는 가장 좋았던 발표로 꼽을수 있겠다. 기조강연은 안철수 연구소의 김홍선 대표님이 “올바른 소프트웨어 설계의 방향” 이란 주제로 발표하셨다.

개인적으로 파악한 발표의 주된 맥락은 다음과 같다.

소프트웨어가 기존에는 기술적이고 특정한 사람들을 위한 것이 었다면 이제는 보편적으로 사용되고 사용하는 사람들의 계층 또한 다양해 졌으며 사회적 도구로 까지 발전하고 있으므로 이러한 소프트 웨어의 접근성은 구축의 빠른 단계 : early stage서부터 계획되고 고민되어야 한다.

오후의 시작은 장애인의 입장에서 웹 접근성에 관한 내용이 진행되었다. 개인적으로 한국시각장애인연합회의 강완식 팀장님의 말씀이 인상 깊었다.
역시 개인적으로 중요했다고 생각되는 내용은 다음과 같다.

정부 부처들을 중심으로 웹접근성 개선 사업을 추진하여 정부 기관 웹사이트들의 접근성은 비약적으로 높아졌다. 하지만 정부기관의 웹사이트들에서 얻을수 있는 정보나 실질적 편의는 그다지 크지않으며 장애인의 실재 생활에 편의를 제공할수 있는 쇼핑, 뱅킹등의 민간 사이트들의 접근성은 아직도 요원한 수준이다.

이 두가지 내용이 인상 깊었던것은 Na!의 접근성에 대한 관점이나 의견과 통하는 바가 있기 때문이다. 이 블로그를 통해서도 여러번 언급했지만 웹 접근성은 웹저작의 어느 특정 단계에서 모두 이루어 질수 없으며 기획단계 부터 고려되어 야 한다고 생각한다. 이는 웹 자체가 정보에 대한 접근 제공하기 위한 도구 이기 때문이라 생각한다.

정부 및 관 주도의 법적 제재를 통한 접근성 정책에 대한 개인적인 생각도 어느 정도는 빠른 전파나 효율이 있을지 모르지만 자칫 접근성이란 것을 공공역역이나 특정분분에 한정된 이야기가 되어 버릴수 있지 않을까 생각이 있었다. 웹 표준과 접근성이 웹 제작자들에게 제약으로만 여겨진다면 이 둘의 확산은 장기적으로 불리 할 수 밖에 없다고 본다.

어떻게 보면 마지막 Q&A시간의 분위기는 위 두가지 사항이 만들어 낸 것이 아닐까 한다. 익명을 신청한 (아마도 사이트를 실재 만드는 입장인 듯) 첫 번째 질문자(라기 보다는 토론자)의 여러가지 이야기가 주최측이나 접근성 마크에 대한 개인적인 성토처럼 들렸을지 모르지만 현장 분위기는 공감하는 내용을 속 시원히 이야기 해줬다는 느낌이었다. 이어 관공서에서 오신 두분의 이야기를 들어 볼때도 접근성 마크의 순작용은 물론 인정하지만 접근성을 공공분야에서 적용되는 제약적 규정처럼 여겨지등의 역작용도 생각해봐야 할 때가 왔다고 본다.

개인적으로 Q&A의 감상은 마치 웹 표준과 접근성이 “산수유” 같다는 생각이 들었다. “참 좋은데 설명 할 방법이 없네..” 하는..

Na!의 견해로는 웹 표준과 접근성은 웹 저작자들에게도 분명히 해택이 있다. 막연한 개념적 해택이 아닌 실제 업무상 해택이 있다고 생각한다. 문제는 웹 제작 어느 한 단계에서 만으로는 부족하다.
아.. 정말 “참 좋은데 설명 할 방법이 없네..”가 와닿는다.

개인적으로는 첫시간과 마지막 시간이 가장 흥미롭고 기억에 남았지만 Micro Soft에서 나오신 분들이나 접근성에 관심 있다면 익숙한 발표자분들의 내용 역시 배울점이 많았던 행사였다.
이날 주된 내용이었던 “한국형 웹 콘텐츠 접근성 지첨 2.0″은 웹접근성 연구소에서 받아 볼수 있다. 자료 페이지

마지막으로 이번 세미나의 전체적인 감상을 적어본다면 접근성이란 단어를 낮설지 않게 만드는 일을 해왔던 세미나가 이제는 단순히 알리는 일을 넘어서 발전적인 고민을 시작해야 하는 때가 왔음을 주최자나 참석자 모두에게 인식시켜준 행사가 아니었나 한다.

W3C HTML5 한국 관심그룹 바캠프
일시 : 2011년 2월 9일
장소 : 한국 MS Win룸

그리고 Barcamp의 특성상 Na!도 “움직이지 않는 HTML5 이야기”라는 제목으로 슬라이드를 몇장 만들어 발표를 하였다.


이제는 거의 고정된 자기 소개 – 안녕하세요. Na!입니다.

HTML5에 대한 이야기가 나오기 시작하며 웹상에는 기존의 웹 기술로는 불가능했던 화려한 데모들이 여기저기서 나오기 시작했다. 그러한 데모들은 대부분 화려한 애니메이션 효과를 가진 것들이었다. 개인적으로도 HTML <video>와 <canvas>를 이용한 위 데모는 상당히 인상적인것 이었다.

그런 데모들 때문인지 몰라도 종종 HTML5가 Flash와 경쟁하는 구도처럼 이야기되는 경우를 볼수 있다. 개인적인 생각으로는 Flash와 경쟁하여야 하는것은 MS의 Silverlight이지 HTML5가 아니며 이렇게된 이유는 Apple이 Adobe와 싸우면서 HTML5란 단어를 끌어들였기 때문인 아닐까 생각한다. 스티브잡스의 영향력으로 HTML5의 붐업에 도움이 되긴했지만 어떤면에서는 HTML5와 Flash의 관계를 오해하게 만든 점도 있다고 생각한다.

그리고 우리가 일반적으로 부르는 HTML5란 용어 정의도 불분명한 경우가 많다. 요즘 HTML5라고 하면 차세대 웹기술을 모두 한꺼번에 이야기하는 듯한 경향이 있다. (최근 발표된 HTML5로고의 사용예를 봐도 그렇고..) CSS3는 기본이고 inline SVG가 지원되면서 SVG도 HTML5로 이야기 되고 있다. 그리고 웹상의 HTML5 데모는 이런것들이 복합적으로 구성된 예가 많은것도 사실이다.

CSS나 SVG를 제외하더라도 HTML5라고 이야기 되는것들의 수는 적지 않다. 그리고 그것들 중 다수는 기존에 HTML에는 없는 개념들이었다. 새로운 개념이기 때문에 더 관심이 가고 주목받는것은 당연한것이겠지만 기본이 되는 HTML tag자체의 변화에 대한 이야기는 별로 없는것 같아 다른 새로운 기술처럼 화려 하지는 않치만 중요한 변화라고 생각하는 HTML5 tag자체의 이야기를 해보고자 했다.

2011년 2월 현재 HTML5 스펙에 정의된 tag들은 총 106개이다.

HTML4와 비교하여 추가된 tag의 숫자는 총 27개로 <video>와 <canvas>로 대표되는 새로운 컨텐츠 형태와 <output>, <progress>등 웹어플리케이션을 상정한 tag들 그리고 이 글에서 주로 이야기 하고자하는 Outline구성을 위한 <section> <article> 등의 tag들이 추가 되었다.

HTML5에서 Outline과 직접 관계된 tag들을 본다면 기존 HTML의 heading tag를 포함하여 <section>, <nav>, <article>, <aside>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <hgroup>이 Outline을 직접적으로 생성하는 tag들이다.

또한 <header>, <footer>, <time>는 Outline의 섹션별로 추가적인 정보를 제공하여 정보구조를 강화할수 있는 기능이 있으므로 이 또한 Outline과 관계가 있다 할수 있겠다.

그리고 <body>, <blockquote>, <fiqure>, <td>, <fieldset>, <details>은 독립적인 Outline을 생성하는 요소들로 이역시 Outline과 관련 있다

앞에서 살펴본봐와 같이 HTML5 tag중 상당수는 Outline의 구성을 위한 태그들이다. 그러나 다른 화려한 기술에 가려저 그 중요성에 비해 별 주목을 받지 못하는것같다.

HTML5에서 꽤많은 tag를 새로 추가하면서 구현하고자 하는 Ourtline은 무엇을 위해서일까? 개인적인 의견은 웹에 정보를 분자화하려는 것이 아닐까 한다. 분자는 물질의 특성을 가진 가장 작은 단위로 알고 있다. 웹이 가지고 있는 정보가 분자구조처럼 작성되어 있다면 정보는 HTML파일단위가 아닌 Outline이 구성한 Section 단위로 유통 될 수 있을것이다. 그리고 그렇게 구성된 Section 단위 정보는 분자의 특성처럼 그자신이 온전한 정보를 담고 있으면서 다른 정보와 결합하여 새로운 가치를 만들어 낼 수도 있을 것이다.

그러다면 Outline은 어디서 어떤 방법으로 만들어 질까. outline과 관련된 HTML의 Sectioning Group Element를 소개할때 자주 언급되고 설명하는 방식중 하나는 예전에 특정부분에 쓰였던 <div>요소의 id와 비교하여 설명하는 그림이 있다 하지만 Na!의 개인적인 경험에 의하면 그 방식으로는 정상적인 Outline를 만들어내기 어렵다. 개인적으로는 Sectioning Group Element들은 <div>와는 아무런 관련도 없는 요소들로 그것을 기존의 <div>요소로 설명하고자 하는 방식은 좋치 않다고 본다. Outline은 정보의 시각적 배치와는 무관한 구조에 관한 문제이기 때문이다.

실재로 우리팀 사이트의 작성예를 들어보면 위의 내용은 우리팀 사이트의 구성원 소개 페이지의 컨텐츠 리스트이다 구성원페이지는 각 구성원을 소개하고 구성원 서로가 서로에 대해 코멘트를 하는 것으로 구성하기 로 했다. 그리고 컨텐츠별로 사이트 레벨에서 반복할 것과 카타고리 레벨에서 반복할것을 정하고 HTML5의 Sectioning Group Element를 이용하여 기본 템플릿을 작성하였다.
중요한점은 이 시점은 시안은 커녕 아직 우리팀의 로고 디자인도 결정되지 않은 상태였다는 것이다.

그리고 그 기본 구성과 템플릿을 발전시켜 완성된 구성원 소개페이지의 모습은 왼쪽과 같다. 작성된 페이지의 Outline을 검사할 수 있는 방법으로는 HTML5 Outliner 가 있는데 페이지의 URL이나 파일을 올리면 Outline을 추출하여 보여준다. 또한 크롬 브라우저의 확장기능으로 제공되는 도구도 있다.
과연 왼쪽의 완료된 형태에서 오른쪽의 아웃라인을 만들어 내는것이 쉬운 일일까?

검사된 Outline을 보면 낮익은 모습이 보인다.
Outline은 페이지의 컨텐츠 기획을 할때의 문서와 거의 똑같다. 다시 한번 언급하지만 이 컨텐츠 리스트는 시안 이전의 문서이다.
물론 우리팀이 진행한 방식이 반드시 옳다고는 생각하지 않는다. 다만 정보구조인 Outline의 작성이 어느 단계에서 어떤 방식으로 이루어져야 하는 가에 대한 하나의 의견으로 봐줬으면 한다.

Outline은 어떤 역할을 하게 될까? 가까이는 HTML 코딩 수준 대한 객관적 지표가 되지 않을까 생각한다. 지금까지의 HTML 코딩의 품질에 대한 객관지 지표는 HTML Markup Validation 이었다. HTML5에서는 Outliner가 더 중요해지지 않을까 생각한다. Markup Validation은 본질적으로 받아쓰기검사와 같다. 정보의 구조는 체크 되지 않는다. 반면 HTML5 Outliner는 글쓰기와 비슷하다고 본다. HTML5 Outliner가 글의 수준과 내용을 파악하지는 못하겠지만 최소한 구조는 보여 줄 수 있기 때문이다.

조금 멀리 보면 HTML5 Outline은 Documnet Web에서 Data Web으로 발전하기 위한 과정이 아닌가 생각한다. (개인적으로는 XHTML2.0이 이걸 너무 과격하게 추진하다가 HTML5한테 제압당했다고 본다.)

그러고 보니 예전에 개인적으로 그려봤던 Data Web에 대한 개념정리도가 생각이 났다. Web이 잘 구성된 데이터를 갖는다면 여러가지 형태로 사람과 기계에 제공할수 있을것이란 생각으로 Life Asia 08에 참가하여 얻은 생각이었다. 이러한것 생각이 HTML5로 인해 점점 현실화 되어 가는게 아닐까?

HTML5는 웹의 표현능력과 기능을 크게 확장시켰으며 그러한 것이들이 많이 주목 받고 있다. 앞서도 언급했듯이 그것들이 주목받고 이슈화 되는것은 당연하다고 생각한다. 하지만 HTML이 원래 가지고 있던 그리고 더 발전하려는 정보의 연결과 구조화란 역할에 있어서도 HTML5는 발전을 이루었고 이역시 다른 기능에 못지 않은 중요성과 웹의 변화를 가저 오게 될 것며 이런 모든 발전의 목적은 웹이 탄생한 순간 부터 변하지 않은 보편적인 정보의 전달 이라 생각한다.

NAVER 블로그 재능기부 : 박칼린 강연 기부에 초대합니다.
일시 : 2011년 1월 31일 (월) 오후 7:30~9:00
장소 : 분당 정자동 NHN 그린 팩토리 2층 커넥트 홀

네이버에서 진행하는 “재능기부”라는 프로그램에 박칼린님의 강연이 있었다. 작년예능프로그램의 합창단을 통해 이슈가 되었고 그 이후 새로운 리더쉽을 이야기할때 빠지지 않고 등장하시는 분이 되었다.

작년의 예능프로에서 각기 다른 사람들을 모아 하나의 목표와 결과를 만들내는 과정과 리더쉽은 Na!역시 깊은 인상을 받은터라 강연 광고베너를 보고 신청하였고 운좋게도 초청을 받을수 있었다.

강연의 제목은 “날개를 달아라”였는데 특별히 어떤 주제를 가지고 이야기 했다기 보다는 박칼린님이 살아오면서 가졌던 만남들에 대한 이야기를 하셨으며 그 사람들이 자신이 살아온 또 살아가는 계기기 되어주고 힘이 되어 주었고 자신도 그런 사람이 되고자 노력한다는 이야기로 들었다.

Na!는 강연 내용중 기억에 남는 두가지를 소개해본다.

케릭터 캐스팅

뮤지컬배우를 캐스팅하는 이야기중에 나온것 단어인데 어떤 뮤지컬의 배우를 캐스팅 할 때 그 배우의 노래나 춤실력도 중요하지만 배역과 그 사람의 캐릭터가 잘 맞는가가 더 중요한 요소라 한다.
뮤직컬의 배역 뿐 아니라 사람을 대하는 데도 있어 중요한 단어가 아닐까 생각했다.
그 사람의 캐릭터를 파악하여 그 사람이 잘 할 수 있는 것을 맏긴다던가 더 잘할수 있는 환경을 구성해주는 리더가 있는 조직이나 팀이라면 분명 좋은 결과를 낼수 있으리라 생각한다.
그리고 박칼린님도 자신의 캐릭터를 파악하고 그것을 펼칠수 있도록 도와 주신분들 덕에 자신이 있을수 있다고 말씀하였다.

3년이면 밝혀진다.

쉽게 말하자면 “정의는 반드시 승리한다.”랄까.
자신이 행위가 진실되다면 당장의 오해가 있더라도 결국은 밝혀진다는 이야기였다. 아마도 개인적인 경험으로 3년이란 시간을 말씀하신것 같다는 생각이 들었다. 좀 독불장군 스타일처럼 느껴질수도 있는 말이지만 내가 진실되다면 오해들은 신경쓸일이 아니며 결국 시간이 지나면 드러나게 된다는 것이다. 하지만 보통 사람들은 그 시간을 인내해 내기는 쉽지 않치 않나라는 생각도 함께 들었지만 진실성 만이 힘이 될 수 있다는 이야기는 가슴에 남는 이야기 였다. 그리고 강연후 질문 답변 시간에는 그 진실성이란것이 느껴질만큼 진지하게 청중의 질문에 답해주는 모습도 감명 깊었다.

날씨는 춥고 분당은 멀었고 시간상 저녁을 못먹어 배도 고프고 그랬지만 좋은 이야기를 듣고 왔다고 생각한다.

마지막으로 한가지 더 이야기 한다면 실제로 본 박칼린님은 TV로 볼때 보다 키도 컸고 날신했다. – 등장할때 여자분들은 놀라더라는..

IE가 웹세상의 전부는 아니다.

음.. 웹의 신기술을 이야기하는 책치고는 좀 진부한 카피가 아닌가? 하는 생각이 들었다.

웹표준 가이드 HTML5+CSS3 [원제 : DEVELOPING WITH WEB STANDARDS]
| john allsopp 저 | 김지원,홍승표 공역| 한빛미디어 2010

결론부터 말하자면 이책은 HTML5의 내용을 다루고는 있지만 HTML5책은 아니라고 생각한다. 일단 원제도 HTML5라는 단어도 없고 HTML5와 CSS3가 한 장으로 다루어 지고 있지만 이책의 메인 컨텐츠는 그것이 아니다. HTML5와 CSS3는 (특히나 HTML5는) 간략한 소개정도에 그치고 있다.
물론 시장의 유행이나 흐름를 타는것은 마케팅적으로 중요한 일일수 있겠으나 Na!같이 HTML5의 내용을 기대한 사람에게는 실망감을 주지 않을까 한다. (여러 선입견으로 인해 목차를 보지 않고 구입한 Na!의 실수도 크다고 할수 있겠지만.. 약간은 속았다는 기분은 어쩔수 없다.)

이 책의 정체(?)를 밝혀보자면.. 2년전 위키 북스를 통해 국내 번역되어 소개된 “제프리젤드만의 웹표준 가이드 [원제 : Designing With Web standards]의 (자매품이랄까?) “병행교재” 저자서문에는 라고 표현되어 있다.

두 책의 원제를 보면 대략 어떤 성격인지 파악 되리라 생각한다. 개인적으로는 앞의 책이 웹표준에 관한 전반적인 개념적인 이야기를 주로 다루었고 이번의 책은 HTML과 CSS에 관한 이야기를 주로 하고 있다. 제목이 Developing… 이지만 일반적으로 개발하면 생각나는 서버사이드 개발이은 다루지 낳고 있으며 javascript쪽 역시 크게 다루지는 않는다.

하지만 Na!의 개인적인 번역서 제목에 대한 약간의 배신감을 별개로 책은 괞찮은 내용을 담고 있다고 생각한다. 현용 HTML표준인 HTML4.01 / XHTML 1.0과 CSS2에 관한 설명은 잘되어 있다. 또한 javascript를 깊게 다루지는 않치만 DOM과 접근성에 관한 내용도 있어 현재 사용되고 있는 표준안의 사용자측 개발분야를 학습하는데는 많은 도움이 되리라고 생각한다.

책 자체는 비교적 잘 구성되있고 (개인적으로는 본문의 글자색을 태그, 속성, 속성값에 따라 달리 사용하고 있어 읽기에 매우 편했다.) 부가적인 내용들 예를 들면 새로 생기는 HTML5나 CSS3의 새로운 기능들에 대한 서로 다른 의견들의 소개가 개인적으로는 재미있었다.

이 책에 대한 개인적인 의견은 입문자나 경력이 얼마 안되는 사용자측 개발자가 HTML4.01 / CSS2기반의 현용표준을 배우고자 한다면 괞찮은 선택이 될것이라 생각하지만 기존 경력자가 HTML5와 CSS3의 정보를 얻고 싶어 한다면 (앞서 언급한대로 이책도 두 내용을 다루기는 하지만 제목으로 뽑을 만큼의 비중은 아니라고 본다.) 다른 책을 선택하는것이 더 좋다고 본다.

책은 전반적으로 괞찮은 내용의 나름 신경써서 (코드 요소의 성격별 색지정등과 같이) 만든 책인것 같은데..

개인적 평가는 번역된 제목 때문에 많이 깍아먹은 듯 하다.

우리가 웹을 잘 돌봐야 하는 이유
- 표준과 개방성에 관한 조금은 멀리간 생각

인트로랄까… 베타 비디오와 인쇄술에 관한 이야기로 시작하였다.

1998년의 대세작  카우보이비밥의 18화 Speak Like a Child (페이 발렌타인의 과거가 밝혀지는 회.. )베타 비디오에 관한 재미있는 에피소드가 있다.

어느날 비밥일행에게 의문의 물체가 택배로 배달된다. 카우보이 비밥이란 작품의 배경은 인류가 태양계 전체로 생활영역을 넓힌 미래로 비디오 테이프란 유물과도 같은 존재 였다. 비밥일행역시 그것이 무엇인가를 알기 위해 그시대의 골돌품상과 같은 곳에서 그것이 영상을 담은 매체라는 것을 알게 되었으나 그것을 재생시켜볼 플레이어를 구하는데 실패한다.

비밥 팀에 천재해커 에드워드 웡 하우 페페르 티브르스키 4세 (에드 – 빕밥에서 아인과 함께 가장 좋아 하는 케릭터)가 베타 비디오 플레이어가 있는 곳을 알아내고

일행은 산넘고 물거너는 정도가 아닌 태양계를 가로질러 목숨을걸고 플레이어와 디스플레이 장치를 획득하였으나

그렇게 가지고온(여러개중 큰것을 선택했다..) 비디오 플래이어는 VHS라서 비디오 테이프 재생에 실패하고 만다. 과연 이들이 비디오테이프를 재생하는데 성공했는지는 아직 이 작품을 보지 못한 분들을 위하여 이야기 하지 않겠다.

베타와 VHS의 비디오 표준 경쟁은 매우 유명한 이야기이다. 그리고 상업적 목적으로 자사의 규격을 시장 표준화 하기 위해 다른 경쟁사와의 규격과 경쟁하는것 이 잘못되었다고 이야기 하기도 힘들것이다.

하지만 공통된 표준이 필요하고 그것을 준수함으로써 전체적으로는 더 유리한 분야가 분명히 있다. 예를 들면 철도 같은것이다. 철도의 표준괘의 간격은 1,435mm로 대부분의 국가에서 이를 표준으로 이용하고 있다. 그래서 유럽에서는 국경을 넘나드는 철도 노선이 있고 우리나라는 정치적 이념으로 갈라진 남북이 경의선 철도로 연결될 수 있었고(요즘은.. –;) 유로-아시아라인의 총착역이 될수 있는것이다. 이 처럼 넓게 연결하고 소통하기 위한 도구는 공통된 규격을 준 하는것이 더 서로에게 더 유리하다.
물론 연결되고 소통하는것이 문제가 된다고 생각된다면 이를 달리 생각할 수 있다. 다시 철도의 예를 들면 이전의 러시아는 독일과의 단절을 위하여 의도적으로 다른 규격의 철도 간격을 사용하였다고도 한다.

철도로 표준에 관한 이야기를 하였다면 인쇄술을 통하여 개방성에 대한 이야기를 하고자 하였다. 1440년경 구텐베르크는 금속활자를 이용하여 성경을 찍어냈다.

물론 다들 알고 있겠지만 금속활자 인쇄술은 우리나라가 더 앞서 발명했고 남아있는 최고의 금속활자 인쇄본은 直指心體要節(직지심체요절)로 1372년에 제작된것이다. 인류의 역사에서 보면 신기하게도 전혀 교류가 없던 문화권에서 비슷한 기술이 비슷한 시기에 등장하곤 한다. 하지만 같은 기술만 그사회에 미치는 영향은 동일하지 않다.

시기적으로 크게 차이가 있지 않았으며 같은 기술이라 볼수 있는 구텐베르크의 인쇄술과 조선의 인쇄기술에 대한 평가는 어떠한가 쿠텐베르크의 인쇄술은 정보를 대량생산하여 전파함으로써 종교개혁과 나아가 유럽 산업혁명의 도화선이 되었다는 평가가 일반적이다. 하지만 조선의 인쇄기술은 이러한 정보혁명을 가져오지 못하였다.

비슷한 시기에 같은 기술의 결과가 왜 이렇게 달라졌을까.

이러한 앞선 기술들의 예를 통해 우리가 웹을 잘 돌봐야 하는 이유에 대해 이야기해 보고자 하였다.

그냥 자기 소개..

웹은 이제 우리생활에서 거의 필수품이 되었다. 이러한 웹이 좀더 큰 관점으로 인류사에 있어 어떠한 역할을 하게 될까. 이 발표물의 출발점이 되었던 Håkon Wium Lie의 한국강연에서 그는 Web이 인쇄술과 비슷한 역할을 하게 될것이라고 이야기 하였다.
또한 그러한 이유로 인쇄술이 400년이상 인류사에 영향을 미치고 있는것과 같이 웹또한 400년이상 사용되지 않을까 생각한다고 하였다.
인쇄술이 기본적으로 정보를 기록하는 기술이므로 인쇄술과 같은 역할을 한다면 웹 역시 정보기록의 기능을 가져야 할것이다.

그러고 보니 현재 인류의 기록은 어디에 어떻게 기록되고 있을까라는 궁금증이 들었다. 자료에 따르면 지난 5년사이 인류의 만들어낸 디지탈 정보의 양은 열배가량 증가했으며 2010년도에 만들어진 디지탈 데이터의 양이 “제타바이트”를 넘어설것으로 예측된다고 한다. “제타 바이트”란 다음과 같은 크기이다.

기가 > 테라 > 페타 > 엑사 > 제타
(각 단계는 전단계 단위의 ×1204)

물론 이 많이량의 테이타가 모두 웹데이타는 아니겠지만 이중 상당량은 웹을 통해 배포되고 이용 될것이란 것에는 동의하리라 생각한다.

이 처럼 인류는 정보저장기술은 놀라운 진보를 이루어 냈지만 그 정보의 보존력은 아이러니 하게도 고대의 석판이나 점토판을 능하지 못하였다.

기계가 정밀해지고 중요한 역할을 수행할 수록 정기적인 정비는 필연적인 것이 된다. 고도화된 정보역시 마찮가지 일것 이라 생각한다. 그리고 이러한 정비작업이 원활하기 위해서는 그 대상(물리적 기계든 디지탈화된 정보든)이 어떠한 규격에 맞도록 구성되어야 할것이다. 그래야만이 그것을 직접 만들지 않는 이도 그를 이용한거나 유지하는것이 원활할 것이다.
인류는 이와 같은 생각을 물리적 대상에 대해서는 오래전에 깨달았지만 정보에 대해서는 그러치 못했던것 같다.

개인적인 예를 한번 들어보고자 한다. 1994~5년쯤 어떤 워드 프로세스를 사용했는가? 당시는 windows 3.1이 주로 사용되고 상당수의 국산 워드 프로세스가 시장에 나왔었다. Na!는 그림에서 보이는 1472라는 윈도우 3.1용 워드를 사용하였었다. 당시 제품중 개인적으로는 상당히 기능이나 안정성이 만족스러웠던 제품이었고 아마도 대학 2학년부터는 개인적 또는 참여하고 있는 단체를 위한 문서 작업에 사용하 도구였다.
그러나 불과 2~3년을 못가서 windows95가 나오면서 프로램의 실행에 문제가 생기기 시작했다. OS가 변경되어 프로그램 실행이 지원안되는것은 그리 큰 문제가 아니었다. 더 중요한것은 2~3년간 작성해왔던 데이터를 볼수도 편집할수 도 없었다는것이 큰 문제였다. 결국 Na!는 그 자료들의 보존을 위해 OS를 재설치 하고 모두 출력한후 이미지로 스켄하여 보관하였다. 디지탈 자료로써의 많은 장점은 포기해야 했으며 결국 (스켄하였으니 다시 디지탈화 한것이지만 ) 예전의 종이 저장방식으로 회귀한것이 되었다.
만약 데이타의 규격이 다른 프로그램에서도 그를 볼수 있는 통일된 규격이었다면 Na!는 위와 같은 할필요가 없었을것이다. 하지만 그때는 아직 인류가 디지탈 정보에 대해여 거기까지 생각이 미치지 못하였지 않나 생각한다.

위와 같은 경험은 불과 15년전 20년이 안된 이야기이다. 그때는 웹도 생소했다. 우리가 매일 접하고 생활의 일부처럼 사용하고 있어 웹이 마치 고대적 부터 있었던것 처럼 생활하고 있지만 생각해보면 참 얼마 안된 기술이다.
(가끔 웹을 처음 만든 사람이 아직 살아있다는 것을 깨달을때마다 놀라움을 느끼곤 한다.)

그래서 Na!는 언제 부터 웹과 관련을 맺과 살아왔는가를 생각해 보았다.
웹이란 것을 (사용이 아니라) 인지한 기간은 생에 45%였으며 웹을 접속하는데 있어 환경적 경제적(정액제를 사용할수 있기전까지는 전화요금 스트레스를 받지 않을수 없었다.) 제약을 크게 느끼지 않고 사용한것은 생에 25%기간 이었다.
웹을 직업으로 삼고 있는 Na!조차도 웹은 비교적 최근에 알게된 도구이며 매체이다.

그러다 보니 현시점에서 웹은 정말 보편적인 매체인가? 라는 질문까지 나가게 됬었다.(어차피 제목이 멀리간 생각이니까..) 올해 (2010) 인터넷 진흥원에서 발표한 연령대별 인터넷 사용율을 보면 10대에서 30대까지는 99.5%이상이며 40대에서 약간 떨어지고 50대부터는 50%대로 급격히 떨어져 그이상 연령대의 격차는 더 크게 벌어진다.
이러한 표를 보면서 알수 있는 것은 경재 생산인구의 거의 대다수의 사용율이 90%이상또는 그에 근접하는 것으로 보아 이는 기호성이 아닌 생활과  업무에 필수적인 요소라고 판단할수 있을것이다. 또하나 50대를 기점으로 사용률이 크게 갈리는것은 웹이 정보전달 매체임을 고려해볼때 세대별 의식차이가 커지는데 하나의 이유가 되지  않았을까 하는 것도 이야기 될수 있을것이다.
보편적으로 사용되고 있다고 볼수도 있겠으나 일단 연령대별 격차가 크고 우리나라의 전체 평균은 71.15%가 된다.  70%이상이면 상당히 보편적이라 볼수 있을 수도 있겠다.

하지만 멀리 가기로 한건 좀더 나가보자 위의 자료는 세계 지역별 인터넷 사용률로 다음과 같다.

• 북아메리카 : 77.4%
• 호주 : 61.3%
• 유럽 : 58.4%
• 남미 : 34.5%
• 중동 : 29.8%
• 아시아 : 21.5%
• 아프리카 : 10.9%

세계평균의 28.7%로 우리나라의 71.15%는 지구차원으로 볼때는 상당히 특이한 지역인것이다. (우리가 속한 아시아의 평균사용률의 3배가 넘는다.)

웹의 현재 시점의 보편성과 또하나 생각해보고 싶은것은 과연 웹은 현재 시점에서 완전한 기술인가 인것이다. 물론 “완전”이란 단어가 완전할수는 없는 개념(-오 쓰고보니 그럴듯한 문장인걸..)이지만 그래서 기술의 성숙도나 그런것들을 고려할수 있을것이다.
웹이 앞에서 살펴본봐와 같이 지구의 특정영역에서는 매우다양한 분야에서 널게 사용되고 있어 성숙도나 완전성이 높은 기술로 여겨 질수도 있다고 본다.

하지만 개인적으로는 아직 초창기이고 발전하는 기술이라고 생각한다.

물론 웹이 지금도 강력하며 발전가능한 잠재력이나 앞으로 인류사에 큰영향을 미칠것이라는것은 어느정도 예측할수 있다고 본다.

하지만 앞에서 구텐베르크와 조선의 인쇄술의 예에서 언급한대로 기술이 사회에 미치는  영향은 기술자체로 속단 할 수는 없을것이다. 그 이유는 무엇일까.

어떤 테크놀로지가 중요한것이 아니라 누가 테크놀로지를 장악하고 있는가 가 중요하다.
- 고려대학교 언론학부 김민환 교수

이 문장은 하나의 이유가 될수 있을것이다. 쿠텐베르크의 인쇄술이 마틴루터의 반박문을 대량 인쇄하고 그 내용을 전파하여 종교개혁의 불씨를 지폈다고 했지만 같은 인쇄술로 중세의 교회는 면죄부를 찍어 팔았던것은 이 이유에 대한 하나의 역사적 증빙이라 할 것이다.
그리고 웹이 인류사에 있어 인쇄술과 같은 역할을 하고자 한다면 정보배포 수단으로서 다음과 같이 사용어야 한다고 생각한다.

가장 유능한 사람이 가진 정보를 가장 유능하지 못한 사람에게 빠르게 전달할수 있는 사회를 만들어야 한다.
- 국어문화운동본부 남영신 회장

웹은 앞으로 어떤한 길을 가게 될까.
웹이 인쇄술과 같은 기술이라면 구텐베르크의 인쇄술과 직지심경을 찍었던 조선의 인쇄술중 어떤 길을 뒤따르게 될것인가?

웹이란 기술이 최소 400년을 갈 것이라면 그 기간에 아직 10%도 오지못한 웹의 초창기라 볼수 있다. 이러한 기술이 어떤길을 가게될것인가는 웹의 초창기에 서있는 우리의 “선택”과 “웹을 어떻게 돌보는가?” 가 큰영향을 미칠수 있을 것이다. 그리고 그 올바른 선택은 “표준”과 “개방성”이며 이것을 유지할수 있도록 돌봐야 하지 않을까라고 생각한다.

빠르게 변화하는 정보기술속에서 그러한 일을 하는 사람으로써 한가지 생각해볼만한 글귀가 있어 소개 하고자 한다.

세상은 진보하여 그치지 아니하매
예 사람이 오늘의 형편을 짐작하지 못하는것과 같이
오늘에 또한 내일의 문명을 예측하기 어려우니 만치 사람의 지혜는 발달되어 간다.
그러므로 사람은 누구나 다 남이 배우는것을 배우고 남이 아는 것을 알고 남과 같이 살아야 할 뿐 아니라 한걸음 더 나아가서 남보다 더 배우고 더 많이 일하고 더 벌어서 더 영광스럽게 살아야 할것이다.
- 맹사일지 中 : 松巖 박두성 (1888~1963)

위의 글은 한글점자체계 훈맹정음을 만드신 박두성 선생의 글이다. 옛글이지만 오늘과 같이 급변하는 정보사회에서 그러한 정보들이 어떻게 배포되어야 하는지를 생각하게 하는 글이라고 생각되어 위의 글를 소개하며 조금은 멀리간 우리가 웹을 잘돌봐야 하는 이유에 대한 이야기를 마치고자 한다.

.. 이렇게 HTML5 사양은 모든 웹 기술을 포함하고 있으므로 전부를 한 권의 책으로 다 소개 할수 없을 정도로 방대한 분량이 되었습니다. 따라서 이 책에서는 HTML5의 첫출발로 우선 마크업과 관련한 주제에 한정하여 해설하고자 합니다.

철저해설 HTML5 마크업 가이드북 | 하타노 후토미 저 | 안동현 역
| 프리렉 2010

사실 이 책은 앞에 다른 책을 구입할때 “다른 것도 있구나.. 저건 나중에 보자.”라고 생각했었다. 그 날 좀 책을 많이 사서 지출이 꽤 되었기 때문에 일단 보류 하고 싶었다. 그래도 대충 흩어나 볼까 하고 책 표지를 읽는데..

저자의 이름이 낮익지 않은가.
하타노 후토미.. Na!도 이제 국제화(참 고색창연한 단어군.) 인지 “외국인 이름이 낮이익다니.. ” 라는 생각을 하였다.

저자는 지난 10월 CSSnite in SEOUL VOL2에서 HTML5의 발표자였다. 그리고 그날의 발표는 개인적으로 매우 인상깊게 들었기 때문에 이 책을 그냥 두고 올 수 없었다. (집에 가는 길에 가방이 매우 무거웠다..)

이책의 출판사인 프리렉에서는 이미 HTML5서적을 출간한적이 있는데 한국에 최초로 출간된 HTML5 번역서인 HTML5&API 입문 이다. 이전에 API에 중점을 많은 중점을 둔 책을 출간한 것은 이 책의 판권을 획득하고 있었기 때문이 아니었다 라는 생각이 든다.

앞에 인용한 저자 서문의 내용에서 밝히고 있듯이 이책은 API는 거의 다루지 않는다. <canvas>와 <video>, <audio> 의 컨트롤을 위한 매우 기본적인 내용이외에는 javascript도 거의 없다. 번역서를 낸 출판사의 의도가 마크업 분야와 api분야를 각각의 책으로 출간하는 것이 아니었을까 하는 추측이다.

책의 스타일은 기존에 출간된 ” HTML5:차세대 웹표준 기술“과 거의 흡사하게 각 태그 스펙을 자세히 설명하고 예시를 보여주고 있다. 결국 두 책은 포지션이 같다. (구매시 참고하시길..)

다만 먼저 출간된 책이 매우 기술사양서 같다면 이 책은 그 보다는 친절한 방식으로 서술하고 있다. 문체를 봐도 ” HTML5:차세대 웹표준 기술” 약간의 문어체적 느낌과 경어는 생략하고 있는데 반하여 이책은 경어로 서술하고 있다.
어차피 두권다 사양해설을 위주로 한 책이 기 때문에 크게 다르지는 않다고 보지만 개인적을 성향에따라 선택이 갈릴 것 같다.

다만 Na!같이 두 권 다사는것은 비추이다. –;
정말로 두책의 성격이 거의 비슷하기 때문이다. 두 책의 각 저자분들도 어쩌다 보니 면식이 있어 어떤 책에 손들어 주기도 좀 그렇다.

어쨌든 HTML5 도서의 두번째 출간 러시중 두번째 책이었다.