Amazon SES와 SendGrid 비교: 인증·주문 메일 발송 비용과 운영 기준

회원가입 인증, 주문 확인, 비밀번호 재설정 메일을 앱에서 보내려면 Amazon SES와 Twilio SendGrid 같은 발송 서비스를 검토할 수 있습니다. AWS 구성에 맞춰 발송과 이벤트 처리를 연결하려면 SES를, Email API·SMTP 서비스의 기능과 운영 도구를 함께 비교하려면 SendGrid를 후보로 둘 수 있습니다. 결정할 때는 한 건의 단가와 함께 도메인 인증, 실패한 주소의 처리, 피크 시간의 발송 속도와 운영 인력을 확인해야 합니다.

직접 생성한 개념 이미지. 이메일 발송과 결과 수집 흐름을 표현했으며 받은편지함 도착을 보장하는 그림은 아닙니다.

1. 직원용 메일함과 앱 발송 서비스는 역할이 다릅니다

이 글은 직원이 로그인해 메일을 읽는 회사 메일함을 비교하지 않습니다. 앱의 이벤트에 따라 수신자에게 메시지를 보내는 트랜잭션 이메일을 대상으로 합니다. 주문 확인과 비밀번호 재설정은 내용·유효시간·재시도 요구가 다르므로 같은 발송 목록으로 뭉뚱그리지 않는 편이 좋습니다. 업무용 계정과 이전은 Microsoft 365와 Google Workspace 비교에서 별도로 확인할 수 있습니다.

비교 항목	Amazon SES	Twilio SendGrid
도입 검토	AWS 발송 환경·리전·이벤트 연계 확인	Email API·SMTP 기능과 요금제 확인
첫 운영 준비	발신자 인증·샌드박스 상태·할당량 확인	도메인 인증·계정 및 발송 조건 확인
가격 비교	요금제와 개별 기능 과금 구분	Email API 요금제·포함량·추가 항목 구분
실패 처리	반송·불만 통지와 처리 시스템 구성	Event Webhook 이벤트와 처리 시스템 구성

SendGrid 공식 제품 안내의 Email API·SMTP 서비스를 비교 대상으로 삼았습니다. 마케팅 캠페인 제품의 연락처 수와 발송 가격을 트랜잭션 Email API 견적에 그대로 적용하지 마세요. 두 서비스 중 어느 것을 사용해도 수신 측 정책과 발신 평판에 따라 결과가 달라집니다.

2. 월 사용자 수 대신 실제 수신자별 발송 건수를 계산하세요

가상의 쇼핑 서비스가 한 달에 주문 4만 건마다 주문 확인과 배송 안내를 각각 한 번 보내고, 비밀번호 재설정 등 기타 알림을 1만 건 보낸다고 가정합니다. 예상 발송은 4만×2+1만=9만 건입니다. 같은 사람이 여러 번 받는 메일과 한 메시지의 여러 수신자를 구분하고, 재발송 증가와 계절별 피크도 견적 입력에 포함하세요. 이 숫자는 서비스 요금이나 실측 발송량이 아니라 계산 방법을 보여주는 예시입니다.

2026년 10월 3일 확인한 SES 공식 요금표는 Essentials·Pro·Enterprise 요금제와 à la carte 항목을 함께 설명합니다. 오래된 글에 나온 한 가지 발송 단가만으로 현재 계정의 비용을 계산하지 말고 적용 요금제, 계정·리전별 고정 항목, 첨부 데이터와 선택 기능을 확인해야 합니다. SendGrid Email API 요금표도 같은 발송량과 필요한 기능을 선택해 비교하세요.

• 한 달의 수신자별 발송량과 최대 초당 발송 요구량을 따로 기록
• 공유 IP·전용 IP, 발송 분석, 검증 기능과 지원 범위의 필요 여부 결정
• 반송 처리·이벤트 저장·운영 대응에 쓰는 부가 서비스 비용 포함
• 체험 기간·할인·세금·환율을 기본 요금과 구분해 기록

전용 IP를 추가한다고 받은편지함 도착이 자동으로 개선되는 것은 아닙니다. 발송량과 일관된 운영 계획을 함께 검토해야 합니다. 현재 요금표의 조건을 입력한 견적과 팀의 운영 시간을 비교하면 가격만 낮은 선택에서 생기는 누락을 줄일 수 있습니다.

3. 첫 발송 전에 도메인과 발송 제한을 확인하세요

SES 프로덕션 접근 안내에 따르면 신규 계정의 샌드박스 상태는 리전별로 관리됩니다. 샌드박스에서는 검증된 수신자나 시뮬레이터 등으로 대상이 제한되고 발송량·속도 제한도 있습니다. 한 리전에서 운영 접근이 가능해도 다른 리전의 설정이 같다고 가정하면 안 됩니다. 승인 시각을 확정적으로 약속하지 말고 계정 화면의 현재 상태를 기준으로 준비하세요.

SES의 DKIM 설정과 SendGrid의 도메인 인증은 공식 안내와 서비스 화면에 표시된 DNS 값을 기준으로 적용합니다. From 주소, DKIM 서명, SPF와 DMARC의 관계를 확인하고 수신한 테스트 메일의 헤더를 검토하세요. 기존 회사 메일 DNS를 무작정 덮어쓰거나 샘플 DNS 값을 그대로 복사하면 다른 발송 경로에 영향을 줄 수 있습니다.

발송 API의 자격 증명은 서버에서 보관하고 앱의 프런트엔드 코드나 공개 저장소에 넣지 않습니다. 인증 메일에 포함된 일회용 링크나 코드를 발송 로그에 통째로 저장하지 않고, 메시지 식별자와 처리 상태를 중심으로 기록하는 운영 방식을 정하세요.

4. API 성공·수신 서버 전달·사용자 확인을 구분하세요

앱에서 발송 요청이 성공했다고 사용자가 메일을 읽었다고 볼 수는 없습니다. 요청 접수 뒤 일시 지연, 반송, 수신 서버의 거부가 생길 수 있습니다. SES 이벤트 통지와 SendGrid Event Webhook로 결과를 수집하고, 주문 번호 등 내부 업무 식별자와 제공자의 메시지 ID를 연결해 원인을 추적하세요.

SendGrid 문서에서 delivered는 메시지를 수신 서버에 전달한 상태입니다. 받은편지함 배치나 사용자의 열람을 보장하는 상태로 표시하면 고객 대응이 잘못될 수 있습니다. “발송 요청 접수”, “수신 서버 전달”, “실패·지연”을 별도 상태로 기록하고, 인증 메일처럼 시간이 중요한 경우에는 지연 경보 기준도 설정하세요.

주문 이벤트 → 내부 발송 작업 저장
발송 작업 → Email API 요청 → 제공자 메시지 ID 기록
처리 결과 이벤트 → 메시지 ID 연결 → 상태 갱신
반송·불만 → 재발송 제외 정책 적용
일시 오류 → 제한된 재시도·지연 경보

위 흐름은 설계 예시입니다. 네트워크 오류로 응답을 못 받았을 때 요청이 실제 접수됐는지 불분명할 수 있으므로 같은 주문에 중복 메일이 나가지 않도록 앱에서 발송 작업의 중복 방지 기준을 마련하세요. 영구 반송과 일시 오류에 동일한 무한 재시도를 적용하지 않습니다. API 제한 대응은 HTTP 429와 재시도 백오프를 함께 참고할 수 있습니다.

5. 선택을 위한 작은 검증 시나리오

• 팀이 관리하는 테스트 주소로 인증·주문·재설정 템플릿의 링크와 문자 인코딩 확인
• 발송 요청의 성공·일시 실패·영구 실패를 구분해 내부 상태가 바뀌는지 확인
• 이벤트가 재전달돼도 상태가 중복 처리되지 않는지 확인
• 발송 속도 제한과 인증 링크의 만료 시간 사이에 지연이 생기는지 확인
• 고객 문의 시 메시지 ID로 검색하고 실패 원인을 설명할 수 있는지 확인

운영자가 AWS 이벤트 연계와 서버 측 처리에 익숙하고 그 책임을 맡을 수 있다면 SES의 구성과 요금제를 먼저 검증할 수 있습니다. 이메일 전담 기능·사용자 작업 흐름·지원 요구가 더 중요하다면 SendGrid의 실제 플랜과 운영 화면을 확인하세요. 어느 쪽이 항상 더 싸거나 도착률이 높다고 단정할 근거는 이 글에서 제시하지 않습니다. 위 시험은 독자가 수행할 검증 목록이며 실제 서비스에서 측정한 성능 결과는 아닙니다.

6. 자주 묻는 질문

SES나 SendGrid를 쓰면 회사 메일함도 생기나요?
이 글의 비교 대상은 앱 발송 서비스입니다. 직원용 메일함·캘린더·협업 계정과는 따로 도입 범위를 확인해야 합니다.

SMTP를 사용하면 기존 코드 수정이 필요 없나요?
SMTP 연결 설정만 바꿔도 발송할 수 있는 경우가 있지만, 인증·발송 제한·결과 수집·중복 방지와 실패 처리까지 검증해야 운영 이전이 완료됩니다.

delivered이면 스팸함에 들어가지 않았다고 볼 수 있나요?
아닙니다. 수신 서버 전달과 받은편지함 배치는 구별해야 합니다. 사용자 확인이 필요한 업무는 별도의 앱 상태와 만료·재요청 절차를 설계하세요.

확인 기준: 2026-10-03. 공식 요금제와 계정 조건은 변경될 수 있습니다. 예시 발송량과 처리 흐름은 설명용 가정이며 실측 비용·도착률 비교가 아닙니다.