Mailgun, Resend, Postmark: 이메일 API가 아니라 제품의 대화 방식을 고르는 일
Resend는 알림을 보낼 때 좋고, Mailgun은 많이 뿌릴 때 좋고, Postmark는 이메일이 제품 상태를 바꾸는 입구일 때 좋다.
이메일 벤더를 고를 때 제일 흔한 실수는 가격표부터 보는 것이다.
몇 통까지 무료인지, 월 얼마인지, 1,000통당 얼마인지 비교한다. 물론 돈은 중요하다. 그런데 작은 제품에서 이메일 벤더를 고를 때 진짜 중요한 건 가격이 아니다.
더 중요한 질문은 이것이다.
이 제품에서 이메일은 무슨 역할을 하는가?
이메일을 단순 알림으로 쓸 수도 있다.
이메일을 대량 배포 채널로 쓸 수도 있다.
이메일을 사용자가 제품에 무언가를 입력하는 입구로 쓸 수도 있다.
이 세 가지는 완전히 다른 문제다. 그런데 우리는 자주 이걸 뭉뚱그려 “메일 발송”이라고 부른다. 그래서 선택이 흐려진다.
내 기준은 단순하다.
Resend는 알림을 보낼 때 좋다.
Mailgun은 많이 뿌릴 때 좋다.
Postmark는 이메일이 제품 상태를 바꾸는 입구일 때 좋다.
이게 이 글의 전부다.
이메일은 죽은 채널이 아니라 낡지 않은 인터페이스다
요즘 제품에서 이메일은 여전히 가장 보편적인 인터페이스다.
가입 링크가 이메일로 온다.
결제 영수증이 이메일로 온다.
리포트가 이메일로 온다.
장애 알림이 이메일로 온다.
고객 문의가 이메일로 들어온다.
AI 에이전트의 결과물이 이메일로 오고, 사람이 답장하면 다음 단계가 진행된다.
그러니까 이메일은 단순한 알림 채널이 아니다. 제품과 외부 세계가 만나는 오래된 API다.
브라우저를 열지 않아도 된다.
새 앱을 배우지 않아도 된다.
계정을 새로 만들지 않아도 된다.
그냥 메일을 받거나 보내면 된다.
이 단순함 때문에 이메일은 오래 살아남았다. 그리고 이 단순함 때문에 제품 안에서 꽤 강력하다. 사용자가 이미 알고 있는 인터페이스이기 때문이다.
좋은 제품은 이메일 벤더를 사용자에게 숨긴다
Ghost를 보면 이 원칙이 잘 보인다.
Ghost(Pro)는 이메일 발송 설정을 사용자가 직접 만지지 않게 한다. 이메일 delivery는 서비스에 포함되어 있고, 설정은 Ghost가 처리한다. 사용자는 Mailgun, SMTP, API key를 몰라도 된다.
반대로 self-hosted Ghost에서 뉴스레터를 보내려면 Mailgun 설정이 필요하다. Ghost 문서는 대량 뉴스레터를 기본 SMTP로 보내지 말라고 한다. bulk email은 별도의 bulk mail provider가 필요하고, Ghost가 공식 지원하는 bulk provider는 Mailgun이다.
이 차이가 중요하다.
대여형 소프트웨어에서 사용자는 이메일 벤더를 고르고 싶은 게 아니다. 사용자가 원하는 건 “내 고객에게 메일이 잘 감”이다.
SaaS든, 출판 서비스든, 마켓플레이스든, AI agent 앱이든 마찬가지다. 벤더는 내부 선택이다. 제품 경험은 하나의 약속이어야 한다.
좋은 제품은 내부 인프라를 설명하지 않는다. 그냥 약속한 일이 되게 만든다.
Resend: 제품에서 메일을 보내야 할 때
Resend는 시작이 빠르다.
API가 단순하고 문서가 깔끔하다. 작은 앱에서 회원가입 메일, 초대 메일, waitlist 알림, 결제 완료 메일, 운영자 알림을 붙이기 좋다.
2026년 5월 26일 기준 공식 문서상 Free는 3,000 emails/month, 100 emails/day이고, Pro는 월 20달러부터 시작한다. 초기 제품에는 충분히 매력적인 구간이다.
그래서 문제가 “제품 이벤트가 생겼을 때 이메일을 보내고 싶다”라면 Resend가 가장 편하다.
예를 들면 이런 경우다.
사용자가 가입했다.
로그인 링크를 보내야 한다.
새 신청이 들어왔다.
운영자에게 알림을 보내야 한다.
결제가 끝났다.
영수증을 보내야 한다.
이 정도라면 Resend가 좋다. 개발자가 붙이기 쉽고, 코드도 예쁘게 남는다.
다만 Resend의 중심은 여전히 “잘 보내는 API”에 가깝다. 이메일이 제품의 입구가 되고, 사용자의 답장이 상태를 바꾸고, inbound가 운영 로직과 강하게 붙기 시작하면 이야기가 달라진다.
Mailgun: 이메일이 배포망일 때
Mailgun은 더 인프라답다.
Ghost self-hosted가 뉴스레터 발송에 Mailgun을 요구하는 이유도 여기에 있다. 많은 사람에게 이메일을 보내는 일은 그냥 SMTP로 밀어 넣는 문제가 아니다.
도메인 인증이 필요하다.
평판 관리가 필요하다.
bounce와 suppression이 필요하다.
event log가 필요하다.
unsubscribe와 route가 필요하다.
Mailgun은 이런 “이메일 배포망”의 느낌이 강하다. 2026년 5월 26일 기준 공식 Help Center에 따르면 무료 플랜은 100 messages/day, 1 custom domain, 1 inbound route를 제공한다.
뉴스레터가 제품의 본체라면 Mailgun은 계속 강한 후보다.
커뮤니티 공지, 리포트 대량 발송, 회원 세그먼트별 메일, 출판물 배포처럼 “많은 사람에게 안정적으로 보내는 것”이 중요하면 Mailgun 쪽으로 기운다.
단점은 있다. 가벼운 제품에는 조금 무겁다. 오늘 당장 waitlist 알림 하나 붙이려고 Mailgun을 보면 설정 표면이 과하게 느껴질 수 있다.
Mailgun은 “메일 하나 보내기”보다 “메일을 계속 많이 보내는 시스템”에 가깝다.
Postmark: 이메일이 워크플로우의 입구일 때
Postmark는 결이 다르다.
Postmark는 transactional email의 신뢰성과 속도를 오래 밀어온 서비스다. 그리고 inbound email processing도 잘 갖춰져 있다. 이메일을 JSON 이벤트로 받아 제품 안의 상태와 연결하기 좋다.
이 차이는 생각보다 크다.
고객이 이메일로 문의하면 티켓이 생긴다.
운영자가 답장하면 상태가 바뀐다.
AI 에이전트가 결과물을 이메일로 보내고, 사람의 승인 답장을 기다린다.
작가가 원고를 이메일로 보내면 검토 큐에 들어간다.
파트너가 첨부 파일을 보내면 내부 레코드가 생긴다.
이런 흐름에서는 “메일을 보내는 API”보다 “메일을 제품 이벤트로 바꾸는 파이프”가 중요하다.
Postmark가 잘 맞는 지점은 여기다. 이메일을 알림이 아니라 상태 전이의 입구로 볼 때.
2026년 5월 26일 기준 Postmark의 Free tier는 100 emails/month이고, Basic은 월 15달러부터 시작한다. Resend보다 무료 구간은 작다. 대신 작은 프로덕션 서비스가 돈을 내고 쓰는 운영 파이프로는 납득 가능한 수준이다.
셋은 경쟁자라기보다 세 가지 세계관이다
Mailgun, Resend, Postmark는 겹치는 부분이 있다. 셋 다 메일을 보낼 수 있다. 셋 다 API가 있다. 셋 다 어느 정도의 운영 기능을 제공한다.
하지만 제품을 고르는 기준은 “가능하냐”가 아니다.
무엇을 중심에 두고 설계됐는지가 중요하다.
Resend는 빠르게 붙이는 개발자 경험이 좋다.
Mailgun은 대량 발송과 이메일 인프라 운영에 강하다.
Postmark는 신뢰성 있는 transactional과 inbound workflow에 강하다.
그래서 답은 하나가 아니다.
초기 SaaS에서 알림 메일을 빨리 붙일 거면 Resend.
뉴스레터와 대량 발송이 핵심이면 Mailgun.
이메일이 사용자의 입력이자 운영 상태의 시작점이면 Postmark.
이렇게 고르면 된다.
이메일 벤더 선택은 제품 설계다
처음에는 모두 “메일 하나 보내면 되지 않나?“로 시작한다.
그런데 제품이 조금만 진지해지면 이메일은 금방 상태, 권한, 승인, 고객 경험, 운영 비용과 연결된다.
누가 어떤 주소로 보냈는가.
그 메일은 어떤 고객, 주문, 글, 작업과 연결되는가.
답장을 하면 무엇이 바뀌는가.
실패하면 누가 알아야 하는가.
대량 발송에서 빠진 사람은 어떻게 관리하는가.
이 질문들이 생기는 순간 이메일은 단순 발송 기능이 아니다. 제품의 바깥쪽 인터페이스다.
그래서 이메일 벤더 선택은 가격표 비교가 아니다.
제품이 외부 세계와 대화하는 방식을 정하는 일이다.
사용자는 그 벤더 이름을 몰라도 된다. 아니, 몰라야 한다. 좋은 제품은 내부 인프라를 숨긴다. 사용자는 그냥 약속한 일이 됐는지만 본다.
내 결론은 간단하다.
이메일을 알림으로 보면 Resend가 먼저 보인다.
이메일을 배포망으로 보면 Mailgun이 먼저 보인다.
이메일을 워크플로우의 입구로 보면 Postmark가 먼저 보인다.
그리고 이 셋 중 무엇을 고르든, 진짜 결정은 벤더가 아니라 제품 쪽에서 이미 내려진다.
이 제품은 이메일을 무엇으로 보는가.
그 질문에 답하면, 벤더 선택은 따라온다.
