저는 아무것도 없는 상태에서 리치 텍스트 에디터를 만들었습니다. ProseMirror나 의존성 없이.
(dev.to)
기존의 ProseMirror나 Lexical 같은 의존성 없이 6만 줄의 코드로 직접 구축한 리치 텍스트 에디터 엔진 'Trevixal'이 공개되었으며, 이는 데이터 중심의 문서 모델과 강력한 확장성을 통해 에디터 개발의 새로운 패러다임을 제시합니다.
이 글의 핵심 포인트
- 1외부 라이브러리(ProseMirror, Lexical 등) 의존성 없이 6만 줄의 TypeScript/SCSS로 직접 구현
- 2문서를 HTML이 아닌 스키마 검증이 가능한 JSON 객체로 관리하여 데이터 일관성 확보
- 3모든 편집을 역전 가능한 단계(Invertible steps)로 처리하여 완벽한 Undo/Red도 시스템 구현
- 4LaTeX, Mermaid, PlantUML 등 강력한 다이어그램 및 수식 렌더링 기능 내장
- 5HTML, Markdown, Word, PDF 등 다양한 포맷으로의 정교한 내보내기 기능 지원
이 글에 대한 공공지능 분석
왜 중요한가?
기존 에디터 라이브러리의 한계인 의존성 문제와 엔진 자체의 버그 수정 어려움을 극복하기 위해, 엔진 자체를 재구축했다는 기술적 도전 정신과 완성도 측면에서 매우 중요합니다.
어떤 배경과 맥락이 있나?
현재 대부분의 에디터는 ProseMirror나 Slate 같은 기존 엔진 위에 레이어를 쌓는 방식인데, 이는 기능 확장이 어렵고 엔진 자체의 버기나 업데이트에 종속되는 문제를 야기합니다.
업계에 어떤 영향을 주나?
개발자들에게 '의존성 없는 엔진'이라는 새로운 선택지를 제공하며, 특히 복잡한 문서 처리 기능이 필요한 SaaS 제품 개발 시 커스텀 엔진의 효용성을 증명할 수 있는 사례가 될 것입니다.
한국 시장에 어떤 시사점이 있나?
고도화된 문서 편집 기능이 필요한 국내 협업 툴 및 에디터 스타트업들에게, 오픈소스 의존도를 낮추고 독자적인 기술 자산을 확보할 수 있는 기술적 영감을 줍니다.
이 글에 대한 큐레이터 의견
Trevixal의 등장은 '의존성 제로'라는 극단적인 기술적 순수성을 추구하며, 문서 모델을 HTML이 아닌 데이터(JSON)로 정의함으로써 데이터의 일관성과 확장성을 확보한 점이 탁월합니다. 이는 단순한 에디터를 넘어, 복잡한 워크플로우를 가진 SaaS 제품을 설계하는 창업자들에게 강력한 빌딩 블록이 될 수 있습니다.
하지만 6만 줄에 달하는 방대한 코드를 단일 개발자가 유지보수한다는 것은 장기적인 관점에서 운영 리스크가 매우 큽니다. 생태계가 형성되지 않은 독자 엔진은 버그 대응이나 브라우저 호환성 업데이트 측면에서 기존 거대 라이브러리(ProseMirror 등)에 비해 취약할 수 있다는 트레이드오프가 존재합니다.
따라서 창업자들은 이 엔진을 무조건적인 대체재로 보기보다는, 특정 도메인(예: 수식, 다이어그램이 중요한 공학용 툴)에 특화된 커스텀 에디터가 필요한 경우에 한해 전략적으로 도입을 검토해야 합니다. 기술적 자립도를 높이되, 유지보수 비용과 커뮤니티 지원 부재라는 리스크를 어떻게 상쇄할지 계산하는 것이 핵심입니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.