해커뉴스에서 768포인트. 이메일 도구 하나로.
그 숫자 하나만으로도 개발자 커뮤니티에서 이 상처가 얼마나 깊은지 알 수 있다. 이번 주 Show HN 게시물로 등장한 Email.md라는 새로운 오픈소스 프로젝트는 이름 그대로의 기능을 수행한다. 마크다운을 반응형 크로스 클라이언트 이메일 HTML로 변환하는 것이다. 댓글 스레드는 제품 논의라기보다는, Outlook 2019에서 렌더링된 이메일을 디버깅하다 오후를 통째로 날려본 사람들의 집단 치유 세션에 더 가깝다.
실제로 출시된 것
Email.md는 표준 마크다운 입력을 받아 Gmail, Apple Mail, Outlook(데스크톱 및 웹), Yahoo Mail, 그리고 수많은 소규모 클라이언트에서 올바르게 렌더링되는 HTML을 생성한다. 출력물은 인라인 CSS가 적용된 테이블 기반 레이아웃을 사용하는데, 프론트엔드 코드 리뷰에서는 비웃음을 살 만한 마크업이지만 이메일 클라이언트 안에서 픽셀을 원하는 위치에 놓을 수 있는 유일하게 신뢰할 수 있는 방법이다.
이 프로젝트는 반응형 브레이크포인트, 다크 모드 호환성, 그리고 각기 다른 클라이언트가 패딩, 마진, 폰트 렌더링을 해석하는 악명 높을 정도로 일관성 없는 방식들을 처리한다. Show HN 목록에 따르면, 커스텀 테마, 코드 구문 강조, 대체 alt 텍스트가 포함된 이미지 임베딩도 지원한다.
워크플로우는 투박할 정도로 단순하다. 마크다운을 작성한다. Email.md를 통해 실행한다. ESP나 트랜잭션 이메일 서비스에 붙여넣거나 SMTP로 직접 보낼 수 있는 HTML을 얻는다. 드래그 앤 드롭 편집기 없음. 위지윅 없음. 텍스트를 넣으면 이메일이 나온다.
2026년에도 이메일 HTML이 여전히 끔찍한 이유
이메일 개발 분야 밖의 사람들을 당혹스럽게 하는 부분이 바로 이것이다. 우리에게는 컴포넌트 라이브러리, 디자인 시스템, CSS Grid, Container Queries, View Transitions API가 있다. 2026년의 웹 플랫폼은 정말로 인상적이다. 그런데 이메일 클라이언트를 열면, 다시 2003년이다.
그 이유는 구조적인 것이지, 기술적 게으름에서 비롯된 것이 아니다. 이메일 클라이언트는 브라우저가 아니다. Gmail은 특정 맥락에서 <style> 태그를 제거한다. Windows의 Outlook은 HTML에 Microsoft Word의 렌더링 엔진을 사용하는데, 이는 공들여 만든 플렉스박스 레이아웃이 워드프로세서에 의해 해석된다는 뜻이다. Yahoo Mail은 자체적으로 계속 바뀌는 CSS 속성 세트를 조용히 무시한다. Apple Mail은 이 중에서 가장 표준을 잘 준수하는데, 그것이 최대 장점인 동시에 함정이다. 개발자들이 Apple Mail에서 먼저 테스트하고 모든 것이 작동한다고 착각하기 때문이다.
이 파편화가 지속되는 이유는 어떤 단일 기업도 이메일 렌더링 생태계를 통제하지 않기 때문이다. 결국 웹 표준 프로젝트(Web Standards Project)와 이후 WHATWG를 통해 공유 표준으로 수렴한 브라우저 전쟁과 달리, 이메일 클라이언트들은 발맞출 유인이 전혀 없다. 구글은 당신의 뉴스레터가 Outlook에서 깨져 보이든 신경 쓰지 않는다. 마이크로소프트는 당신의 거래 영수증이 Gmail에서 제대로 렌더링되지 않든 신경 쓰지 않는다. 결과는 최소 공통분모 개발이라는 영구적 상태다.
MJML 같은 프레임워크와 Maizzle 같은 도구가 수년에 걸쳐 이 문제를 조금씩 해결해 왔다. React Email은 컴포넌트 기반 사고를 이 영역에 도입했다. 하지만 Email.md는 의도적으로 다른 접근 방식을 취한다. 개발자에게 이메일 HTML을 더 잘 작성할 수 있는 도구를 주는 대신, 이메일 HTML을 아예 작성하지 않으면 어떨까?라고 묻는 것이다.
사이드 프로젝트 핵에서 본격적인 솔루션으로
해커뉴스 토론은 예상대로 아키텍처 논쟁으로 흘러갔다. 여러 댓글 작성자들이 마크다운-이메일 변환은 새로운 것이 아니라고 지적했다. 라이브러리도 있다. 스크립트도 있다. 이 글을 읽고 있는 시니어 엔지니어 절반은 아마 어딘가에 비슷한 기능을 하는 조잡한 파이썬 스크립트를 가지고 있을 것이다.
반론, 그리고 업보트 패턴을 보면 공감을 얻은 주장은, Email.md가 이 문제를 사이드 프로젝트 핵이 아닌 본격적인 문제로 다룬다는 것이다. 이 도구의 렌더링 파이프라인은 대부분의 자체 제작 솔루션이 완전히 건너뛰는 엣지 케이스를 처리한다. 예를 들어 Outlook의 다크 모드는 단순히 색상을 반전시키지 않는다. 텍스트는 그대로 두면서 배경색만 선택적으로 수정하는데, 그 방식이 공들여 고른 색상 팔레트를 읽을 수 없게 만들 수 있다. Email.md는 조건부 CSS와 MSO 전용 마크업으로 이를 처리한다.
반응형 디자인에 대한 프로젝트의 접근 방식도 마찬가지로 의도적이다. Gmail 모바일 앱이 비AMP 맥락에서 제거하는 미디어 쿼리에 의존하는 대신, 플루이드-하이브리드 방식을 사용한다. 테이블에 max-width를 설정하고 내부 너비를 백분율 기반으로 잡아, 클라이언트가 제거할 수 있는 CSS 없이도 자연스럽게 리플로우된다. 이 기법은 이메일 개발 커뮤니티에서 수년간 문서화되어 왔지만, 마크다운 입력에서 이를 자동화하는 것은 도입 장벽을 크게 낮춘다.
세 부류의 사용자, 하나의 페인 포인트
토론 스레드에서 세 가지 사용 사례가 두드러진다.
첫째, 개발자 간 커뮤니케이션. 엔지니어링 팀이 보내는 내부 업데이트, 인시던트 보고서, 또는 변경 로그 이메일. 이들은 이미 마크다운으로 사고하고, 문서를 마크다운으로 작성하며, 서식이 있는 메시지를 작성하기 위해 텍스트 편집기를 벗어나야 하는 것에 불만을 품는 사람들이다.
둘째, 트랜잭션 이메일. 비밀번호 재설정, 주문 확인, 배송 알림. 이 템플릿들은 변경 빈도가 낮지만 어디서나 작동해야 한다. 레포에서 마크다운 파일로 관리하면 버전 관리가 되고 diff가 가능해져, 불투명한 HTML 블롭을 관리하는 것에 비해 의미 있는 개선이다.
셋째, 뉴스레터. 인디 뉴스레터 영역이 폭발적으로 성장했고, 많은 작성자들은 마크다운을 알 만큼 기술적이지만, 이메일 클라이언트 간 테이블 레이아웃을 디버깅할 만큼 기술적이지는 않거나, 혹은 인내심이 없다. Email.md는 이 사용자층에게 딱 맞는 지점에 위치한다.
이 반응이 드러내는 것
Email.md의 반응에서 가장 흥미로운 점은 도구 자체가 아니다. 개발자 도구의 우선순위에 대해 이 반응이 드러내는 바다.
웹 개발 생태계는 브라우저에 영향을 미치는 문제를 해결하는 데 막대한 에너지를 쏟아왔다. 빌드 도구, 프레임워크, 상태 관리, 서버 컴포넌트, 엣지 렌더링—수십억 달러의 벤처 캐피털이 이 문제들을 쫓았다. 지구상에서 가장 널리 사용되는 커뮤니케이션 채널 중 하나인 이메일은 뒷전으로 밀려났다.
이것은 부분적으로 위상의 문제다. 이메일 HTML은 화려하지 않다. 아무도 컨퍼런스 발표 초록에 "Outlook 조건부 주석 전문가"라고 쓰지 않는다. 그 결과 개발자 고통의 한 범주 전체가 과소 대응되어 왔다. 풀 수 없어서가 아니라, 유행하지 않아서다.
Email.md의 768포인트 데뷔는 수요가 항상 존재했음을 시사한다. 개발자들은 누군가 이 문제를 진지하게 받아들이고 제대로 된 솔루션을 내놓기를 기다리고 있었을 뿐이다.
주목할 점, 그리고 시도해볼 것
이 프로젝트는 오픈소스이므로, 그 지속성은 커뮤니티의 채택과 기여에 달려 있다. 이메일 클라이언트의 렌더링 특이점은 끊임없이 변한다. Gmail은 최근 몇 년간 CSS 처리 방식을 여러 번 수정했다. Outlook의 엔진은 Office 릴리스와 함께 업데이트된다. 호환성을 유지하려면 지속적이고, 확실히 화려하지 않은 작업이 필요하다. 수십 가지 클라이언트와 디바이스 조합에서의 수동 테스트 말이다.
진짜 시험대는 Email.md가 메인테이너들의 번아웃 없이 이메일 클라이언트 렌더링이라는 움직이는 과녁에 보조를 맞출 수 있는지 여부다. Show HN 토론을 보면 프로젝트는 활발히 유지 관리되고 있지만, 이메일 호환성은 장기전이다.
지금 당장은, 스타일이 적용된 이메일을 보내면서 이미 다른 모든 곳에서 마크다운을 쓰는 개발자라면 Email.md를 살펴볼 가치가 있다. 레포를 확인하라. 호환성 노트를 읽어라. 테스트 커버리지를 검토하라. 그리고 Apple Mail에서는 완벽하게 보이는 이메일이 Outlook에서 와르르 무너지는 이유를 고민하다 오후를 날려본 적이 있다면, 768명이 왜 이것에 업보트를 눌렀는지 이미 알 것이다.