웹 기반 마크다운 에디터 만들기 - QWrite.md 개발 과정 (Milkdown 기반)
웹에서 동작하는 마크다운 에디터 QWrite.md를 직접 개발한 과정과 기술 선택에 대한 이야기. Milkdown과 ProseMirror를 활용해 WYSIWYG와 Markdown을 통합한 에디터 설계 경험을 정리했습니다.
Loading the article...마크다운으로 블로그나 개발 문서를 작성하다 보면 한 번쯤 이런 생각이 든다.
왜 딱 내가 원하는 에디터는 없을까?
이미 수많은 마크다운 에디터가 존재하지만, 막상 사용해보면 하나씩 아쉬운 점이 남는다.
그래서 결국 직접 만들기로 했다. 그 결과물이 바로 QWrite.md다.

🚀 바로 사용해보기
https://qwrite.qwer.dev설치 없이 브라우저에서 바로 사용하는 마크다운 에디터
리치 텍스트 ↔ 마크다운 전환, 슬래시 명령, GFM 지원
처음엔 단순했다.
괜찮은 에디터 하나 찾으면 되겠지.
하지만 여러 에디터를 써보면서 생각이 바뀌었다.
기능은 충분했지만, 내가 원하는 방식은 아니었다.
대표적으로 사용해본 에디터들:
| 에디터 | 특징 |
|---|---|
| StackEdit | 협업, 클라우드 중심 |
| Typora | 뛰어난 WYSIWYG, 하지만 유료 |
| Notion | 문서 관리 중심 |
| VSCode | 강력하지만 에디터로 쓰기엔 무거움 |
| 기본 메모 앱 | 가볍지만 기능 제한적 |
결국 공통된 문제는 하나였다.
기능은 많지만, 딱 맞지는 않는다.
특히 Typora는 가장 마음에 들었지만 유료화 이후 계속 사용하기 부담스러웠다.
또 많은 에디터들이 AI 기능을 기본으로 포함하고 있었는데, 개인적으로는 꼭 필요한 요소는 아니었다.
그래서 방향을 정리했다.
가볍고, 빠르고, 내가 통제할 수 있는 에디터.
요구사항은 생각보다 명확했다.
마크다운 단축키 지원
브라우저 기반 (설치 없음)
테이블 / 이미지 지원
GFM 지원
커스터마이징 가능
유지보수 가능한 구조
몇 가지 후보를 검토했다.
Meta에서 만든 프레임워크라 기대가 컸지만 결과는 맞지 않았다.
GFM 지원 부족
테이블 / 이미지 처리 한계
마크다운 ↔ 리치텍스트 변환의 어색함
다시 탐색하던 중 ProseMirror 기반 에디터를 알게 되었고, 그중 하나가 Milkdown이었다.
테스트해보자마자 방향이 정리됐다.

Milkdown의 핵심은 이 구조다.
Markdown ↔ AST ↔ Rich Text
이 구조 덕분에
마크다운
리치 텍스트
GFM
이 세 가지가 자연스럽게 연결된다.
단점도 있었다.
업데이트가 활발하지 않다는 점이다.
하지만 선택한 이유는 분명했다.
필요한 기능은 이미 충분했고
구조가 안정적이며
커스터마이징이 가능했기 때문이다
완벽한 최신 기술보다는 지금 문제를 해결할 수 있는 도구를 선택했다.
목표는 단순했다. Typora + Web
그래서 다음과 같이 설계했다.
WYSIWYG 모드 + Markdown 모드 통합
브라우저 기반 동작
슬래시 명령, 툴팁 등
가장 중요하게 생각한 건 하나였다.
글을 쓰는 동안 흐름이 끊기지 않게.
초기 개발은 빠르게 진행했다.
Milkdown 기반 에디터 구성
GPT / Gemini로 초기 세팅 가속
필요한 기능 중심으로 확장
여기서 중요하게 생각한 원칙이 하나 있다.
처음부터 완벽하게 만들려고 하지 않는다.
조금씩 만들고, 계속 개선한다.
이 방식은 실제로도 효과적이었다.
어느 정도 기능이 갖춰진 시점에서, 서비스를 배포했다.
가장 먼저 개선하고 싶은 부분은 파일 관리다.
File System API를 활용하면 다음이 가능해진다.
로컬 파일 읽기 / 쓰기
브라우저 기반 로컬 에디터 환경
장점:
설치 없이 로컬 환경 구성 가능
작업 흐름 개선
단점:
이미 관련 기능을 구현해본 적은 있지만, 현재는 우선순위에서 밀려 있다.