네이티브 앱이 텍스트만 만나면 무너지는 이유

네이티브가 항상 최고일까요?

모바일 앱이나 데스크톱 앱을 만들 때 "네이티브로 가야 진짜다"라는 말, 많이 들어보셨을 거예요. iOS면 Swift/SwiftUI, 안드로이드면 Kotlin/Compose, 데스크톱이면 각 OS의 네이티브 UI 프레임워크를 쓰는 게 성능이나 사용자 경험 면에서 가장 좋다는 통념이죠. React Native나 Flutter 같은 크로스 플랫폼은 "빠르게 만들기엔 좋지만 진짜 디테일은 네이티브에 못 미친다"는 평을 받곤 합니다.

그런데 이번 글의 저자는 정반대 경험을 풀어놓습니다. 자기 앱을 처음부터 끝까지 네이티브로 만들었는데, 다른 부분은 다 만족스러웠지만 "텍스트"를 다루기 시작하자 갑자기 모든 게 어려워졌다는 거예요. 우리가 평소에 너무나 당연하게 여기는 글자 처리가, 알고 보면 네이티브 UI 프레임워크의 가장 약한 고리라는 이야기입니다.

텍스트 입력은 생각보다 괴물입니다

텍스트 입력이 뭐냐면, 그냥 키보드로 글자 치면 화면에 나오는 그거 맞아요. 하지만 그 단순해 보이는 동작 뒤에는 어마어마한 복잡성이 숨어 있어요. 한국어처럼 "ㄱ + ㅏ + ㅁ" 같은 자모를 조합해서 "감"이라는 한 글자를 만드는 IME(입력기) 처리부터 시작해서, 이모지처럼 여러 유니코드 코드포인트가 합쳐져 한 글자가 되는 경우, 오른쪽에서 왼쪽으로 쓰는 아랍어/히브리어, 자동완성과 자동수정, 받아쓰기, 클립보드 붙여넣기, 텍스트 선택 핸들, 드래그 앤 드롭, 접근성 기능까지 전부 텍스트 입력 컴포넌트가 책임져야 합니다.

저자는 SwiftUI나 다른 네이티브 텍스트 컴포넌트가 기본 입력은 잘 처리하지만, 조금만 커스터마이즈하려고 하면 막힌다고 토로해요. 예를 들어 "입력 중인 단어에 자동으로 자동완성 제안을 보여주고 싶다", "특정 단어를 하이라이트하고 클릭 가능하게 만들고 싶다", "리치 텍스트 편집을 지원하면서도 마크다운으로 저장하고 싶다" 같은 요구가 들어오면, 네이티브 API의 한계와 부딪힌다는 거죠. 그러다 보니 UITextView나 NSTextView 같은 옛 API를 끄집어내서 직접 깎아야 하고, 결국 코드가 산으로 가게 됩니다.

그래서 결국 웹뷰로?

저자가 내린 결론이 흥미로워요. UI의 나머지 부분은 그대로 네이티브로 두되, 텍스트 편집 영역만 웹뷰(WebView)로 처리하는 하이브리드 접근을 택했다는 겁니다. 왜냐하면 웹의 contenteditable이라는 속성과 Lexical, ProseMirror, TipTap 같은 풍부한 에디터 라이브러리 생태계가 이미 텍스트 편집의 온갖 난제를 해결해 놨거든요.

생각해 보면 Notion, Slack, Discord, Linear 같은 "네이티브처럼 보이는" 데스크톱/모바일 앱들이 사실 대부분 Electron이나 웹뷰 기반인 이유도 여기 있어요. 텍스트와 협업 기능이 핵심인 앱일수록 웹 기술 스택을 벗어나기가 정말 어렵습니다. 웹은 30년 가까이 "문서를 표현하고 편집하는" 일에 진심이었거든요. 그 누적된 자산을 네이티브 텍스트 API가 짧은 시간에 따라잡기는 쉽지 않죠.

기술적으로 어떻게 합쳐지나

네이티브 + 웹뷰 하이브리드를 구현하는 방식은 대체로 이래요. 일단 메인 화면 구조, 사이드바, 네비게이션, 버튼 같은 건 SwiftUI나 Jetpack Compose로 만듭니다. 그리고 본문 편집기 영역에 WKWebView(iOS/macOS)나 WebView(Android)를 띄우고, 그 안에 HTML/JS로 작성된 에디터를 로드해요. 네이티브와 웹뷰는 JavaScript 브리지를 통해 양방향으로 메시지를 주고받습니다. 사용자가 글자를 입력하면 웹뷰에서 네이티브로 "본문이 이렇게 바뀌었어" 하고 알려주고, 네이티브에서는 그걸 받아 모델에 저장하거나 동기화하죠.

물론 단점도 있어요. 웹뷰는 메모리를 더 쓰고, 첫 로딩 시 살짝 깜빡임이 있을 수 있고, 키보드 동작이나 스크롤 관성이 네이티브와 미묘하게 달라서 사용자가 위화감을 느끼기도 합니다. 그래서 키보드 처리, 다크모드 색상 동기화, 폰트 동기화, 안전 영역(safe area) 보정 같은 작업을 꼼꼼히 해야 진짜 "하나의 앱"처럼 보입니다.

업계 흐름에서의 위치

이 글이 흥미로운 이유는 "순수 네이티브 vs 순수 크로스 플랫폼"이라는 이분법을 넘어선다는 점이에요. 최근 흐름은 목적에 따라 기술을 섞는 하이브리드가 늘고 있어요. Notion은 코어 에디터를 웹으로 두고 네이티브 셸로 감쌌고, Linear는 데스크톱은 Electron이지만 모바일은 React Native로 갔어요. Bear, Craft 같은 마크다운 노트 앱들도 일부 텍스트 영역은 웹 기반 에디터를 쓰는 걸로 알려져 있습니다.

반대편에는 Apple이 밀고 있는 TextKit 2가 있어요. iOS 15에서 도입돼서 텍스트 렌더링 엔진을 현대화하고 있지만, 여전히 contenteditable 생태계의 풍부함에는 못 미친다는 평가가 많습니다. SwiftUI의 TextEditor도 점점 좋아지고 있지만, 본격적인 리치 텍스트 편집기를 만들기엔 부족하다는 게 중론이고요.

한국 개발자에게 주는 시사점

한국어 사용자를 위한 앱을 만든다면 텍스트 처리는 더더욱 신경 써야 할 부분이에요. 자모 분리 입력, 오토마타 처리, 한자 변환, 사용자 사전 같은 한국어 특유의 입력 시나리오가 있거든요. 네이티브 API에만 의존하면 OEM별 키보드 차이로 인한 버그가 끊임없이 나옵니다. 차라리 본격적인 에디터를 만들 때는 처음부터 웹뷰 + TipTap 같은 조합을 고려해 보는 게 시간을 아끼는 길일 수 있어요.

또 협업 기능을 넣을 계획이라면 거의 무조건 웹뷰 쪽으로 가게 됩니다. CRDT 기반의 실시간 동기화 라이브러리(Yjs, Automerge)들이 모두 자바스크립트를 1급으로 지원하거든요. 네이티브 포팅도 있지만 성숙도와 커뮤니티 면에서 차이가 큽니다.

마무리

핵심은 "네이티브가 정답"이라는 신념을 텍스트 앞에서는 잠시 내려놓아야 한다는 거예요. 도구는 목적에 맞게 쓰는 것이고, 텍스트 편집이라는 도메인은 웹이 압도적으로 앞서 있는 영역입니다.

여러분이 앱을 만든다면, 어떤 영역까지를 네이티브로 두고 어떤 부분에서 웹뷰를 받아들이시겠어요? 사용자 경험과 개발 생산성의 균형은 어디서 잡으시나요?