# 이메일 A/B 테스트: 데이터로 답할 수 있는 질문 던지기

정식 URL: https://brew.new/ko/blog/email-ab-testing
글쓴이: Thomas Park
게시일: 2026-08-12
수정일: 2026-09-29

이메일 A/B 테스트는 비슷한 조건에서 두 버전을 비교해요. 테스트의 가치는 대시보드에 붙는 승자 배지가 아니라, 테스트 덕분에 내릴 수 있는 결정에 있어요.

어느 쪽 결과가 나오든 다음 이메일이 달라질 만큼 구체적인 질문에서 시작하세요. “스크린샷이 있으면 신규 사용자가 설정을 더 잘 마칠까?”는 쓸모 있는 질문이에요. “어느 이메일이 더 나을까?”는 정해지지 않은 부분이 너무 많아요.

## 결과 지표부터 정하기

발송 목적에 가까운 지표를 쓰세요. 목표가 활성화라면 오픈보다 제품에서 완료한 작업이 더 유용해요. 뉴스레터라면 관련 있는 클릭이나 답장으로 충분할 수도 있어요. 스팸 신고와 수신 거부는 주요 지표가 아니더라도 비용으로 추적하세요.

분모를 정하세요. 전달된 이메일당 클릭과 오픈한 사람당 클릭은 서로 다른 질문에 답해요. 오픈 기반 지표는 개인정보 보호 기능의 영향도 받아요. 예를 들어 Apple의 [Mail Privacy Protection](https://support.apple.com/en-us/102580)은 이메일의 원격 콘텐츠를 백그라운드에서 불러올 수 있어서, 아무도 읽지 않은 메시지에도 오픈이 기록될 수 있어요. 테스트를 시작하기 전에 정확한 계산식을 적어 두세요.

추적 데이터가 어디서 오해를 부를 수 있는지는 [이메일 지표 가이드](/ko/blog/email-metrics-that-matter)에서 설명해요.

## 우선순위로 본 테스트 항목

어디서 시작할지 모르겠다면 이 목록을 위에서부터 차례로 내려가며 테스트하세요. 위쪽 요소는 독자가 애초에 이 메시지를 원하는지를 좌우해요. 아무도 원하지 않는 제안은 버튼을 아무리 다듬어도 살릴 수 없어요.

| 요소 | 결과가 명확할 때 알 수 있는 것 |
| --- | --- |
| 오디언스 또는 제안 | 이 집단이 내가 요청하는 행동을 원하는지 알 수 있어요. 나머지 요소가 모두 여기에 달려 있으니 가장 먼저 테스트하세요. |
| 제목 | 어떤 표현 방식이 적합한 독자를 열어 보고 행동하게 만드는지 알 수 있어요. 오픈뿐 아니라 클릭이나 그 뒤에 이어지는 행동으로도 판단하세요. |
| 발신자 이름 | 독자가 보내는 사람 이름을 알아보고 신뢰하는지 알 수 있어요. 예를 들어 회사 이름과 실제 사람 이름을 비교할 수 있어요. |
| 미리보기 텍스트 | 제목 뒤에 보이는 한 줄이 열어 볼 이유를 주는지 알 수 있어요. 일부 이메일 클라이언트는 이 텍스트를 줄이거나 숨기므로, 효과는 독자가 어떤 클라이언트를 쓰는지에 따라 달라져요. |
| CTA 문구와 위치 | 클릭하면 무슨 일이 일어나는지 독자가 이해하는지, 링크를 애써 찾지 않고도 발견하는지 알 수 있어요. |
| 레이아웃 | 구조가 독자를 행동까지 이끄는지 알 수 있어요. 레이아웃을 바꾸면 여러 요소가 한꺼번에 바뀌므로, 결과도 하나의 묶음으로 해석하세요. |
| 발송 시간 | 이 오디언스가 이런 종류의 메시지에 주로 언제 반응하는지 알 수 있어요. 하루는 특이할 수 있으니 두 번 이상의 발송에 걸쳐 비교하세요. |

발송 시간은 처음부터 버전마다 발송 시점이 달라지도록 설계하는 유일한 테스트예요. 오디언스를 나누는 방식을 포함해 나머지는 모두 똑같이 유지하고, 두 그룹을 같은 길이의 기간 동안 측정하세요.

## 테스트마다 가설 세우기

가설에는 바꿀 요소, 오디언스, 지표, 그리고 차이가 날 거라고 예상하는 이유가 들어가요. 배움은 그 이유에서 나와요. 결과가 반대로 나오면 어떤 가정을 의심해야 할지 알 수 있어요.

```text
If we [change] for [audience], [metric] will [rise or fall] because [reason].
```

몇 가지 예를 들어 볼게요.

- 신규 체험 사용자에게 보내는 온보딩 이메일에 설정을 마친 화면의 스크린샷을 넣으면, 무엇을 목표로 작업하는지 볼 수 있으므로 7일 안에 설정을 완료하는 건수가 늘어날 것이다.
- 뉴스레터를 회사 이름 대신 편집자 이름으로 보내면, 독자가 글을 쓰는 사람을 알아보므로 답장이 늘어날 것이다.
- 릴리스 이메일 제목에 “제품 업데이트” 대신 새 기능의 이름을 쓰면, 독자가 자신과 관련이 있는지 판단할 수 있으므로 기능 페이지로 가는 클릭이 늘어날 것이다.
- 웨비나 초대 이메일의 미리보기 텍스트에 등록 마감일을 넣으면, 받은편지함에서 날짜가 보이므로 마감 전 등록이 늘어날 것이다.
- 메인 링크를 첫 번째 이미지 위로 옮기면, 스크롤하지 않아도 링크에 닿을 수 있으므로 휴대폰으로 읽는 사람들의 클릭이 늘어날 것이다.
- 진행이 멈춘 체험 계정에 할인 대신 설정 지원 통화를 제안하면, 이 계정들은 설정 단계에서 멈췄으므로 유료 전환이 늘어날 것이다.

이 가설은 모두 틀릴 수 있고, 틀린 결과에서도 독자에 대해 배울 점이 있어요. 반면 “새 템플릿 써 보기” 같은 막연한 테스트는 어느 버전이 이기든 배울 게 거의 없어요.

## 의미 있는 차이의 기준 정하기

작은 변화는 실제로 있더라도 추가 제작 작업을 정당화하기엔 너무 작을 수 있어요. 결정을 바꿀 만한 최소 효과 크기를 정하고, 기준선이 되는 비율을 추정한 다음, 신뢰 수준과 통계적 검정력을 명시해 표본 크기를 계산하세요.

수신자 1,000명 같은 보편적인 최소 기준은 없어요. 흔한 행동과 드문 구매는 필요한 표본이 달라요. 아주 작은 개선 효과를 찾는 테스트에는 큰 변화를 찾는 테스트보다 더 많은 데이터가 필요해요.

리스트가 작다면 캠페인 하나를 아주 작은 그룹 여러 개로 쪼개기보다, 비슷한 조건의 여러 발송에 걸쳐 큰 변화를 테스트하거나 정성적인 피드백을 모으는 편이 나을 수 있어요. 캠페인을 반복하면 발송 시점의 차이가 생기니, 결과를 해석할 때 이 한계를 함께 밝히세요.

## 해석할 수 있는 비교 유지하기

대상 수신자를 무작위로 각 버전에 배정하세요. 오디언스 규칙, 발송 시간대, 그 밖의 중요한 콘텐츠는 비교할 수 있게 비슷하게 유지하세요. 제목, 레이아웃, 제안, 랜딩 페이지를 한꺼번에 바꾸면 전체 묶음을 테스트하는 셈이라, 어느 부분이 차이를 만들었는지 말할 수 없어요.

같은 사람에게 반복해서 보낸 발송을 독립된 관측값으로 세지 마세요. 계정 단위 성과라면 같은 계정에 속한 사람들이 서로 영향을 줄 수 있는지 고려하세요.

목표 행동이 일어날 수 있을 만큼 관찰 기간을 충분히 잡으세요. 사용하는 통계 방법이 명시적으로 지원하지 않는 한, 결과를 수시로 들여다보다가 처음 유리하게 흔들린 시점에 테스트를 멈추지 마세요.

## 헤드라인 숫자가 아니라 불확실성 읽기

한 버전에서 구매가 24건, 다른 버전에서 27건 나왔다고 해 볼게요. 이 숫자만으로는 승자를 정할 수 없어요. 그룹 크기, 배정 방법, 추정한 차이의 신뢰 구간이 필요해요.

결론이 나지 않았다면 그렇다고 밝히세요. 더 단순한 버전을 유지하거나, 배운 점을 바탕으로 더 탄탄한 다음 테스트를 설계하세요. 큰 개선 가능성을 배제해 준 테스트도 시간을 아껴 줄 수 있어요.

가설, 버전, 오디언스, 표본, 날짜, 지표, 결과, 다음 결정을 기록하고, 이 기록을 캠페인에 연결해 두세요. [제목](/ko/blog/email-subject-lines)을 검토할 때는 테스트 한 번의 결과를 모든 오디언스에 적용되는 영구 규칙으로 만들고 싶은 유혹을 참으세요.