개발자만 수렁에 빠졌나. 이동통신사나 제조사 사정도 크게 다르지 않다. 이통사는 iOS, 안드로이드OS, 블랙베리OS 등 다양한 모바일 OS를 탑재한 스마트폰을 유통한다. 제조사도 마찬가지다. 기계만 뿌려놓으면 뭐하나. 그 위에서 돌아갈 소프트웨어, 즉 앱을 확보해야 한다. 헌데 OS별로 일일이 앱을 만드는 개발자를 보고 있노라면 속이 탄다. 진열대가 찰 때까지 마냥 기다릴 수도 없는 노릇이다.

이런 고민들을 한꺼번에 해결할 수 없을까. 조만영 미래웹기술연구소 대표는 ‘표준 웹기술’에서 해답을 찾으라고 말한다. 웹 기술? 그건 웹개발자들에게나 해당되는 얘기 아닌가? 네이티브 앱이 아닌, 모바일웹 기반의 ‘웹 앱’을 만들라는 얘기처럼 들리는데….

“표준 웹기술을 활용해 네이티브 앱을 만들자는 흐름은 지난해부터 꾸준히 증가해왔습니다. 국내에선 아직 잘 알려지지 않았지만요. 요즘처럼 OS와 화면 크기가 제각각인 모바일 환경에서, 개발자가 일일이 그 환경에 맞는 네이티브 앱을 개발하기란 만만찮은 일이죠. 표준 웹기술을 활용하면 한 번 제작한 앱을 여러 OS나 기기로 한꺼번에 배포할 수 있습니다. 개발 비용도, 시간도 단축시키고 N스크린 환경에도 발빠르게 대응할 수 있는 것이죠.”

여기서 표준 웹기술이란 HTML, CSS, 자바스크립트를 일컫는다. 국제표준 제정기구인 월드와이드웹 컨소시엄(W3C)이 제정한 표준 기술들이다. 웹개발자에겐 친숙한 기술인데다 특정 기업에 종속되지 않은 열린 기술이다. 헌데, 이들을 이용해 어떻게 서로 다른 OS와 기기에 맞는 네이티브 앱을 만든다는 얘길까.

비결은 ‘폰갭‘이란 기술이다. 웹으로 만든 앱(웹 앱)을 스마트폰이나 태블릿용 네이티브 앱으로 변환해주는 오픈소스 프레임워크다. 화면 크기나 플랫폼에 구애받지도 않는다. 예컨대 표준 웹기술을 이용해 전자책 앱을 만든 다음, 이를 폰갭 기술을 이용해 아이폰·안드로이드폰·블랙베리용 앱이나 아이패드·갤럭시탭용 앱으로 한 번에 변환해 배포할 수 있다는 얘기다.

이같은 기술이 새로운 건 아니다. 2008년 폰갭을 시작으로 지난해 ‘타이태니엄 앱셀러레이터‘가 이같은 네이티브 앱 변환 프레임워크를 제공한다. 어도비시스템즈는 올해 ‘어도비CS5.5′를 내놓으며 ‘드림위버CS5.5′에 폰갭 프레임워크를 적용하기도 했다. 국내에선 올해 KTH가 ‘앱스프레소‘란 이름으로 비슷한 통합 개발환경을 공개한 바 있다. 현재 폰갭처럼 웹 앱을 네이티브 앱으로 변환해주는 기술은 20여종이 나와 있다.

“웹은 태어날 때부터 열린 기술이었습니다. 표준화된 기술은 웹브라우저만 지원되면 어떤 기기나 OS에서든 막힘 없이 이용할 수 있게 해주죠. 특허도 없고, 어떤 회사든 사용할 수 있습니다. 그래서 개선이 빨리 이뤄지죠. 기기를 제한한 적도 없습니다. 태생이 N스크린에 대응하는 기술이란 뜻입니다. 그런 웹 기술의 중립성이 지금 시대와 맞아떨어져 꽃을 피우는 것입니다.”

기술 원리는 이렇다. 웹개발자는 HTML이나 CSS, 자바스크립트 기술을 이용해 원하는 기능을 담은 웹 앱을 제작한다. 그런 다음 폰갭 같은 프레임워크로 이를 감싸준다. 이 과정은 마우스 클릭 한 번으로 끝난다. 폰갭 프레임워크를 적용한 앱은 말 그대로 스마트폰이 인식하는 네이티브 앱이 된다. 이제 개발자는 이 앱을 애플 앱스토어나 안드로이드마켓, 블랙베리 앱월드 등 원하는 모바일 앱스토어에 뿌리면 된다.

폰갭은 게다가 오픈소스 프레임워크다. 개발자가 일일이 이용자화면(UI)을 구현하기 위해 번거로운 코딩 과정을 거칠 필요도 없다. 2006년 W3C가 ‘위젯’ 스펙을 제정한 뒤 일이 쉬워졌다. 웹에 공개된 다양한 웹UI 프레임워크를 활용하면 UI 설계 고민도 줄어든다. jQ터치나 센차터치 같은 웹사이트를 방문하면 다양한 자바스크립트 라이브러리와 예제들을 보고 내려받을 수 있다.

이같은 기술들을 활용하면 개발자는 어떤 이익을 얻을 수 있을까. 무엇보다 훨씬 큰 시장에 자기 앱을 인정받을 기회를 갖게 된다. 아이폰이나 안드로이드폰 시장별로 앱을 따로 제작하지 않아도, 한 번 제작한 앱을 여러 시장에 동시에 선보일 수 있기 때문이다. 자연스레 수익 창출 기회도 올라간다.

이런 움직임은 이미 해외에서 시작됐다. 2010년 2월 열린 ‘모바일 월드 콩그레스 2010′에선 전세계 24개 이통사가 참여한 ‘홀세일 앱 커뮤니티’(WAC)가 공식 출범했다. 국내 KT와 SK텔레콤을 포함해 AT&T, 버라이즌, 보다폰, 도이치텔레콤 등 유명 이통사가 ‘열린 앱 장터’를 만들자는 데 뜻을 모은 셈이다. 삼성전자와 LG전자, 소니에릭슨 같은 제조업체도 힘을 보탰다. 국내에서도 이통 3사를 중심으로 오는 8월을 목표로 한국형 통합 앱스토어 KWAC 구축을 추진중이다.

“폰갭 같은 기술은 한마디로 웹 앱을 감싸는 기술에 불과합니다. 실제 앱 성능은 HTML과 CSS, 자바스크립트로 만든 앱의 구동 능력에 따라 좌우되죠. 이렇게 만든 네이티브 앱은 웹브라우저 엔진을 기반으로 동작합니다. 다만, 현재 스마트폰에 내장된 웹브라우저가 제대로 지원하지 않는 웹GL 기반 앱들은 아직까지 사각지대로 남아 있습니다.”

미래웹기술연구소가 도입한 폰갭은 올해 4월28일 ‘폰갭0.9.5′를 내놓으며 국내 삼성전자가 선보인 ‘바다OS’도 공식 지원하기 시작했다. 웹 앱으로 만들어 바다OS 앱스토어인 ‘삼성 웹 앱스’로도 제공할 수 있게 된 셈이다. 미래웹기술연구소는 폰갭보다 앞선 2월부터 바다OS용 앱 프레임워크 연구를 진행해왔다. 연구소는 최근 이 결과를 담은 보고서를 무료로 내려받을 수 있도록 PDF 파일로 공개했다. PDF로 만든 전자책을 간단한 변환 과정을 거쳐 여러 앱스토어에 손쉽게 적용할 수 있는 전자책 앱 변환 솔루션도 제공한다.

“지금은 스마트폰 뿐 아니라 가전 영역도 N스크린, N디바이스 환경으로 변화하고 있습니다. 스마트폰 앱 개발 트렌드도 웹기술을 활용하는 쪽으로 선회하고 있고요. 앞으로는 웹기술이 앱 개발 분야에서 더욱 각광받게 될 겁니다. 폰갭 같은 기술은 최근 적용된 바다OS까지 모두 7종류 모바일 운영체제를 지원합니다. 국내 개발자들도 이런 흐름에 빨리 올라타고, 표준 웹기술을 활용해 N스크린 환경에 효과적으로 대응했으면 하는 바람입니다.”

조만영 미래웹기술연구소 대표는 2006년 8월부터 4년6개월여 동안 오페라소프트웨어에서 일하며 국내외 주요 스마트폰과 TV, 셋톱박스 등에 모바일 웹브라우저를 적용하도록 지원하는 일을 도맡았다. 삼성전자 옴니아1·2에 들어간 ‘오페라 모바일’이나 삼성전자·보다폰 전략폰인 ‘보다폰360′에 들어간 웹브라우저가 모두 그의 작품이다. 최근에는 휴맥스 셋톱박스에 웹브라우저를 탑재해 스마트TV 경험을 확장하는 작업을 진행하기도 했다. W3C 대한민국 사무국에서 ‘비즈니스 앤 테크놀로지 스페셜리스트’를 맡아 웹 기술의 중요성을 알리고 강연하는 웹표준 전도사이기도 하다.

PC용 웹에선 이같은 웹접근성과 상호운용성을 보장하는 일이 점차 당연시되는 추세다. 모바일웹으로 눈을 돌려보자. 아직 갈 길이 멀어보인다. 어떡하면 모바일웹에서도 접근성과 상호운용성을 보장할 수 있을까.

다양한 웹표준을 제정·보급하는 월드와이드웹 컨소시엄(W3C)은 이런 개발자를 위한 지침을 제공한다. 2010년 12월14일에 공개한 ‘모바일웹 애플리케이션 모범사례’(MWABP) 권고안을 보자. 웹표준을 따르면서도 풍부한 이용자 경험(UX)을 제공하는 모바일웹을 설계하는 방법을 빼곡히 담았다.

긴 문서를 일일이 검토하기 어려운가. 핵심만 추려 카드(PDF) 형태로 제작한 자료를 참조하면 된다. 네트워크 병목과 지연을 줄이기 위한 개발 방법론, 다양한 이용자 환경에 맞는 기능 제공법, 웹 원칙을 지키면서도 유연하게 구조를 설계하는 방법 등을 담았다.

W3C 대한민국 사무국이 ‘모바일 웹 애플리케이션 모범사례’ 카드를 한글로 번역해 공개했다. 이 웹사이트도 HTML5와 CSS3를 충실히 따랐다. 카드 이미지만 떼내 소개한다. 원본이 담긴 웹사이트를 방문하면 각 항목별 바로가기 주소가 포함된 자료가 뜬다.

W3C는 모바일 접근성을 보장하기 위한 ‘모바일웹 모범사례‘(MWBP), ‘웹 콘텐츠 접근성 지침 2.0‘(WCAG20)도 함께 제공한다.

출처 : http://www.w3c.or.kr/Translation/MWABP.

‘웹사이트를 만들 땐 되도록 웹표준을 지켜야 한다’고들 말한다. 이 때 ‘웹표준’은 누가 만들까. 표준을 제정하는 기관은 여럿이지만, 가장 권위 있고 믿음직한 곳은 하나다. 월드와이드웹 컨소시엄(W3C)이다.

W3C는 ‘웹’에 관한 모든 기술과 규약에 관한 글로벌 표준안 마련을 주도하는 비영리단체다. 우리에게 낯익은 HTML, HTTP, URL, XML 같은 웹 기본 표준부터 위젯, 디바이스 API, HTML5 같은 최신 웹표준 기술이 W3C에서 마련됐다. W3C 의장은 ‘인터넷의 창시자’로 유명한 팀 버너스 리가 맡고 있다. 2010년 11월 현재 전세계 326곳 기관과 기업이 W3C 회원으로 가입돼 있으며, 한국에선 한국전자통신연구원(ETRI), 모바일웹2.0포럼, SK텔레콤, 삼성전자, LG전자가 회원사로 참여한다. 전세계 18곳에 사무국을 두고 있는데, 한국에선 ETRI가 2002년 3월부터 공식 지정돼 활동하고 있다.

이 W3C에서 CEO를 맡고 있는 제프 자페(Jeff Jaffe)가 11월10일 처음으로 한국을 찾았다. 스페인과 독일을 거쳐 한국을 찍고 중국과 일본으로 이어지는 회원사 연례 방문 활동이기도 하지만, 또 다른 뜻이 담겨 있다. 11월10일 공식 발족한 ‘W3C HTML5 한국관심그룹(KIG)’의 첫 회의를 축하하기 위해서다. 그는 이 회의에서 기조 연설을 맡았다.

11일 오후에 열린 KIG 회의를 앞두고 제프 자페 CEO를 만났다. 그는 올해 11월 열린 W3C 총회에서 ‘개방형 웹 플랫폼’을 선언했으며, 방한 기간 동안 웹표준 작업의 중요성을 국내 기업들에 강조하고 협력방안도 논의할 예정이라고 했다.

왜 웹표준을 따르면 좋을까. 제프 자페 CEO는 “웹표준을 지키면 내 아이디어를 표준화하고 글로벌 시장에서 선보일 수 있다”고 강조했다. 마이크로소프트와 구글, 모질라그룹과 오페라소프트웨어, 애플까지 주요 웹브라우저 업체들이 W3C 워킹그룹에 참여해 웹표준 기술을 지원하는 웹브라우저를 만드는 데 앞장서고 있다. 그러니 특정 웹브라우저나 기업에 종속된 기술을 쓰는 것보다 웹표준 기반 기술로 아이디어를 구현하면, 웹브라우저가 내장된 어떤 플랫폼이나 단말기든 이를 동시에 선보일 수 있다는 얘기다.

한동안 웹표준 지원에 미적거리던 마이크로소프트도 인터넷익스플로러8(IE8)부터는 웹표준 기술 지원에 앞장서는 모양새다. 곧 나올 IE9는 HTML5와 같은 최신 웹표준 기술도 적극 받아들인다. 그래서 제프 자페 CEO는 “작은 회사라 해도 웹표준 기반으로 아이디어를 구현하면 비즈니스 현장에서 기술력을 입증받는 기회를 갖게 된다”고 웹표준 준수의 혜택을 설명했다.

‘웹은 죽었다’고 선언한 해외 유명 매체의 도발적 지적에도 W3C는 고개를 가로젓는다. 제프 자페 CEO는 “전세계에서 30억명이 넘는 사람이 매일 웹에 접속하고 있다”라며 “웹은 다양한 층위가 있고 이는 심플 웹, 애플리케이션, 소셜 웹 등 다양한 형태로 구현될 뿐”이라고 되받았다. “HTML5 같은 최신 웹표준 기술을 사용하면 지금까지 특정 회사 기술로 구현할 수 있다고 생각했던 다양한 웹기반 그래픽과 서비스를 유연하게 구현할 수 있고, 실제로도 많은 사례들이 나오고 있다”고도 말했다. 그건 곧 ‘웹은 죽지 않았다’는 반증이기도 하다는 게 제프 자페 CEO의 지적이다.

모바일 세상에서 웹과 응용프로그램(앱)의 주도권 다툼에 대해서도 W3C는 모바일웹의 손을 들어준다. “앱의 효용성을 무시하지 않습니다. 웹이든 앱이든 장단점이 있는 만큼, 기업이 필요에 따라 비즈니스 요구에 맞춰 적용하면 됩니다. 하지만 생각해볼 일입니다. 앱은 하나의 플랫폼에서 돌아가므로 서로 다른 기기나 플랫폼용으로 중복 개발·관리해야 하는 어려움이 있지만, 웹은 브라우저만 있으면 멀티 플랫폼에서 문제 없이 구현될 수 있는 게 장점이죠.”

허나 궁금하다. 누구든 똑같은 표준 기술로 제품이나 서비스를 만들면, 서로 경쟁이 이뤄질 수 있을까. 이는 웹표준 기술 위에 자사 독자 기술을 얹으려는 기업들이 즐겨 내세우는 주장이기도 하다. 제프 자페 CEO가 내놓은 해법은 간명하다.

“특정 기업에 종속된 기술은 질 수 밖에 없습니다. 아이디어가 있다면 그걸 W3C로 가져와서 표준화하면 됩니다. 기업이 혁신을 이끌고 싶어하지만 그 혁신이 웹표준과 충돌하는 경우가 더러 있습니다. 혁신은 매력적이고 위대해 보이지만, 그 열매는 작을 뿐입니다. 지속가능한 발전과 성장에 필요한 건 웹표준을 따르는 일입니다. 우리가 극복해야 할 것은 바로 이 혁신과 웹표준 사이의 긴장입니다.”

제프 자페는 MIT에서 전기공학과 전산공학 박사학위를 받고 IBM을 거쳐 벨연구소 연구소장과 노벨연구소 CTO를 역임했다. 빌 클린턴 정부 시절에는 대통령 자문단을 맡기도 했다. 2010년 3월부터는 W3C CEO로 활동하고 있다.

우연의 일치일까요. ‘블로터 포럼’을 진행한 뒤 애플 스티브 잡스가 때마침 제대로 한 방 날렸더군요. 아이폰에서 플래시를 지원하라는 어도비를 향해 ‘플래시 대안은 HTML5′라며 ‘어도비는 게으르다’고 심기를 건드린 겁니다.

왜 갑자기 여기저기서 HTML5를 외치는 걸까요. 특정분야 개발자들을 빼고는 대체로 비슷한 반응을 보입니다. HTML에 익숙한 사람도 HTML5 앞에선 꿀 먹은 벙어리마냥 얌전해집니다. 딱딱하고 어려운 게 사실이지만 알아두고 준비해야 할 기술. 이번 ‘블로터 포럼’에선 입문자 눈높이에 맞춰 HTML5를 들여다보고 싶었습니다.

• 일시 : 2010년 1월27일(목) 오후 5시~7시
• 장소 : SK커뮤니케이션즈 회의실
• 참석자 : 윤석찬 다음커뮤니케이션 DNA랩 팀장, 도안구·이희욱·주민영 블로터닷넷 기자

이희욱 | 오늘 주제가 참 어렵다. HTML5 문외한 입장에서 궁금한 점이 많다. 먼저 묻고 싶다. HTML5가 뭔가?

윤석찬 | HTML5가 어느 날 갑자기 나타난 게 아니다. 사연이 길다. 1998년 HTML4.01 이후 웹표준을 개발하는 국제 컨소시엄인 W3C는 XHTML 표준 개발에 박차를 가했다. 웹브라우저 전쟁 이후 그 작업에서 웹브라우저 제조사들이 빠졌다. 이후 웹표준의 방향은 XML을 기반한 꽤 이상적인 표준을 만들기 시작했다. 2004년 파이어폭스가 나오고 아작스(Ajax)와 웹2.0이 활성화되면서 문서가 아닌 웹애플리케이션을 위한 웹표준의 재정비가 필요했다.

하지만 이러한 현실적 요구를 W3C가 받아들이지 않았다. 웹브라우저 제조사들에게는 W3C의 XHTML2.0과 XML기반 DOM 및 이벤트 핸들러 등은 루비콘 강을 건너는 것이다. 당시 XHTML 문서가 전체 웹에서 5%에 불과했고 웹브라우저 엔진들의 차이 탓에 개발자들은 ‘크로스 브라우징’에 생고생을 하고 있었다. 2004년 W3C의 한 워크샵에서 서로 틀어진 뒤 모질라와 오페라, 애플과 구글은 별도의 ‘웹 하이퍼텍스트 애플리케이션 테크놀로지 워킹그룹’(WHATWG)이라는 공개 표준 그룹을 만들고 새로운 HTML 표준안을 만들기 시작했다. 이것이 바로 HTML5의 시초다.

도안구 | W3C와 웹브라우저 제조사 사이에 그런 의견 다툼이 있었나? 흥미롭다.

윤석찬 | 반목이 오래가지는 않았다. 2006년 팀 버너스 리 경이 ‘리인벤팅 HTML’(Reinventing HTML)이라는 글을 쓰고 WHATWG을 W3C 안으로 받아들이기로 결정하면서 2007년초께 다시 W3C에 HTML 워킹그룹이 결성됐다. 당시 재미있는 에피소드라면 WHATWG의 개방적 표준 활동에 참여하던 700여명 멤버들이 W3C 안 초청 전문가(Invite Expert) 형식으로 대거 들어왔다는 점이다. W3C 역사상 초유의 일이다. 그 때 나도 함께 했다.

기존 WHATWG 표준 초안을 가져오며 ‘HTML5′라 불렀다. 당시 IE7 개발을 맡았던 MS 유명 아키텍트인 크리스 윌슨이 워킹그룹 의장이 됐고 모질라, 오페라, 애플, 구글 등 모두 참여해 HTML5 표준을 만들고 있다.

주민영 | 복잡한 과정을 거쳤다. HTML5는 왜 만들어지게 됐나?

윤석찬 | 기존 웹브라우저들이 제공하는 웹표준 수준이 조금씩 다르고 기존 스펙의 모호성으로 인해 버그도 많다. 제조사마다 다른 렌더링 엔진을 쓰고 당연히 차이가 있다. 웹 개발자들은 각각 테스트해봐야 하는 어려움이 있다. 이를 해소하기 위해 HTML5의 새로운 문서 형식 제안하고, 이 독타입(DOCTYPE)을 사용할 경우 기존 엔진 문제점들을 고쳐 제공해줘 웹 개발자들을 고생에서 벗어나게 해주자는 취지다.

HTML5 독타입은 매우 간단하다. ‘< !DOCTYPE HTML >’ 이렇게 HTML 파일 맨 앞 줄에 넣어주면 끝이다. 이 뒤에 나오는 코드는 웹브라우저마다 HTML5에 맞춰 렌더링한다. HTML5 표준 초안은 웹브라우저 엔진 개발자들을 위해 만든 것으로, 보다 상세하게 구현 내용을 적고 있다.

두 번째 목적은 동적 웹애플리케이션을 지원할 리치 웹 기술을 담고 있다는 것이다. 멀티미디어를 다루는 ‘canvas’, ‘video’, ‘audio’ 태그를 비롯해 웹브라우저 내 로컬 스토리지를 다루는 돔 API와 드래그앤드롭 API 등 일반 표준 문서에서는 보기 힘든 다양한 기술이 뒤섞여 있다. 특히 웹 개발자 수고를 덜어줄 ‘웹폼2.0′이라는 표준과 함께 쓰면 보다 멋진 리치 웹애플리케이션을 만들 수 있다.

웹브라우저 안에 DB를 탑재해 로컬 스토리지로 활용해 오프라인에서도 데이터를 싱크해 활용할 수 있다. 구글 G메일 ‘오프라인’ 기능이 그렇게 구현돼 있다.

이희욱 | 리치 웹애플리케이션이라면 플래시나 실버라이트를 얘기할 때 자주들 언급한다. HTML5가 리치 웹에 주목하는 이유는 무엇인가?

윤석찬 | 웹브라우저 업체 입장에서 리치 웹 기술에 관심을 갖는 이유는 다양하다. 제가 참여하고 있는 모질라 커뮤니티의 경우, 웹은 읽을 수 있고(readable), 저장할 수 있고(Indexable), 편집할 수 있어야(editable) 한다고 믿는다. HTML 소스를 보고, 복사를 하고, 고칠 수 있었기 때문에 웹 문서가 비약적인 성공을 했다. 기존 플러그인 기반 리치 웹 기술들, 예컨대 플래시나 실버라이트는 그게 어렵다. 물론 이들도 XML 기술을 통해 이용자화면(UI)을 만들 때 스크립트 언어로 동작을 제어한다. 하지만 결국 읽을 수 없는 ‘바이너리’를 포함하고 있다. 이는 웹 본질과 일치하지 않는다. HTML5가 리치 웹 기술의 선택 가능한 대안으로 자리잡아야 한다.

물론 아직 플래시나 실버라이트에 비해 HTML5가 제한 사항이 많다. 하지만 궁극적으로 웹이 나아갈 방향이라고 본다. 구글이나 오페라와 애플도 이러한 점에 동의를 하고 있고 MS 역시 미온적이지만 참여를 하고 있다. 초창기 많은 사람들이 ‘리치 웹 환경에서 HTML5가 성공할 것인가’라는 물음엔 회의적이었다. 지금은 많이 바뀌었다. 이런 ‘블로터 포럼’에도 불려다니는 걸 보면. (웃음)

도안구 | HTML5가 주목 받게 된 특별한 계기나 사건이 있나?

윤석찬 | 아무래도 구글 영향이 컸다. 지난 2009년 4월에 열린 ‘구글 I/O 컨퍼런스’가 전환점이 됐다. 구글은 2008년 첫 구글 I/O 컨퍼런스에서 안드로이드와 구글 기어스를 발표했다. 구글 기어스는 리치 웹애플리케이션을 만들기 위한 웹브라우저 플러그인이었다. 하지만 2009년 컨퍼런스에선 구글 CTO가 첫날 주제로 HTML5를 다루고, 둘쨋날 구글 웨이브를 다뤘다. 그런데 첫날 HTML5를 얘기하면서 ‘HTML5가 대세’란 분위기를 크게 조성했다. 자사 웹브라우저인 ‘구글 크롬’에도 아직 탑재 안 된 HTML5 기술을 파이어폭스와 사파리로 시연할 정도였다. 그러면서 인식이 많이 바뀌었다. 구글이 드디어 HTML5에 베팅하는구나. 시장에도 긍정적인 신호를 줬다.

특히 모바일을 보면 완전히 다르다. 지금 PC의 웹브라우저 시장은 IE가 다수이고 파이어폭스, 크롬, 사파리가 따라오는 모양새다. 모바일 웹에서는 유럽 스마트폰 시장은 오페라가, 아이폰은 사파리를 기반하고 있다. 안드로이드폰이 나오면 크롬이 주력으로 들어간다. 모질라를 빼도 메이저 3사다. 결국 IE가 대세가 아니다. 모바일 애플리케이션 개발 환경은 PC 못지않게 폐쇄적이다. 이런 상황은 오래 가지 않을 것이고, 결국 범용 리치 웹 환경을 사용하는 것으로 바뀔 것이다. 특히 모바일 웹의 변화가 더욱 빠를 것 같다.

주민영 | 허나 애플 아이폰이 촉발시킨 앱스토어도 개발자 입장에선 큰 기회다.

윤석찬 | 물론 지금은 앱스토어가 유행이다. 돈벌이가 아니라 서비스를 만드는 관점에서 보면, 지금은 앱스토어용 따로, 웹애플리케이션 따로 만드는 식으로 과도기다. 결국 HTML 표준으로 웹 문서를 만들듯 웹애플리케이션도 표준으로 쉽게 만들고 서비스하는 환경이 와야 한다. 폐쇄적인 개발 플랫폼을 기반으로 하는 플레이어도 필요하지만 모두에게 이익이 되는 범용 개발 환경이 웹의 목표이고 지향하는 바다. 웹 개발자들은 이를 간과하면 안된다.

이희욱 | HTML5는 그럼 웹 개발자들을 위한 표준 기술 문서인가?

윤석찬 | 앞서 말했듯이 HTML5는 웹브라우저 엔진 개발자를 위한 스펙이다. 하지만 이 안에는 렌더링 엔진 뿐만 아니라 중요한 리치 웹 기술이 포함돼 있다. 예컨대 크롬이 탭마다 적용한 병렬 프로세스 기능이나 외부와 데이터를 주고받을 때 웹브라우저가 어떻게 처리할 지 규약도 있고, 데스크톱에서 웹브라우저로 드래그앤드롭한 파일을 어떻게 처리할 지에 관한 스펙도 있다. HTML 뿐 아니라 방대한 내용들이 추가되고 있다. 초안 자체가 어렵기 때문에 웹 개발자들이 이를 쉽게 이해하고 이용할 수 있도록 설명 문서들도 함께 만들고 있다.

도안구 | 그 스펙은 계속 추가되고 실제 구현되고 있나?

윤석찬 | W3C 표준 제정 과정을 보면, HTML5는 현재는 초안 단계다. 한 단계 넘어가기 위해 준비 중이고 이는 정해진 내부 프로세스를 따라가는 것이다. 무엇보다 중요한 건, HTML5의 어떤 기술이 웹브라우저에서 구현되고 있고 얼마만큼 사용할 수 있느냐 하는 점이다. 현재 PC 기반 웹브라우저에서 HTML5의 주요 기능을 쓰는 데는 아직 무리가 있다.

가장 중요한 건 IE가 아직 안 바뀌었고, 각 웹브라우저 제조사 사이에도 기술적 차이가 있다. 하지만 ‘canvas’, ‘video’, ‘audio’ 태그와 돔 스토리지 등은 어느정도 쓸 수 있는 단계에 와 있다. 올해 초 MS가 공식적으로 IE9에서 HTML5를 지원하겠다고 밝혔다. 어느 정도까지 지원할 지 모르겠지만, 올 3월 MIX에서 HTML5 기능을 탑재한 IE9을 만나볼 수 있을 것으로 기대한다.

주민영 | 유튜브나 비메오 같은 동영상 공유 사이트가 플래시 대신 HTML5를 수용하겠다고 해서 화제가 되기도 했다.

윤석찬 | 유튜브나 비메오 등이 수용한 건 HTML5의 일부다. ‘video’ 태그를 이용해 플러그인 도움 없이도 웹브라우저 만으로도 동영상을 서비스할 수 있다. 지금까지는 윈도우 미디어 플레이어나 플래시 플러그인을 깔아야만 가능했다. 문제는 동영상 코덱에 있다. 파이어폭스와 오페라는 오픈소스 기반 OGG 테오라(OGG Theora)를 지지해왔다. 하지만 크롬과 사파리는 특허료를 내야하는 H.264 MPEG 포맷을 지원한다. 유튜브와 비메오도 H.264 코덱을 지원하기 시작했다. 이 때문에 파이어폭스도 H.264 코덱을 지원해야 한다는 여론이 일었다. 이에 대해 모질라 제품담당 마이크 셰이버는 거부 의사를 분명히 했다.

파이어폭스가 H.264 코덱을 이용하는 데 1년에 500만 달러 정도의 특허료를 지불해야 하다. 모질라 입장에서 그리 큰 돈은 아니다. 하지만 문제는 이를 통해 서비스 개발자 및 업체 모두 2011년부터 특허료를 내야 한다. 이는 선택 가능한 대안을 중요시하는 모질라의 미션과 배치되는 것이다. 코덱은 물론 웹의 영역은 아니다. 하지만 플러그인들이 오픈웹에 큰 걸림돌이 되듯, 폐쇄형 코덱은 오픈 비디오 환경에 도움이 되지 않는다고 판단한다.

이희욱 | 그럼 유튜브 HTML5 비디오 태그와 파이어폭스의 연동은 영영 안 되는 건가?

윤석찬 | 가능성은 있다. 구글이 지난해 8월, 동영상 코덱 업체 ‘온투(On2) 테크놀로지’를 인수했다. 구글이 온투 코덱을 오픈소스와 특허 무료로 공개하는 거다. 온투 코덱은 플래시와 호환된다. 이러한 계획은 이미 구글도 밝힌 바 있다. 테오라 역시 온투의 과거 버전이 오픈소스화 된 것이다. 오픈 비디오 환경은 이래저래 구글의 결정에 큰 영향을 받게 될 것이다.

주민영 | 그럼 국제적으로 HTML5가 널리 퍼지고 있는가?

윤석찬 | 사람들이 잘 모르는 게 있다. 구글 첫 화면에서 소스코드를 열어보라. HTML5 독타입이다. 예전 HTML 4.01 독타입을 쓰다가 지난해 하반기에 바뀌었다. 그렇다고 밑에 코드들이 마크업 유효성에 다 통과된 것은 아니다. 하지만 한 발걸음이 중요하다.

2005년쯤 다음이 첫 화면을 W3C 인증을 통과한 웹표준으로 바꾼 적이 있는데, 당시 많은 사람들이 첫 화면만 웹표준을 적용하면 뭐하냐는 반응들을 보였다. 회사 내부에서 선언적으로 첫화면을 바꿈으로서 모든 웹서비스에 영향을 줘, 많은 것이 바뀌었다. 구글 내부에서도 이러한 움직임이 계속될 것으로 보인다. 그런 리더십이 업계 전반에 영향을 준다.

도안구 | 국내 웹사이트들의 HTML5 도입 현황은 어떤가?

윤석찬 | 아직까지 국내에서는 HTML5에 대한 웹 개발자들의 관심이 높지는 않다. HTML5 독타입을 쓰면 표준 모드로 동작하므로 사용해도 지장은 없다. 우선 HTML5에 대한 문서자료와 HTML5갤러리나 HTML5닥터 웹사이트에서 다양한 예제를 살펴보고, 가능한 것부터 해보는 것이 좋겠다.

• HTML4와 HTML5의 차이점 : http://channy.creation.net/project/html5/html4-differences/
• HTML5 Design Principals(영문) : http://dev.w3.org/html5/html-design-principles/
• HTML5 Reference (영문) : http://dev.w3.org/html5/html-author/

이희욱 | 그럼 XHTML은 더 이상 개발 되지 않는 것인가?

윤석찬 | 그렇지 않다. 물론 XHTML 2.0 표준 개발은 완전히 멈췄다. 지난해에 그룹이 해체됐다. 하지만 XHTML의 유용성은 그대로 있기에, HTML5 문서를 XHTML로도 표현할 수 있고 이를 위한 독타입을 선언하면 그대로 XHTML 문서로 유효하다. 이를 ‘XHTML5′라고 부른다. XHTML은 여전히 HTML5 안에서 유효하다.

주민영 | HTML5가 산업에 미치는 영향은 어떨 것으로 예상하나?

윤석찬 | 가장 큰 수혜자는 기존 웹 개발자다. 요즘 모바일 애플리케이션 개발자는 중고 매킨토시를 산 뒤 코코아 개발환경을 익혀 앱스토어에 애플리케이션을 올리고, 안드로이드 애플리케이션 개발자는 자바를 배워야 한다고들 말한다. 하지만 자신이 가진 웹 기술에 조금만 더 보태면 감탄할 만 한 리치 애플리케이션을 만들 수 있다. 예컨대 ‘R그래프‘란 서비스를 보면 HTML5를 기반한 각종 비주얼 차트를 서비스 안에 넣을 수 있다.

그러니 웹 프론트엔드 개발자가 더 많은 생각을 갖고 HTML5를 적용하는 노력을 기울여야 한다. 그게 결국은 자기에게 보답으로 돌아온다. 전세계에 제공되는 범용 웹브라우저 기반으로 웹애플리케이션을 만들면 모든 개발자가 수혜를 받는다. 결국 이게 정석이다.

웹 산업에서 대형 주자가 폐쇄된 개발 환경과 플랫폼에서 비즈니스하는 것은 당연하다. 좋은 이용자경험(UX)을 주는 것은 칭찬할 만 하다. 중요한 것은, 선택 가능하고 범용적인 웹 기반 플랫폼도 제공돼야 한다. 표준은 죽기도 하고 산업에 밀리기도 한다. 100% 올바르지도 않다. 하지만 없는 것 보다는 낫다.

이희욱 | HTML5 확산을 위한 과제가 있다면?

윤석찬 | 국내에서는 일단 HTML5가 대형 포털이 적용할 만큼 매력이 있느냐의 문제가 있다. 국내에서 이용하는 대다수 웹브라우저가 아직 지원하지 않는 부분이 있기 때문이다. 파일럿 서비스나 모바일 웹 서비스를 준비하는 사람은 HTML5를 적용해보면 좋겠다. 아이폰용 웹 페이지를 만들 때 ‘video’나 ‘canvas’ 태그 혹은 오프라인 스토리지 기능을 이용하는 아이디어를 내야 한다. 천편일률적인 모바일 페이지는 식상하다. 기왕이면 모바일 웹페이지를 만들 때 ‘엣지있게’ 만들면 좋잖나.

만약 누군가 ‘canvas’ 태그를 이용해 그림을 그리고 이를 공유하는 서비스를 모바일 웹서비스로 만들었다 치자. 그는 회사에서 인정받는 사람이 될 수 있다. 그런 점들에 개발자가 좀 더 신경쓰면 좋겠다. 스스로 찾고 배워서 도전해 봤으면 한다.

이희욱 | 새롭고 흥미로운 얘기들을 많이 들었다. 아직은 어렵고 낯선 면이 많다. 리치 웹을 플러그인 없이 구현할 수 있는 기술을 내장했다는 얘기가 기억에 오래 남는다. 웹 개발자분들이 좋은 기회로 활용했으면 하는 생각이 든다. 새로운 정보들도 자주 알려주시길 기대한다.

지금은 그 가치가 예전만 못하다고는 하나, 웹에디터는 여전히 웹사이트 개발자에게 쓸모 있는 도구다.

어마야(amaya)는 웹에디터다. 말하자면 웹페이지를 만들고 다듬고 출판하는 도구다. 웹페이지를 만들고 보여주는 방법은 다양하다. 어떤 프로그래밍 언어를 쓰고, 어떤 구조를 짜느냐에 따라 웹페이지 성격은 달라진다. 제각각인 웹사이트를 다양한 운영체제나 웹브라우저에서 고루 제대로 보기란 쉽지 않다. 그래서 제창된 것이 ‘웹표준’이다.

그런 점에서 웹표준 개발·보급 기구인 월드와이드웹 컨소시엄(W3C, WWW Consortium)이 어마야를 직접 개발했다는 점은 믿음직스럽다.

1996년, W3C는 자신들이 개발한 웹표준 기술들을 최대한 반영할 수 있는 저작도구에 목말라 있었다. ‘우리가 제안한 수많은 웹표준 기술들을 통합 반영할 수 있는 모델을 어떻게 구현할 것인가.’ 이 고민에 대한 해답으로 탄생한 것이 어마야다.

단순한 HTML·CSS 에디터로 출발한 어마야는 웹기술 발전에 발맞춰 XML, XHTML, MathML, SVG 등 다양한 형식을 끌어안게 된다. 새로운 기술이 나오면 누군가 소스를 뜯어고쳐 어마야에 반영한다. 웹이 발전하는만큼 어마야도 성장한다.

어마야는 저작도구이자 배움틀이기도 하다. 어마야를 쓰면서 자연스레 웹표준을 따르는 웹페이지를 만들고 관련 기술을 배우게 된다.

어마야의 매력은 여기서 그치지 않는다. 다양한 형식의 웹문서를 동시에 편집할 수 있는 점은 특히 돋보인다. 웹브라우저 기능도 내장돼 있다. 어마야를 이용해 웹사이트를 돌아다니다 멋진 페이지나 기능을 발견하면 일단 마우스로 해당 내용을 긁어다 복사하시라. 그런 다음 작업중인 소스에 붙여넣으면 곧바로 해당 컴포넌트가 적용된다.

여럿이 작업할 때 유용한 기능들도 포함돼 있다. 다른 사람들이 작업한 내용에 주석을 달거나 특정 웹 문서에 표시를 다는 기능들이 그렇다. 등록정보 메뉴에서 이용자 화면(UI)도 입맛대로 변경할 수 있다. 윈도우, 맥OS, 유닉스 등 운영체제에 관계 없이 쓸 수 있는 점도 매력이다. 설치 파일 크기도 7MB 정도로 가볍고 부담 없다.

어마야는 영어·독일어·프랑스어·중국어 등 13개 언어로 이용할 수 있다. 한글이 제대로 지원되지 않는 점은 아쉽다. 몇몇 웹페이지에서 프레임이 깨지는 현상도 개선돼야 할 것으로 보인다.

• Amaya 10.0.1 내려받기~!