Web App 또는 Mobile App? MVP 플랫폼 선택하기

Source: Dev.to

플랫폼 선택에 대한 불편한 진실

아무도 말해주지 않는 사실: “올바른” 플랫폼은 트렌드나 경쟁자가 만든 것과 관계가 없습니다. 당신의 특정 사용자가 그들의 특정 문제를 해결해야 하는 곳이 바로 플랫폼입니다.

• 하루에 세 번씩 데스크톱 앞에 앉아야 하는 명상 앱? 이미 실패한 셈입니다.
• 영업팀이 전화기로만 확인하는 B2B 분석 대시보드? 역시 실패합니다.

플랫폼은 선택이 아니라 사용자 행동에 의해 정해지는 제약입니다.

모바일이 적합할 때 (그리고 그렇지 않을 때)

모바일 앱은 매력적입니다. 웹 앱이 줄 수 없는 “실제감”을 줍니다. 손에 쥘 수 있고, 아이콘도 있습니다. 엄마도 앱 스토어에서 찾을 수 있죠.

하지만 모바일은 비용이 많이 들고 개발이 느립니다. 언제 가치가 있는지 살펴보세요:

제품에 이동성이 필수일 때

“모바일에 있으면 좋겠어요”가 아니라 필수인 경우.

모바일이 반드시 필요한 예시

• 라이드‑쉐어링
• 피트니스 트래킹 (사람들은 노트북을 들고 달리지 않음)
• 음식 배달 (고객이 어디서든 주문)
• 현장 서비스 관리 (기술자가 현장에서 작업)
• 위치 기반 소셜 앱 (핵심이 바로 외부에 있음)

모바일이 필요하지 않은 예시 (창업자들이 흔히 착각함)

• 대부분의 B2B SaaS (결정권자는 책상 앞에 있음)
• 프로젝트 관리 도구 (세부 작업은 화면 공간이 필요)
• CRM 시스템 (영업팀은 컴퓨터 앞에서 작업)
• 분석 대시보드 (복잡한 데이터는 넓은 화면이 필요)

네이티브 디바이스 기능이 필요할 때

카메라, GPS, 푸시 알림, 생체 인증, 실제로 동작하는 오프라인 기능 등. 핵심 가치 제안이 이러한 기능에 의존한다면 모바일은 협상 불가입니다.

솔직히 말해보세요: 카메라가 정말 필요합니까, 아니면 멋지다고 생각해서인가요? “멋짐”은 개발 시간 몇 주를 추가합니다.

사용자가 실제로 모바일‑퍼스트일 때

“그들은 휴대폰을 많이 사용한다”는 말은 모두에게 해당됩니다.

핵심은 특정 문제를 주로 휴대폰에서 해결하고, 데스크톱으로 강제하면 감당할 수 없는 마찰이 발생한다는 점입니다.

• Z세대를 겨냥한 소비자 앱? 모바일‑퍼스트가 타당합니다.
• 재무팀을 위한 엔터프라이즈 소프트웨어? 보통 3대 모니터가 달린 데스크톱을 사용합니다.

앱 스토어에서 경쟁하고 있을 때

때때로 배포 채널 자체가 전략이 됩니다. 사용자가 App Store 또는 Google Play에서 솔루션을 찾을 것으로 기대한다면, 반드시 그곳에 있어야 합니다.

하지만 기억하세요: 앱 스토어에서의 발견은 매우 가혹합니다. 추천받는 것은 복권 당첨 수준이며, 마케팅 없이 자연 다운로드는 거의 불가능합니다.

웹 앱은 구글 검색, 링크 공유, 설치 없이 즉시 접근이 가능하므로 그 점을 과소평가하지 마세요.

웹 앱 사례 (생각보다 강력함)

웹 앱은 “모바일 앱보다 덜 진지하다”는 편견에 휩싸이곤 합니다. 이는 전혀 사실이 아닙니다.

• Slack은 웹 앱으로 270억 달러 규모 회사를 만들었습니다.
• Notion은 웹‑퍼스트로 가정용 브랜드가 되었습니다.
• Linear, Figma, Airtable—모두 웹‑퍼스트, 이후에 모바일을 추가했습니다.

MVP는 몇 주 안에 출시해야 함, 몇 달이 아니라

모바일 앱을 만든다는 것은:

• iOS (Swift/SwiftUI) 개발
• Android (Kotlin/Jetpack Compose) 개발
• 혹은 크로스‑플랫폼 (React Native/Flutter) 개발 및 프레임워크 제한과 싸우기
• 앱 스토어에 제출하고 승인 대기
• 버전 관리, 업데이트, 리뷰 사이클 처리

웹 앱을 만든다는 것은:

• 하나의 코드베이스
• 원하는 시점에 배포
• 모든 사용자가 즉시 업데이트 적용
• 승인 절차 없음
• 같은 날 피드백을 반영해 반복 가능

MVP에서는 이 속도가 전부입니다. 아이디어가 작동하는지 학습하려는 것이지 완벽한 제품을 만들려는 것이 아닙니다.

우리는 최근 한 창업자와 계약자 관리 플랫폼을 개발했습니다. 처음엔 “우리 경쟁자가 앱을 가지고 있다”는 이유로 모바일 앱을 원했죠. 우리는 웹‑퍼스트로 설득해 8주 만에 출시했고, 초기 사용자를 확보해 실제로 중요한 기능을 파악했습니다. 이제는 현장 시간 추적이라는 한 가지 기능을 위해 모바일 보조 앱을 개발 중입니다.

만약 모바일‑퍼스트로 진행했더라면? 16주가 걸렸을 것이고, 앱 스토어 승인 때문에 학습 절반만 얻었을 겁니다.

복잡한 인터페이스 또는 데이터‑무거운 워크플로

스마트폰 화면은 약 6인치 정도입니다. 일부 작업은 더 많은 화면이 필요합니다.

재무 대시보드, 스프레드시트 중심 도구, 디자인 소프트웨어, 코드 편집기, 복잡한 설정 인터페이스 등은 모바일 제약에 맞서기보다 회피합니다.

반응형 웹 앱은 사용자가 필요할 때 데스크톱 수준의 파워를, 필요 없을 때는 모바일 접근성을 제공합니다.

소비자가 아닌 기업을 대상으로 할 때

B2B 사용자는 B2C와 사용 방식이 다릅니다.

• 책상 앞에 앉아 있습니다.
• 워크플로가 존재합니다.
• 다른 도구와의 통합이 필요합니다.
• 여러 탭을 열고 전환합니다.

이들은 실제 키보드와 넓은 화면을 필요로 하는 집중 작업을 합니다. 물론 특정 작업에 대한 모바일 접근이 필요해질 수 있지만, 제품을 체험하기 전에 앱을 다운로드하도록 강요하면 이미 복잡한 B2B 영업 과정에 마찰을 더하게 됩니다.

엔터프라이즈 영업에서는 “앱을 다운로드하세요”보다 깔끔하고 북마크 가능한 URL을 가진 웹 앱이 언제나 승리합니다.

예산과 일정이 중요할 때

• 네이티브 iOS MVP: 몇 개월
• 네이티브 Android MVP: 또 몇 개월
• 두 플랫폼 모두: 상당한 시간 투자(또는 타협이 있는 크로스‑플랫폼)
• 반응형 웹 앱: 일반적으로 6–10주

이 수치는 임의가 아닙니다. 모바일 개발은 여러 플랫폼을 동시에 다루거나 크로스‑플랫폼 프레임워크 오버헤드 때문에 복잡합니다. 부트스트래핑 단계이거나 프리시드 단계라면, 이 일정 차이가 출시 여부를 가르는 결정적인 요인이 됩니다.

크로스‑플랫폼 중간 지대 (주의 깊게 접근)

“React Native나 Flutter는 왜 안 쓰나요? 하나의 가격으로 두 플랫폼을 얻을 수 있잖아요!”

이론적으로는 맞습니다. 실제로는 복잡합니다.

크로스‑플랫폼 프레임워크는 많이 발전했습니다. React Native는 Facebook, Instagram, Shopify를, Flutter는 Google Ads, Alibaba, BMW를 구동합니다. 장난감이 아닙니다.

하지만 트레이드‑오프가 존재합니다:

프레임워크 제한과 싸우고 있음

네이티브 iOS·Android 기능이 React Native/Flutter에 구현되기까지 시간이 걸립니다. 때로는 구현되지 않기도 합니다. 항상 프레임워크가 따라오기를 기다려야 합니다.

Apple이 방금 발표한 최신 iOS 기능이 필요하다면? 네이티브 개발자는 바로 사용할 수 있지만, 크로스‑플랫폼 개발자는 라이브러리 지원을 기다려야 합니다.

80/20 법칙 적용

앱의 80 %는 크로스‑플랫폼으로 잘 동작합니다. 나머지 20 %—특이한 엣지 케이스, 플랫폼‑특화 UX, 네이티브 통합—가 개발 시간의 80 %를 차지합니다.

경험 많은 모바일 개발자는 이를 관리할 수 있지만, 에이전시나 주니어 개발자를 고용한다면 골칫거리가 될 것입니다.

성능이 완전 네이티브는 아님

대부분의 앱에서는 큰 차이가 없지만, 그래픽 집약적이거나 성능이 중요한 경우 차이를 느낄 수 있습니다.

크로스‑플랫폼이 적합한 경우

• 모바일이 필요하지만 두 개의 네이티브 앱을 만들 여유가 없을 때.
• 최신 플랫폼 기능에 크게 의존하지 않을 때.
• 경험 있는 React Native 또는 Flutter 개발자를 보유하고 있을 때.
• 앱이 유틸리티 중심이며 “프리미엄” 느낌이나 고도화된 네이티브 앱과 경쟁하려는 목적이 아닐 때.

MVP 단계에서는 저는 회의적입니다. 학습 속도를 늦추고 위험을 높이는 복잡성을 추가하게 되니까요.