PWA, Capacitor, Expo, Flutter, 네이티브 중 무엇을 고를까

추상적으로 가장 좋은 모바일 프레임워크는 없습니다. 확인된 요구사항과 현재 팀에 가장 위험이 낮은 경로가 있을 뿐입니다.

선택하려는 모바일 시장 이해하기

도달 범위, 기기 구성, 스토어 경제성은 국가와 대상 사용자에 따라 달라집니다. 아래 수치는 프레임워크 결정을 위한 특정 시점의 배경 자료이며, 내 제품의 실제 사용자 분석을 대신하지 않습니다.

다섯 가지 경로

중요한 축으로 다섯 경로 비교하기

어떤 재사용 추정치든 기존 웹이 진짜 반응형이라는 가정이 필요합니다. hover, 데스크톱 표, 브라우저 팝업, 웹 전용 인증·결제에 의존하면 재사용 가능성은 크게 내려갑니다.

방향성 판단일 뿐 약속이 아닙니다. 실제 사용할 버전과 플러그인을 검증하세요.

결정 트리

1. 반응형 웹으로 해결되는가? 웹이나 PWA를 선택하고 멈춥니다.
2. 완성도 높은 모바일 웹 앱이 있는가? Capacitor를 검토합니다.
3. 어려운 네이티브 기능 여러 개가 핵심인가? 먼저 프로토타입을 만듭니다.
4. 팀은 무엇을 아는가? React라면 Expo, Dart라면 Flutter, 두 플랫폼 전담팀이 있다면 네이티브가 현실적입니다.
5. 가장 어려운 기능이 실제 기기에서 된 뒤 최종 선택합니다.

이름이 품질을 보장하지는 않습니다

“네이티브 느낌”은 가능성의 상한이지 기본값이 아닙니다. 키보드, 화면 전환, 로딩 상태, 긴 목록 성능, 오류 복구, 실제 기기 테스트가 프레임워크 로고보다 중요합니다.

“오프라인 지원”도 단순한 예·아니오가 아닙니다.

• 본 콘텐츠 다시 보기는 비교적 간단합니다.
• 오프라인 작성·수정은 로컬 저장소와 동기화 큐가 필요합니다.
• 완전한 오프라인 CRUD는 충돌 해결이 필요해 UI 전체보다 큰 작업이 될 수 있습니다.

어떤 경로든 오프라인 기능을 만들 수 있지만 데이터 규칙까지 자동으로 주지는 않습니다.

웹을 감싸기 전에 감사하기

Capacitor 재사용률은 기존 웹이 모바일에 잘 맞을 때만 높습니다. 데스크톱 전용 메뉴, hover, 넓은 표, 팝업, 파일 업로드, 결제, WebView 안의 인증 이동을 확인하세요.

콘텐츠, 커머스, 교육, 현장 업무, 사내 앱에서 Capacitor는 임시 다리가 아니라 최종 구조가 될 수 있습니다.

6개월을 약속하기 전에 2주 증명하기

증명에는 가장 어려운 기능, 로그인, 대표 데이터 흐름 하나, 운영과 비슷한 화면 이동, 오류 처리, 두 플랫폼에 설치되는 빌드가 포함되어야 합니다. 브라우저 미리보기만 보고 판단하지 마세요.

코딩 전에 통과 기준을 정합니다. 예: “30분 녹음하고, 전화 한 번을 견디며, 느린 네트워크에서 진행률을 보여주고, 실패 후 한 번 이어 올리며, 정한 배터리·메모리 한도 안에 들어온다.”

선택 원칙

첫 데모를 보여주는 가장 단순한 구조가 아니라, 가장 어려운 확인된 요구사항을 지원하는 가장 단순한 구조를 고르세요.

핵심 정리

요구사항과 이미 가진 자산에서 출발하세요. 불확실성이 가장 큰 기능을 시험한 뒤, 팀이 새로 배우고 운영할 것이 가장 적은 경로를 선택하세요.