프롤로그 — 2026, 다섯 강자의 시대

2018년의 모바일 크로스 플랫폼은 두 강자였다. **React Native** 와 **Flutter**. 그 사이를 Cordova·Ionic 같은 웹뷰 진영이 메우고, NativeScript는 변두리에 있었다.

2026년 5월, 풍경이 완전히 다르다.

- **React Native** 는 0.76부터 New Architecture(Fabric + TurboModules + Hermes)가 기본이 되었다. 2026년 후반 **React Native 1.0** 이 예고됐다.

- **Expo** 는 사실상 RN의 표준이 됐다. SDK 52, Expo Router 4, EAS Build·Update가 없으면 "RN 한다"는 말이 어색해졌다.

- **Flutter 3.27** 는 **Impeller** 렌더러를 모든 플랫폼에서 기본으로 켰다. Skia 시대의 잰크는 옛말이다.

- **Compose Multiplatform 1.7 + KMP 2.1** — iOS가 정식 stable이다. Jetpack Compose를 iOS에서 그대로 돌리는 시대.

- **Tauri 2 Mobile** 이 beta로 진입했다. Rust + 시스템 웹뷰 조합으로 번들 30MB 이하를 노린다.

- **Lynx** — ByteDance가 2025년 3월에 오픈소스로 푼 새 프레임워크. TikTok·Lark가 내부에서 쓰던 물건이다.

다섯 강자다. 그리고 그 위로 **Capacitor 7**, **.NET MAUI**, **NativeScript** 가 자기 자리를 지킨다.

이 글은 2026년의 모바일 크로스 플랫폼 지도를 — 네 가지(이제 다섯 가지) 모델부터 한국·일본의 실제 사용 사례까지 — 한 호흡에 정리한다.

1장 · 2026년 모바일 크로스 플랫폼 지도 — 다섯 강자

다섯 강자를 한 표에 놓고 시작한다. 숫자는 npm/pub.dev/Maven Central 다운로드와 GitHub star 기준 2026년 5월 시점이다.

| 프레임워크 | 언어 | 렌더링 모델 | 번들 크기(빈 앱) | 핵심 강점 |

| --- | --- | --- | --- | --- |

| React Native + Expo | TypeScript/JS | Native render(Fabric) | iOS 15MB / Android 13MB | 웹 개발자 친화, 거대 생태계 |

| Flutter | Dart | 자체 렌더러(Impeller) | iOS 17MB / Android 14MB | 픽셀 단위 일관성, 60fps 일관 |

| Compose Multiplatform + KMP | Kotlin | Skia(Skiko) | iOS 18MB / Android 9MB | 코드 공유 자유도(UI 또는 logic만) |

| Tauri 2 Mobile | Rust + 웹 프론트 | 시스템 WebView | iOS 8MB / Android 6MB | 번들 최소, 보안, Rust 백엔드 |

| Lynx | TypeScript/JS | 듀얼 스레드 + 자체 렌더 | 미공개(추정 12MB) | TikTok급 성능, 듀얼 스레드 |

옆자리 후보 셋.

| 프레임워크 | 언어 | 렌더링 모델 | 메모 |

| --- | --- | --- | --- |

| Capacitor 7 (Ionic) | TypeScript/JS | 시스템 WebView | Ionic 팀, 웹 우선 |

| .NET MAUI | C#/XAML | Native render | 마이크로소프트 진영, 엔터프라이즈 |

| NativeScript | TypeScript/Vue/Svelte | Native render(JS 브리지) | 작은 커뮤니티, 살아있음 |

기억할 한 줄: **"렌더링 모델이 곧 성격이다."** 시스템 웹뷰는 빠르게 만들고, native 렌더는 일관되게 만들고, 자체 렌더러는 픽셀까지 통제한다.

2장 · 모바일 크로스 플랫폼의 네 가지 모델 (이제 다섯)

크로스 플랫폼은 결국 **"네이티브 UI를 어떻게 그리느냐"** 의 문제다. 다섯 가지 길.

1) WebView 모델 — Capacitor / Cordova / Tauri Mobile

iOS의 WKWebView와 Android의 WebView 위에 웹 앱을 얹는다. 카메라·블루투스·푸시 같은 OS 기능은 네이티브 플러그인이 JS 브리지로 노출한다.

- 장점 — 웹 개발자가 그대로 모바일을 만든다. 번들 크기가 작다. 핫 업데이트가 자유롭다(스토어 우회는 별도 정책 이슈).

- 단점 — 60fps 인터랙션이 어렵다. iOS WKWebView 메모리·키보드 이슈. App Store가 "그냥 웹뷰 래퍼"를 거절하는 경우.

2) Native Bridge 모델 — React Native (구 Architecture) / NativeScript

JS 엔진이 따로 돌고, 네이티브 UI(UIView·View)는 별도로 산다. 둘 사이를 **JSON 메시지 큐**로 잇는다.

- 장점 — UI는 진짜 네이티브 컴포넌트, 즉 OS 업데이트에 자동으로 따라간다.

- 단점 — 브리지가 비동기 + 직렬화라 큰 리스트·애니메이션에서 잰크. **New Architecture가 이 문제를 푼다.**

3) Native Render 모델 — React Native New Architecture / .NET MAUI

JS는 여전히 따로 돌지만, JSI(JavaScript Interface)로 **동기 호출**이 가능하고, Fabric이 C++ 레이어에서 네이티브 뷰 트리를 직접 만든다.

- 장점 — 진짜 네이티브 컴포넌트 + 동기 호출 + concurrent rendering.

- 단점 — 마이그레이션 비용. 구 아키텍처용 라이브러리가 일부 남아있다.

4) 자체 렌더러 모델 — Flutter / Compose Multiplatform (iOS)

OS의 네이티브 UI를 쓰지 않는다. **Skia/Impeller** 같은 그래픽 라이브러리로 모든 픽셀을 직접 그린다. iOS 버튼·Android 버튼이 모두 Flutter가 그리는 버튼이다.

- 장점 — 픽셀 단위 일관성. 한 코드가 모든 OS에서 똑같이 보인다.

- 단점 — OS UI 변화(Material You 업데이트, Dynamic Type, 접근성)를 직접 따라가야 한다.

5) 듀얼 스레드 + 자체 렌더 — Lynx

ByteDance의 새 모델. JS 스레드(메인 비즈니스)와 별도 UI 스레드를 두고, 첫 화면을 동기로 그린다. RN의 Fabric과 유사하지만 더 공격적으로 메인 스레드를 보호한다.

기억할 한 줄: **"WebView는 빠르게, Native Render는 일관되게, 자체 렌더는 픽셀까지."**

3장 · React Native New Architecture — 0.76부터 기본

2024년 10월 0.76 릴리스가 분기점이었다. **New Architecture 가 기본 활성화** 가 되었고, 이후 모든 신규 프로젝트는 자동으로 Fabric + TurboModules + Hermes 셋업이다.

세 부품의 역할을 분리해서 본다.

Hermes — JS 엔진

페이스북이 만든 JS 엔진. RN 0.70부터 기본이었고, 2026년 현재 사실상 RN의 표준 엔진이다.

- AOT 바이트코드 — 앱 빌드 시 JS를 Hermes 바이트코드로 컴파일. 시작 속도가 빠르다.

- 메모리 사용량이 V8/JSC보다 낮다.

- 디버거 — Chrome DevTools가 직접 Hermes에 붙는다.

JSC(JavaScriptCore)는 호환성용으로 남아있지만 신규 권장은 Hermes다. V8은 Android에서만 옵션으로 가능하다(번들이 커진다).

JSI — JavaScript Interface

JS와 네이티브를 잇는 **새 다리**. 핵심은 두 줄.

- 브리지가 아니라 **C++ HostObject** 다 — JS에서 보이는 객체가 사실은 C++ 메모리.

- **동기 호출** 이 가능하다 — 예전엔 모든 호출이 비동기 JSON 메시지였다.

// JSI 위에서 동기로 도는 호출 (TurboModule)

const { CryptoModule } = NativeModules

// 예전: 비동기였다

// const hash = await CryptoModule.sha256(input)

// 지금(TurboModule + JSI): 동기 가능

const hash = CryptoModule.sha256Sync(input)

TurboModules — 네이티브 모듈 인터페이스

`CodegenSchema`로 TypeScript 타입에서 C++/Java/Obj-C 인터페이스를 자동 생성한다. 예전 NativeModules의 런타임 dynamic dispatch가 컴파일 타임 type-safe로 바뀌었다.

// specs/NativeCrypto.ts

export interface Spec extends TurboModule {

sha256(input: string): string

randomBytes(length: number): string

}

export default TurboModuleRegistry.getEnforcing\<Spec\>('Crypto')

이 한 파일에서 Android(Java/Kotlin)·iOS(Obj-C/Swift) 인터페이스 코드가 자동 생성된다.

Fabric — 새 UI 매니저

C++ 레이어에서 React 트리를 받아 네이티브 뷰 트리를 직접 만든다.

- **Concurrent rendering** — React 18의 Suspense·startTransition이 RN에서 제대로 돈다.

- **Shadow tree 동기화** — 레이아웃 계산이 한 트리에서 끝난다(예전엔 JS·Shadow·Native 셋이 각자 가졌다).

- **Synchronous events** — 스크롤·터치가 메인 스레드에서 동기로 처리되어 잰크가 줄었다.

마이그레이션 체크리스트

0.76+ 신규 프로젝트

npx @react-native-community/cli@latest init MyApp # 자동으로 New Arch

기존 프로젝트 마이그레이션

1. RN 0.76+ 로 업그레이드

npx react-native upgrade

2. iOS Podfile

RCT_NEW_ARCH_ENABLED=1 npx pod-install

3. Android gradle.properties

newArchEnabled=true

4. 호환 안 되는 라이브러리 점검

npx react-native doctor

4장 · Expo SDK 52 + Expo Router 4 — 사실상 표준

"맨 RN으로 시작한다"는 말은 2026년에는 거의 듣지 않는다. **Expo 가 곧 RN의 표준 셋업** 이 되었다. 이유는 셋이다.

1. **EAS Build** — 로컬 Xcode 없이 클라우드 빌드. iOS 인증서·프로비저닝까지 다 관리해 준다.

2. **EAS Update** — JS·이미지·소형 자산 OTA 업데이트. App Store 우회가 아니라 "버그 수정 빠르게".

3. **Expo Router 4** — 파일 기반 라우팅이 네이티브 앱에 그대로. Next.js의 `app/` 디렉터리가 모바일에 온 셈.

Expo Router 4 — 파일 기반 라우팅

app/

├── _layout.tsx # 루트 레이아웃 (Tab/Stack)

├── (tabs)/

│ ├── _layout.tsx # 탭 레이아웃

│ ├── index.tsx # /

│ ├── feed.tsx # /feed

│ └── profile.tsx # /profile

├── post/

│ └── [id].tsx # /post/123 (동적 라우트)

├── modal.tsx # /modal (네이티브 모달)

└── +not-found.tsx # 404

// app/_layout.tsx

export default function RootLayout() {

return (

)

}

// app/post/[id].tsx

export default function PostScreen() {

const { id } = useLocalSearchParams\<{ id: string }\>()

return (

)

}

핵심은 두 가지다.

- **타입세이프 링크** — `expo-router`가 라우트 타입을 자동 생성한다. 잘못된 라우트는 컴파일 타임에 에러.

- **딥링크가 공짜** — `/post/123` URL이 그대로 앱 안에서 동작한다. 웹·iOS·Android 셋이 같은 라우트 트리를 본다.

EAS Build — 클라우드 빌드

// eas.json

{

"cli": { "version": ">= 13.0.0" },

"build": {

"development": {

"developmentClient": true,

"distribution": "internal"

},

"preview": {

"distribution": "internal",

"ios": { "simulator": false }

},

"production": {

"autoIncrement": true

}

},

"submit": {

"production": {}

}

}

eas build --platform ios --profile production

eas submit --platform ios --latest

이 두 줄이면 App Store까지 간다. Xcode는 한 번도 열지 않는다.

EAS Update — OTA

코드만 바뀐 작은 변경

eas update --branch production --message "Fix login crash"

네이티브 모듈을 안 건드린 변경이라면 스토어 리뷰 없이 사용자에게 도달한다. App Store 가이드라인을 지키는 한 합법이다(주요 기능 변경·UI 전면 개편은 정식 빌드 권장).

5장 · Flutter 3.27 + Impeller — 자체 렌더러 전략

Flutter는 처음부터 길을 달리 갔다. **OS의 네이티브 UI를 쓰지 않는다.** Skia(이제는 Impeller)로 모든 픽셀을 직접 그린다.

Impeller — Skia를 대체한 새 렌더러

2024년까지는 Skia + GPU shader 컴파일이라는 두 단계 때문에 첫 프레임 잰크가 있었다. **Impeller** 는 그 문제를 푼 새 렌더러다.

- **셰이더 미리 컴파일** — 빌드 시 GPU 셰이더가 다 컴파일되어 들어간다. 런타임 컴파일 잰크가 사라졌다.

- **Metal(iOS)·Vulkan(Android)** 백엔드를 기본으로 쓴다. OpenGL ES는 폴백.

- Flutter 3.27부터 **iOS·Android 모두 기본**.

Material You 3 + Cupertino

void main() {

runApp(const MyApp());

}

class MyApp extends StatelessWidget {

const MyApp({super.key});

@override

Widget build(BuildContext context) {

return MaterialApp(

title: 'Flutter Demo',

theme: ThemeData(

colorSchemeSeed: const Color(0xFF6750A4),

useMaterial3: true,

brightness: Brightness.light,

),

darkTheme: ThemeData(

colorSchemeSeed: const Color(0xFF6750A4),

useMaterial3: true,

brightness: Brightness.dark,

),

home: const HomeScreen(),

);

}

}

class HomeScreen extends StatelessWidget {

const HomeScreen({super.key});

@override

Widget build(BuildContext context) {

return Scaffold(

appBar: AppBar(title: const Text('Hello Flutter 3.27')),

body: const Center(child: Text('Material You 3 + Impeller')),

floatingActionButton: FloatingActionButton(

onPressed: () {},

child: const Icon(Icons.add),

),

);

}

}

`useMaterial3: true` + `colorSchemeSeed` 한 줄이면 Material You 컬러 시스템이 자동 적용된다. Light·Dark 톤맵핑·접근성 콘트라스트까지 자동.

자체 렌더러의 정체성

장단을 분명히 한다.

- **장점** — Android·iOS·웹·데스크톱이 픽셀 단위로 동일. 디자이너의 픽셀 퍼펙트가 진짜 동작한다.

- **단점** — OS의 UI 진화(iOS Dynamic Island 같은)에 직접 대응해야 한다. 접근성도 OS 위임이 아니라 직접 구현.

Flutter의 길은 **"OS와 다른 길로 가더라도 일관성을 잡는다"** 다. 게임·미디어·브랜드 강한 앱에 잘 맞고, OS 룩앤필을 그대로 따라가야 하는 앱에는 다소 어색할 수 있다.

6장 · Compose Multiplatform 1.7 / KMP 2.1 — iOS 정식 stable

2024년까지 Compose Multiplatform의 iOS는 "alpha"였다. 2025년 2분기 **1.6에서 beta**, 2026년 1분기 **1.7에서 stable**. 이게 뜻하는 바는 크다.

**Jetpack Compose 로 짠 코드가 iOS에서 그대로 돈다.**

KMP — 코드 공유의 자유도

Kotlin Multiplatform은 "공유 범위를 자유롭게" 가 핵심이다. 세 가지 선택.

1. **Logic만 공유** — 네트워크·DB·도메인은 KMP, UI는 SwiftUI(iOS)·Compose(Android). 가장 보수적이고 가장 많이 쓰이는 패턴.

2. **Logic + UI 일부 공유** — 공통 화면은 Compose Multiplatform, 플랫폼 특화 화면은 네이티브.

3. **Logic + UI 전부 공유** — 100% Compose Multiplatform. Flutter와 비슷한 자체 렌더(iOS는 Skiko = Skia for Kotlin).

// shared/src/commonMain/kotlin/UserRepository.kt

class UserRepository(private val api: UserApi, private val db: UserDb) {

suspend fun getUser(id: String): User {

return db.findById(id) ?: api.fetch(id).also { db.insert(it) }

}

}

// shared/src/commonMain/kotlin/App.kt

@Composable

fun App() {

MaterialTheme {

var name by remember { mutableStateOf("World") }

Column {

TextField(value = name, onValueChange = { name = it })

Text("Hello, $name!")

}

}

}

// iOS 앱에서 호출

struct ContentView: View {

var body: some View {

ComposeView() // Compose UI를 SwiftUI에 임베드

}

}

KMP 2.1의 새로움

- **K2 컴파일러** 가 기본 — 컴파일 속도 약 2배.

- **expect/actual** 가 더 안정화되어 플랫폼 특화 구현이 깔끔하다.

- **Native target** 이 Apple Silicon 빌드를 더 빠르게.

Compose Multiplatform iOS — 어디까지 왔나

- iOS Stable — 프로덕션 권장.

- Skiko 렌더링 — Skia 기반(Flutter의 Skia와 같은 라이브러리, 다른 통합).

- 접근성 — VoiceOver 지원이 1.7에서 크게 좋아졌다(아직 100% SwiftUI는 아니다).

- 텍스트 입력 — iOS 키보드·IME가 안정화됐지만 한국어 IME에서 가끔 카더라가 있다.

기억할 한 줄: **"KMP는 logic부터 시작해서 점진적으로 UI까지 올라가는 길을 준다."**

7장 · Tauri 2 Mobile — Rust + 시스템 웹뷰의 새 시도

Tauri는 데스크톱(Windows/macOS/Linux)에서 Electron의 대안으로 자리를 잡았다. **번들 30MB 이하, 메모리 1/5** 가 셀링 포인트였다. 2024~2025년에 **Mobile** 이 alpha→beta로 들어왔다.

구조 — Rust core + 시스템 웹뷰

- **iOS** — WKWebView 위에 웹 프론트(React/Vue/Svelte/Solid 등).

- **Android** — WebView(Chromium) 위에 같은 프론트.

- **Rust core** — 네이티브 기능을 Rust로 작성하고 IPC로 노출.

// src-tauri/src/lib.rs

#[tauri::command]

fn greet(name: &str) -> String {

format!("Hello, {}!", name)

}

#[cfg_attr(mobile, tauri::mobile_entry_point)]

pub fn run() {

tauri::Builder::default()

.invoke_handler(tauri::generate_handler![greet])

.run(tauri::generate_context!())

.expect("error while running tauri application");

}

// 프론트(React) 쪽

const greeting = await invoke\<string\>('greet', { name: 'YJ' })

Tauri 2 Mobile의 강점·약점

- 강점 — 번들 6-8MB(Android), 보안(자동 CSP·권한 manifest), Rust 백엔드(빠른 IO·암호화·DB 접근).

- 약점 — UI 성능은 결국 시스템 웹뷰. 60fps 게임·복잡한 애니메이션엔 부적합. iOS 17 이전 호환성 일부 이슈.

누가 쓰는가

2026년 현재 Tauri Mobile은 **prosumer 도구** — 보안 키 관리, 로컬 노트 앱, 개발자 유틸 — 에서 채택이 늘고 있다. TikTok급 소비자 앱은 아직 흔치 않다.

8장 · Capacitor 7 vs Cordova — 웹 우선의 현재

웹 우선 모바일의 두 라이벌이었다. **Cordova는 2024년 메이저 업데이트 사실상 정지**, Apache Cordova 프로젝트가 retire 트랙으로 들어갔다. 웹 우선의 자리는 사실상 **Capacitor 7** (Ionic 팀이 만든) 이 차지했다.

Capacitor 7 핵심

- **iOS WKWebView · Android Chromium WebView** 위에 웹 앱.

- **Capacitor Plugins** — 카메라·블루투스·푸시·파일 등 네이티브 기능을 JS API로.

- **Ionic Framework** 가 위에 얹어지는 UI 키트(필수는 아니다, React/Vue/Angular 어떤 거든 가능).

// Capacitor 카메라 사용

const takePhoto = async () => {

const photo = await Camera.getPhoto({

quality: 90,

allowEditing: false,

resultType: CameraResultType.Uri,

})

return photo.webPath

}

기본 셋업

npm install @capacitor/core @capacitor/cli

npx cap init

npx cap add ios

npx cap add android

npm run build

npx cap copy

npx cap open ios

누가 쓰는가

- **PWA를 빠르게 앱화** — 기존 React/Vue 앱이 있고 1-2주 만에 스토어 진입이 필요할 때.

- **엔터프라이즈 라인 오브 비즈니스 앱** — 사내용 도구. 성능 요구가 낮고 빠른 배포가 중요할 때.

- **하이브리드 e-commerce** — 일부 화면만 네이티브(체크아웃), 나머지는 웹.

App Store가 "그냥 웹뷰 래퍼"를 거절하는 사례가 늘었기 때문에, Capacitor를 쓸 때는 **"하이브리드 가치"** — 네이티브 기능 적극 사용, 오프라인 동작, 앱스러운 인터랙션 — 를 보여야 한다.

9장 · Lynx (ByteDance) — TikTok 내부 프레임워크의 오픈소스

2025년 3월, ByteDance가 **Lynx** 를 오픈소스로 풀었다. 사내에서 TikTok·Lark·Douyin 같은 거대 앱이 쓰던 크로스 플랫폼 프레임워크다. 의미는 크다.

왜 새 프레임워크인가

RN과 Flutter가 있는데 왜? ByteDance의 공식 설명을 거칠게 옮기면.

- **메인 스레드 보호** — TikTok 같은 무한 스크롤·짧은 영상 앱에서 첫 프레임 동기 렌더가 핵심이다. RN의 Fabric도 좋지만 더 공격적으로 메인 스레드를 비우고 싶었다.

- **듀얼 스레드 모델** — Main thread(UI 동기 렌더)와 Background thread(JS 로직)를 분리. 첫 프레임이 동기로 그려진다.

- **PrimJS** — Lynx 전용 JS 엔진(QuickJS 기반 포크). Hermes와 비슷한 AOT 바이트코드 접근.

Lynx 한 줄 코드

export default function App() {

return (

)

}

표면적으로는 RN과 거의 비슷한 JSX·컴포넌트 모델. 차이는 내부에 있다.

무엇이 다른가

- **첫 프레임 동기** — `\<List\>`가 처음 그릴 때 메인 스레드에서 동기로 레이아웃·페인트.

- **Atomic CSS** — Tailwind 비슷한 atomic CSS가 1급 시민. 빌드 시 사전 처리.

- **Rust 코어** — 일부 critical path가 Rust로 다시 짜여졌다.

누구를 위한 도구인가

ByteDance가 자기 앱(TikTok급)을 위해 만들었다. 그 말은 **거대 트래픽 + 무한 스크롤 + 짧은 영상** 에 특화돼 있다는 뜻이다. 일반 SaaS·이커머스·생산성 앱은 RN/Flutter가 여전히 안전한 선택이다.

오픈소스화의 진짜 의미는 **"RN/Flutter가 못 따라가는 케이스가 있다"** 는 공개 인정과, **TikTok급 노하우의 외부 유출**이다. 2026년 후반~2027년에 누가 따라가는지가 관전 포인트.

10장 · .NET MAUI / NativeScript — 그 외 옵션

다섯 강자 외에 두 옵션이 자기 자리를 지킨다.

.NET MAUI — 마이크로소프트의 답

Xamarin.Forms의 후계. C# + XAML로 iOS·Android·Windows·macOS 한 코드로.

<!-- MainPage.xaml -->

- 강점 — Visual Studio 통합, .NET 진영 라이브러리 그대로, 엔터프라이즈 SSO·Active Directory가 한 줄.

- 약점 — 모바일 first 디자인이 아니고 Xamarin 유산이 남아있다. 커뮤니티 활성도가 RN/Flutter보다 낮다.

NativeScript — 살아있다

Telerik 시절부터 살아남았다. TypeScript/Vue/Svelte/Angular로 진짜 네이티브 UI(UIView·View) 를 직접 다룬다.

- 강점 — JS에서 iOS·Android API를 거의 그대로 호출(브리지 코드 없이).

- 약점 — 커뮤니티가 작다. RN의 New Architecture 이후 차별점이 흐려졌다.

2026년 5월 현재 NativeScript는 **"RN 이전 시대의 향수"** 가 더 큰 이유로 쓰인다. 신규 프로젝트라면 RN/Flutter/KMP가 먼저 고려된다.

11장 · 어떤 프레임워크를 골라야 하나 — 의사결정 표

다섯 강자 + 두 옵션을 팀·제품·디자인·번들사이즈로 줄세운다.

팀 기준

| 팀 배경 | 1순위 | 2순위 | 메모 |

| --- | --- | --- | --- |

| 웹(React/TS) | React Native + Expo | Capacitor 7 | RN 학습 곡선이 가장 낮다 |

| 웹(Vue/Svelte) | Capacitor 7 | Tauri 2 Mobile | RN의 React 의존이 거슬리면 |

| Kotlin/Android | KMP + Compose Multiplatform | Flutter | iOS 점진 도입 가능 |

| iOS 위주 | KMP (logic만) | React Native | SwiftUI는 그대로 유지 |

| Dart/모바일 first | Flutter | Compose Multiplatform | 픽셀 일관성 우선 |

| C#/.NET | .NET MAUI | React Native | 엔터프라이즈 |

제품 기준

| 제품 종류 | 추천 | 이유 |

| --- | --- | --- |

| 콘텐츠·피드 앱(TikTok급) | Lynx 또는 RN | 메인 스레드 보호 |

| 게임·미디어 인터랙티브 | Flutter | 픽셀 단위 60fps |

| 핀테크·은행 | RN (Expo) 또는 KMP | 큰 생태계, 보안 라이브러리 |

| 이커머스 | RN (Expo) | 빠른 출시, 광고 SDK 호환 |

| 사내 LOB 앱 | Capacitor 7 | 빠른 배포, 낮은 비용 |

| prosumer 도구 | Tauri 2 Mobile | 번들 작고 보안 |

디자인 기준

| 디자인 방향 | 추천 |

| --- | --- |

| OS 표준 룩앤필 강조 | RN, KMP(SwiftUI/Compose 따로) |

| 브랜드 픽셀 퍼펙트 | Flutter, Compose Multiplatform |

| 웹 디자인을 그대로 | Capacitor, Tauri Mobile |

번들 사이즈

| 프레임워크 | iOS 빈 앱 | Android 빈 앱 |

| --- | --- | --- |

| Tauri 2 Mobile | 약 8MB | 약 6MB |

| Capacitor 7 | 약 10MB | 약 8MB |

| KMP(logic 공유) | 약 12MB | 약 7MB |

| React Native + Expo | 약 15MB | 약 13MB |

| Flutter | 약 17MB | 약 14MB |

| Compose Multiplatform | 약 18MB | 약 9MB |

번들 사이즈는 **빈 앱** 기준이다. 실제 앱은 이미지·폰트·라이브러리로 두세 배 커진다. 100MB 이상이면 App Store cellular download 제한에 걸려 4G/5G에서 자동 다운로드가 안 된다.

12장 · 한국·일본 모바일 생태계 — 실제로 뭘 쓰나

이론 표는 의사결정의 출발선이고, 현실은 다르다. 한국·일본의 큰 회사들이 2026년 5월 시점에 실제 뭘 쓰는지 정리한다(공개된 채용공고·기술블로그·컨퍼런스 발표 기준).

한국

- **카카오** — Android는 Kotlin + Jetpack Compose, iOS는 Swift + SwiftUI. 일부 사내 도구·신규 서비스에 **KMP(logic 공유)** 도입 사례가 늘고 있다. RN은 사내 도구·이벤트성 미니앱.

- **네이버** — 같은 방향. 핵심 앱은 네이티브(Swift/Kotlin), 검증 단계 서비스에 RN/Flutter 채용공고가 나온다.

- **쿠팡** — RN 채택이 가장 적극적. 일부 검색·리스트 화면이 RN으로 알려져 있다. Hermes 위에서 동작.

- **토스** — iOS Swift + Android Kotlin이 메인. 일부 사내·운영 도구가 RN.

- **당근(당근마켓)** — Flutter 도입이 가장 눈에 띈다. 일부 서비스(중고 + 동네생활)에 Flutter 사용.

- **배달의민족(우아한형제들)** — 네이티브 위주. 일부 신규 실험에 Flutter.

일본

- **메루카리(Mercari)** — Android에서 KMP 도입 사례를 컨퍼런스에서 여러 번 공유. iOS는 Swift, Android는 Kotlin이 메인, 공유 비즈니스 로직만 KMP.

- **CyberAgent** — 자회사가 많아 스택이 다양. **AbemaTV 는 RN/Flutter 이력 없이 네이티브**. 일부 자회사는 Flutter.

- **DeNA** — 게임·엔터테인먼트는 Unity/네이티브. 일반 앱은 Swift + Kotlin.

- **LINE Yahoo Japan** — LINE 앱 자체는 네이티브. 일부 미니 앱·캠페인 페이지에 웹뷰.

- **PayPay** — 네이티브 위주. RN/Flutter 흔적은 적다.

- **freee / SmartHR / Money Forward** — SaaS 진영. 모바일 앱은 RN/Flutter 혼재, 신규 프로젝트에 Flutter 채택이 늘고 있다.

두 시장의 공통 패턴

- **핵심 앱은 여전히 네이티브** — 슈퍼앱 격(카카오톡·LINE·페이코) 은 거의 다 Swift + Kotlin.

- **신규·실험 서비스에 RN/Flutter** — 신규 도메인, 미니 앱, 사내 도구.

- **KMP가 조용히 늘고 있다** — UI까지 가지 않고 비즈니스 로직 공유로 시작하는 패턴. 메루카리·카카오 사례가 대표.

- **Compose Multiplatform 도입은 아직 보수적** — iOS stable이 2026년 1분기라 본격 채택은 2026년 하반기~2027년에 보일 듯.

시사점

큰 회사는 **"리스크 < 코드 공유 이득"** 일 때만 크로스 플랫폼을 쓴다. 핵심 사용자 경험이 걸린 앱은 네이티브를 유지하고, **새로운 기능·실험·내부 도구**에서 크로스 플랫폼을 검증한다. KMP의 logic-only 공유가 그 검증 진입점으로 가장 안전하다.

마무리 — 체크리스트와 안티패턴

의사결정 체크리스트

1. 팀의 주력 언어는 무엇인가? (TS / Dart / Kotlin / Swift / C#)

2. UI 기준이 OS 표준인가, 브랜드 픽셀 퍼펙트인가?

3. 핵심 화면이 60fps 동영상·복잡 애니메이션인가, 폼·리스트 위주인가?

4. 번들 크기 상한이 있는가? (App Store cellular 200MB)

5. App Store/Play Store 리뷰 속도 vs OTA 업데이트 비중은?

6. 기존 웹 자산이 있는가? (Capacitor/Tauri의 가치)

7. 보안 요구는? (Tauri의 Rust 백엔드, 또는 RN의 보안 라이브러리)

8. 5년 후 코드 유지 보수자는 누구인가?

안티패턴 10가지

1. RN 0.76 이상에서 **New Architecture 끄고** 운영(불필요한 비대칭).

2. Expo로 시작해 놓고 **eject** 후 후회.

3. Flutter로 **iOS 네이티브 룩앤필 흉내** 내려고 시간 낭비.

4. KMP의 **UI 공유**를 안정 stable 전(2025년 이전)에 프로덕션 도입한 사례 답습.

5. Capacitor 위에 60fps 게임 애니메이션을 욱여넣음.

6. Tauri Mobile을 **TikTok급 소비자 앱**에 적용 시도.

7. Lynx를 **사내 도구** 같은 작은 앱에 도입(과한 도구).

8. JS 엔진을 **JSC로 고정**한 채 Hermes 마이그레이션 안 함.

9. EAS Update를 **주요 UI 전면 개편**에 사용해 App Store 가이드 위반 위험.

10. .NET MAUI를 **모바일 first 디자인** 앱에 골라 놓고 데스크톱 패턴 강요.

다음 글 예고

다음 글 후보: **React Native New Architecture 마이그레이션 실전 — 0.74→0.76 단계별 가이드**, **KMP logic-only 공유로 SwiftUI/Compose 둘 다 살리기**, **Flutter Impeller 셰이더 디버깅 — 잰크 잡는 법**.

> "크로스 플랫폼은 한 코드로 두 OS를 동시에 만드는 마법이 아니라, 어느 비용을 어디로 옮기느냐의 협상이다."

— 크로스 플랫폼 모바일 개발 2026, 끝.

참고 / References

- [React Native 공식](https://reactnative.dev/)

- [React Native 0.76 New Architecture 블로그](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)

- [Hermes 엔진](https://hermesengine.dev/)

- [Expo 공식](https://expo.dev/)

- [Expo SDK 52 릴리스 노트](https://expo.dev/changelog)

- [Expo Router 문서](https://docs.expo.dev/router/introduction/)

- [EAS Build 문서](https://docs.expo.dev/build/introduction/)

- [Flutter 공식](https://flutter.dev/)

- [Flutter Impeller 렌더러](https://docs.flutter.dev/perf/impeller)

- [Material You 3 가이드](https://m3.material.io/)

- [Kotlin Multiplatform 공식](https://kotlinlang.org/docs/multiplatform.html)

- [Compose Multiplatform 공식](https://www.jetbrains.com/compose-multiplatform/)

- [Tauri 공식](https://tauri.app/)

- [Tauri 2 Mobile 가이드](https://v2.tauri.app/start/prerequisites/#mobile)

- [Capacitor 공식](https://capacitorjs.com/)

- [Ionic Framework](https://ionicframework.com/)

- [Lynx 공식 사이트](https://lynxjs.org/)

- [Lynx GitHub](https://github.com/lynx-family/lynx)

- [.NET MAUI 공식](https://dotnet.microsoft.com/apps/maui)

- [NativeScript 공식](https://nativescript.org/)

- [메루카리 엔지니어링 블로그(KMP 사례)](https://engineering.mercari.com/en/blog/)

- [카카오 기술 블로그](https://tech.kakao.com/)