텍스트가 필요할 때까지는 전부 네이티브: 풍부한 텍스트 렌더링의 고군분투

거의 20년 동안 Apple 플랫폼 개발자들의 모토는 “전부 네이티브”였습니다. 약속은 간단합니다: 더 나은 성능, 더 깊은 OS 통합, 그리고 뛰어난 사용자 경험. 하지만 현대 애플리케이션 패턴이 채팅 중심 인터페이스와 LLM 기반 스트리밍 텍스트로 이동함에 따라 좌절스러운 현실이 나타나고 있습니다. 많은 경우, 네이티브 경로는 다듬어진 제품이 아니라 기술적 교착 상태로 이어집니다.

최근 도발적인 글에서 개발자 Artem Loenko는 SwiftUI에서 마크다운 지원을 갖춘 간단한 채팅 인터페이스를 구현하려는 고군분투를 상세히 설명합니다. 사소한 작업이어야 했던 것이 Apple SDK의 여러 층을 통과하는 하강으로 변했으며, 복잡하고 동적인 콘텐츠에 대한 네이티브 텍스트 처리의 성숙도가 놀랍게도 부족함을 드러냈습니다.

네이티브 하강: SwiftUI에서 TextKit까지

Loenko의 여정은 현대 선언형 프레임워크인 SwiftUI에서 시작되었습니다. 간단한 화면을 처리할 수는 있지만, 풍부한 텍스트와 장문 스크롤 영역에 들어가자 경험이 악화되었습니다. 주요 문제점은? SwiftUI 기본 요소로 만든 전체 마크다운 문서를 선택할 수 없다는 점—디자인상 지원되지 않는 기본적인 사용자 기대였습니다.

보다 견고한 솔루션을 찾기 위해 그는 NSTextView와 TextKit 2로 이동했습니다. 이들은 더 많은 제어를 제공했지만 새로운 마찰을 일으켰습니다:

Integration Gaps: TextKit 2는 현대 SwiftUI 생태계와 잘 맞지 않아 성능 테스트와 텍스트 기능 사이에 트레이드오프를 강요합니다.
Performance Spikes: 스트리밍 텍스트(모든 현대 AI 채팅 앱의 필수 요소)가 상당한 CPU 급증을 일으켰습니다.
UI Glitches: 성능 문제를 해결하기 위해 NSCollectionView로 전환했지만 "깜빡이는" 셀을 초래했으며, 이는 또 다른 디자인 수준의 제약입니다.

궁극적으로 Loenko는 기본 macOS 동작—컨텍스트 메뉴, 사전 조회, 접근성—과 기능 동등성을 맞추려면 수개월에 걸친 수작업이 필요하다는 것을 발견했습니다. 결론은 놀라웠습니다: 개발을 쉽게 만들기 위해 설계된 네이티브 도구가 실제로는 제약이 되고 있었습니다.

"다크 사이드"와 브라우저의 승리

절망에 빠진 Loenko는 WebKit을 거쳐 결국 Electron으로 눈을 돌렸습니다. 결과는 네이티브 구현을 괴롭히던 문제들이 즉시 해결된 것이었습니다. 텍스트 작업, 마크다운 렌더링, 타이포그래피가 바로 작동했으며, 성능은 그의 순수 TextKit 2 프로토타입을 능가했습니다.

이 전환은 더 넓은 산업 트렌드를 강조합니다. 오늘날 가장 성공적인 채팅 중심 앱 중 다수가 웹 기반인 이유는 브라우저 엔진이 사실상 가장 성숙한 텍스트 렌더링 엔진이기 때문입니다. 한 댓글자 @StilesCrisis가 언급했듯이:

"우리는 현대 WebKit/Blink 스택에서 너무 많은 것을 당연하게 여기고 있습니다. 현대 다국어 텍스트 처리 자체가 정말 어려운 문제입니다."

대논쟁: 스킬 문제인가 시스템적 실패인가?

Loenko의 경험에 대한 커뮤니티 반응은 양극화되었으며, 개발자 커뮤니티 내 깊은 분열을 반영했습니다.

"스킬 문제" 논쟁

일부 개발자는 네이티브 도구를 올바르게 사용하면 충분하다고 주장했습니다. @lenkite는 swift-markdown-ui와 같은 기존 라이브러리를 지목하며 SwiftUI에서 마크다운 렌더링이 가능함을 증명했습니다. 또 다른 사람들, 예를 들어 @msephton은 TextKit 2를 사용해 고성능 텍스트 편집기를 구축한 성공 사례를 공유하며, 빠른 키 입력과 전체 재스타일링을 8ms 이하로 달성할 수 있다고 주장했습니다.

시스템적 실패 논쟁

반대로, 많은 개발자들이 Loenko의 고통에 공감했습니다. @splittydev는 AI 채팅 앱에서 비슷한 어려움을 겪었다고 보고했으며, UIKit/SwiftUI용 가장 인기 있는 GitHub 구성 요소들이 "어떤 식으로든 깨지고, 버그가 많으며, 느리다"고 언급했습니다.

또한 웹의 지배가 거대한 투자 결과라는 주장도 있습니다. @Yokohiii는 Chrome이 아마도 "세계에서 가장 자금이 풍부한 소프트웨어"이며, 그 성숙도는 막대한 재정 및 엔지니어링 노력의 결과이며, 네이티브 프레임워크는 텍스트 렌더링 분야에서 이를 따라가지 못했다고 관찰했습니다.

종합: 중간 지점 찾기

논의는 선택이 반드시 "순수 네이티브"와 "전체 Electron" 사이의 이분법이 아니라는 것을 시사합니다. 여러 하이브리드 전략이 실현 가능한 대안으로 떠올랐습니다:

The Hybrid Approach: 애플리케이션 쉘(메뉴, 툴바, 네비게이션)에는 네이티브 프레임워크를 사용하고, 풍부한 텍스트/마크다운 영역에는 WKWebView를 별도로 활용합니다. 이렇게 하면 전체적인 네이티브 느낌을 유지하면서 브라우저의 렌더링 파워를 활용할 수 있습니다.
Low-Level Customization: 브라우저의 오버헤드를 감당할 수 없는 경우, 맞춤형 레이아웃 엔진(예: Rust 또는 C++로)을 구축하는 것이 출판 수준의 성능을 달성하는 유일한 방법일 수 있습니다.
Accepting the Trade-off: Electron이 "부풀어 있다"는 점을 인정하면서도, 현재 Apple의 고수준 프레임워크가 따라올 수 없는 생산성 및 텍스트 처리 신뢰성을 제공한다는 점을 받아들입니다.

결론

텍스트는 겉보기엔 단순하지만 속임수가 있습니다. 우리는 매일 매초 텍스트와 상호작용하지만, 이를 동적으로, 접근 가능하게, 그리고 성능 있게 렌더링하는 것은 소프트웨어 엔지니어링에서 가장 어려운 문제 중 하나입니다. SwiftUI와 AppKit은 많은 사용 사례에서 여전히 강력하지만, 앱의 주요 가치 제안이 풍부하고 유연하며 스트리밍 텍스트라면 "전부 네이티브" 접근 방식은 오히려 위험 요소가 될 수 있습니다.