"요즘은 서브라임 텍스트 같은 물건을 안 만든다"는 한탄에 공감한 개발자가 적지 않았던 모양이다. 개발자 dbushell은 여기서 한 발 더 나아가, 아예 자신만의 텍스트 에디터를 직접 만들어 보기로 했다. 거창한 제품 출시가 아니라 "질리기 전까지"라는 단서가 붙은 개인 실험이지만, 웹 기술로 코드 에디터를 구현할 때 부딪히는 근본적인 선택지들을 압축해 보여준다는 점에서 실무자가 곱씹어 볼 만한 기록이다.
세 가지 렌더링 접근과 각각의 벽
출발점은 VS Code의 기반인 Monaco 에디터에 대한 불만이었다. 그는 Monaco를 수많은 `가 뒤엉킨 구조라고 표현하며, 성능 좋은 애플 실리콘 맥이 그 무거움을 가려줄 뿐이라고 봤다. 그래서 첫 실험은 정반대 방향, 즉 모든 텍스트를 에 그리는 방식이었다. 캔버스는 60~120fps로 화면을 다시 그리느라 CPU를 상당히 쓰지만 겉으로는 티가 나지 않는다. 문제는 캔버스가 아무것도 공짜로 주지 않는다는 점이다. 텍스트 선택, 커서, 스크롤바 같은 기본 요소를 전부 손으로 구현해야 한다.
대표적인 우회로가 스크롤바다. 탄력 스크롤을 직접 만드는 대신, 캔버스 텍스트 크기에 맞춘 숨겨진 를 하나 두고 그 요소의 네이티브 오버플로 스크롤 위치를 읽어 캔버스의 렌더링 오프셋을 계산하는 식이다. 브라우저가 이미 잘 만들어 둔 기능을 빌려 쓰는 전형적인 절충이다. 하지만 그는 곧 더 큰 문제에 부딪힌다. 캔버스는 화면에 픽셀을 그릴 뿐이어서 스크린 리더 같은 접근성 도구가 내용을 전혀 인식하지 못한다. 선택 기능을 계속 붙여봐야 이 근본적인 접근성 결함은 풀리지 않는다.
브라우저가 공짜로 주는 것들을 되찾기
그래서 방향을 튼다. 텍스트를 캔버스에 그리는 대신 오버플로용 에 그대로 네이티브로 렌더링하고 contenteditable 속성으로 편집 가능하게 만드는 것이다. 특히 plaintext-only 값은 코드 편집에 잘 맞고, 모든 내용이 하나의 텍스트 노드 안에 유지된다. 이 전환의 이점은 분명하다. 텍스트 선택, 실행 취소 히스토리, 그리고 접근성 지원을 브라우저가 알아서 처리해 준다. 커서는 Selection API가 제공하는 위치 정보를 받아 직접 그리고, ::selection으로 선택 영역 스타일도 손볼 수 있다.
다만 세부에서 함정이 도사린다. 그는 spellcheck 같은 속성을 꺼야 입력 지연 급증을 막을 수 있다는 사실을 알아내는 데 며칠이 걸렸다고 털어놓는다. 또한 네이티브 커서 색을 투명으로 숨기고 커스텀 커서를 그리는 방식은 편법에 가깝다고 스스로 인정한다. 더 큰 문제는 성능이다. 일정 글자 수를 넘어서면 contenteditable에서 이상한 성능 저하가 나타나는데, 크로미움 계열이 웹킷이나 파이어폭스보다 나빴고 그마저도 예측하기 어려웠다.
결국 가장 단순한
결론은 다소 김이 빠지면서도 실용적이다. 긴 텍스트에서는 소박한 가 오히려 훨씬 빠르더라는 것이다. 대신 는 CSS 하이라이트를 쓸 수 없어 구문 강조를 위해 별도의 레이어가 필요하다. 그는 데모에서 보이는 줄만 로 겹쳐 MicroLighter로 색을 입히는 방식으로 처리했다. 원래 계획이던 contenteditable의 커스텀 ::highlight는 하이라이트가 너무 많아지면 그 자체가 성능 병목이 된다는 한계도 함께 지적한다. 그는 새로 등장한 OpaqueRange API가 에서도 커스텀 하이라이트를 열어주고, EditContext API가 캔버스 입력을 개선한다는 후속 정보도 덧붙였다.
더 견고한 해법으로는 Tree-sitter로 구문 트리를 만든 뒤 화면에 보이는 줄에 대해서만 하이라이트를 생성하는 방식을 꼽는다. 다만 그가 실제로 다룰 파일 크기는 성능 한계선에 닿지 않으므로 contenteditable로 되돌아가도 무방하다고 본다. 정답이 하나로 정해져 있지 않고, 편집 대상의 규모와 요구 접근성에 따라 선택이 갈린다는 점이 이 실험의 핵심 교훈이다.
실무자에게 남는 시사점
그는 지금 상태를 "기능의 1%로 텍스트 에디터의 90%를 만든 셈"이라고 요약한다. 여기서 나머지를 채우는 일 자체는 어렵지 않지만, 탭 들여쓰기 같은 사소해 보이는 처리들이 발목을 잡는다. 현재는 탭 키를 가로채 공백 두 칸을 넣는 임시방편을 쓰고 있을 뿐이다. 또 하나 놓치기 쉬운 함정으로 자바스크립트 문자열과 텍스트 범위가 UTF-16 코드 단위로 동작한다는 점을 든다. 이모지나 특정 문자를 다룰 때 순진하게 인덱스를 세면 버그가 쉽게 스며든다는 경고다.
이 글은 완성된 라이브러리를 소개하는 대신, 웹에서 에디터를 만들 때의 선택지를 실험으로 훑는다. 캔버스는 렌더링 자유도를 주지만 접근성과 기본 기능을 모두 스스로 짊어져야 하고, contenteditable은 브라우저의 공짜 기능을 되찾는 대신 규모가 커지면 성능이 흔들리며, `는 가장 견고하지만 구문 강조를 겹겹의 레이어로 얹어야 한다. 저자 스스로 데모가 최적화되지 않았고 접근성도 완벽하지 않다고 인정하며 프로젝트를 "비 오는 날"을 위해 접어 두었다. 그럼에도 캔버스로 처음부터 다시 시작하는 것보다는 훨씬 나은 자리에 있다는 그의 판단은, 비슷한 편집 UI를 고민하는 개발자에게 어느 지점에서 타협해야 하는지를 미리 일러 준다.