모바일웹 플랫폼과 Device API 표준 이강찬 TTA 유비쿼터스 웹 응용 실무반(WG6052)의장, ETRI 선임연구원 1. 머리말 현재 소개되어 이용되는 모바일 플랫폼은 아이폰, 윈 도 모바일, 안드로이드, 심비안, 모조, 리모, 팜 WebOS, 바다 등이 있으며, 플랫폼별로 버전을 고려하면 그 수 를 열거하기 힘들 정도로 다양하게 이용되고 있다. 이 러한 상황에서 개발자들이 응용 개발을 위해서는 플랫 폼을 선택할 수 밖에 없는 상황이며, 다양한 플랫폼을 모두 지원하는 것은 현실적으로 불가능 한 것에 가깝 다고 볼 수 있다. 이렇게 다양한 플랫폼을 지원하기 위해서는 플랫폼 자체를 통합하거나, 모든 모바일 플랫폼에서 동작할 수 있도록 통일된 API를 사용하는 것이다. 그러나, 모 바일 디바이스에 종속적인 부분을 API로 해결하는 것 은 부분적으로는 통일된 API를 사용하게 할 수는 있으 나 모든 플랫폼에서 이를 수용하는 것도 큰 문제점 중 의 하나이다. 2010년 2월, MWC (Mobile World Congress) 2010에서 이러한 문 제점을 해결하고자 모바일웹 기반의 응용 개발 환경 표준화를 위해 WAC (Wholesale App Community)1) 신설을 결의했고, 3월 국내에서도 SK텔레콤이 T스토어를, KT는 쇼스토 어를 각자 운영함에 따라 국내 개발자들이 다른 표준 에 맞춰 애플리케이션을 개발해야 했던 불편함을 해소 하기 위해 통합 앱스토어를 개발하겠다고 이동통신 3 사 및 관련 기관이 합의를 발표했다. 이러한 일련의 상황에 대하여 실효성에 대한 많은 의견들이 나타나고 있으나, 결과를 예측하기 이전에 모바일 플랫폼의 현실적인 문제점을 모바일웹을 통해 다른 플랫폼 환경에서 보다 효과적인 응용 개발 및 사 용자에게 응용 서비스를 쉽게 제공하려 한다는 점에서 매우 중요하고, 늦은 감이 없지는 않지만 조속히 기술 적인 통합 및 표준화가 이루어져야 하는 부분이라 생 각된다. 기술적으로는 웹 콘텐츠를 모바일과 같은 다양한 단 말 환경에서 단순한 브라우징만 하는 방식에서 탈피 해, 네이티브 애플리케이션을 개발하는데 웹 기능을 이용하기 위해서는 모바일 단말 쪽의 API가 표준화되 어야만 가능하다. 1) WAC는 2010년 2월 전 세계 25개 이통사 제조사가 다양한 모바일 플랫폼 환경에 효율적인 응용개발 및 유통을 지원하기 위해 결성한 조직 44
Special Theme _ 모바일웹과 스마트폰 본 고에서는 모바일웹에서의 단말 API인 W3C DAP (Device API and Policy) 의 표준 개발 현황에 대해서 살펴보고 관 련하여 개발 중인 사례를 통하여 이해를 돕고자 한다. 2. 웹 애플리케이션과 네이티브 애플리케이션 디바이스 API를 쉽게 이해하기 위해서는 모바일 플 랫폼에서 애플리케이션 개발 형태를 먼저 이해해야 한 다. [그림 1]에서 보는 바와 같이 기본적으로 일반적인 네이티브 애플리케이션은 디바이스의 네이티브 API를 이용해 애플리케이션을 개발하게 된다. 이러한 네이티 브 애플리케이션은 빠른 속도, 단말의 기능을 완전히 사용할 수 있는 장점이 있으나 앞서 언급한 다양한 플 랫폼의 문제점이라는 것이 만약 플랫폼이 상이하게 되 면 네이티브 API의 형태가 달라지기 때문에 애플리케 이션도 다른 방식으로 개발할 수 밖에 없다. 웹 애플리케이션은 네이티브 API를 이용하는 표준화 된 디바이스 API를 사용하는 방식이다. 이는 브라우저 에 디바이스 API가 내장되어야 하며, 이를 통하여 브라 우저는 디바이스의 기능을 이용하게 된다. 웹 애플리 케이션은 디바이스 API를 지원하는 브라우저만 있으면 애플리케이션이 구동 가능하고, 인터넷 상에 있는 다 양한 서비스와 매시업이 가능하며, 많은 웹 개발자들 은 디바이스의 네이티브 API를 알 필요 없이 자바 스크 립트로 되어 있는 디바이스 API만 알면 프로그램이 가 능한 장점들이 있으나, 고성능 처리를 요구하는 게임 이나 섬세한 UI를 요구하는 응용에서는 제약이 있다. 또한, 하이브리드 애플리케이션은 웹 런타임 엔진을 이용해 네이티브 UI 형태로 웹 애플리케이션을 사용할 수 있도록 하는 방식도 이용되고 있다. 3. W3C DAP 표준 개발 현황 W3C에서 Device API에 대한 표준화를 요구는 다양 한 단말에 위젯을 표준화하는데 필요한 단일화된 단 말 API가 필요하기 때문이었다. 이러한 유사한 시도는 여러 곳에서 시도되었다. 특히, 통신회사들은 OMTP 과 JIL 등과 같이 자바 스크립트를 확장하거나 단말 플 랫폼에 자바 스크립트 확장이나 미들웨어 형태로 디 바이스 API를 제공하는 시도를 하고 있고, 솔루션 업 체들은 각 플랫폼에 최적화된 크로스 플랫폼 솔루션 (PhoneGap, Titanium, Rhodes 등)을 시도하고 있다. 또 한, 노키아와 팜 같은 제조사들은 단말의 운영체제 안 에 디바이스 API에 대한 기능을 포함시키는 형태로 제 공하고 있다. 결국 여러 개의 단말 플랫폼이 있는 상황에서 어떻 게 편리하고 효과적으로 애플리케이션을 개발할 것인 지, 즉, 응용 및 서비스 개발 비용을 줄이면서 동시에 Special Report 3 Browser Web Runtime Engine Device Device Device API Device API Native API Native API [그림 1] 네이티브 애플리케이션과 웹 애플리케이션 개념도 TTA Journal No.128 45
개방형 마켓 플레이스 형태로 외부 개발자들이 쉽게 모바일 플랫폼에서 애플리케이션을 개발할 수 있는 장 점이 생기기 때문에 이러한 시도가 지속되고 있다. 이러한 시대적 요구 때문에, W3C DAP 워킹그룹에는 이동통신사, 브라우저 벤더, 글로벌 포털, 제조업체 등 20여 개의 기관에서 60여 명이 활발히 참여하고 있고, 2010년 3월 현재 <표 1>의 표준이 개발 중에 있다. 이밖에도 DAP에서는 다음과 같은 요구사항과 보안 관련 요구사항과 기술 자료를 개발 중에 있다. Device APIs Requirements: 일전적 요구사항, 애플리 케이션 설정, 일정, 카메라, 로그, 연락처, 파일 시스 템, 갤러리, 시스템 정보, 업무 등에 대한 요구사항과 유즈케이스 Device API Policy Requirements: 디바이스 API의 보 안 정책에 대한 요구사항 Device API Design Patterns: 디바이스 API를 설계하 는 데 필요한 WebIDL, 인터페이스, 속성, 메소드 등 의 명명에 대한 규칙 Device Interface : DAP 워킹그룹에서 정의하는 API 의 공통 API 명세 또한, DAP의 API 스타일은 통상적인 API의 함수 호 출 방식이 아니라 [그림 2]와 같이 웹에 있는 자원을 REST 방식으로 접근하고 있다. 따라서 디바이스의 로 컬 자원뿐만 아니라 웹에 있는 자원까지도 모두 디바 Calendar Contact Capture Messaging <표 1> W3C DAP 표준개발 동향 API 이름 설명(이슈사항은 2010년 3월 기준) 개발주체 System Information File Writer Gallery Powerbox 디바이스의 일정 정보에 접근하기 위한 API 이슈사항 : 일정 정보의 보안 이슈, 음력 및 국제화 지원(현재는 ical, vcalendar 지원) 디바이스의 주소록 정보에 접근하기 위한 API 이슈사항 : 멀티 디바이스 주소록, SIM 주소록 및 인터넷 주소록(페이스북, 트위터)와의 연동 디바이스 내 오디오, 이미지, 비디오 기능에 접근하기 위한 API 이슈사항 : Geolocation API와의 연동 디바이스의 SMS, MMS, email 기능에 접근하기 위한 API 이슈사항 : MMS 메시징 생성 방식, 메시징 로그 접근 방식 디바이스의 기본적인 속성에 대한 API (배터리 용량, 네트워크 대역폭, CPU부하, 저장 용량, 입/출력 기기) 이슈사항 : DCO와의 연동, 센서 기능 추가 디바이스에 파일을 쓰기 위한 API 이슈사항 : 스트링으로부터 BLOB 생성 및 파일 쓰기에 대한 이벤트 모델 디바이스 내에 있는 미디어 갤러리(media gallery)에 접근하는 API 이슈사항 : 갤러리 메타데이터 속성, 갤러리 검색 메소드 이름 사용자 개인 리소스를 브라우저에서 요청하기 위한 웹 기반 전달 방식 이슈사항 : 유사 방식(Open Provider)와의 모델 차이 Launcher 디바이스에 인스톨된 애플리케이션(Native )에 접근하기 위한 API ETRI 프랑스 텔레콤, RIM 프랑스 텔레콤 인텔, 노키아, 도이치 텔레콤 텔레포니카, 오페라, 에릭슨 인텔, 오페라 Tasks API 디바이스 내에 저장된 업무(task) 관리(업무 추가, 삭제, 수정)를 위한 API - Configuration 웹 애플리케이션의 설정(사용자의 선호도나 환경설정)을 변경하기 위한 API - User Interaction 서로 다른 플랫폼에서도 사용자가 웹 애플리케이션을 더욱 수월하게 조작할 수 있도록 하는 API의 집합 Communication Log 디바이스 내 전화, 문자의 기록(log)의 내용물 및 메타데이터에 접근하기 위한 API - 구글 ETRI 구글 - 46
Special Theme _ 모바일웹과 스마트폰 Example function showmap (position) { // show a map centred at (position.coords.latitude, position.coords.longitude). } // One-shot position request. $.getjson( service://w3c/geo/get-location, showmap); [그림 2] REST 방식의 DAP 메소드 호출 Special Report 3 APPLICATIONS Native 3 rd Party Developer s Hybrid GeoLocation Accelermeter Camera Vibration HTML+JAVA Script APPLCATION FRAMEWORK HyWAIR Native APLs SMS API Sounds Orientaion Gesture/multi Function Activity Window Content Providers View System SQLite Wrapper File Sytem I/O Contact API Network Package Telephony Resource Location Notification Telephone API Manetometer Storage Personal Information LIBRAIES Graphics Media Framework SSL & Webkit ANDROID RUNTIME Core Libraries FTP Log (SMS, Telephone) Invocation Settings libc SOlite Surface Dalvik VM Device Socket XMPP API Bluetooth Properties UNUX KERNEL Hardware Drivers Power Mamagement Process Management Memory Management Maps Implemented Future Plan [그림 3] HyWAI 구성도 및 지원 Device API 이스 API의 이용 대상으로 고려할 수 있게 확장성 있도 록 설계되고 있다. 현재 디바이스 API의 표준 개발은 2009년 11월에 첫 대면 회의 이후, 5개월이 채 지나지 않았음에도 불구하 고 3~4종의 API는 3월 말 WG 최종 버전을 앞두고 있 다. 2010년 하반기에 권고안(Recommendation) 트랙에 들어갈 수 있으며, 다음 대면 회의에서는 권고안 이전 의 워킹그룹 내의 API 프리 테스트(pre-test)에 대해서 논의할 예정이다. 4. 디바이스 API 구현 사례 디바이스 API의 구현 형태는 웹브라우저 기반과 웹 런타임 엔진 기반으로 구분될 수 있다. 브라우저 방식으 로는 모질라에서 기능을 선보이고 있으며, 웹 런타임 엔 진은 많은 곳에서 추진 중에 있으나 본 고에서는 ETRI의 HyWAI 를 통하여 구현 사례를 살펴보고자 한다. 4.1 웹 런타임 엔진 방식 : HyWAI HyWAI (Hybrid Web Interface) API는 디바이스의 API와 웹 표준으로 작성된 애플리케이션 사이에 인터페이스 를 제공하여 사용자가 좀 더 편리하고 빠른 속도로 애 플리케이션을 제작할 수 있도록 하였다. TTA Journal No.128 47
HyWAI 는 크로스 플랫폼 웹 기반으로, GPS, 파일, 카메라, 개인 정보(주소록, 일정 등), SMS, 사운드, 진 동, 각종 센서 등 각종 자원에 대한 자바스크립트 API 제공하며, 자바스크립트 API 등록 및 관리 모듈인 디 바이스 API 핸들러 및 자원 추상 계층을 이용하여 각 모바일 플랫폼의 네이티브 API 기반으로 디바이스 API 기능 구현이 가능하다. 현재 W3C DAP 표준 중에 Gallery와 Launcher는 HyWAI 의 구현을 따 라 표준이 개발되고 있으며, 나머지 표준도 HyWAI 에 서 모두 수용 할 예정이다. HyWAI 는 W3C의 DAP WG 차기 회의에 프리 테스트에 API 상호운용성을 시험할 예정이다. 4.2 브라우저 방식: 모질라 브라우저 현재 웹브라우저 기반으로는 모질라에서 File API 2) 와 Contact API 3) 에 대해서 모질라 3.5 버전 이상을 대상으 [그림 4] 모질라 File API 데모 실행 화면 [그림 5] 모질라 Contact API 데모 화면(연락처 설정) [그림 6] 모질라 Contact API 데모 실행 화면(보안 설정) 2) http://demos.hacks.mozilla.org/openweb/fileapi/ 3) http://mozillalabs.com/conceptseries/identity/contacts/ 48
Special Theme _ 모바일웹과 스마트폰 로 일부 구현을 선보이고 있다. File API는 모질라 브라우저에 이미지 파일을 드래깅 하여 올려놓으면 해당 이미지를 브라우저 안에 내장 시키고, 이미지 내의 EXIF 정보를 분석하여 지도와 매시업하여 이미지의 위치 정보를 보여줌 Contact API는 네이티브 주소록, 구글/트위터 등의 인터넷의 연락처 정보를 브라우저 내에서 저장하고, 중복을 제거하고, input 태그에 email 등에 대해서 자 동 입력할 수 있도록 하는 형태. 또한, 브라우저 내에 서 연락처 정보를 사용하기 위한 보안 모듈 제공 5. 맺음말 기존의 모바일 애플리케이션 제공 방식과는 달리 향 후의 모바일 단말의 경쟁력은 웹 환경의 채택에 따라 크게 좌우되기 때문에 브라우저 벤더와 포털 회사에서 보다 공격적으로 디바이스 API에 대한 요구사항을 제 시하고 있으며, 개방형 플랫폼을 통한 외부 개발자의 서비스 및 응용 개발을 촉진하여 관련 시장을 확대할 수 있기 때문에 제조사와 이통사가 적극적으로 대응하 고 있는 상황이다. 또한 OMTP의 BONDI에서도 관련 명세/가이드라인 과 SDK를 제공하고 있지만, 웹 시장에서의 표준에 자 신의 요구사항을 반영하기 위해 매우 적극적으로 DAP 에 참여하고 있으며, 이는 웹에서의 표준화의 중요성 을 반증하는 것으로 사료된다. W3C DAP는 그 목표에서 나타나는 바와 같이 웹에서 단말 API를 표준화하는 측면에서 그 기대가 매우 크다 고 볼 수 있다. 그러나, 디바이스 API는 시장 출시 시간 단축(time to market)이 매우 중요한 분야이고, 많은 업 체가 참여하고 있기 때문에 조속한 표준 개발과 공감 대 형성이라는 두 마리 토끼를 모두 쫓아야 하는 부담 을 안고 있으며, 국제화 DAP (internationalization DAP) 에 대한 고 려도 필요한 상황이다. 현재 W3C DAP 워킹그룹에는 국내에서 ETRI, SKT, 삼성전자가 참여하고 있고, 국내에 모바일웹2.0포럼에 서도 디바이스 API 특별(Ad-hoc)그룹이 활동하고 있는 만큼 이에 대한 국내에서의 공감대 기반으로 국내 표 준 개발 및 DAP 워킹그룹과의 협력을 통한 표준 개발 이 필요한 상황이다. 또한, 국가적인 차원에서의 모바 일 플랫폼에서의 디바이스 API에 대한 표준 로드맵 및 단말-콘텐츠-서비스-이용자를 고려한 생태계적 접근 으로의 국내 산업전략을 고려해야 할 것으로 사료된다. [참고문헌] [1] 이강찬, W3C DAP(Device API and Policy) 표준화 동향, IT Standard Weekly, 2009. 12. [2] W3C Device API and Policy WG, http://www.w3.org/2009/ dap/. [3] Security for Access to Device APIs from the Web - W3C Workshop, http://www.w3.org/2008/security-ws/. Special Report 3 TTA Journal No.128 49