이메일 폰트 지정이 거의 항상 헛수고인 이유

결론부터 말하면, 지금 이메일에 커스텀 폰트를 넣으려고 시간 쓰고 있다면 멈춰도 됩니다. 수신자 대부분은 어차피 다른 폰트로 읽고 있어요. 설정 실수가 아니라 이메일이라는 매체 자체의 구조적 한계 때문입니다.

B2B·사내 메일이라면 처음부터 포기하는 게 맞다

기업 환경에서는 Outlook for Windows(2007~2019 등)가 아직 흔합니다. 이 버전들은 HTML 이메일을 웹 브라우저가 아니라 Microsoft Word 렌더링 엔진으로 처리해요. Word는 문서 편집 프로그램이지 브라우저가 아니니 @font-face 같은 웹 표준을 파싱하는 능력 자체가 없습니다. flexbox도 엉망으로 쏟아내는 그 Outlook이 맞아요.

아무리 정교하게 CSS를 짜도 Word가 모르는 코드는 없는 코드나 다름없어요. 발신자 입장에서는 수신자가 어떤 버전의 Outlook을 쓰는지 알 방법이 없고, 선택지도 없습니다. 이 환경에서 커스텀 폰트에 시간을 쓰는 건 그냥 손실이에요.

Gmail 수신자가 대다수라도 사정은 같다

Gmail은 이메일을 표시하기 전에 HTML을 정리하는 과정에서 @font-face나 @import 같은 외부 폰트 로드 선언이 포함된 <style> 블록을 제거합니다. 보안과 UI 간섭 방지가 목적이에요.

남는 건 인라인 스타일(style="font-family: ...")뿐인데, 그마저도 해당 폰트가 수신자 기기에 설치돼 있어야 작동해요. font-family: "Pretendard", sans-serif라고 적어놔도 상대방 컴퓨터에 프리텐다드가 없으면 시스템 기본 고딕으로 폴백됩니다. CSS를 어떻게 짜든 Gmail 수신자한테는 대부분 의미가 없어요.

여기서 놓치기 쉬운 점이 있는데요. 인라인 스타일로 폰트를 명시해봤자, 그 폰트가 수신자 기기에 깔려 있는지를 발신자가 확인할 방법은 없습니다. 즉 지정을 해도 적용 여부를 보장할 수가 없는 구조예요. 뉴스레터 에디터에서 서체 설정을 아무리 열심히 잡아도, 수신자 화면에서는 그냥 기본 고딕인 경우가 대부분인 이유가 바로 이것입니다.

Apple Mail 지원만 보고 커스텀 폰트를 넣으면 역효과가 난다

Apple Mail은 @font-face를 지원하는 몇 안 되는 클라이언트 중 하나예요. 그래서 "Apple Mail에서 테스트해봤더니 되더라"는 이유로 커스텀 폰트를 넣는 경우가 있는데, 이게 오히려 문제를 키웁니다.

Gmail과 Outlook을 동시에 커버해야 하는 이상, Apple Mail에서만 렌더링되는 커스텀 폰트를 지정하면 다른 환경에서 폴백이 터지면서 폰트 통일성이 깨져요. 모든 수신자에게 동일한 인상을 주려고 폰트를 지정한 건데, 환경별로 전혀 다른 서체가 뜨는 결과가 됩니다. 발신자가 수신자의 클라이언트를 통제할 수 없으니 이건 구조적으로 피할 수 없는 문제예요.

그래서 실제로 쓸 수 있는 건 web-safe 폰트뿐이다

수신자 기기에 이미 설치된 폰트, 즉 web-safe font만 어떤 환경에서도 안정적으로 뜹니다. 영문 기준으로 믿을 수 있는 건 Arial, Helvetica, Georgia, Verdana, Times New Roman, Courier New, Trebuchet MS 정도예요. 한글 환경��서는 macOS의 Apple SD 산돌고딕 Neo, Windows의 맑은 고딕이 각각 기본으로 깔려 있어서, sans-serif 폴백이 걸리면 대체로 이 둘 중 하나가 뜹니다.

뉴스레터들이 "고딕이냐 명조냐"만 고르는 것처럼 보이는 이유가 이거예요. 애초에 선택지가 그 정도밖에 없는 구조거든요. font-family를 지정할 때는 폰트 스택을 쌓아두는 게 기본입니다.

font-family: "Apple SD Gothic Neo", "Malgun Gothic", sans-serif;

기기별 폴백을 미리 적어두면 렌더링 오차를 최소화할 수 있습니다. 이 스택 자체가 이메일 환경에서 폰트 작업의 사실상 전부예요.

서체 인상이 반드시 필요하다면 이미지 헤더로 범위를 제한해야 한다

브랜드 헤더처럼 서체 분위기가 핵심인 영역만큼은 이미지로 만들어 삽입하는 게 현실적입니다. 이미지는 클라이언트의 폰트 처리 방식에 영향을 받지 않으니까요.

단, 이 방법도 조건이 있어요. 이미지 비중이 너무 높으면 스팸 필터에 걸릴 수 있고, Outlook은 이미지 자동 표시가 기본 OFF인 경우가 많아서 alt 텍스트는 반드시 챙겨야 합니다. 핵심 정보가 담긴 텍스트라면 이미지 단독보다 이미지+텍스트 병행이 더 안전하고, 본문은 web-safe로 유지하는 식으로 범위를 제한하는 게 맞아요.

그래서 현실적인 접근은 이렇습니다. 브랜드 인상이 중요한 헤더나 로고 영역만 이미지로 처리하고, 나머지 본문 전체는 web-safe 폰트 스택으로 두는 거예요. "전체를 브랜드 서체로" 하려다 모든 환경에서 폴백이 터지는 것보다, 헤더 한 줄을 이미지로 못 박아두는 게 실제 수신자 경험에서 훨씬 낫습니다.

결국 폰트 지정에 쓸 시간을 레이아웃·여백·컬러에 쓰는 게 이메일 매체에 훨씬 어울립니다. 이메일에서 폰트는 내가 선택하는 게 아니라 수신 환경이 허용하는 것에 가깝고, 그 전제를 받아들이고 나면 어디에 힘을 빼고 어디에 힘을 줄지가 명확해져요.

이메일 밖 작업물에 쓸 무료 폰트라면 폰트비에서 사용 범위나 라이선스 조건을 미리 확인해볼 수 있어요.