블로그용 위지윅 에디터 개발기

2026.08.30
대표 이미지

2024 초기 에디터 → 2025 리팩토링 → 2026 최종 에디터.

만들다 두 번 포기했고, AI로 완성했습니다.


과거의 에디터 프로젝트

2024년에 개발하다가 포기했던 **Custom 위지윅 에디터**가 있습니다.

[에디터 페이지 방문](https://editor-sandy.vercel.app) / [깃헙 레포](https://github.com/vavoya/editor)

에디터에 대해서 아는 게 없던 상태였기에, 다음과 같이 조사부터 했습니다.

  • Obsidian 편집기, 네이버 블로그 에디터(에디터 자체와 네이버 에디터 설명 영상), 그 외 블로그 에디터들을 개발자 도구로 요소와 동작 분석

  • MDN 개발 문서에서 caret, selection과 연관된 Web API 전부 훑어보기

대학 4학년 때 한 거라 경험이 적었습니다. 개발에 대한 생각도 부족하다 보니 기능 구현에만 집중했고, 코드 건강도는 신경 쓰지 못한 채 하나의 파일에 무작정 800줄을 박았었습니다.


이걸 개발하면서 들었던 생각이 아직도 기억납니다.

'구현해야 하는 목표는 있고 어떻게 구현하면 되는지도 알겠는데, 이렇게 하는 게 정답일까? 이렇게 하는 게 맞는 건가?'


예를 들면, 현재 caret에서 방향키를 아래로 내렸을 때 대략 2가지 방법이 있습니다.

  1. x, y 좌표를 탐색하며 아래 element 감지

  2. caret 기준 문자를 1개씩 읽으며 x, y 좌표 탐색

뭐로 구현하는 게 정답인지를 모르니, 그걸 고민하는 데 시간을 소모했습니다.

이외에도 caret의 상하 이동은 매 순간의 x 위치가 아니라 처음의 x 위치로 판정한다는 등, 자잘한 기능도 하나하나 신경 써야 합니다.


마크다운 파서

2025년에 마크다운 에디터를 포기했습니다. 이유는 두 가지입니다.

  1. 상용 라이브러리를 따라갈 수 없다

  2. 그에 맞는 수준을 위해서는 더 많은 조사와 복잡한 설계가 필요하다


그럼에도 npm에 풀린 라이브러리 중에는 제 요구사항(Obsidian 편집기 스타일)을 만족하는 에디터가 없었습니다. 그래서 Velog나 Github 등에서도 쓰는 미리보기 방식으로 방향을 틀었습니다.

그렇게 개발한 게 **마크다운 AST 파서**입니다. [npm 링크](https://www.npmjs.com/package/md-ast-parser)


이 프로젝트에서 신경 쓴 부분입니다.

  1. FP(함수형 프로그래밍) 책을 읽은 뒤라, 불변성과 순수 함수 등 FP 개념을 일부 적용했습니다.

  2. 파서는 순수 함수 형식을 띱니다. 같은 raw 문자열을 입력하면 동일한 Block을 반환합니다. 이 성질을 이용해 LRU 캐시를 적용했습니다.

  3. 접두어 매칭(prefix) 방식을 사용해 문법 매칭을 O(k) 수준으로 찾게 했습니다.


그 외에도 신경 쓴 게 더 있는데, 작성 시점 기준으로 1년 넘은 프로젝트라 기억이 더 나지 않습니다.

이렇게 만든 마크다운 파서에 미리보기를 붙여 이 블로그 플랫폼에 적용했습니다. (현재는 아닙니다)


최종적인 위지윅 에디터

[NPM 링크](https://www.npmjs.com/package/react-md-ast-editor)

회사에서 개발자로 일하면서 많은 AI를 사용해봤습니다. 그동안 AI의 업무 처리 가능 영역이 꾸준히 넓어져 오는 것을 체감했습니다.

사내에서 쓰려고 마크다운 위지윅 에디터를 AI 바이브 코딩으로 만들어본 적도 있습니다. 제가 원하던 방향으로 나오긴 했지만, 이때는 제가 에디터를 직접 구현하면서 알아낸 내용들을 반영하지 않았습니다.

그래서 이번엔 이런 생각이 들었습니다. 이렇게 발전된 AI를 활용하면, 내가 원하는 에디터를 완벽하게 구현할 수 있지 않을까.


작업을 AI에게 지시하니, 제가 이전에 개발했던 프로젝트를 참고하며 개발을 진행했습니다. 문제는 이전 설계에 미흡한 점이 있었다는 겁니다. AI가 그걸 그대로 가져와서 개발했기에 기능 불량도 있었습니다. 다만 요즘 Claude는 직접 브라우저를 다루면서 테스트를 하기에, Claude와 개발자(저)가 서로 검증하면서 빠르게 기능 수정이 가능했습니다.


하지만 AI를 믿지 않기 때문에, 수정할 때마다 이렇게 반복 지시했습니다.

'떔빵 하지 말고, 설계에 문제가 있는지 확인하고 문제가 있으면 설계를 고치고 그걸 코드에 반영해라'

덕분에 빠르게 개발이 완료되어 NPM에 배포하고, 블로그 플랫폼에도 적용해 업데이트할 수 있었습니다.


![스크린샷 2026-08-31 오전 7.54.52.png](https://pub-6ece89a8bceb4744ab36f4c6c2fed32a.r2.dev/684e6a789552b75f411685fa/1788133231739-c1b1fd5b-3aaf-4b43-b136-336eae2f05a0.png)스크린샷 2026-08-31 오전 7.54.52.png

이렇게 보니 IME 입력 이벤트도 신경 써서 개발했던 게 떠오릅니다. 네이버 에디터도 IME 때문에 고생했다고 했습니다.

2024~2025년에 끝내 완성 못 하고 삽질로 끝났던 걸 AI 덕분에 끝냈다는 게 떨떠름합니다. 어쨌든 성능 최적화도 했고, 이미지 관리 방식 구상을 비롯해 원하던 기능도 잘 돌아가게 완성되었습니다.


생각

여전히 AI가 이렇게 발전하고 있는 것이 저한테 긍정적인지 부정적인지 판단이 서질 않습니다. 이전까지는 AI에 부정적이었지만, 이렇게 제가 구현하고 싶었던 걸 결국 완성해낼 수 있었던 걸 생각하면 긍정적이기도 합니다.


사실 모르겠습니다. 좋은 거 같기도 하고 안 좋은 거 같기도 하고.


완성된 편집기 캡쳐

![스크린샷 2026-08-31 오전 7.59.44.png](https://pub-6ece89a8bceb4744ab36f4c6c2fed32a.r2.dev/684e6a789552b75f411685fa/1788133232808-812f787b-83a1-467f-98f2-ef6b738484db.png)스크린샷 2026-08-31 오전 7.59.44.png

블로그용 위지윅 에디터 개발기 - sim-log