창업 초기, iOS와 Android 앱을 모두 만들어야 했을 때 저는 과감하게 Native(Swift/Kotlin)를 버리고 Flutter를 선택했습니다. 개발 속도 2배, 비용 절감 50%의 효과를 본 경험과, 크로스 플랫폼 개발의 현실적인 장단점을 '스타트업 생존' 관점에서 공유합니다.
로그인 화면을 만들었는데 키보드가 올라오니 노란 줄무늬 에러가 뜹니다. resizeToAvoidBottomInset부터 스크롤 뷰, 그리고 채팅 앱을 위한 reverse 팁까지, 키보드 대응의 모든 것을 정리해봤습니다.
안드로이드는 오는데 iOS는 조용합니다. 혹은 앱이 켜져 있을 때만 옵니다. Background/Terminated 상태 처리, APNs 인증서, 그리고 Notification Channel 설정까지 완벽하게 해결합니다.
안드로이드는 Xcode보다 낫다고요? Gradle 지옥에 빠져보면 그 말이 쏙 들어갈 겁니다. minSdkVersion 충돌, Multidex 에러, Namespace 변경(Gradle 8.0), JDK 버전 문제, 그리고 의존성 트리 분석까지 완벽하게 해결해 봅니다.
Debug에선 잘 되는데 Release에서만 죽나요? 범인은 '난독화'입니다. R8의 원리, Mapping 파일 분석, 그리고 Reflection을 사용하는 라이브러리를 지켜내는 방법(@Keep)을 정리해봤습니다.
창업 초기, 나와 프리랜서 한 명이 전부였습니다. 통장 잔고는 매달 말라가고 있었고, 투자자들은 "빨리 앱 런칭해서 지표를 가져오라"고 조르고 있었습니다. 그런데 서비스는 iOS와 Android 앱이 모두 필요했죠.
기술 스택을 결정해야 하는 순간, 선택지는 두 가지였습니다.
개발자로서의 욕심은 당연히 Native였습니다. "앱은 손맛이지! 애니메이션 60프레임 칼같이 나와야지! 플랫폼 가이드라인 딱 맞춰야지!"
하지만 대표로서의 이성은 Cross-Platform을 가리키고 있었습니다. "우리 지금 망하기 일보 직전인데, 언제 Swift 공부하고 Kotlin 공부할래? 개발자 뽑을 돈은 있고?"
결국 눈물을 머금고 Flutter를 선택했습니다. 개발자로서의 자존심을 버리고, 창업가로서의 생존을 선택한 것입니다. 그리고 1년 뒤, 이 선택은 우리 회사를 살린 신의 한 수가 되었습니다.
Flutter를 쓰면서 가장 충격받은 건 Hot Reload(핫 리로드)였습니다. 과장이 아니라, 이건 앱 개발의 역사를 바꾼 기능입니다.
코드를 수정하고 저장(Cmd+S)하면, 0.5초 만에 앱 화면이 바뀝니다. 앱을 다시 빌드하거나 재시작할 필요가 없습니다. 상태(State)도 유지됩니다.
이 속도 차이는 단순한 시간 절약이 아닙니다. 개발자의 몰입(Flow)을 끊지 않는다는 게 핵심입니다. 하루에 수정하고 테스트할 수 있는 UI 횟수가 10배는 차이 났습니다. 덕분에 우리는 2명이서 2달은 걸릴법한 작업을 3주 만에 끝내고 MVP를 출시할 수 있었습니다.
가장 걱정했던 건 UX의 이질감이었습니다. 옛날 하이브리드 앱(웹뷰 껍데기, Ionic, PhoneGap 등)을 써본 분들은 아실 겁니다. 그 특유의 버벅거림과 "웹사이트 같은 느낌". 버튼을 눌렀는데 반응이 반박자 늦는 그 불쾌한 골짜기 말이죠.
하지만 Flutter는 달랐습니다.
기존의 크로스 플랫폼(React Native 등)은 자바스크립트로 로직을 짜면, 그걸 네이티브 컴포넌트(iOS의 UIButton, Android의 Button)로 변환해서 보여주는 방식(Bridge)이었습니다. 그래서 가끔 통신 병목이 생기면 느려졌죠.
반면 Flutter는 운영체제의 UI 컴포넌트를 아예 안 씁니다. 대신 Skia라는 C++ 그래픽 엔진을 내장해서, 화면의 픽셀 하나하나를 직접 그립니다. 마치 유니티(Unity) 게임 엔진으로 게임을 만드는 것과 똑같은 원리입니다.
그래서 다음과 같은 장점이 생깁니다.
물론 100% 네이티브 같진 않았습니다. 스크롤 감도나 내비게이션 전환 효과가 미세하게 달랐죠. 하지만 일반 사용자의 99%는 눈치채지 못했습니다. 오직 개발자들만 "어? 이 스크롤 관성이 iOS 순정보다 0.1초 긴데?" 하고 시비 걸 뿐이었죠. 사용자는 그냥 "앱이 예쁘네" 하고 씁니다.
물론 꽃길만 있진 않았습니다. 크로스 플랫폼의 한계는 명확했습니다.
지도, 카메라, 블루투스 같은 하드웨어 기능을 깊게 써야 할 때 지옥이 시작됩니다. 네이버 지도 SDK가 네이티브(iOS/Android) 버전은 기능이 100개라면, Flutter 플러그인은 기능이 50개밖에 없었습니다. 심지어 버그도 많았죠.
결국 Flutter 코드 안에서 Platform Channel이라는 구멍을 뚫고, Java와 Swift 코드를 직접 짜서 연결해야 했습니다. "아니, Swift 안 하려고 Flutter 썼는데, 결국 Swift를 짜고 있잖아?" 하는 자괴감이 들었죠.
Flutter는 Dart라는 언어를 씁니다. 구글이 만들었지만, 솔직히 메이저 언어는 아닙니다. 채용 공고를 올리면 지원자가 많지 않습니다. "저 자바밖에 못 하는데요", "저 자바스크립트밖에 못 하는데요" 하는 분들이 대부분입니다. 반면 React Native는 "저 리액트 할 줄 아니까 RN도 할게요" 하는 웹 개발자들이 넘쳐나죠.
하지만 반전이 있습니다. Dart는 배우기 정말 쉽습니다. 자바나 자바스크립트를 아는 개발자라면, 주말 이틀만 공부하면 월요일부터 코드를 짤 수 있습니다. 우리는 그냥 "언어 상관없음, 러닝 커브 빠른 분"을 뽑아서 가르치는 전략을 썼습니다.
이 질문도 많이 받습니다. 제 기준은 이렇습니다.
저는 개인적으로 Flutter의 개발 경험(DX)이 훨씬 좋았습니다. RN은 의존성 라이브러리 버전 맞추다가 하루가 다 가는데, Flutter는 구글이 "이거 하나면 돼" 하고 다 넣어준(Batteries Included) 느낌이라 안정적이거든요.
많은 개발팀이 네이티브를 고집하며 이런 핑계를 댑니다. "에어비앤비도 RN 쓰다가 네이티브로 돌아갔대요!", "페이스북(메타)도 네이티브 비중 늘린대요!"
하지만 뼈아픈 팩폭을 하나 하자면, 우리는 에어비앤비가 아닙니다. 돈과 인력이 넘쳐나고, 앱 성능 0.1초 개선에 수백억 가치가 왔다 갔다 하는 유니콘 기업의 전략을, 이제 막 시작하는 3명짜리 스타트업이 따라 하는 건 자살행위입니다.
스타트업의 목표는 "최고의 코드를 짜는 것"이 아니라, "망하기 전에 제품을 시장에 내놓는 것"입니다.
여러분의 앱이 성공할지 망할지도 모르는데, 벌써부터 "네이티브의 완벽한 퍼포먼스"를 걱정하지 마세요. "최고의 성능을 가진, 아무도 안 쓰는 앱"이 되고 싶지 않다면요. 일단 출시하세요. 그게 정답입니다.
Early in my startup, it was just me and a freelancer. Our bank account was drying up, and we were bootstrapping and running low on runway. Yet, we needed both iOS and Android apps to capture the market.
We stood at a crossroads with two choices:
As a developer, my heart desperately wanted Native. "Apps should feel premium! 60fps animations are mandatory! We must follow Human Interface Guidelines!"
But as a CEO, my rational brain pointed to Cross-Platform. "We are about to go bankrupt. Do you really have time to learn Swift AND Kotlin? Can we afford to hire two more experts?"
I swallowed my pride and chose Flutter. I chose survival over perfectionism. And a year later, that choice became the Best Decision Ever that saved our company.
The most shocking thing about Flutter was Hot Reload. This isn't an exaggeration; it changed the history of app development.
Modify code, hit Save (Cmd+S), and the screen updates in 0.5 seconds. No rebuilding. No restarting. The current state is preserved.
This speed difference isn't just about saving minutes. It's about maintaining Developer Flow. We could iterate on UI designs 10 times more per day. Thanks to this, we finished a 2-month workload in just 3 weeks with 2 people and launched our MVP.
My biggest worry was UX Dissonance. You know those old Hybrid Apps (Ionic, PhoneGap) that were just web pages wrapped in an app shell? The button clicks felt laggy, and it looked like a website pretending to be an app.
But Flutter was different.
Previous cross-platform frameworks (like React Native) used a Bridge to convert JavaScript logic into Native components (iOS UIButton, Android Button). This bridge often became a bottleneck causing frame drops.
Flutter doesn't use the OS's UI components. Instead, it uses a built-in C++ graphics engine called Skia to draw every pixel itself. It works exactly like a game engine (Unity).
This brings two massive benefits:
Of course, it wasn't 100% Native. Scroll physics and navigation transitions were slightly off. But 99% of users didn't notice. Only developers nitpicked, "Hey, the scroll inertia feels weird." Users just said, "The app looks pretty."
It wasn't all roses. The limitations of Cross-Platform were clear.
When integrating hardware-heavy features like Maps, Camera, or Bluetooth, hell begins. The Naver Map SDK (widely used in Korea) had 100 features for Native, but the Flutter plugin only had 50. And it was buggy.
I eventually had to dig a Platform Channel inside Flutter code and write Java/Swift code manually to bridge them. I felt defeated. "I chose Flutter to avoid Swift, yet here I am writing Swift..."
Flutter uses Dart. It's made by Google, but let's be honest, it's not a major language like Java or JS. When we posted job openings, few applied. "I only know Java," "I only know React." React Native has a huge pool of web developers, but Flutter doesn't.
But there's a twist. Dart is incredibly easy to learn. If you know Java or JS, you can learn it over a weekend and start coding on Monday. We adopted a strategy of hiring "Smart people who learn fast" regardless of language stack.
I get this question a lot. Here is my criteria:
Personally, Flutter's Developer Experience (DX) was superior. RN often breaks due to dependency hell (npm packages), but Flutter feels like a robust "Batteries Included" kit from Google.
Many teams insist on Native saying, "Airbnb switched back to Native!", "Facebook is moving back to Native!"
Here's a reality check: You are not Airbnb. Copying the strategy of a Unicorn with unlimited budget and talent is suicide for a 3-person startup. Their goal is micro-optimization; your goal is survival.
Startup's Goal: Not "Writing perfect code," but "Getting the product to market before cash runs out."
Don't worry about "Peak Performance" when you don't even know if your app will succeed. You don't want to build The Highest Performance App That No One Uses. Just launch it. That's the answer.
