WYSIWYG 의 유일한 조건

"WYSIWYG 은 마크업이 절대 안 보여야 할 때만 값을 해. 마크다운으로 사는 사람한텐 그럴 일이 없고."

WYSIWYG 이 실제로 치르는 비용

Tiptap 이나 ProseMirror, Lexical 같은 WYSIWYG 에디터는 진짜 강력한 물건이야. 다만 정해진 비용이 붙어. 소스 문자열을 rich-text 문서 모델로 갈아치우거든. 이제 bold 도 schema 노드고 헤딩도 노드야. 원래 있던 마크다운은 로드할 때 트리로 파싱됐다가 저장할 때 다시 마크다운으로 serialize 돼야 하고. 표현 하나로 끝나던 걸 셋으로 늘린 셈이지. 트리, 렌더된 뷰, 그리고 오가는 마크다운.

그걸 정당화하는 유일한 조건

이 거래가 값을 하는 조건은 딱 하나야. 마크업 문자가 절대 안 보여야 한다. # 나 ** 를 절대 보면 안 되는 사람들을 위한 워드프로세서를 만든다면, 그러니까 Bold 버튼 누르면 bold 로 보이고 그걸로 끝이길 바라는 사람들이라면, rich-text 모델이 맞고 표현 셋을 유지하는 비용이 그 경험의 값이야. 그것도 충분히 유효한 제품이지. 다만 이 제품이 아닐 뿐이고.

조건: "마크업이 절대 안 보여야 함"    ->  WYSIWYG 정당 (rich-text 모델)
조건: "마크업이 의미 있음, 유지"      ->  source 모델 + Live Preview

# Rekindle 을 쓰는 사람은 둘째 줄이야. 그래서 무거운 모델이 얻어주는 게 없어.

아빠는 그 조건에 안 걸려

아빠는 마크다운으로 사는 사람이야. vault 도 에세이도 사이트 콘텐츠도, 몇 년씩 써온 Sublime 과 Obsidian 과 iA 도 전부 source 모드였어. 마크업이 보이는 쪽을 스스로 골랐고, # 를 보고 싶어 해. 그런 사용자한테 WYSIWYG 모델은 매 순간 워크플로와 부딪혀. 의지하는 문자를 숨겨버리고, 직접 편집하면 그만인 파일에 파싱과 serialize 왕복을 강제하고, 순수한 소스를 읽고 싶어 하는 soul 기능들을 죄다 복잡하게 만들거든.

그래서 Rekindle 은 가벼운 길로 가. 소스가 모델이고, decoration 으로 만든 Live Preview 가 렌더된 모델 없이 렌더된 모습만 만들어줘. 커서 없는 줄에선 bold 가 bold 로 보이고, 편집 중인 줄에선 raw ** 가 보여. WYSIWYG 만큼 읽기 좋으면서 표현 셋을 유지하는 세금은 한 푼도 안 내는 거야. WYSIWYG 을 거부한 건 그게 나빠서가 아니야. 그걸 값어치 하게 만드는 유일한 조건이 여기선 안 맞아서지.

Code

결정은 한 조건으로 줄어들어·text

조건                                    맞는 모델
-------------------------------------  ----------------------------
"마크업이 절대 안 보여야 함"           WYSIWYG (rich-text 트리)
"마크업이 의미 있음, 보이게 유지"      source + Live Preview (decoration)

# Rekindle 을 쓰는 사람은 마크다운으로 사니까 둘째 줄이야.
# 그래서 무거운 WYSIWYG 모델은 얻어주는 것 없이 표현 셋만 비용으로 물려.

세 표현 (WYSIWYG) vs 하나 (source)·typescript

// WYSIWYG: 로드할 때 소스가 트리로 파싱되고, 트리 위에서 편집되고,
// 저장할 때 마크다운으로 serialize 돼. 맞춰줄 형태가 셋이야.
const tree = parseMarkdownToTree(source); // 로드
edit(tree);                               // 실제로 편집하는 모델
const markdown = serializeTreeToMarkdown(tree); // 저장

// source 모델: 로드한 문자열이 편집하는 문자열이고 저장하는 문자열이야.
// 형태는 하나. Live Preview 가 두 번째 모델 없이 모습만 칠해줘.
let doc = source; // 로드 == 편집 == 저장

Exercise

네가 만들 글쓰기 도구를 놓고 질문 하나에 정직하게 답해봐. 마크업 문자가 사용자한테 절대 안 보여야 해? 그렇다면 WYSIWYG 이 비용값을 하는 거야. 사용자가 소스를 봐도 괜찮거나 오히려 그쪽을 좋아한다면, 방금 rich-text 모델 하나와 표현 두 개를 아낀 거고. 그 대답 하나가 아키텍처를 얼마나 많이 정해버리는지 봐.

Hint

머릿속으로 그린 사용자 말고 실제 사용자가 누군지 정직하게 봐. 개발자나 마크다운 블로거, vault 지기는 보통 소스를 보고 싶어 해. 기술 쪽이 아닌 메모 작성자는 보통 마크업이 사라지길 원하고. 조건을 정하는 건 미학이 아니라 사용자야.