[ICT / Articles] 웹도 네이티브앱처럼…최신 웹기술 8가지

원문 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20141018101009

웹앱은 네이티브앱을 뛰어 넘을 수 있을까? 웹진영에서는 네이티브앱을 따라잡기 위한 노력이 한창이다. 가장 큰 이슈로 지적돼 왔던 성능 문제나 하드웨어와 연계 기능 부족 문제를 극복할 묘안들이 웹 표준기술지정을 앞두고 있다.

​

웹표준화단체 월드와이드웹컨소시엄(W3C)에서 시스템애플리케이션 부분 워킹그룹 의장을 맡고 있는 이원석 삼성전자 수석은 17일 세종대학교 광개토관에서 열린 '한국웹20주년국제콘퍼런스'에서 네이티브앱과 격차를 줄이기 위해 마련된 웹 표준 기술들을 소개하는 시간을 가졌다.

​

이원석 수석은 먼저 네이티브앱과 비교해 지적되는 문제들에 대해 "웹이 처음부터 디바이스를 위한 플랫폼으로 만들어지지 않았는데 플랫폼이 되려다 보니 발생한 이슈"라고 설명했다.

​

이 수석은 웹플랫폼이 네이티브플랫폼과 동등한 수준이 되기 위해서 반드시 넘고 가야 할 이슈를 3가지로 정리했다.

​

가장 큰 이슈는 성능이다. 웹앱은 네이티브와 비교해 느리기도 하고 가끔씩 끊기는 현상도 일어난다. 사용하는 다비이스에 따라 성능이 달라지고 특히 저사양 디바이스에서 느려지는 문제들도 있다.

​

하드웨어에 접근하는 애플리케이션 프로그래밍 인터페이스(API)가 네이티브앱에 비해 적은 것도 웹앱이 해결해야 될 과제다. 라인이나 카톡 같은 메신저 앱이 처음 하는 일이 개인의 연락처정보를 읽어 친구목록에 등록하는 건데, 웹에는 아직 연락처 표준 API가 없다. 블루투스, 근거리무선통신(NFC), 미디어 데이터 엑세스 표준 API도 아직 없다. 네이티브 플랫폼에 비해 웹이 보완해야 할 점이다.

​

W3C에서 표준화 절차를 거쳐 기술이 안정적인 상태가 되더라도 각 브라우저 업체들이 지원하지 않는 경우도 많다. 표준은 W3C에서 만들지만 그 기술을 실제 브라우저에 배치하는 것은 기업들의 몫이다. 브라우저에서 지원하지 않으면 무용지물일 뿐이다.

W3C 시스템애플리케이션 WG 의장 이원석 삼성전자 수석

이 수석은 이어 네이티브와 격차를 최소화하려는 웹진영의 노력을 소개했다. 각 기술마다 "굉장히 중요한 기술이다", "웹앱을 개발하려면 꼭 알아야 하는 스펙이다"는 말도 곁들였다.

​

■ 서비스워커(Service Worker)
인터넷이 연결되지 않은 오프라인 상태에서도 웹앱이 동작할 수 있게 하기 위해 나온 스펙이다. 네트워크 연결에 의존하지 않고 사용자 PC에 저장된 데이터를 다루는 작업을 할 수 있다.

​

네이버 페이지를 예로 들면 첫 페이지만 100개 이상의 다양한 파일로 구성돼 있다고 한다. 많은 리소스를 네트워크에서 매번 로딩하려고 하면 웹앱 실행 시간이 네이티브앱 보다 느려질 수 밖에 없다.

​

서비스워커를 이용하면 리소스를 처음 한번은 로딩해야 하지만 두 번째부터는 어떤 데이터는 디바이스에 캐싱하고 어떤 데이터는 네트워크에서 매번 가져올지 통제할 수 있다. 두 번째 로딩할 때는 네이티브앱 같은 성능을 사용자에게 제공할 수 있게 된다고 이 수석은 설명했다.

​

서비스워커에서 브라우저를 벗어나도 동작할 수 있는 백그라운드 실행을 지원하기 때문에 푸시 API를 사용하는 것도 가능해 진다. 사용자가 웹툰에서 푸시를 받겠다고 웹에서 푸시가입을 하면 신간 웹툰이 나왔을 때 브라우저를 실행하지 않아서도 푸시를 받고 푸시를 누르면 웹툰 콘텐츠를 볼 수 있는 서비스가 가능해 진다.

​

이 수석은 "서비스워커가 구글 크로미움과 모질라에서 최우선순위 기능일만큼 중요하다"고 강조했다.

​

■ 매니페스트 포맷(Manifest Format)
매니페니스 포맷은 사이트에 메타데이터로 앱이름, 아이콘 링크, URL 등을 넣어주는 기능이다. 애플이 메타태그로 지원했던 기능인데 W3C에서 표준화했다. 이 기능을 이용하면 네이버 사이트에 들어갔을 때 "네이버를 홈화면에 설치하시겠습니까?"란 질문이 나오게 하고 홈화면에 바로가기 아이콘을 설치할 수 있게 된다.

​

이 수석은 "네이티브 플랫폼 사용자경험(UX)에 사람들이 익숙해졌기 때문에 웹플랫폼에서도 비슷한 기능을 지원하면 편하게 느낄 수 있다"고 설명했다.

​

또 “서비스워커와 연계하면 특정 사이트에 들어가지 않아도 매니페스트 포맷을 가지고 있는 링크를 눌렀을 때 홈화면에 바로가기를 만들면서 캐싱을 함께 떨어뜨려 줄 수 있기 때문에 로딩 속도도 빨라진다”고 덧붙였다.

​

■ 푸시(Push) API
푸시 지원이 안되기 때문에 웹앱으로 만들고 싶어도 네이티브앱을 만드는 경우가 있었는데 이제는 웹에서도 얼마든지 푸시 기능을 쓸 수 있게 됐다.

​

이 수석은 웹앱에서 푸시 API를 이용할 수 있게 되면서 소규모 콘텐츠 프로바이더(CP)에게 상당한 메리트가 된다고 강조했다. 푸시 기능은 사용자들에게 마케팅 메시지를 보내 서비스로 유입을 유도하는 중요한 수단이다. 이전에는 푸시를 보내려면 제작비가 비싼 네이티브앱을 만들어야 했지만 이제는 웹사이트만 만들어도 푸시를 보낼 수 있게 됐다는 설명이다.

​

■ Picture 엘리먼트와 srcset 애트리뷰트
해상도가 다양한 디바이스에 쉽게 대응할 수 있게 해주는 반응형웹 기술이다. 반응형웹에 많이 쓰이고 있는 CSS 미디어쿼리는 이미지를 다양한 크기 디바이스에 맞춰 적절하게 보여주기가 어렵다는 문제가 있다. Picture 엘리먼트와 srcset 애트리뷰트를 이용하면 디바이스 크기에 따라 이미지를 적절하게 맞춰 줄 수 있다.

이 수석은 "모바일에서 엠닷(m.)으로 시작하는 사이트가 많이 생겼는데 이렇게 리다이렉션을 하면 퍼포먼스가 느려진다"며 “어떤 디바이스에서 들어와도 적절한 UI와 이미지를 한 페이지에서 다 처리해주는 반응형웹 방식 성능이 더 좋다"고 설명했다.

​

그는 또 "지금처럼 멀티플 디바이스가 등장하는 상황에서 Picture 엘리먼트와 srcset 애트리뷰트는 굉장히 중요한 스펙"이라고 강조했다.

​

■ 웹RTC(WebRTC)
웹RTC는 브라우저에서 별도 프로그램 설치가 당연시되는 화상회의나 영상대화 서비스를 '플러그인' 없이 구현해줄 수 있는 웹 기술이다. 행아웃 같은 앱을 브라우저에서 만들 수 있다.

​

■ 웹 컴포넌트(Web Component)
웹 컴포넌트는 이미 만들어진 라이브러리를 재사용하자는 개념이다. 달력이나 지도 사이트를 가져와서 본인이 만든 메뉴를 넣어 UI를 만들고자 할 때 기존에 웹 컴포넌트로 만들어진 라이브러리가 있으면 커스터마이징 해서 쓸 수 있고 퍼포먼스도 최적화 할 수 있다고 이 수석은 설명했다.

​

구글은 웹컴포넌트를 기반으로 폴리머(Polymer)라는 기술을 만들고 있다. 이 수석은 "폴리머가 성공한다면 웹앱을 개발하는 방식, 여러분들이 코딩하는 방식이 많이 바뀔 것이기 때문에 관심 있게 지켜봐야 할 중요한 기술"이라고 강조했다.

​

■ ES6 프로미스(Promise)
ES6에서 표준화 진행중인 프로미스도 중요하다. 비동기 코드 실행을 추상화한 오프젝트로 기존 콜백의 다중 중첩 복잡도 문제를 해결해 줄 수 있다. 또 비동기 API 프로그래밍을 동기 API 프로그래밍 스타일로 작성할 수 있게 해 코드 가독성윽을극대화했다.

​

■ 이 밖에도..
프리빌리지드 API(Privileged APIs)라고 해서 하드웨워와 긴밀하게 연동할 수 있는 다양한 API가 만들어지고 있다. 알람 API, 연락처 API, 레거시 서버와 커뮤니케이션 할 수 있는 인터페이스인 TCP/UDP 소켓도 만들어지고 있다. 블루투스 API, 미디어 콘텐츠 엑세스 API도 정의하려고 진행하고 있다.

​

이 수석은 웹기술 자체가 가지는 장점에 네이티브앱을 따라잡는 기술이 보완되면 웹앱이 크게 성장할 수 있을 것으로 내다봤다.

​

"설치할 필요가 없다는 점은 네이티브앱에 비해 웹이 좋다. 또 업그레이드할 필요 없이 항상 최신버전을 유지한다는 것도 장점이다. 링크만 보내면 같은 게임을 친구들과 함께 할 수도 있다. 서비스워커랑 이런 장점이 합쳐지면 네이티브앱 같은 사용자 경험을 주면서 설치나 업그레이드는 필요 없고 링크만 던지면 친구와함께 쓸 수 있게 된다"고 이 수석은 설명했다.