리치 텍스트 에디터 통일 분석

Tiptap vs @uiw/react-md-editor — 2026 최적 방식과 HTML 통일 타당성을 현 레포 + beta 실데이터로 검증

대상: 앱린다(send-grid-test) · admin 프론트엔드 / beta DB 실데이터 · 2026-06-16

결론 (TL;DR)

→ Tiptap(HTML 출력) 단일화. MDEditor 제거.

도메인 적합성: 이 제품의 쓰기 산출물은 거의 전부 이메일 HTML(서명·템플릿·시퀀스·답장). markdown은 table/inline-style 표현력이 부족해 구조적 미스핏.
실데이터가 이미 HTML: 에디터 원본 저장 테이블에서 markdown 포맷 0건, HTML 81~98%. MDEditor를 쓰는데도 DB엔 markdown이 없음 = markdown 에디터에 HTML을 넣는 오용.
발송 text 파트는 자동 파생 중: 발송 이메일의 99.9%가 text/plain 동시 포함(multipart). 에디터를 HTML로 통일해도 text는 서버 html→text 변환으로 계속 생성 — plain text는 폐기 대상이 아니라 발송 레이어에서 유지.
현재 분열: 같은 도메인(서명·템플릿·시퀀스)에 Tiptap과 MDEditor가 중복 공존 → 출력 포맷 drift 위험.

1. 현황 — 두 에디터가 같은 도메인에 공존

현 레포 admin/src 전수 grep 결과. Tiptap 12곳, MDEditor(RichTextEditor 래퍼) 4곳. 핵심 도메인이 겹친다.

@tiptap 3.20

12+ 사용처 (사실상 표준)

@uiw/react-md-editor 4.0.8

4 사용처 (제거 후보)

3 도메인

서명·템플릿·시퀀스 중복

도메인	Tiptap (HTML, WYSIWYG)	MDEditor (markdown raw)	상태
이메일 서명	InlineSignatureEditor, EmailSignatureManagement	SignatureEditorModal	중복
이메일 템플릿	EmailTemplateCreateForm	EmailTemplateForm	중복
시퀀스 단계	EmailEditorPanel	SequenceStepForm, SequenceLaunchModalStepEditor	중복
답장/인박스	NewEmailComposer, InlineReplyComposer, floating-reply-popup	—	Tiptap만
레이아웃·넛지·업데이트노트	PiecesPanel, NudgeEmailTab, NudgeAutoConfigTab, UpdateNoteForm, BuilderStepEditor	—	Tiptap만

구조적 미스매치: rich-text-editor.tsx의 MDEditor는 preview="edit" 모드 = markdown 소스 raw 편집기. 그런데 이 에디터가 쓰이는 서명·템플릿·시퀀스 필드엔 모두 HTML이 저장됨. 즉 사용자가 markdown 에디터에 HTML을 넣고 있고, 툴바·미리보기·배송 하이라이트가 전부 markdown을 가정해 어긋난다.

2. beta DB 실데이터 — 무슨 포맷으로 저장되나

에디터가 직접 쓰는 "원본 작성" 테이블의 본문 컬럼을 HTML / markdown / plain 으로 분류 집계.

테이블.컬럼 (에디터)	전체	포맷 분포	HTML	MD	plain	text 파트
email_templates.body_html MD에디터	151	98%	148	0	3	150
email_signatures.signature_html MD에디터	309	81%empty 18%	250	1	4	252
sequence_steps.email_body_html MD에디터	4,784	12%empty 88%	595	0	0	1,048
email_reply_drafts.body_text 답장	2,882	plain 100%	0	0	2,878	2,878

핵심 발견 ① — markdown 포맷으로 저장된 본문은 전 테이블 합쳐 단 1건(서명 1건). MDEditor가 markdown 에디터임에도 markdown 산출물이 사실상 0건 → MDEditor 유지의 데이터적 근거가 없다.

핵심 발견 ② — 채워진 본문은 81~98%가 HTML. 서명은 250건이 HTML(테이블 레이아웃·이미지 서명 포함)이라 markdown으론 애초에 표현 불가.

발송 산출물 (emails 테이블, 최근 5만 건 샘플)

98.7%

HTML 본문 존재

99.9%

text/plain 파트 동시 존재

0.04%

HTML-only (text 누락)

핵심 발견 ③ — 발송 파이프라인은 이미 multipart/alternative (HTML + text 둘 다)를 99.9% 생성. text 파트는 에디터가 아니라 발송 레이어에서 자동 파생되고 있다. 에디터를 HTML로 통일해도 이 동작은 그대로 유지된다.

3. text/plain은 왜 존재하는가 — 폐기하면 안 되는 이유

"HTML로 통일"이 곧 "plain text 폐기"가 아니다. 에디터 입력은 HTML 단일이 맞지만, 발송 MIME의 text 파트는 반드시 유지해야 한다.

① 스팸 필터 — 정량 페널티

HTML-only 메일은 SpamAssassin의 MIME_HTML_ONLY 룰을 트리거 → +0.7 스팸 점수. 멀티파트로 보내되 text 파트가 placeholder가 아닌 실제 읽히는 변환본이어야 함. 스팸 필터는 HTML과 text 양쪽을 모두 분석하므로 둘의 내용 불일치도 감점 요인.

② 접근성 — 스크린리더 · plain-text 모드

Email Markup Consortium 2025 보고서: HTML 이메일의 99.89%가 "Serious/Critical" 접근성 결함. 스크린리더 사용자, 저시력, plain-text 모드 수신자는 text 파트로 폴백한다. text 파트가 없으면 이들에게 빈 메일이 된다.

③ 클라이언트 렌더링 폴백 (Gmail · Outlook · Apple Mail)

클라이언트	HTML 렌더링 특성	text 파트 역할
Gmail (웹·앱)	media query 지원하나 접근성 기능 빈약, `<style>` 일부 제약	미리보기 스니펫·plain 모드 폴백
Outlook (legacy Windows)	Word 렌더 엔진 — 20개 중 7개 기능만 지원, 레이아웃 깨짐 빈번	깨진 HTML 시 가독 폴백
Apple Mail	media query 완벽 지원, 접근성 ~100%	plain 모드·스크린리더 폴백

세 클라이언트가 HTML을 제각각 해석하므로, text 파트는 "어디서든 읽히는" 최저 공통 보장선이다.

정리: 에디터 = HTML 단일(Tiptap). 발송 MIME = HTML + text 멀티파트 유지(서버가 html→text 파생, 이미 99.9% 작동). 두 레이어를 분리해서 보면 "HTML 통일"과 "plain text 유지"는 충돌하지 않는다.

4. 권고 — MDEditor 제거 영향 분석

김치볶음밥 원칙: 더하기 전에 빼기. 제거는 안전하나 단순 삭제가 아니라 Tiptap으로 교체가 필요(4곳이 실사용 중).

MDEditor가 실제 import 되는 5개 파일

components/ui/rich-text-editor.tsx — MDEditor 래퍼 본체 (제거 대상)
components/SignatureEditorModal.tsx — 서명 편집 → Tiptap 교체
pages/email-templates/EmailTemplateForm.tsx — 템플릿 → Tiptap 교체
pages/sequences/SequenceStepForm.tsx — 시퀀스 단계 → Tiptap 교체
pages/leads/SequenceLaunchModalStepEditor.tsx — 시퀀스 런치 모달 → Tiptap 교체

이전 "죽은 코드" 가설은 오답이었다. RichTextEditor는 4개 화면에서 실사용 중 → 의존성을 바로 지우면 빌드 깨짐. 먼저 4곳을 tiptap-editor.tsx로 마이그레이션 → 그 다음 rich-text-editor.tsx + @uiw/react-md-editor 제거 순서.

마이그레이션 시 점검(2026 패턴)

배송가능성 하이라이트: RichTextEditor의 deliverabilityHighlightTerms 오버레이 기능을 Tiptap Decoration(ProseMirror)으로 이식.
커서 변수 삽입: insertTextAtCursor → Tiptap은 이미 VariableItem 확장으로 동일 기능 보유, 재사용.
기존 데이터 호환: 저장값이 이미 HTML이라 Tiptap이 그대로 로드 가능 — 데이터 마이그레이션 불필요.
sanitize SSOT 일원화: 출력 HTML은 sanitizeEmailHtml()(email-renderer.ts) 단일 경로로 — markdown→HTML 중간 변환 레이어가 사라져 파이프라인 단순화.

출처: Suped — multipart/alternative · SendCheckit — plain vs HTML 딜리버러빌리티 · Email Markup Consortium — Accessibility 2025 · Email Client Compatibility 2025