--- title: "네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백" published: 2026-05-17T11:49:46.000Z canonical: https://jeff.news/article/2841 --- # 네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백 20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다. - 이 글은 ‘또 Electron이야?’라는 반응에 대한 네이티브 개발자의 반격에 가까움 - 작성자는 거의 20년 동안 macOS와 iOS 네이티브 개발을 해온 사람임 - 그런데 단순한 마크다운 채팅 UI를 순수 Swift·SwiftUI로 만들다가, 결국 네이티브 스택이 생각보다 많이 미성숙하다는 결론에 도달함 - 시작은 아주 평범했음. SwiftUI 앱에서 마크다운을 지원하는 채팅 화면을 만들고 싶었던 것뿐임 - SwiftUI로 적당한 성능은 낼 수 있음 - 스크롤이 조금 튀고 약간의 랙이 있어도 스스로 납득할 수는 있음 - 그런데 SwiftUI primitive로 만든 마크다운 문서 전체를 선택하려고 하면 안 됨. 그냥 설계상 안 되는 영역에 가까움 - 그래서 NSTextView로 내려갔지만, 여기서도 다른 문제가 터짐 - TextKit 2 지원이 있으니 괜찮아 보이지만 SwiftUI와 잘 섞이지 않음 - SwiftUI 쪽에서 해둔 테스트와 성능 작업을 꽤 잃게 됨 - 2026년식 앱답게 모델 응답을 스트리밍하려고 하면 CPU 스파이크가 보이기 시작함 - AppKit과 NSCollectionView로 더 내려가도 깔끔하게 끝나지 않음 - 성숙하고 빠르고 검증된 기술처럼 보이지만, 셀 깜빡임 같은 문제가 계속 남음 - TextKit 2를 직접 써보면 성능은 괜찮아도 스트리밍 텍스트 처리가 여전히 별로임 - 결국 SwiftUI를 걷어내고 AppKit에 붙어 확장되는 텍스트 덩어리를 직접 관리하는 상황까지 감 > [!IMPORTANT] > 작성자가 막힌 건 ‘고급 기능’이 아님. 채팅 메시지의 마크다운을 렌더링하고, 긴 텍스트를 선택하고, 스트리밍으로 자연스럽게 보여주는 기본 UX임 - 더 무서운 건 기능 패리티 비용임 - 컨텍스트 메뉴, 사전 조회, 선택, 접근성, 텍스트 상호작용처럼 macOS 사용자가 당연히 기대하는 것들을 다시 맞춰야 함 - 이걸 제대로 하려면 몇 주가 아니라 몇 달이 걸릴 수 있다는 게 작성자의 판단임 - WebKit으로 마크다운을 렌더링하자 상황이 갑자기 좋아짐 - 성능이 좋고, 타이포그래피도 거의 제대로 나오고, 제어권도 충분히 확보됨 - 당연히 단점은 있지만, 네이티브 텍스트 스택에서 겪던 문제들보다 훨씬 실용적으로 보였다는 얘기임 - 결국 Electron 프로젝트를 만들어봤고, 작성자는 꽤 충격을 받음 - 텍스트 작업, 마크다운 렌더링, 좋은 타이포그래피가 거의 기본으로 됨 - 순수 TextKit 2 구현보다 체감 성능도 더 나았다고 말함 - Git diff 같은 복잡한 UI도 몇 줄로 붙일 수 있고, macOS 통합도 충분히 가능했다고 봄 - 결론은 꽤 세다. 채팅 중심 앱, 장문 리치 텍스트, 유연한 타이포그래피가 핵심이면 웹 기반이 사실상 대안이 없다는 것 - SwiftUI는 단순 화면에는 괜찮고, Swift는 성능 중요한 부분에 여전히 좋음 - 하지만 리치 텍스트 렌더링이 제품의 중심이면 네이티브 SDK가 장점이 아니라 제약이 될 수 있음 - 그래서 요즘 채팅-heavy 앱들이 Electron, React Native, WebKit 같은 웹 기반 렌더링을 붙이는 이유가 꽤 명확해짐 --- ## 기술 맥락 - 이 글의 핵심 선택지는 ‘네이티브냐 웹이냐’가 아니라 ‘텍스트 렌더링을 누가 책임지냐’예요. 단순 버튼과 리스트는 SwiftUI로도 충분하지만, 장문 마크다운 채팅은 선택, 스크롤, 스트리밍, 접근성이 한꺼번에 걸리거든요. - SwiftUI에서 AppKit, TextKit 2로 내려갈수록 제어권은 늘어나지만 기본 UX를 직접 맞춰야 하는 비용도 같이 커져요. 사용자는 텍스트 선택이나 컨텍스트 메뉴를 기능이라고 생각하지 않지만, 앱 개발자는 그걸 하나씩 다시 구현해야 해요. - WebKit과 Electron이 강한 이유는 브라우저가 지난 수십 년 동안 텍스트와 문서 렌더링 문제를 계속 풀어왔기 때문이에요. 마크다운, 코드 블록, diff, 타이포그래피, 선택 동작이 웹 생태계에서는 이미 많이 닦여 있어요. - 그래서 이 글은 Electron 찬양이라기보다 제품 요구사항에 맞는 렌더링 엔진을 고르자는 얘기에 가까워요. 네이티브 앱이라도 텍스트가 핵심이면 웹 엔진을 섞는 게 더 엔지니어링다운 선택일 수 있어요. ## 핵심 포인트 - SwiftUI만으로 마크다운 문서 전체 선택 같은 기본 텍스트 상호작용을 처리하기 어렵다고 지적함 - NSTextView와 TextKit 2로 내려가도 SwiftUI와의 통합, 스트리밍 성능, 현대적 UI 조합에서 문제가 생김 - WebKit은 마크다운 렌더링, 타이포그래피, 제어권 면에서 훨씬 안정적으로 작동했다고 평가함 - Electron은 텍스트 작업과 마크다운 렌더링, Git diff 같은 기능이 예상보다 쉽게 동작했다고 말함 - 채팅·장문 리치 텍스트 앱에서는 웹 기반 접근이 사실상 표준이 된 이유를 설명함 ## 인사이트 ‘Electron 또 씀?’이라는 반응에 대한 꽤 날카로운 반박이다. 리치 텍스트가 제품의 핵심이면 네이티브라는 이름값보다 브라우저의 텍스트 모델이 더 실용적인 선택일 수 있다는 얘기다.