모바일 앱 토론
소개
모바일 앱과 HTML5는 현재 가장 인기 있는 기술 중 하나이며 상당히 겹치는 기술입니다. 웹 앱은 모바일 브라우저에서 실행되며 다양한 모바일 플랫폼에서 기본 앱으로 다시 패키징할 수도 있습니다. 다양한 플랫폼 지원과 모바일 브라우저의 강력한 성능을 결합한 개발자들은 HTML5를 '하나를 여러 개 실행하면 여러 개 실행'할 수 있는 솔루션으로 전환하고 있습니다. 하지만 정말로 실현 가능한가요? 네이티브로 전환해야 하는 설득력 있는 이유가 여전히 존재하며, 분명히 많은 개발자들이 네이티브로 나아가고 있습니다. 이 문서에서는 네이티브와 웹 환경의 논쟁을 다룹니다.
풍부한 기능
요점: 네이티브 광고는 더 많은 일을 할 수 있습니다.
모바일 기능은 두 가지 차원, 즉 앱 자체의 환경과 기기의 생태계에 연결되는 방식, 예를 들어 Android의 경우 위젯이나 알림과 같은 기능으로 나눌 수 있습니다. 네이티브 광고는 두 가지 측면에서 모두 뛰어납니다.
앱 경험 측면에서 네이티브 앱은 더 많은 일을 할 수 있습니다. 이를 지원하는 플랫폼에서 스와이프 이벤트를 손쉽게 제어할 수 있으며, 심지어 다중 터치도 가능합니다. 일반적으로 Android 검색 버튼 및 볼륨 제어와 같이 눌린 하드 키에서 작동할 수 있습니다. GPS, 카메라와 같은 하드웨어에도 액세스할 수 있습니다. 또한 일부 플랫폼에서는 사용자 권한을 통해 제한 없이 운영체제에 액세스할 수 있습니다. HTML5를 사용하여 배터리가 얼마나 남았는지 확인해 보세요.
하지만 인앱 경험 그 이상입니다. Android와 같은 운영체제는 앱이 사용자, 그리고 실제로 다른 앱과 상호작용할 수 있는 다양한 방법을 제공합니다. 홈페이지에 활성 위젯이 있습니다. 기기의 상태 표시줄에 표시되는 알림이 있습니다. 인텐트도 있습니다. 인텐트는 앱이 가끔 다른 앱에 필요할 수 있는 일반 서비스를 제공한다고 스스로 알릴 수 있습니다.
카운터 포인트: 네이티브 기능을 보강할 수 있지만 웹은 그 속도를 따라잡고 있습니다.
대부분의 인앱 기능은 HTML5 앱으로는 도저히 할 수 없습니다. 웹-푸 기술이 아무리 멋져도 앱이 카메라 API가 없는 샌드박스에 갇혀 있다면 당장 스냅 사진을 찍지 못할 것입니다. 다행히 샌드박스에 있지 않아도 됩니다. 웹 앱에서 사진을 촬영해야 하는 경우 사용자 인터페이스의 대부분을 제공하는 웹 뷰가 삽입된 네이티브 앱을 만들 수 있습니다. 오픈소스 PhoneGap 프레임워크가 작동하는 방식은 다음과 같습니다. 즉, 네이티브 기능을 웹 보기로 노출하여 간극을 메웁니다. 웹 뷰에서 표준 네트워킹 API를 사용하여 호출합니다. 이와 같은 하이브리드 앱을 빌드하면 위젯, 알림, 인텐트와 같은 플랫폼 기능에 연결할 수도 있습니다.
네이티브와 웹이 혼합된 하이브리드 앱을 만드는 것은 이상적인 솔루션이 아닙니다. 이는 복잡성을 더하고 모바일 브라우저에서 액세스하는 기존 웹사이트가 아닌 네이티브 앱으로 래핑된 웹 앱에만 적용됩니다. 오래 갈수록 필요하지 않을 수도 있습니다. 웹 표준은 빠르게 진화하고 있으며 최신 모바일 브라우저도 그 속도를 따라가고 있습니다. 예를 들어 최신 스마프톤에서는 오프라인 저장소, 위치정보, 캔버스 그래픽, 동영상/오디오 재생 등이 모두 광범위하게 지원됩니다. 카메라도 지원되기 시작했습니다. Android 3.1부터는 웹 표준을 사용하여 사진과 동영상을 캡처할 수 있습니다. 또한 최신 iOS 브라우저는 기기 방향 감지뿐만 아니라 양방향 스트리밍을 위한 WebSocket을 지원합니다.
전반적으로 모바일은 진화하고 있습니다. 하지만 웹 역시 빠르게 진화하고 있습니다. 데스크톱 브라우저 외에도 5개의 주요 브라우저 공급업체가 빠르게 표준을 발전시키고 기능을 추가하고 있습니다. 이러한 기능을 모바일에 포팅하는 것은 간단한 과정은 아니지만 대다수가 이미 모바일 브라우저에 지원되었습니다.
네이티브 광고는 빠르게 변화하는 목표이지만 웹에서는 이 격차를 좁히고 있습니다.
성능
요점: 네이티브 광고는 더 빠르게 실행됩니다.
네이티브 앱에는 처리할 웹 런타임 장벽이 없습니다. 하드웨어에 가깝게 실행되며 GPU 가속 및 멀티스레딩과 같은 성능 향상 기능을 활용할 수 있습니다.
카운터 포인트: 오늘날 웹 런타임은 훨씬 더 빨라졌으며 대부분의 앱은 속도가 필요하지 않습니다.
최근 몇 년 동안 웹이 빨라졌다고 말하기는 어렵습니다. Chrome과 함께 제공되는 자바스크립트 엔진인 V8은 출시 당시 웹 성능 면에서 상당한 발전이었으며, 이후 다음과 같이 더욱 빨라졌습니다.
그래픽 렌더링 엔진도 웹의 속도를 높여주었고 이제 하드웨어 가속이 발생하기 시작했습니다. 하드웨어 가속 캔버스에서 제공되는 속도 급증을 살펴보세요.
또한 새로운 Web Workers API를 사용하면 멀티스레딩이 가능하며 최신 웹 개발자는 성능이 최적화된 다양한 라이브러리와 철저한 조사를 거친 성능 최적화 기법을 호출할 수도 있습니다. 대부분은 데스크톱 웹에서 시작되었지만 여전히 모바일과 관련이 있으며 모바일에 대한 관심이 높아지고 있습니다. 예를 들어 성능 전문가인 Steve Souders는 모바일 성능 도구 전용 페이지를 만들었습니다.
데스크톱의 발전이 아직 모든 모바일 플랫폼에 이뤄진 것은 아니지만, 트렌드에 따르면 이제 가고 있는 추세입니다. 또한 대부분의 모바일 앱은 최첨단 3D 게임이 아니라 기본적으로 정보 기반(예: 뉴스, 메일, 일정, 소셜 네트워크)입니다. Gmail, Amazon, Twitter와 같은 모바일 사이트를 방문하여 모바일 웹 성능이 적절한 수준 이상임을 확인할 수 있습니다. 게임의 경우 2D 캔버스에서 기본 게임을 이미 실행할 수 있으며 WebGL이 휴대기기에 표시되기 시작했습니다. Firefox 4를 참고하세요. 널리 보급될 때까지는 WebGL 앱을 OpenGL을 활용할 수 있는 네이티브 앱(예: ImpactJS)으로 컴파일하는 프레임워크 제품군이 증가하고 있습니다.
개발자 환경
요점: 네이티브 광고는 개발이 더 쉽습니다.
네이티브 앱은 복잡한 애플리케이션 개발을 위해 설계되었으며 실적을 입증한 강력한 프로그래밍 언어 (예: 자바, Objective C, C++)를 사용합니다. API는 당면한 플랫폼을 지원하도록 처음부터 설계되었습니다. 대상 기기를 가깝게 표시하는 데스크톱 에뮬레이터에서 앱을 쉽게 디버그할 수 있습니다.
웹 개발을 특히 어렵게 만드는 것은 브라우저와 런타임의 엄청난 다양성입니다. 앱이 실행되더라도 X 기능을 사용할 수 있다는 보장은 없습니다. 사용하더라도 브라우저는 어떻게 구현할까요? 표준은 해석의 여지가 있습니다.
카운터 포인트: 웹 개발이 더 쉬운 경우가 많으며, 특히 여러 기기를 타겟팅하는 경우 더욱 그렇습니다.
먼저 핵심 기술부터 살펴보겠습니다. 사실 웹 표준은 웹이 근본적으로 앱이 아니라 문서에 관한 것이고 자바스크립트를 단 10일 만에 빌드 및 배포하는 시대에 처음 고안되었습니다. 하지만 웹 개발자들은 상상보다 훨씬 뛰어난 성능을 발휘했습니다. 웹 개발자는 확장 가능한 설계에서 파악된 패턴을 통해 좋은 부분과 나쁜 부분을 길잡는 방법을 배웠습니다. 또한 이러한 표준은 변하지 않으며 HTML5, CSS3, EcmaScript Harmony와 같은 노력이 모두 개발자 환경을 개선하고 있습니다. C++, 자바 또는 자바스크립트를 선호하는 것은 종교적 논쟁의 문제이며 기존 코드베이스에 따라서도 달라집니다. 그러나 요즘에는 JavaScript를 심각한 경쟁 상대로 포함할 수 있습니다.
브라우저/런타임 단편화의 단점은 이러한 모든 환경이 애초에 존재한다는 것입니다. 자바로 Android 앱을 개발하면 iOS를 지원하기 위해 Objective C로 완벽히 포트되어야 합니다. 웹 앱을 한 번 개발하면 Android와 iOS에서 실행됩니다. WebOS, BlackBerry, Windows Mobile은 말할 것도 없고 그것이 이론입니다. 실제로는 제대로 된 환경을 제공하려면 각 플랫폼에 맞게 조정해야 합니다 하지만 대부분의 모바일 운영체제에서는 다양한 버전과 다양한 기기가 있기 때문에 네이티브에서도 이 작업을 수행해야 합니다.
좋은 소식은 웹에서 항상 이러한 방식으로 '파편화'를 처리했으며 이를 처리하는 잘 알려진 기술이 있다는 것입니다. 가장 중요한 점은 점진적 개선 원칙에 따라 개발자는 먼저 기본 기기를 타겟팅하고 가능한 경우 플랫폼별 멋짐의 레이어를 추가해야 한다는 것입니다. 기능 감지의 핵심 원칙도 도움이 되며 최근에는 Modernizr와 같은 라이브러리 지원을 통해 반응형 웹 디자인을 지원합니다. 이러한 기법을 현명하게 사용하면 제조업체나 OS에 관계없이 구식 '피처폰'은 물론 시계, TV와 같은 폼 팩터까지 포함하여 대부분의 기기로 도달범위를 확장할 수 있습니다. Google IO 2011에서 로직과 마크업의 공통 코드베이스를 사용하여 고유한 폼 팩터 (피처폰, 스마트폰, 태블릿, 데스크톱, TV)를 타겟팅한 다중 UI 데모를 확인하세요.
스타일리시한 디자인
요점: 네이티브가 플랫폼 디자인과 분위기에 적합
모든 플랫폼을 정의하는 특징 중 하나는 디자인과 분위기입니다. 사용자는 컨트롤이 일관적으로 표시되고 동일한 방식으로 조작되기를 기대합니다. 플랫폼마다 다른 관용구가 있습니다. 예를 들어 사용자가 '길게 누르기' (요소를 몇 초간 계속 터치)를 하면 어떻게 될까요? 플랫폼에는 표준 관용구가 있으며 단일 HTML5 앱으로는 이러한 요소를 모두 충족할 수 없습니다.
또한 플랫폼의 디자인과 분위기는 플랫폼의 기본 소프트웨어 라이브러리에 의해 조정됩니다. 네이티브 소프트웨어 라이브러리는 위젯이 사용자가 기대하는 디자인과 분위기를 캡슐화합니다. 기본 도구 키트를 사용하기만 해도 '무료'의 예상된 디자인과 분위기를 많이 얻을 수 있습니다.
카운터 포인트: 웹에는 고유한 디자인과 분위기가 있으며 가장 관심 있는 플랫폼에 맞게 웹 인터페이스를 맞춤설정할 수도 있습니다.
이전 섹션에서 설명한 것처럼 웹 개발은 기본적인 '일률적인' 버전을 작성한 후 점진적으로 개선하는 것입니다. 개선사항은 일반적으로 기능을 기반으로 하지만 가장 관심 있는 플랫폼을 타겟팅하여 개선할 수도 있습니다. 이는 일종의 '브라우저 감지'입니다. 웹 커뮤니티에서는 눈살을 찌푸릴 수 있습니다. 그 이유는 주로 사용할 수 있는 브라우저가 너무 많기 때문입니다. 그러나 2~3개의 플랫폼을 우선순위가 매우 높은 것으로 보고 네이티브 대안과 경쟁하기 위해 추가 노력을 기울일 용의가 있다면 이렇게 하는 것이 좋습니다.
기준 버전에 관해서는 웹 자체의 디자인과 분위기가 있으며, 각 모바일 플랫폼에는 기본 브라우저와 웹 런타임에 의해 설정된 고유한 '웹 디자인과 분위기'가 있다고 할 수 있습니다. '웹의 디자인과 분위기'는 사용자에게 적합할 수 있으며, 실제로 사용자가 작업 중인 다른 기기의 화면은 물론 데스크톱 탐색 환경과의 일관성을 높일 수 있습니다. 또한 네이티브 디자인과 분위기를 많이 지원하지 않는 성공적인 앱도 많습니다. 이는 게임(좋아하는 모바일 게임이 모바일 OS의 디자인과 분위기를 따르는가?)에도 해당하며, 보다 전통적인 앱(예: 선택한 플랫폼에서 더 인기 있는 기본 Twitter 클라이언트 확인)에서도 마찬가지입니다. 작업 시 다양한 사용자 인터페이스 메커니즘을 확인할 수 있습니다.
발견 가능성
요점: 네이티브 앱을 더 쉽게 찾을 수 있습니다.
Android 마켓 및 Apple의 App Store와 같은 앱 배포 메커니즘은 최근 몇 년 동안 엄청난 인기를 누리면서 전체 모바일 산업의 주요 원동력이 되고 있습니다. 개발자는 누구나 마켓플레이스에 네이티브 앱을 제출할 수 있으며, 사용자는 마켓플레이스에서 탐색, 검색, 추천을 받아서 앱을 발견할 수 있습니다. 뿐만 아니라, 작업을 제대로 했다면 빛나는 평점과 댓글을 통해 사용자가 가장 중요한 설치 버튼을 누르도록 설득할 수 있습니다.
카운터 포인트: 웹 앱은 검색 가능성이 작기 때문에
웹은 가장 검색 가능성이 높은 매체입니다. Google은 이론상으로는 표준 웹사이트에 게시된 모든 앱을 비롯하여 웹에 게시된 모든 항목에 대한 고유 식별자를 가지고 있습니다. 검색엔진을 사용하면 모바일 마켓플레이스와 유사한 웹 앱 카탈로그를 비롯한 기타 웹사이트에서 해당 콘텐츠와 링크를 쉽게 찾을 수 있습니다. 누구나 이메일과 소셜 네트워크 메시지에 링크하기만 하면 웹 앱을 친구들과 공유할 수 있습니다. SMS로도 링크를 전송할 수 있으므로 모바일 사용자가 링크를 클릭하고 기기의 브라우저에서 앱을 실행할 수 있습니다.
사용자가 앱을 평가하고 댓글을 쓸 수 있는 마켓플레이스가 아직 없지만, 마켓플레이스도 변화하고 있습니다. 계속 읽어 보세요...
수익 창출
요점: 네이티브 광고는
"6살짜리가 점심시간에 앱을 만들고 1인당 3달러에 100만 부 판매". 요즘은 헤드라인이 너무 많기 때문에 크고 작은 개발자들이 수익 창출을 위해 모바일 마켓플레이스를 찾고 있는 것은 아닙니다. 모바일 플랫폼은 개발자가 앱에 직접 요금을 청구할 수 있는 여러 가지 방법을 제공합니다. 가장 간단한 것은 일회성 결제로 영원히 앱을 잠금 해제하는 것입니다. 일부 플랫폼에서는 인앱 결제 및 정기 결제 메커니즘도 제공하며, 이러한 메커니즘은 일관되고 안전한 메커니즘으로 긴밀하게 통합되어 있습니다. 이 새로운 결제 방법을 통해 개발자는 히트작 앱을 장기적인 수익원으로 전환할 수 있습니다.
앱 결제 외에도 광고 및 스폰서십과 같은 기존 웹 모델로 수익을 창출할 수 있습니다.
카운터 포인트: 웹에서 수익을 창출하는 것은 예전부터 가능했고, 기회는 늘어나고 있습니다.
수익을 창출할 기회가 충분하지 않다면 웹은 현대 산업의 엔진이 될 수 없습니다. 직접적인 '사용량에 따른 지불' 메커니즘은 아직 번성하지 못했지만 구독 기반의 'Software as a service' 솔루션이 실제로 실현 가능한 다양한 틈새가 존재합니다. Google Apps, 37Signals 제품 범위, 다양한 이메일 서비스의 프리미엄 버전이 여기에 해당합니다. 또한 웹 앱에서 수익을 올릴 수 있는 유일한 방법은 직접 결제도 아닙니다. 여기에는 온라인 광고, 제휴사 링크, 스폰서십, 다른 제품 및 서비스로의 상호 프로모션이 있습니다.
하지만 웹 개발자가 헤드라인을 읽고 결제를 부러워하는 것은 당연합니다. 네이티브 마켓에 웹 URL을 제출할 수 없습니다. 그렇다면 웹 개발자는 어떻게 해야 할까요? 타겟팅하는 각 플랫폼에 웹 뷰만 포함하는 빈 네이티브 앱을 만듭니다. 웹 뷰는 실제 앱을 삽입하는 곳입니다. 그런 다음 이러한 앱을 다양한 마켓에 제출하기만 하면 됩니다(매출이 증가하는 모습을 관찰). 오늘날 주요 마켓에는 수백, 수천 개가 아닌 수천 개의 웹 기반 앱이 있을 것입니다. 그중 일부는 교묘하게 교묘하게 흡수했기 때문에 우리는 웹 앱을 전혀 알지도 못했습니다.
단점은 각 플랫폼에 대한 크로스 컴파일이 필요하다는 것입니다. 여기서 PhoneGap과 같은 기존 프레임워크가 도움이 될 수 있습니다. 더 좋은 점은 PhoneGap Build 및 Apparatio와 같은 웹 서비스가 개발되고 있다는 것입니다. 이러한 웹사이트가 코드 저장소를 가리키도록 하면 Android 앱, iOS 앱 등이 표시되어 각 스토어에 제출할 준비가 됩니다. 따라서 머신에 네이티브 SDK를 설치할 필요가 없습니다. 코드 편집기와 웹브라우저만으로 모든 네이티브 앱을 빌드할 수 있었습니다.
마켓은 기본적으로 웹 앱을 래핑하는 오버헤드 없이 웹 앱을 직접 지원할까요? 아직 명확하지 않습니다. Google은 작년에 Chrome 웹 스토어를 도입한 것을 알고 있습니다. Chrome 웹 스토어는 데스크톱에만 적용되지만, 웹 스토어는 다른 브라우저 공급업체의 관심을 유발했으며 일부 모바일 관련 시도를 포함하여 웹 앱 카탈로그에 대한 트렌드의 전반적인 일부가 되었습니다. 웹 스토어는 초기 단계이지만 웹 스토어는 발전의 여지가 있습니다.
결론
여기서 승자를 발표하면 좋겠지만 현재 확정된 승자는 없습니다. 네이티브 앱에 가장 적합한 앱도 있고 웹에 가장 적합한 앱도 있습니다. 웹 스택은 아마도 더 많은 모멘텀을 갖고 있지만, 기능 및 실행 품질의 측면에서도 네이티브 앱 역시 빠르게 변화하고 있습니다. 그리고 대부분의 모바일 OS에서 웹 기술이 최우선으로 고려되는 경우가 아니라면 네이티브는 언제나 중요한 고려사항입니다.
이 문서에서 언급된 기법 중 하나는 하이브리드 앱이며, 이는 일부 개발자에게는 최상의 절충안일 수 있습니다. 가능한 경우 웹 뷰를, 그렇지 않은 경우 플랫폼별 네이티브 구성요소일 수 있습니다.
웹 경로를 선택할 경우 웹 표준 및 점진적 개선의 원칙에 유의해야 합니다. 웹은 수많은 기기와 운영체제를 타겟팅하는 방법을 알고 있는 기술입니다. '파편화' 또는 '다양성' 중 무엇을 선택하든 웹에서는 이를 수용하므로 개발자는 기존의 모든 기술을 활용할 수 있습니다.