Emailify 문제 해결

Emailify의 디자인, 내보내기, 이메일 클라이언트별 문제를 해결하는 가이드예요.

Figma ​

Emailify 밖에서 만든 Figma 이메일 디자인은 지원되지 않아요 ​

바로 쓸 수 있는 HTML을 내보내기 전에 Emailify의 디자인 도구로 이메일 레이아웃을 만드세요. 이 도구들은 Emailify가 HTML을 생성하는 데 필요한 Row, Column, Button 등 구조화된 레이어를 추가해 줘요. 추가한 뒤에는 콘텐츠와 스타일을 원하는 대로 바꿀 수 있어요.

Emailify 플러그인 없이 Figma에서 미리 디자인해 둔 레이어나 프레임을 추가하면 서식 있는 텍스트나 HTML 콘텐츠가 아니라 정적 이미지로 렌더링돼요.

이미지 형식 재정의 설정 ​

Emailify는 레이어에 완전히 투명한 영역이 있는지 자동으로 감지해 있으면 기본 내보내기 형식을 PNG로, 없으면 JPG로 설정해요. 레이어에 직접 내보내기 설정을 추가하면 어떤 레이어든 내보내기 형식을 JPG나 PNG로 바꿀 수 있어요.

Figma의 ‘Scroll Wheel’ 또는 ‘Drag to Pan’ 설정을 켰을 때 멈추는 문제 ​

이 설정(아래 스크린샷 참고)을 켜 두면 플러그인이나 캔버스가 이상하게 멈추는 문제가 가끔 발생해요.

Figma 파일에서 이런 문제가 생긴다면 Main Figma Menu에서 Preferences로 내려가 Use scroll wheel zoom과 Right-click and drag to pan 설정의 체크를 해제하면 해결할 수 있어요.

Figma의 스크롤 휠 확대/축소 및 드래그로 화면 이동 환경설정

일반 Figma 텍스트 레이어의 문단이나 콘텐츠에 링크 추가 ​

Figma 텍스트 레이어에서 링크를 걸 텍스트를 선택한 다음 Figma 헤더 툴바 영역의 Figma 기본 “Link” 아이콘 버튼을 클릭하면 URL을 붙여 넣을 수 있어요. 이 링크는 Emailify가 자동으로 렌더링해요.

이 방법은 콘텐츠 텍스트 레이어에만 사용하세요(버튼이나 내비게이션 링크에는 사용하지 마세요). 이 방법은 일반 콘텐츠 텍스트 레이어에서만 작동해요. Emailify가 생성한 버튼, 소셜 아이콘, 내비게이션 링크 레이어에 링크를 설정하려면 해당 Figma 레이어를 클릭하고 Emailify 플러그인 헤더의 Settings 버튼을 클릭한 다음 링크 필드에 URL을 붙여 넣으세요.

버튼이나 링크 레이블이 Figma에서는 보이는데 미리보기나 내보내기에서는 사라지는 문제 ​

Figma에서는 텍스트가 보이는데도 버튼이 비어 있거나 내비게이션 링크가 사라졌다면, 가변 폰트를 포함해 폰트 데이터가 섞여 있어서 생기는 내보내기 문제일 수 있어요. 링크 URL이 올바르다고 해서 레이블까지 제대로 내보내졌다는 뜻은 아니에요.

레이블은 원래의 Emailify Button 또는 내비게이션 컴포넌트 안에서 편집 가능한 텍스트로 유지하세요. Emailify를 닫았다가 다시 열고, 미리보기를 새로 고친 뒤 다시 내보내세요. 이메일 플랫폼에 업로드하기 전에 다운로드한 HTML을 확인하세요.

그래도 레이블이 계속 사라진다면 문제가 있는 Figma 이메일 프레임과 내보낸 HTML 또는 ZIP을 첨부해 지원팀에 문의해 주세요. 텍스트 레이어를 살펴보고 문제를 재현해 볼게요.

위 첨자 또는 아래 첨자 텍스트 추가 ​

Figma 텍스트 레이어에 위 첨자와 아래 첨자를 추가하면, 플러그인에서 HTML로 내보낼 때 자동으로 위 첨자(예: sup) 또는 아래 첨자(예: sub) 태그로 렌더링돼요.

HTML 텍스트에 제목 태그(예: h1, h2, h3) 사용 ​

필요하다면 기본 문단 태그(p)를 원하는 제목 태그(예: h1, h2)로 바꿀 수 있어요. Figma 텍스트 레이어 콘텐츠를 원하는 제목 태그로 감싸면 Emailify 플러그인으로 HTML을 내보낼 때 태그가 자동으로 바뀌어요.

Windows용 Figma 데스크톱 앱에서 파일 확장자가 비어 있는 문제 ​

Figma 데스크톱 앱(Windows에서만)에는 Figma에서 일반 파일을 내보낼 때도 생기는 알려진 문제가 있어요. 파일을 저장하려고 하면 “all files” 레이블이 보일 수 있어요. 이를 무시하고 “Save”를 클릭해 계속 진행해도 파일은 올바른 확장자로 저장되고, 컴퓨터에 다운로드된 뒤 정상적으로 열 수 있어요. 그래도 확장자 없이 저장된다면 파일 이름을 바꿔 올바른 확장자를 직접 붙이면 돼요.

HTML 내보내기 크기를 줄이도록 디자인 최적화 ​

내보낸 HTML 크기에 가장 큰 영향을 주는 것은 Row 컴포넌트의 개수예요. Row마다 표 요소가 한 세트씩 더 생기기 때문이에요. 같은 구조 안에 콘텐츠를 넣을 수 있다면 Row를 재사용하세요.

예를 들어 제목, 부제목, 본문, 버튼은 Row 하나 안의 Column 하나에 함께 넣을 수 있어요. Row 레이어를 네 개로 나눌 필요가 없어요.

Emailify Figma 레이어를 클릭해도 Emailify 설정 패널 옵션이 나타나지 않는 문제 ​

Figma 디자인에서 Emailify 레이어를 클릭하고 플러그인 헤더의 Settings 버튼을 클릭해도 설정이 나타나지 않는다면, 기본 Emailify 프레임이 다른 프레임이나 그룹 등의 안에 중첩되어 있을 수 있어요. 이 문제를 해결하려면 Emailify 프레임을 중첩된 프레임이나 레이어 밖으로 꺼내 다른 레이어 안에 들어 있지 않도록 “Page” 수준으로 옮기세요.

HTML 이메일을 보낼 때 UTM 쿼리 파라미터가 제거되는 문제 ​

HTML 이메일을 보낼 때 UTM 쿼리 문자열 파라미터가 제거되는 데에는 몇 가지 이유가 있어요. 지난 1년여 동안 개인정보 보호를 이유로 이 파라미터를 자동으로 제거하는 브라우저와 기기가 늘어났기 때문이에요. Emailify 미리보기 창에서 링크를 열 때는 쿼리 문자열이 잘 작동하는데 이메일 마케팅 플랫폼에서 이메일을 보낸 뒤에는 작동하지 않는다면, 발송할 때 추가로 적용되는 링크 포워더나 단축 서비스가 파라미터를 제거하거나 깨뜨리고 있을 가능성이 높아요.

‘Please wait, loading Figma images...’ 속도 ​

얼마 전 Figma 업데이트로, 모든 Figma 플러그인은 이미지 데이터를 내보내기 전에(레이어나 이미지 하나만 필요하더라도) 현재 Figma 페이지에 있는 모든 원본 해상도 이미지가 다 로드될 때까지 기다려야 하게 됐어요.

현재로서는 현재 Figma 페이지의 프레임과 레이어 수를 줄이는 것이 유일한 해결책이에요. 그러면 플러그인을 처음 실행할 때 이 과정이 훨씬 빨라져요. 예를 들어 현재 Figma 파일에 새 페이지를 만들고 작업하거나 내보낼 Emailify 프레임만 그 빈 페이지로 옮긴 뒤 그곳에서 플러그인을 다시 실행하면 훨씬 빠르게 로드될 거예요.

내보낸 이미지가 픽셀화되는 문제 ​

Figma의 이미지 에셋이 아직 점진적으로 로드되는 중에 이메일을 내보내면, 이미지가 Figma 파일에서 완전히 로드되기 전에 내보내져 픽셀이 깨져 보일 수 있어요. 이 문제를 해결하려면 Emailify 플러그인으로 이메일을 내보내기 전에 Figma 파일에서 모든 이미지가 100% 로드되어 선명하게 보이는지 확인해 주세요.

이 문제를 더 줄이려면 TinyImage의 “Downsizer” 기능(영어)으로 이미지 채우기를 레이어 크기에 맞게 줄일 수 있어요. 파일 크기가 줄어들어 Figma 파일에서 훨씬 빠르게 로드돼요.

Adobe Acrobat에서 PDF를 편집할 때 점선이 보이는 문제 ​

PDF를 편집하는 동안 Adobe Acrobat 앱 사이드바에서 “Show bounding boxes” 토글을 해제하면 해결할 수 있어요. 앱에서 PDF를 열고 “Edit” 모드로 들어가면 점선으로 된 경계 상자가 Adobe 기본값으로 표시되지만, “Show bounding boxes” 토글을 끄면 클릭 한 번으로 숨길 수 있어요.

중국에서는 VPN이 필요할 수 있어요 ​

중국에 있다면 “만리방화벽(The Great Firewall of China)” 때문에 계정 서버에 연결하지 못할 수도 있어요. 유효한 키를 입력했는데도 활성화 오류가 표시된다면 VPN을 사용해야 문제가 해결될 가능성이 커요.

‘An error occurred while loading the plugin environment’ ​

Figma 데스크톱 앱에서 Figma의 Use Developer VM 디버그 설정이 실수로 켜져 있으면 이 오류가 발생할 수 있어요. Figma 캔버스 아무 곳에서나 마우스 오른쪽 버튼을 클릭하고 Plugins, Development 순으로 마우스를 올린 다음 Use Developer VM이 체크 해제되어 있는지 확인하세요. 체크가 해제되면(옆에 체크 표시가 없으면) Figma 플러그인을 다시 실행했을 때 정상적으로 작동할 거예요.

네트워크에서 이미지 업로드가 차단되는 문제 ​

Upload Hosted Image URLs 기능을 켰거나 Emailify 내장 내보내기 옵션으로 HTML 이메일을 이메일 플랫폼에 업로드했다면, 플러그인이 이미지를 자동으로 온라인에 업로드해 호스팅해요.

플러그인에 경고 메시지(Images uploads may be blocked on your current network)가 보인다면, 이미지를 온라인에 호스팅하는 데 필요한 업로드 서비스에 플러그인이 접근하지 못한다는 뜻이에요.

보통 연결된 네트워크(예: 특정 URL을 차단하는 방화벽이 있을 수 있는 회사 네트워크)나 ISP(인터넷 서비스 제공업체)가 해당 URL을 제한하거나 차단해서 생겨요. 다음과 같이 문제를 해결해 보세요.

  • 휴대폰을 Wi-Fi 핫스팟으로 컴퓨터에 연결한 다음 Emailify Figma 플러그인을 다시 실행해 문제가 해결되는지 확인하세요. 해결된다면 기존 네트워크가 요청을 차단하고 있었다는 뜻이에요.
  • VPN을 사용해 보는 것도 방법이에요. 네트워크 요청을 터널링해 네트워크 차단 문제를 우회할 수 있어요.
  • 이미 VPN을 사용 중이라면 VPN을 끈 다음 Emailify Figma 플러그인을 다시 실행해 문제가 해결되는지 확인하세요.

그래도 문제가 계속되면 언제든 이메일로 문의해 주세요.

이메일 클라이언트 ​

새 Outlook이 이메일을 로드한 뒤 스타일을 다시 쓸 수 있어요 ​

Windows용 새 Outlook에는 이메일이 처음에는 제대로 표시되다가 로드된 뒤에 바뀌는 후처리 문제가 보고되어 있어요. Outlook이 이 두 번째 렌더링 단계에서 이메일 CSS의 일부를 다시 쓰는 것으로 보이며, 그 결과 데스크톱의 열이 예기치 않게 세로로 쌓이는 등의 문제가 생길 수 있어요.

이 동작은 일관되지 않아요. 한 수신자만 영향을 받고 나머지는 모두 예상한 레이아웃을 볼 수도 있고, 같은 테스트 메일이 같은 메일함에서 다르게 렌더링될 수도 있어요. Customer.io가 New Outlook, same headache(영어)에 이 증상과 현재까지 확인된 내용을 정리해 두었어요.

새로 내보내는 Emailify 파일에는 알려진 열 쌓임 문제에 대응하는 방어용 호환성 레이어가 들어 있어요. Emailify는 MJML의 원래 반응형 스타일과 기존 Outlook용 표 대체 레이아웃을 유지하고, 생성된 데스크톱 열 너비 규칙만 한 번 더 복사해 이메일 본문 안에 넣어요. 이렇게 하면 이메일 head에서 스타일을 제거하는 웹 기반 Outlook 버전에 도움이 되고, 다른 클라이언트에서는 MJML의 일반적인 모바일 쌓임과 브레이크포인트 동작이 그대로 유지돼요.

디자인을 다시 만들 필요는 없어요. Emailify를 업데이트하고 이메일을 다시 내보내 생성된 HTML에 대체 규칙이 들어가게 한 뒤 테스트 메일을 다시 보내세요.

이 문제가 생기면 다음을 해 보세요.

  • 문제가 있는 이메일을 Outlook 읽기/미리보기 창이 아닌 별도 창에서 여세요. 보고된 사례에서는 별도 창에서 제대로 렌더링되는 경우가 많아요.
  • 내보낸 같은 HTML을 다른 수신자나 이메일 클라이언트로 보내 한 Outlook 사용자에게만 생기는 문제인지 확인하세요.
  • 같은 메일이 서로 다르게 렌더링된다면, Emailify 디자인이나 내보내기를 바꾸기 전에 받은 두 메시지를 .eml 파일로 다운로드해 HTML을 비교하세요.

대체 규칙은 보고된 데스크톱 열 쌓임 문제를 줄여 주지만, 전송 이후에 일어나는 모든 스타일 재작성을 Emailify가 제어할 수는 없어요. 문제가 계속되는데 받은 HTML이 바뀌지 않았다면, 일관되지 않은 Outlook 미리보기 하나 때문에 디자인을 크게 바꾸지는 마세요.

HTML 이메일 템플릿을 전달하면 깨지는 문제 ​

아쉽게도 받은 사용자 지정 HTML 이메일을 다른 사람에게 전달하면, 전달된 이메일의 모양이 깨지는 경우가 많아요.

이메일을 전달할 때 이메일 클라이언트마다 HTML 코드의 일부를 수정하거나 제거해서 깨지는 거예요. Litmus의 When Forwarded Emails Break(영어) 글에서는 이렇게 설명해요.

이메일 클라이언트마다 이메일을 다르게 렌더링한다는 건 널리 알려진 사실이에요. 구독자가 이메일을 전달하면 일부 이메일 클라이언트는 전달되는 메시지의 코드를 바꿔요. 특정 HTML 요소를 제거하거나, 이메일을 blockquote로 감싸거나, 코드에 클래스를 추가하는 식인데, 이 모든 변경이 디자인을 깨뜨리고 전달받은 사람에게 이메일이 제대로 작동하지 않게 만들 수 있어요.

이런 영향을 줄이는 흔한 방법은 이메일이 제대로 렌더링되지 않을 때 브라우저에서 열 수 있는 “웹 링크” 버전을 두는 거예요. 보통 이메일 상단 어딘가에 넣어요(MailChimp의 이 예처럼). 필요하다면 이메일 어딘가에 공유용 링크로 만들어 둘 수도 있어요.

이메일이 스팸함으로 가요. 원인이 뭘까요? ​

이메일이 스팸함으로 가는 흔한 이유는 몇 가지가 있어요.

  • 링크가 너무 많아요: 링크 하나하나가 전달률에 영향을 줘요. 불필요한 소셜 미디어 링크를 포함해 꼭 필요하지 않은 링크를 지우면 받은편지함 도달률이 좋아져요.
  • 발신자 평판이 낮아요: 도메인이나 IP에 낮은 참여율, 반송, 신고 이력이 있으면 메일함 제공업체가 이메일을 스팸으로 표시할 수 있어요.
  • 스팸성 콘텐츠: 홍보성 문구(예: “Free!”, “Act now!”, “Limited time offer”)를 남발하거나 이미지는 너무 많고 텍스트는 너무 적으면 필터에 걸릴 수 있어요.
  • 인증 문제: 발신 도메인에 SPF, DKIM, DMARC를 올바르게 설정했는지 확인하세요.
  • 낮은 참여율: 구독자가 계속 이메일을 열지 않거나 클릭하지 않으면 이후 이메일이 스팸으로 분류될 가능성이 높아져요.
  • 목록 품질: 오래된 목록이나 구매한 목록으로 보내면 반송과 스팸 신고가 생겨 발신자 점수가 떨어질 수 있어요.

우선 이메일을 단순하게 만들고, 도메인 인증을 확인하고, 불필요한 링크를 줄여 보세요. 이것만으로도 전달률이 좋아지는 경우가 많아요.

다크 모드 재정의는 iOS/Mac Apple Mail 앱에서만 지원돼요 ​

현재 이메일 클라이언트의 다크 모드 재정의 스타일 지원은 아직 비교적 낮은 편이에요. 이 점을 염두에 두고, 다크 모드 재정의는 “점진적 향상”으로 생각하며 이메일을 디자인해 주세요.

다른 이메일 클라이언트용 대비책으로, 다크 모드를 고려해 이메일을 만드는 다른 영리한 디자인 기법을 함께 활용하는 것도 좋아요.

Gmail 흰색 버튼 텍스트 해결 방법은 순수한 흰색 버튼 텍스트를 유지하는 것이 목적이라 쓰임새가 더 좁아요. Gmail 다크 모드에서 연한 배경 위의 검은색 텍스트를 그대로 유지하는 방법은 아니에요.

쌓인 모바일 이미지 사이의 얇은 흰색 서브픽셀 선 ​

전체 너비 인라인 이미지를 사용할 때 가끔 생기는 문제예요. 기기 너비에 따라 모바일에서 이미지가 축소되면서 이미지 높이에 “서브픽셀”이 끼어들 수 있어요(이 때문에 이미지 사이에 희미한 틈이 생기고 그 뒤의 배경이 비쳐 보여요).

가장 빠른 해결 방법은 해당 이미지가 들어 있는 “Row” 레이어를 Wrapper 레이어로 감싸고, 그 Wrapper의 배경을 양쪽 끝 모두 배경색(예: 회색)으로 된 “Linear Gradient”로 설정하는 거예요. 이렇게 하면 배경이 이미지로 렌더링되어 다크 모드에서 CSS 배경색이 바뀌거나 검은색으로 반전되는 것을 막고, 이미지 Row 뒤에 일관된 배경이 깔려 서브픽셀 틈을 가려 줘요.

Google/사용자 지정 폰트 임베드는 iOS/macOS Apple Mail 앱에서만 지원돼요 ​

현재 이메일 클라이언트에서 사용자 지정 폰트는 iOS/macOS용 Apple Mail에서만 지원돼요. 그래서 Figma 텍스트 레이어에는 웹 안전 폰트를 사용하는 것을 권장해요. 웹 안전 폰트는 Emailify의 “Preview” 기능에 있는 Configure Fonts 패널에서 설정할 수 있어요.

또한 일부 이메일 서비스 제공업체(예: MailChimp)는 웹 안전 폰트만 사용되도록 이메일을 보내기도 전에 사용자 지정 폰트를 적극적으로 제거해요.

그래도 Emailify는 Google 폰트 @import를 포함하고, 서식 있는 텍스트에 Google 폰트를 사용하면 웹 안전 대체 폰트(예: “Arial”, “Georgia”, “Courier”)도 설정해요. 이 폰트는 이메일에서 @font-face를 지원하는 이메일 클라이언트에서 표시돼요.

이미지 안에서 사용자 지정 폰트 사용하기. 모든 이메일 클라이언트에서 사용자 지정 폰트가 똑같이 보여야 한다면 텍스트 레이어를 “Image” 프레임 안에 넣는 것도 방법이에요. 이 텍스트 콘텐츠는 이미지의 일부로 내보내지기 때문에 사용자 지정 웹 폰트 지원 여부와 상관없이 제대로 표시돼요.

이메일 속 폼 요소는 지원되지 않아요 ​

HTML 이메일에서 form 요소 지원은 아직 꽤 낮은 편이고, 포함하면 이메일이 스팸 등으로 분류될 수 있어요. 그러니 지금은 HTML 이메일 안에 기본 폼을 쓰지 않는 것이 좋아요.

가장 좋은 대안은 Emailify 디자인에 보기 좋은 콜 투 액션(CTA) 버튼을 만들고, Google Forms나 Typeform 같은 외부 폼 URL로 연결해 수신자 정보를 브라우저에서 받는 거예요.

일부 클라이언트의 이미지 차단 방식 이해하기 ​

아래에 이미지 차단이 무엇인지, 그리고 어떤 이메일 클라이언트가 기본으로 이미지를 차단하는지(주로 Outlook) 잘 설명한 글이 두 개 있어요. 반면 Gmail, Android, Apple/iOS 등 다른 클라이언트는 기본으로 이미지를 표시해요.

How Image Blocking Works in Email(영어)

Email Image Blocking: Answering the What, Why, Where, Who, and How(영어)

아쉽게도 이는 이미지가 보안 연결(SSL)인지와는 관계가 없고, 이메일 안의 모든 이미지에 일괄 적용돼요.

다행히 수신자가 앞서 말한 이메일 클라이언트를 쓴다면 보통 이런 상황에 꽤 익숙해서 “이미지 표시” 버튼을 클릭하거나, 받은 이메일의 이미지가 기본으로 표시되도록 이미 설정해 두었을 가능성이 높아요.

Gmail의 보라색 텍스트(같은 제목으로 테스트 메일을 여러 번 보낼 때) ​

Gmail 계정으로 이메일 테스트를 여러 번 보내면 일부 텍스트가 진한 보라색으로 보일 수 있어요.

HTML 코드 문제가 아니에요. 같은 날 같은 제목으로 보낸 여러 이메일을 Gmail이 서로에 대한 답장이라고 판단하면 생기는 현상이에요. 이때 Gmail은 이메일 스레드를 “대화형 보기”로 표시해요.

Gmail의 대화형 보기에 대해 더 알아보려면 Google 문서(영어)를 읽어 보세요.

보라색은 화면 표시에만 쓰이는 기능으로, 보이는 화면에만 존재해요. 어떤 메시지에도 함께 전송되지 않으며, Gmail의 원본 보기 기능으로 이를 확인할 수 있어요. 단, HTML 코드를 조금은 알아야 해요.

이 색상은 현재 대화의 이전 메시지에서 반복된 텍스트에 적용돼요. 수신자에게도 보이는 이유는 수신자도 Gmail을 쓰고 현재 대화의 이전 메시지 사본을 갖고 있기 때문이에요. 수신자의 대화에서 색이 입혀지는 부분은 내 대화에서 색이 입혀지는 부분과 꽤 다를 수 있어요.

이메일 클라이언트가 날짜, 전화번호, 주소에 파란색 링크를 추가하는 문제 ​

일부 메일 클라이언트가 날짜, 전화번호, 주소 같은 텍스트에 자동으로 링크를 걸고 자체 색상 스타일(보통 파란색 링크)까지 적용하는 오래된 문제예요.

Emailify는 일부 이메일 클라이언트에서 이 문제를 줄이도록 권장 코드 수정 사항을 모두 자동으로 적용하지만, 클라이언트가 업데이트되면서 이런 수정 사항을 우회하거나 적용되지 않게 막는 경우가 많아요.

이메일 클라이언트가 링크를 자동으로 추가하지 못하게 하는 추가 방법이 2가지 있어요(둘 다 위 글에 나와 있어요).

방법 1은 Figma에서 해당 텍스트 레이어마다 자리 표시용 링크(예: 내 웹사이트)를 미리 걸어 두고, Figma에서 밑줄 스타일을 모두 없앤 뒤 색상을 원하는 대로 설정하는 거예요(그러면 클릭할 수 있는 것처럼 보이지 않아요). 이렇게 하면 날짜 텍스트에 링크 태그가 미리 씌워지므로, 이메일 클라이언트가 스타일 없는 자체 링크를 자동으로 적용하지 않아요.

방법 2는 날짜, 전화번호, 주소의 첫 글자 바로 뒤에 보이지 않는 특수 HTML 엔티티(‌)를 넣는 거예요(예: 6‌75 Massachusetts Ave, Cambridge, MA 02139). 이렇게 하면 이메일 클라이언트가 날짜가 아니라고 판단해 날짜 링크를 자동으로 적용하지 않을 가능성이 높아요.

일부 VPN에서 업로드된 이미지가 표시되지 않는 문제 ​

Upload Hosted Image URLs 기능을 켰거나 Emailify 내장 내보내기 옵션으로 HTML 이메일을 이메일 플랫폼에 업로드했다면, 아주 드물게 일부 VPN이 할당한 IP 주소가 이미지 호스트에서 차단되어 이미지가 로드되지 않을 수 있어요.

이미지가 로드되지 않는 문제가 있다면 이것이 원인일 가능성이 높아요(잠시 VPN을 끄고 직접 확인해 보세요).

이메일 서명은 사용자 지정 폰트를 지원하지 않아요 ​

일반 HTML 이메일에서는 사용자 지정 폰트를 임베드할 수 있지만(그래도 Apple Mail에서만 가능하고, Gmail이나 Outlook 같은 다른 클라이언트는 어떤 방식의 사용자 지정 폰트 임베드도 지원하지 않아요), 이메일 서명에서는 폰트 임베드 코드를 추가할 수 있는 style 태그 자체를 지원하지 않아요. 그러니 서명은 웹 안전 시스템 폰트를 사용하도록 디자인하세요.

Gmail iOS 앱에서 모바일 반응형 스타일이 렌더링되지 않는 문제 ​

주된 원인은 @media 쿼리 안의 CSS 속성이나 스타일에 오타가 있거나(예: padding-bottom 대신 padding-bottm), 스타일 속성 중간에 줄바꿈이 있는 경우예요(예: padd 줄바꿈 ing-top). 이러면 Gmail 앱은 다른 스타일을 모두 무시하고 모바일 반응형 재정의를 전혀 렌더링하지 않아요.

플러그인에서 바로 내보낸 코드에서는 생기지 않는 문제지만, Emailify에서 내보낸 뒤 HTML 코드를 직접 수정했거나 이메일 마케팅 플랫폼이 코드를 수정하거나 줄 길이 제한을 추가하면 생길 수 있어요.

HTML 이메일의 줄당 500자 제한 ​

Emailify는 내보내는 HTML을 줄당 500자로 제한해요. 공식 제한은 998자이지만, 줄을 더 짧게 하면 Outlook과 일부 이메일 서비스 제공업체에서 생기는 렌더링 및 전송 문제를 피할 수 있어요.

VPN 때문에 일부 소셜 미디어 링크가 제대로 열리지 않을 수 있어요 ​

드문 일이긴 하지만 일부 소셜 네트워크(예: Facebook, Instagram)로 가는 링크가 제대로 열리지 않는다면 이것이 원인일 가능성이 높아요(잠시 VPN을 끄고 직접 확인해 보세요). HTML 이메일이나 링크 자체의 문제는 아니에요.

Outlook ​

Outlook에서 모서리 둥글기(border-radius)가 표시되지 않는 문제 ​

아쉽게도 Outlook은 border-radius 속성을 지원하지 않아서 항상 일반적인 각진 모서리로 대체돼요. 어떤 이메일 클라이언트가 이 CSS 속성을 지원하는지는 border-radius 지원 목록을 참고하세요.

Outlook.com에서 버튼 높이가 줄어드는 문제(실제 URL이 없을 때) ​

버튼 컴포넌트의 높이가 그 안의 텍스트 레이어 크기로 줄어든다면, href가 실제 URL로 설정되지 않았을 때(예: https://google.com 같은 실제 URL 대신 [replaceLinkInHere]) Outlook.com에서 생기는 현상이에요. Figma에서 버튼 레이어를 클릭하고 플러그인의 Settings 버튼을 사용해 URL을 붙여 넣어 버튼 컴포넌트에 실제 URL을 설정하세요.

일부 Outlook 버전에서 ‘순서 반전’ Row에 생기는 1px 흰색 선 ​

일부 Outlook 버전에서 열 순서 반전(영어) 설정을 사용하면 열 하나 옆에 1px 흰색 선이 나타나는 알려진 버그가 있어요. Microsoft Word 렌더링 엔진 때문에 생기는 Outlook 렌더링 특성 중 하나로, 순서를 반전한 Row에 패딩이 적용되어 있을 때 생길 수 있어요.

가장 좋은 해결 방법은 순서를 반전한 Row 레이어에서 패딩을 없애고, Row를 Wrapper(영어)로 감싼 뒤 패딩을 바깥쪽 Wrapper로 옮기는 거예요. 이렇게 하면 시각적인 간격은 그대로 유지하면서 순서를 반전한 Row 자체에서 생기는 Outlook 렌더링 버그를 피할 수 있어요.

이 해결 방법은 관련 MJML GitHub 이슈에서 논의된 방식과 같아요.

Outlook이 날짜와 시간을 파란색 캘린더 링크로 자동 변환하는 문제 ​

Outlook이 텍스트를 날짜나 시간으로 인식해 자동으로 링크로 렌더링하지 않게 하려면, 요일, 날짜, 시간 사이에 “폭 없는 공백(zero-width space)” HTML 엔티티(​)를 넣어 Outlook의 패턴 인식을 깨뜨리면 돼요. 테스트를 거쳐 작동이 확인된 예시는 다음과 같아요: Monday​ — Friday 8​am to 5​pm

악센트(발음 구별 기호)가 있는 대문자 텍스트가 잘리는 문제 ​

“대문자” 텍스트 레이어에 발음 구별 기호가 있는 문자(예: Ä, Ö, Ü)가 있는데 Outlook에서 위쪽 악센트가 보이지 않는다면, Figma 텍스트 레이어의 “줄 높이” 값이 “폰트 크기” 값보다 작기 때문이에요. Outlook은 줄 높이 값 안에 들어가지 않는 콘텐츠를 사실상 잘라 내요(다른 클라이언트는 그냥 넘쳐서 보이게 두고요).

이 문제를 해결하려면 줄 높이 값을 폰트 크기보다 조금 더 크게 늘리기만 하면 돼요. 예를 들어 폰트 크기가 “24px”인 텍스트 레이어의 줄 높이가 현재 “23px”이라면, Figma에서 줄 높이를 “23px”에서 “28px”로 늘리세요(24px 대문자 위로 올라오는 악센트를 위한 여유 높이를 충분히 확보하기 위해서예요). 그러면 줄 높이가 낮아서 잘리던 악센트와 발음 구별 기호가 Outlook에서 제대로 렌더링돼요.

무작위로 나타나는 Outlook ‘1px 선’ 버그 ​

일부 Outlook 버전에서 무작위로 나타나는 Outlook 1px 선 버그(영어)라는 아주 성가신 문제가 있어요.

Outlook은 이메일에 선을 추가로 넣어요. 이 선은 body 태그에 설정된 배경을 상속해요... 설상가상으로 이 버그는 무작위로 생기는 것 같은데, Windows 7보다 Windows 10 컴퓨터에서 더 자주 나타나요.

위 글에서도 말하듯이 꽤 무작위로 생기고 확실한 해결책은 없지만, 선이 나타나는 위치 위쪽 텍스트 콘텐츠의 폰트 크기를 이리저리 조정해 보면 대개 해결할 수 있어요. 예를 들어(글에서 인용):

어떤 사람에게는 폰트 크기를 홀수에서 짝수로 바꾸기만 해도 해결돼요. 예를 들어 폰트 크기가 13px이나 15px이라면 14px로 바꿔 보세요.

Fixing White Lines in Outlook(영어)이라는 좋은 개요 글에서도 추가 정보와 가능한 해결 방법을 자세히 다뤄요.

더 깊이 알아보려면 Outlook 2016 madness and the weird 1px thin horizontal lines(영어) 글에서 근본적인 문제를 더 자세히 설명하고, 자세한 Litmus 포럼 토론(영어)에서도 가능한 원인과 문제 해결 방법을 추측해 볼 수 있어요.

Gmail ​

Gmail이 이메일을 잘라 내는 문제 ​

Gmail은 메시지 크기가 102KB보다 큰 이메일을 잘라 내고 전체 내용을 “View entire message” 링크 뒤에 숨겨요. 이를 피하려면 내보내기 전에 Preview 버튼으로 HTML 파일 크기를 확인하고, 콘텐츠를 최대한 줄여 파일 크기를 낮춰 보세요.

HTML 파일 크기 제한보다 작은데도 이메일이 잘린다면, 이메일 콘텐츠에 쓰인 UTF-8 문자 때문일 가능성이 가장 높아요. UTF-8 문자도 Gmail이 이메일을 잘라 내게 만들 수 있어요. 가장 좋은 해결책은 UTF-8 문자를 HTML 인코딩 버전으로 바꾸는 거예요(예: © 대신 &copy 사용). 플러그인은 이 작업을 자동으로 적용해요.

같은 제목으로 이메일을 보낼 때(예: 나에게 테스트 메일을 여러 번 보낼 때)도 이런 일이 생겨요. Gmail이 이메일을 하나의 스레드로 묶으면서 이후에 보낸 메일의 내용을 잘라 낼 수 있어요. 이를 피하려면 제목을 항상 다르게 하세요(예: “Test v1”, “Test v2” 등).

다크 모드의 Gmail 모바일 앱에서 버튼의 흰색 텍스트가 검은색으로 바뀌는 문제 ​

Gmail(및 다른 앱)은 사용자의 시스템 테마가 다크 모드로 설정되어 있으면 버튼을 포함해 이메일에 다크 모드 스타일을 자동으로 적용해요.

라이트 모드와 다크 모드 모두에서 흰색 텍스트를 유지해야 하는 버튼이라면:

  1. Figma에서 버튼 텍스트 레이어를 순수한 흰색(#FFFFFF)으로 설정하세요.
  2. Button 컴포넌트를 선택하고 Settings를 연 다음, 다크 모드 재정의 텍스트 색상도 순수한 흰색(#FFFFFF)으로 설정하세요.
  3. 이메일을 다시 내보내고, 문제가 생겼던 Gmail 모바일 앱으로 테스트 메일을 보내세요.

두 색상을 모두 순수한 흰색으로 설정하면 Emailify가 흰색 버튼 텍스트를 유지하기 위한 호환성 코드를 추가해요. 이 해결 방법은 검은색이나 흰색이 아닌 다른 색상의 텍스트를 유지해 주지 않으며, 버튼 배경색을 고정하지도 않아요. 디자인에 연한 배경 위 검은색 텍스트가 필요하다면 의도한 색상을 그대로 두고 그 디자인은 따로 테스트하세요. 텍스트를 흰색으로 바꾸면 그 요구 사항을 해결하는 게 아니라 디자인 자체가 바뀌어요.

그래도 결과가 디자인과 다르다면 내보낸 HTML 또는 ZIP, 스크린샷, 이메일 앱과 기기, 유지하고 싶은 텍스트/배경 색상을 함께 보내 지원팀에 문의해 주세요. 이미 시도해 본 설정도 알려 주세요. 전체 워크플로와 제한 사항은 다크 모드 디자인 및 테스트(영어)를 참고하세요.

Gmail 데스크톱에서 열이 세로로 쌓이는 문제 ​

일부 이메일 서비스 제공업체(예: MailChimp)는 이메일을 보내기 전에 HTML을 수정하려고 하는데, 이 때문에 Gmail 데스크톱에서 이메일의 일부 열이 한 줄로 나란히 있지 않고 세로로 쌓일 수 있어요.

이런 플랫폼이 HTML을 수정하는 이유는 보통 HTML 요소에 스타일을 “인라인”으로 넣기 위해서예요. 하지만 Emailify는 모든 CSS 스타일을 미리 자동으로 인라인 처리하므로 이메일을 바로 쓸 수 있어요. 이메일 서비스 제공업체의 HTML/가져오기 옵션에서 이런 인라인 처리나 수정을 “끄는” 설정을 찾을 수 있다면 문제가 해결될 거예요.

이메일 서비스 제공업체 때문인지 코드 자체 때문인지 확실하지 않다면, HTML을 전혀 수정하지 않는 htmltest.email 같은 무료 서비스로 나에게 테스트 이메일을 보내 보세요. htmltest.email에서 보낸 테스트가 제대로 표시된다면, 이메일 서비스 제공업체가 발송 전에 HTML을 수정하고 있는 거예요.

iOS용 Gmail은 최소 줄 높이를 강제로 적용해요 ​

line-height를 현재 font-size보다 작은 값으로 설정하면 Gmail이 자동으로 line-height:normal;로 바꿔요. 그래서 line-height:1, line-height:1em, line-height:100%는 모두 예상대로 작동하지만, line-height:0.9, line-height:0.9em, line-height:99%는 모두 line-height:normal;로 바뀌어요.

px 값도 마찬가지예요. font-size:20px; line-height:19px는 작동하지 않지만 font-size:19px; line-height:19px는 작동해요.

이 문제를 해결하려면 텍스트 레이어의 줄 높이가 폰트 크기와 같거나 더 크게 설정되어 있는지만 확인하세요.

Gmail iOS 앱에서 모바일 반응형 스타일이 렌더링되지 않는 문제 ​

주된 원인은 @media 쿼리 안의 CSS 속성이나 스타일에 오타가 있거나(예: padding-bottom 대신 padding-bottm), 스타일 속성 중간에 줄바꿈이 있는 경우예요(예: padd 줄바꿈 ing-top). 이러면 Gmail 앱은 다른 스타일을 모두 무시하고 모바일 반응형 재정의를 전혀 렌더링하지 않아요.

플러그인에서 바로 내보낸 코드에서는 생기지 않는 문제지만, Emailify에서 내보낸 뒤 HTML 코드를 직접 수정했거나 이메일 마케팅 플랫폼이 코드를 수정하거나 줄 길이 제한을 추가하면 생길 수 있어요.

Gmail이 영어로만 된 이메일을 다른 언어로 잘못 인식해 번역하는 문제 ​

이메일이 서식 있는 텍스트 없이 대부분 이미지 블록으로 되어 있거나, 서식 있는 텍스트가 아래쪽에 나오기 전에 이미지 블록이 많으면, Gmail이 이메일을 다른 언어로 판단해 영어로 번역할지 묻는 경우가 있어요. Emailify가 html 태그와 body 태그에 lang="en" 속성을 자동으로 추가하는데도 그래요.

Litmus 포럼의 이 문제를 다룬 글(영어)에서는 이렇게 말해요.

실제 콘텐츠 앞에 CSS와 HTML이 많이 들어 있는 메일은 콘텐츠가 다른 언어로 되어 있어도 영어로 분류된다는 것을 (경험적으로) 확인했어요.

저희는 텍스트와 HTML로 된 멀티파트 이메일을 보내고, 텍스트 버전을 HTML 부분 앞에 두는 방법으로 해결했어요. 물론 텍스트는 “Bonjour ...” 정도가 아니라 충분한 분량이어야 해요. 그렇지 않으면 여전히 HTML 태그와 CSS가 더 큰 비중을 차지하거든요.

번역 알고리즘은 메일 본문에서 html/css를 걸러 내려고 하지 않는 것 같아요. 걸러 낸다고 해도 걸러 내기 전에 메시지를 잘라 버려서, 언어 감지에 쓸 콘텐츠가 거의 남지 않는 것일 수도 있어요. (요즘은 콘텐츠 한 줄이 나오기 전에 헤더와 CSS만 5000자가 넘는 경우도 흔해요.)

GIF ​

동영상을 이메일용 애니메이션 GIF로 변환하기 ​

아쉽게도 HTML 이메일에서는 기본 video 태그를 지원하지 않기 때문에, HTML 이메일 디자인에 움직이는 이미지나 동영상 콘텐츠를 넣는 가장 좋은 방법은 GIF를 쓰는 거예요. 인터넷에서 다운로드한 GIF 파일이나 직접 만든 GIF를 사용할 수 있어요.

GIF로 쓰고 싶은 동영상이 이미 있다면, Gifski라는 무료 앱으로 짧은 동영상 파일을 애니메이션 GIF 파일로 변환해 이메일 디자인에 쓸 수 있어요.

Emailify 디자인에서 GIF를 쓰는 여러 방법과 HTML 내보내기에 포함하는 방법을 다룬 유용한 영상 튜토리얼(영어)도 있어요.

GIF의 색상이나 그라디언트가 거칠어 보이는 문제 ​

GIF는 최대 256색까지만 담을 수 있어 일반 JPG/PNG 이미지와는 조금 달라요. 디테일이 많은 이미지나 색상 변화가 많은 그라디언트를 사용하면, GIF 형식의 이런 제한 때문에 GIF의 원본 이미지만큼 선명하거나 색이 정확하지 않은 것이 정상이에요.

GIF에서 투명도가 표시되지 않는 문제 ​

GIF 파일 형식은 불투명도 0% 또는 100%만 지원하고 그 사이 값은 지원하지 않아요. 그래서 완전히 불투명하게 보이는 요소 뒤에 완전히 투명한 배경이 있는 애니메이션 GIF는 만들 수 있어요. 즉 레이어는 완전히 투명하거나 완전히 불투명해야 해요. 불투명도가 50%보다 낮은 레이어는 투명해지고, 50%보다 높은 레이어는 불투명해져요.

Figma에서 투명 GIF 지정하기. Emailify는 GIF에 투명한 배경이 있는지 자동으로 감지하려고 해요. GIF에 투명도가 꼭 필요한데 플러그인이 스스로 감지하지 못한다면, Figma 레이어 이름 아무 곳에나 Transparent라는 단어를 넣으세요(예: My Layer Name - Transparent). 그러면 투명한 배경을 켠 상태로 강제로 내보내져요.

내보낼 때 원본 GIF 파일 유지하기(가로세로 비율 유지) ​

GIF를 Figma에 넣고 원래 가로세로 비율을 유지하도록 레이어 크기를 비례에 맞게 조정하면, Emailify가 내보낼 때 원본 GIF 파일을 자동으로 사용해요.

반대로 Figma 레이어의 가로세로 비율을 원본 GIF와 다르게 바꾸면, Emailify가 잘린 이미지 영역에 맞춰 GIF를 다시 만들어야 해요. 그러면 GIF 파일 크기가 커지고 내보내기 시간이 길어질 수 있어요.

Gmail에서 GIF 이미지가 표시되지 않는 문제(파일 크기 제한) ​

디자인에 GIF를 썼는데 Gmail 받은편지함으로 테스트 메일을 보냈을 때 보이지 않는다면, Gmail 이미지 캐싱 제한에 걸려 렌더링되지 않았을 가능성이 높아요.

HTML로 내보낼 때 Emailify는 큰 GIF를 압축해 Gmail의 파일 크기 제한 아래로 맞추려고 해요. 그래서 거의 모든 경우 이 문제가 해결될 거예요(처음부터 GIF가 유난히 길거나, 크기가 크거나, 프레임 속도가 아주 높은 경우는 예외예요).

Klaviyo ​

이메일 디자인에 GIF를 쓰면 Klaviyo 템플릿 편집기가 (가끔) 멈추는 문제 ​

Klaviyo에는 무작위로 Error 500(내부 서버 오류)이 발생해 Something is amiss. We're on it. 페이지가 표시되는 버그가 있어요. 주로 템플릿이 “Editable”일 때 생기는 것으로 보여요.

Klaviyo도 이 버그를 알고 있지만, 가까운 시일 안에 고칠 계획은 없는 것 같아요.

한 가지 해결 방법은 Klaviyo용 HTML을 내보내기 전에 Figma 디자인에서 GIF를 빼고, 템플릿 편집기가 위 오류 없이 로드된 뒤 GIF 이미지를 Klaviyo에 따로 업로드하는 거예요.

편집 가능한 Klaviyo 템플릿에서 텍스트 블록 주위에 패딩이 추가되는 문제 ​

Klaviyo가 편집기를 업데이트하고 2023년 6월 6일부터 모든 템플릿에 새 편집기를 강제로 적용하면서, 아쉽게도 Emailify에서 Editable Content 토글을 켜고 HTML 이메일을 내보내면 Klaviyo가 기본적으로 텍스트 요소마다 약 18px의 패딩을 자동으로 추가해요. 편집 가능한 템플릿이면 HTML에 새 td 요소를 삽입하고 거기에 인라인 style 속성으로 패딩을 넣는 방식이에요.

Emailify에서 Force the padding added by Klaviyo's new editor to be 0px 토글을 켜면 모든 모바일 클라이언트와 Gmail 같은 Outlook 외 데스크톱 클라이언트에서 이 패딩을 없애는 CSS가 자동으로 추가돼요. 하지만 Outlook에서는 Klaviyo 편집기에서 캠페인용 이메일을 편집할 때 템플릿의 모든 편집 가능한 텍스트 블록의 “Padding” 값을 직접 “0”으로 바꾸지 않으면 여전히 패딩이 렌더링돼요.

Klaviyo 미리보기 텍스트가 중복되거나 본문 내용이 추가로 표시되는 문제 ​

미리보기 텍스트는 한 곳에서만 설정하세요. Emailify에서 이미 Preheader Text를 입력했다면 Klaviyo의 미리보기 텍스트 필드는 비워 두세요. Klaviyo에서 미리보기 텍스트를 관리하고 싶다면 해당 내보내기에서는 Emailify의 프리헤더를 비워 두세요.

의도한 미리보기 텍스트 뒤에 Klaviyo가 여전히 본문 내용을 추가로 표시한다면, Emailify의 내보내기 옵션에서 Add Whitespace to Preview Text를 켜고 이메일을 다시 내보내세요. 비어 있지 않은 프리헤더 뒤에 보이지 않는 호환성 공백을 추가해 주지만, 받은편지함에서 어떻게 처리되는지는 Klaviyo와 이메일 클라이언트에 따라 여전히 다를 수 있어요.

전체 프리헤더 워크플로는 HTML 이메일의 제목과 프리헤더 텍스트 설정(영어)을 참고하세요.

MailChimp ​

편집 가능한 이미지를 켜면 더 흐린 @1x 이미지가 사용돼요(@2x 레티나 대신) ​

Editable Images 토글로 템플릿의 이미지를 MailChimp에서 편집할 수 있게 설정할 수 있지만, 아쉽게도 MailChimp는 편집 가능한 @2x 레티나 이미지를 지원하지 않아서 이미지가 @1x로 바뀌어요.

편집할 수 없더라도 @2x 레티나 이미지를 원한다면 이 옵션을 꺼 두세요.

이메일에 사용자 지정 Typekit 스타일시트를 추가하면 MailChimp가 링크 스타일을 제거해요. 구체적으로는 <head>에 다음과 같은 태그를 넣으면: <link rel="stylesheet" href="https://use.typekit.net/lml7iwl.css">

MailChimp가 <a> 태그에서 style 속성을 모두 제거해요. 이 태그를 지우면 문제가 해결되고 링크 스타일이 돌아와요.

그래도 Typekit 폰트를 쓰고 싶다면 플러그인에 내장된 Web Fonts 기능으로 쓸 수 있어요. 스타일시트를 링크하는 대신 Typekit CSS 파일에 있는 .woff2 폰트 파일의 직접 URL이 필요해요(예: https://use.typekit.net/...). 이 URL을 플러그인의 Configure Fonts 패널에 붙여 넣으면 HTML에서 Figma 폰트 이름에 맞는 @font-face 스타일이 자동으로 생성돼요. 자세한 내용은 단계별 영상 튜토리얼(영어)을 참고하세요.

사용자 지정 웹 폰트는 Apple Mail에서만 작동한다는 점을 기억하세요. 다른 이메일 클라이언트(예: Outlook, Gmail)는 지원하지 않으니, 플러그인에서 웹 안전 대체 폰트를 설정해 대신 표시될 폰트를 정하는 것을 권장해요. Figma에서 처음부터 웹 안전 폰트로 디자인하는 것이 가장 쉽다는 사용자가 많지만, 사용자 지정 웹 폰트를 추가하면 Apple Mail 사용자를 위한 좋은 점진적 향상이 될 수 있어요.