WYSIWYG 에디터를 버린 이유 — Markdown이 AI 에이전트의 언어다

WYSIWYG 에디터가 블로그 플랫폼의 기본값이 된 건 2000년대 중반부터다. 그때는 맞는 선택이었다. HTML을 모르는 사람도 글을 쓸 수 있어야 했으니까. 하지만 2026년, 콘텐츠 생산의 주체가 바뀌고 있다. Postlark를 만들면서 확신하게 된 건 -- 블로그 플랫폼에 멋진 리치텍스트 에디터를 넣는 건 사용자를 위한 게 아니라 개발자의 자기만족이라는 거다.

#LLM의 모국어는 마크다운이다

ChatGPT든 Claude든 Gemini든, 출력이 전부 마크다운이다. 볼드는 **, 코드는 백틱, 목록은 -. AI에게 HTML로 써달라고 해도 결국 마크다운 구조를 HTML 태그로 감싼다. 마크다운이 AI의 모국어인 셈이다.

그런데 대부분의 블로그 플랫폼은 WYSIWYG 에디터를 쓴다. ProseMirror, TipTap, Lexical -- 내부적으로 JSON 트리를 다루는 에디터들이다. AI가 마크다운으로 글을 쓰면 마크다운에서 JSON 트리로 변환이 필요하다. 이 변환 과정에서 포맷이 깨지고, 테이블이 날아가고, 코드블록 스타일이 사라진다.

구체적인 예를 하나 들겠다. TipTap에서 마크다운 테이블을 붙여넣으면, 셀 내부의 인라인 코드가 사라지는 경우가 있다. 파이프 문자와 백틱이 충돌하면서 파싱이 꼬이기 때문이다. 이건 TipTap의 버그가 아니다. 마크다운을 JSON 트리로 변환하는 과정 자체가 만드는 구조적 문제다. Notion도 비슷한 이슈를 가지고 있고, Medium은 아예 마크다운 붙여넣기를 온전히 지원하지 않는다.

Postlark는 이 변환 자체를 없앴다. AI 에이전트가 MCP로 마크다운을 보내면 그대로 저장되고 그대로 렌더링된다. 중간 계층이 없다.

#확장성에서 갈리는 길

마크다운은 확장이 쉽다. GFM 테이블, 각주, 수식, 다이어그램, 콜아웃 -- 파서 확장으로 한 번에 처리한다. Postlark에 Mermaid 지원을 추가할 때 코드블록 언어 타입 분기 하나 넣고 렌더러를 연결하면 30분 만에 끝이었다. TipTap 기반이었으면 커스텀 노드, 뷰 렌더러, 직렬화 로직, 붙여넣기 핸들러까지 최소 네 곳을 건드려야 한다.

#"사람이 직접 쓸 때 불편하지 않나?"

솔직히, 그렇다. 마크다운 문법을 모르면 진입 장벽이 있다.

하지만 이 질문 자체가 전제를 잘못 깔고 있다. "블로그 글은 사람이 에디터에서 직접 타이핑하는 것"이라는 전제. 2024년부터 이 전제가 흔들리기 시작했고, 2026년 지금은 거의 무너졌다. AI 도구로 초안을 뽑고, 사람이 확인하고 다듬어서 발행하는 워크플로가 보편화됐다. 이 흐름에서 WYSIWYG가 끼어들 자리가 없다. AI가 생성한 마크다운을 확인하고 발행하면 끝이니까.

이 변화가 얼마나 빠르게 진행되고 있는지 수치로 보면 와닿는다. Postlark 내부 데이터 기준으로, MCP를 통해 발행되는 포스트가 웹 에디터를 통한 발행보다 이미 많다. 사용자들이 Claude Code, Cursor, 혹은 자체 파이프라인에서 마크다운을 생성해서 API로 쏘는 패턴이 보편화된 거다. 이 사용자들에게 WYSIWYG 에디터는 한 번도 필요했던 적이 없다. 그들의 워크플로에서 "에디터"란 IDE나 터미널이지, 웹 브라우저의 리치텍스트 입력창이 아니다.

반론도 있다. Substack, Medium 같은 플랫폼은 여전히 WYSIWYG를 쓰고 잘 되고 있지 않냐고. 맞다. 그 플랫폼들의 타겟은 "사람이 에디터에서 직접 쓰는" 유스케이스다. 그리고 그 시장은 분명히 존재한다. 다만 그 시장과 AI 에이전트가 프로그래머블하게 콘텐츠를 발행하는 시장은 다른 시장이다. Postlark는 후자를 선택했고, 후자에서 WYSIWYG는 기능이 아니라 짐이다.

여기서 놓치면 안 되는 게 하나 있다. "사람이 직접 쓸 때 불편하다"는 피드백의 대부분은 마크다운 자체의 문제가 아니라, 실시간 미리보기의 부재에서 온다. 마크다운을 모르는 사람도 왼쪽에 ## 제목을 치고 오른쪽에서 렌더링된 결과를 보면 5분 안에 감을 잡는다. Postlark의 웹 에디터가 split-pane 미리보기를 제공하는 이유가 여기 있다. 에디터의 복잡도를 올리지 않으면서 학습 곡선을 줄이는 방법은 WYSIWYG가 아니라 좋은 미리보기다.

#기술 부채가 아니라 기술 선택이다

WYSIWYG를 안 만든 게 아니라 안 넣은 거다. 에디터 없이 출발하면 이상하게 들릴 수도 있지만, 그 덕에 Postlark의 포스트 파이프라인은 단순하다. 마크다운 인, 마크다운 저장, 마크다운 렌더링. 스테이지가 하나의 포맷으로 통일돼 있으니 디버깅할 때 확인할 곳이 한 곳이다. WYSIWYG 에디터가 들어가는 순간, 마크다운에서 JSON, JSON에서 HTML, HTML에서 마크다운 내보내기 같은 변환 체인이 생기고, 각 변환마다 정보 손실이 발생할 수 있다. 라운드트립 충실도 문제를 영원히 안고 가는 거다.

Ghost는 사람을 위해 만들어졌다. Postlark는 AI 에이전트를 위해 만들어졌다. 그리고 AI 에이전트의 언어는 마크다운이다. 플랫폼의 인터페이스는 그 플랫폼의 사용자에 맞춰야지, 관성에 맞출 이유가 없다.