모든 캠페인 발송 전에 할 점검과 Brew 이메일 점검의 기준값을 정리했어요. 102 KB 잘림, 깨진 링크, 대체 텍스트, 클라이언트 지원, 카피 길이를 다뤄요.
발송 전 QA 체크리스트는 모든 이메일을 내보내기 전에 확인하는 짧은 점검 목록이에요. 문제가 있는 캠페인은 대개 버튼 링크가 아직 # 기호를 가리키거나, 저녁 6시에 히어로 이미지가 4 MB짜리 PNG로 바뀌었거나, 클래식 Outlook이 무시하는 2단 레이아웃인 채로 나가요. 하나같이 발송 전에는 1분이면 잡아낼 수 있지만, 발송한 뒤에는 고칠 수 없어요.
저희는 이번 달에 이 점검 항목을 중심으로 Brew의 이메일 점검을 새로 만들었고, 항목마다 정확한 기준값을 정했어요. Brew를 쓰든 안 쓰든 직접 해 볼 수 있어요.
심각도별로 묶은 점검 결과와 하나의 발송 준비 판정.
깨진 링크 하나가 발송을 헛되게 만들어요. 다음을 확인하세요:
#, example.com, 채워지지 않은 {{url}} 같은 값이 아니라 실제 목적지로 연결되는지https를 쓰는지brew.new/pricing이라고 적힌 링크가 다른 곳으로 연결되면 피싱처럼 보여요링크는 에디터가 아니라 받은 테스트 이메일에서 하나하나 클릭해 보세요. ESP는 발송 시점에 클릭 추적을 위해 링크를 다시 쓰기 때문에, 리디렉션 체인이나 깨진 추적 파라미터는 실제로 받은 메일에서만 드러나요.
자동 검사 도구가 수신 거부 링크나 수신 설정 링크에 요청을 보내게 해서는 절대 안 돼요. 일부 업체는 그 URL에 들어온 요청을 모두 수신 거부로 처리해요. 그리고 검사 도구에 봇 차단 페이지가 나타났다고 해서 링크가 깨졌다는 뜻은 아니에요. 직접 클릭해 보세요.
Gmail은 HTML이 약 102 KB를 넘는 메시지를 잘라 “전체 메시지 보기(View entire message)” 링크 뒤로 숨겨요. 그러면 푸터, 수신 거부 링크, 우편 주소가 가려지기 때문에, 잘린 마케팅 이메일은 소리 없이 규정 준수 문제가 돼요.
저희 기준값은 다음과 같아요:
80 KB에서 경고하는 이유는 클릭 추적이 짧은 링크를 더 긴 리디렉션 URL로 바꾸고, 일부 ESP는 마크업을 덧붙이기 때문이에요. 에디터에서 98 KB였던 이메일이 105 KB로 도착할 수 있어요.
용량을 키우는 흔한 원인은 요소마다 반복되는 인라인 스타일, 빌더가 남긴 주석, 숨겨 둔 모바일용·데스크톱용 중복 섹션, base64로 삽입한 이미지예요.
모든 이미지는 다음 조건을 갖춰야 해요:
alt 텍스트가 있을 것. 순수한 장식용이라면 alt=""width와 height를 지정할 것큰 이미지 한 장에 텍스트 한 줄만 달린 이메일은 이미지를 끄면 읽을 수 없고, 스크린 리더도 내용을 알 수 없으며, 일부 필터에는 스팸 신호로 보여요. 헤드라인과 혜택은 이미지가 아닌 텍스트로 넣으세요.
Flexbox, grid, position, 배경 이미지, 인라인 SVG는 각각 주요 클라이언트 중 적어도 하나에서 깨져요. Can I email은 기능별, 클라이언트별 지원 현황을 추적하는, 하나만 고르라면 가장 좋은 참고 자료예요.
가장 주의할 건 Outlook이에요. Gmail과 Apple Mail은 보통 티 나지 않게 표시가 조금 무너지는 정도로 그쳐요. Windows용 클래식 Outlook은 Word의 레이아웃 엔진으로 렌더링하기 때문에 CSS 너비 설정을 상당수 무시하고, 배경 이미지를 빼 버리고, 스타일을 입힌 링크로 만든 버튼에서 안쪽 여백을 없애요.
저희는 Gmail이나 Outlook 같은 클라이언트 계열 안에서 적어도 두 클라이언트가 어떤 기능을 지원하지 않을 때만 그 기능을 표시해요. 경고는 Outlook에서 대체 수단 없이 깨질 때만 띄우고, 나머지는 모두 정보로 표시해요. 그러지 않으면 이메일마다 클라이언트 경고가 스무 개씩 붙고, 사람들은 결국 전부 무시하게 돼요.
손쉽게 할 수 있는 점검:
<html>에 lang 속성 지정<title> 요소h1에서 h4로 건너뛰지 않기기준은 WCAG 2.2예요. 이메일에서 생기는 문제는 대부분 대체 텍스트, 명도 대비, 페이지 언어, 헤딩에 관한 WCAG 기준에 해당해요.
제목은 약 60자, 9단어 미만으로 쓰세요. 그보다 길면 휴대폰에서 잘려요. 영문을 전부 대문자로 쓰거나, 답장이 아닌 메일에 “RE:”나 “FWD:”를 붙이거나, 느낌표를 연달아 쓰는 건 피하세요.
미리보기 텍스트는 제목을 반복하지 말고 약 90자 미만으로 쓰세요. 비워 두면 많은 클라이언트가 대신 ‘브라우저에서 보기’ 같은 문구를 보여 줘요.
대체값이 없는 개인화 태그는 이름이 없는 모든 수신자에게 “ 님, 안녕하세요”를 보내요. 독자는 이런 걸 기억해요.
모든 수치에는 가리킬 수 있는 출처가 있어야 해요. 확신에 찬 숫자를 쉽게 만들어 내는 AI 초안이라면 더욱 그래요. 문구는 읽는 사람이 행동으로 옮길 수 있는 마케팅 이메일 작성법과 제목 가이드에서 더 자세히 다뤄요.
CAN-SPAM에 따라 상업용 이메일에는 제대로 작동하는 수신 거부 링크와 유효한 우편 주소가 있어야 해요. Gmail과 Yahoo에 대량으로 보내는 발신자는 원클릭 수신 거부 헤더도 갖춰야 해요. 자세한 내용은 에이전트가 이메일을 보낼 때도 여전히 적용되는 원칙에서 다뤄요.
트랜잭션 메일은 일부 마케팅 규칙에서는 빠지지만, 이 체크리스트에서는 빠지지 않아요. 깨진 링크가 있는 영수증도 결국 고객 지원 문의로 돌아와요.
이메일 클라이언트가 제거하거나 차단하는 요소는 빼세요:
<script>, <form>, <iframe> 요소data: URIbackground-color 대체 색상이 없는 배경 이미지. 이미지가 로드되지 않아도 텍스트를 읽을 수 있도록 대체 색상을 지정하세요doctype으로 시작하세요. doctype이 없으면 일부 클라이언트가 쿼크 모드로 렌더링해 간격이 틀어져요.
Brew의 이메일 점검은 다음 위치에서 이 목록을 실행해요:
POST /v1/emails/audit 엔드포인트 또는 audit_email 도구모든 필드는 점검 문서와 API 레퍼런스에서 확인하세요.
무료 즉시 점검은 HTML만 있으면 되는 모든 규칙에 대해 자동으로 실행돼요. 자리 표시자, 용량, 누락된 대체 텍스트와 이미지 크기, 헤딩 순서, lang과 <title>, 제목과 미리보기 텍스트 길이, 대체값 없는 개인화 태그, 차단되는 마크업이 여기에 해당해요.
점검 실행은 네트워크 요청이나 판단이 필요한 점검을 더해요:
각 AI 판단은 저희 소유의 이메일에서 제기한 문제가 95% 이상 맞도록 조정돼 있어요. 양치기 소년처럼 헛경보를 울리는 AI 검토자는 없느니만 못해요.
전체 점검에는 크레딧 5개가 들어요. 필수 점검 항목을 실행할 수 없으면 점수 없이 무료 부분 점검 결과를 받아요. 점검을 건너뛴 점수는 오해를 부를 수 있기 때문이에요.
모든 점검은 0~100점의 점수와 함께 ‘준비 완료’, ‘검토 필요’, ‘준비 안 됨’ 중 하나의 상태를 반환해요(앱에서는 ‘발송 준비 완료’, ‘검토 필요’, ‘문제 발견’으로 표시돼요). 각 점검 결과에는 심각, 오류, 경고, 정보 중 하나의 심각도와, 깨진 링크의 HTTP 상태 같은 근거가 함께 표시돼요.
점수는 100점에서 시작해요. 심각 항목은 하나당 20점, 오류는 10점, 경고는 3점이 깎이고, 정보는 감점이 없어요. 규칙마다 처음 세 번까지만 감점돼요.
예를 들어 버튼이 # 기호로 연결되어 있고, 푸터 링크가 404를 반환하고, 대체 텍스트 없는 이미지가 두 개 있고, 제목이 68자이고, Yahoo 클라이언트 두 개가 무시하는 flexbox를 썼다고 해 볼게요.
| 점검 결과 | 심각도 | 점수 |
|---|---|---|
| 버튼 링크가 자리 표시자 | 심각 | −20 |
| 푸터 링크가 404 반환 | 오류 | −10 |
| 대체 텍스트 없는 이미지(×2) | 경고 | −6 |
| 60자를 넘는 제목 | 경고 | −3 |
| Yahoo 클라이언트 2개가 flexbox 미지원 | 정보 | 0 |
| 점수 | 61 |
심각이나 오류 항목이 하나라도 있으면 ‘준비 안 됨’, 경고만 있으면 ‘검토 필요’예요. 링크 두 개를 고치면 이 이메일은 91점, ‘검토 필요’가 돼요. 솔직한 판정이죠. 그대로 보내도 문제는 없지만, 나머지도 1분 정도 들여 고칠 만해요.
채팅에서 수정을 누르면 경고 이상의 항목을 Brew 에이전트에게 넘기고, 수정이 끝나면 무료 즉시 점검을 다시 실행해요.
점검은 발송을 막지 않아요. 심각 항목이 있으면 발송 창에서 그래도 보내기를 눌러야 하고, 이렇게 경고를 무시하고 보낸 기록이 남아요. API, MCP, 자동화 발송은 점검 결과를 보고한 뒤 그대로 진행돼요. 이게 올바른 기본값이에요. 점검이 마음에 들어 하지 않는 이메일 중에도 보내야 하는 게 있고, 발송을 볼모로 잡는 QA 도구는 결국 꺼지게 돼요.
점검은 HTML을 고쳐 쓰지 않아요. 수정은 직접 시작하는 별도의 단계예요.
받은편지함 도달 테스트, 렌더링 스크린샷, 다크 모드 확인도 하지 않아요. 다크 모드는 휴대폰에서 다크 모드를 켜고 테스트 이메일을 열어 보세요. 검은 배경에서 사라지는 로고를 잡아낼 수 있어요.
발송 창에서는 15분이에요. 15분이 지나거나 이메일이 바뀌면 패널에서 다시 점검하라고 안내해요. MCP로는 저장된 리포트를 7일 동안 무료로 다시 읽을 수 있어요.
아니요. 점검은 이메일 자체만 확인해요. 받은편지함 도달은 도메인 평판, 인증, 스팸 신고율에도 달려 있으며, 이 내용은 전달성 가이드에서 다뤄요.
네, API나 MCP로 할 수 있어요. Brew 이메일 ID 대신 emailHtml 또는 emailJsx 값을 보내면, ESP에 넣기 전에 같은 리포트를 받을 수 있어요. 갤러리 템플릿을 리믹스해 ESP로 내보낸다면, 내보내기 전에 Brew에서 점검하세요.
브랜드에 접근할 수 있는 사람이라면 누구나 실행할 수 있어요. 조직 관리자와 브랜드에 추가된 멤버가 여기에 해당해요. Brew에는 보기 전용 역할이 없어요.
