Flutter, React Native, Kotlin, Swift 중 “무엇이 가장 좋은가”라는 질문에는 제품 조건이 빠져 있습니다. Android만 필요한지, iOS까지 동시에 내야 하는지, BLE·백그라운드·HealthKit 같은 플랫폼 기능이 핵심인지, 팀이 이미 React·TypeScript나 Dart를 다루는지에 따라 먼저 검증할 후보가 달라집니다.
이 글에서는 인기나 막연한 생산성 대신 네 가지 제약을 입력으로 받는 짧은 판정 규칙을 만들었습니다. 2026년 9월 25일 Windows 10과 Dart SDK 3.13.4에서 8개 조건 조합을 실행하고 기대 조건 10개를 검사했습니다. 이 결과는 프레임워크 성능 순위가 아니라, 후보를 줄이고 다음 실험을 정하기 위한 편집용 의사결정 도구입니다.
8개 제품 가정을 실행 가능한 입력으로 바꿨다
각 사례는 배포 대상, 네이티브 기능 깊이, 현재 보유 기술, 공통 모바일 코드 요구, Mac 사용 가능 여부를 입력으로 받습니다. 출력은 한 개의 정답이 아니라 먼저 확인할 후보 목록, 현재 차단 조건, 실제로 증명해야 할 과제입니다.
{
target: mobileBoth,
nativeDepth: ordinary,
skill: reactTypeScript,
sharedMobileCodeRequired: true,
macAvailable: false
}
shortlist: [react_native, flutter]
blocker: no_local_macos_xcode_path_for_ios_build_and_signing
proof: build Android release + build/sign/run iOS on macOS/Xcode| 실행한 조건 | 먼저 남은 후보 | 필수 검증 |
|---|---|---|
| URL로 사용자 반응부터 확인 | 반응형 웹·PWA | 대상 기기의 설치·오프라인·푸시·로그인 복귀 |
| Android 전용, BLE·백그라운드가 핵심 | Kotlin·Compose | 실기기 release 빌드와 핵심 기능 한 개 |
| iOS 전용, HealthKit 같은 Apple 기능이 핵심 | Swift·SwiftUI | Mac·Xcode에서 서명 후 실기기 실행 |
| Android·iOS, React·TypeScript 팀 | React Native → Flutter | 공유 UI와 플랫폼별 경계 측정 |
| Android·iOS, Dart 팀 | Flutter → React Native | 공유 UI와 플랫폼별 경계 측정 |
| Android·iOS, 기존 기술 없음 | Flutter와 React Native 모두 유지 | 같은 핵심 흐름을 두 후보로 짧게 구현 |
| 양쪽 플랫폼 기능이 깊고 UI 분리 허용 | Kotlin + Swift 네이티브 | 두 코드베이스 운영 비용과 릴리스 일정 |
| Android·iOS 필요, Mac 경로 없음 | 후보는 유지하되 결정 보류 | iOS 빌드·서명 경로를 먼저 확보 |
테스트는 웹 우선 조건이 웹·PWA를 남기는지, 깊은 Android 기능이 Kotlin을 먼저 두는지, 깊은 iOS 기능이 Swift를 먼저 두는지, React 팀과 Dart 팀의 첫 후보가 달라지는지 등을 확인했습니다. Mac이 없는 양쪽 모바일 사례에는 iOS 빌드 차단 조건이 반드시 기록되는지도 검사했습니다. 10개 조건은 모두 통과했고 analyzer 종료 코드와 실행 종료 코드는 0이었습니다.
iOS 빌드 경로는 언어 취향보다 앞선다
Flutter로 iOS 앱을 작성해도 App Store용 빌드와 릴리스에는 Xcode와 macOS 장치가 필요합니다. React Native의 네이티브 로컬 환경도 iOS에는 Xcode가 포함됩니다. SwiftUI 역시 Xcode 프로젝트에서 개발·테스트·배포합니다. 따라서 Windows에서 코드를 시작할 수 있는지와 iOS 산출물을 서명해 실기기·TestFlight에서 확인할 수 있는지는 다른 질문입니다.
Mac이 지금 없다고 Flutter나 React Native를 곧바로 제외하지는 않았습니다. 대신 후보 목록과 별개로 iOS 빌드·서명 경로 없음을 차단 조건으로 반환했습니다. 원격 Mac이나 CI 서비스를 사용할 계획이라면 비용, 인증서·프로비저닝 관리, 실패 로그 접근, 실제 기기 확인 담당자를 선택 전에 문서화합니다. 이 경로를 확인하지 않은 채 UI 예제만 만든 결과는 “양쪽 플랫폼 출시 가능”의 증거가 아닙니다.
플랫폼 기능이 핵심이면 플러그인 이름이 아니라 실패 경로를 시험한다
Flutter와 React Native는 공통 코드가 가능한 범위를 넓혀 주지만 모든 플랫폼 기능을 같은 코드로 없애 주지는 않습니다. Flutter 공식 문서도 필요한 기능을 플러그인에서 찾지 못하면 플랫폼별 코드를 작성하거나 플러그인을 만들 수 있다고 안내합니다. React Native도 JavaScript 코드에서 Swift·Objective-C·Java·Kotlin·C++ 구현을 연결하는 Native Module과 Native Component 경계를 제공합니다.
그래서 BLE 스캔, 백그라운드 위치, 알림 action, HealthKit, 결제처럼 제품의 생존을 좌우하는 기능은 패키지 다운로드 수만 보고 고르지 않습니다. 후보마다 아래 한 흐름을 release 또는 profile 성격의 빌드로 끝까지 통과시킵니다.
- 실제 대상 OS 버전의 물리 기기에서 권한을 처음 거부한 뒤 다시 허용한다.
- 앱이 백그라운드·종료 상태가 됐을 때 원하는 동작과 OS 제한을 기록한다.
- 플러그인 소유자, 최근 호환 버전, 네이티브 코드 수정 지점을 확인한다.
- 업그레이드가 끊겼을 때 직접 유지할 범위와 대체 경로를 적는다.
여기까지 통과해야 “공통 코드가 가능하다”는 장점과 네이티브 경계 유지 비용을 같은 표에서 비교할 수 있습니다.
조건별로 후보를 줄이는 실제 순서
URL 배포와 빠른 검증이 우선일 때
설치 전에 수요와 업무 흐름을 확인하는 것이 목표라면 반응형 웹이나 PWA가 첫 후보입니다. 다만 PWA라는 이름만으로 네이티브 앱과 기능이 같아지지는 않습니다. 대상 브라우저에서 푸시, 파일 선택, 카메라, 오프라인, 홈 화면 설치, 외부 로그인 복귀가 요구사항대로 되는지 각각 확인합니다. 더 구체적인 경계는 웹앱으로 시작할 때의 장점과 한계에서 이어서 점검할 수 있습니다.
Android 한 플랫폼과 깊은 기능이 중심일 때
Android만 배포하고 플랫폼 API가 핵심이면 Kotlin과 Jetpack Compose를 먼저 검토합니다. Android 공식 문서는 새 Android 개발을 Kotlin으로 시작하도록 권장하고 Compose를 네이티브 UI의 현대적 권장 도구로 설명합니다. 이것은 모든 Android 앱이 무조건 네이티브여야 한다는 뜻은 아닙니다. 화면 위주 앱이고 팀이 Dart나 React를 이미 운영한다면 Flutter·React Native 후보를 함께 두고 핵심 네이티브 흐름으로 비교합니다.
iPhone 한 플랫폼과 Apple 기능이 중심일 때
iOS 단독이며 Apple API와 플랫폼 마감이 제품 중심이면 Swift·SwiftUI를 먼저 확인합니다. Xcode는 Apple 플랫폼 앱의 빌드·테스트·배포를 맡는 도구입니다. 실제 결정은 Swift 문법 예제보다 서명, entitlements, 실제 기기 권한, App Store 제출 흐름까지 한 번 통과한 결과로 내립니다.
Android와 iOS를 함께 낼 때
React·TypeScript 경험이 있으면 React Native, Dart 경험이 있으면 Flutter를 첫 후보로 배치했습니다. 경험이 없다면 둘을 모두 남겨 같은 작은 기능으로 비교합니다. 후보를 설치하는 절차는 Windows Flutter 설치와 doctor 점검과 Flutter 첫 Android 빌드 로드맵처럼 환경 검증을 포함해야 합니다.
두 플랫폼 모두 깊은 네이티브 기능이 많고 UI를 따로 운영할 인력·일정이 있다면 Kotlin과 Swift 두 구현도 비교 후보입니다. 반대로 공통 코드가 사업상 필수면 Flutter·React Native를 유지하되 네이티브 bridge를 누가 책임질지 먼저 정합니다.
이 컴퓨터의 PATH 검사는 선택 결과가 아니다
작업 당일 같은 Windows 셸에서 where.exe로 도구를 확인했습니다. Node.js는 PATH에서 발견됐고 로컬 Dart SDK 3.13.4는 명시 경로로 실행했습니다. flutter, java, javac, kotlinc, swift, xcodebuild, adb는 PATH에서 찾지 못했습니다.
이 결과는 현재 셸이 곧바로 모바일 앱 전체를 빌드할 준비가 되지 않았다는 증거일 뿐, 컴퓨터 전체에 해당 도구가 없거나 특정 기술을 선택할 수 없다는 증거가 아닙니다. 특히 Windows에서 xcodebuild가 없다는 관찰은 iOS 빌드 환경 요구사항과 일치하지만, 다른 Mac·CI 경로의 존재 여부까지 판단하지 않습니다. 실제 Flutter·React Native·Android·iOS 앱은 이번 실행에서 컴파일하지 않았습니다.
이틀짜리 기술 검증의 합격 기준
| 검증 항목 | 남길 증거 | 탈락 또는 보류 조건 |
|---|---|---|
| 환경 재현 | 설치 명령, SDK 버전, doctor·build 출력 | 다른 개발자 환경에서 재현 불가 |
| 핵심 기능 한 개 | 실기기 화면과 권한·오류 로그 | 필수 OS 상태에서 실패하고 우회책 없음 |
| release 산출물 | Android release와 iOS 서명 빌드 결과 | 디버그에서만 동작 |
| 플랫폼 경계 | 공유 파일과 Android·iOS 전용 파일 목록 | 핵심 흐름 대부분을 별도 구현해야 함 |
| 업그레이드 책임 | 필수 패키지·플러그인·네이티브 코드 소유자 | 중단 시 유지할 사람이 없음 |
| 접근성·오류 처리 | 스크린리더, 큰 글자, 오프라인·재시도 결과 | 제품 필수 기준을 충족하지 못함 |
기술 후보를 고른 뒤에는 기능 성공만 기록하지 말고 실패 조건과 복구 정책까지 남깁니다. 출시 직전의 상태·동시성·재시도 검증 방식은 앱 출시 전 상태·동시성·오류 흐름 점검에서 실제 테스트 예제로 확인할 수 있습니다.
이번 판정이 증명하지 않은 것
- 8개 사례는 조건을 명확히 보여 주기 위한 편집 규칙이며 산업 전체의 객관적 순위가 아닙니다.
- Flutter·React Native·Kotlin·Swift 앱을 같은 기능으로 작성하거나 성능을 측정하지 않았습니다.
- 패키지 생태계, 접근성, 앱 크기, 메모리, 프레임 시간, 스토어 심사 결과를 비교하지 않았습니다.
- 팀 경험은 첫 후보 순서에만 반영했습니다. 제품의 필수 플랫폼 기능이 실패하면 익숙한 기술이라도 탈락할 수 있습니다.
- 공식 문서의 지원 범위와 도구 버전은 변할 수 있으므로 실제 검증을 시작하는 날 다시 확인해야 합니다.