모바일 앱 논쟁
소개
모바일 앱과 HTML5는 현재 가장 인기 있는 기술이며, 이 두 기술은 많은 부분에서 겹칩니다. 웹 앱은 모바일 브라우저에서 실행되며 다양한 모바일 플랫폼에서 네이티브 앱으로 다시 패키징할 수도 있습니다. 지원해야 하는 플랫폼이 다양한 데다 모바일 브라우저의 성능이 워낙 뛰어나 개발자들은 HTML5를 '한 번 작성하면 여러 곳에서 실행'할 수 있는 솔루션으로 여기고 있습니다. 하지만 정말로 실현 가능할까요? 네이티브로 전환해야 하는 설득력 있는 이유가 여전히 있으며, 실제로 많은 개발자가 이 경로를 따르고 있습니다. 이 도움말은 네이티브와 웹의 장단점을 비교합니다.
기능 풍부도
포인트: 네이티브는 더 많은 작업을 할 수 있음
모바일 기능은 앱 자체의 환경과 기기의 생태계에 연결되는 방식(예: Android의 경우 위젯 및 알림과 같은 기능)이라는 두 가지 차원으로 나눌 수 있습니다. 네이티브는 두 가지 측면 모두에서 뛰어납니다.
앱 환경 측면에서 네이티브 앱은 더 많은 작업을 할 수 있습니다. 이러한 플랫폼에서 스와이프 이벤트, 멀티터치 이벤트 등을 쉽게 가져올 수 있습니다. 일반적으로 Android의 검색 버튼과 볼륨 컨트롤과 같은 하드 키가 눌러지는 경우에 작동할 수 있습니다. GPS, 카메라와 같은 하드웨어에도 액세스할 수 있습니다. 또한 사용자의 허가를 받아 일부 플랫폼에서는 운영체제에 대한 무제한 액세스를 제공합니다. HTML5로 배터리 잔량을 감지해 보세요.
하지만 인앱 환경이 전부가 아닙니다. Android와 같은 운영체제는 앱이 사용자와 상호작용할 수 있는 다양한 방법을 제공하며, 실제로 다른 앱과도 상호작용할 수 있습니다. 홈페이지에 활성 위젯이 있습니다. 기기의 상태 표시줄에 표시되는 알림이 있습니다. 또한 인텐트가 있어 앱이 다른 앱이 가끔 필요로 할 수 있는 일반 서비스를 제공한다고 알릴 수 있습니다.
반대 의견: 네이티브 기능은 보강할 수 있으며 웹은 어차피 따라잡고 있습니다.
HTML5 앱에서는 많은 인앱 기능을 사용할 수 없습니다. 웹 기술이 아무리 뛰어나도 카메라 API가 없는 샌드박스에 앱이 갇혀 있다면 사진을 찍을 수 없습니다. 다행히도 이 샌드박스에 있을 필요는 없습니다. 웹 앱에서 사진을 찍어야 하는 경우 사용자 인터페이스의 대부분을 제공하는 삽입된 웹 뷰가 있는 네이티브 앱을 만들면 됩니다. 오픈소스 PhoneGap 프레임워크는 네이티브 기능을 웹 서비스로 노출하여 격차를 해소합니다. 웹 서비스는 표준 네트워킹 API를 사용하여 웹 뷰를 호출합니다. 이와 같은 하이브리드 앱을 빌드할 때 위젯, 알림, 인텐트와 같은 플랫폼 기능에 연결할 수도 있습니다.
하이브리드(네이티브 + 웹) 앱을 만드는 것은 이상적인 솔루션이 아닙니다. 복잡성이 추가되며 모바일 브라우저에서 액세스하는 기존 웹사이트가 아닌 네이티브 앱으로 래핑된 웹 앱에만 적용됩니다. 하지만 오래 걸리지는 않을 것입니다. 웹 표준은 빠르게 발전하고 있으며 최신 모바일 브라우저도 이에 발맞추고 있습니다. 오프라인 저장소, 위치정보, 캔버스 그래픽, 동영상/오디오 재생은 최신 스마트폰에서 널리 지원됩니다. 카메라까지 지원되기 시작했습니다. Android 3.1부터 웹 표준을 사용하여 사진과 동영상을 캡처할 수 있습니다. 최신 iOS 브라우저는 양방향 스트리밍을 위한 WebSocket과 기기 방향 감지를 지원합니다.
전반적으로 모바일은 진화하고 있습니다. 하지만 웹도 빠르게 진화하고 있습니다. 데스크톱 브라우저만 해도 표준을 발전시키고 기능을 빠른 속도로 추가하는 주요 브라우저 공급업체가 5곳이나 있습니다. 이러한 기능을 모바일로 포팅하는 것이 간단한 프로세스는 아니지만 이미 많은 기능이 모바일 브라우저에 적용되었습니다.
네이티브는 빠르게 움직이는 타겟이지만 웹이 그 격차를 좁히고 있습니다.
성능
장점: 네이티브가 더 빠르게 실행됨
네이티브 앱은 웹 런타임 장벽을 처리하지 않아도 됩니다. 이러한 앱은 하드웨어에 가까운 곳에서 실행되며 GPU 가속 및 멀티 스레딩과 같은 성능 부스터를 활용할 수 있습니다.
반대 의견: 오늘날 웹 런타임은 훨씬 빠르며 대부분의 앱에는 속도가 필요하지 않습니다.
최근 몇 년간 웹이 더 빨라졌다고 말하는 것은 과소평가입니다. Chrome과 함께 제공되는 JavaScript 엔진인 V8은 출시 당시 웹 성능에 있어 획기적인 발전이었으며 그 이후로도 계속해서 속도가 빨라지고 있습니다.
그래픽 렌더링 엔진도 웹 속도를 높였으며 이제 하드웨어 가속이 시작되고 있습니다. 하드웨어 가속 캔버스에서 제공하는 속도 제한을 살펴보세요.
또한 새로운 Web Workers API를 통해 멀티스레딩이 가능해졌으며, 최신 웹 개발자는 다양한 성능 최적화 라이브러리와 잘 연구된 성능 최적화 기술을 호출할 수도 있습니다. 이러한 도구는 대부분 데스크톱 웹에서 시작되었지만 모바일과도 관련이 있으며 모바일에 대한 관심이 높아지고 있습니다. 예를 들어 성능 전문가인 Steve Souders는 모바일 성능 도구 전용 페이지를 보유하고 있습니다.
아직 모든 모바일 플랫폼에 데스크톱의 발전이 적용되지는 않았지만, 추세에 따르면 곧 적용될 것으로 보입니다. 또한 대부분의 모바일 앱은 최첨단 3D 게임이 아니라 기본적으로 정보 기반(뉴스, 메일, 시간표, 소셜 네트워크 등)이라는 점도 중요합니다. Gmail, Amazon, Twitter와 같은 모바일 사이트를 방문하면 모바일 웹 성능이 충분하다는 것을 확인할 수 있습니다. 게임의 경우 2D 캔버스로 기본적인 게임은 이미 가능하며 모바일에서 WebGL이 등장하기 시작했습니다(Firefox 4 참고). 이러한 기술이 널리 퍼지기 전까지는 OpenGL을 활용할 수 있는 네이티브 앱으로 WebGL 앱을 컴파일하는 프레임워크(예: 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의 마켓과 Apple의 App Store와 같은 앱 배포 메커니즘은 최근 몇 년간 압도적인 인기를 얻었으며 전체 모바일 업계의 주요 동력이 되고 있습니다. 모든 개발자는 네이티브 앱을 마켓에 제출할 수 있으며, 사용자는 탐색, 검색, 추천을 통해 앱을 찾을 수 있습니다. 뿐만 아니라, 앱을 제대로 만들었다면 빛나는 평점과 댓글이 사용자에게 매우 중요한 설치 버튼을 누르도록 유도할 것입니다.
반론: 웹 앱이 더 쉽게 검색됨
웹은 지금까지 만들어진 매체 중 가장 검색이 용이한 매체라고 할 수 있습니다. 겸손한 URL에는 웹에 게시된 모든 항목(표준 웹사이트에 게시된 앱 포함)의 고유 식별자가 있습니다(이론적으로는). 검색엔진을 사용하면 이러한 콘텐츠를 쉽게 찾을 수 있으며, 모바일 마켓과 유사한 웹 앱 카탈로그를 비롯한 다른 웹사이트에서 이러한 콘텐츠로 연결할 수 있습니다. 실제로 누구나 이메일과 소셜 네트워크 메시지에서 웹 앱에 링크하기만 하면 친구와 웹 앱을 공유할 수 있습니다. 링크는 SMS로도 전송할 수 있으며, 모바일 사용자는 링크를 클릭하여 기기의 브라우저에서 앱을 실행할 수 있습니다.
사용자가 앱을 평가하고 댓글을 달 수 있는 마켓은 아직 없지만 이 부분도 변화하고 있습니다. 계속 읽어 보세요.
수익 창출
포인트: 네이티브 광고로 수익을 창출할 수 있음
'6세 어린이가 점심시간에 앱을 만들어 3달러에 수많은 사본을 판매' 요즘 이 헤드라인을 많이 보셨을 텐데요, 크고 작은 개발자들이 모바일 마켓에서 수익을 창출하려고 하는 것도 당연합니다. 모바일 플랫폼은 개발자가 앱에 대해 직접 요금을 청구할 수 있는 여러 방법을 제공합니다. 가장 간단한 방법은 앱을 영구적으로 잠금 해제하는 일회성 결제입니다. 일부 플랫폼에서는 인앱 결제 및 정기 결제 메커니즘도 제공되며, 이러한 메커니즘은 일관되고 안전한 메커니즘에 긴밀하게 통합되어 있습니다. 이러한 새로운 결제 수단을 통해 개발자는 히트 앱을 장기적인 수익원으로 전환할 수 있습니다.
앱 결제 외에도 광고 및 스폰서십과 같은 기존 웹 모델로 수익을 창출할 수 있습니다.
반박: 웹에서 수익을 창출하는 것은 항상 가능했으며 기회는 계속 늘어나고 있습니다.
웹에서 충분한 수익을 창출할 수 없다면 웹은 현대 산업의 엔진이 될 수 없습니다. 직접적인 '사용량 기반 요금제' 메커니즘은 아직 활성화되지 않았지만, 구독 기반 '서비스로서의 소프트웨어' 솔루션이 실제로 실행 가능한 다양한 틈새시장이 있습니다. 예로는 Google Apps, 37Signals의 다양한 제품, 다양한 이메일 서비스의 프리미엄 버전이 있습니다. 또한 직접 결제는 웹 앱에서 수익을 창출하는 유일한 방법이 아닙니다. 온라인 광고, 제휴 링크, 스폰서십, 다른 제품 및 서비스와의 교차 프로모션 등이 있습니다.
하지만 웹 개발자가 헤드라인을 읽고 약간의 보상 부러움을 느끼는 것은 지극히 합리적입니다. 네이티브 마켓에 웹 URL을 제출할 수 없는데 웹 개발자는 어떻게 해야 하나요? 각 타겟 플랫폼에 대해 웹 뷰만 포함하는 빈 네이티브 앱을 만듭니다. 웹 뷰는 실제 앱을 삽입하는 곳입니다. 그런 다음 이러한 앱을 다양한 마켓에 제출하면 됩니다(수익이 발생하기를 바라면서). 오늘날 주요 마켓에는 웹 기반 앱이 수백 개, 아니 수천 개가 있을 것입니다. 그중 일부는 너무 교묘하게 동화되어 웹 앱인지조차 알 수 없습니다.
단점은 각 플랫폼으로 교차 컴파일해야 한다는 것입니다. PhoneGap과 같은 기존 프레임워크가 도움이 될 수 있습니다. 더 나은 점은 PhoneGap Build 및 Apparatio와 같은 웹 서비스가 개발 중이라는 것입니다. 이러한 웹사이트를 코드 저장소로 연결하면 Android 앱, iOS 앱 등이 표시되어 각 스토어에 제출할 수 있습니다. 머신에 네이티브 SDK를 설치할 필요가 없습니다. 이러한 네이티브 앱을 모두 빌드하는 데 필요한 것은 코드 편집기와 웹브라우저뿐입니다.
마켓에서 네이티브로 래핑하는 오버헤드 없이 웹 앱을 직접 지원할 예정인가요? 아직 명확하지 않습니다. Google이 작년에 Chrome 웹 스토어를 도입한 것은 알고 있습니다. 데스크톱에만 적용되지만 스토어는 다른 브라우저 공급업체의 관심을 끌었으며, 전반적으로 모바일 전용 시도를 포함한 웹 앱 카탈로그를 향한 추세의 일부입니다. 웹 스토어라는 개념은 아직 초기 단계이지만 징후는 유망합니다.
결론
여기서 승자를 선언하면 좋겠지만 현재로서는 확실한 승자가 없습니다. 네이티브에 가장 적합한 앱이 있고 웹에 가장 적합한 앱이 있습니다. 웹 스택이 더 많은 모멘텀을 가지고 있다고 할 수 있지만, 기능과 실행 품질 측면에서 네이티브 앱도 빠르게 움직이고 있습니다. 웹 기술이 대부분의 모바일 OS에서 일급 시민이 되는 시기가 오지 않는 한 네이티브는 항상 중요한 고려사항이 될 것입니다.
이 도움말에 언급된 한 가지 기술은 하이브리드 앱이며, 이는 일부 개발자에게 최적의 절충안일 수 있습니다. 가능한 경우 웹 뷰를 사용하고, 불가능한 경우 플랫폼별 네이티브 구성요소를 사용합니다.
웹 경로를 선택하는 경우 웹 표준과 점진적 개선 원칙을 염두에 두세요. 웹은 다양한 기기와 운영체제를 타겟팅하는 방법을 아는 기술입니다. '단편화'라고 부르든 '다양성'이라고 부르든 웹은 이를 수용하며 개발자는 기존의 모든 선행 기술을 활용할 수 있습니다.