네이티브 및 PWA: 도전자가 아닌 선택!

"네이티브"와 "웹" 사이의 균열이 실제로 어디에서 시작되었는지 정확히 말하기는 어렵습니다. Flash의 초창기부터 표면 바로 아래에서 휘젓다가 최근에 모바일 플랫폼이 부상하면서 폭발하게 된 것 중 하나라고 생각합니다. 그럼에도 불구하고 개발자들은 이 "큰 틈"을 가로질러 자신의 편을 강화하기 위해 서로에게 모욕을 퍼붓습니다.

나는 그 싸움에 관심이 없다. 물론 저는 "웹 가이"입니다. 하지만 그렇다고 해서 네이티브 개발의 매력을 볼 수 없다는 것은 아닙니다. 저도 소프트웨어 개발자입니다. 무엇보다 저는 실용주의자입니다. 나는 모든 프로젝트가 다르고 각각에 대한 접근 방식이 프로젝트의 요구와 목표에 맞춰져야 한다는 것을 알고 있습니다.

PWA(Progressive Web Apps)가 네이티브 개발 영역을 잠식하면서 한발 물러서서 제품 구축에 대한 이 두 가지 접근 방식을 검토하기에 좋은 시기라고 생각했습니다. 제 희망은 우리 모두가 우리가 만드는 제품에 적합한 것을 찾기 위해 각 접근 방식의 장점을 명확하게 볼 수 있는 능력을 갖추는 것입니다.

속사 비교

거의 초기부터 웹 기반 경험은 데스크탑 소프트웨어(원래 "네이티브 앱")에서 대화형 CD-ROM, Flash, 가장 최근에는 모바일 앱에 이르기까지 모든 것과 비교되었습니다. 여러 번 죽은 것으로 선언되었음에도 불구하고 웹은 지속되었습니다. 많은 경우에 킬러(RIP Flash)보다 오래 지속되었습니다.

이와 관련하여 웹의 주요 장점 중 하나는 적응성입니다. 인터넷이 연결된 곳이면 어디든 갈 수 있고 계속해서 새로운 기능을 얻을 수 있습니다. 모든 프로그래밍 언어는 진화하므로 예상치 못한 일이 아니지만 시간이 지남에 따라 웹의 성장하는 경계는 계속해서 기존 소프트웨어의 영역을 잠식했습니다.

그러나 웹이 역사적으로 부족했던 한 영역은 성능 영역이었습니다. 설치된 소프트웨어는 웹에서 할 수 없는 방식으로 기본 운영 체제에 연결할 수 있습니다. 하드웨어에 직접 액세스하거나 우리가 흔히 말하는 "금속에 더 가깝다"고 호스트의 공용어로 작성되었습니다. 거의 항상 그 위의 하나 이상의 추상화 계층을 운영하는 웹은 성능 면에서 경쟁하는 데 어려움을 겪었습니다. 시간이 지남에 따라 성능 격차가 줄어들었지만, 최소한 웹이 하드웨어 핀에서 직접 신호를 해석할 수 있게 될 때까지는 네이티브 코드가 웹 코드보다 더 빠르게 계속 실행될 것입니다.

성능 이점과 함께 네이티브 개발은 NFC, Bluetooth, 근접 및 주변 광 센서 등과 같은 장치 기능에 훨씬 더 빨리(그리고 더 일찍) 액세스할 수 있습니다. 웹에서도 이러한 기능에 꾸준히 액세스하고 있지만 웹에서 이러한 기능을 활용하기 전에 기본 API를 개발해야 하고 브라우저 전체에서 표준화하는 데 시간이 걸리기 때문에 항상 기본 API보다 뒤쳐집니다.

또한 기본 코드는 주소록 및 캘린더와 같은 OS 수준 기능에 연결할 수 있습니다. 푸시 알림은 또 다른 중요한 기능이었지만 이제 서비스 워커를 통해 웹에서도 해당 기능을 활용할 수 있습니다. 최근 웹에서 지불 처리가 유사하게 개선되었습니다. 아마도 주소록과 캘린더 액세스는 결국 웹에도 올 것입니다.

잠시 서비스 워커로 돌아가서 웹 개발자의 도구 상자에 최근 추가된 이 기능에는 다른 많은 트릭이 있습니다. 우선, 이전에 AppCache를 사용하여 웹에서 사용했던 것보다 훨씬 더 강력한 캐싱 시스템을 제공합니다. 서비스 워커를 사용하여 오프라인 요청을 관리하고, 특정 리소스를 캐시하고, 사용자가 사이트를 열지 않았을 때 원격 서버와 데이터를 동기화하는 등 수많은 작업을 수행할 수 있습니다. 서비스 워커는 다른 어떤 단일 기술보다 더 많은 앱과 같은 경험을 제공하는 웹을 가능하게 했습니다.

서비스 워커는 PWA의 세 가지 기술 핵심 요소 중 하나입니다. 다른 하나는 웹 앱 매니페스트입니다. 다소 지루하게 들릴 수도 있지만 Web App Manifest는 웹사이트가 자체적으로 앱으로 광고할 수 있도록 해준다는 점에서 실제로 매우 강력한 도구입니다. 이 비교적 간단한 JSON 파일 형식은 설명하는 웹 사이트에 대한 풍부한 정보를 제공하고 PWA 인식 브라우저와 운영 체제가 기본 소프트웨어인 것처럼 사이트를 설치할 수 있도록 합니다.

일부 앱 스토어는 매니페스트를 사용하여 관련 항목을 채우는 PWA를 인덱싱하기 시작했습니다. 사용자 관점에서 앱 스토어의 PWA는 주변의 기본 앱과 다르지 않습니다. 설치 및 제거가 가능하며 설정을 기본 운영 체제의 앱 관리 도구에 노출할 수도 있습니다. PWA는 실제로 웹에 있기 때문에 PWA를 사용하기 위해 사용자가 명시적으로 설치할 필요가 없다는 점도 주목할 가치가 있습니다.

웹과 웹 모두에 있다는 것은 PWA가 항상 최신 상태임을 의미합니다. 사용자는 새로운 기능에 액세스하기 위해 새로운 것을 적극적으로 다운로드할 필요가 없습니다. 그리고 새로운 콘텐츠와 기능이 출시되더라도 대부분의 기본 앱의 경우처럼 사용자가 전체 PWA를 다시 다운로드해야 할 가능성은 거의 없습니다. 어떤 것이든, 그들은 몇 가지 새로운 자산과 몇 가지 새로운 HTML을 얻을 수 있으며 앱 스토어가 필요 없이 매우 즉각적으로 발생합니다. 물론 여전히 앱 스토어에서 제공하는 검색 및 배포 옵션이 있으므로 실제로는 두 가지 모두에서 최고입니다.

앱 스토어에 있다는 것은 PWA를 발견, 배포 및 수익화 측면에서 네이티브 앱과 동등한 위치에 놓이게 합니다. 사실, PWA는 검색 엔진을 통해서도 검색할 수 있고 URL에 존재하기 때문에 앱보다 무한히 공유할 수 있기 때문에 네이티브보다 웹을 보관할 수도 있습니다. 잘 구축되면 PWA는 브라우저, 플랫폼 및 장치 간에도 상호 운용 가능합니다. PWA 기능은 점진적 개선 사항이기 때문에 PWA는 서비스 워커와 같은 기능을 지원하지 않는 브라우저에서도 작동합니다.

웹은 또한 매우 성숙한 접근성 지원을 제공하므로 가장 광범위한 사용자가 프로젝트를 사용할 수 있도록 비교적 쉽게 할 수 있습니다. 복잡한 인터페이스는 프로그래밍과 관련하여 좀 더 노력이 필요하지만 의미 체계 HTML이 제공하는 접근성 이점은 특히 텍스트가 많은 정보 제공 또는 간단한 양식 기반 제품의 경우 기본 접근성을 적절하게 처리합니다. 대조적으로, 거의 항상 접근성 API를 인식하고 네이티브 코드에 통합해야 합니다.

개발이라는 주제에 관해서는 개발 경험에 있어 확실한 승자는 없다고 생각합니다. 모든 언어에는 팬이 있으며 개발자 도구도 마찬가지입니다. 당신은 당신이 좋아하는 것을 좋아하고 당신이 알고 있고 열정적인 도구와 언어를 사용하는 경향이 있습니다. 웹이나 네이티브 개발 모두 거기에는 뚜렷한 이점이 없습니다.

그러나 네이티브 개발이 빛나는 곳은 SDK(소프트웨어 개발 키트)를 사용하여 빌드된 UI의 일관된 품질 수준을 보장할 때입니다. 대부분의 기본 SDK는 성능, 디자인, 기능 등을 테스트하기 위한 도구를 제공합니다. 여기에는 또한 기본 소프트웨어 제공의 전반적인 기준을 높이는 데 도움이 되는 상용구 코드, 디자인 시스템 및 기타 도구가 포함됩니다. 물론 웹을 위한 유사한 도구가 있지만 웹 전체에 흩어져 있고 사람들이 웹 사이트를 구축하는 데 사용하는 모든 다양한 개발 환경에 보편적이지 않습니다. 양질의 웹 경험을 정의하고 이를 구축하기 위한 도구를 제공하는 단일 주체는 없습니다(많은 사람들이 시도했지만).

제품 개발에 인력을 배치할 때 웹용으로 빌드하는 방법을 알고 있는 사람을 고용하는 것이 확실히 더 쉽습니다. 내가 입력할 때 프로그래밍 언어 색인은 현재 JavaScript를 가장 인기 있는 언어로 순위를 매겼고 그 뒤에 Java가 있습니다. C#은 5위, HTML은 7위, CSS는 9위, Swift는 15위입니다. 이 인덱스는 GitHub의 공개 리포지토리에서 변경된 행으로 스택 오버플로 태그를 상호 참조하므로 약간의 이해가 필요하지만 많은 사람들이 웹 기술을 알고(그리고 사용하고) 있다는 매우 분명한 표시를 제공합니다. 반면에 재능 있는 네이티브 개발자는 적고 수요가 많기 때문에 찾고 고용하는 것이 어려울 수 있습니다.

재능이 부족하면 결국 네이티브 개발에 더 많은 비용을 지불하게 될 것입니다. 모든 프로젝트는 분명히 다르고 기능과 요구 사항도 다르지만 평균 개발 비용을 비교하는 것으로 설명할 수 있습니다. 코멘텀은 중간 규모의 웹 앱을 구축하는 비용이 US$10,000 미만에서 US$150,000이라고 제안합니다. 기본적으로 Appster는 중간 규모의 모바일 앱 프로젝트를 구축하는 데 110,000~305,000달러가 소요될 것으로 추정합니다. 네이티브 프로젝트는 웹 프로젝트보다 개발 비용이 두 배 정도 더 든다고 가정하는 것이 안전할 것입니다. 그리고 그것은 플랫폼에 따라 다릅니다. 또한 기본 앱은 일반적으로 개발하는 데 시간이 더 오래 걸립니다.

PWA를 구축하지 않고 웹 기술을 사용하여 기본 소프트웨어를 구축할 수 있는 옵션이 있다는 점은 주목할 가치가 있습니다. React Native, PhoneGap, Ionic 및 Appcelerator Titanium과 같은 프레임워크를 사용하면 HTML, CSS 및 JavaScript에서 기본 코드를 생성할 수 있습니다. 이러한 도구 중 하나를 사용하면 기본 개발자 팀을 고용하는 것과 비교할 때 인력 및 개발 비용을 낮출 수 있지만 장치 기능에 대한 액세스 측면에서 프로젝트는 프레임워크가 구현한 것으로 제한됩니다. 그에 따라 계획하십시오.

앱이 개발되면 해당 앱 또는 앱의 지속적인 유지 관리 비용도 고려해야 합니다. Clutch에서 실시한 설문 조사에 대한 응답으로 Dom & Tom은 첫해에는 제품 초기 가격의 50%, 두 번째 해에는 25%, 그 이후에는 매년 15-25%의 예산을 책정할 것을 권장합니다.

웹 개발과 네이티브 개발이 어떻게 비교되고 대조되는지 충분히 이해하고 나면 프로젝트와 관련된 강점과 약점을 평가할 수 있습니다. 약간의 절충을 해야 할 가능성이 높으며 이는 예상된 일입니다. 만능 솔루션은 없습니다. 그리고 있다면 누구에게도 잘 맞지 않을 것입니다.

네이티브 개발과 PWA 개발 간의 차이점에 초점을 더 명확하게 맞추기 위해 몇 가지 가상 프로젝트를 실행해 보겠습니다.

프로젝트 #1: 기존 네이티브 앱

이미 네이티브 앱을 구축하는 과정을 거쳤다고 가정해 보겠습니다. 모든 것이 순조롭게 진행된다면 진로를 바꿀 이유가 없습니다. 정말 그럴만한 이유가 없는 한 PWA로 전환하기 위해 기존 작업을 모두 버리지 마십시오. PWA로의 전환을 고려할 만한 시나리오는 한 가지뿐입니다. 새 OS에 대한 지원을 혼합에 도입하는 것입니다. 그런 경우에도 웹만으로 앱의 요구 사항을 충족할 수 있는 경우에만 의미가 있습니다.

제품에 새 플랫폼에 대한 지원을 추가하는 경우 해당 요구 사항을 충족하는 비용과 관련하여 프로젝트의 요구 사항 및 목표를 평가할 수 있는 완벽한 기회가 생성됩니다. 웹이 작업에 적합하지 않은 경우 기본을 고수하십시오. 그러나 그럴 경우 잠시 멈추고 다음 사항을 고려하십시오. PWA를 사용하여 새 플랫폼에 대한 지원을 추가하면 향후 추가 플랫폼(웹 포함)을 지원할 수 있고 PWA가 설치되면 기존 기본 애플리케이션을 교체할 수도 있습니다. 철저히 테스트되었습니다.

기존 기본 앱을 PWA로 교체하는 것이 불가능해 보인다면 다음을 고려하십시오. Starbucks와 Twitter는 이미 이 아이디어를 모색하고 있습니다.

앱을 기본 상태로 유지해야 하는 특정한 이유가 있는 경우에도 특정 앱 기능을 웹에 "아웃소싱"하는 것을 고려할 가치가 있습니다. 몇 년 전 저는 대형 금융 서비스 회사에서 프로젝트를 진행하고 있었는데, 일반 앱 스토어보다 더 빠르게 보안 기능을 출시할 수 있도록 네이티브 앱의 로그인 흐름을 웹으로 옮기기로 결정했습니다. 승인 프로세스를 통해 달성할 수 있었습니다. 아마도 당신의 프로젝트에는 웹이 당신의 네이티브 앱이 충족할 수 있도록 하는 유사한 요구 사항이 있을 것입니다.

프로젝트 #2: 기존 크로스 플랫폼 앱

교차 플랫폼에서 작동하는 기존 앱이 있는 경우 해당 앱의 지속적인 개발 및 유지 관리를 위해 많은 돈을 지출할 가능성이 높습니다. 또한 각 네이티브 플랫폼에는 고유한 개발 일정이 있는 경향이 있기 때문에 인앱 기능이 일부 차이가 나는 것을 볼 수 있습니다. 예를 들어 소매업체 Target의 앱은 현재 사용자가 iOS에서 쇼핑 목록을 관리할 수 있도록 하지만 Android 버전에는 해당 기능이 없습니다. 여러 면에서 웹사이트의 "데스크톱" 버전과 "모바일" 버전 사이에서 종종 볼 수 있는 차이와 유사합니다.

웹이 이미 크로스 플랫폼 믹스의 일부인 경우 거기에 대한 투자를 두 배로 줄이고 기본 앱을 PWA로 교체하는 것을 고려할 수 있는 좋은 기회를 제공합니다. 수중 음파 탐지기 및 Lighthouse와 같은 도구는 기존 사이트가 PWA화에 얼마나 잘 준비되어 있는지에 대한 통찰력을 제공하고 작업해야 할 사항을 알려줄 수도 있습니다. 거기에서 웹 사이트를 PWA로 바꾸는 것은 비교적 간단합니다. 몇 분 안에 사이트를 PWA로 업그레이드하는 데 도움이 되는 무료 도구도 있습니다. 그러나 그렇지 않은 경우 플랫폼 간의 기능 차이가 심각해지거나 다른 기본 플랫폼(또는 웹)을 혼합에 추가하는 것을 고려하지 않는 한 이러한 이동을 할 인센티브가 많지 않습니다.

프로젝트 #3: 새로운 크로스 플랫폼 제품

둘 이상의 플랫폼을 목표로 하는 새 프로젝트를 시작하는 경우 PWA로 한 곳에서 만들고 유지 관리하는 것이 확실히 테이블 위에 있어야 합니다. 예산과 직원에 따라 예산을 가장 많이 늘릴 수 있습니다. 즉, 제품에 하드웨어 또는 기본 OS에 대한 직접 연결이 필요한 경우 기본으로 전환해야 할 수도 있습니다. 그러나 그 길을 가기 전에 모든 요구 사항의 목록을 만든 다음 웹이 할 수 있는 것과 할 수 없는 것을 확인하십시오. 둘 이상의 브라우저에서도 지원되는지 확인하십시오.

프로젝트 #4: 새로운 하이퍼 포커스 제품

당신이 새로운 제품을 만들고 있고 그 제품의 전체 목적의 일부가 특정 플랫폼에 대한 깊은 연결이라면, 반드시 그 플랫폼을 위해 빌드하십시오. 예를 들어, 제품이 Apple의 메시지 플랫폼 또는 HomeKit과의 통합에 의존하는 경우 반드시 Swift에서 iOS 및/또는 macOS용으로 빌드하십시오. 제품이 위젯을 통해 사용자 요구를 가장 잘 충족시키거나 사용자 정의 실행기를 구축하는 경우 Android를 구축하는 것이 가장 좋으며 Java를 사용해야 합니다.

그러나 모든 기본 기능이 벽으로 둘러싸인 정원은 아닙니다. Amazon의 Alexa, Apple의 Siri 및 Google Assistant는 모두 앱과 통합하기 위해 기본 코드(또는 JSON API)가 필요하지만 흥미롭게도 Microsoft의 Cortana는 HTML head 에서 연결된 XML 파일만 사용하여 PWA를 음성으로 활성화합니다. 아마도 다른 사람들이 그들의 리드를 따를 것입니다.

PWA 또는 네이티브? 선택은 당신의 것입니다

웹과 네이티브는 각각 제공할 것이 많습니다. 어느 것이 더 나은지 묻는다면 나는 단순히 "그것은 다릅니다"라고 대답할 것입니다. 나는 회피하거나 헌신적이지 않습니다. 프로젝트에 적합한 것이 무엇인지 파악하는 것은 전적으로 프로젝트의 특정 요구 사항에 달려 있습니다. 구축하려는 대상, 구축을 담당하는 기존 팀 또는 이를 위해 고용해야 하는 팀의 구성, 작업해야 하는 예산을 고려해야 합니다. 대부분의 경우 웹은 프로젝트 목표를 달성하는 데 필요한 모든 것을 제공하지만 항상 예외가 있습니다. 웹이 제공하는 가능성을 탐색하려면 이 기사의 끝에 몇 가지 리소스를 포함시켰습니다.

소프트웨어 개발에 대한 다양한 접근 방식(또는 다양한 프레임워크, 라이브러리, 언어, 디자인 시스템 등)을 평가할 때 할 수 있는 가장 중요한 일은 현재 진행 중인 프로젝트와 관련하여 옵션을 고려하는 것입니다. 조사를 하고 옵션을 평가하십시오. 그리고 영리한 마케팅, 섹시한 데모 또는 열렬한 팬보이에 의해 좌우되지 마십시오. 이것 포함.

PWA 관련 리소스

• PWA 빌더
  유용한 권장 사항 및 레시피가 포함된 3단계 웹사이트-PWA 생성 도구입니다. 또한 PWA를 Windows, Android 및 iOS용 설치 가능한 기본 앱으로 전환할 수 있습니다.
• 프로그레시브 웹 앱을 위한 프로그레시브 로드맵
  Jason Grigsby는 그의 팀이 몇 개월 동안 웹사이트에 PWA의 측면을 통합하기 시작한 방법에 대해 설명하며 다양한 기능을 한 번에 조금씩 추가할 수 있는 방법을 훌륭하게 보여줍니다.
• 예, 해당 웹 프로젝트는 PWA여야 합니다.
  귀하가 작성한 PWA의 UX 기회(및 위험)에 대한 개요입니다.
• MDN의 프로그레시브 웹 앱
  고품질 PWA의 특징에 대해 알아야 할 모든 기술적인 부분을 위한 허브입니다.
• 오늘날 웹이 할 수 있는 일
  기기, OS 및 브라우저가 지원하는 API를 살펴보세요. 당신이 발견한 것이 당신을 놀라게 할 수도 있습니다.
• 사용해도 되나요
  모든 주요 브라우저에서 사용할 수 있는 API 및 기능과 사람들이 실제로 사용하는 브라우저와 관련하여 해당 지원이 측정되는 방법에 대한 최종 데이터베이스입니다. 또한 특정 기능이 이전 버전과 얼마나 호환되는지 확인할 수 있는 탁월한 보기를 제공할 수도 있습니다.