올해 초 세계적인 IT 기업 애플과 구글이 적극적으로 HTML5에 대한 지원의지를 밝히면서 HTML5는 세계 IT산업의 가장 중요한 키워드가 되고 있다. 또한 애플, 구글, MS, 모질라, 오페라와 같은 주요 웹 브라우저 업체들간의 브라우저 기술개발 경쟁이 치열해 지면서, HTML5 기술을 포함한 전체적인 웹 플랫폼 기술은 하루가 다르게 빠르게 발전하고 있다. 

 

반면에 IT업체들이나 웹 개발자들은 새로운 서비스의 기획이나 개발에 있어 혼돈스러워하고 있다. 가장 주요한 이유를 보면, 첫째는 HTML5 표준 개발을 주도하고 있는 W3C에서 HTML5 표준에 대한 로드맵을 보여주지 못하고 있다는 것이다. 둘째는 현재 애플 사파리, 구글 크롬, 파이어폭스, 오페라 등 주요 브라우저들이 HTML5의 많은 기능을 지원하고 있으나 이들 브라우저가 지원하는 HTML5 기능이 다르다는 것이다. 

 

또한 같은 브라우저의 경우도 버전에 따라서 지원하는 기능이 상당히 차이가 난다. 이외에도 국내의 경우 95%이상을 점유하고 있는 MS의 IE6, 7, 8이 HTML5를 거의 지원하지 못한다는 것이다. 그야말로 혼돈의 시대이다. 

 

그럼 모바일 환경은 어떠한가? 현재까지 진행되는 상황을 보면 PC보다 모바일 환경이 HTML5 기반의 서비스 적용에 적합한 환경으로 변화하고 있으며, 바로 지금이 HTML5 기반의 모바일 서비스를 준비해야할 시기라고 생각한다. 

 

■ 증대되는 모바일 웹의 중요성 

 

작년 말에 발표된 모건스탠리의 보고서에 따르면 향후 5년 내로 모바일을 통해 웹에 접속하는 사람들이 데스크톱 PC로 접속하는 사람보다 많아질 전망이라고 한다. 예전에는 주로 PC나 노트북을 이용해 웹의 다양한 서비스를 이용했지만, 스마트폰이 활성화 되면서 스마트폰을 이용한 인터넷 사용시간이 크게 증가하고 있다. 

 

또한 아이패드 같은 테블릿 제품이 성공적으로 출시되면서 가까운 미래에는 스마트폰, 테블릿, e북리더기 등 다양한 모바일 디바이스를 활용한 인터넷 사용이 더욱 증가할 것으로 예상된다. 

 

■ 모바일 웹에서 HTML5 활용의 의미 

 

웹에서 어떠한 기능을 구현하는가에 따라 다르겠지만 새로운 시맨틱 마크업을 추가한 HTML5를사용하면 같은 기능을 구현할 때 HTML4에 비해서 훨씬 적은 자바스크립트 코드로 구현이 가능하다. 따라서 기본적으로 웹 서비스 로딩속도가 빨라지며 이러한 특성은 특히 네트워크 속도에 예민한 모바일 환경에서 더욱 큰 의미를 갖는다. 

 

또한 경우에 따라 다르겠지만 많은 기능이 HTML5 표준에 포함되어 브라우저의 기본기능으로 제공되면서 HTML5 기반의 서비스 실행속도가 15%정도는 향상되는 것으로 알려져 있다. 추가적으로 HTML5가 오프라인 웹 애플리케이션, Geolocation, 웹펌, 웹소켓, 웹 저장소 등 모바일 환경에 반드시 필요한 기능을 지원함으로써 모바일 환경에서 훨씬 향상된 웹 서비스와 애플리케이션을 개발할 수 있게 되었다. 

 

■ 모바일 웹 브라우저 = 웹킷 = HTML5 ? 

 

스마트폰의 시대가 되면서 모바일 웹 브라우저는 웹킷 플랫폼을 기반으로 개발하는 것이 대세가 되고 있다. 웹킷은 애플에서 시작한 브라우저 랜더링 엔진에 대한 오픈소스 프로젝트로 애플, 구글, 노키아 등 세계적인 IT 업체들의 적극적인 참여로 세계에서 가장 빠르게 발전하는 웹 플랫폼이 되었다. 

 

현재 웹킷을 사용하고 있는 주요 모바일 플랫폼은 애플의 아이폰/아이패드용 iOS, 구글의 안드로이드, 노키아 S60 플랫폼 등이 있었고, 조만간 출시될 RIM(Research In Motion)의 블랙배리 6 OS도 웹킷 기반의 브라우저를 탑재한 것으로 알려졌다. 

 

웹킷은 HTML5를 가장 잘 지원하는 웹 플랫폼이다. 따라서 웹킷 기반 모바일 브라우저가 크게 확산이 되면, 자연스럽게 모바일 환경은 HTML5를 지원하는 환경이 된다는 측면에서 상당히 중요한 의미를 갖는다. 

 

■ HTML5, 모바일부터 준비가 필요한 시기 

 

지난달 초 야후는 스마트폰을 위한 HTML5 기반 메일 서비스를 시작했는데, 이 서비스는 속도 개선은 물론 오프라인에서 메일 검색 기능지원, 화려한 사용자 인터페이스 등 기존의 웹 메일 서비스 보다 한층 개선된 기능을 제공한다. 

 

또한 구글은 HTML5기반 유튜브 모바일 서비스를 개시하였는데, 이는 로딩 속도 개선, 화려한 사용자 인터페이스 그리고 네이티브 애플리케이션과 비교해도 손색 없는 비디오 품질을 제공한다. 

 

이외에도 AOL의 모바일 사이트, 체크-인(Check-in) 모바일 서비스 등 다양한 서비스들이 HTML5 기반 서비스를 시작하였으며, 앞으로도 HTML5 기반 모바일 서비스는 점차 확대될 것으로 예상된다. 

 

그럼 우리는 앞으로 어떤 준비가 필요할까? 불행히도 기업이든 개인이든 어떤 새로운 변화를 짧은 시간에 적응하는 것은 어렵다. 변화에 대한 올바른 이해과정인 시행착오의 시간이 필요하기 때문이다. HTML5가 가져오는 변화는 이미 우리 앞에 있으며 이를 피할 수 있는 방법은 없어 보인다. 따라서 지금부터 HTML5가 몰고 올 변화에 대한 적응을 시작할 필요가 있다. 그리고 HTML5 활용의 첫번째 무대는 모바일 환경임을 기억하자. 

 

[필자소개] 
현재 ETRI 선임연구원이며, W3C 대한민국 사무국 코디네이터, 모바일 웹 2.0 포럼 HTML5 AG(Ad-hoc Group) 의장 등으로도 활동하고 있다. 트위터는 @wonsuk73을 사용하고, 미래 웹 표준 기술에 관한 이야기(http://www.wonsuk73.com/)라는 블로그를 운영중이다.

저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. 2010.08.10 10:13  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • 이원석(wonsuk73@gmail.com) 2010.08.10 12:57 신고  댓글주소  수정/삭제

      안녕하세요.
      플래쉬가 보여지는 문제는 HTML5 보는 브라우저가 플래쉬를 지원하는 여부에 따라서 결정이 됩니다^^ 따라서 브라우저가 플래쉬를 지원하면 보여지는 문제는 없습니다.

  2. acompanhantes em sp 2014.04.30 06:37 신고  댓글주소  수정/삭제  댓글쓰기

    플래쉬를 지원하는 여부에 따라서 결정이 됩니

지난 글 "HTML5 표준 범위와 W3C HTML WG 표준화 현황"에서 HTML5의 표준 범위에 대해서설명 하면서 Device API에 대한 중요성을 설명하였는데, 지난 7월 14일~16일까지 런던에서 W3C DAP(Device APIs and Policy) WG 회의가 있었다. 필자도 DAP WG에서 에디터를 맡고 있어 회의에 참석하였으며 이에 대한 주요한 내용을 정리해 본다.

기존 웹 애플리케이션의 한계: 음성인식 검색, 비디오 캡쳐 등 구현 불가 
현재 다음과 구글이 제공하는 Native 스마트폰 애플리케이션은 음성인식 기반 인터넷 검색 기능을 제공하고 있으며, 구글의 스마트TV에서도 음성인식 기반의 콘텐츠 검색을 지원할 예정이다. 또한 스마트폰에서 카메라 애플리케이션이나 음악을 녹음해서 이를 기반으로 해당 노래에 대한 정보를 찾아주는 애플리케이션 등은 상당히 유용하고 인기있는 애플리케이션이다. 그러나 지금까지 표준기반의 웹 애플리케이션으로는 이러한 기능 개발이 불가능했다. 기본적으로 마이크나 비디오 카메라를 제어하기 위한 표준화된 자바스크립트 API가 존재하지 않았으며, 또한 HTML에서 이러한 디바이스들 연결하여 사용할 수 있도록 해주는 마크업이 존재하지 않았기 때문이다. 


Device API 개념 소개
Device API 표준은 웹 애플리케이션이 디바이스의 자원들 (GPS, 센서주소록일정카메라 제어배터리 정보갤러리파일 시스템 등)을 접근 가능하게 하는 API 표준으로, 이러한 표준을 이용하면 웹 애플리케이션이 사진이나 동영상 캡처 등의 기능을 자연스럽게 지원할 수 있다. 아래의 그림은 Device API의 개념을 보여준다.



먼저 현재 DAP WG에서 적극적으로 개발 중인 API 표준은 아래와 같이 정리해 볼 수 있으며, 이러한 표준 이외에도 보안과 Privacy에 대한 표준 개발을 진행하고 있다.

API 

설 명

개발주체

Calendar

디바이스의 일정 정보에 접근하기 위한 API

프랑스 텔레콤, RIM

Contact

디바이스의 주소록 정보에 접근하기 위한API

프랑스 텔레콤

Media Capture

디바이스 내 오디오, 이미지, 비디오 기능에 접근하기 위한 API

인텔, 노키아, 도이치 텔레콤

Messaging

디바이스의 SMS, MMS, email 기능에 접근하기 위한 API

텔레포니카, 오페라, 에릭슨

System Information

디바이스의 기본적인 속성에 대한 API(배터리 용량, 네트워크 대역폭, CPU부하, 저장 용량, /출력 기기)

인텔, 오페라

Gallery

디바이스 내에 있는 미디어 갤러리(media gallery)에 접근하는 API.

ETRI

Powerbox

사용자 개인 리소스를 브라우저에서 요청하기 위한 웹 기반 전달 방식

구글

Application Launcher

디바이스에 인스톨된 어플리케이션(Native Application)에 접근하기 위한 API

ETRI




W3C DAP WG의 Device API 표준 개발 전략
DAP WG에서 지금까지 Device API에 대한 보안 및 Privacy 이슈가 아직 견고하게 정리가 되지 않은 상황이기 때문에 현재 개발하고 있는 표준 API들을 Read 기능과 Write 기능을 분리하여 별도의 표준으로 개발하기로 하였다. 이렇게한 이유는 표준 개발이 가능한 기능은 최대한 빠르게 시장에 제공하기 위함이다. 따라서 Device API에 포함된 표준들은 보안 및 Privacy 이슈가 상대적으로 적은 Read 기능에 대한 표준들이 빠르게 표준화가 이루어질 것이며, 그후 Write 기능에 대한 표준들이 개발될 예정이다.


Device API 표준과 HTML5 마크업 관계 정립
DAP WG에서 Device API 표준과 HTML5의 마크업 간의 조화를 이루기 위한 노력을 진행하고 있다. 이는 웹 애플리케이션이 보다 자유롭고 쉽게 디바이스의 자원들을 처리할 수 있는 방법들을 제공한다는 의미에서 상당히 중요한 이슈이다. 예로 이번 회의에서 초안이 정리된  HTML Media Capture 표준을 볼 수 있다. 본 표준은 Media Capture API와 별개로 HTML 마크업을 이용해서 디바이스의 자원과 연동하기 위한 기능을 정의하고 있다. HTML Media Capture 표준에 대해 이번회의에서 정리된 주요 내용은 아래와 같다. HTML의 <input>에 accept 애트리뷰트를 이용하여 어떤 Device에서 어떤 타입의 미디어를 받아들일지 정의하는 것이다. 즉, 카메라를 이용해서 image를 입력으로 받겠다고 정의를 한 것다.

<input type="file" accept="image/*; capture=camera">

* Note: capture의 값으로 camera, camcorder, microphone, filesystem이 올 수 있음.

아래의 예는 HTML Media Capture 표준을 이용해서 구현할 수 있는 Media Caputure File Picker에 대한 랜더링 예를 보여준다. 트위터 같은 애플리케이션을 보면 트위팅을 할 때 사진을 같이 올릴 수 있으며, 사진을 선택할 때 기존에 찍어둔 사진을 선택하여 활용할 수도 있고 바로 카메라 기능을 이용해서 직접 사진을 찍어서 사용할 수도 있다. 아래의 왼쪽 그림은 기존에 찍어둔 화일을 선택하는 모드를 보여주며, 오른쪽 그림은 직접 사진을 찍기위한 카메라 모드를 보여준다. 이런한 기능이 HTML Media Capture을 이용해서 웹 애플리케이션에서 가능해지는 것이다.



또한 Contacts API의 경우도 HTML5의 <input>이나 <device>과 어떤 형태로 조화롭게 활용할 수 있을지에 대해 고민하고 있다. 현재까지는 HTML5에 새롭게 추가된 <device> 보다는 <input>을 활용하는 것이 안정적이라는 의견이 많은 사황이다. 그리고 앞으로 센서, 메시징, 갤러리 등 다양한 디바이스의 자원들을 마크업으로도 연동하여 웹 애플리케이션으로 표현할 수 있을 것으로 예상된다.


Device API 관련 W3C WG의 역할 분담
사실 W3C에서 API에 대한 표준은 주로 Web Applications WG에서 개발하는 것으로 되어 있었으나 개발해야할 스펙이 많아 디바이스의 자원을 접근하는 API 개발은 DAP WG을 새롭게 만들어 진행하게 되었다. 그러나 Device API와 관련된 표준들도 여러 상황에 따라서 다른 WG에서 개발하기로 하거나 기존의 기술에 의해서 표준 개발의 필요성이 없어진 표준이 있다. 이러한 내용을 아래와 같이 정리할 수 있다.
Web Applications WG로 이관: 화일 쓰기(File Writing)와 화일시스템 (Filesystems) 표준 개발
Geolocation WGOrientation / Acceleration 표준 개발
Web Notification Working Group: Notification 표준 개발
Application configuration 표준: localStorage와 Widget interface APIs로 대체


앞으로의 전망
앞으로는 HTML Media Capture 표준을 이용해서 웹 애플리케이션에서 음성인식 기능, 카메라 애플리케이션 구현이 가능할 것으로 생각되며, 향후 더 다양한 Device API 들이 제공되면 앞으로 정말 Native 애플리케이션과 같은 애플리케이션 개발이 가능할 것으로 기대한다. 이러한 의미에서 웹 플랫폼은 멀티플랫폼/멀티디바이스를 지원하는 가장 경쟁력있는 플랫폼으로 진화하고 있는 것이다.

 

저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. 김영보 2010.07.21 20:41 신고  댓글주소  수정/삭제  댓글쓰기

    매우 값진 글입니다. 감사합니다.
    - 화일 쓰기(File Writing)와 화일시스템 (Filesystems) 표준 개발은 언제쯤 Last Call을 예상하세요?

    - 앞으로 정말 Native 애플리케이션과 같은 애플리케이션 개발이 가능할 것으로 기대한다에서--->
    여기서 Native는 모바일 업체에서 제공하는 Native인가요?
    그럼 자바스크립트로 악세스가 가능하게 되나요?

    혹시 데이터베이스 통합/형태에 대해서 거론 된 것이 있습니까?
    파이어폭스 4.0에 indexed database가 탑재되는 것으로 알고 있습니다만,
    하나로 통일되는 방향으로 설정이 되었나요? 아니면 다른 방안이 있나요?

    단어 하나 하나의 의미를 되새긴 뒤 질문 좀 하겠습니다^-^

  2. 이원석(wonsuk73@gmail.com) 2010.07.22 01:04 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 김영보 선생님^^

    - 화일 쓰기(File Writing)와 화일시스템 (Filesystems) 표준 개발은 언제쯤 Last Call을 예상하세요?
    답변) 아시겠지만 예측하기가 좀 어려운데... 개인적인 생각으로는 보안과 Privacy에 대한 이슈가 있어서 시간이 좀 걸릴 것 같습니다.

    - 앞으로 정말 Native 애플리케이션과 같은 애플리케이션 개발이 가능할 것으로 기대한다에서--->
    여기서 Native는 모바일 업체에서 제공하는 Native인가요?
    그럼 자바스크립트로 악세스가 가능하게 되나요?
    답변) 예.

    - 혹시 데이터베이스 통합/형태에 대해서 거론 된 것이 있습니까?
    답변) 사실 Indexed database는 Web Applications WG에서 개발하고 있는 표준이기 때문에 구체적인 내용에 대해서는 논의가 없었습니다. 그러나 HTML WG Activity Lead인 Mike로부터 들은 바로는 Web SQL Database에 대한 표준 개발은 다시 없을 것 같고 대신에 Indexed database를 표준으로 만들어 사용할 예정이라고 합니다^^

    좋은 질문 감사합니다~ ;)

  3. 김영보 2010.07.22 03:54 신고  댓글주소  수정/삭제  댓글쓰기

    와~ 감사합니다.
    방향 설정에 잣대가 되었습니다.
    화일 쓰기를 기다리고 있습니다만, 준비만 해야 할 것 같습니다.^-^
    Native에 접근할 수 있다는 것은 자바스크립트로 모든 디바이스를 제어하게 된다는 의미가 아닌가요...
    그럼, Native도 일정 부분 표준화가 되겠네요...
    결국 indexed database로 가게 되네요...
    하기야 자바스크립트 개발자에게 SQL을 요구한다는 것은 또 하나의 부담이 될 것 같습니다.

    문장 하나 하나 되새겨 본 뒤에 조금 더 질문 드리겠습니다.
    감사합니다. 다음에 지하철 미팅해요. 메모해 두었다가 하나씩 물어 보게요^-^

  4. 강태욱 2010.07.22 08:54 신고  댓글주소  수정/삭제  댓글쓰기

    따끈한 소식 감사합니다~(--)(__)

  5. Wise 2010.07.22 10:20 신고  댓글주소  수정/삭제  댓글쓰기

    항상 따끈따끈한 소식 감사합니다~ ^^

  6. 민원기 2010.07.30 11:24 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 감사합니다. 자주 놀려 오겠습니다.

  7. 김대원 2010.09.21 05:50 신고  댓글주소  수정/삭제  댓글쓰기

    현재 WD상태의 W3C Device API에 대한 구현물들이 있나요?
    알려주시면 고맙겠습니다. 브라우져 벤더들이 내부적으로 구현하고 있다는 소문 정도만 들었고 구체적인것은 없네요.
    참고로 Ubivelox에서 만든 구현물이 12월 경에 국내 이통사를 통해서 출시 될 예정입니다.
    구현된 것중에 12월경에 비교적 안정된 spec만을 open 하겠지만요..

  8. 2010.09.21 05:51  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  9. 정상현 2012.07.16 16:50 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 정말 감사드립니다.

    한가지 의문이 가는것은 현재의 ms 계열 모바일 브라우저에서조차 touchEvent 를 지원하지 않는데, 모든 모바일 브라우저에서 이러한 것을 지원하고, 이것이 현실화 되기까지 어느정도의 시간이 걸릴것인가...입니다.

    보안 문제등으로 인해 표준안만 나오고 지원하는 디바이스나 브라우저가 적어 묻히는건 아닌지 개인적으로 불안합니다. 하지만 정말 웹에서 디바이스를 컨트롤 할 수 있게된다면 지금 웹보다 훨씬 더 많이 발전할 수 있게 되겠군요!!!

    다시한번 좋은 정보 감사드립니다!!!

  10. www.eparacord.com 2012.12.04 00:51 신고  댓글주소  수정/삭제  댓글쓰기

    브루가가들조각했는데 실수을리는없.....에라잇 르것다 섬세한 조각씨하나만큼은대하~ 단!

  11. http://efrenchdoors.com/pages/french-patio-doors 2012.12.04 02:44 신고  댓글주소  수정/삭제  댓글쓰기

    해민씨, 저도 정말 재미있는 시간이었습니다. 세계 최고의 엔지니어들과 함께할 수 있는 기회를 주셔서 감사합니다~ ;) 숙대는 박교수님께서 초청해 주시면 당근 가야죠~ ㅋㅋㅋ 여대^^;

  12. longchamp 2013.04.24 04:14 신고  댓글주소  수정/삭제  댓글쓰기

    지금은 냉장고등 저장시설이

  13. acompanhantes em sp 2014.04.30 06:38 신고  댓글주소  수정/삭제  댓글쓰기

    있다는 소문 정도만 들었고 구체적인것은 없네요.


오늘 구글코리아를 방문하여 HTML5에 대한 Tech Talk을 했는데 정말 생각보다 많은 엔지니어 분들이 참석해 주셔서 좋은 대화의 시간을 갖았다. 그리고 성함은 모르지만 구글 본사 마운틴뷰에 계신 분도 비디오 컨퍼런스로 연결하여 참석해 주셔서 감사했다. 또한 이번에 다시한번 구글의 자유로운 분위기와 그러한 자유로운 분위기 속에서의 책임감을 바탕으로 운영되는 조직문화에 다시금 놀랬다.

구글 Tech Talk을 유튜브에서 보신분들은 아시겠지만 항상 발표하기 전에 구글 종이가방에 선물을 넣어 발표자에게 전달한다. 항상 뭐가 들어있을지 개인적으로도 궁금했는데 오늘은 직접 받아서 확인을 했다.



가방안에는 큰 박스와 빨간색 구글 티셔츠가 있었다. 박스 안의 내용물은 비밀로 하고 싶다. 너무 좋은 선물이 있었기 때문. 그냥 사진만 올려본다.



그리고 오늘 발표한 "The current status of HTML5 technology and standard"에 대한 발표자료는 아래와 같다.



많은 분들이 이 발표자료를 트위팅해 주셔서 Hot on Twitter에 올라갔다. HTML5에 관심이 있으신 분들에게 조금이나마 도움이 되었으면 좋겠다. 아래 이미지는 Hot on Twitter 페이지의 인증 삿.



마지막으로 오늘 부족한 강연을 열심히 들어주시고 좋은 질문을 해주신 모든 구글러 여러분께 감사드린다.

발표자료(PDF 버전) 다운로드




저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. 이해민 2010.07.09 01:03 신고  댓글주소  수정/삭제  댓글쓰기

    원석씨, 오랜만에 얼굴 뵈어서 반가왔습니다.

    멀리까지 오셔서 좋은 발표 해주셔서 감사합니다.

    담엔 숙대에서 한 번 더...후다닥 =3=3=3

    • 이원석(wonsuk73@gmail.com) 2010.07.09 01:17 신고  댓글주소  수정/삭제

      해민씨, 저도 정말 재미있는 시간이었습니다. 세계 최고의 엔지니어들과 함께할 수 있는 기회를 주셔서 감사합니다~ ;) 숙대는 박교수님께서 초청해 주시면 당근 가야죠~ ㅋㅋㅋ 여대^^;

  2. leezche 2010.07.09 10:07 신고  댓글주소  수정/삭제  댓글쓰기

    저는 엔지니어는 아니고 디자이너인데 그럼에도 불구하고 정말 많은 도움이 된것 같습니다. 시간이 너무 짧아 아쉬웠습니다. 감사드립니다.

  3. 서동일 2010.07.09 10:29 신고  댓글주소  수정/삭제  댓글쓰기

    HTML5를 이해하는데에 정말 많은 도움이 될 것 같습니다. 유익한 tech talk, 발표자료 너무 감사드립니다.

  4. ninacry 2010.07.12 10:21 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세용^^ 김*현 과장님 소개로 예전에 세미나 들었던 사람입니다.
    여전히 열정적으로 활동하고 계시군요~ 그때도 감사드렸고 오늘도 자료 너무 감사하게 받아갑니다..^^
    저 구글 상자 안이 궁금하군요...ㅋ 좋은하루 되세요 ^^

  5. 머털도사 2010.07.16 11:01 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 자료 감사합니다. 이원석님
    퍼 갑니다.

  6. www.eparacord.com 2012.11.13 01:15 신고  댓글주소  수정/삭제  댓글쓰기

    해민씨, 저도 정말 재미있는 시간이었습니다. 세계 최고의 엔지니어들과 함께할 수 있는 기회를 주셔서 감사합니다~ ;) 숙대는 박교수님께서 초청해 주시면 당근 가야죠~ ㅋㅋㅋ 여대^^;

  7. http://roomdividersco.com/ 2012.12.04 02:45 신고  댓글주소  수정/삭제  댓글쓰기

    끔한 정리 감사합니다. 2011년 10월 현재의 동향도 정리해주시면 큰 도움 될 것 같습니다. :) roomdividersco.com

  8. acompanhantes em sp 2014.04.30 06:38 신고  댓글주소  수정/삭제  댓글쓰기

    오늘도 자료 너무 감사하게 받아갑니다..^^
    저 구글 상자 안이 궁금하군요...ㅋ 좋은하루 되세요 ^^

W3C에서 개발되고 있는 HTML5 표준은 기존 표준들과는 다르게 상당히 많은 스펙들로 구성되어 있다. 이러한 면은 HTML5를 배우는 많은 이들에게 HTML5 표준을 어디까지로 봐야할 까하는 의구심을 들게한다. 또한 많은 이들이 현재 W3C에서 표준화가 진행되고 있는 상황에 대해서도 궁금할 것이다. 이와 관련해서 지난 3월에 W3C에서 HTML WG 의장 중 한명인 마이크로소프트의 폴 코튼(Paul Cotton)과 인터뷰한 내용 [1] 과 W3C AC(Advisory Committee) 미팅에 보고된 내용 [2]이 있어 소개한다.


폴 코튼이 생각하는 HTML5 표준의 범위

폴 코튼은 HTML5라는 용어가 상당히 느슨한 의미로 사용이 되고 있다고 생각한다. 폴 코튼이 생각하는 HTML5 표준의 범주는 HTML WG에서 개발되고 표준, Web Applications WG에서 개발하고 있는 API 표준, Device APIs and Policy WG에서 개발하는 표준 그리고 마지막으로 우리가 자바스크립트로 알고 있는 ECMAScript-262에 대한 표준도 포함한다.

일반적으로 Device APIs and Policy WG에서 개발되고있는 Device API 표준은 웹 애플리케이션의 디바이스의 자원들 (GPS, 센서, 주소록, 일정, 카메라 제어, 배터리 정보, 갤러리, 파일 시스템 등)을 접근 가능하게 하는 API 표준이다. , 이런 API를 이용하면 디바이스의 카메라 기능을 이용해서 사진과 동영상도 촬영하는 기능을 웹 애플리케이션으로 구현할수 있다. 지금까지 디바이스 API HTML5 표준으로 포함시켜 논의되지는 않았다. 하지만 이 또한 HTML5의 핵심적인 API 표준이다. 또한 지속적으로 HTML5에 대한 표준은 추가적으로 제안되어 개발될 것으로 예상된다.


HTML WG 표준개발 현황

폴 코튼은 HTML WG에서 개발 중인 HTML5 스펙들 현황에 대해서는 HTML WG에서 개발중인 HTML5 스펙들이 W3C 초안 Last Call 단계 (초안에 대한 최종 검토 단계를 의미함)에 가기 위해서는 초안과 관련된 대한 알려진 모든 코멘트와 이슈들을 해결해야 하는 것이 필요하며 지금까지 이러한 작업을 지속적으로 진행하고 있는 중이라고 한다. 즉, WG 내부 또는 외부에서 지속적으로 표준 초안에 대한 이슈들이 제기가 될 것이고, 이러한 이슈들을 계속해서 해결하는 작업이 진행을 진행한다. 이러한 일련의 작업을 통해 초안의 문제가 모두 해결되면 Last Call 단계에 진입하는 것이다.

참고로 2009 1월에서 2010 2월까지 새롭게 발생한 이슈 비율과 해결된 이슈 비율을수자로 정리하면 아래와 같다. 지속적으로 새로운 이슈들이 발생하고 해결되고 있는 것이다.


HTML WG에서 현재 개발중인 문서는 아래와 같이 6개가 있으며, 지난 3월 4일에 공식적으로 Publication된 문서이다.


HTML5 표준의 최종승인에 대한 전망

HTML5 언제 표준화가 마무리됩니까? 가장 자주 듣는 질문이다. 그러나 HTML5 표준 개발이 언제 마무리될지 예측하는 것은 상당히 어려운 상황이다. 하지만 폴 코튼이 이야기한 내용들을 보면 지속적으로 HTML WG의 스펙들에 대한 이슈를 해결해 나가고 있는 상황이기 때문에 어느 정도 시간이 지나면 문제들은 정리가 될 것으로 조심스럽게 예측해 본다. 또한 W3C 표준 개발 절차상 초안 Last Call 단계에 진입하고 이 단계가 잘 정리 되면, HTML5 표준의 마무리에 대한 예측이 가능할 것으로 예상한다. 따라서, Last Call 단계를 언제 진입하는 지가 상당히 중요하며, 그 이후에는 HTML5에 대한 보다 긍정적인 기대의 글들이 만발하지 않을까 기대해 본다.


(참고자료)

[1] Interview: Paul Cotton on Microsoft Participation in the W3C HTML Working Group

[2] W3C HTML Working Group Status Report(November, 2009 - March, 2010)

저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. acompanhantes em sp 2014.04.30 06:38 신고  댓글주소  수정/삭제  댓글쓰기

    오늘도 자료 너무 감사하게 받아갑니다..^^
    저 구글 상자 안이 궁금하군요...ㅋ 좋은하루 되세요 ^^

  2. massagista 2014.05.14 12:53 신고  댓글주소  수정/삭제  댓글쓰기

    기고있다는 점을 제외하고 말을해야할지 모르겠어요. 블로그가 멋지 네요.

  3. acornpanharntes em sp 2015.06.21 06:26 신고  댓글주소  수정/삭제  댓글쓰기

    오늘도 자료 너무 감사하게 받아갑니다..^^
    저 구글 상자 안이 궁금하군요...ㅋ 좋은하루 되세요 ^^

웹을 물결로 비유하면 1989년에 팀 버너스리(Tim Berners-Lee)에 의해서 웹이 탄생된 이후 전세계에 빠르게 확산되어 되었던 때를 웹의 첫 번째 물결로, 2004년부터 화두가 되었던 개방과 참여, 공유를 기반으로 플랫폼으로서의 웹을 지향하는 웹 2.0 시대를 두 번째 물결로 정의할 수 있다. 

 

그럼 웹의 세 번째 물결은 언제, 어떻게 올 것인가? 필자는 웹의 세번째 물결이 멀티 디바이스 시대와 함께 엄청난 크기로 오고 있다고 생각한다. 멀티 디바이스 시대에서 해결해야 할 가장 큰 문제는 애플리케이션 개발 플랫폼 및 에코시스템의 분열에 대한 이슈이며 이를 해결할 수 있는 가장 적합한 기술이 웹이기 때문이다. 

 

W3C에서는 2007년 초부터 웹 애플리케이션 개발을 목적으로 하는 차세대 HTML 표준인 HTML5를 개발하고 있고, 최근 2~3년간 엄청나게 빠른 속도로 발전하고 있는 웹 브라우저 기술을 볼 때 지금이 웹의 세번째 물결에 적극적인 동참이 필요한 시기라 생각한다. 

 

■ 멀티 디바이스 환경에서 사용자의 현실과 이상은? 

 

요즘 개인이 인터넷에 연결해서 사용하는 디바이스는 2개 이상이다. 즉 1인당 개인적으로 사용하는 PC 또는 노트북과 휴대폰은 대부분 가지고 있다. 본 글에서는 미래 지향적인 관점의 글이기 때문에 휴대폰을 스마트폰으로 가정하겠다. 현재 사용자가 이런 두개의 디바이스에 애플리케이션을 어떻게 설치하고 사용할 때 어떤 어려운 점들이 있는지 보자. 

 

사용자는 원하는 애플리케이션을 두 디바이스에 각각 직접 설치해야 하며 새로운 버전이 나오면 지속적으로 업그레이드를 해야 한다. 상당히 번거로운 작업들이다. 그리고 각 디바이스에 업그레이드된 운영체제(윈도우, 아이폰OS, 안드로이드 등)를 설치해야 한다면 이런 작업을 반복적으로 수행해야만 한다. 

 

그런데 이것이 끝이 아니라는 것이다. 아이패드, 스마트 TV 등 지속적으로 개인이 활용하는 디바이스들이 늘어날 때 마다 아마도 이러한 작업을 디바이스 별로 또 반복적으로 해야 한다는 것이다. 이는 사용자에게는 너무 혹독한 현실이며 반드시 해결되야 하는 숙제라고 생각된다. 

 

반면에 만일 웹 브라우저만 있으면 사용자가 원하는 이메일, 오피스, 포토샾, 메신저, 트위터, 페이스북 등 모든 애플리케이션을 자신이 가지고 있는 PC, 스마트폰, TV, 네이게이션 등 모든 디바이스에서 사용할 수 있고, 어느 디바이스에서든 한번만 애플리케이션을 설치하면 자신의 다른 디바이스에서도 같은 애플리케이션을 반복적으로 설치할 필요가 없이 사용할 수 있다면, 아마도 대부분의 사용자들은 이러한 기술에 갈채를 보낼 것이다. 이러한 환경이 사용자가 바라는 이상적인 환경일 것이다. 

 

■ 멀티 디바이스 환경에서의 애플리케이션 개발자 현실과 이상 

 

현재 애플리케이션 개발자가 특정 애플리케이션을 개발할 때 부딪치는 가장 큰 문제는 지원할 목표 플랫폼의 개수에 따라 전혀 다른 개발환경에서 전혀 다른 API를 이용해서 같은 애플리케이션을 개발해야 한다는 것이다. 

 

즉, 아이폰 애플리케이션은 오프젝트-C라는 언어로 개발해야 하고, 안드로이드는 자바로, 심비안은 C/C++ 그리고 바다 플랫폼도 C/C++을 이용해서 개발해야 한다. 그럼 노키아의 심비안과 삼성의 바다 플랫폼은 개발 언어가 같기 때문에 개발 코드를 공유할 수 있지 않을까 하는 희망을 가질 수 있으나 이들 플랫폼에서 제공하는 API가 전혀 다르기 때문에 코드 공유가 어려운 것이 현실이다. 

 

반면에 만일 애플리케이션 개발자들이 한번 개발한 애플리케이션이 PC, 스마트폰, TV, 네이게이션 그리고 심지어 가전에서도 실행될 수 있는 세상이 온다면, 아마도 개발자들은 너무 좋아서 덩실덩실 춤이라도 추지 않을까 싶다. 이러한 환경이 개발자들이 진정으로 원하는 이상이라고 생각된다. 

 

■ 혁신적인 웹 표준으로 이상 실현

 

앞에서 이야기한 사용자와 애플리케이션 개발자가 원하는 이상은 실현될 수 있을까? 어떻게 이런 세상이 가능할 수 있을까? 하는 의구심이 생길 것이다. 현재 상황으로 필자가 답을 하자면 이러한 세상이 오고 있으며 이의 핵심에는 차세대 웹 표준인 HTML5가 있다. 

 

W3C에서 개발되고 있는 HTML5 표준은 웹 콘텐츠를 저작하기 위한 표준이 아니라 웹 애플리케이션 개발을 목표로 개발되고 있는 표준이다. 따라서 만일 디바이스에 설치된 웹 브라우저가 HTML5 표준을 지원한다면 웹 애플리케이션은 디바이스에 상관없이 실행이 될 것이다. 

 

또한 HTML5에서 제공하는 풍부한 기능을 활용하면 웹 애플리케이션이 기존의 네이티브 애플리케이션과 비교 해도 손색이 없을 정도의 기능 구현이 가능하다. 물론 아직 표준화가 마무리되지 않았고, 브라우저가 지원하는 기능의 편차가 크며, 컴퓨팅 파워가 약한 모바일 디바이스의 경우 비디오와 2차원 그래픽 등의 처리에서 일부 문제들이 있을 수 있다. 그러나 이러한 문제들은 시간이 지나면서 자연스럽게 해결이 될 것으로 조심스럽게 예상해 본다. 

 

앞으로 스마트폰, 테블릿, TV, 가전 등 디바이스의 종류와 이들을 위한 플랫폼의 종류가 증가하면 할수록 현재 많이 활용되고 있는 플래시, 실버라이트 등과 같은 특정 업체의 기술은 이러한 변화에 대응하기가 쉽지 않기 때문에 지속적으로 영향력이 감소할 것으로 예상된다. 반면 HTML5와 같은 웹 표준 기술의 중요성이 지속적으로 증가할 것으로 예상된다. 

 

따라서 국내 업체들은 HTML5와 같은 혁명적인 웹 표준에 대해 지속적인 관심이 필요하다. 또한 가능하다면 적극적으로 W3C 표준개발 과정에 참여할 것을 권고하고 싶다. 왜냐하면 승인된 표준을 잘 활용하는 것도 중요하지만 실제 표준개발 과정에서 논의되는 다양한 기술적인 이슈와 이를 해결해 가는 과정에서 배울 수 있는 유익한 것들이 많기 때문이다. 



저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. plumbing sterling 2013.02.12 01:49 신고  댓글주소  수정/삭제  댓글쓰기

    当我们想到一个介绍,我们通常考虑的演示文稿本身,其准备,筹划和排练。但它也是重要的考虑我们如何与我们的观众。...

  2. Fencing Upminster 2013.02.12 06:36 신고  댓글주소  수정/삭제  댓글쓰기

    回到这个比喻。你的防火墙将安全门。现在,这个安全门要停止每一辆汽车,并确保他们是一个受欢迎的客人。如果不欢迎他们,他们不能进入的细分。

  3. acompanhantes em sp 2014.04.30 06:39 신고  댓글주소  수정/삭제  댓글쓰기

    但它也是重要的考虑我们如何与我

HTML5와 관련해서 정말 많은 관련 표준과 이슈가 있지만 현재까지 가장 뜨거운 이슈는 HTML5 비디오 기능에 대한 이슈가 아닌가 싶다. 이는 이미 주요 브라우저들이 잘 지원을하면서 구글이 HTML5 기반의 유튜브 서비스를 시작하고 애플의 스티브 잡스가 애플의 디바이스에서 앞으로 플래쉬를 지원하지 않겠다고 선언을 하면서 HTML5 기반의 비디오 서비스가 빠르게 확산되고 있다. 아마도 현재까지 가장 많이 활용되는 HTML5 기능일 것이다. 그럼에도 불구하고 아직 남아있는 HTML5 비디오 표준 관련 이슈들이 있어 본 글에서 정리해 본다. 


코덱(CODEC) 이슈

HTML5의 표준 비디오 코덱에 대한 이슈는 W3C에서 논쟁만 많았을 뿐 업체들 간의 합의점을 도출하지 못한 이슈였고 이의 결과로 각 브라우저 밴더들의 정책에 따라 자신들이 원하는 코덱을 지원하고 있는 상황이다. 이의 주요 이슈는 코덱의 특허 및 라이센스 비용에 대한 문제였다. 이러한 이슈 때문에 현재 주요 브라우저 밴더가 지원하는 코덱을 보면 모질라 파이어폭스와 오페라는 오픈소스 코덱인 OGG, IE9과 애플 사파리는 H.264를 지원하고구글 크롬은 두가지 모두 지원하고 있다

그러나 지난 5월 19일 구글은 I/O 컨퍼런스에서 WebM이라는 미디어 코덱에 대한 오픈소스 프로젝트를 발표하면서 표준 비디오 코덱에 대한 일정 부분의 합이점을 만든 것으로 보인다. 현재까지 파이어폭스, 오페라, IE9이 이에 대한 지원을 공식적으로 발표했고, 어도비도 이를 지원하기로 결정했으며 스카이프 등 상당히 많은 업체들이 지원을 약속했다. 이는 회사의 비용과 관련된 민감한 요소였고 앞으로도 회사의 이익과 직결되는 요소이기 때문에 손쉽게 협력업체들을 결집된 것이다. 

그러나 웹 표준 코덱에 대한 내용이 모두 정리된 것은 아니다. 일단 애플은 WebM 프로젝트의 코덱 지원에 대해 언급하지 않고 있으며, WebM 프로젝트의 비디오 코덱인 VP8이 H.264의 기술을 상당부분 도용하여 향후 특허 이슈에 휘말릴 수 있다는 의견도 있다. 그러나 여러 전문가들은 구글이 이러한 특허 이슈들을 이미 처리했을 것으로 믿고 있으며, 이러한 이유로 특허에 민감한 파이어폭스, 오페라 등 많은 업체들이 이미 협력 업체로 들어왔을 것이라 생각한다. 

코덱과 관련하여 다른 중요한 이슈는 하드웨어 업체들이 WebM 코덱의 디코딩(decoding)에 대한 하드웨어 가속기능의 지원여부이다. 이게 중요한 이유는 컴퓨팅 파워가 상대적으로 약한 휴대폰부터 테블릿, PC, TV까지 미디어 재생에 문제가 없어야하기 때문이며, 또한 이는 향후 HD급의 미디어 서비스를 생각하면 반드시 필요한 필수적인 기능이기 때문이다. 현재는 데스크탑 및 랩탑에서 H.264의 디코딩에 대한 하드웨어 가속기능을 지원하지만 반면에 오픈소스 프로젝트인 OGG는 지원하지 않고있다. 그러나 WebM의 경우 이미 많은 하드웨어 업체들이 지원을 약속하고 있고 인텔도 최근 지원할 계획이 있는 것으로 발표하여 이에 대한 이슈는 없을 것으로 예상된다. 지원업체 대한 부분은 구글 WebM 프로젝트 런칭, HTML5 비디오 코덱(CODEC) 이슈 해결? 을 참고하기 바란다.

또한 모바일 브라우저의 WebM 지원에 대한 이슈도 있는데 애플을 제외하고는 문제가 없을것으로 조심스럽게 예측한다. 물론 WebM의 지원은 모바일 브라우저는 구글의 안드로이드가 가장 빨리 지원할 것으로 예상된다.

마지막으로 모질라가 W3C에 공식적으로 WebM 코덱을 HTML5의 표준 코덱화 하는 제안을 할 계획이라고 하니 앞으로의 결과를 지켜보자~


스트리밍(Streaming) 이슈

기존에 웹 비디오 서비스는 스트리밍 서버를 기반으로 RTP, RTCP, RTSP 등의 프로토콜을 기반으로 하고 있었으나 최근에느 이마저도 HTTP를 기반으로 옮겨가기 위한 시도들이 주요 IT 업체를 중심으로 이루어지고 있다. 이는 향후 웹 비디오 뿐 아니라 IPTV 그리고 모바일 IPTV 환경에도 커다란 영향을 미칠 것으로 예상된다. 더이상 고가의 스트리밍 서버가 필요가 없이 무료인 HTTP 서버를 사용하면되고, CDN을 기반으로 비디오 콘텐츠 전달이 효과적으로 가능하고 또한 방화벽 문제가 없기 때문이다. 기본적인 현황에 대해서만 일단 아래와 같이 정리해 보았다. 보다 자세한 기술적인 내용은 다음에 정리를 할 계획이다.

HTML5 표준에는 아직까지 스트리밍에 대한 부분이 없다. 예전에 RTP/RTCP와 같은 Live Streaming 지원에 대한 논의가 있었지만RTP/RTCP는 웹 이슈가 아니기 때문에 이를 웹 애플리케이션 프레임워크의 일부로 만드는 것은 어렵고특히 이를 위해서 별도의 서버가 필요하고 HTTP 서버와는 같이 동작하지 않는다는 문제점이 제기되었다.

최근에 여러 벤더들은 이러한 특정 프로토콜이나 서버를 지양하고 지능적인 브라우저(UA)와 HTTP 기반의 스트리밍을 제공하는 방향으로 옮겨가고 있다마이크로소프트는 Smooth Streaming”, 애플은 HTTP Live Streaming”, 어도비는 최근 HTTP Dynamic Streaming을 시작했다이들 벤더들은 MPEG 파일을 대상으로 이런 노력을 진행하고 있는 상황이며OGG는 이러한 부분에서 배제되었다. 그리고 앞으로 WebM을 지원할지 여부는 지켜봐야할 것 같다.

이와 관련된 표준화 기구의 활동들을 보면 3GPP2010 3월에 3GPP 릴리즈 93GPP Adaptive HTTP Streaming(AHS)를 정의하였고, IETF의 경우 애플이 HTTP Live Streaming 표준을 개발하고 있으며, 지금 필자도 참여하고 있는 MPEG(ISO/IEC JTC1 SC29 WG11) MPEG 파일 포맷에 대한 HTTP 기반 Adaptive Bitrate Streaming을 위한 표준 개발을 이제 막 시작하고있다.

HTTP 기반 Adaptive Bitrate Streaming은 동적인 bandwidth를 지원하고 안정적인 Live Streaming을 지원하기 위한 적절한 방법이나, 포맷에 독립적이며 객관적으로 증명이된 표준화된 방법은 없다. 특히 HTML5 이슈를 볼 때 우리는 적어도 MPEG4, OGG Theora/Vorbis 그리고 WebM은 지원해야할 것으로 본다. 따라서 이 이슈도 새로운 표준을 통해 명확하게 정리하는 것이 필요하다.


전체화면 모드

HTML5 비디오의 성공을 위해서는 전체화면으로 비디오를 보여주는기능이 필수적으로 필요하다. 이런 기능이 없으면 HTML5 비디오는 단편적인 비디오 클립 제공에만 적합하고 장편의 영화나 드라마 등을 보여주는데는 한계가 있다. 그러나 아직까지 전체화면에서 비디오를 실행하는 표준 API는 없는 상황이다. 파이어폭스 3.6에서는 전체화면으로 비디오를 재생하는 기능이 가능하며(오른쪽 클릭 이용), 웹킷은 ALT-클릭으로 전체화면 모드가 실행된다. 전체화면 비디오 재생을 위한 명확한 API가 필요하다.

지금까지 이야기한 이슈들은 이미 HTML5 표준화 활동에서 논의가 되고 있으니 본 이슈들은 어떻게든 정리가 될 것으로 예상해본다.


(참고문헌)

[1] HTML5 Video: Not Quite There Yet

[2] Smooth Streaming

[3] Dynamic streaming on demand with Flash Media Server 3.5

[4] 3GPP adaptive HTTP Streaming (AHS)

[5] HTTP Streaming of MPEG Media

 
저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. Channy 2010.05.28 11:49 신고  댓글주소  수정/삭제  댓글쓰기

    WebM 라이브 스트리밍에 대해서는 오픈 소스 스트리밍을 지원하는 flumotion에서 이미 구현을 한 바 있습니다. 기술적인 문제는 없을 듯 하네요 ㅎㅎ
    http://www.flumotion.com/blog/2010/05/21/news/webm-vp8-streaming-live-from-flumotion/

  2. 이원석(wonsuk73@gmail.com) 2010.05.28 14:25 신고  댓글주소  수정/삭제  댓글쓰기

    먼저 좋은 정보 감사합니다^^ 기술적인 문제가 없는 것에는 동의합니다~
    그런데 HTML5 비디오 관점에서 라이브 스트리밍을 위한 표준화 작업은 필요한 것 같습니다.

  3. article 2012.04.06 18:22 신고  댓글주소  수정/삭제  댓글쓰기

    제대 사챙먹지 하 람에겐 말좋더라구요.

  4. pandoras 2013.04.21 10:10 신고  댓글주소  수정/삭제  댓글쓰기

    하게 소개하면서 윤동주의

  5. acompanhantes em sp 2014.04.30 06:39 신고  댓글주소  수정/삭제  댓글쓰기

    위한 표준화 작업은 필요한 것 같습니다.

구글의 개발자 컨퍼런스인 구글 I/O 컨퍼런스 2010이 5/19일 ~ 20일 양일간에 걸쳐 개최되고 있는데, 첫날인 5/19일에 드디어 구글의 비디오 코덱 오픈 소스 프로젝트(일명 WebM)가 런칭되었다. 필자가 이 이슈와 관련해서 구글의 VP8 비디오 코덱 오픈 소스화??? 빠른 HTML5 기반 비디오 활성화 예상!!!와 HTML5 비디오 영향으로 플래시 쇄퇴?라는 글을 통해 언급한 적이 있다. 그러나 실제로 발표한 내용을 보니 필자가 예상한 것보다도 훨씬 큰 영향을 줄 것으로 예상된다.

일단 공식적인 프로젝트명이 WebM(an open web media project)이며 아래와 같은 내용을 목표로 한다.
  • BSD 스타일 로열티 프리 라이센스 형태의 VP8(고화질 비디오 코덱) 개발
  • 기존 오픈 소스 오디오 코덱인 Vorbis 개발
  • Matroska 미디어 콘테이너의 일부분을 기반으로 컨테이너 포맷 개발(확장자는 .webm)

일단 VP8이 주목을 받을 수 밖에 없는 이유는 기존에 비디오 코덱에 대한 오픈 소스 프로젝트가 없었던 것은 아니지만 H.264에 비해서 효율성이나 성능에 대한 부분이 크게 떨어져서 실제로 상용 서비스에 채택해서 활용되지 못한 상황에서, VP8은 오픈 소스 프로젝트이지만 H.264 보다 훨씬 더 좋은 효율성과 성능을 자랑하기 때문이다. 따라서 지금처럼 로열티를 지불하면서 H.264를 사용할 의미가 없을 것으로 보인다.

또한 한가지 더 놀라운 것은 WebM 프로젝트 런칭 시점임에도 불구하고 이를 지원하는 기업들의 수가 상당히 많고(아래그림 참조), 또한 빠른속도로 증가하고 있다는 것이다. 추가적으로 재밌는 것은 어도비도 지원 업체 중 하나라는 것인데, 이는 예전에 플래쉬에서 On2의 VP6를 사용했었다는 것을 생각하면 이해가 편할 것 같다. 어도비 입장에서도 로열티가 없는 코덱이 있다면 이를 마다할 이유가 없다. 그리고 지원업체들 중 하드웨어 업체들 대부분은 칩을 개발하는 업체들인데 이를 통해서 아마도 VP8에 대한 하드웨어 가속기능들이 빠르게 지원되지 않을까 생각된다.



WebM 프로젝트의 공식적인 런칭을 통해서 앞으로 HTML5 비디오 코덱에 대한 이슈는 해결이 될 것으로 조심스럽게 예측해 본다. 이미 크롬, 오페라, 파이어폭스가 곧바로 VP8을 지원할 것이라고 발표를 했으며, 5/19일 마이크로소프트 블로그에 IE9도 H.264와 함께 별도 플러그인 형태로 별도의 설치가 필요하지만 VP8을 지원할 것이라는 글이 올라온 것을 감안하며, VP8이 그야말로 웹 비디오의 공식적인 표준 코덱의 1순위임에 의심할 여지가 없어보인다. 또한 개인적으로 기존에 코덱에 대한 표준을 개발해온 MPEG(ISO/IEC JTC1 SC29 WG11) 표준화 활동이 향후 어떻게 대응이 가능할지 궁금증이 생긴다.


(참고문서)
저작자 표시 비영리 변경 금지
신고
Posted by 이원석(wonsuk73@gmail.com)

댓글을 달아 주세요

  1. arozin 2010.05.20 13:52 신고  댓글주소  수정/삭제  댓글쓰기

    국내 포탈들이 더 이상 H.264를 지원할 필요가 없을까요? 정말이요?
    국내 포탈들은 아직도 IE6도 지원을 해야하는 상황인데 너무 성급한 판단인 것 같습니다. 먼 훗날에 VP8이 윈도에 기본으로 설치되어 있고 IE9 이하 버전을 지원하지 않아도 되는 상황이면 생각해볼 수 있는 시나리오라고 생각됩니다. 특정 플랫폼(예를들어 맥?)이 H.264만 지원한다고 하면 H.264를 버릴 수는 없을 것입니다.

    IPTV나 모바일 IPTV도 단 기간에 H.264를 버릴 수는 없을 것입니다. 단말기에서 코덱이 지원되어야 하는데 이제 공개되면 칩셋, 소프트웨어 코덱이 단말에 들어가는 시간동안에는 당연히 실현 불가능한 솔루션이겠지요. 그리고 대부분의 비디오 표준에 H.264가 박혀 있는데(!) 여러 정치적인 이슈들 때문에도 단말에서 H.264를 몰아내는 상황은 일어나지 않을 것입니다. H.264를 사용하지 않으면 로얄티를 내지 않아도 되어서 좋겠지만 말입니다...

    물론 공개되어 있는 라이센스를 하지 않아도 되는 표준이 있다는 것은 좋은 것(!)입니다.

    짧은 생각 남겨봅니다. ^^;

  2. 이원석(wonsuk73@gmail.com) 2010.05.20 14:57 신고  댓글주소  수정/삭제  댓글쓰기

    전적으로 동의합니다~^^ 댓글 감사합니다~ ;)

  3. 김성훈 2010.05.20 18:18 신고  댓글주소  수정/삭제  댓글쓰기

    퍼가도 될까요? HTML5정보에 대해 잘 정리 되있는거 같아서요 ^^;;

  4. 최인묵 2010.05.20 21:47 신고  댓글주소  수정/삭제  댓글쓰기

    구글이 인수한 On2가 자체코덱뿐만 아니라 해당 코덱의 스트리밍 엔진까지도 만들고 있었던 것으로 볼때 VP8 코덱 영상의 전송을 위해 구글이 스트리밍 엔진까지도 무료화할지에 관심이 갑니다. 현재 H.264 코덱을 스트리밍하는 대표적인 엔진인 FMS(Flash Media Server)와 어도비출신의 엔지니어들이 만든 Wowza 엔진(짝퉁이지만 기능은 훨씬 더 훌륭합니다.) 모두 상용으로 판매되고 있는 상황에서, 영상의 코덱과는 필수불가분의 관계에 있는 스트리밍 엔진 시장도 많은 변화가 불가피한 것으로 보입니다.

  5. 이원석(wonsuk73@gmail.com) 2010.05.21 09:05 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 이슈에 대해서 말씀해 주셔서 감사합니다. 사실 현재 HTML5 비디오 남아있는 큰 이슈 중의 하나가 스트리밍입니다. 애플은 HTTP Live Streaming 이라는 이름으로 IETF, MPEG, 3GPP 등에서 표준화를 진행하고 있습니다. 구글은 어떤 방식을 들고나올지 있는지 궁금하네요^^

  6. 정태영 2010.06.03 00:46 신고  댓글주소  수정/삭제  댓글쓰기

    일부 내용에서 오해를 일으킬 수 있을 것으로 예상됩니다. WebM 비디오 코덱은 VP8입니다.

    VP8의 오픈소스 구현물은 BSD License (코드 저작권과 관련된 라이센스이죠)를 가지므로 무료가 맞습니다. 하지만 VP8에 사용된 기술들에 대한 특허 라이센스는 어떻게 될지 아직 미지수라고 생각합니다.

    H.264에 동일한 이야기를 적용해보겠습니다.

    H.264의 오픈소스 구현물은 x264이며 x264는 GPL License (역시 코드 저작권과 관련된 라이센스이죠)를 가지므로 제한적으로나마 무료라고 볼 수 있을겁니다. 하지만 H.264에 사용된 기술들에 대한 특허 라이센스는 무료가 아닙니다. 그렇기 때문에 MPEG-LA가 있는거고 라이센스료를 지불해야하는 것이겠죠. ;)

    다시 말해 오픈소스라는 것은 코드 저작권에 대한 라이센스 프리를 의미하는 것이지 기술에 대한 라이센스 프리를 의미하는 것이 아닙니다.

    얼마전 x264 개발자의 블로그에서 비교되었듯이 VP8에 사용된 기술들은 H.264에 체택되어 있는 기술들과 굉장히 유사(동일)합니다. VC-1이 라이센스 프리 코덱을 지향하며 표준으로 만들어졌지만 결과적으로 현재 특허 풀이 생성되었고, 라이센스 프리는 꿈이 되어버렸습니다.

    저는 VP8이 VC-1과 마찬가지의 수순을 밟을 것으로 예상하는데 생각이 조금 다르신 거 같네요. ;)

    • 이원석(wonsuk73@gmail.com) 2010.06.03 15:54 신고  댓글주소  수정/삭제

      좋은 댓글을 올려주셔서 감사합니다~

      말씀하신 특허이슈와 관련해서 저두 관심을 갖고 있는데 HTML5 관련 표준화를 하는 친구들은 이 부분이 이미 구글 내부적으로 정리가 되었다고 하더군요. 구글은 완전 무료로 쓸 수 있는 기술이 아니면 이렇게 공개하는 의미가 없습니다. 그리고 남은 특허 이슈들이 있다면 모질라는 파이어 폭스에 절대로 이 코덱을 넣지 않았을 겁니다.

      모든 것이 그렇지만 항상 다양한 의견들이 있을 수 있습니다^^ 어떤 것이 맞을지는 사실 잘 모르구요... 좀더 시간이 지나야 정확히 알 수 있겠죠.

      할튼 저의 개인적인 생각은 VP8 코덱에 대한 특허 이슈는 문제가 되지 않을 것으로 생각합니다. 그리고 혹시나 구글이 예상하지 못한 문제가 되더라도 구글이 해결을 할 것으로 예상해 봅니다^^

      앞으로도 좋은 의견 부탁드립니다~

  7. water cooling 2012.02.17 12:28 신고  댓글주소  수정/삭제  댓글쓰기

    도바나나다이어트해는

  8. this url 2012.04.01 08:41 신고  댓글주소  수정/삭제  댓글쓰기

    그의아이들(가족들이라네.정 벽고멋 리얼리즘 품입니.와~ 그냥사람이분하고 있 느낌입니.대하네요...

  9. massagem tantrica sp 2014.04.25 02:19 신고  댓글주소  수정/삭제  댓글쓰기

    기술들은 H.264에 체택되어 있는 기술들과 굉장히 유사(동일)합니다. VC-1이 라이센스 프리 코덱을 지향하며 표준으로 만들어졌지만 결과적으로 현재 특허

  10. acompanhantes em sp 2014.04.30 06:39 신고  댓글주소  수정/삭제  댓글쓰기

    HTML5 관련 표준화를 하는 친구들은 이 부분이 이미 구글 내부적으로 정리가 되었다고 하더군요. 구글은 완전 무료로 쓸 수 있는 기술이 아니면 이렇게 공개하는 의미가 없습니다. 그리고 남은 특허 이슈들이 있다면 모질라는 파이어 폭스에 절대로 이 코덱을 넣지 않았을 겁니다.



티스토리 툴바