HTML5 웹을 넘어 플랫폼으로…

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!님의 후기

Similar Posts:

• CentOS 삽질 후기: 잘못된 정보여 안녕!
• 유용한 procmail 용 rule!!
• wordpress: korean trackback!
• Block Image only spam mail…
• Spam filter #2