PWA, Capacitor, Expo, Flutter, 네이티브 중 무엇을 고를까
요구사항을 먼저 확인하고 모바일 앱 개발의 다섯 경로를 선택하는 실전 가이드입니다.
On This Page
추상적으로 가장 좋은 모바일 프레임워크는 없습니다. 확인된 요구사항과 현재 팀에 가장 위험이 낮은 경로가 있을 뿐입니다.
프레임워크 비교는 가능성을 설명합니다. 우리 팀의 구현 능력, 실제 플러그인 품질, 제품을 특별하게 만드는 기기 작업까지 측정해주지는 않습니다.
다섯 가지 경로
| 경로 | 이런 상황에서 시작 | 주요 제약 |
|---|---|---|
| 반응형 웹 / PWA | 링크만으로 문제를 풀 수 있고 스토어가 불필요 | 설치 과정과 깊은 OS 연동 |
| Capacitor | 이미 모바일에 잘 맞는 웹 앱이 있음 | WebView 성능과 플러그인 적합성 |
| Expo / React Native | 모바일 우선이며 React·TypeScript에 익숙함 | 네이티브 설정이 사라지는 것은 아님 |
| Flutter | 맞춤 렌더링, 모바일+데스크톱, Dart 경험이 중요 | 채용과 AI 도움의 풀이 상대적으로 작음 |
| 완전 네이티브 | 위젯·워치·키보드·최신 하드웨어·깊은 OS 연동이 핵심 | 두 플랫폼의 인력과 비용 |
중요한 축으로 다섯 경로 비교하기
이 차트는 기존 웹이 진짜 반응형이라는 가정입니다. hover, 데스크톱 표, 브라우저 팝업, 웹 전용 인증·결제에 의존하면 재사용 가능성은 크게 내려갑니다.
| 비교 축 | PWA | Capacitor | Expo/RN | Flutter | 네이티브 |
|---|---|---|---|---|---|
| 빠른 검증 | 매우 좋음 | 기존 웹이면 매우 좋음 | 좋음 | 좋음 | 낮음 |
| 스토어 배포 | 아니오 | 가능 | 가능 | 가능 | 가능 |
| 최신 OS API | 제한적 | 플러그인/맞춤 코드 | 좋음 | 좋음 | 최고 |
| 맞춤 애니메이션 상한 | 보통 | 보통 | 높음 | 매우 높음 | 최고 |
| 솔로 빌더의 AI 도움 | 강함 | 강함 | 모바일 중 가장 강함 | 보통 | 플랫폼별 분산 |
| 모바일 UI 하나 공유 | 가능 | 가능 | 대부분 | 가능 | 불가 |
방향성 판단일 뿐 약속이 아닙니다. 실제 사용할 버전과 플러그인을 검증하세요.
결정 트리
- 반응형 웹으로 해결되는가? 웹이나 PWA를 선택하고 멈춥니다.
- 완성도 높은 모바일 웹 앱이 있는가? Capacitor를 검토합니다.
- 어려운 네이티브 기능 여러 개가 핵심인가? 먼저 프로토타입을 만듭니다.
- 팀은 무엇을 아는가? React라면 Expo, Dart라면 Flutter, 두 플랫폼 전담팀이 있다면 네이티브가 현실적입니다.
- 가장 어려운 기능이 실제 기기에서 된 뒤 최종 선택합니다.
웹으로 충분한가 → 모바일 웹을 재사용할 수 있는가 → 어려운 네이티브 요구가 있는가 → 팀이 무엇을 아는가 → 실제 기기 프로토타입이 통과했는가. 이 순서가 프레임워크 인기 순위보다 안전합니다.
이름이 품질을 보장하지는 않습니다
“네이티브 느낌”은 가능성의 상한이지 기본값이 아닙니다. 키보드, 화면 전환, 로딩 상태, 긴 목록 성능, 오류 복구, 실제 기기 테스트가 프레임워크 로고보다 중요합니다.
“오프라인 지원”도 단순한 예·아니오가 아닙니다.
- 본 콘텐츠 다시 보기는 비교적 간단합니다.
- 오프라인 작성·수정은 로컬 저장소와 동기화 큐가 필요합니다.
- 완전한 오프라인 CRUD는 충돌 해결이 필요해 UI 전체보다 큰 작업이 될 수 있습니다.
어떤 경로든 오프라인 기능을 만들 수 있지만 데이터 규칙까지 자동으로 주지는 않습니다.
웹을 감싸기 전에 감사하기
Capacitor 재사용률은 기존 웹이 모바일에 잘 맞을 때만 높습니다. 데스크톱 전용 메뉴, hover, 넓은 표, 팝업, 파일 업로드, 결제, WebView 안의 인증 이동을 확인하세요.
콘텐츠, 커머스, 교육, 현장 업무, 사내 앱에서 Capacitor는 임시 다리가 아니라 최종 구조가 될 수 있습니다.
6개월을 약속하기 전에 2주 증명하기
증명에는 가장 어려운 기능, 로그인, 대표 데이터 흐름 하나, 운영과 비슷한 화면 이동, 오류 처리, 두 플랫폼에 설치되는 빌드가 포함되어야 합니다. 브라우저 미리보기만 보고 판단하지 마세요.
코딩 전에 통과 기준을 정합니다. 예: “30분 녹음하고, 전화 한 번을 견디며, 느린 네트워크에서 진행률을 보여주고, 실패 후 한 번 이어 올리며, 정한 배터리·메모리 한도 안에 들어온다.”
- 확인된 요구사항과 명시적 비요구사항
- 실제 기기 프로토타입 증거
- 플러그인 상태, 라이선스, 유지관리 활동
- 팀 역량과 채용 경로
- 오프라인과 백그라운드 동작
- 빌드, 출시, OTA 업데이트 방식
- 탈출구: API, 데이터, 인증, 분석, 식별자
선택 원칙
첫 데모를 보여주는 가장 단순한 구조가 아니라, 가장 어려운 확인된 요구사항을 지원하는 가장 단순한 구조를 고르세요.
핵심 정리
요구사항과 이미 가진 자산에서 출발하세요. 불확실성이 가장 큰 기능을 시험한 뒤, 팀이 새로 배우고 운영할 것이 가장 적은 경로를 선택하세요.