용어 · Amazon SES

Amazon SES란 무엇이며 애플리케이션 이메일에 어떤 영향을 주나요?

Amazon Simple Email Service(Amazon SES)는 API 또는 SMTP 인터페이스로 이메일을 발송하고 수신하는 AWS 인프라입니다. 애플리케이션 팀이 SES를 선택한다는 것은 발송 호출 이상의 것을 소유한다는 뜻입니다. 검증된 ID, 리전 구성, IAM 권한, 할당량 처리, 메시지 작성, 이벤트 수집, 반송 및 스팸 신고 대응, 발송 제외, 운영 모니터링이 포함됩니다. SES 접수는 AWS가 전달을 시도한다는 뜻이며 받은편지함 도달을 증명하지 않습니다. SES를 더 큰 애플리케이션 이메일 시스템 안의 전송 및 피드백 계층으로 다루세요.

서비스의 경계 이해하기

SES는 AWS API 또는 SMTP 엔드포인트로 애플리케이션 이메일을 접수하며, 구조화된 필드에서 MIME 메시지를 조립하거나 발신자가 조립한 메시지를 받을 수 있습니다. 이는 완전한 제품 워크플로가 아닌 인프라입니다. 발송 가능 주체, 도메인 소유 테넌트, 템플릿과 수신자 데이터 처리, 안전한 재시도 시점, 요청 성공 후 사용자 표시 내용은 애플리케이션이 여전히 결정합니다. 유용한 아키텍처는 세 상태를 분리합니다. 애플리케이션이 작업을 접수한 상태, SES가 메시지를 접수한 상태, 수신 메일 서버가 메시지를 수락 또는 거부한 상태입니다. 이 상태는 서로 다른 시점에 발생하며 다른 식별자가 필요합니다. 제목이나 수신자 데이터로 추측하지 않고 웹훅 재시도와 지원 조사를 조정하도록 자체 불변 작업 ID를 SES 메시지 식별자와 함께 저장하세요.

발송 전에 ID 검증하기

AWS는 검증된 ID를 SES에서 사용하는 도메인 또는 이메일 주소로 정의합니다. 발송 전에 From, Source, Sender, Return-Path ID가 SES 검증 규칙을 충족해야 합니다. 도메인 검증은 해당 도메인 아래의 주소를 승인할 수 있고 도메인 단위 인증을 지원하므로 애플리케이션에는 보통 오래 유지되는 선택입니다. 검증은 모든 배포에 그대로 복사할 수 있는 일회성 체크박스가 아닙니다. ID 상태와 Easy DKIM 설정은 리전별이라, 한 AWS 리전에서 검증한 도메인이 다른 리전에서 자동으로 준비되지는 않습니다. 온보딩은 상태 머신으로 만드세요. ID를 요청하고, 정확한 DNS 레코드를 보여주고, 신뢰할 수 있는 제공업체의 상태를 폴링하고, 선택한 리전이 성공을 보고한 뒤에만 프로덕션 발송을 허용합니다. 다른 발신자와 DNS를 공유한다면 기존 SPF와 DMARC 정책을 그대로 유지하고, 편의를 위해 두 번째 SPF 레코드를 만들지 마세요.

리전을 이메일 구성의 일부로 다루기

SES 리소스와 운영 한도는 리전별입니다. 검증된 ID, 샌드박스 상태, 일일 할당량, 최대 발송 속도, Easy DKIM 설정, 발송 제외 구성, 피드백 대상은 리전마다 다를 수 있습니다. AWS에서 유효한 자격 증명이라고 해서 ID가 다른 SES 엔드포인트로 그대로 이전되지는 않습니다. 리전을 일반적인 환경 기본값 뒤에 숨기지 말고, 구성에서 제공업체 계정과 ID 옆에 명시하세요. 장애 조치를 하려면 사고가 나기 전에 보조 리전을 준비해야 합니다. ID를 검증하고, DKIM 레코드를 게시하고, 프로덕션 액세스와 적절한 할당량을 확보하고, 이벤트 대상을 구성하고, 메시지 식별자와 웹훅 처리를 테스트하고, 발송 제외 동작을 이해하고 있는지 확인하세요. 장애 중에 엔드포인트만 바꾸면 하나의 사고가 검증 실패, 스로틀링, 피드백 누락이라는 다른 사고로 바뀔 수 있습니다.

API와 SMTP는 의도를 갖고 선택하기

AWS는 SES API와 SMTP 인터페이스를 통한 프로덕션 발송을 지원합니다. API는 이미 AWS 인증과 SDK를 쓰는 애플리케이션에 맞고, 구조화된 작업과 원시 메시지 작업을 제공합니다. SMTP는 이미 SMTP를 쓰는 소프트웨어에 맞지만, SES SMTP 자격 증명은 일반 AWS 액세스 키와 별개이며 리전별입니다. 어느 쪽을 택하든 큐, 멱등성, 타임아웃 처리, 안전한 재시도 규칙은 여전히 필요합니다. 애플리케이션이 응답을 받기 전에 연결이 끊어졌더라도 제공업체는 메시지를 접수했을 수 있습니다. 사용자 요청을 새 애플리케이션 식별자로 무작정 재시도하지 마세요. 한 번만 큐에 넣고, 가능하면 제공업체 응답을 보관하고, 워커가 안정적인 작업을 재시도하게 하세요. 원시 메시지 작업은 정확한 MIME 제어가 필요할 때만 사용하고, SES에 메시지를 넘기기 전에 헤더와 줄 길이를 검증하세요.

샌드박스와 할당량을 런타임 제약으로 다루기

새 SES 계정-리전 조합은 샌드박스에 있을 수 있습니다. AWS는 현재 샌드박스 한도를 24시간당 수신자 전달 200건과 초당 이메일 1통으로 문서화하며, 메일박스 시뮬레이터를 제외하면 검증된 수신자로 발송이 제한됩니다. 프로덕션 할당량은 계정, 리전, 승인된 사용 사례에 따라 다릅니다. 할당량은 API 요청이 아닌 수신자 수를 세므로 수신자 10명에게 보낸 요청 하나는 10단위를 사용합니다. 활성 리전마다 실제 할당량을 읽고 롤링 일일 발송량과 발송 속도 모두를 고려해 백프레셔를 설계하세요. 제공업체 스로틀은 대기 중인 작업을 지연해야 하며 중복 발송이나 설명 없는 성공을 만들면 안 됩니다. 출시 전에 프로덕션 액세스와 현실적인 한도를 요청하고 제어된 수신자로 부하 테스트하세요. 샌드박스를 무료 티어라고 설명하거나 한 리전의 승인이 다른 리전에 적용된다고 가정하지 마세요.

이벤트로 전달 상태 구축하기

SES 발송 작업이 성공했다는 것은 요청이 접수되었고 SES가 전달을 시도한다는 뜻입니다. 수신자가 메시지를 열었는지, 받은편지함에서 보았는지, 심지어 수신 서버가 수락했는지도 의미하지 않습니다. SES 이벤트 게시는 구성된 AWS 대상으로 발송, 전달, 반송, 스팸 신고, 거부, 렌더링 실패, 지연, 구독, 열람, 클릭을 보고할 수 있습니다. 운영상 중요한 구분은 전달 이벤트가 수신자의 메일 서버가 수락했음을 나타내는 반면, 반송과 스팸 신고 이벤트에는 정책적 대응이 필요하다는 점입니다. 전달 시스템이 알림을 재시도할 수 있으므로 이벤트는 멱등하게 수집하세요. 제공업체 메시지 식별자와 이벤트 시각을 보존하고, 형식이 잘못된 웹훅 페이로드는 거부하며, 가능하면 상태 전환이 단조롭게 진행되도록 만드세요. 열람과 클릭 관측은 개인정보와 클라이언트 제약이 있는 선택적 참여 신호이며, 전송 전달이 일어났는지를 다시 정의해서는 안 됩니다.

반송, 스팸 신고, 발송 제외 처리하기

문제가 있거나 수신을 원하지 않는 것으로 알려진 수신자를 발송 제외 처리하면 사용자와 발송 계정을 모두 보호할 수 있습니다. AWS는 전역, 계정 수준, 구성 세트 수준, 그리고 새로운 테넌트 수준의 발송 제외 동작을 제공하지만, 정확한 범위는 구성과 리전에 따라 달라집니다. 그래도 애플리케이션에는 명확한 수신자 정책이 필요합니다. 영구 반송된 주소에는 일상적인 재시도를 중단하고, 스팸 신고는 즉시 발송 제외 처리를 유발해야 하며, 해제하려면 해당 주소가 유효하고 수신자가 메일을 기대한다는 증거가 필요합니다. 멀티 테넌트 제품에서는 고객을 온보딩하기 전에 발송 제외를 계정 전체로 둘지 격리할지 정하세요. 공유 발송 제외 처리는 한 테넌트의 결과가 다른 테넌트의 발송에 영향을 줄 수 있기 때문입니다. 원시 주소는 일반 분석과 로그에 남기지 마세요. 운영 시스템은 발송 제외를 적용하기 위해 주소가 필요할 수 있지만, 대시보드와 실험에는 집계 또는 가명 처리된 측정값을 사용해야 합니다.

최소 권한을 적용하고 테넌트 격리하기

IAM 정책은 주체가 호출할 수 있는 SES 작업을 제한할 수 있고, 발송 작업에서는 From, 수신자, Return-Path 주소를 제한할 수도 있습니다. 발송 승인 정책은 다른 문제를 해결합니다. ID 소유자가 검증된 ID의 사용을 위임하도록 하며 독립적으로 철회할 수 있습니다. 단일 애플리케이션이라면 워크로드에 실제로 필요한 발송 및 모니터링 작업만 가진 주체를 사용하세요. 웹 브라우저에는 AWS 자격 증명을 주지 마세요. 멀티 테넌트 이메일 제품에는 애플리케이션 계층의 권한 부여도 필요합니다. 공유 SES 계정 하나가 워크스페이스 모델을 자동으로 이해하지는 않기 때문입니다. SES에 제출하기 전에 인증된 테넌트가 검증된 From 도메인을 소유하는지 확인하고, API 키와 메시지 레코드를 해당 테넌트로 범위를 제한하며, 다른 테넌트의 식별자에는 데이터를 반환하지 않도록 하세요. 제공업체의 IAM과 애플리케이션 권한 부여는 서로 보완하는 제어이며 대체 관계가 아닙니다.

프로덕션 준비 체크리스트 사용하기

출시 전에 AWS 계정, 리전, ID ARN, 검증 상태, DKIM 상태, 샌드박스 상태, 일일 할당량, 최대 발송 속도, 이벤트 대상, 발송 제외 범위, 자격 증명 담당자를 기록하세요. 정상 전달, 메일박스 시뮬레이터 반송, 지원되는 경우의 스팸 신고 테스트, 스로틀 응답, 이벤트 재시도, 제출 후 제공업체 타임아웃을 각각 실행해 보세요. 큐 워커가 안정적인 작업을 중복 처리하지 않는지, 전달 이벤트가 올바른 메시지를 갱신하는지, 영구 반송이 이후의 일상 발송을 막는지 확인하세요. 거부된 요청, 스로틀링, 이벤트 수집 실패, 반송과 스팸 신고 변화, 할당량 여유에 대한 알람을 설정하세요. 새 리전, 도메인, 테넌트 유형, 메시지 유형을 도입할 때마다 구성을 다시 검토하세요. 이 체크리스트는 SES를 숨은 의존성에서 담당자와 관측 가능한 장애 모드가 있는 명시적인 하위 시스템으로 바꿔 줍니다.

SendHQ가 맞는 경우 판단하기

AWS 고유의 제어를 원하고 주변 애플리케이션 계층을 직접 만들 준비가 된 팀은 SES를 직접 연동할 수 있습니다. SendHQ는 검증된 발송 도메인, 범위 지정 API 키, 단건 및 배치 발송, 수신함, 전송 이벤트 접근, 발송 제외 워크플로를 갖춘 워크스페이스 단위의 더 좁은 이메일 계약을 제공합니다. 공개 API는 From 도메인이 워크스페이스에 속하고 검증되어 있어야 하며, 접수된 메시지를 나중에 조회할 수 있도록 기록합니다. 이 제품 계층은 SES의 ID, 할당량, 평판, 수신자 측 필터링 규칙을 대체하지 않습니다. 두 계층을 따로 평가하세요. 제공업체는 메일을 전송하고 보고하며, 애플리케이션 계층은 테넌트 소유권을 강제하고 안정적인 리소스를 제공하며 운영 상태를 보여줍니다. SES를 직접 쓰든 SendHQ를 쓰든 받은편지함 도달이 보장되지는 않으므로, 제어, 관측 가능성, 소유권, 애플리케이션 워크플로에 대한 적합성을 기준으로 둘을 평가하세요.

자주 묻는 질문

Amazon SES는 이메일 API인가요, SMTP 서버인가요?

HTTPS API와 SMTP 인터페이스를 모두 제공합니다. 애플리케이션의 인증 방식과 메시지 구성 방식에 맞게 선택하고, 큐, 안정적인 작업 식별자, 이벤트 처리, 발송 제외 처리는 전송 호출 밖에서 관리하세요.

Amazon SES를 사용하려면 도메인을 검증해야 하나요?

From, Source, Sender, Return-Path 주소로 사용하는 각 ID를 검증해야 합니다. 제한된 경우에는 이메일 주소 ID로도 충분하지만, 애플리케이션이 관리하는 주소와 DKIM에는 도메인 검증이 일반적으로 더 실용적입니다.

SES 성공 응답은 이메일이 전달되었다는 뜻인가요?

아니요. SES가 요청을 접수했고 전달을 시도한다는 뜻입니다. 이후의 전달 이벤트는 수신자의 메일 서버가 메시지를 수락했다는 뜻이며, 두 상태 모두 메시지가 받은편지함 폴더에 도착했음을 증명하지 않습니다.

Amazon SES 할당량은 리전 간에 공유되나요?

아니요. AWS 문서에 따르면 발송 할당량, 샌드박스 상태, 검증된 ID, DKIM 설정, 발송 제외 구성은 리전별입니다. 장애 중에 엔드포인트를 바꾸지 말고, 프로덕션 트래픽을 받을 수 있는 모든 리전을 미리 준비하고 테스트하세요.

SES로 발송한 뒤 애플리케이션은 무엇을 저장해야 하나요?

안정적인 애플리케이션 작업 ID, 접수 시점의 SES 메시지 식별자, 제공업체와 리전, 현재 상태, 타임스탬프, 정규화된 전송 이벤트를 저장하세요. 메시지 내용과 수신자 데이터는 광범위한 로그와 분석에 남기지 마세요.

팀은 언제 SES를 직접 쓰지 않고 SendHQ를 써야 하나요?

팀이 AWS 연동과 주변의 모든 제어를 직접 맡고 싶다면 SES를 직접 사용하세요. 워크스페이스 단위 키, 도메인 소유권 확인, 수신함, 메시지 리소스, 전송 이벤트, 발송 제외 워크플로가 애플리케이션 기본 요소로 유용하다면 SendHQ를 고려하세요.

출처

더 알아보기

Amazon SES 비용: 제품 팀을 위한 요금 모델수신자, 데이터, 요금제, 전용 IP, 이벤트 인프라, 할당량, 그리고 전송을 둘러싼 엔지니어링 계층까지 포함해 Amazon SES 비용을 모델링합니다.