웹 에디터의 역사

요즘 시대에 많은 사람들이 글을 작성하기 위해 컴퓨터와 웹 브라우저를 사용하고 있습니다. 블로그, 이메일, 문서 등 브라우저에서는 지금 이 순간에도 수 많은 글들이 작성되고 있습니다. 현재는 너무나 당연하게 느껴지지만 웹에서 글을 작성하는 것은 매우 까다로운 일 중 하나였습니다. 과거 웹에서 글을 작성하는 것이 그토록 까다로웠던 이유는 무엇일까요? 또 현재는 그 문제를 어떻게 해결한 걸까요?

웹 에디터의 시작

1990년 팀 버너스리(Tim Berners-Lee)가 만든 최초의 웹 브라우저인 WWW(WorldWideWeb) 은 브라우저인 동시에 에디터로 만들어졌습니다. 사람들은 문서를 읽기만 할 뿐 아니라 직접 고치고 쓸 수 있었습니다. 버너스리가 꿈꾼 웹은 단순히 정보를 ‘읽는’ 공간이 아니라, 누구나 함께 ‘읽고 쓸 수 있는’ 협업의 공간이었습니다.¹

그러나 웹이 폭발적으로 성장하는 과정에서 브라우저들은 하나 둘 에디터의 기능을 잃어버렸고, 결국 한동안 웹은 에디터가 아닌 브라우저(읽기)의 역할만을 맡게 되었습니다. 여기에는 몇 가지 이유가 있었습니다.

첫째는 기술적인 문제였습니다. 최초의 WWW는 당시로서도 흔치 않았던 NeXT라는 특정 컴퓨터 위에서 만들어졌고, 편집 기능이 이 시스템에 깊게 묶여 있었습니다. 이러한 이유로 해당 기능은 다른 운영체제로 옮기기가 무척 어려웠습니다. 그래서 이후 여러 플랫폼으로 퍼져 나간 브라우저들은 편집 기능을 제거한 ‘읽기 전용’으로 만들어졌습니다.²

둘째는 대중화를 이끈 브라우저가 읽기 전용이었다는 점입니다. 1993년 등장한 모자이크(Mosaic)는 여러 플랫폼에 대한 지원과 함께 웹을 폭발적으로 대중화시켰지만 문서를 ‘보기’만 할 수 있을 뿐 편집할 수는 없었습니다. 가장 인기 있는 브라우저가 읽기 전용이 되자, 뒤따른 브라우저들도 자연스럽게 그 길을 따랐습니다.³

결과적으로 ‘글을 쓰는 일’은 브라우저 밖으로 밀려났습니다. 사람들은 메모장 같은 텍스트 편집기로 HTML 코드를 직접 작성하거나, 드림위버(Dreamweaver)·프론트페이지(FrontPage) 같은 전용 도구로 페이지를 만든 뒤 서버에 올리는 방식으로 글을 써야 했습니다. 편집 기능은 그렇게 브라우저에서 떨어져 별도의 도구로 분리되는 것처럼 보였습니다. ⁴

하지만 시간이 흐르며 상황은 다시 바뀌었습니다. 2000년대에 들어서면서 블로그, 위키, 게시판처럼 ‘누구나 글을 올리는’ 서비스가 빠르게 늘어났습니다. 더 이상 일부 전문가만 글을 쓰는 시대가 아니라, 모든 사용자가 웹에서 직접 콘텐츠를 만드는 시대가 된 것입니다. 처음 버너스리가 꿈꿨던 ‘읽고 쓰는 웹’이, 전혀 다른 방향에서 다시 요구되기 시작한 셈입니다.

문제는 ‘방법’이었습니다. 브라우저가 기본으로 제공하던 입력칸인 <textarea>는 글자만 넣을 수 있는 단순한 상자라, 굵은 글씨도 링크도 이미지도 표현할 수 없었습니다. 그렇다고 일반 사용자에게 HTML 태그를 직접 입력하라고 할 수도 없었습니다. 결국 “코드를 몰라도 브라우저 안에서 서식 있는 글을 쓰게 하려면 어떻게 해야 할까?” 라는 고민이 생겼습니다.

이 고민에 가장 먼저 답을 내놓은 것은 마이크로소프트였습니다. 그보다 앞서 문서 전체를 편집 모드로 바꾸는 designMode가 있었지만, 이 방식은 페이지를 통째로 편집 상태로 만들어야 해 일부만 고치기엔 번거로웠습니다. 그래서 평범한 HTML 요소 하나에 contenteditable="true" 한 줄만 붙이면 그 부분만 편집할 수 있게 해주는 contentEditable이 2000년경 인터넷 익스플로러 5.5에서 처음 등장했습니다. 이 한 줄만으로 사용자는 자유롭게 글자를 입력하고 서식을 적용할 수 있게 되었습니다. 이후 해당 속성에 대한 여러 브라우저의 지원이 이어졌고 그렇게 시간이 지나 이 기능은 HTML5 표준으로 자리 잡게 되었습니다.⁵

<!-- 해당 속성을 추가하면, 아래 영역이 편집 가능해집니다 -->
<div contenteditable="true">
  글자를 입력 및 굵게·기울임·링크까지 적용할 수 있다
</div>

이렇게 웹은 다시 ‘쓰기’를 지원하게 되었습니다. 그리고 이때 만들어진 contentEditable은 앞으로 살펴볼 모든 웹 에디터 이야기의 출발점이자 동시에 해결해야 할 가장 큰 문제가 됩니다.

contentEditable의 문제와 여러 해결방안

이렇게 편리해보이는 contentEditable은 왜 문제가 되었을까요? 그 이유는 contentEditable이 브라우저가 직접 제공하는 속성임에도 불구하고 그 동작이 신뢰하기 어려웠기 때문입니다. 2014년 당시 Medium 소속 소프트웨어 엔지니어 닉 산토스(Nick Santos)의 「Why ContentEditable is Terrible」라는 글을 통해서 왜 contentEditable이 끔찍한 문제가 되는지를 이야기했습니다.

무엇이 문제인가

contentEditable의 첫 번째 문제는 똑같이 보이는 화면이 서로 다른 HTML을 가질 수 있게 만든다는 점입니다. 예를 들어 “Baggins”라는 단어에 굵게(Bold)와 기울임(Italic)을 함께 적용한다고 해 봅시다. 화면에는 똑같이 굵고 기울어진 글자 하나로 보이지만, 그 안의 HTML은 <strong><em>Baggins</em></strong>일 수도 있고, 순서가 뒤바뀐 <em><strong>Baggins</strong></em>일 수도 있으며, 글자가 중간에 쪼개져 더 복잡하게 얽힌 형태일 수도 있습니다. 사용자 입장에서는 다 같은 글자지만, 편집 기능을 만드는 개발자는 이 모든 변형을 똑같이 다룰 수 있어야만 했습니다. 그렇지 않으면 어떤 글자는 멀쩡히 편집되는 반면 어떤 글자는 엉뚱하게 동작할 수 있기 때문입니다.⁶

여기에 더해, 브라우저는 종종 눈에 보이지 않는 마크업을 몰래 끼워 넣었습니다. 화면에는 아무 흔적도 없었지만 HTML에는 빈 <span>이나 보이지 않는 문자를 추가하여 동일해 보이는 두 영역을 전혀 다르게 동작하게 만들었습니다. 실제로 WebKit 엔진은 시각적으로 아무 의미도 없는 apple-style-span이라는 태그를 자동으로 집어넣곤 했고, 개발자들은 한참 뒤에야 이 ‘유령 마크업’을 찾아내 그것을 걷어내기 위한 작업에 매달려야 했습니다.⁶⁷

두 번째 문제는 커서가 여러 선택을 만든다는 점이었습니다. 사용자가 보기에 커서는 그저 “Baggins” 앞 한 자리에 깜빡이고 있을 뿐이지만 <strong><em>Baggins</em></strong>라는 구조에서 그 한 자리는 DOM 상으로는 여러 지점에 동시에 대응할 수 있습니다. <strong> 태그 바깥일 수도, <strong>과 <em> 사이일 수도, <em> 태그 안쪽일 수도 있는 것입니다. 그럼 만약 지금 글자를 입력한다면 굵게 처리가 될까요, 기울임 처리가 될까요, 아니면 아무 서식도 없을까요?⁶

마지막 문제는 이러한 모든 동작이 브라우저마다 다르다는 점이었습니다. 그래서 “파이어폭스에서 글을 쓰고, 크롬으로 옮겨 한 번 편집한 뒤, 다시 파이어폭스로 돌아와야만 재현되는” 종류의 버그들이 생겨났습니다. 같은 화면을 보고 있었음에도 내부에서 만들어지는 결과가 브라우저별로 제각각이니, 한쪽에서 멀쩡한 문서가 다른 쪽에서는 깨지는 일이 발생했습니다.⁶

이 글의 결론은 “임의의 HTML을 무엇이든 자유롭게 다루면서, 동시에 완벽한 위지윅(WYSIWYG, 보는 그대로 얻는 편집)인 에디터”는 본질적으로 만들 수 없다는 것입니다. 그는 이를 스티브 예기(Steve Yegge)가 말한 “존재하지 않는 짐승(The Nonesuch Beast)“에 빗대어 다음과 같이 표현했습니다.

“A good WYSIWYG editor is axiomatically inconsistent with a good general-purpose HTML editor. It’s impossible to build what ContentEditable wants to be, because they have conflicting requirements.”

두 목표는 애초에 서로 충돌하기 때문에, 둘 다 완벽하게 만족하는 에디터는 상상 속에만 있는 짐승이라는 이야기입니다.⁶ 그렇다면 contentEditable은 정말로 해결할 수 없는 문제일까요? 우리가 현재 사용하고 있는 에디터들은 어떻게 이 문제들을 극복한 걸까요?

첫 번째 해결방안: 정규화

이러한 문제에도 에디터를 다시 브라우저 밖으로 내보낼 수는 없었습니다. 2003년 WordPress가 등장하고 이른바 웹 2.0의 물결 속에서 사용자가 직접 만드는 콘텐츠가 폭발적으로 늘면서, 브라우저 안에서 서식 있는 글을 쓰는 일은 이제 선택이 아니라 필수가 되었기 때문입니다.⁴

이 무렵 등장한 TinyMCE(2004)나 CKEditor(2003년 FCKeditor로 출발) 같은 자바스크립트 라이브러리들이 택한 길은 분명했습니다. contentEditable을 버리는 대신 그대로 받아들이고, 그 위에 두꺼운 보정 층을 쌓아 실제로 쓸 만하게 만드는 것이었습니다.⁴⁸

이들은 contentEditable의 문제들을 방대한 보정 코드로 해결하려 했습니다. 똑같은 화면이 서로 다른 HTML이 되는 문제는 입력된 HTML을 미리 정한 규칙에 따라 다듬고 정규화(normalize)하는 방식으로 처리했고, 브라우저가 몰래 끼워 넣는 보이지 않는 마크업은 붙여넣기나 입력 시점에 걸러냈으며, 브라우저마다 다른 동작은 엔진별 예외 처리 코드를 따로 작성해 해결했습니다. 여기에 더해 편집 영역을 <iframe>으로 격리해, 호스트 페이지의 전역 CSS가 편집 영역의 서식을 망가뜨리지 못하게 막았습니다. 이렇게 쌓아 올린 보정 덕분에 TinyMCE·CKEditor는 여러 서비스에서 사용 가능한 제품 수준의 에디터가 되었고, 한동안은 이 방식이 충분히 잘 작동했습니다.

다만 이러한 대응에는 한계가 있었습니다. 결국 예측하기 어려운 DOM 위에 덧붙이는 사후 처리였기 때문입니다. 진실의 원천은 여전히 DOM이었기 때문에 새 브라우저 버전이 나오거나 예상하지 못한 입력이 들어올 때마다 또 다른 보정을 계속 더해야 했습니다. 이 모든 보정 아래에서 실제로 동작하는 것은 여전히 contentEditable이었고, “DOM에 쓰인 HTML이 곧 문서의 진실”이라는 전제도 그대로였습니다. 결국 이 방식은 문제가 드러날 때마다 사후에 바로잡는 대응이었을 뿐 문제의 원인 자체를 없앤 것은 아니었습니다.

두 번째 해결방안: 문서 모델

2010년대 중반 무렵, 에디터를 깊이 파고들던 개발자들은 한 가지 결론에 이르렀습니다. 브라우저에 의존하는 동작에만 기대서는 제품 수준의 에디터를 결코 만들 수 없다는 것이었습니다. 패치를 아무리 겹겹이 쌓아도, 진실의 원천이 변덕스러운 DOM인 한 문제를 해결하기는 어려워 보였습니다.

그렇다면 DOM을 진실의 원천으로 사용하지 않는다면 어떨까요? 해법은 발상을 뒤집는 데 있었습니다. 에디터가 자기만의 문서 모델(document model) 을 따로 두어 그것을 진실의 원천(source of truth)으로 삼고, DOM을 모델이 ‘그려지는 표면’으로만 사용하는 것입니다. 이러한 발상을 바탕으로 문서 모델을 자신만의 방식으로 구현한 여러 라이브러리들이 등장하기 시작했습니다.

Quill(2014) 은 문서를 Delta라는 JSON 데이터로 표현했습니다. 문단과 서식은 물론 ‘무엇이 어떻게 바뀌었는지’까지 모두 일련의 연산(operation) 목록으로 적은 것이 바로 이 Delta입니다. 그리고 이 데이터를 실제 화면으로 옮기는 일은 Parchment라는 문서 트리가 맡아, DOM을 직접 다루는 대신 한 겹의 문서 모델을 거치도록 했습니다. 문서와 변경을 모두 사람과 기계가 읽기 쉬운 데이터로 환원한 것이 Quill의 방식이었습니다.⁹

2년 뒤 등장한 Meta의 Draft.js(2016) 는 문서를 React의 상태(state)처럼 다뤘습니다. 문서 전체를 하나의 불변(immutable) 상태 객체로 두고 편집할 때마다 새 상태로 교체하는 방식으로 React의 단방향 데이터 흐름에 자연스럽게 맞물렸습니다. 다만 문서를 블록·인라인 두 층으로만 표현하는 한계 탓에 2023년 초 보관(archive) 처리되었고, 그 자리는 Meta가 새로 만든 Lexical이 잇게 됩니다.¹⁰

CodeMirror로 알려진 마레인 하버베커가 만든 ProseMirror(2017) 는 문서를 HTML이 아닌 자신만의 의미적(semantic) 트리로 정의했습니다. 먼저 스키마(schema)로 “어떤 구조가 허용되는가”를 규정하고, 모든 변경을 불변 트랜잭션(transaction)으로 만들어 한 지점에서만 처리하게 했습니다. 변화가 모두 하나의 통로를 거치니 문서가 어긋날 여지가 크게 줄었고, DOM은 이 트리를 비교해 바뀐 곳만 다시 그리는 표면이 되었습니다.¹¹

CKEditor 5(2018) 는 15년 된 기존 코드를 처음부터 새로 짜며, 커스텀 데이터 모델과 그것을 비추는 뷰(view)를 분명히 갈라놓았습니다. 모든 편집 기능은 모델 위에서만 동작하고 그 결과가 DOM에 자동으로 반영되며, contentEditable은 타이핑·선택·IME처럼 브라우저가 직접 맡아야 하는 일에만 남겨졌습니다.⁸

이러한 흐름을 통해 기존 에디터가 DOM을 진실의 원천으로 사용했다면, 이후의 에디터는 DOM을 모델이 그려지는 렌더링 표면으로만 사용한다는 것을 알 수 있습니다. 진실의 원천을 모델 한 곳으로 사용함으로써 똑같은 화면이 제각각의 HTML을 가지던 문제, 커서의 위치 문제, 브라우저마다 결과가 다르던 문제 등을 해결할 수 있게 되었습니다.

세 번째 해결방안: 캔버스

문서 모델이 “DOM을 진실의 원천이 아닌 렌더링 표면으로만 쓴다”면 세 번째 해결방안은 그 표면인 DOM 조차 사용하지 않는 방법이었습니다.

2021년 Google Docs는 DOM을 사용하지 않는 방법을 선택했습니다. 오랫동안 써 온 HTML/DOM 기반 렌더링을 버리고, 문서를 <canvas> 위에 직접 “그리는” 방식으로 전환한다고 발표한 것입니다.¹² The New Stack은 이를 두고 “DOM을 밀어냈다(Sidelining the DOM)“고 표현했습니다.¹³ 이러한 선택의 이유는 명확했습니다. 페이지 경계, 정확한 줄바꿈, 미세한 자간 같은 워드프로세서 수준의 정밀한 렌더링을 구현하는 것이 DOM으로는 매우 어렵기 때문입니다. 다만 화면 낭독기(screen reader)나 점자 기기 같은 보조 기술을 위한 ‘보조 DOM’은 별도로 유지한다고 밝혔습니다.¹²

이렇게 정규화에서 출발해 문서 모델을 거쳐 캔버스에 이르기까지, 세 해결방안을 관통하는 물음은 결국 하나였습니다. “문서를 브라우저의 DOM에 어디까지 맡길 것인가.” 정규화는 진실도 화면도 모두 DOM에 맡긴 채 그 결과를 보정했고, 문서 모델은 ‘진실’을 자신만의 모델로 사용하고 DOM에는 화면을 그리는 일만 남겨두었으며, 캔버스는 화면을 그리는 일마저 DOM에서 거둬들였습니다. 결국 contentEditable을 다루기 위한 여정은 편집에 있어 DOM에 어떠한 책임까지 위임할 것인지에 대한 고민이었던 것입니다. 오늘날 대부분의 에디터는 문서 모델에서 균형을 찾고 워드프로세서 수준의 정밀함이 필요한 소수의 에디터만이 캔버스 방식을 채택하고 있습니다. 각각의 방식이 저마다의 장단점을 가지는 만큼 요구사항을 잘 분석하여 상황에 맞는 것을 고르는 일이 중요합니다.

다시, 읽고 쓰는 웹

돌아보면 이 모든 이야기는 버너스리가 꿈꾼, 누구나 함께 ‘읽고 쓰는’ 웹에서 출발했습니다. 한때 브라우저는 ‘읽기’만 남기고 ‘쓰기’를 잃었었지만 contentEditable을 통해 ‘쓰기’를 되돌려 놓았고, 에디터들은 그것을 바탕으로 정규화, 문서 모델, 캔버스 등의 방법을 적용하며 불안정한 도구를 제품 수준까지 다져왔습니다. 이제 다음은 무엇일까요?

오늘날의 에디터는 또 다른 변화의 한가운데 있습니다. 문단·이미지를 저마다 독립된 ‘블록’으로 다루는 블록 기반 구조(ex. Notion·Gutenberg)¹⁴¹⁵, 2005년 Writely에서 출발한 Google Docs가 대중화한 실시간 협업¹⁶과 이를 중앙 서버 없이 풀어내는 CRDT(ex. Yjs)¹⁷, 그리고 사람보다 수십 배 빠르게 문서를 쏟아내는 AI까지, 저마다 에디터의 모습을 다시 그리고 있습니다.

오늘날의 웹 에디터는 더 이상 단순한 ‘텍스트 박스’가 아니라, 블록과 협업, 그리고 AI까지 떠받치는 하나의 프런트엔드 인프라(frontend infrastructure) 가 되었습니다. 그렇게 버너스리가 꿈꿨던 ‘함께 읽고 쓰는 웹’은, 이제 사람과 AI가 함께 읽고 쓰는 웹으로 다시 쓰이고 있습니다.

References

Footnotes

1. Tim Berners-Lee, The WorldWideWeb Browser · FAQ, W3C — 최초 브라우저가 “browser-editor”였고 ‘읽고 쓰는’ 협업 웹으로 구상됨. https://www.w3.org/People/Berners-Lee/WorldWideWeb.html · https://www.w3.org/People/Berners-Lee/FAQ.html ↩

2. WorldWideWeb, Wikipedia (Features·History 섹션) — 편집 기능이 NeXTSTEP에 묶여 이식이 어려웠고, 이후 편집 없는 “passive browser”가 등장. https://en.wikipedia.org/wiki/WorldWideWeb ↩

3. NCSA Mosaic · ViolaWWW, Wikipedia · History of edition and publishing in web browsers (2023) — 대중화를 이끈 모자이크(1993)는 보기 전용이었음. 인라인 이미지는 모자이크가 처음이 아니라 WWW 후기 버전과 ViolaWWW(1992)가 앞섰으나, 특정 환경에 묶여 있던 그 기능을 모자이크가 여러 플랫폼으로 대중화함(WWW의 인라인 이미지 지원은 ²의 출처 참고). https://en.wikipedia.org/wiki/NCSA_Mosaic · https://en.wikipedia.org/wiki/ViolaWWW · https://techno-barje.fr/post/2023/10/20/history-of-edition-and-publishing-in-web-browsers/ ↩

4. The Evolution of WYSIWYG Editors: From HTML Builders to Rich Text, Improving — 데스크톱 저작 도구(FrontPage 1995~·Dreamweaver 1997)에서 WordPress(2003)·Web 2.0를 거쳐 브라우저 내 편집(TinyMCE 2004·CKEditor)으로 넘어온 흐름, <iframe> 격리·툴바 방식, contentEditable을 떠나게 만든 동인(브라우저 간 불일치·모바일·XSS·성능)까지 폭넓게 정리. https://www.improving.com/thoughts/the-evolution-of-wysiwyg-editors-from-html-builders-to-rich-text/ ↩ ↩² ↩³

5. Native Rich-Text Editing with the contenteditable Attribute, Treehouse — “Internet Explorer was the first browser to implement this technology, way back in IE 5.5 (circa 2000).” / Online rich-text editor, Wikipedia · caniuse: contenteditable — IE 5.5(2000년경)가 contentEditable을 처음 구현. 모질라는 문서 전체 편집용 designMode(Midas)를 1.3(2003)에서 먼저 따라왔지만, 요소 단위 contentEditable 속성 지원은 Firefox 3(2008)에 이르러서였음. 이후 표준(WHATWG·HTML5)으로 자리 잡음. https://blog.teamtreehouse.com/native-rich-text-editing-with-the-contenteditable-attribute · https://en.wikipedia.org/wiki/Online_rich-text_editor · https://caniuse.com/contenteditable ↩

6. Nick Santos, Why ContentEditable is Terrible (Or: How the Medium Editor Works), Medium Engineering (2014) — 같은 화면이 제각각의 HTML이 되는 문제, 모호한 커서, 브라우저별 결과 차이, 그리고 “임의 HTML을 다루는 완벽한 WYSIWYG”이 정지 문제처럼 불가능하다는 결론(스티브 예기의 “The Nonesuch Beast” 인용). Medium 자체 에디터가 문단·구간 목록의 문서 모델을 둔 사례도 같은 글에서 소개. https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480 ↩ ↩² ↩³ ↩⁴ ↩⁵

7. Ryosuke Niwa, apple-style-span is gone, WebKit Blog — 시각적으로 무의미한 apple-style-span 마크업을 자동 삽입했다가 제거하기 위해 애쓴 사례. https://www.webkit.org/blog/1737/apple-style-span-is-gone/ ↩

8. CKEditor, Wikipedia — FCKeditor가 2003년 3월 처음 공개됐고, CKEditor 5는 2018년 코드를 처음부터 새로 짜 커스텀 데이터 모델과 실시간 협업을 토대에 넣고 출시됨. https://en.wikipedia.org/wiki/CKEditor · CKEditor 5 — The Future of Rich Text Editing, CKEditor 공식 블로그(2015) — 커스텀 JS 데이터 모델을 MVC로 두어 뷰(편집 가능한 HTML)를 모델의 표현으로만 삼고, contentEditable은 타이핑·선택 등 네이티브 처리에만 사용하며, 이 모델은 OT(운영 변환) 지원을 목표로 설계됨. https://ckeditor.com/blog/CKEditor-5-The-Future-of-Rich-Text-Editing/ ↩ ↩²

9. Delta · Designing the Delta Format, Quill 공식 문서 — Quill(2014)은 Parchment라는 문서 트리와 Delta라는 JSON 포맷으로 내용과 변경을 표현(사람과 기계 모두 읽기 쉬운 형식). 단, Quill 첫 공개는 2013~2014년이고 Parchment 문서 모델은 2017년 Quill 1.0에서 정식 도입됨. https://quilljs.com/docs/delta/ ↩

10. facebookarchive/draft-js, GitHub · Draft.js, draftjs.org — 메타(페이스북)가 만든 React용 리치텍스트 프레임워크로 2016년 React Conf에서 공개, immutable 모델 기반. 2023년 초 저장소가 보관(archive) 처리됨. 메타는 후속작 Lexical(2022)을 발표해 Draft.js를 대체함. https://github.com/facebook/draft-js · https://draftjs.org/ · https://lexical.dev/ ↩

11. ProseMirror Guide, prosemirror.net — 마레인 하버베커가 2015년부터 개발해 2017년 1.0 출시. 스키마로 허용 구조를 정의하고 모든 변경을 불변 트랜잭션(step)으로 처리하며, 자신을 완성된 장난감 자동차가 아니라 “조립용 레고 세트”에 가깝다고 설명. https://prosemirror.net/docs/guide/ ↩

12. Google Docs will now use canvas based rendering, Google Workspace Updates (2021-05) — Google은 Docs의 렌더링을 HTML 기반에서 canvas 기반으로 전환한다고 발표했으며, 화면 낭독기·점자 기기 등 보조 기술을 위한 접근성 지원은 계속 유지한다고 밝힘. https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html ↩ ↩²

13. Google Docs Switches to Canvas Rendering, Sidelining the DOM, The New Stack — Google Docs의 canvas 전환을 “DOM을 밀어냈다(Sidelining the DOM)“고 표현. https://thenewstack.io/google-docs-switches-to-canvas-rendering-sidelining-the-dom/ ↩

14. What’s New in WordPress 5.0 (Hello Gutenberg), Kinsta — Gutenberg 블록 에디터는 2018년 12월 출시된 WordPress 5.0에서 기본 에디터로 도입됨. https://kinsta.com/blog/wordpress-5-0/ ↩

15. Jake Teton-Landis, Exploring Notion’s Data Model: A Block-Based Architecture, Notion Blog (2021) — “모든 것이 블록”이라는 모델. 각 블록은 ID(UUID)·타입·속성·자식 블록 ID 배열·부모로 구성되며, 들여쓰기가 곧 트리 구조를 이룸. https://www.notion.com/blog/data-model-behind-notion ↩

16. Google Docs · Writely, Wikipedia — Writely가 2005년 출시되어 2006년 Google에 인수됐고, Google Docs가 OT 기반의 브라우저 실시간 협업을 대중화함. https://en.wikipedia.org/wiki/Google_Docs ↩

17. yjs, GitHub — 자바스크립트 진영의 대표적 CRDT 구현. https://github.com/yjs/yjs ↩