React Native와 Flutter 사이에서 고민 중인가요? 다트(Dart) 언어의 매력부터 스키아(Skia) 엔진을 통한 네이티브급 성능, 그리고 선언형 UI(Declarative UI)의 철학까지. 왜 수많은 기업들이 플러터로 넘어가고 있는지, 그 기술적 배경과 장단점을 심층 분석합니다.
로그인 화면을 만들었는데 키보드가 올라오니 노란 줄무늬 에러가 뜹니다. 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 둘 다 지원해야 했습니다.
견적을 알아봤습니다.
"아이폰 앱 개발자 1명, 안드로이드 앱 개발자 1명... 최소 월 1,000만 원은 깨지겠네."
절망적이었습니다. 하이브리드 앱(웹뷰 방식)을 알아봤지만, 조악한 성능과 "웹 냄새"나는 UI 때문에 탈락. 그때 우연히 구글이 만든 Flutter(플러터)를 알게 되었습니다.
"하나의 코드로 iOS와 Android를 다 만든다고? 성능이 네이티브 급이라고? 에이, 설마."
반신반의하며 튜토리얼을 따라 해 봤습니다. 그리고 30분 만에 저는 무릎을 쳤습니다. "이거다. 이걸로 하면 나 혼자서도 다 할 수 있겠다."
결과적으로 저는 단 2주 만에 아이폰과 안드로이드 앱을 런칭했고, 투자자 미팅에서 당당하게 데모를 시연할 수 있었습니다. 오늘은 제가 왜 플러터에 반했는지, 그리고 왜 여러분도 플러터를 선택해야 하는지 이야기해 보려 합니다.
React Native를 써봤던 친구가 플러터를 보더니 깜짝 놀랍니다.
"야, 이거 왜 이렇게 부드러워? 네이티브 아니야?"
비밀은 Skia (또는 Impeller)라는 그래픽 엔진에 있습니다.
기존의 크로스 플랫폼들은 OS의 부품(OEM Widget)을 빌려서 썼습니다.
리액트 네이티브에서 <View>를 그리면, 아이폰에서는 UIView를, 안드로이드에서는 android.view.View를 호출하는 식이죠. 그래서 OS 버전마다 디자인이 미묘하게 다르고, 브릿지(Bridge)를 통신하느라 느립니다.
하지만 플러터는 OS의 부품을 전혀 쓰지 않습니다. 대신 게임 엔진처럼 화면의 모든 픽셀을 직접 그립니다.
버튼, 텍스트, 스크롤바까지 전부 플러터가 직접 픽셀 단위로 렌더링합니다. 덕분에 아이폰 15 Pro에서 보든 5년 된 갤럭시 보급형에서 보든 100% 똑같은 디자인이 나옵니다. 디자이너가 "안드로이드에서 폰트 간격이 이상해요"라고 불평할 일이 사라졌습니다. 이 Pixel Perfection이 주는 통제감이 정말 짜릿합니다.
플러터를 처음 배우면 조금 당황스럽습니다.
화면 가운데 정렬을 하고 싶은데, CSS의 text-align: center 같은 속성이 없습니다.
대신 Center라는 위젯으로 감싸야합니다.
"아니, 정렬조차 위젯이라고?"
네, 플러터의 철학은 "모든 것이 위젯이다"입니다.
Text)도 위젯Padding)도 위젯Center)도 위젯GestureDetector)도 위젯처음엔 귀찮았지만, 익숙해지니 레고 블록을 조립하는 기분이 들었습니다. 위젯 안에 위젯을 넣고, 또 그 안에 위젯을 넣습니다. 이 구조를 Widget Tree라고 부릅니다.
return Center(
child: Container(
color: Colors.blue,
child: Text('Hello World'),
),
);
이 방식은 선언형 UI (Declarative UI)의 끝판왕입니다. "어떻게 그려라" 명령하지 않고, "이런 모습이어야 한다"고 선언만 하면 됩니다. 덕분에 UI 코드가 굉장히 직관적이고 재사용하기 쉬워졌습니다.
앱 개발자들의 고충 1순위는 기나긴 빌드 시간입니다. 글자 색 하나 바꾸고 확인하려면 빌드 -> 설치 -> 실행까지 1~2분을 기다려야 했습니다. 하루에 50번 수정하면 100분을 날리는 셈이죠.
하지만 플러터의 Hot Reload (핫 리로드)는 마법입니다. 코드를 수정하고 저장(Ctrl+S)을 누르면, 0.5초 만에 화면이 바뀝니다. 더 놀라운 건 앱의 상태(State)가 유지된다는 겁니다.
예를 들어 회원가입 양식의 3번째 페이지를 테스트하고 있다고 칩시다. 입력창 디자인을 고치고 저장하면, 앱이 처음부터 다시 시작되는 게 아니라 입력했던 내용 그대로 3번째 페이지에 머문 채 디자인만 바뀝니다.
이건 단순한 시간 단축이 아닙니다. 개발의 리듬을 끊지 않게 해 줍니다. "수정 -> 확인"의 피드백 루프가 1초 미만으로 줄어드니, 개발이 아니라 디자인 툴로 그림을 그리는 느낌까지 듭니다. 저는 이 기능 덕분에 혼자서 2명의 몫을 할 수 있었습니다.
"근데 Dart 언어 또 배워야 하잖아요..."
저도 처음엔 그랬습니다. 자바스크립트나 파이썬이면 좋을 텐데 왜 하필 듣도 보도 못한 Dart일까? 하지만 써보니 구글의 큰 그림이 있었습니다.
Dart는 두 가지 얼굴을 가진 야누스 같은 언어입니다.
그리고 문법이 정말 쉽습니다. 자바(Java)와 자바스크립트(JS)를 섞어놓은 느낌이라, 개발자라면 하루면 적응합니다. 특히 강력한 타입 시스템(Type System)과 Null Safety 덕분에, 런타임 에러가 확 줄어들었습니다.
플러터를 하다 보면 한 번쯤 벽에 부딪히는 순간이 옵니다. 바로 상태 관리(State Management)입니다. 플러터는 UI를 그리는 도구일 뿐, 데이터를 어떻게 관리할지는 정해주지 않았습니다. 그래서 수많은 라이브러리들이 경쟁하고 있습니다.
저는 처음에 GetX로 시작해서 빠르게 MVP를 만들었고, 서비스가 커진 지금은 Riverpod로 리팩토링 중입니다. 정답은 없습니다. 팀의 상황에 맞는 걸 고르면 됩니다.
가끔 개발자 커뮤니티에서 "플러터 vs 리액트 네이티브" 논쟁을 봅니다. 하지만 창업자인 제 입장에서 결론은 명확합니다.
"가장 적은 리소스로, 가장 빠르게, 가장 퀄리티 높은 앱을 만들고 싶다면 플러터다."
물론 리액트 네이티브도 훌륭하고, 네이티브(Swift/Kotlin)가 꼭 필요한 영역도 있습니다. 하지만 스타트업의 목표가 "빠른 시장 검증"이라면 플러터 이상의 도구는 없다고 확신합니다.
지금 당장 공식 문서의 "Get Started"를 눌러보세요. 이번 주말이면 여러분의 첫 앱이 내 폰에서 돌아가고 있을 겁니다.