내 맘대로 보는 세상

webdevmobile에서 3회(1, 2, 3)에 걸쳐 개최한 열린 세미나가 성공적으로 끝이 났습니다. 웹은 예전부터 관심을 가지고 지켜보고 있었지만 최근 HTML5 등의 이슈에 대해서는 제대로 follow up 하지 못하고 있어서 약간의 죄책감을 가지고 있었는데, 덕분에 HTML5에서 지향하는게 무엇인지에 대해 약간이나마 알 수 있어 재밌었습니다. :)

아무래도 HTML이란 이름 때문에 웹퍼블리셔 분들이 많이 참석하셨던데 (특히) 3회째 세미나는 웹퍼블리셔 분들보다 앱 개발자 분들이 좋아하셨을 것 같네요.

HTML5: API

첫 세션은 요번에도 이원석 박사님께서 담당해주셨습니다. 초점은 HTML5에 추가된 API 들에 초점이 맞춰져 있었고, Canvas 2D, Video API, Web Socket, Local storage, Local database 등에 대한 간략한 소개 위주였습니다.

이 정도 API면 왠만한 애플리케이션을 구현하는데는 거의 지장이 없을 것 같더군요. :)

그리고 AJAX의 경우 Cross domain에 대한 쿼리가 불가능했기 때문에 결제 모듈처럼 타 서버로 값을 넘겨주고 그 결과를 리턴받아 사용해야 하는 경우에는 JSON나 로컬 프록시 등의 편법을 사용해야 했는데요, Web Socket에선 이런 제약이 사라졌기 때문에 편법을 사용하지 않고도 훨씬 많은 일들을 할 수 있게 되었습니다.

시작은 플랫폼에 구속받지 않는 문서로 시작되었지만, 이제는 그 굴레를 벗어나 앱으로의 확장을 꿈꾸고 있는 것으로 생각됩니다.

HTML5: Device API

모바일 디바이스를 위한 확장으로 Device API라는 것도 소개를 해주셨는데, 거기에 포함된 것들은 Geo Location(GPS), Filesystem, … 등이 있었습니다.

다만 Geo Location 이라거나 Filesystem 등의 경우 사용자의 Privacy가 노출될 수 있는 문제가 있기 때문에 이를 보완하기 위한 것들이 아직 논의되고 있는 중이라고 하더군요. :)

Java servlet에서 하는 것처럼 signed javascript의 경우 geo location, filesystem 등에 접근하는데 제약이 없도록 하는 건 어떨까 하는 생각이 들었습니다.

HTML5: Worker

Worker는 운영체제의 Thread에 해당되는 기능이라고 합니다. 특정 js 파일을 인자로 new Worker(‘…js’)를 실행시키면 이 js 파일을 처리하기 위한 thread가 생성됩니다.

어떤 복잡한 (시간이 오래 걸리는) 자바스크립트 로직이 있을 경우 이 로직이 처리될 때까지 사용자의 인풋이 블럭될 수 있는 문제가 있습니다. Worker는 이런 문제를 피해가기 위해 추가된 기능이라고 하며, 역시나 실시간 앱 시장을 HTML5에서 얼마나 욕심내고 있는지를 확인시켜주는 기능이라고 생각합니다.

쓰레드 간의 통신을 위해서는 메시징을 이용하면 된다고 하네요.

HTML5 웹을 넘어 플랫폼으로…

이원석 박사님의 세션이 끝나고 든 생각은 ‘HTML5는 문서도 앱도 아니고 플랫폼이구나‘란 생각이었습니다.

그래픽/통신/데이터베이스/파일시스템/쓰레드/Inter-thread communication 등 운영체제들에서 제공하는 대부분의 기능이 HTML5에 정의되어 있는 것을 확인할 수 있었으며, 이 규격만 제대로 구현해도 하나의 운영체제로써의 역할을 할 수 있지 않을까 하는 생각마저 들었습니다.

삼성 등에서는 수없이 많은 휴대폰 모델을 개발하고 있으며, 각각을 위해 앱을 새로(완전히 새로는 아니더라도) 개발하고, 수정하는 과정을 거치고 있습니다. 이런 노력을 줄이기 위해 바다라는 플랫폼을 만들어냈고, 안드로이드라는 플랫폼을 차용하고 있는데요. 앞으로는 안드로이드나 바다 등의 플랫폼보다 웹 플랫폼이 더 사랑받을 수 있지 않을까 하는 생각이 들었습니다.

웹은 이제 옵션이 아닌 필수가 되어가고 있으며, webkit 같은 오픈소스 Web Library를 이용할 경우 쉽고 빠르고 안정적으로 웹 플랫폼을 제공할 수 있을 것으로 생각됩니다.

필수적으로 제공되야 한다면 차라리 이를 플랫폼으로 하고, 전화 App, DMB App 마저도 HTML5로 구현하면 어떨까 하는 생각까지 들더군요. (CDMA 모듈이나 DMB 모듈과 통신하기 위한 plugin을 제공하면 됩니다. 인터페이스만 동일하게 규격화 한다면, App은 재활용이 가능할 것입니다.)

조만영님의 얘기처럼 이제 곧 Web Engineer라는 직종이 새롭게 정의되지 않을까 하는 생각이 듭니다.

그럼에도 HTML5에 아쉬운 점…

최근 화두 중 하나는 3D입니다. 하지만 Canvas에서 2D에만 초점을 맞추고 있다는 점은 조금 아쉬웠습니다. 2D API로도 3D를 그려낼 순 있습니다. 하지만 3D API가 제공되지 않는다면, 하드웨어 가속 기능을 사용할 수 없고 이는 파워가 약한 모바일 디바이스에게 (실행 속도, 전력소모 두가지 측면에서 모두) 치명적인 문제가 될 수 있습니다.

다행히도 WebGL이라는 이름으로 (이원석 박사님 표현에 따르면 실험적인) Canvas 3D 규격이 준비가 되고있기는 한 것으로 보입니다만 아직 HTML5의 기본 기능으로는 분류되지 않고 있는 것 같네요. 조금 아쉬운 부분입니다.

또한 매번 문법을 파싱, 검사, 실행해야 하는 HTML5는 모바일 디바이스에서 약간의 부담일 수 있다고 생각합니다. 그렇기 때문에 java에서 그랬듯이 플랫폼에 무관한 바이너리로 변환해주는 기능(컴파일러)이 필요하지 않을까 하는 생각이 들었습니다.

물론 표준에 포함되지 않더라도 브라우져의 캐쉬단에서 파일을 컴파일해 저장해둔 뒤 다시 보여줘야할 땐 컴파일된 파일을 바로 로딩해서 보여주는 방법을 활용할 수도 있을거라 생각합니다.

에필로그

HTML5가 나오더라도 IE가 또 발목을 잡지 않을까 하는 이야기가 들려옵니다. HTML5, CSS3를 언제쯤 실무에 적용하면 좋을지에 대한 이야기도 들려옵니다.

저는 이렇게 이야기하고 싶습니다.

아직 PC를 위한 페이지에 적용하기는 조금 이를지 모르겠습니다. 하지만 모바일을 위한 페이지에는 적극적으로 HTML5를 활용해보아도 좋다고 생각합니다.

재작년말, 작년초 다음 커뮤니케이션 면접 때 ‘앞으로 웹이 어떻게 변할 것이라고 생각하시나요?’란 질문을 받았습니다. 그 때 전 이렇게 대답했습니다.

‘스토리지를 담당하는 서비스가 나오고, 이 서비스를 활용하는 어떤 매쉬업이 나올 것으로 생각됩니다. 웹은 이런 서비스들이 거미줄처럼 얽혀 무한한 가능성을 만들어낼 수 있는 플랫폼이 될 것으로 생각됩니다.’

그 때 제가 생각했던 것들이 점점 현실이 되어가고 있는 것 같습니다. 점점 더 재밌어지네요. 오랫만에 가슴이 두근두근 거리는 것 같습니다.

덧: 좀 게으름을 피다보니 그 때 나눴던 이야기들 중 까먹은 이야기가 너무 많네요… 메모라도 했음 좀 나았을텐데, 맨 몸으로 참석해서 맨 몸으로 돌아와버렸더니… OTUL

덧2: 다른 분들이 올려주신 후기들입니다. 역시 관점이나 생각에 따라 다들 느끼는 점이 다른 것 같습니다. :)

1. Wise님의 후기
2. Na!님의 후기

예전부터 방관자 입장으로 멀찍이에서 웹을 바라보고 있었는데, 최근 이슈가 되고 있는 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을 제공할 수 있는 구조로 되어 있었습니다.

<video width="320" height="240" controls>
  <source src="pr6.mp4"  type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"'>
  <source src="pr6.ogv"  type='video/ogg; codecs="theora, vorbis"'>
</video>

다시 말해 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회 열린 세미나 후기