Skip to content
Published on

2026 이메일 인프라 — Resend·Postmark·Loops·SES·SendGrid·Mailgun 심층 비교

Authors

프롤로그 — 이메일은 죽지 않았고, 어렵기만 졌다

2026년에도 이메일은 모든 SaaS의 1번 채널이다. 비밀번호 재설정 링크, 결제 영수증, 회의 초대장, 온보딩 시퀀스, 휴면 사용자 재참여 — 푸시·SMS·인앱이 아무리 늘어도 이 다섯 가지는 이메일이 한다. 문제는 보내는 게 아니다. 받은 편지함에 도착시키는 것 이다.

2024년 2월 Google과 Yahoo는 발신자 인증 요건을 강화했다. 하루 5,000통 이상 보내는 모든 도메인은 SPF·DKIM·DMARC 세 가지를 다 통과해야 하고, 마케팅 메일은 1-click unsubscribe(List-Unsubscribe-Post 헤더)를 반드시 넣어야 하며, 스팸 신고율(complaint rate)이 0.30%를 넘으면 도메인 전체가 격리(quarantine) 또는 거부된다. Microsoft 365도 2025년 같은 기준을 따라잡았고, 2026년 현재는 작은 ISP들도 거의 비슷한 정책을 쓴다. 즉 DKIM 없이 메일을 보내는 시대는 끝났다.

이런 배경 위에서 이메일 인프라 시장은 두 갈래로 갈렸다.

  1. 트랜잭셔널(Transactional) 우선 — Resend, Postmark, AWS SES. 1통씩 트리거되는 영수증·알림이 핵심.
  2. 이메일이 곧 제품(Email as a product) — Loops, Customer.io, Brevo. 시퀀스·세그먼트·자동화가 1급 시민.

이 둘은 자주 겹친다. 어떤 SaaS도 결국 둘 다 필요하다. 이 글은 그 선택을 다룬다. 어떤 단계에서 어떤 도구를 쓰는 게 맞는지, 10,000명 구독자에 한 달 얼마가 드는지, 한국 ISP까지 어떻게 만족시키는지 — 2026년 5월 기준 실제 상태로 정리한다.


1장 · 이메일 인프라의 책임 분기선

1.1 ESP가 해주는 것, 안 해주는 것

ESP(Email Service Provider)는 SMTP 서버 한 줄로 끝나는 게 아니다. 모든 ESP는 다음을 한다.

  • SMTP/REST API를 노출해 메일 발송을 받아준다.
  • 공유 또는 전용 IP에서 메일을 송신한다.
  • SPF·DKIM·DMARC 정렬 을 도와준다(자기 도메인을 발신자로 정렬하는 설정).
  • 반송(Bounce)·불평(Complaint)·열림(Open)·클릭(Click) 이벤트를 웹훅이나 대시보드로 돌려준다.
  • 억제 목록(Suppression list) 을 관리해 같은 사용자에게 반복 발송을 막는다.

ESP가 안 해주는 것:

  • 당신의 도메인 자체 평판(domain reputation)을 만들어주지 않는다. 이건 누적된 송신 이력에서 자라난다.
  • 메일 내용의 품질을 보장하지 않는다. 스팸 키워드·HTML 비율·이미지 크기는 발신자 책임이다.
  • 사용자 동의(consent)·CAN-SPAM·GDPR 준수를 대신 하지 않는다.

핵심은 이거다. ESP는 도구를 빌려주지, 결과를 보장하지 않는다. 한 번의 잘못된 캠페인(예: 콜드 메일링 리스트 구매)으로 도메인 평판이 무너지면 어떤 ESP에 옮겨도 똑같이 스팸함으로 간다.

1.2 SPF·DKIM·DMARC — 2026년 최소 요건

세 가지를 한 줄로 풀면.

  • SPF (Sender Policy Framework): 도메인의 TXT 레코드에 "이 도메인을 발신자로 쓸 수 있는 IP/호스트는 다음입니다"라고 선언. ESP의 SMTP 서버를 include:로 추가한다.
  • DKIM (DomainKeys Identified Mail): 보내는 메일 본문에 도메인 개인키로 서명을 박는다. 수신자는 도메인 DNS의 공개키로 검증한다.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): SPF·DKIM이 통과 못 한 메일을 어떻게 처리할지 정책(quarantine/reject)을 도메인 소유자가 직접 명시.

2024년 Google·Yahoo 가이드라인 이후 사실상 세 가지가 다 통과해야 받은 편지함에 들어간다. Resend·Postmark·SES 모두 도메인 인증 화면이 비슷해진 이유다. DNS에 TXT 3 ~ 4개를 박아 넣고 1시간을 기다리면 끝.

; example.com SPF
example.com.    IN  TXT  "v=spf1 include:_spf.resend.com -all"

; resend._domainkey.example.com DKIM
resend._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

; _dmarc.example.com DMARC
_dmarc.example.com. IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

DMARC 정책은 처음엔 p=none 으로 시작해 리포트만 받고, 1 ~ 2주 모니터링 후 p=quarantine, 마지막에 p=reject로 단계적으로 올린다. 단번에 reject로 가면 잘못된 SPF 한 줄로 정상 메일이 다 거부된다.

1.3 IP 평판 vs 도메인 평판

2010년대까지는 IP 평판이 거의 모든 것이었다. 그래서 전용 IP가 비싸도 사용자가 샀다. 2026년에는 도메인 평판 이 지배한다. Gmail·Outlook이 학습 모델로 도메인+발신자 페어를 따로 점수화한다.

이건 두 가지 의미다.

  • 전용 IP의 가치가 떨어졌다. 월 5,000 ~ 50,000통 발송이면 공유 IP로도 충분하다. 그 이상이거나 매우 시간에 민감한 트랜잭션(2FA 코드) 비중이 크면 전용 IP를 고려한다.
  • 도메인을 갈아 끼우면 평판이 0에서 시작한다. acme.com 에서 acme.io 로 옮기면 새로 길러야 한다. 보통 mail.example.com 같은 서브도메인을 따로 두고 평판을 분리한다.

2장 · Resend — 개발자 우선 ESP의 새 표준

2.1 포지셔닝

Resend는 2023년 출범했고, 2024 ~ 2025년 사이 인디 해커·Next.js 진영에서 빠르게 자리잡았다. React Email 라이브러리와 묶여 "JSX로 이메일 짠다"가 핵심 마케팅이다. Vercel·Stripe 출신 팀이 만들었고, 시리즈 B(2024)까지 끝났다.

가격(2026년 5월 기준):

  • Free: 월 3,000통, 하루 100통.
  • Pro: 월 $20에 50,000통, 하루 10,000통.
  • Scale: 월 $90에 100,000통, 추가는 1,000통당 약 $0.90.
  • Enterprise: 협상.
// Resend — 최소 트랜잭셔널 발송
import { Resend } from 'resend'

const resend = new Resend(process.env.RESEND_API_KEY)

await resend.emails.send({
  from: 'Acme <hello@mail.acme.com>',
  to: ['user@example.com'],
  subject: '환영합니다',
  html: '<strong>가입해주셔서 감사합니다.</strong>',
})

2.2 강점

  • React Email 통합이 1급이다. JSX로 이메일 컴포넌트를 짜고 그대로 from React Email 임포트해 본문에 넣는다.
  • 개발자 경험이 압도적이다. 도메인 인증 화면, 로그, 웹훅, 배치 발송 — 모두 깔끔하다.
  • Batching API 로 한 번에 100개까지 묶어 보낸다.
  • Webhook 이벤트email.sent, email.delivered, email.bounced, email.complained, email.opened, email.clicked.
  • Audiences·Broadcasts(2024 ~ ) — 가벼운 마케팅 캠페인 기능이 들어왔다. Loops 영역을 일부 가져옴.

2.3 약점

  • 본격 마케팅 자동화는 약하다. 시퀀스·분기·세그먼트는 Loops·Customer.io에 비해 단순.
  • 고가 발송 단계(월 1M통 이상)에서는 SES + 자체 인프라가 더 저렴.
  • deliverability 자료를 자주 공개하지만, 본격 전용 IP·warmup은 여전히 Postmark가 한 수 위라는 평이 있다.

2.4 언제 쓰나

  • Next.js·React 기반 SaaS의 트랜잭셔널 메일.
  • 인디 해커·1인 개발자.
  • "이메일 디자인을 코드로 관리하고 싶다"가 1순위인 팀.

3장 · Postmark (ActiveCampaign) — 도착률 왕

3.1 포지셔닝

Postmark는 2010년 Wildbit이 만든 ESP다. 2022년 ActiveCampaign에 인수됐다. 트랜잭셔널 도착률(deliverability) 이 기본 신조다. 평균 도착 시간을 공개하고("median 9.8s") 분석 도구도 도착률 중심이다. 마케팅 메일은 같은 인프라에서 안 보내준다 — 이걸 거꾸로 강점으로 판다.

가격(2026년 5월 기준):

  • Free trial: 100통.
  • Starter: 월 $15에 10,000통.
  • Premium: 월 $115에 100,000통. 그 위는 단계별 패키지.
  • Marketing(Streams): 별도 — Postmark는 트랜잭션과 마케팅 메시지 스트림을 강제로 분리한다.
// Postmark — Server Token 한 줄
import { ServerClient } from 'postmark'

const client = new ServerClient(process.env.POSTMARK_TOKEN!)

await client.sendEmail({
  From: 'hello@mail.acme.com',
  To: 'user@example.com',
  Subject: '비밀번호 재설정',
  HtmlBody: '<a href="https://acme.com/reset?token=xxx">재설정</a>',
  MessageStream: 'outbound', // 'broadcast' 와 구분 필수
})

3.2 강점

  • 트랜잭션 도착률이 업계 최고 수준이다. 평균 9 ~ 12초에 인박스 도착이라는 게 보장형 마케팅이다.
  • Message Streams가 강제 — 트랜잭션과 브로드캐스트를 같은 도메인에서 보내도 IP·평판이 분리된다.
  • 분석 도구가 도착률 중심. Spam complaints, bounce reasons, open/click 등 모든 데이터가 빨리 보인다.
  • DMARC Digests 무료 — 도메인 DMARC 리포트 분석을 GUI로 본다.

3.3 약점

  • 가격이 비싸다. 100k통에 $115는 SES의 $10과 비교가 안 된다.
  • 마케팅 자동화 약함. 트랜잭션에 집중. 시퀀스·세그먼트는 ActiveCampaign 본체로 가야 한다.
  • 글로벌 IP 풀이 한정적. 일본·한국 ISP 대상에는 평판 warm-up이 더 오래 걸린다는 평이 있다.

3.4 언제 쓰나

  • 금융·헬스·B2B SaaS — 1회 발송이 늦거나 누락되면 클레임이 들어오는 경우.
  • 매출이 도착률에 직결되는 도메인 (인증 코드, 결제 영수증, 법적 통지).
  • "마케팅 메일은 아예 다른 도구로 보낼 거라" 결심한 팀.

4장 · Loops — 이메일이 곧 제품

4.1 포지셔닝

Loops는 2022년 출범, 2024년 시리즈 A. "인디 SaaS의 마케팅+트랜잭션 통합 ESP" 라는 좁고 강한 포지션을 잡았다. 오디언스 관리, 시퀀스(루프), 트랜잭셔널 한 화면. UI가 SaaS 답게 깔끔하고, Slack·Notion·Linear 같은 인디 진영 도구의 고객 메일에 자주 쓰인다.

가격(2026년 5월 기준):

  • Free: 1,000 콘택트·2,000통/월.
  • Pro: 월 $49부터 — 5,000 콘택트·25,000통.
  • Business: 월 $249부터 — 25,000 콘택트·100,000통.
  • 추가 콘택트·발송량은 단계별로 가격이 늘어남.
// Loops — 트랜잭셔널 이벤트 트리거
import { LoopsClient } from 'loops'

const loops = new LoopsClient(process.env.LOOPS_API_KEY!)

await loops.sendTransactionalEmail({
  transactionalId: 'cltt6abcd1234', // Loops 대시보드에서 만든 ID
  email: 'user@example.com',
  dataVariables: {
    firstName: '영주',
    resetUrl: 'https://acme.com/reset?token=xxx',
  },
})

4.2 강점

  • 트랜잭션 + 마케팅을 한 도구에서 본다. 콘택트 1명에 트랜잭션 이벤트와 캠페인 발송이 같은 타임라인에 쌓인다.
  • Loops Loops(루프) — 분기·지연·조건이 들어간 시퀀스 빌더. 단순한 케이스에 충분히 강력하다.
  • 이벤트 기반userSignedUp, subscriptionPaid 같은 이벤트로 자동 시퀀스 시작.
  • 인디 진영 친화 — Stripe·Posthog·Segment 연동이 매끄럽다.

4.3 약점

  • 본격 마케팅 도구로 보면 단순. 다단계 분기, A/B 테스트, 사용자 점수화 같은 건 Customer.io·HubSpot에 비해 약하다.
  • 고가 발송에는 비효율. 100k 콘택트 단계가 되면 가격이 빠르게 올라간다.
  • 도메인 인증·도착률 통계는 Postmark·Resend 대비 정보가 적다.

4.4 언제 쓰나

  • $1k ~ $50k MRR 인디 SaaS — 마케팅 자동화 도구를 따로 두기엔 작고, 그렇다고 트랜잭션만 보내기엔 캠페인이 필요한 단계.
  • "마케팅 사람을 두지 않은 솔로 창업자가 한 화면에서 모든 메일을 관리한다."

5장 · AWS SES — 가장 저렴, 그러나 모든 책임은 당신 것

5.1 포지셔닝

SES(Simple Email Service)는 2011년 출시된 AWS의 이메일 서비스다. 가격은 사실상 업계 최저. 그러나 도착률·warmup·UI·자동화 기능은 사용자가 다 만들어야 한다. "DIY 이메일의 기반"이다.

가격(2026년 5월 기준):

  • 발송: 1,000통당 $0.10 (EC2에서 보내든 외부에서 보내든 동일).
  • 수신: 1,000통당 $0.10 + 청크당 $0.09.
  • 전용 IP: 월 $24.95/IP.
  • VDM(Virtual Deliverability Manager): 발송량 비례 추가 비용.
// AWS SES v2 — Node SDK
import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2'

const ses = new SESv2Client({ region: 'us-east-1' })

await ses.send(new SendEmailCommand({
  FromEmailAddress: 'hello@mail.acme.com',
  Destination: { ToAddresses: ['user@example.com'] },
  Content: {
    Simple: {
      Subject: { Data: '환영합니다' },
      Body: { Html: { Data: '<strong>가입 완료</strong>' } },
    },
  },
}))

5.2 강점

  • 가격이 압도적으로 저렴. 100,000통이 $10. Postmark 동량의 약 1/10.
  • AWS 인프라 안에서 동작 — EventBridge, SNS, Lambda 등과 자연스럽게 묶인다.
  • 샌드박스 해제 후 무제한 — 발송량 상한이 사실상 없다(API quota는 따로).
  • VDM — 2023년 도입된 도달률 관리 대시보드. 평판 모니터링·발송 권장 등.

5.3 약점

  • 샌드박스 모드가 기본. 풀려면 AWS Support 티켓을 열고 사용 사례 설명 — 보통 24 ~ 72시간.
  • UI가 빈약. 템플릿 에디터, 시퀀스, 세그먼트 같은 건 없다.
  • 도착률은 사용자 몫. SPF·DKIM·DMARC, warmup, 콘텐츠 품질 — 다 직접.
  • 불평·반송 처리 도 직접 — SNS로 받아 자체 억제 목록 운영.

5.4 언제 쓰나

  • 월 1M통 이상 발송 — 가격 격차가 명확히 의미 있어진다.
  • AWS 본진을 이미 쓰는 팀.
  • 사내 메일 인프라 팀이 있고 도착률·warmup을 직접 운영할 수 있을 때.

6장 · SendGrid (Twilio) — 엔터프라이즈 기본값

6.1 포지셔닝

SendGrid는 2009년 출범, 2019년 Twilio에 인수됐다. 트랜잭셔널 + 마케팅의 거인 이다. 큰 기업의 첫 선택지로 자주 들어가고, API·연동·SDK가 압도적으로 넓다. 다만 UI·UX가 옛 시대의 흔적을 많이 남기고 있고, 가격은 협상 영역이 크다.

가격(2026년 5월 기준):

  • Free: 100통/일 (총량 제한 있음).
  • Essentials: 월 $19.95부터 — 50,000통/월.
  • Pro: 월 $89.95부터 — 100,000통/월·전용 IP 옵션.
  • Premier: 협상 — 수백만 통 이상.
// SendGrid — v3 API
import sgMail from '@sendgrid/mail'

sgMail.setApiKey(process.env.SENDGRID_API_KEY!)

await sgMail.send({
  to: 'user@example.com',
  from: 'hello@mail.acme.com',
  subject: '결제 영수증',
  html: '<p>감사합니다.</p>',
})

6.2 강점

  • 모든 곳에서 작동한다. SDK가 30개 이상 언어. 레거시 시스템·엔터프라이즈 SI에 들어가는 비율이 가장 높다.
  • Twilio 통합 — SMS·WhatsApp·Voice를 한 계정에서 관리.
  • 마케팅 캠페인 도구 — 시퀀스·세그먼트·A/B 테스트가 깊다.
  • 전용 IP·warmup 자동화 — Pro 이상에서 IP 풀 관리가 강력.

6.3 약점

  • UI 노후. 메뉴 구조가 13년 된 흔적이 곳곳에 남아 있다.
  • 공유 IP 평판 변동성이 크다. 큰 가격대 위주로 관리되고, 작은 사용자는 영향을 받기 쉽다.
  • 고객 지원이 가격대별로 갈린다. Pro 이하는 응답이 느리다.

6.4 언제 쓰나

  • 큰 회사·레거시 시스템 — SAP·Oracle 같은 본진에 메일을 꽂아야 할 때.
  • Twilio SMS/Voice를 이미 쓰는 경우 — 청구·관리 통합.
  • 마케팅+트랜잭션이 같은 도구에서 굴러가야 하는 글로벌 팀.

7장 · Mailgun (Sinch) — 옛 개발자 친화, 2026년 위치

7.1 포지셔닝

Mailgun은 2010년 출범, 2017년 Rackspace 인수, 2021년 Sinch가 모회사를 인수. 2010년대 초 개발자 친화 ESP의 원조다. API가 깔끔하고 EU 데이터 거주(EU region) 옵션이 일찍부터 있었다.

가격(2026년 5월 기준):

  • Foundation: 월 $15에 10,000통/월.
  • Growth: 월 $35에 50,000통.
  • Scale: 월 $90에 100,000통.
  • Enterprise: 협상.
// Mailgun — REST API
import formData from 'form-data'
import Mailgun from 'mailgun.js'

const mg = new Mailgun(formData).client({
  username: 'api',
  key: process.env.MAILGUN_API_KEY!,
})

await mg.messages.create('mail.acme.com', {
  from: 'hello@mail.acme.com',
  to: ['user@example.com'],
  subject: '환영합니다',
  html: '<p>안녕하세요</p>',
})

7.2 강점

  • EU regionapi.eu.mailgun.net — 데이터가 EU 안에서 처리된다. GDPR·법 요건이 강한 EU 고객에 의미 있다.
  • 이벤트 로그 7일 보존이 기본, 30일 보존이 옵션. 디버깅에 강하다.
  • 검증 API(Email Validation) — 발송 전 주소 유효성 검사를 직접 호출.

7.3 약점

  • 2020년대 들어 정체된 인상. 신생 ESP에 비해 UI·DX가 뒤떨어진다.
  • 공유 IP 평판 이 변동적이라는 평이 잦다.
  • 가격이 중간 — Resend·SendGrid보다 크게 싸지도, Postmark만큼 도착률 보장도 아니다.

7.4 언제 쓰나

  • EU 데이터 거주가 법적으로 요구되는 경우.
  • 이미 Mailgun에 고객 데이터가 누적된 레거시 운영.
  • 신규 도입이라면 Resend·Postmark·SES 셋 중 하나가 먼저다.

8장 · 그 외 — Brevo·Mailtrap·Customer.io·Plunk

8.1 Brevo (구 Sendinblue)

프랑스 파리 기반. 마케팅+트랜잭션+SMS+CRM을 묶은 올인원. 유럽 인디 진영에서 인기. 가격이 합리적이고 무료 티어가 관대(300통/일). 단, 마케팅에 무게 중심이 있어 순수 트랜잭션 도착률은 Postmark·Resend 대비 미세하게 낮다는 평.

8.2 Mailtrap — 개발 환경 테스트

스테이징·로컬에서 이메일 발송을 흉내내는 도구. 실제 발송 없이 SMTP를 받아 가짜 인박스에 저장 → 개발자가 본문·헤더·HTML을 확인. CI에서 회귀 테스트로 자주 쓰인다. 2024 ~ 2025년 사이 실제 발송(Mailtrap Email Sending)도 출시했지만 메인 사용처는 여전히 테스트 환경이다.

// Mailtrap — Nodemailer SMTP 테스트 인박스
import nodemailer from 'nodemailer'

const transporter = nodemailer.createTransport({
  host: 'sandbox.smtp.mailtrap.io',
  port: 2525,
  auth: { user: process.env.MAILTRAP_USER, pass: process.env.MAILTRAP_PASS },
})

await transporter.sendMail({
  from: 'hello@mail.acme.com',
  to: 'qa@example.com',
  subject: 'staging 환경 테스트',
  html: '<p>Hello, Mailtrap</p>',
})

8.3 Customer.io — 본격 마케팅 자동화

이벤트 기반 마케팅 자동화의 강자. 시퀀스 빌더가 매우 깊다(if/else, A/B, 분기 후 합류, 시간대 발송). 가격이 빠르게 올라간다 — 보통 매출 $50k MRR 이상에서 도입한다. Liquid 템플릿·webhook·in-app 메시지까지 지원한다.

8.4 Plunk — 오픈소스 셀프호스트

plunk.com. 2024년 출범한 오픈소스 ESP. 자체 SES 위에서 돌아가는 호스티드 버전도 있고, GitHub 저장소를 받아 self-host도 가능하다. 인디 진영의 "셀프호스트 선택지". 도착률은 결국 뒤에 둘러싼 SES에 의존한다. 가격 민감·데이터 주권 요구에 강하다.


9장 · 10,000 구독자 비용 매트릭스

가정: 월 10,000 콘택트, 월 발송 100,000통(콘택트당 평균 10통/월), 트랜잭션 50% + 마케팅 50%.

서비스월 비용트랜잭션마케팅 자동화도착률 평판메모
AWS SES$10강함없음사용자 책임DIY, 인프라 자체 운영
Resend Pro/Scale$90강함중간좋음React Email 통합
Postmark Premium$115최강별도 분리최강트랜잭션 전용
Mailgun Scale$90강함약함중간EU 데이터 거주
SendGrid Pro$89.95강함강함가변적Twilio 통합
Loops Business$249강함강함좋음인디 SaaS 통합
Brevo Business$65 ~중간강함좋음마케팅 무게
Customer.io Premium$200 ~강함최강좋음별도 트랜잭션 ESP 권장
Plunk + SES$10 ~ $30SES 의존단순SES 의존셀프호스트 옵션

이 표는 두 가지 결론을 던진다.

  1. 순수 가격만 본다면 SES가 압도적이다. 운영 인력 비용을 더하면 100k통 수준에서는 별 차이 없을 수 있지만, 1M통 단계에서는 격차가 명확해진다.
  2. 마케팅 자동화가 필요하면 Loops·Customer.io 가 같은 가격대에서 가장 깊다. Resend가 Broadcasts로 들어왔지만 시퀀스 분기 깊이는 아직 따라가지 못한다.

9.1 100,000 구독자 단계에서의 재계산

가정: 월 100,000 콘택트, 월 발송 1M통.

서비스월 비용 (추정)운영 인력총 비용(인력 포함)
AWS SES$100약 0.3 FTE인력비 + $100
Resend$900 ~ $1,5000$900 ~ $1,500
Postmark$1,200 ~0$1,200 ~
SendGrid Pro/Premier$500 ~ $2,000(협상)0 ~ 0.2 FTE협상
Customer.io$2,000 ~ $5,0000$2,000 ~ $5,000
SES + 자체 도구$100 + 인력비1 FTE본격 운영

1M통 단계에서는 SES + 자체 인프라가 의미 있어지지만, 그 인프라를 짤 시간이 솔로/소규모 팀에 있는지는 따로 본다.


10장 · React Email·MJML·Maizzle — HTML 이메일의 현실

10.1 이메일 HTML이 끔찍한 이유

이메일 클라이언트는 1999년에 멈춘 HTML 렌더링 엔진을 굴린다. Outlook은 여전히 Word 엔진(2007 ~ )을 쓴다. Gmail은 <style> 태그 일부만 받고 일부 미디어 쿼리는 무시한다. iOS Mail은 CSS Grid를 모른다. 현대 CSS는 거의 다 안 된다.

해법은 두 갈래다.

  • 테이블 기반 레이아웃 — 2003년스러운 <table><tr><td> 중첩.
  • 인라인 스타일<style> 태그가 사라져도 살아남게.

이걸 손으로 짜는 건 형벌이다. 그래서 도구가 생겼다.

10.2 React Email

// React Email — 컴포넌트 한 줄로 이메일
import { Body, Button, Container, Head, Html, Text } from '@react-email/components'

export function WelcomeEmail({ name }: { name: string }) {
  return (
    <Html>
      <Head />
      <Body style={{ fontFamily: 'sans-serif' }}>
        <Container>
          <Text>안녕하세요 {name}님,</Text>
          <Button href="https://acme.com/welcome">시작하기</Button>
        </Container>
      </Body>
    </Html>
  )
}

빌드 단계에서 인라인 스타일이 박힌 HTML로 변환된다. Resend가 같은 팀에서 나왔기 때문에 통합이 1급. Postmark·SES에도 그대로 보내진다.

10.3 MJML

Mailjet이 만든 마크업 언어. 자체 태그(mj-section, mj-column)를 쓰고, 빌드 시 표준 테이블 기반 HTML로 컴파일된다. 2015년대 표준으로 자리잡았고, 지금도 PHP·Ruby 진영에서 자주 쓰인다.

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>환영합니다.</mj-text>
        <mj-button href="https://acme.com/welcome">시작</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

10.4 Maizzle

Tailwind 기반 이메일 프레임워크. 일반 HTML + Tailwind 클래스로 짜고, 빌드 시 PostCSS로 인라인 스타일로 변환한다. 디자이너에게 가장 자연스러운 선택. React Email과 달리 SSR/JSX가 아니라 정적 빌드. CMS 운영 캠페인에 자주 들어간다.

10.5 어떤 걸 쓰나

  • Next.js·React 본진: React Email. 컴포넌트 재사용, TypeScript 자동완성.
  • 다국어 캠페인·디자이너 협업: Maizzle. Tailwind 친화.
  • PHP·Ruby 레거시: MJML.

세 도구 다 결과물은 같은 인라인 테이블 HTML이다. 도구 선택은 팀 스택에 맞춘다.


11장 · 웹훅·반송·불평 — 들어오는 이벤트의 기술

11.1 모든 ESP는 같은 이벤트를 보낸다

이름은 조금씩 달라도 핵심 이벤트는 동일하다.

  • delivered — SMTP 250 응답.
  • bounce.hard — 영구 실패(존재하지 않는 주소). 즉시 억제 목록 등록.
  • bounce.soft — 일시 실패(우편함 가득 참 등). 재시도 후 보통 7일 내 hard로 승격.
  • complaint / spam_report — 사용자가 "스팸 신고"를 누름. 즉시 모든 마케팅 발송 중단.
  • opened — 픽셀 트래커가 로드됨(부정확). Apple Mail Privacy Protection으로 2022년부터 거의 신뢰 못 함.
  • clicked — 링크 클릭(rewriting 으로 ESP가 추적).

11.2 멱등한 웹훅 핸들러

// Next.js Route Handler — Resend webhook 멱등 처리
import { headers } from 'next/headers'
import { db } from '@/lib/db'
import { Webhook } from 'svix' // Resend는 svix 시그니처를 쓴다

export async function POST(req: Request) {
  const body = await req.text()
  const h = await headers()

  const wh = new Webhook(process.env.RESEND_WEBHOOK_SECRET!)
  let event
  try {
    event = wh.verify(body, {
      'svix-id': h.get('svix-id')!,
      'svix-timestamp': h.get('svix-timestamp')!,
      'svix-signature': h.get('svix-signature')!,
    }) as any
  } catch {
    return new Response('Bad signature', { status: 400 })
  }

  // 멱등 처리: 이벤트 ID를 PK로 저장
  const stored = await db.emailEvent.create({
    data: { id: event.data.email_id + ':' + event.type, payload: body },
  }).catch(() => null)

  if (!stored) return new Response('Already processed', { status: 200 })

  switch (event.type) {
    case 'email.bounced':
      await suppressUser(event.data.to[0], 'hard_bounce')
      break
    case 'email.complained':
      await suppressUser(event.data.to[0], 'complaint')
      break
  }

  return new Response('ok', { status: 200 })
}

핵심: 반송·불평은 즉시 억제 목록에 넣는다. 한 번 더 보내는 게 곧 도메인 평판 손상이다.

11.3 1-click unsubscribe (RFC 8058)

2024년 Google·Yahoo 가이드라인 이후 모든 마케팅 메일은 다음 헤더가 필수다.

List-Unsubscribe: <https://acme.com/unsub?t=xxx>, <mailto:unsub@mail.acme.com?subject=unsub>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

수신자가 메일 클라이언트의 "구독 취소" 버튼을 누르면 ESP가 그 URL에 POST 한다. 사용자는 페이지를 열지 않고도 한 번에 빠진다. Resend·Postmark·SendGrid·SES 모두 발송 시 자동으로 헤더를 박는 옵션을 제공한다.


12장 · 한국 ISP 도착률 — 네이버·다음의 현실

12.1 한국이 어려운 이유

한국 사용자의 약 40 ~ 50%는 네이버 메일(@naver.com), 다음 메일(@daum.net, @hanmail.net), Gmail Korea의 혼합 사용자다. 글로벌 ESP는 Gmail/Outlook 기준으로 평판을 관리하지만, 네이버·다음은 자체 정책이 더 보수적이다.

특히:

  • 고정 IP 신뢰가 강하다. 공유 IP 평판이 한국 ISP에서 더 변동적.
  • 한국어 본문 + 영문 발신 도메인 조합에 민감하다 — 사용자 보호 차원에서 가짜 인증 메일을 거르려는 휴리스틱.
  • 반송 사유가 영어 그대로 영문 코드로 오지 않고 한글 응답을 섞기도 한다.

12.2 한국 ISP 도착률 올리는 실전

  • DKIM·SPF·DMARC 셋 다 통과 — 글로벌 기준과 동일.
  • From 도메인이 한국어 본문과 연관 있게noreply@mail.gmail-fake.tk 같은 의심스러운 도메인은 즉시 차단.
  • 한국 사용자 비중 30% 이상이면 전용 IP 또는 별도 IP 풀을 고려.
  • 네이버 우편함 등록(Whitelist) — 네이버 정책 페이지의 "발신자 등록" 절차를 거치면 일부 도움이 된다.
  • 첫 발송 시 워밍업 — 한국 사용자 비중이 높은 캠페인은 작은 배치(100통/일)로 시작해 점진적으로 늘린다.

12.3 한국 사용자 비중에 따른 결정

  • 5% 이하: 글로벌 ESP만으로 충분. Resend·Postmark 그대로.
  • 10 ~ 30%: 글로벌 ESP에 도메인 평판 모니터링 추가. 네이버·다음 도착률을 매주 표본 추출(@naver.com 테스트 계정으로 발송 후 확인).
  • 30% 이상: 한국 ISP 전용 발송 경로 고려 — Stibee·Mailbluster·국내 SMTP relay 같은 한국 ESP 옵션. 단, 글로벌 도착률은 따로 관리.

13장 · 마케팅 vs 트랜잭션 — 메시지 스트림 분리

13.1 두 스트림은 다른 IP에서 보내라

마케팅 메일과 트랜잭션 메일은 평판이 다르다. 마케팅 메일은 스팸 신고 비율이 본질적으로 높고, 트랜잭션 메일은 거의 0이다. 같은 IP에서 둘을 섞으면 마케팅이 트랜잭션 평판을 갉아먹는다.

  • Postmark: 강제 분리 — MessageStream: 'outbound' vs 'broadcast'. 같은 도메인에서도 IP가 다르다.
  • SendGrid: IP Pools 로 분리. Pro 이상에서 권장.
  • Resend: 도메인 또는 서브도메인을 분리(mail.acme.com 트랜잭션, news.acme.com 마케팅).
  • SES: Configuration Set + Dedicated IP Pool으로 분리.

13.2 서브도메인 전략

acme.com              ← 메인 도메인 (메일 발신 안 함)
mail.acme.com         ← 트랜잭션 (영수증·인증)
news.acme.com         ← 마케팅 (뉴스레터·캠페인)
notifications.acme.com ← 시스템 알림 (Slack 스타일)

각각 SPF·DKIM·DMARC를 따로 세팅하고 ESP를 다르게 둘 수도 있다. 예: 트랜잭션은 Postmark, 마케팅은 Loops, 시스템 알림은 SES.


14장 · 운영 안티 패턴

자주 보는 실패다.

  • 콜드 메일 리스트 구매 후 첫날 1만 통 발송 — 도메인 평판이 즉시 무너진다. 회수에 보통 3 ~ 6개월.
  • noreply@ 발신자 + 답장 안 봄 — 사용자가 답장을 보내면 사라진다. CAN-SPAM 준수에도 안 좋다. support@로 받거나 자동 회신을 둔다.
  • DMARC를 첫날부터 p=reject — 잘못된 SPF 한 줄이 정상 메일을 다 죽인다. p=nonequarantinereject 단계.
  • 반송을 무시하고 계속 발송 — 하드 바운스가 1%를 넘으면 ISP가 도메인 자체를 차단한다.
  • 1-click unsubscribe를 안 박음 — 2024년부터 마케팅 메일에 필수. 안 박으면 Gmail이 스팸함으로.
  • 트래킹 픽셀·링크 단축에 의존 — Apple Mail Privacy Protection으로 opened 이벤트는 2022년부터 거의 신뢰 못 한다. 클릭률·실제 응답으로 측정.
  • 이메일 발송을 동기 HTTP 응답 안에 박음 — 발송 지연이 그대로 사용자 응답 지연이 된다. 큐(BullMQ·SQS) 뒤에서 비동기로.

15장 · 의사결정 트리

질문 1: 트랜잭션이 주인가, 마케팅이 주인가?
  ├─ 트랜잭션 우선 (인증·영수증·알림)
  │   ├─ Next.js·React 본진 → Resend
  │   ├─ 도착률 최우선 (금융·헬스) → Postmark
  │   ├─ AWS 본진 + 자체 운영 인력 → SES
  │   └─ 레거시·SAP·엔터프라이즈 → SendGrid
  └─ 마케팅 + 트랜잭션 통합
      ├─ 인디 SaaS (월 $1k ~ $50k MRR) → Loops
      ├─ 본격 마케팅 자동화 → Customer.io + 트랜잭션은 별도 Postmark/Resend
      └─ EU 데이터 거주 + 마케팅 + CRM → Brevo

질문 2: 월 발송량은?
  ├─ < 50,000통 → 어느 곳이든 OK. 가격 격차 작음.
  ├─ 50k ~ 500k → ESP 가격 비교 의미 있음.
  └─ > 1M → SES + 자체 인프라 또는 Premier 협상.

질문 3: 한국 사용자 비중은?
  ├─ < 10% → 글로벌 ESP 단독.
  ├─ 10 ~ 30% → 글로벌 ESP + 도메인 평판 모니터링.
  └─ > 30% → 글로벌 + 한국 ESP 병행 검토.

에필로그 — 이메일은 한 번 망가지면 6개월을 잃는다

이메일 인프라의 무서운 점은 한 번의 실수가 6개월을 빼앗는다는 것이다. 도메인 평판이 떨어지면 새 도메인을 사거나, 3 ~ 6개월의 회복 기간을 견뎌야 한다. 그래서 첫 발송 전에 SPF·DKIM·DMARC를 다 세팅하고, 마케팅과 트랜잭션을 분리하고, 반송·불평 웹훅을 멱등하게 받아두는 것 이 인디 개발자가 첫 주에 끝내야 하는 작업이다.

2026년의 이메일 시장은 8년 전과 다르다. Resend가 React Email로 개발자의 마음을 가져갔고, Postmark는 도착률 신뢰의 표준으로 자리잡았다. Loops가 인디 SaaS의 마케팅+트랜잭션 통합을 열었고, SES는 가격으로 여전히 압도적이다. Google·Yahoo의 2024년 가이드라인은 시장을 흔들었지만 모두 같은 방향으로 흘렀다 — SPF·DKIM·DMARC 없이는 메일을 보내지 말라.

첫 주 체크리스트

  • 1일차: 발신 서브도메인을 정한다. mail.acme.com(트랜잭션)·news.acme.com(마케팅).
  • 1일차: ESP 1차 선택(Resend 또는 Postmark).
  • 2일차: SPF·DKIM TXT 레코드 3개 입력. DNS 전파 대기.
  • 3일차: DMARC p=none + 리포트 메일 주소 설정.
  • 4일차: 반송·불평 웹훅 핸들러를 멱등하게 구현(event.id PK).
  • 5일차: 첫 트랜잭션 메일 발송. Gmail·Outlook·Naver·Daum 4개 인박스에서 확인.
  • 7일차: List-Unsubscribe 헤더 + 1-click unsubscribe 페이지.
  • 14일차: DMARC 리포트 확인 후 p=quarantine.
  • 30일차: 발송량이 5,000통/일 가까워지면 전용 IP 또는 IP 풀 분리 고려.

안티 패턴 (재정리)

  • 콜드 리스트 사다가 첫날에 도메인 평판 박살.
  • 마케팅과 트랜잭션을 같은 IP에서 섞다가 인증 메일까지 스팸함으로.
  • noreply@ 발신 + 답장 안 받기 + 1-click unsubscribe 없음.
  • 반송 처리 무시하다가 1% 넘어 차단.
  • DMARC를 첫날에 p=reject 박고 정상 메일까지 거부.
  • 한국 사용자 30%인데 글로벌 ESP만 쓰고 네이버·다음 도착률을 측정하지 않음.

다음 글 예고

다음 글에서는 이메일이 도착한 뒤 에 대해 쓴다. 받은 편지함에 도착한 메일이 어떻게 클릭되고 답장되고 매출로 이어지는지 — 개봉률·클릭률·답장률·구독해지율·매출 기여를 어떻게 측정할지, Apple Mail Privacy Protection 이후 신뢰할 수 있는 지표가 무엇인지, A/B 테스트는 어떻게 설계하는지 — 이메일 분석의 실전 운영을 한 호흡에 정리한다.


참고 / References