# Wordgard: ProseMirror 제작자의 브라우저용 리치 텍스트 편집기

> Clean Markdown view of GeekNews topic #31125. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31125](https://news.hada.io/topic?id=31125)
- GeekNews Markdown: [https://news.hada.io/topic/31125.md](https://news.hada.io/topic/31125.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-05T05:34:48+09:00
- Updated: 2026-07-05T05:34:48+09:00
- Original source: [wordgard.net](https://wordgard.net/)
- Points: 1
- Comments: 1

## Topic Body

- **Wordgard**는 브라우저에서 리치 텍스트 편집기를 만들기 위한 오픈소스 JavaScript 라이브러리로, ProseMirror 제작자가 만든 새 편집기 기반임
- 자유 형식 HTML 편집기보다 **문서 구조 통제**에 초점을 두며, 개발자가 허용할 콘텐츠 종류와 의미 구조를 정밀하게 정할 수 있음
- 복잡한 맞춤형 편집기를 겨냥해 **스키마 기반 모델**과 확장 중심 구조를 제공하고, 필요에 맞게 기능을 교체하거나 수정할 수 있음
- 접근성, 국제화, RTL·양방향 문서, 구조화 콘텐츠, 함수형 스타일, **협업 편집** 같은 요구사항을 편집기 기반에서 다룸
- MIT 라이선스의 허용적 오픈소스지만, 버그 리포트는 환영하고 **Pull request는 받지 않는** 운영 방식을 택함

---

### 문서 구조를 통제하는 편집기 기반
- **Wordgard**는 브라우저 내 리치 텍스트 편집기를 구현하는 오픈소스 JavaScript 라이브러리임
- 자유 형식 HTML 편집기가 아니라, 개발자가 지원할 콘텐츠의 종류와 문서 구조를 정확히 제어하는 **시맨틱 리치 텍스트 편집기 시스템**임
- 문서 구조를 정밀하게 정의하고 커스텀 문서 요소를 만들 수 있도록 **스키마 기반** 접근을 제공함
- 프로그래밍 인터페이스는 범용성과 유연성을 목표로 설계되어, 요구사항이 큰 맞춤형 편집기의 기반으로 쓰일 수 있음

### 확장성, 접근성, 협업 기능
- 대부분의 편집기 기능은 **확장(extension)** 으로 구현되어, 필요에 맞지 않으면 교체하거나 수정할 수 있음
- 접근성 기능은 스크린 리더 사용자, 키보드만 쓰는 사용자, 모바일 기기 환경을 고려하며 UI 국제화도 지원함
- 오른쪽에서 왼쪽으로 쓰는 환경을 위해 콘텐츠와 인터페이스 모두에서 **방향 인식**을 지원하고, 양방향 콘텐츠와 RTL 문서를 다룰 수 있음
- 문서 트리는 테이블, 중첩 리스트, 캡션이 있는 figure, 커스텀 구조 같은 **구조화 콘텐츠**를 포함할 수 있음
- 시스템의 큰 부분은 명확성과 테스트 가능성을 위해 함수형 스타일로 작성됨
- 여러 사용자가 같은 문서를 동시에 편집하고 동시 편집 내용을 병합하는 **협업 편집**을 지원함

### 라이선스와 프로젝트 운영
- 라이선스는 [MIT](https://code.haverbeke.berlin/wordgard/wordgard/src/branch/main/LICENSE)이며, 개발은 [code.haverbeke.berlin](https://code.haverbeke.berlin/wordgard/wordgard)에서 진행됨
- 버그 리포트는 환영하지만 [Pull request는 받지 않음](https://wordgard.net/docs/faq/#h-why-dont-you-take-pull-requests)
- 프로젝트 논의와 질문은 [forum](https://discuss.wordgard.net/) 이용이 권장되며, 버그는 [issue tracker](https://code.haverbeke.berlin/wordgard/wordgard/issues)에 보고해야 함

## Comments



### Comment 61265

- Author: neo
- Created: 2026-07-05T05:34:49+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48772573) 
- 대부분은 “왜?”를 알고 싶어 할 것 같음. 이 문서가 ProseMirror와의 차이를 다루고 있어서 그 질문에 가장 가까운 답이었음: [https://wordgard.net/docs/prosemirror/](<https://wordgard.net/docs/prosemirror/>)  
  한 가지 주목할 점은 **업그레이드 경로**가 없다는 것임. ProseMirror와 공유하는 개념은 많지만, 전환하려면 꽤 많은 작업이 필요해 보임. Obsidian은 CodeMirror 기반이라 바꾸지 않을 것 같지만, tiptap.dev 같은 곳은 영향이 있을 수 있음  
  @merijn, Wordgard가 전환 비용을 감수할 만큼 가치 있는 이유를 설명해 줄 수 있을지 궁금함  
  수정: Marijn의 개인 블로그에서 많은 쟁점이 다뤄진 걸 봤고, 더 나은 맥락을 위해 [https://marijnhaverbeke.nl/blog/wordgard-0.1.html](<https://marijnhaverbeke.nl/blog/wordgard-0.1.html>)을 HN에 제출했음
  - “Wordgard가 전환 비용을 감수할 만큼 가치 있는가?”에 대해서는 아닐 수도 있음. ProseMirror에 만족한다면 계속 ProseMirror를 쓰면 되고, 내가 계속 지원할 것임  
    다만 블로그 글에서 설명했듯 ProseMirror에서 부딪힌 몇 가지 문제를 피할 수 있는 **새 설계 통찰**이 꽤 쌓였고, 그래서 새 반복판을 만들고 싶어졌음  
    웹사이트 문서 섹션에 블로그 글 링크를 추가하겠음  
    그리고 이름은 merijn이 아니라 marijn임
  - 블로그에 “이제 ProseMirror 말장난도 별로 마음에 들지 않는다. CodeMirror인데 산문용이라는 뜻, 알겠죠?”라고 되어 있으니, 이제 누군가 **Codegard**를 만들 차례인 듯함
  - “전환 비용을 감수할 가치가 왜 있나?”가 진짜 궁금한 질문임. 더 중요하게는 왜 그냥 **ProseMirror v2**로 만들지 않았는지도 궁금함  
    랜딩 페이지에는 “무엇”보다 “왜”에 대한 정보가 더 필요해 보임

- 에디터와 별개로, 디자인을 맡은 아티스트가 정말 인상적임. 굉장히 세련됐고 눈에 확 띄었음: [https://kamilastankiewicz.com/](<https://kamilastankiewicz.com/>)
  - 같은 생각임. 정말 아름답고, 기존 웹사이트에 이런 **일러스트**를 넣으려면 비용이 어느 정도일지 궁금함
  - 그래픽이 놀라울 정도로 좋고 **Ghibli** 느낌도 남. 리치 텍스트 에디터 맥락에서 이런 말을 하게 되는 게 신기함

- 약 25년 전 학교 신문에 PHP-Nuke 사이트를 띄우기 위해 **위지윅 에디터**를 돌리는 게 큰 난관이었고, 결국 넘어섰던 기억이 있음  
  이런 기능에 대해 15년 전에 이미 통과된 웹 표준 구현이 없다는 게 말이 안 됨
  - contenteditable이 있고, Wordgard나 ProseMirror 같은 것들도 근본적으로는 그 위에 만들어짐. 나머지는 **사용자 인터페이스**와, 임의의 HTML 입력을 원하지 않는 시스템과의 상호운용성에 가까움
  - 오랫동안 브라우저 벤더들은 단순한 **텍스트 선택** 동작의 세부사항조차 합의하지 못했음

- 이건 놀라울 정도로 훌륭해 보임  
  최근 비슷한 걸 찾다가 결국 직접 만들었는데, 블록 기반 **운영 변환(OT)** 으로 로컬 서버에 동기화하고 원격 서버에는 차이 기반 동기화를 붙였음  
  시스템 가이드를 읽으면서 계속 고개를 끄덕이고 있음. 비슷한 점과 대비되는 점을 보니 꽤 검증받는 느낌임
  - ProseMirror는, 아마 Wordgard도 마찬가지로, 맞게 처리한 부분이 정말 많음

- 모든 에디터가 실패했던 아주 기본적인 영역이 하나 있음. iPhone으로 에디터 안에서 **완전한 문장**을 입력할 수 있느냐는 것임  
  Wordgard는 이 테스트를 통과하지 못했음. 자동 수정이나 키보드 추천에서 들어오는 입력이 삼켜지고, 부분적으로 입력했거나 철자가 틀린 단어가 삭제됨
  - ProseMirror는, 형제 댓글에서 말한 Lexical도 그렇고, 이 부분을 잘 처리할 수 있어야 함  
    모바일 Safari와 Android Chrome은 데스크톱 형제 브라우저와 달리 이상한 동작을 정말 많이 하고, 표준도 꽤 느슨하게 다룸. 그래서 제대로 동작하게 만들려면 긴 꼬리의 **우회 코드**가 필요해지는 경우가 많음  
    Wordgard도 결국 도달하겠지만, 첫 릴리스 전까지의 초점은 아키텍처였음
  - 몇 년 전에 웹 기반 리치 텍스트 에디터를 검토했었음. 데스크톱에서는 다 괜찮아 보였지만, 모바일에서는 시도한 것마다 엉망이었음  
    선택이 안 되고, 자동 수정이 깨지고, 텍스트를 눌러도 커서가 이동하지 않고, 입력이 멈추고, 요소가 포커스를 잃어도 키보드가 사라지지 않는 식이었음  
    지난 수십 년 동안 웹에 제대로 된 **리치 텍스트 요소**를 추가하려는 시도는 여러 번 있었지만 왜 다 실패했는지는 모르겠음. 크고 복잡하고 보상 없는 작업이라 그런 듯함  
    제대로 된 네이티브 리치 텍스트 지원은 웹의 큰 사각지대 중 하나임. 네이티브 플랫폼들은 수십 년 전에 해결한 문제임

- 약 6년 전 @ 스타일의 원격 리소스 자동완성, 즉 다른 사용자나 문서를 참조하는 기능을 조사하고 구현하느라 매우 고생했음. 이 에디터의 확장 방식은 ProseMirror의 진화형처럼 보임  
  이게 공룡 예제를 바탕으로 직접 만들어야 하는 게 아니라 **기본 내장 기능**이면 정말 좋겠음. 이런 텍스트 에디터 라이브러리를 쓸 때마다 1순위 사용 사례가 이것이고, 그다음이 위지윅임
  - @ 멘션 스타일이 기본 제공되고 API만 제공되면 훌륭할 것임  
    **일급 모바일 지원**도 마찬가지로 필요함

- ProseMirror를 TipTap으로 쓰면서 힘들었던 점은, 문서의 JSON 표현을 프로그램적으로 다뤄서 데이터를 추출해야 하는 경우가 아주 많다는 것임. 그러려면 정적 타입이 붙은 표현이 필요하거나, 적어도 강하게 선호하게 됨  
  ProseMirror에는 이를 위한 장치가 딱히 없어서 결국 둘 중 하나를 하게 됐음  
  1. 스키마를 두 번 정의함. 한 번은 ProseMirror로, 한 번은 Zod 같은 것으로 정의하고, 두 스키마가 일치하는지 확인하는 동등성 테스트를 잔뜩 둠  
  2. ProseMirror 스키마를 출력할 수 있는 **메타 스키마 정의 계층**을 만들되, 표준 스키마 명세 [https://standardschema.dev/](<https://standardschema.dev/>)를 따르게 함. 이 접근은 Tiptap 같은 것을 쓰지 않을 때 더 실용적임  
  Wordgard는 아직 써보지 않아서 이 문제를 다루는지 모르겠지만, 해결되면 좋을 고통 지점이라 짚어둠

- 웹사이트의 **아트워크**가 아름다움. 관심을 끄는 이런 방식이 새삼 잊혀졌던 것처럼 느껴짐
  - “AI 0% 포함”이기도 함. 이 아티스트는 정말 멋짐
  - 여기저기 **AI 쓰레기**가 넘치는 상황에서 손으로 그린 아름다운 일러스트를 보니 정말 상쾌함

- 웹에서 위지윅을 좋아하지 않음. 포럼 글을 길고 지루하게 서식 잡아놓고 탭을 닫으면 전부 사라짐  
  로컬 텍스트 에디터를 쓰고 웹 폼에 Ctrl+V로 붙여넣는 쪽을 선호함. Markdown이면 그렇게 할 수 있음
  - 어떤 플랫폼들은 localStorage로 이 문제를 해결하는 걸 봤음. 입력하는 동안 “초안”을 자동 저장하고, 페이지를 다시 열면 자연스럽게 복원함  
    실수로 탭을 닫은 뒤 처음 이걸 겪었을 때 정말 기분 좋은 놀라움이었음
  - Linear를 확인해 보길. 관계자는 아니지만, 바로 어제 실수로 대화상자를 닫았고 다시 이슈 생성을 눌렀더니 내가 쓴 긴 글이 그대로 있었음  
    요점은 이게 기술 문제가 아니라 **제품 문제**라는 것임
  - 경우에 따라 다름. 내 블로그에는 웹 기반 에디터가 있지만, 그냥 Markdown을 쓰고 미리보기를 붙인 형태라서 설명한 작업 흐름과 비슷함  
    노트 앱에는 위지윅을 쓰기로 했는데, 분할 보기를 둘 공간이 없고 Markdown 원문만 보고 싶지도 않았기 때문임  
    위지윅에 대한 가장 큰 불만은 방해가 될 수 있다는 점임. 예를 들어 verbatim 블록을 만들었는데 그 블록에서 빠져나올 수 없을 때가 있음. Teams를 보고 하는 말임. 그래서 LaTeX를 그렇게 좋아했던 것 같기도 함
  - ProseMirror와 다른 에디터용으로 좋은 **백엔드**들이 이미 있음. 설정하기 어렵지 않음
  - 동의하지만 많은 사람은 위지윅을 선호함. 단순하게는 여러 HTML 에디터나 Markdown 에디터처럼 **나란히 보기**를 두면 됨

- 오랜만에 진짜 **아트**를 보게 되어 정말 기쁨. 보기 좋음