# 발송 전 이메일 QA 체크리스트: 꼭 확인할 8가지

정식 URL: https://brew.new/ko/blog/pre-send-email-qa-checklist
글쓴이: Thomas Park
게시일: 2026-10-11
수정일: 2026-10-11

발송 전 QA 체크리스트는 모든 이메일을 내보내기 전에 확인하는 짧은 점검 목록이에요. 문제가 있는 캠페인은 대개 버튼 링크가 아직 `#` 기호를 가리키거나, 저녁 6시에 히어로 이미지가 4 MB짜리 PNG로 바뀌었거나, 클래식 Outlook이 무시하는 2단 레이아웃인 채로 나가요. 하나같이 발송 전에는 1분이면 잡아낼 수 있지만, 발송한 뒤에는 고칠 수 없어요.

저희는 이번 달에 이 점검 항목을 중심으로 Brew의 이메일 점검을 새로 만들었고, 항목마다 정확한 기준값을 정했어요. Brew를 쓰든 안 쓰든 직접 해 볼 수 있어요.

![점수, 발송 준비 상태, 심각도별로 묶은 점검 결과를 보여 주는 이메일 점검 화면.](/images/blog/email-audit-findings.png)

*심각도별로 묶은 점검 결과와 하나의 발송 준비 판정.*

## 핵심 요약

- 링크, 용량, 이미지, 클라이언트 지원, 접근성, 카피, 규정 준수, 마크업의 8가지 영역을 확인하세요.
- Gmail은 약 102 KB가 넘는 HTML을 잘라 푸터와 수신 거부 링크를 숨겨요. 클릭 추적이 용량을 늘리기 때문에 Brew는 80 KB부터 경고해요.
- 받은 테스트 이메일에서 모든 링크를 클릭해 보세요. 단, 자동 검사 도구가 수신 거부 링크나 수신 설정 링크를 열게 해서는 절대 안 돼요.
- Brew의 점검은 0~100점으로 점수를 매겨요. 심각 항목은 하나당 20점, 오류는 10점, 경고는 3점씩 깎여요. 심각이나 오류 항목이 하나라도 있으면 ‘준비 안 됨’이에요.
- 점검은 발송을 막지 않으며, 받은편지함 도달, 렌더링 스크린샷, 다크 모드는 테스트하지 않아요.

## 1. 링크

깨진 링크 하나가 발송을 헛되게 만들어요. 다음을 확인하세요:

- 모든 버튼이 `#`, `example.com`, 채워지지 않은 `{{url}}` 같은 값이 아니라 실제 목적지로 연결되는지
- 404나 410을 반환하거나, 조회되지 않는 도메인을 가리키거나, 인증서에 문제가 있거나, 연결을 거부하거나, 리디렉션이 반복되는 링크가 없는지
- 모든 링크가 `https`를 쓰는지
- 눈에 보이는 링크 텍스트가 실제 목적지와 일치하는지. `brew.new/pricing`이라고 적힌 링크가 다른 곳으로 연결되면 피싱처럼 보여요
- 공개 URL 단축 서비스를 쓰지 않는지. 단축 서비스는 그 서비스를 쓰는 모든 스패머와 평판을 공유해요

링크는 에디터가 아니라 받은 테스트 이메일에서 하나하나 클릭해 보세요. ESP는 발송 시점에 클릭 추적을 위해 링크를 다시 쓰기 때문에, 리디렉션 체인이나 깨진 추적 파라미터는 실제로 받은 메일에서만 드러나요.

자동 검사 도구가 수신 거부 링크나 수신 설정 링크에 요청을 보내게 해서는 절대 안 돼요. 일부 업체는 그 URL에 들어온 요청을 모두 수신 거부로 처리해요. 그리고 검사 도구에 봇 차단 페이지가 나타났다고 해서 링크가 깨졌다는 뜻은 아니에요. 직접 클릭해 보세요.

## 2. 용량

Gmail은 HTML이 약 **102 KB**를 넘는 메시지를 잘라 “전체 메시지 보기(View entire message)” 링크 뒤로 숨겨요. 그러면 푸터, 수신 거부 링크, 우편 주소가 가려지기 때문에, 잘린 마케팅 이메일은 소리 없이 규정 준수 문제가 돼요.

저희 기준값은 다음과 같아요:

- HTML **80 KB**: 경고
- HTML **102 KB**: Gmail에서 잘리므로 오류
- HTML과 이미지를 합친 전체 로드 용량 **3 MB**: 경고
- 전체 로드 용량 **5 MB**: 오류

80 KB에서 경고하는 이유는 클릭 추적이 짧은 링크를 더 긴 리디렉션 URL로 바꾸고, 일부 ESP는 마크업을 덧붙이기 때문이에요. 에디터에서 98 KB였던 이메일이 105 KB로 도착할 수 있어요.

용량을 키우는 흔한 원인은 요소마다 반복되는 인라인 스타일, 빌더가 남긴 주석, 숨겨 둔 모바일용·데스크톱용 중복 섹션, base64로 삽입한 이미지예요.

## 3. 이미지

모든 이미지는 다음 조건을 갖춰야 해요:

- `alt` 텍스트가 있을 것. 순수한 장식용이라면 `alt=""`
- 이미지를 불러오는 중이거나 차단됐을 때도 레이아웃이 유지되도록 `width`와 `height`를 지정할 것
- 제대로 로드되고, HTML 오류 페이지가 아닌 실제 이미지일 것
- **1 MB** 미만일 것. GIF는 **3 MB** 미만

큰 이미지 한 장에 텍스트 한 줄만 달린 이메일은 이미지를 끄면 읽을 수 없고, 스크린 리더도 내용을 알 수 없으며, 일부 필터에는 스팸 신호로 보여요. 헤드라인과 혜택은 이미지가 아닌 텍스트로 넣으세요.

## 4. 클라이언트 지원

Flexbox, grid, `position`, 배경 이미지, 인라인 SVG는 각각 주요 클라이언트 중 적어도 하나에서 깨져요. [Can I email](https://www.caniemail.com/)은 기능별, 클라이언트별 지원 현황을 추적하는, 하나만 고르라면 가장 좋은 참고 자료예요.

가장 주의할 건 Outlook이에요. Gmail과 Apple Mail은 보통 티 나지 않게 표시가 조금 무너지는 정도로 그쳐요. Windows용 클래식 Outlook은 Word의 레이아웃 엔진으로 렌더링하기 때문에 CSS 너비 설정을 상당수 무시하고, 배경 이미지를 빼 버리고, 스타일을 입힌 링크로 만든 버튼에서 안쪽 여백을 없애요.

저희는 Gmail이나 Outlook 같은 클라이언트 계열 안에서 적어도 두 클라이언트가 어떤 기능을 지원하지 않을 때만 그 기능을 표시해요. 경고는 Outlook에서 대체 수단 없이 깨질 때만 띄우고, 나머지는 모두 정보로 표시해요. 그러지 않으면 이메일마다 클라이언트 경고가 스무 개씩 붙고, 사람들은 결국 전부 무시하게 돼요.

## 5. 접근성

손쉽게 할 수 있는 점검:

- 스크린 리더가 올바르게 읽도록 `<html>`에 `lang` 속성 지정
- `<title>` 요소
- 순서에 맞는 헤딩 수준. `h1`에서 `h4`로 건너뛰지 않기
- 이미지가 전달하는 내용을 설명하는 대체 텍스트. “3월에 가입자가 두 배로 늘었음을 보여 주는 막대 그래프”는 도움이 되지만, “image1.png”는 도움이 안 돼요
- 본문, 버튼, 연회색 푸터 텍스트의 명도 대비. 대부분의 문제가 여기에 숨어 있어요

기준은 [WCAG 2.2](https://www.w3.org/TR/WCAG22/)예요. 이메일에서 생기는 문제는 대부분 대체 텍스트, 명도 대비, 페이지 언어, 헤딩에 관한 WCAG 기준에 해당해요.

## 6. 카피, 제목, 미리보기 텍스트

제목은 약 **60자**, **9단어** 미만으로 쓰세요. 그보다 길면 휴대폰에서 잘려요. 영문을 전부 대문자로 쓰거나, 답장이 아닌 메일에 “RE:”나 “FWD:”를 붙이거나, 느낌표를 연달아 쓰는 건 피하세요.

미리보기 텍스트는 제목을 반복하지 말고 약 **90자** 미만으로 쓰세요. 비워 두면 많은 클라이언트가 대신 ‘브라우저에서 보기’ 같은 문구를 보여 줘요.

대체값이 없는 개인화 태그는 이름이 없는 모든 수신자에게 “ 님, 안녕하세요”를 보내요. 독자는 이런 걸 기억해요.

모든 수치에는 가리킬 수 있는 출처가 있어야 해요. 확신에 찬 숫자를 쉽게 만들어 내는 AI 초안이라면 더욱 그래요. 문구는 [읽는 사람이 행동으로 옮길 수 있는 마케팅 이메일 작성법](/ko/blog/how-to-write-marketing-emails)과 [제목 가이드](/ko/blog/email-subject-lines)에서 더 자세히 다뤄요.

## 7. 규정 준수

[CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business)에 따라 상업용 이메일에는 제대로 작동하는 수신 거부 링크와 유효한 우편 주소가 있어야 해요. Gmail과 Yahoo에 대량으로 보내는 발신자는 원클릭 수신 거부 헤더도 갖춰야 해요. 자세한 내용은 [에이전트가 이메일을 보낼 때도 여전히 적용되는 원칙](/ko/blog/agent-email-deliverability)에서 다뤄요.

트랜잭션 메일은 일부 마케팅 규칙에서는 빠지지만, 이 체크리스트에서는 빠지지 않아요. 깨진 링크가 있는 영수증도 결국 고객 지원 문의로 돌아와요.

## 8. 마크업

이메일 클라이언트가 제거하거나 차단하는 요소는 빼세요:

- `<script>`, `<form>`, `<iframe>` 요소
- 삽입된 SVG와 `data:` URI
- `background-color` 대체 색상이 없는 배경 이미지. 이미지가 로드되지 않아도 텍스트를 읽을 수 있도록 대체 색상을 지정하세요

doctype으로 시작하세요. doctype이 없으면 일부 클라이언트가 쿼크 모드로 렌더링해 간격이 틀어져요.

## Brew에서 체크리스트 실행하기

Brew의 이메일 점검은 다음 위치에서 이 목록을 실행해요:

- 발송 창의 **점검** 탭(‘미리보기’, ‘오디언스’ 탭 옆)
- 자동화 캔버스의 이메일 단계에 있는 **점검** 버튼
- API와 MCP: `POST /v1/emails/audit` 엔드포인트 또는 `audit_email` 도구

모든 필드는 [점검 문서](https://docs.brew.new/create-emails/audit-email)와 [API 레퍼런스](https://docs.brew.new/api-reference/public-v1/emails/audit-an-email)에서 확인하세요.

무료 **즉시 점검**은 HTML만 있으면 되는 모든 규칙에 대해 자동으로 실행돼요. 자리 표시자, 용량, 누락된 대체 텍스트와 이미지 크기, 헤딩 순서, `lang`과 `<title>`, 제목과 미리보기 텍스트 길이, 대체값 없는 개인화 태그, 차단되는 마크업이 여기에 해당해요.

**점검 실행**은 네트워크 요청이나 판단이 필요한 점검을 더해요:

- 모든 링크에 실제 요청 보내기(이메일당 최대 100개, 수신 거부·수신 설정 링크는 제외). 봇 차단 페이지는 깨진 링크가 아니라 ‘확인되지 않음’으로 표시돼요
- 모든 이미지에 요청을 보내 깨졌거나 너무 큰 에셋 찾기
- Gmail, Apple Mail, Outlook, Yahoo의 4개 계열, 클라이언트 15개에서 지원 여부 확인(4번 항목의 규칙 적용)
- 명도 대비를 비롯한 접근성 규칙(WCAG 2.2 기준 표시)
- 제목이 오해를 부르지 않는지, 링크 텍스트와 대체 텍스트가 의미를 담고 있는지, 어느 나라 형식이든 우편 주소가 들어 있는지, 이메일이 마케팅용인지 트랜잭션용인지에 대한 AI 검토

각 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일 동안 무료로 다시 읽을 수 있어요.

### 점수가 높으면 받은편지함에 도착한다는 뜻인가요?

아니요. 점검은 이메일 자체만 확인해요. 받은편지함 도달은 도메인 평판, 인증, 스팸 신고율에도 달려 있으며, 이 내용은 [전달성 가이드](/ko/blog/email-deliverability)에서 다뤄요.

### 다른 도구로 만든 이메일도 점검할 수 있나요?

네, API나 MCP로 할 수 있어요. Brew 이메일 ID 대신 `emailHtml` 또는 `emailJsx` 값을 보내면, ESP에 넣기 전에 같은 리포트를 받을 수 있어요. [갤러리 템플릿을 리믹스해 ESP로 내보낸다면](/ko/blog/how-to-remix-a-real-brand-email-template-and-export-it-to-your-esp), 내보내기 전에 Brew에서 점검하세요.

### 팀에서 누가 점검을 실행할 수 있나요?

브랜드에 접근할 수 있는 사람이라면 누구나 실행할 수 있어요. 조직 관리자와 브랜드에 추가된 멤버가 여기에 해당해요. Brew에는 보기 전용 역할이 없어요.