내가 직접 Markdown Editor를 만들려고 했지만 (현실이 크게 충격을 줬다)

발행: (2026년 2월 19일 오후 01:21 GMT+9)
10 분 소요
원문: Dev.to

I’m ready to translate the article for you, but I’ll need the full text you’d like translated (the content of the post itself). Please paste the article’s body here, and I’ll provide the Korean translation while keeping the source line and all formatting exactly as you requested.

Source:

2024년에 daylog를 시작했을 때, AI는 지금만큼 똑똑하지 않았어요

“모델에게 에디터 절반을 만들어 달라고 요청”하는 바로 가기가 없었기 때문에 대부분의 무거운 작업을 직접 해야 했습니다. 그때 나는 한 가지를 깨달았어요:

색상과 스타일이 적용된 텍스트 에디터를 만드는 것은 겉보기보다 훨씬 어렵다.

순진한 시작

daylog 은 마크다운을 지원하는 간단한 노트‑작성 웹 앱입니다. 적어도, 아직도 그 아이디어는 그대로예요.

시작할 때 나는 이렇게 생각했어요: “구문 강조가 있는 마크다운 에디터를 만드는 게 얼마나 어려울까?”

스포일러 #1: 매우 어려워요 (적어도 나에게는).

이 문제에 접근하는 방법은 크게 세 가지가 있습니다:

  1. 기존 라이브러리를 사용한다.
  2. 일반 <textarea> + 미리보기 창을 사용한다.
  3. 입력하면서 강조 표시를 해주는 완전 맞춤형 에디터를 만든다.

처음엔 기존 라이브러리에 의존하고 싶지 않았어요. 제어권을 원했기 때문에 옵션 2, 즉 <textarea>와 미리보기 패널부터 시작했습니다.

그 방법은 작동했으며, 제 요구에 정말 잘 맞았습니다.

GitHub Issues와 PR 에디터에서 영감을 얻었어요: 간단한 <textarea>, 작은 툴바, 아래에 미리보기. 깔끔하고 기능적이죠.

GitHub Issue Editor

하지만 몇 달 동안 직접 만든 앱을 사용해 보니 뭔가 불편했습니다. 너무 저렴하게 느껴졌거든요. 더 많은 시각적 피드백을 원했어요 – 굵은 텍스트, 헤딩, 리스트, 작업 항목을 즉시 확인하고 싶었고, 단순히 마크다운 기호만 보는 것이 아니라 말이죠. 그래서 레벨업을 결심했습니다.

“내가 직접 마크다운 에디터를 만들겠어.”

네, 그게 바로…

문제 #1 – <textarea> 장벽

HTML <textarea>부분 스타일링을 지원하지 않아요. 전체 색상은 바꿀 수 있지만 굵은 텍스트나 헤딩만 색칠할 수는 없습니다.

그래서 몇 가지 해킹을 시도했어요:

  • <textarea> 위에 <div>를 겹쳐 놓기.
  • 실제 내용을 숨기기.
  • contenteditable을 대신 사용하기.

이때부터 상황이 복잡해지기 시작했습니다.

문제 #2 – 커서 악몽

가짜 강조 레이어와 실제 <textarea> 사이의 커서를 동기화하는 것은 고통이에요:

  • 텍스트 선택? 깨짐.
  • 서식 적용? 정렬이 어긋남.
  • 빠르게 입력? 커서가 튀어오름.

contenteditable을 사용하면 선택 범위를 직접 관리하고, 캐럿을 이동시키고, 텍스트 노드를 재구성하면서 모든 것을 깨뜨리지 않으려 애써야 합니다.

가능하긴 하지만, 장기적으로 유지보수하기엔… 다른 이야기죠.

문제 #3 – 성능 현실 검증

  • 짧은 메모? 괜찮음.
  • 수천 줄에 달하는 대용량 문서? 매 키 입력마다 정규식 파싱을 하면 절대 괜찮지 않아요. 입력 지연이 발생하기 시작하고, 타이핑하고 결과가 1초 뒤에 나타나는 건 누구도 원하지 않죠. 글쓰기 도구에선 용납될 수 없습니다.

물론 “노트”는 크게 만들 필요가 없다고 할 수도 있지만, 사용자에게 제한을 두고 싶지는 않아요. 어느 순간 나는 스스로에게 물었습니다: “나는 노트 앱을 만들고 있는 건가… 아니면 코드 에디터를 만들고 있는 건가?”

Source:

The realization

한 달 동안 고군분투하고, 늦은 밤을 보내며, 커피를 너무 많이 마신 끝에 나는 깨달음을 얻었다: 내 목표는 텍스트‑에디터 엔진을 만드는 것이 아니었다. 내 목표는 daylog를 만드는 것이었다.

그래서 “모든 것을 직접 만들자”는 사고방식을 버리고 견고한 Markdown 에디터를 찾기 시작했다.

스포일러 #2: 이것도 쉬운 일은 아니었다.

Monaco: 너무 강력해서 오히려 방해가 됨

VS Code 뒤에 있는 코어 에디터인 Monaco를 떠올렸다. 완벽하게 들리지?

하지만…

  • 처음엔 통합이 쉬웠다.
  • 간단한 메모 앱에 비해 지나치게 무겁다.
  • 일반 CSS로 커스터마이징하기 어렵다.
  • 모바일 지원? 그다지 좋지 않다.
  • 모바일에서 커서와 키보드 동작? 고통스럽다.

Monaco는 놀랍지만 daylog에는 과도한 선택이었다… 그래서 다른 옵션을 찾아보았다.

다음과 같은 여러 옵션을 살펴보았다:

The winner: @uiw/react-md-editor

내가 이 라이브러리를 좋아한 이유:

  • 구현이 쉽다.
  • 설정이 가능하다.
  • <textarea> 캡슐화를 기반으로 한다.
  • 무거운 코드‑에디터 엔진이 없다.
  • Mermaid, KaTeX, GitHub‑flavored Markdown을 지원한다.
  • CSS 오버라이드로 스타일을 조정할 수 있다.

원래 내 아이디어와 딱 맞는 느낌이었다!

daylog에 이를 통합하고 몇 가지 커스텀 CSS를 적용했을 때 모든 것이 제자리를 찾았다:

  • 에디터가 보기 좋았다.
  • 반응형이었다.
  • 앱의 목적에 딱 맞았다.

daylog Note Editor with MDEditor

그리고 가장 중요한 것은, 이제 다른 예정된 기능들을 진행할 수 있게 되었고, 여기 dev.to에 공유했습니다!

내가 배운 점

  • 아마도 내 자체 에디터를 만드는 것을 너무 일찍 포기했을지도… 아닐 수도 있어요.
  • 확실히 좋은 학습 경험이 되었을 텐데요 – 분명히.
  • 내 제품 목표와는 맞지 않았어요 – 그렇지는 않아요.

때때로 모든 것을 처음부터 만드는 것은 자아심일 때도 있습니다.
때때로 그것은 학습이죠.
때때로 단순히 불필요한 고통일 뿐… (내 경우엔).

내 입장이라면 여러분은 어떻게 했을까요?
주요 제품이 아닌 무언가를 너무 깊게 구축한 적이 있나요? 여러분의 이야기를 듣고 싶어요.

코드를 보고 싶다면 daylog 저장소를 확인해 보세요:

https://github.com/artifacts-oss/daylog

[https://github.com/artifacts-oss/daylog](https://github.com/artifacts-oss/daylog)
0 조회
Back to Blog

관련 글

더 보기 »