웹기술 진화 앞장서는 구글 외면하는 애플

웹표준 발전이 모바일 앱을 도태시킬 것인가

웹표준 기술이 발전하면 모바일 애플리케이션(이하 '앱')은 시대에 뒤떨어진 존재가 될까?

앱의 기능을 쓰려면 '내려받아 설치한다'는 과정이 상식이었다. 이젠 예외 사례가 많아졌다. 브라우저만 켜면 메일 관리, 문서 편집, 이미지 수정, 멀티미디어 변환, 게임 실행이 된다. 발전한 웹표준 기술이 확산된 덕분이다. 모바일 쪽에서도 같은 현상을 기대할 수 있다는 관측이 나옴직하다. 다만 유력한 모바일 플랫폼 iOS를 소유한 애플은 이런 흐름에 역행하고 있기에, 판도가 어떻게 굴러갈지는 단언하기 어렵다.

IT미디어 아스테크니카는 지난달 28일자 보도를 통해 같은 화두를 던졌다. 실은 더 급진적이다. 지난 몇년간 모바일 앱의 세계는 경쟁 면에서 안드로이드와 iOS라는 양대 플랫폼에 종속되면서 고착됐는데, 최근 1~2년새 이런 상황은 확 달라졌다는 진단이다. 심지어 '오늘날 앱은 사실 꼭 필요하지 않다'고 평가한다. (☞링크)

최근 그 존재감을 확 키운 HTML5 플랫폼의 일부로써 모바일 웹앱 분야에 적용 가능한 표준이 빠르게 발전하고 있다. 주요 브라우저 개발사, 구글과 모질라가 적극 밀고 있는 이 흐름의 목표는 네이티브 앱이 할 수 있는 것이라면 어떤 일이든 웹사이트도 할 수 있도록 만드는 것으로 요약된다.

이게 현실화하면 네이티브 앱은 더 이상 필요 없어지게 된다. 웹앱의 장점은 점유 공간 최소화, 알아서 처리되는 업데이트, 모든 플랫폼 동시 지원 등이다. 이는 개발자와 사용자들에게 아이폰이나 안드로이드같은 특정 모바일 기기 플랫폼 대신 웹을 더 선호할 수 있게 만들어줄 수 있다. 모바일 네이티브 앱과 웹앱 사용 경험의 격차가 그만큼 줄었다.

일반적으로 알려진 모바일 네이티브 앱과 웹앱간의 격차를 구체적으로 짚자면 이렇다. 엄지와 검지로 터치스크린 화면의 표시 영역을 키우거나 줄이는 일명 '핀치투줌' 동작이나 나침반, 가속도계, 카메라같은 기기 내장 센서와 장치의 기능을 쓰는 동작은 네이티브 앱만 할 수 있었다.

크로스플랫폼 네이티브 모바일앱 개발툴 '퓨즈' 소개 영상의 한 장면. 아이폰과 삼성전자 안드로이드 스마트폰에 동일한 앱을 만들어 실행 중인 모습. (이미지는 본 기사와 무관함)

그런데 이 격차가 사라졌다. 모바일 브라우저가 이런 기기 내장 기능을 활용할 수 있게 됐다. 그래픽 제어, 기기 알림, 데이터 저장공간, 지불 결제, GPS, 나침반, 가속도계, 기타 센서, 멀티미디어를 다루는 인터페이스를 만들었다. 웹표준화단체 월드와이드웹컨소시엄(W3C)이 잡은 표준화 일정에 따라 유럽연합(EU)의 후원을 통해 마무리된 'HTML5앱스' 프로젝트의 결과물이다.

다만 이 모바일 웹앱 기술 확산의 걸림돌로 꼽히는 부담스러운 존재가 있다. 애플이다. 이 회사는 iOS 환경에서 돌아가는 웹앱 기술의 발전에 적대적인 태도를 취해 온 것으로 평가된다. 애플에게 iOS 플랫폼의 네이티브 앱 생태계는 막대한 수익을 보장해 주는 존재다.

지난해 1월 애플은 당시 기준 자사 네이티브 앱 장터인 '앱스토어'의 등록 개발자들이 앱과 게임을 팔아서 누적매출로 250억달러를 벌었다고 밝혔다. 개발자들이 앱스토어에서 앱을 팔거나 유료 구독 사용자를 확보하거나 앱내결제를 유도해 발생된 매출 가운데 30%는 애플이 가져간다. 애플은 아이폰 사용자들 사이에서 웹앱이 인기를 끌어 네이티브 앱의 활용이 줄어들수록 손실을 입게 된다.

그래서일까? 애플은 자사 플랫폼에 모바일 웹앱을 꽃피울 주요 웹표준을 채택하는 데 인색했다. 서비스워커, 바이브레이션API, CSS터치-액션 속성, 3가지 기술이 대표적이다.

서비스워커는 자바스크립트를 통해 오프라인 상태인 기기에서도 브라우저가 사용자 측의 이벤트에 대응해 작동할 수 있도록 해 주는 표준이다. 크롬, 오페라, 파이어폭스가 이를 부분적으로 지원하고 마이크로소프트(MS)는 엣지 브라우저에 구현을 고려 중이라 밝혔다. 애플은 자사 브라우저에 서비스워커를 지원하지도, 관련 계획을 언급하지도 않는다.

바이브레이션API는 웹앱으로도 기기의 진동 기능을 쓰게 해 주는 API다. 파이어폭스, 크롬, 오페라는 지원한다. 사파리, 인터넷익스플로러(IE), 엣지는 지원하지 않지만 MS는 엣지에 지원을 고려 중이라 밝혔다.

CSS의 터치-액션 속성은 브라우저가 사용자의 터치 입력에 어떻게 반응할지를 웹페이지에서 결정하도록 만들어 준다. 크롬과 오페라, IE와 엣지가 이를 지원한다. 파이어폭스도 지원하지만 기본 비활성화 상태다. 애플의 사파리는 지원하지 않고 있다.

사파리 대신 더 많은 웹표준 기술을 제공하는 다른 브라우저를 쓰면 어떨까? 아이폰에서는 불가능한 얘기다. 애플은 정책적으로 iOS 사용자와 개발자들이 쓸 수 있는 웹앱 기술을 통제한다. iOS 내장 브라우저인 사파리 대신 자체 구현한 렌더링 엔진 또는 자바스크립트 엔진을 쓰는 앱을 만드는 일 자체가 애플의 개발자 가이드라인에 위배된다.

모바일 웹앱을 위한 웹표준 기술 도입 측면에서 구글의 행보는 애플과 대척점에 있다. 사업자로서 입장이 다르기 때문이다. 모바일 앱 시장 분석업체 앱애니의 보고서에 따르면 지난해 3분기 iOS 앱스토어의 매출은 구글플레이보다 80% 더 많았다. 직전 분기 매출 격차 70%에서 더 벌어진 숫자였다. 즉 애플처럼 구글도 모바일 플랫폼 사용자를 위한 네이티브 앱 장터를 운영하지만, 수익 면에서 그 무게가 덜하다.

구글의 크롬 웹 플랫폼 팀을 이끄는 알렉스 코모로스케 프로덕트매니저는 구글이 모바일에서 각각의 웹 환경간 격차를 가능한한 줄이길 원한다는 입장을 밝혔다. 그에 따르면 구글이 파악한 안드로이드용 크롬 사용자들의 월간 방문 웹사이트(100종) 규모는 그들의 월간 사용 네이티브 앱(20~25종) 규모를 넘는다. 애플처럼 네이티브 앱에 집중하기보단 웹앱 사용자까지 아우르는 쪽에 무게를 두는 게 적절할 수 있다.

■구글, 모바일 웹앱 성능 개선에 주력

네이티브 앱 중심 세계관에서 웹앱의 한계로 자주 지적되는 지표가 성능이다. 네이티브 앱은 이론상 언제나 웹앱보다 빠를 수밖에 없다. 다만 이렇게 반문할 수 있다. 웹앱이 꼭 네이티브 앱만큼 빨라야 할까? 어쩌면 그저 '쓸만한 수준'이면 충분할 것이다. 필요 이상의 속도를 구현하기 위해 목을 매는 건 의미 없는 일일 수도 있다.

구글은 이런 관점에서 모바일 웹앱의 성능을 충분히 괜찮은 속도를 내는 데 초점을 맞춘 행보를 가져가고 있다. 충분히 괜찮은 속도란 다시 말해 '사용자가 속도 지연(delay)을 느끼지 못할 정도'를 가리킨다. 앞서 소개한 모바일 웹앱 관련 표준 기술 가운데 서비스워커가 등장함에따라, 충분히 괜찮은 속도를 보여 주는 웹사이트를 설계할 길도 열렸다.

구글은 그 일환으로 '레일(RAIL)'이란 약어를 제시했다. 웹앱이 충분히 괜찮은 속도를 내는지 판단하기 위한 일종의 기준 틀이다. 이는 구체적으로 ▲100밀리초(ms) 미만의 터치입력에 대한 반응시간(Reaction time) ▲프레임당 16.67ms 미만(60fps)의 동작시간(Animation time) ▲사용자가 결과를 얻기 위해 기다려야 하는 50ms 이하의 대기시간(Idle time) ▲1초 이하의 로딩시간(Load time), 4가지 지표를 포함한다.

사용자가 앱에 어떤 기능을 기대하느냐에 따라선 성능이 좀 더 중시되는 경우도 있을 수 있다. 보통 웹앱 역할은 서버 측에서 처리가 끝난 연산 결과를 전달하는 데 초점을 맞추겠지만, 사용자 기기에서의 처리 성능에 의존해야 하는 경우가 전혀 없진 않을 것이다. 이런 경우 성능을 높이기 위한 방법이 모질라 asm.js, 심디(SIMD), 웹어셈블리(WebAssembly)같은 프로그래밍 언어, 병렬연산 기법, 바이너리포맷이다.

■모질라·MS·블랙베리…남은 변수들

모바일 시장은 구글과 애플에 양분돼 있다. 연관산업 매출이나 사용자 규모 등을 따질 경우 사실상 구글의 안드로이드와 애플의 iOS를 제외하면 번듯한 경쟁자를 꼽기는 쉽지 않다. 다만 장기적 비전을 갖고 움직이는 몇몇 사업자들의 모바일 플랫폼이 살아남아 지금보다 입지를 키울 가능성을 무시할 필요는 없을 것이다.

모질라는 파이어폭스 브라우저를 개발하면서, 모바일 플랫폼인 '파이어폭스OS' 기반 스마트폰 플랫폼 확산을 통해 개방형 웹 플랫폼의 확대를 꿈꿔 왔다. 사용자에게 모바일용 파이어폭스OS 기기는 웹앱 구동에 최적화된, 그 자체가 모바일 브라우저였다. 그러나 모질라는 지난해 12월 모바일용 파이어폭스OS 개발과 공급을 중단키로 했다. 안드로이드와 iOS의 아성을 쓰러뜨리기엔 역부족이었다.

MS는 '하나의 윈도' 전략을 기치로 모바일 플랫폼에 투자를 지속해 왔다. PC와 태블릿에 윈도10으로 공동 대응하면서, 차세대 브라우저 엣지에 플러그인 기능은 배제하고 최신 웹표준을 적극 탑재하겠다고 공언했다. 아직 엣지 브라우저의 웹표준 구현 수준이 경쟁자들을 따라잡기에 충분히 빠른지는 의문이지만, 웹표준 구현 의지 자체를 의심하기에도 이르다. 윈도10은 웹앱을 아예 네이티브 윈도 앱으로 구현할 수 있게 해주는 '유니버설윈도플랫폼'도 탑재돼 있다. MS는 모바일용 윈도10 기기를 통해 유니버설윈도플랫폼의 모바일 확산에 속도를 더할 전망이다.

왕년의 비즈니스용 스마트폰 강자였던 블랙베리는 웹킷 기반의 브라우저를 탑재하고 있다. 웹킷은 오픈소스 렌더링 엔진 프로젝트지만 신기능 탑재와 개선의 열쇠는 애플이 쥐고 있는 기술이다. 블랙베리가 웹앱 사용 환경을 키울 의지를 갖고 있더라도 그걸 얼마나 실현될 수 있을지는 불투명하다. 블랙베리의 의지보다는 애플의 계획에 좌우될 공산이 크다는 얘기다. 구글도 이런 문제 때문에 과거 크롬 브라우저에 웹킷을 쓰다가, 결국 '블링크'라는 자체 엔진을 쓰면서 독자 행보를 가속해 왔다. 블랙베리는 스마트폰 사업 현황상 이런 투자를 감행하기가 쉽지 않을 듯하다.