메일 클라이언트는 웹 브라우저가 아니라 각자 다른 렌더링 엔진을 쓰는 독립된 환경이라 CSS 지원 범위가 제각각이다
외부 스타일시트나 `<style>` 태그가 무시되는 클라이언트가 있어, 핵심 스타일은 인라인(inline) CSS로 넣는 것이 기본 원칙이다
레이아웃은 `<div>`+flex/grid보다 표(`<table>`) 기반 구조가 여러 클라이언트에서 더 안정적으로 깨지지 않는다
반응형은 미디어쿼리를 지원하는 클라이언트에서만 적용되므로, 미디어쿼리를 지원하지 않는 클라이언트를 위한 '고정 폭 기본 레이아웃'을 항상 함께 설계해야 한다
이미지에는 항상 대체 텍스트(alt)와 배경색을 지정해, 이미지 차단 설정에서도 메시지가 전달되게 한다
왜 웹 디자인 감각을 그대로 가져오면 깨지는가
브라우저는 몇 종류로 통일되어 있지만, 이메일을 여는 환경은 지메일 웹, 지메일 앱, 네이버메일 웹, 네이버메일 앱, 아웃룩, 애플 메일 등 각기 다른 렌더링 엔진을 쓰는 프로그램의 집합입니다. 이 중 상당수는 자체 보안 정책상 외부 스타일시트 링크나 <style> 태그 안의 CSS를 무시하고, 태그에 직접 붙인 인라인 스타일(style="color:#111")만 반영합니다. 그래서 웹사이트를 만들 때 쓰던 별도 CSS 파일 방식이나 flex·grid 같은 최신 레이아웃 문법은 이메일에서 절반도 적용되지 않을 수 있습니다. 뉴스레터 HTML을 짤 때는 "이 스타일이 인라인으로 들어갔는가"를 매번 확인하는 습관이 첫 번째 규칙입니다.
레이아웃은 표(table) 기반으로 짜는 것이 기본이다
현대 웹 개발에서는 표 태그로 레이아웃을 짜는 것을 지양하지만, 이메일 HTML에서는 반대입니다. <table>과 그 안의 셀(<td>)로 구획을 나누는 방식이 다양한 메일 클라이언트에서 가장 예측 가능하게 렌더링됩니다. flex나 grid 기반 레이아웃은 이를 지원하지 않는 클라이언트에서 요소들이 세로로 무너지거나 겹치는 형태로 깨질 수 있습니다. 실무에서는 전체 뉴스레터를 하나의 표로 감싸고, 그 안에서 섹션별로 다시 표를 중첩하는 구조를 씁니다.
미디어쿼리가 통하는 클라이언트와 그렇지 않은 클라이언트를 나눠 설계한다
반응형(화면 크기에 따라 레이아웃이 바뀌는 것)은 CSS 미디어쿼리로 구현하지만, 이 미디어쿼리를 지원하지 않는 메일 클라이언트도 여전히 존재합니다. 그래서 실무에서는 미디어쿼리로 "모바일에서는 이렇게 보이게" 규칙을 추가하되, 미디어쿼리가 무시되는 클라이언트에서도 레이아웃이 깨지지 않도록 기본 폭(보통 데스크톱 기준 고정 폭)의 표 구조를 먼저 안정적으로 짜 두는 순서로 접근합니다. 즉 반응형은 '더 나은 경험을 추가하는 레이어'로 보고, 반응형이 적용되지 않아도 읽는 데 지장이 없는 기본 레이아웃을 먼저 완성하는 것이 원칙입니다.
폰트와 이미지가 화면 크기별로 깨지는 것을 막는 규칙
폰트는 시스템 기본 폰트 여러 개를 폴백(fallback)으로 나열해, 특정 폰트가 지원되지 않는 클라이언트에서도 읽기 어려운 대체 폰트로 넘어가지 않게 합니다. 폰트 크기는 화면이 작아질수록 줄어드는 웹사이트 관행과 달리, 모바일에서 오히려 본문 폰트를 일정 크기 이상으로 유지해야 가독성이 떨어지지 않습니다. 이미지는 폭을 픽셀 고정값이 아니라 최대폭(max-width) 기준의 상대값으로 지정해 화면보다 넘치지 않게 하고, 이미지 자체에 항상 대체 텍스트(alt)를 넣어야 합니다. 상당수 메일 클라이언트가 기본값으로 이미지를 자동으로 불러오지 않기 때문에, 이미지가 차단된 상태에서도 대체 텍스트와 배경색만으로 메시지의 핵심(예: 버튼의 문구)이 전달되도록 설계하는 것이 중요합니다.
발송 전 반드시 거쳐야 하는 확인 절차
레이아웃을 완성했다고 바로 전체 발송을 하면 안 됩니다. 최소한 지메일(웹·앱), 네이버메일(웹·앱), 아웃룩, 애플 메일에서 실제 렌더링을 확인하는 것이 정석이며, 대부분의 ESP는 여러 클라이언트에서의 미리보기 기능이나 테스트 발송 기능을 제공합니다. 특히 제목·본문의 첫 줄(프리헤더)이 각 클라이언트의 받은편지함 목록에서 어떻게 잘려 보이는지도 함께 확인해야 합니다 — 화면 크기에 따라 노출되는 글자 수가 달라, 데스크톱에서는 온전히 보이던 문구가 모바일 목록에서는 중간에 잘려 의미가 달라질 수 있습니다.
단일 컬럼 구조를 기본값으로 삼는 이유
데스크톱 화면을 기준으로 두세 개 컬럼(단)으로 나눈 레이아웃은 화면이 좁은 모바일에서 컬럼이 강제로 압축되거나, 미디어쿼리가 적용되지 않는 클라이언트에서는 좁은 화면에 여러 컬럼이 그대로 눌려 글자가 겹치는 형태로 깨지기 쉽습니다. 그래서 실무에서는 처음부터 세로로 쌓이는 단일 컬럼 구조를 기본값으로 놓고, 여백이 충분한 데스크톱 환경에서만 미디어쿼리로 일부 요소를 가로로 나란히 배치하는 방식을 씁니다. 이렇게 설계하면 반응형이 적용되지 않는 클라이언트에서도 최악의 경우 '세로로 조금 길어질 뿐' 레이아웃 자체가 무너지지는 않습니다. 버튼(CTA)처럼 클릭을 유도하는 핵심 요소는 화면 크기와 무관하게 항상 충분히 크고 터치하기 쉬운 크기로 고정해, 모바일에서 손가락으로 누르기 어려울 만큼 작아지지 않도록 하는 것도 같은 원칙의 연장입니다.
다음 행동
다음 발송 전, 현재 템플릿을 지메일 앱과 네이버메일 앱 두 곳에서만이라도 실제로 열어 폰트 크기와 이미지 정렬이 무너지지 않는지 확인해보세요. 이 최소 점검만으로도 레이아웃 사고의 상당수를 미리 걸러낼 수 있습니다.
← 이전 글 · 레슨 04 유저 세그먼트 자동화 트리거: [가입 후 3일간 미구매자], [최근 30일간 로그인 없는 자] 등 행동 데이터 기반 자동 발송(Automation)
CHALLENGE
배운 걸 실전 문제로 확인
카테고리별 Level Test로 실무 레벨을 점검해보세요.