"decoration 엔진이 3중 역할을 하는 건 좋은 보너스가 아냐. CodeMirror 를 고른 이유 전부야."
세 기능, 하나의 원시 요소
물러서서 세 역할을 함께 봐. Live Preview: 범위 계산, mark 붙이기. voice underline: 범위 계산, mark 와 widget 붙이기. CMD+K: 제안 담은 widget 붙이기, 수락 시 mutate. 완전히 관련 없어 보이는 세 기능 — 렌더러, linter, AI 에디터 — 이 같은 모양으로 줄어들어. 소스 위 범위를 계산하고, decoration 을 붙이고, 사용자가 커밋할 때만 mutate 한다. 원시 요소 하나, 한 번 배워서, soul 레이어 전체를 굴려.
Live Preview 범위 -> mark (모습 렌더)
voice underline 범위 -> mark + 여백 widget (voice 이슈 표시)
CMD+K widget 제안 -> 수락 편집 하나 (AI 재작성 무대)
# 다른 입력. 같은 decoration 원시 요소. 그게 승리야.왜 rich-text 모델은 세 우회로로 갈라지나
이제 같은 세 기능을 rich-text 트리 (Tiptap/Lexical) 위에 짓는다고 상상해. Live Preview 는 개념조차 아냐 — 트리가 곧 렌더된 형태라, '렌더된 모습으로 소스 보여주기' 가 모델과 싸워. voice underline 은 문자 범위 대신 노드 트리에서 위치를 찾아 주석 달아야 해. CMD+K 프리뷰는 직접 편집되길 원하는 문서 모델 안에서 비파괴적 제안을 표현해야 해. 각 기능이 트리 결에 맞선 자기 우회로가 돼. 하나가 아니라 세 서브시스템을 짓게 돼.
재사용이 곧 아키텍처
이게 '메커니즘 하나, 역할 셋' 이 행복한 우연이 아니라 load-bearing 결정인 이유야. CodeMirror 가 선택된 건 그 decoration-over-source 원시 요소가 세 soul 기능 전부를 같은 모양으로 만들기 때문이야. 제품 전체 — margin-Pippa, 라이브 voice, inline AI — 가 한 번 짓고 디버깅하는 메커니즘 하나를 타. 그게 가족의 첫 pillar, Reuse, 를 에디터-코어 선택으로 표현한 거야. 가장 기능 많은 substrate 를 고르지 마. 네 기능들이 이미 공유하는 단일 원시 요소를 가진 걸 골라. 재사용이 그만큼 깊으면, 최적화이길 멈추고 아키텍처가 돼.