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

• 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

[GN⁺]

Hacker News 의견들

• 최근 TextKit 2를 쓰는 iOS용 텍스트 편집기를 출시했는데, 5,000줄 파일에서도 성능이 높게 나옴
  Project Gutenberg의 Moby Dick으로 테스트했고, 2025년 8월부터 2026년 4월 사이에 만들었으며 개발은 계속 중임
  키 입력마다 8ms 안에 다시 스타일링되고, 디바운싱이나 지연 렌더링 없이 빠른 20회 입력도 각 입력 후 전체 재스타일링까지 포함해 150ms에 처리됨
  태그와 불리언 검색은 20ms 안에 끝나고, 보이는 범위만 렌더링하면 문서 전체 스타일링보다 25배 빠르며 120Hz 화면 갱신도 지원함
  앱 파일 크기는 1.0에서 722KB였고, 기능이 늘어난 1.1도 약 950KB로 보임
  iOS에서 이 정도가 가능하다면 macOS에서는 10배쯤 더 쉬워야 함
  https://www.gingerbeardman.com/apps/papertrail/

  • 유료 제품의 핵심 기능이 편집기라면 이해됨. 하지만 Markdown 렌더링이 앱의 주기능도 아니고 2026년에 사용자가 기대하는 편의 기능에 가까운데, 그걸 위해 8개월과 계속 개발해야 한다는 마음가짐으로 저수준 커스텀 구현을 해야 하는 건 이상함
    “불가능하다”가 아니라, 왜 사람들이 이런 일에 네이티브 대신 웹 기술을 고르는지 이해된다는 뜻임. 제품을 만들고 싶은 거지, 시스템 한계와 싸우고 싶은 게 아님
  • 2012년에 NSString과 속성으로 인터랙티브 소설을 만들고, 폐기된 저수준 글리프 API로 로그라이크를 만들고, SwiftUI로 Markdown 지원 채팅 앱 2개와 iOS 트릭을 섞은 방치형 게임을 만든 입장에서 보면, 이 반응은 결국 숙련도 문제라고 요약하게 됨
  • 5,000줄은 정말 작은 크기라 이 설명이 혼란스러움. 테스트했다는 Moby Dick도 22,000줄이 넘는 것으로 보이고, Windows 기본 메모장도 그 정도 파일은 버벅이지 않음
    텍스트 뷰어라면 적어도 그보다 두 자릿수는 큰 파일을 다뤄야 함. 수십만 줄짜리 JSON 파일은 흔하고, CSV와 로그 파일은 그보다 더 김
  • SwiftUI의 Mac 구현이 별로일 가능성이 큼. 이런 앱에는 SwiftUI-on-Catalyst가 더 나을 수도 있지만, 아마 다른 문제가 있을 것임
  • iOS에서 되면 macOS에서 10배 쉽다는 말은 강하게 의심됨. 오히려 정반대일 것 같고, 실제로 아는 사람의 이야기를 듣고 싶음

• 보통은 웹뷰 대신 네이티브 API를 쓰는 이유가 성능이었는데, 이제는 꼭 그렇지 않아 보임
  브라우저 렌더링 엔진은 상당히 성숙했고 GPU 가속도 많이 들어갔으며, 10년 넘게 비대한 웹 앱들로 스트레스 테스트를 받아왔음
  반면 SwiftUI는 딱히 빠르게 느껴지지 않음. Apple이 최신으로 다시 만든 시스템 설정도 UI를 체크박스 행 위주로 단순화했는데, 섹션 전환이 us-east-1에서 웹페이지를 불러오는 것보다 더 버벅일 때가 있음

  • 여기서 문제는 네이티브 앱 전반이 아니라 SwiftUI임
    Qt C++와 QML로 네이티브 앱을 만들었고, 비슷한 웹 앱보다 훨씬 빠르고 RAM도 훨씬 덜 쓴다는 걸 보여줬음
    그래서 일반적으로 웹 앱은 잘 설계된 네이티브 앱보다 느리고 자원을 더 많이 씀
    [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
    [2] https://x.com/daniel_nguyenx/status/1734495508746702936
    [3] https://rubymamistvalove.com/block-editor#8-performance
  • 그래도 네이티브 앱과 가장 가벼운 브라우저 앱 사이에는 큰 차이가 있고, 저전력 기기에서는 더 두드러짐
    원래 웹 개발자였지만 최근 6~12개월 동안 네이티브 크로스플랫폼 앱을 만들기 시작했는데, 단순한 작업에서도 성능 격차가 꽤 큼
  • 브라우저는 오래된 하드웨어에서 형편없음. 구형 Chromebook은 흔하고 가벼운 용도나 특정 목적용으로는 사양도 괜찮은데, 브라우저가 정말 느리게 돌아감
  • 단순한 웹 앱이면 몰라도 복잡한 애플리케이션에서는 눈에 띄는 느려짐이 있음. Jira 같은 괴물까지 갈 필요도 없고, VS Code처럼 잘 최적화된 앱도 네이티브 앱보다 낮은 성능 상한이 있음
  • WebView도 결국은 “네이티브”임
    수천 인년의 최적화와 실제 환경에서의 수백만 인년짜리 검증을 버리고, 더 못한 텍스트 렌더링 엔진을 다시 만들자는 식으로 생각하는 게 이상함

• macOS에서는 WebKit이 네이티브 OS 프레임워크임. Markdown 렌더링에 WebKit을 쓰는 건 완전히 적절해 보임
  물론 모든 것을 WebKit으로 렌더링하는 건 모든 걸 PDFKit으로 렌더링하는 것만큼 말이 안 됨. 하지만 Markdown 뷰라면 WebKit은 논리적인 선택이고, 그렇다고 판을 뒤집어 Chromium 웹 앱으로 갈 필요는 없음

  • HTML 엔진이 UI에서 렌더링하기 가장 어려울 수 있는 리치 텍스트를 네이티브 UI 라이브러리보다 잘 렌더링한다면, 버튼이나 텍스트 필드처럼 더 쉬운 것들도 왜 그걸로 렌더링하지 않겠음?
    그리고 OS X는 오랫동안 DisplayPDF/Quartz로 UI를 렌더링했음
  • WebKit으로 Markdown을 렌더링하는 게 왜 적절한지 설명이 필요함
  • 원문 작성자는 “네이티브”를 Swift/ObjC 원시 요소만 쓰는 것으로 보는 듯함
    WebKit은 다른 플랫폼에도 있으니 반칙이라는 건가? 그럴 거면 Java를 써도 되겠음
  • 리치 텍스트를 렌더링하는 데 왜 WebKit을 써야 한다고 기대해야 하는지 모르겠음
    HTML/CSS/JS 렌더러로 텍스트를 렌더링하는 게 “완전히 적절”하다면, 적절하지 않은 영역은 무엇임? 왜 모든 것을 그걸로 렌더링하지 않음?
    “텍스트 렌더링은 적절하지만 모든 렌더링은 말도 안 된다”로 이어지는 논리가 이해되지 않음
  • 실제로 지금 진행 중인 해법이 최종 Markdown과 스트리밍을 WebKit으로 렌더링하는 것임
    macOS에서 WebKit이 네이티브 OS 프레임워크라는 점에는 동의하고, 그런 의미에서는 “네이티브”임
    하지만 리치 텍스트, Markdown, 선택, 타이포그래피, 긴 형식의 포맷된 콘텐츠를 제대로 다루려면 웹 기술이 빠르게 유일하게 실용적인 선택지가 된다는 더 큰 요지를 뒷받침하기도 함
    Markdown 뷰에 WebKit을 쓰는 게 틀렸다는 게 아니라, 오히려 가장 합리적인 선택일 가능성이 큼. 문제는 여기서 “네이티브” 해법이 사실상 웹 렌더링 해법이라는 점임
    각 WKWebView는 자체 성능과 메모리 오버헤드를 가진 WebKit 엔진을 가져오므로, 아무 데나 뿌려 놓고 공짜 네이티브 macOS 컴포넌트처럼 볼 수 없음
    이런 종류의 UI에서 SwiftUI / AppKit / TextKit이 “그냥 WebKit을 써라”보다 나은 깔끔하고 현대적이며 조합 가능한 경로를 주지 못한다는 점이 답답함

• “Markdown이 있는 채팅에서 메시지 전체를 선택할 수 있게 하는” 정도가 안 된다는 건 말이 안 되는 듯함
  SwiftUI에는 성숙한 Markdown 렌더러를 활용할 수 있음. https://github.com/gonzalezreal/swift-markdown-ui와 그 차세대 대체인 https://github.com/gonzalezreal/textual을 보면 됨
  직접 써봤고 문제 없었음. Swift나 SwiftUI를 좋아하지 않고 Objective-C를 선호하는 바보 같은 나도 LLM 도움 없이 해냈음

  • 오늘 일찍 Textual을 시험해 봤는데 결과가 썩 좋지 않았음
    정적 완료 Markdown 스크롤은 새 집중 프로브를 통과하지 못했고, p95 18.86ms로 16.7ms 예산을 넘었으며 최대 232.49ms였음
    긴 실시간 Markdown/코드 업데이트 경로도 실패했고, p95 59.33ms 대 16.7ms, 최대 75.94ms였음. 업데이트 중 큰 리치 텍스트 표면을 다루는 별도지만 관련 있는 스트레스 케이스임
    긴 히스토리 확장은 기술적으로 통과하지만 부드러운 프레임이라 보기 어려움: 120턴 p95 21.35ms, 500턴 23.11ms, 1000턴 36.77ms
    나쁘지는 않지만 내 해법보다 약간 느리고, 주로 Textual 구현보다는 SwiftUI와 관련된 비슷한 성능 격차가 있음
  • 새 텍스트가 스트리밍될 때 깜빡임 없이 처리할 수 있음?
  • Markdown 문서를 한 번만 렌더링하거나, 문서가 단순하고 짧은 경우라면 가능할 것임
    예전에 앱에서 swift-markdown-ui를 썼지만 성능은 wkwebview에 전혀 못 미쳤음. 큰 표, 코드 블록, 중첩 인용 같은 까다로운 요소가 있는 큰 문서를 스트리밍하면 비치볼까지 볼 수 있는데, wkwebview를 쓸 때는 그런 일이 없었음
  • 첫 번째 라이브러리는 Claude iOS 앱이 쓰는 것으로 보이고, 텍스트 선택과 스트리밍도 가능하면서 성능도 괜찮아 보임
  • 사용자 입장에서는 오래된 비 HTML 기반 앱들이 “규칙”을 따르지 않는 게 보임. 선택할 수 있어야 하는 텍스트가 선택되지 않거나, control/option C로 복사되지 않는 식임
    그러다 브라우저와 그 기반 기술들이 UI에 새로운 패러다임을 도입했고, 네이티브 UI 프레임워크가 그걸 따라가지 못했다는 걸 깨달았음
    웹 기반 앱보다 네이티브 앱을 선호하는 입장에서도 그렇게 느껴짐

• 코드를 보여주든가, 아니면 나가야 함. 지금도 Markdown 렌더링과 스트리밍 텍스트를 제대로 처리하는 네이티브 Mac/iOS 앱이 아주 많음
  도대체 어떤 핑계가 있는지 궁금할 뿐임

  • “SwiftUI 원시 요소로 만든 Markdown 문서 전체를 선택하고 싶다”고 하는데, 누가 그걸 원함? 그런 제품 판단은 사실상 문서 편집기를 만들겠다는 뜻이고, 수십 년 동안 어려웠던 영역이며 LLM 채팅 UI의 범위를 벗어나 보임
    대부분은 연속된 각 블록 안에서만 선택을 지원하고, 메시지 전체에는 복사 버튼을 두는 쪽으로 정착했음
  • 웹뷰 없이 가능하다면 코드를 공유해보면 됨

• 재미있는 사실은 Apple도 예전에 이렇게 했다는 것임
  예전 macOS / AppKit은 네이티브 NSTextField 안의 리치 텍스트를 렌더링하는 데 WebKit을 썼음. 텍스트는 어려운 문제임
  게다가 네이티브 WebView는 매우 빠르고 가벼워서 텍스트 레이아웃 엔진으로 쓰는 게 이상하지 않음. 테이블의 각 행마다 별도 WebView를 써도 훌륭한 성능이 나올 수 있음
  Mac용 iMessage도 WebView를 썼고, Adium도 그랬음. 리치/마크업 텍스트를 렌더링한다면 HTML은 완전히 맞는 도구임

  • 여기서는 iOS와 Mac OS를 혼동하고 있음
    Mac은 NSTextField 렌더링에 WebKit을 쓴 적이 없음. iOS가 처음 만들어졌을 때는 UIKit 컨트롤을 포함해 전반적으로 WebKit을 텍스트 렌더러로 썼고, 이를 “sweet solution”이라고 불렀음
    하지만 너무 무겁고 번거로운 것으로 드러나면서 Core Text/AppKit식 텍스트 렌더링 접근이 넘어왔음
  • 원문의 흐름은 조금 이상함
    복잡한 네이티브 텍스트 렌더링이 어렵다는 걸 발견하고, 저수준 방식으로 텍스트를 렌더링하다가 네이티브 상호작용을 다시 구현해야 한다고 불평함
    WebKit을 시도하니 아주 잘 됐는데, 그걸 버리고 다시 네이티브 상호작용을 구현해야 하는 상황으로 감
    개인적으로는 WebKit이 잘 되는 시점에서 멈췄을 것임

• 2015년에 주니어 엔지니어였을 때 iOS 앱의 문단 안에 클릭 가능한 링크를 렌더링하라는 일을 받았던 기억이 남
  Swift가 막 나왔던 시기라 완전히 ObjC/UIKit 스택이었고, 정말 악몽 같았음. 간신히 동작하게 만들었음
  2016년쯤 이후로 iOS를 거의 만지지 않아서, 새 SwiftUI에는 당연히 이런 게 기본으로 들어갔을 거라 생각했는데 아니었다니 꽤 미친 일임

  • 말 그대로 Link라는 게 있음
    https://developer.apple.com/documentation/swiftui/link
    이쯤 되면 얼마나 더 쉽게 만들 수 있을지 모르겠음
  • Qt는 10년 전에도 이걸 꽤 쉽게 만들었음
  • NSLinkAttributeName이 있지 않았음?
  • 속성 있는 텍스트가 예전부터 이걸 잘 처리한다고 생각했는데, 아니었음?
  • 문단 안에 클릭 가능한 링크를 넣어 달라는 요구 자체가 이미 나쁜 아이디어였음

• “단순한 화면을 벗어나면 네이티브가 아직도 이렇게 미성숙하다”는 건 당연한 일임
  사람들이 충분한 노력을 투자하지 않으면 그게 성숙해지길 기대할 수 없음
  더 많은 노력이 웹 기술로 몰리기 때문에 사람들이 거기에 묶여 있음. 네이티브를 보고 “충분히 발전하지 않았다”고 말한 뒤 다시 웹 개발을 더 하는 순환이 반복됨
  브라우저에서는 이미 “그냥 된다”는 이유로 네이티브를 개선하려는 노력을 하려는 사람이 거의 없음

  • 그렇다 해도 네이티브 UI 개발 키트는 상용 제품 아닌가? 사람들이 스스로를 설득할 일이 아니라, 그쪽이 사람들에게 팔아야 하는 일임
    웹 쪽이 훨씬 성숙한 이유 중 하나는 대형 상용 OS 제조사들이 시대를 따라가지 않으려 했기 때문임. Windows UI 키트들은 정말 엉망임
  • 동의함. 결국 Swift에서 Markdown을 빠르게 다루는 데 아직 별 노력이 들어가지 않았다고 불평하는 셈인데, 정작 본인이 거기에 기여하려고 하지는 않음

• 내 AI 채팅 앱에서도 거의 같은 경험을 했음. 제대로 되는 게 없음
  Markdown 렌더링은 느리고 버벅이고, 스트리밍도 느리고 버벅이며, 모든 게 UI를 멈추게 함
  GitHub에서 인기 있는 UIKit과 SwiftUI용 텍스트 편집 컴포넌트를 적어도 5개는 시험해 봤는데, 전부 어떤 식으로든 깨져 있거나 버그가 있고 느렸음. 말도 안 됨

• 이건 어려운 문제임. Qt C++와 QML로 블록 편집기를 처음부터 만들며 어떻게 해결했는지 길게 썼음
  불연속 블록 사이의 선택, 커서 아래의 원본 Markdown 표시, 서로 다른 delegate 크기 같은 비슷한 문제를 겪었음
  그때 배운 내용을 바탕으로 스트리밍 Markdown 파서를 갖춘 네이티브 LLM 클라이언트를 만들고 있음
  [1] https://rubymamistvalove.com/block-editor
  [2] https://www.get-vox.com

[GN⁺]

Lobste.rs 의견들

• 복잡한 텍스트 레이아웃에는 웹뷰가 맞다는 데 동의하지만, 편의성 말고 굳이 Electron까지 가야 하는지는 잘 모르겠음
  Electron은 사실상 WebView를 감싼 래퍼인데, Chromium 엔진 전체를 같이 끌고 오기 때문에 편의성의 대가로 앱 크기가 너무 커짐
  2001~2002년에 iChat의 상징적인 말풍선 텍스트 레이아웃을 NSTextView와 온갖 꼼수로 구현했는데, AppKit 텍스트 설계자였던 Hideki Itamura의 도움을 받아도 꽤 고생스러웠음. 지금은 HTML+CSS로 꽤 간단해짐
  • 여러 시스템을 지원할 때는 결국 단순함이 큼
    Tauri를 쓰던 앱에 관여했는데, Electron으로 Chromium을 쓰도록 바꾸니 훨씬 잘 동작했음. 특히 win7부터 win11까지 매우 넓은 범위를 대상으로 했다는 점도 중요함
    Tauri 계열은 시스템 웹뷰를 쓴다는 점이 좋아 보이지만, Windows에서는 Chrome이나 Edge, macOS에서는 Safari, 그 외 환경에서는 운에 맡기는 셈임. 결국 예측 가능성과 성숙도가 이겼고, 알 수 없는 이유로 성능도 더 나았음
  • 이건 개인 선택이라고 봄. 앱 크기든 RAM 사용량이든 편의성의 대가를 낼 준비가 되어 있고, Visual Studio Code 같은 앱의 수백만 사용자도 동의하는 듯함
    결국 htop 차트를 만족시키기보다 더 나은 소프트웨어를 원함
    블로그 글의 핵심은 “모두 Electron을 선택해야 한다”가 아니라, 자원과 돈이 있는 회사들도 왜 여전히 Electron이나 웹 기술을 선택하는지 이제 이해했다는 것임. 적어도 내 기준에서는 적절한 부분에서 타협하면서 좋은 사용자 경험을 제공함
    Apple의 TextKit 2나 다른 네이티브 텍스트 프레임워크를 옹호하는 사람은 많지만, Apple SDK만으로 만든 인기 있고 고성능인 텍스트 편집기는 거의 없음. Xcode는 꽤 잘하고 있고 아마 유일한 실전 사례에 가까움. Zed, Sublime Text, Visual Studio Code, JetBrains IDE들은 모두 이유가 있어서 자체 텍스트 렌더링 솔루션을 씀
• 소프트웨어를 만드는 사람들이 전 세계 상위 0.1% 수준의 좋은 컴퓨터와 휴대폰에서 개발한다는 게 문제 중 하나임
  그래서 최악의 방식으로 만들어도 자기 환경에서는 괜찮아 보일 수 있음
  반면 훨씬 낮은 사양의 기기를 쓰는 나머지 사람들은 계속 비대하고 느린 소프트웨어를 떠안게 됨
• GTK/Qt 같은 쪽은 요즘 어떤지 궁금함. GUI를 한 지 오래됐음
  • 이해하기로는 이 작업도 Qt에서는 웹뷰 없이 구현 가능할 것 같음
    다만 글쓴이는 여기서 그쪽까지 탐색하지는 않은 듯함
• Electron과 Flutter를 비교하면 어떨지 궁금함
  바깥에서 보기에는 Flutter가 “Chromium에서 렌더러인 Skia만 남기고 GUI 앱에 쓰면 어떨까?”에 대한 답처럼 보임. Electron보다 가벼우면서도 비슷한 기능을 갖춘 크로스플랫폼 도구여야 할 것 같음
• https://github.com/stevengharris/MarkupEditor 작성자는 이 글이 현재 가능한 해법 중 하나로 꽤 좋다고 제안함: https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-promised-land/
  • 그런데 MarkupEditor는 TextKit2가 아니라 WebView를 씀. README에도 MarkupEditor가 contentEditable DIV 하나를 쓰는 HTML 문서와 상호작용하고, WKWebView의 하위 클래스를 사용한다고 되어 있음
    아이러니한 점은 Apple의 네이티브 텍스트 엔진이 HTML DOM 트리보다 훨씬 나은 데이터 모델, 즉 문자열과 실행 길이 부호화된 스타일 속성을 쓴다는 것임
    DOM에서 텍스트를 편집하는 건 악몽에 가까운데, 선택 영역이 여러 계층의 여러 요소를 가로지르는 일이 많아 매우 복잡하게 쪼개고 병합해야 하기 때문임. 예전에 contenteditable 지원이 들어간 Safari 빌드를 처음 만졌을 때 버그 리포트를 엄청 많이 냈고, 지금도 많은 웹 리치 텍스트 편집기가 목록 항목을 잘라내거나 붙여넣을 때 망가짐
    결국 90~00년대의 CISC 대 RISC와 비슷한 일이 벌어진 것 같음. ‘열등한’ 구조가 더 많은 자원을 투입받으면서 더 뛰어난 구현을 낳은 셈임