Wordgard 0.1, ProseMirror 이후 9년의 편집기 설계를 다시 꺼냈어요

Wordgard 0.1, ProseMirror 이후 9년의 편집기 설계를 다시 꺼냈어요

AI 뉴스 썸네일

웹에서 문서 편집기를 만들 때 ProseMirror는 여전히 강한 선택지예요. 그런데 ProseMirror와 CodeMirror를 만든 Marijn Haverbeke가 새 리치 텍스트 편집기 라이브러리 Wordgard 0.1을 공개했어요. 기존 프로젝트를 조금 고친 버전이 아니라, 9년 동안 쌓인 불편함을 새 API와 새 이름으로 다시 정리한 작업에 가까워요.

728x90

핵심 요약

구분	핵심	왜 볼 만한가요
새 편집기 라이브러리	Wordgard 0.1은 ProseMirror 계열 아이디어를 다시 설계한 JavaScript 리치 텍스트 편집기예요	웹앱에서 문서 편집, 노션형 인터페이스, 협업 편집을 다루는 팀이 참고할 만해요
변경 모델	ProseMirror의 steps 대신 변경 섹션 기반 모델을 써요	복수 변경, undo, 협업 편집 같은 기능을 더 단순하게 다루려는 시도예요
확장 방식	CodeMirror 6의 facet 개념을 거의 그대로 가져와요	플러그인 순서에 의존하던 확장 구조를 더 잘게 나눌 수 있어요
브라우저 처리	포인터와 키보드 선택을 직접 처리하고, 입력은 beforeinput 중심으로 받아요	브라우저별 커서·선택 버그를 줄이려는 방향이에요
운영 방식	MIT 라이선스지만 pull request는 받지 않는 실험을 해요	AI 코드 생성 이후 오픈소스 유지보수 부담을 어떻게 다룰지 보여 주는 사례예요

1. ProseMirror 2.0 대신 새 이름을 택한 리치 텍스트 편집기

Wordgard 0.1은 브라우저 DOM 위에서 동작하는 JavaScript 리치 텍스트 편집기 라이브러리예요. 작성자는 ProseMirror를 계속 유지하지만, 오래된 설계 일부를 지금 기준으로 다시 만들고 싶어 새 프로젝트를 열었다고 설명해요. ProseMirror 2.0처럼 비호환 버전을 내면 이름이 가리키는 대상이 흐려지고, 1.x에 새 구조를 억지로 붙이면 API가 지저분해질 수 있다고 봤어요. 그래서 Wordgard는 ProseMirror의 많은 생각을 이어받되, 호환성 부담 없이 새 API로 출발해요. 1

첫 번째 차이는 변경을 표현하는 방식이에요. ProseMirror는 steps라는 원자적 변경 단위를 이어 붙여 문서 갱신을 표현해요. Wordgard는 CodeMirror의 변경 표현과 ShareJS의 delta 형식에서 온 섹션 기반 모델을 써요. 예를 들어 일부 구간은 그대로 두고, 어떤 구간은 교체하고, 어떤 구간은 굵게 표시하는 식으로 한 변경 안에 상태를 담아요. 리치 텍스트라서 단순 문자열이 아니라 노드 열기·닫기 토큰과 리프 토큰까지 다루지만, 작성자는 이 모델이 변경 합성과 검사를 더 쉽게 만든다고 설명해요. 2

이 설계는 협업 편집에도 연결돼요. Wordgard는 같은 시작 문서에서 나온 여러 변경을 합칠 수 있도록 제한적인 운영 변환을 지원해요. 문서 구조가 깨질 수 있는 경우에는 fix-up change를 만들어 두 변경 순서가 같은 유효 문서로 수렴하게 해요. 개발자 입장에서는 “문서가 실제로 어떤 범위에서 바뀌었는지”를 따라가는 부담을 줄이려는 선택으로 볼 수 있어요. 2

스키마 쪽도 ProseMirror와 달라요. Wordgard에서는 노드와 마크 타입이 특정 스키마 안에만 갇히지 않고, 여러 문서 스키마에서 함께 쓸 수 있는 독립 객체로 다뤄져요. 텍스트 정렬이나 이미지 대체 텍스트처럼 특정 노드 속성으로 붙던 기능도 마크 쪽으로 일반화해 더 모듈식으로 추가할 수 있게 했어요. 문서 구조 제약도 더 느슨해졌어요. 정규식 기반 콘텐츠 순서 제약을 버리고, 필요한 경우 correction이라는 보정 프로그램으로 문서 형태를 다루는 쪽을 택했어요. 2

확장 시스템은 CodeMirror 6의 facet 방식에 가깝게 움직여요. ProseMirror 플러그인은 배열 순서가 우선순위에 영향을 주고, 하나의 플러그인이 여러 역할을 함께 맡을 때 미묘한 문제가 생길 수 있어요. Wordgard는 타입이 있는 확장 지점을 두고, 각 확장 값이 자체 우선순위를 가질 수 있게 해요. 이벤트 핸들러, 편집기 속성, 상태 조각을 확장 트리로 묶는 방식이라 기능 단위를 더 작게 조합할 수 있어요. 2

브라우저 의존을 줄인 점도 눈에 띄어요. ProseMirror는 브라우저의 네이티브 선택 동작에 기대는 부분이 많았고, 양방향 텍스트나 특이한 스타일에서 커서가 이상하게 움직이는 문제가 있었어요. Wordgard는 포인터와 키보드 기반 선택을 거의 직접 처리해요. 다만 터치 선택은 네이티브 컨텍스트 메뉴가 깨질 수 있어서 브라우저 구현을 유지해요. 입력 처리도 DOM 변경 감시에 기대기보다 beforeinput 이벤트를 중심으로 가져가요. 아직 실제 사용 환경 검증이 더 필요하지만, 오래된 우회 구현을 덜어내려는 방향은 분명해요. 2

현재 상태는 0.1이에요. npm에서 `wordgard`로 설치할 수 있고, 공식 사이트와 참조 매뉴얼도 공개돼 있어요. 작성자는 핵심 인터페이스가 원하는 기능 대부분을 담고 있지만, 실제 작업에 쓰이기 전까지는 문제가 더 드러날 수 있다고 봐요. 그래서 적어도 1년 정도는 0.x 버전에 머물며 피드백과 버그 수정을 받을 계획이에요. 2

마지막으로 오픈소스 운영 방식도 꽤 직접적이에요. Wordgard는 MIT 라이선스로 공개됐지만, 작성자는 pull request를 받지 않는 실험을 하겠다고 밝혔어요. 큰 변경을 리뷰하고 조율하는 일이 직접 구현하는 것보다 더 오래 걸리는 경우가 많고, AI 코드 생성 비용이 낮아지면서 관리자가 “던져진 코드”를 검토해야 하는 부담이 더 커졌다는 이유예요. 소프트웨어는 언어 모델 없이 직접 설계하고 만들었다고도 적었어요. 2

왜 중요한가요

리치 텍스트 편집기는 겉으로 보면 입력창 하나처럼 보여요. 실제로는 문서 모델, 스키마, undo, 협업 편집, 브라우저 선택 동작, 모바일 터치까지 엮인 어려운 문제예요. Wordgard 0.1은 이 문제를 다시 푼 라이브러리라서, 지금 당장 모든 팀이 갈아탈 대상이라기보다 “다음 세대 웹 편집기는 어디를 덜어내고 어디를 직접 다뤄야 하나”를 보여 주는 자료에 가까워요. 2

웹 제품을 만드는 팀에는 두 가지 관점이 있어요. 새 프로젝트에서 문서 편집 기능을 깊게 다룬다면 Wordgard의 변경 모델과 facet 확장 구조를 읽어 볼 만해요. 이미 ProseMirror를 쓰고 있다면 당장 이전을 판단하기보다, 어떤 불편함이 새 설계의 출발점이 됐는지 확인하는 쪽이 현실적이에요. 2

오픈소스 유지보수 관점도 남아요. 코드 생성 도구가 흔해질수록 관리자는 더 많은 외부 코드를 검토해야 해요. Wordgard의 “pull request를 받지 않는다”는 선택은 극단적으로 보일 수 있지만, 작은 핵심 라이브러리를 오래 유지하는 개발자가 어떤 피로를 느끼는지 꽤 솔직하게 보여 줘요. 기술 설계와 운영 방식이 같은 글 안에서 함께 드러난다는 점에서 읽어 볼 만한 릴리스예요. 2

참고 자료

1. Wordgard 0.1 릴리스 — GeekNews
2. Wordgard Release 0.1 — Marijn Haverbeke