2회 HTML5 열린 세미나 후기…

예전부터 방관자 입장으로 멀찍이에서 웹을 바라보고 있었는데, 최근 이슈가 되고 있는 HTML5에 대한 열린 세미나에 참석할 기회가 생겼습니다.

사실 기술 세미나는 잘 참석하지 않는 편인데, 요번 세미나 및 뒷풀이를 통해 재밌는 이야기를 많이 해볼 수 있었던 것 같습니다.

제가 이해한 내용, 그리고 사석에서 이야기 해봤던 내용은 다음과 같습니다. 다만 음주 토크가 좀(?) 있었고, 따로 HTML5에 대해 공부를 해보진 않았기 때문에 잘못된 내용이 있을 수도 있습니다.

좀 더 세분화된 컨텐츠 구조화를 위해 정의된 태그들

html4에서는 문서의 구조화를 위해 heading element(h1 ~ hx) 태그만을 활용할 수 있었습니다. 하지만 html5에서는 문서 컨텐츠의 구조화를 위해 article, aside, header, section 등의 태그가 새롭게 정의되었습니다.

문서 하나에 여러 가지 주제의 글들이 있을 경우 각각을 article로 묶어주고, 그 안에서 독립적인 구조(section, h1~hx)를 가질 수 있는 구조가 되었으므로, 기계 입장에서 조금 더 쉽게 문서를 분석해낼 수 있을 것으로 생각됩니다.

HTML5: 웹을 넘어 앱으로…

구글 애플리케이션, EyeOS, 구글 OS 등에서는 이미 웹을 이용한 애플리케이션의 가능성을 보여주고 있었습니다. HTML5에서는 드래그앤 드롭, Video, Audio, Canvas, Device API 등의 기능을 제공하고 있고, 이를 통해 네이티브 애플리케이션에 버금가는 기능들을 제공할 수 있게 될 것으로 생각됩니다.

열린 세미나에서는 W3C 위젯을 이용한 애플리케이션 개발 데모를 볼 수 있었는데요. 정말 간단하더군요. :)

HTML/CSS로 UI를 구성하고 javascript로 사용자 인터렉션을 구현하고, config.xml을 통해 시작 페이지나 윈도우 사이즈 등을 정의한 뒤 zip으로 묶으면 끝입니다. (사실 확장자를 zip에서 widget으로 바꿔주는 과정이 추가로 필요하긴 합니다.)

사실 어떻게 보면 안드로이드 앱 개발 과정과 크게 달라보이진 않습니다. 참고로 안드로이드 앱 개발 과정은 XML로 UI를 구성하고, JAVA로 사용자 인터렉션을 구현하고 패키징을 하는 과정으로 구성됩니다. Widget을 만드는 방법과 동일하죠? (사실 둘 다 개발툴로 이클립스를 사용하다 보니 더욱더 거기서 거기가 아닐까 싶은데…)

하지만 아무래도 특수하게(그리고 빡빡하게) 정의된 XML보단 아주 유연하게 정의된 HTML 쪽이 진입 장벽이 쉽다고 생각됩니다. 그리고 이미 파이어폭스, 사파리, 오페라 등등 아주 훌륭한 에뮬레이터(?)들이 수없이 존재한다는 점은 큰 장점이죠.

안드로이드에서도 앱(웹?) 스토어를 준비하고 있고, 휴대폰 시장에서도 대동단결하여 W3C Widget을 지원할 예정이라고 하네요.

하지만 그 이면에서 생각해볼만한 문제들…

분명 HTML5는 표현에 머물러있던 HTML4를 확장하기 위해 많은 노력을 하고 있는 것으로 보입니다. 웹을 넘어 앱으로 나아가기 위한 준비에 특히나 초점을 맞추고 있는 것으로 생각되구요.

하지만 조금 생각해봤을 때 몇 가지 생각해볼만한 문제를 발견할 수 있었습니다.

HTML을 통한 Widget 개발은 쉽다. 그런데 소스 노출 문제는 어떻게?

HTML을 통한 widget 개발은 분명 쉬워보입니다. 하지만 zip이라는 아주 범용적인 압축 포멧을 사용하고 있다보니 widget을 소스로 다시 풀어내기도 쉽습니다.

제가 어떤 widget을 개발해서 판매한다고 하면 누군가 제 widget을 압축 해제하고 조금만 수정한다면 무슨 일이 일어날까요?

뒷풀이 자리에서는 이런 내용에 대해 논의해볼 수 있었고, 이런 문제 때문에 digital signature 기능이 새롭게 추가되고 있다는 이야기를 들을 수 있었습니다만 digital signature가 이 문제를 해결할 수 있을 지에 대해서는 조금 더 생각을 해봐야할 것으로 생각됩니다.

Video Tag… Open Codec은 답이 될 수 없는건가?

W3C에서 HTML5 표준화와 관련해서 난항을 겪고 있는 점 중 하나가 Video Tag에 어떤 코덱을 사용해야하는지를 결정하지 못해서라고 들었습니다.

하지만 Video tag를 보니 아래와 같이 fall back을 제공할 수 있는 구조로 되어 있었습니다.

다시 말해 Codec 이슈를 open codec으로 해두고, 서비스 프로바이더에서 타겟에 맞춰 알아서 파일들을 제공하면 안될까 하는 생각이 들었습니다.

사실 DMB, DVB 등의 서비스를 지원하는 장치에는 이미 H.264/AVC 코덱이 포함되어 있습니다. 이런 장치들은 이미 하드웨어 코덱을 가지고 있을테므로 (혹은 라이센스된 코덱을 가지고 있을테므로) 이와 링크된 WebView library에서 따로 라이센스를 지불할 필요는 없을거라고 생각됩니다.

OS 위에 올라가는 브라우져라면? 윈도우에서는 DirectShow를 이용하면 됩니다. 맥에서는 퀵타임을 이용하면 됩니다. 리눅스에선 Xine, vlc, gstreamer 등을 이용하면 됩니다. 이렇게 할 경우 미디어 플레이어/Quicktime/Totem 등에 코덱을 설치하게 되면 브라우져에서도 이 코덱으로 인코딩된 영상을 재생할 수 있습니다.

게다가 이 기능을 브라우져 자체에서 제공하는 것이 아니므로 따로 라이센스료를 낼 필요는 없을 것이라 생각되므로 이후 어떤 코덱이 더 많이 사용될 지는 시장의 선택에 맡기면 될 것이라 생각합니다.

WebM 코덱이 많이 사용된다면 WebM 코덱을 지원하는 Consumer Device도 점점 늘어날 것입니다. Ogg Theora도 마찬가지겠죠.

이원석 박사님께서 막차 시간 문제로 일찍 돌아가셔야 했던 관계로 이 이야기를 길게 나누지 못해 조금 아쉬웠네요.

에필로그

하여튼 오랫만에 재밌는 이야기를 나눌 수 있었던 자리였던 것 같습니다. :)

세미나 일정이 이원석 박사님의 출장 일정에 맞춰지기 때문에 다음 일정이 어떻게 될 지는 아직 잘 모른다고 하네요. 다음에도 또 재밌는 이야기들을 나눌 수 있었음 좋겠습니다.

이만 후기 끝!

p.s) 막상 써놓고 보니 제 블로그 제목대로 정말 제 맘대로만 보고 온 것 같네요.

참고 자료

  1. Future Web Accessibility: HTML5 Semantic Elements
  2. HTML5 articles and sections: what’s the difference?
  3. Video on Web – Dive into HTML5
  4. 제 2회 열린 세미나 후기

‘div’를 어떻게 읽는게 좋을까? 디브? 디비젼?

최근 미투데이에서 div를 ‘디브’라고 읽지 말자는 주장이 나왔고 ‘HTML 요소 이름의 풀어쓴 말과 한국말 표현‘이라는 페이지가 생겨났다. 이를 처음 봤을 때 생각났던 글은 바로 요 글!

이 주장에 따르면 div는 ‘디비젼’이라 읽어야 하고, em은 ‘앰퍼시스’로, pre는 ‘프리 포매티드’, cite는 ‘사이테이션’이라 읽어야 한다. 그런데 malloc을 ‘말록’이라 읽는 것을 보고 한심해보였다는 글이나 div ‘디브’라고 읽으면 싸보인다는 말을 난 이해할 수가 없다.

자 HTML specification에서 div를 어떻게 표현했는지를 한 번 살펴보자.

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

div를 ‘division’이라 지칭한 곳은 전혀 없다. em과 pre는?

EM: Indicates emphasis.

The PRE element tells visual user agents that the enclosed text is “preformatted”

from http://www.w3.org/TR/html401/struct/text.html

이를 그대로 해석해보자면 ‘EM은 강조를 나타낸다. … PRE 요소는 시각적인 유져 에이젼트에게 자신의 안에 있는 텍스트가 “이미 형식화되어있는” 텍스트라는 것을 알려준다.‘가 된다. 다시 말해 강조를 위해 사용되는 태그로 EM이란 태그가 있고 형식화된 텍스트를 표현하기 위해 사용할 수 있는 PRE(프리, 피알이)란 태그가 있다라고 말할 수 있다.

태그는 축약 표현으로 볼 수도 있지만 그 자체로 약속이고, (그 약속을 이해하는 사람들이 모두 이해할 수 있는) 하나의 단어라고 생각한다. 만약 div를 ‘디브’라 읽고, EM을 ‘이엠’, pre를 ‘프리’ 라고 읽는 문제 때문에 서로간의 의사 소통에 문제가 생길 수 있다면 위에서와 같은 주장을 이해할 수 있겠지만 실제 이런 태그를 생긴 그대로 읽는 것 때문에 생기는 문제를 난 보지 못했다.

오히려 abbr같은 태그를 ‘어브리비에이션’처럼 읽게 되면 알아듣기도 쉽지 않고, (미리 이 단어가 무슨 단어인지를 알지 못하는 이상)[1] 발음하기도 쉽지 않을 것 같고, 실제 외국인들과 토론을 할 일이 생겼을 지라도 이런 식으로 태그를 읽는 것이 도움이 될 것 같지는 않다. (한국인과의 대화에 익숙하지 않은 사람들은 엑센트와 장/단음을 제대로 지키지 않는 한국식 발음을 잘 알아듣지 못한다.)

왜 형을 형이라 부르면 안되고, 아버지를 아버지라 부르면 안되는걸까?

난 이해할 수가 없다.

길동아 내 너에게 호부호형을 허락하노라.

[1] 부끄럽지만 난 최근에서야 super script나 sub script같은 단어들의 의미를 알게되었다

div만 쓰면 웹표준?

예전에 작업해줬던 사이트를 오랫만에 방문했더니 뭔가 느낌이 묘하다. 얼핏 봤을 때는 몰랐는데, 제대로 보니 여기저기 많은 부분들이 바뀌어있다. 작업할 때 일 분배 건으로 조금 기분이 상하기도 했었고, 서로 바쁜 탓에 애를 먹었던 기억이 있었는데 어쨌든 기능이 추가되고 한 거 보니 개발을 담당할 다른 누구를 찾은 것 같다.

ftp 비밀번호 등은 아직 기억하고 있지만, 구지 로그인해서 내 소스를 얼마나 잘 이해하고 활용했는지까지는 알고 싶지 않았다. 다만 일부 구간만 스크롤 되고 하는 것들에 fixed positioning이 사용된 걸 보니 웹표준을 조금 아는 사람이 작업을 한 것 같아서 ‘소스 보기’를 클릭했는데, 어라?

Continue reading div만 쓰면 웹표준?