끝까지 네이티브로, 텍스트가 필요해지기 전까지

• macOS에서 SwiftUI만으로 Markdown 채팅 UI를 만들면 기본 성능은 어느 정도 나오지만, 문서 전체 선택을 지원하기 어려움
• NSTextView와 TextKit 2로 옮기면 SwiftUI 테스트·성능 작업을 잃고, 스트리밍 입력에서 CPU 스파이크가 생김
• NSCollectionView 재구현은 셀 깜빡임을 만들고, 순수 TextKit 2도 성능은 괜찮지만 스트리밍 연동이 좋지 않음
• WebKit은 Markdown 렌더링, 성능, 타이포그래피, 제어 수준이 대체로 잘 맞고, Electron도 텍스트 작업이 기본으로 동작함
• 긴 채팅과 리치 텍스트에서는 SwiftUI와 Apple 네이티브 SDK가 제약이 되며, 웹 기반이 텍스트·렌더링 모델에서 유리해짐

네이티브 macOS Markdown 채팅 UI의 한계

• SwiftUI만으로 Markdown을 지원하는 단순 채팅을 만들면 기본 성능은 어느 정도 가능하지만, SwiftUI 프리미티브로 구성된 Markdown 문서 전체를 선택할 수 없음
• NSTextView로 옮기면 TextKit 2 지원은 얻지만, SwiftUI에서 해둔 테스트와 성능 작업을 대부분 잃고 SwiftUI와도 잘 맞지 않게 됨
• 모델 응답을 스트리밍 방식으로 NSTextView에 넣으면 CPU 스파이크가 발생함
• NSCollectionView로 다시 구현해도 셀이 계속 깜빡이며, 설계상 피하기 어려운 동작으로 남음
• 순수 TextKit 2 프로토타입은 성능은 괜찮지만 스트리밍이 여전히 나쁘고 현대적인 구성요소들과 잘 맞지 않음
• SwiftUI를 완전히 제거하고 AppKit만 사용해도 확장되는 텍스트 조각을 수동으로 다뤄야 하며, 많은 부분이 깨진 상태에서야 텍스트 선택이 가능해짐
• 기본적인 macOS 동작과 비슷한 수준에 도달하려면 컨텍스트 메뉴, 사전 조회, 선택, 접근성, 텍스트 상호작용처럼 사용자가 당연하게 기대하는 기능을 다시 맞춰야 함

WebKit과 Electron이 더 잘 맞는 지점

• WebKit으로 Markdown을 렌더링하면 몇 가지 주의점은 있지만 대체로 잘 동작하고, 성능과 타이포그래피가 좋으며 제어 수준도 충분함
• 단순한 Electron 프로젝트를 만들면 텍스트 작업, Markdown 렌더링, 좋은 타이포그래피가 기본으로 동작하고, 순수 TextKit 2 구현보다 얻기 어려웠던 성능도 나옴
• Electron에서도 macOS 통합이 제공되며, 몇 줄의 코드로 화려한 Git diff를 렌더링할 수 있고 diffs.com 같은 사례도 있음
• SwiftUI, AppKit, TextKit, WebKit까지 검토해도 “Markdown을 지원하고 메시지 전체 선택이 가능한 채팅”이라는 단순한 요구를 제대로 만족시키기 어려움
• 채팅, 긴 형식의 리치 텍스트, 유연한 타이포그래피가 중요한 새 앱들이 웹 기반으로 가는 이유가 더 분명해짐
• SwiftUI는 스크롤이 많지 않은 단순 화면에 적합하고, Swift는 성능이 중요한 부분에 여전히 유용함
• Electron이나 React Native는 네이티브 상호운용성으로 상당한 성능을 얻으면서, 더 나은 텍스트·렌더링 모델을 유지할 수 있음
• 긴 형식의 채팅을 위한 리치 텍스트 렌더링에서는 SwiftUI와 Apple 네이티브 SDK가 장점이 아니라 제약으로 바뀜
• 관련 토론: Hacker News, Lobsters