웹표준 HTML5, 후속 버전 방향 이슈 부상

웹표준화기구 월드와이드웹컨소시엄(W3C)이 최신 웹표준 HTML5를 지난달 말 확정 공개했다. 이런 가운데 W3C는 HTML5 후속판격인 'HTML5.1' 표준화 작업을 2016년을 목표로 진행중이다.

그러나 HTML5.1은 안 만드는 것이 낫다는 얘기도 나오고 있어 주목된다.

HTML5 표준의 중요성을 인식해 온 웹 브라우저 개발업체, 웹 서비스 운영업체, 웹 기술 및 솔루션 전문업체, 웹 애플리케이션 개발사와 개발자, 인터넷 관련 정책을 입안하고 추진하는 정부 당국자 등 모든 업계 관계자들의 이해관계와 업무방식에 중대 변수로 작용할 전망이다.

■HTML5가 뭐길래

HTML5는 웹 문서 및 애플리케이션(이하 '앱')을 위한 표준 기술 규격이다. 지난 10월 28일 공식 표준(Recmmendation, '권고안')으로 확정됐다. 현재까지 권고안으로 공개된 웹표준 가운데 가장 마지막에 만들어진 것.

다시 쉽게 말하자면, 동일한 HTML을 처리할 때 브라우저가 다른 기술을 쓰더라도 그 결과물은 똑같이 나오도록 'HTML에서 A라고 쓴 건 a라는 뜻으로 하자, B라고 쓴 건 b라는 뜻으로 하자, …' 이렇게 온갖 표현에 대해 정의한 내용의 최신판이란 뜻이다.

검색, 지도, 메일, 동영상 등 부가프로그램 설치 없이 제공되는 인기 웹서비스 대부분이 이런 최신 웹 표준 기반이다.현재 대다수 웹 서비스 개발자와 서비스 공급업체들에게 익숙한 웹 표준은 거의 15년 전인 지난 1999년 12월 24일 확정된 'HTML4.01'이다. 웹의 역할이 간단한 하이퍼링크를 통한 정보간의 연결을 넘어 프로그래밍을 통한 복잡한 정보 공유와 가공까지 맡게 되면서, 부족한 기능에 대한 아쉬움이 컸다.

그래서 W3C는 구글, MS, 애플 등 유명 브라우저 개발업체의 기술 전문가들과 함께 기존 HTML 표준을 대폭 손질한 HTML5를 내놨다.

지난 2008년 1월 22일 '초안'을 낸지 거의 8년만에 완성됐다. 기존 웹문서 규격 HTML4.01과 웹프로그래밍 규격 'XHTML1.1'의 애플리케이션 프로그래밍 인터페이스(API)는 초안의 바탕으로 포함됐다.

이런 HTML5는 자바스크립트와의 연계를 통해 복잡한 웹앱을 구현할 수 있게 됐다. 어도비 플래시나 마이크로소프트(MS) 실버라이트같은 비표준 기술 없이도 웹 기반의 화상통화, 실시간 채팅, P2P 파일공유, 문서 및 사진 편집 도구, 멀티미디어 가속 성능을 활용한 게임과 앱을 만드는 게 가능해졌다.

구글, 네이버, 다음 등 국내외 검색서비스 업체를 비롯한 몇몇 사업자와 개발자들은 이미 HTML5 표준화 이전부터 신기능을 포함한 서비스를 테스트 내지 상용화했다. 플러그인에 의존해 온 서비스를 웹표준 기반으로 바꾼 사례도 찾아볼 수 있게 됐다.

이런 소위 'HTML5 서비스'가 돌아가려면 이용자들의 웹 브라우저가 최신 기술을 지원해야 한다. 물론 이같은 기술은 이미 실현됐다. MS, 모질라, 구글, 애플, 오페라 등 주요 개발업체가 표준화 이전 단계부터 꾸준히 HTML5 기능을 탑재한 브라우저를 만들어 배포한 덕분이다.

■HTML5.1은 'HTML5 개정증보판'

HTML5.1은 그 이름에서 짐작할 수 있듯 이번에 나온 HTML5의 후속 표준안이다. 앞서 HTML5가 올해 10월 표준화를 예고한 시점에 이미 HTML5.1의 표준화도 진행 중이었다.

HTML5.1의 완성 시점은 HTML5 최종 확정으로부터 불과 2년 뒤인 2016년 4분기로 예고돼 있었다. HTML4.01과 거기서 큰 도약을 이룬 HTML5의 표준화 시점이 15년이란 간격을 둔 것에 비해 훨씬 짧은 셈이다.

사실 HTML5.1 표준화는 HTML5 표준으로 함께 논의됐으나, 시간 관계상 이번 표준화 일정에 맞추기 어려워 밀린 내용을 포함하는 성격이 짙다. 중요도로 치면 사실상 이번에 표준화를 마친 HTML5와 대등한 수준이지만, 단지 표준화 일정상 함께 마무리되지 못했던 내용들이 HTML5.1에서 보완되는 것이다. 하지만 W3C에서 이런 HTML5.1 표준안을 만들지 않는 게 차라리 낫지 않느냐는 의견도 대두된 상황이다. 웹 표준화 무용론은 아니다. W3C의 복잡한 현행 표준화 방식으로는 HTML5같은 방대한 규격을 유지, 관리, 업그레이드하기가 앞으로도 쉽지 않을 것이라는 진단 때문이다.

W3C HTML5 대한민국관심그룹(KIG)의 이원석 의장은 최근 지난 2004년 초기 논의부터 최종 완성까지 거의 10년에 걸쳐 만들어진 HTML5 규격은 아주 많은 세부 규격으로 구성돼 있다며 그 문서를 종이에 출력하면 1천장에 육박할 정도로 방대하다고 묘사했다.

이어 표준화되지 않은 이슈들은 HTML5.1이란 이름으로 기존 규격을 보완해 2016년에 완료한다는 게 당초 W3C의 일정이었다며 그런데 W3C측의 HTML5 표준화에 과정에 참여한 어떤 사람들은 이런 거대한 스펙을 만들지 말고, 개별 기능(feature)에 대한 표준화를 하는 방식으로 바꾸자는 의견을 갖고 있다고 언급했다.

■하나의 거대한 표준 vs. 여러가지의 작은 표준

W3C 표준화 방식에 대한 문제제기는 대충 이렇게 요약된다. 우선 HTML5처럼 거대한 표준을 관리하기보다는, 작은 표준을 만드는 게 효율적이고 여러모로 유리하다. 방대한 표준을 한꺼번에 정기적으로 개편하려면 물리적인 시간이 많이 걸리고 절차가 복잡하다. 이건 변화가 빠른 IT업계 전체 흐름과도 맞지 않다.

표준화를 작은 단위로 나눠 할 경우, 주제별로 다른 표준화에 참여하는 전문가들이 동일한 일정에 맞춰 움직일 필요가 없다. 내용이 비교적 간단하거나 이미 검증이 마무리된 표준은 빨리 확정하고, 복잡하거나 시장 여건상 도입이 어려운 표준은 좀 더 신중하게 진행해 나중에 확정할 수 있는 것이다.

2가지 표준화 방식을 놓고 어떤 게 나을지에 대한 의견이 오가는 중이다. 기존대로 HTML5와 HTML5.1 같은 거대 단위 표준을 (상호 일정 조율해서 정기적으로) 내놓는 방식과, 새롭게 그때그때 (시장 수요, 전문가들간의 의견 조율 등) 상황에 따라 개별 기술에 대한 표준화를 추진하는 방식 중 어느 쪽이 적절한지에 대한 토론이다. HTML5 문서 표준화 작업을 수행한 W3C의 로빈 버존 에디터(editor)는 후자 쪽에 가까운 견해를 갖고 있는 대표적 인물이다. 그는 '서비스워커', '픽처', '웹RTC', '푸시API' 등 기능이나 기술 주제별로 표준화를 추진하는 방안이 미래 웹기술 표준화에 더 알맞은 방식이라고 여긴다.

작은 기능 단위로 웹 표준을 만들어나가는 것의 장점에 대해 묻자, 버존 에디터는 특정 기능의 검토와 구현을 원하는 사람들이 표준화 과정을 추적하고 의견을 제시하는 등의 협력을 더 쉽게 만들고, 단일 기능에 대한 상호운용성 확보와 테스트 수행 작업도 간편해진다고 설명했다.