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