SendGrid 무료 요금제 종료: 30분 마이그레이션 가이드

영구 무료 플랜의 종료

소규모 사이드 프로젝트나 신규 제품에서 SendGrid 무료 플랜에 의존했다면 변화를 이미 눈치챘을 것입니다. 무료 플랜이 이제 60일 체험판으로 바뀌었습니다. 체험판이 끝나면 유료 플랜으로 옮겨야 하며, Essentials는 월 19.95 USD부터 시작합니다(SendGrid 요금). 마이그레이션하려면 발송 제외 목록을 내보내고, DNS 레코드를 업데이트하고, API 연동을 교체해야 합니다. 템플릿이 단순하다면 이 과정은 약 30분이 걸립니다.

대안 평가하기

대체 서비스를 고를 때는 제공업체의 접수(API가 요청을 받아들임), 전달(수신 서버가 메일을 받아들임), 받은편지함 도달(메일이 스팸함을 피함)을 구분해야 합니다. 마지막 단계는 발신자 평판과 콘텐츠에 좌우되므로 어떤 제공업체도 보장할 수 없습니다.

비용 현황 (2026년 9월)

소량 트랜잭션 메일에서는 가격 차이가 상당합니다. 50,000통을 발송하는 데 Amazon SES 종량제에서는 약 5 USD, Postmark 요금제에서는 약 66 USD가 듭니다.

• Amazon SES: 종량제로 1,000통당 0.10 USD입니다(AWS SES 요금). 2026년 7월 21일에 도입된 새 단계별 요금제에는 Essentials(1,000통당 0.16 USD), Pro(1,000통당 0.22 USD에 리전별 월 105 USD), Enterprise(1,000통당 0.23 USD에 월 500 USD)가 있습니다.
• Resend: 월 3,000통(일 100통 한도)의 무료 플랜을 제공합니다. Pro 플랜은 50,000통에 월 20 USD이며, 초과분은 1,000통당 0.90 USD입니다(Resend 요금).
• Mailgun: 10,000통에 월 15 USD부터 시작하며, 초과분은 1,000통당 1.80~1.10 USD입니다(Mailgun 요금).
• Postmark: 10,000통에 월 15 USD부터 시작하며, 초과분은 1,000통당 1.80~1.20 USD입니다(Postmark 요금).
• SendHQ: EU 전용 개인정보 최소화 텔레메트리와 워크스페이스 단위 API 키에 초점을 맞춘, 제품 팀과 AI 에이전트를 위한 현대적인 대안입니다.

1단계: 데이터 내보내기와 발송 제외 목록

발송 제외 목록을 내보내지 않고 목록을 옮기지 마세요. 이전에 반송되었거나 수신 거부한 주소로 발송하면 새 제공업체에서 평판이 손상될 위험이 있습니다.

SendGrid는 UI 또는 API로 발송 제외 목록을 내보낼 수 있습니다. 연락하면 안 되는 이메일의 CSV를 받게 됩니다. 이를 새 제공업체로 가져올 때는 GDPR이나 CAN-SPAM 같은 법규를 준수하도록 "사유"(반송 대 수신 거부)를 올바르게 매핑해야 합니다.

2단계: DNS와 인증

대부분의 마이그레이션이 여기서 실패합니다. API 키만 바꿀 수는 없으며, 새 제공업체에 도메인 소유권을 증명해야 합니다.

DKIM, SPF, DMARC

DNS 제공업체에 새 CNAME 또는 TXT 레코드를 추가해야 합니다. SendHQ로 옮긴다면 변경하기 전에 이메일 DNS 확인 도구로 현재 설정을 검증할 수 있습니다.

1. SPF: SPF 레코드에 새 제공업체를 포함하도록 업데이트하세요. 제공업체를 여러 개 쓴다면 SPF TXT 레코드를 여러 개 둘 수 없다는 점을 기억하세요. 하나로 합쳐야 합니다(예: v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). 더 자세한 내용은 SPF 용어집 항목을 참고하세요.
2. DKIM: 새 제공업체의 대시보드에서 새 DKIM 키를 생성하고, 생성된 CNAME 레코드를 DNS에 추가하세요. 이렇게 하면 수신 서버가 전송 중에 이메일이 변조되지 않았음을 검증할 수 있습니다.
3. DMARC: DMARC 정책은 도메인 단위 정책이므로 제공업체와 관계없이 그대로 유지됩니다. 다만 이메일이 거부되지 않도록 새 제공업체가 DMARC 정책에 맞게 정렬되어 있는지 확인하세요. 구현 세부 사항은 DKIM, SPF, DMARC 가이드를 참고하세요.

3단계: 코드 마이그레이션

대부분의 제공업체는 REST API를 사용합니다. SendGrid의 동적 템플릿을 사용했다면 해당 HTML/CSS 레이아웃을 새 제공업체의 템플릿 엔진으로 옮겨야 합니다.

예시: SendGrid에서 일반적인 REST API로

SendGrid는 personalizations에 특정 JSON 구조를 사용합니다. SendHQ를 포함한 대부분의 최신 API는 가독성을 높이기 위해 더 평평한 구조를 선호합니다.

SendGrid 페이로드:

{ "personalizations": [ { "to": [{"email": "user@example.com"}], "dynamic_template_data": { "first_name": "Alice" } } ], "from": {"email": "noreply@yourdomain.com"}, "template_id": "d-12345" }

최신 API 페이로드(예: SendHQ):

{ "to": "user@example.com", "from": "noreply@yourdomain.com", "template_id": "welcome-email", "variables": { "first_name": "Alice" } }

코드에서 마이그레이션 처리하기

다운타임을 피하려면 래퍼 또는 전략 패턴을 구현하세요. 그러면 환경 변수로 제공업체를 전환할 수 있습니다.

interface EmailProvider { send(payload: EmailPayload): Promise<void>; } class SendGridProvider implements EmailProvider { async send(payload: EmailPayload) { // SendGrid specific implementation } } class SendHQProvider implements EmailProvider { async send(payload: EmailPayload) { // SendHQ specific implementation } } const provider = process.env.EMAIL_PROVIDER === 'sendhq' ? new SendHQProvider() : new SendGridProvider();

4단계: AI 에이전트와 멱등성

AI 에이전트로 이메일을 트리거한다면 특정 위험이 있습니다. 에이전트가 타임아웃 때문에 루프에 빠지거나 요청을 여러 번 재시도해 사용자가 똑같은 이메일을 열 통 받을 수 있습니다.

이메일 발송은 외부 부수 효과이므로 멱등성을 구현해야 합니다. 멱등성 키는 헤더로 보내는 고유 식별자로, API에 "이 키를 이미 본 적이 있다면 이메일을 다시 보내지 말고 최초의 성공 응답만 반환하라"고 알려 줍니다.

에이전트 대응 구현:

{ "headers": { "Idempotency-Key": "order_123_welcome_email" }, "body": { "to": "customer@example.com", "template_id": "order-confirmation" } }

또한 비밀번호 재설정이나 결제 알림처럼 위험도가 높은 에이전트 작업에는 사람 승인 단계(human-in-the-loop)나 사용자 ID별 엄격한 속도 제한을 적용해, 에이전트의 환각으로 고객에게 스팸이 발송되는 일을 막으세요.

5단계: 테스트와 검증

환경 변수를 새 제공업체로 전환하기 전에 다음 체크리스트를 확인하세요.

• DNS 전파: dig 같은 도구나 웹 기반 확인 도구로 새 DKIM 및 SPF 레코드가 적용되었는지 확인하세요.
• 웹훅 검증: 전달 이벤트(delivered, opened, clicked)에 의존한다면 웹훅 엔드포인트를 업데이트하세요. SendGrid의 이벤트 형식은 다른 곳과 다릅니다. 엔드포인트가 새 JSON 스키마를 오류 없이 처리할 수 있는지 확인하세요.
• 오류 처리: 애플리케이션이 제공업체별 오류를 어떻게 처리하는지 테스트하세요. 예를 들어 429(Too Many Requests)는 백오프 전략을 실행해야 하고, 400(Bad Request)은 대개 형식이 잘못된 이메일 주소를 뜻하므로 데이터베이스에서 반송으로 표시해야 합니다.

테스트할 일반적인 오류 사례

1. 잘못된 이메일 형식: API가 명확한 오류를 반환하고 코드가 무한정 재시도하지 않는지 확인하세요.
2. 속도 제한: 이메일을 한꺼번에 몰아서 보내, 큐가 제공업체의 한도를 처리하는지 확인하세요.
3. 큰 첨부 파일: 새 제공업체의 최대 페이로드 크기를 확인하세요. 10MB로 제한하는 곳도 있고 25MB로 제한하는 곳도 있습니다.

마이그레이션 요약 체크리스트

• 발송 제외 내보내기: SendGrid에서 CSV를 내보냅니다.
• DNS 레코드 설정: SPF, DKIM, DMARC 정렬.
• 템플릿 마이그레이션: HTML/CSS를 새 형식으로 변환합니다.
• API 로직 업데이트: 제공업체 래퍼를 구현합니다.
• 멱등성 추가: AI 에이전트 트리거에 필수입니다.
• 웹훅 테스트: 이벤트 전달과 파싱을 검증합니다.
• 트래픽 전환: ENV 변수를 업데이트하고 로그를 모니터링합니다.

전달성에 대한 마무리 생각

제공업체를 옮기는 시기는 발송 습관을 점검하기 좋은 때입니다. 제공업체의 접수는 첫 번째 관문일 뿐이라는 점을 기억하세요. 전달은 수신 ISP(Gmail, Outlook 등)가 연결을 받아들이는 데 달려 있습니다. 받은편지함 도달은 마지막 관문으로, 도메인의 장기 평판과 수신자의 반응률로 결정됩니다.

이런 API를 원치 않는 대량 이메일에 쓰려는 유혹은 피하세요. 불법인 경우가 많을 뿐 아니라, 어느 제공업체를 선택하든 계정이 정지됩니다. 트랜잭션 성격의, 수신 동의를 받은 커뮤니케이션만 발송해 발신자 점수를 건강하게 유지하세요.

AI 네이티브 애플리케이션을 만드는 팀은 MCP 서버, llms.txt 파일 같은 에이전트 대응 기능을 제공하는 제공업체를 찾으세요. 연동이 매끄러워집니다. SendHQ는 바로 이러한 워크플로를 위해 설계되었으며, 현대적인 제품 팀에 필요한 인프라를 제공합니다.

안정적인 이메일 시스템을 구축하는 방법을 더 알아보려면 https://sendhq.cc를 방문하세요.