AWS SES 샌드박스 모드: 고객에게 이메일이 안 가는 이유와 프로덕션 전환 방법

SES로 내 계정 이메일로는 잘 보내지는데, 실제 고객 이메일 주소로는 전송이 안 된다. 처음 SES를 설정할 때 가장 많이 마주치는 상황이다. 원인은 단순하다 — AWS SES는 모든 신규 계정을 기본적으로 샌드박스(Sandbox) 모드로 시작하며, 이 상태에서는 발신과 수신 모두 사전 검증된 이메일 주소로만 제한된다.

TL;DR — SES 샌드박스 모드 핵심 요약

항목샌드박스 모드프로덕션 모드
수신자 제한검증된 이메일/도메인만 가능임의의 수신자 가능
일일 발송 한도200건/일, 1건/초요청에 따라 증가 가능
발신자 주소검증된 이메일/도메인만 가능검증된 이메일/도메인만 가능
바운스/컴플레인 처리시뮬레이터로 테스트 가능실제 피드백 루프 필요
전환 방법—AWS Support 케이스 제출

정확한 한도 수치는 AWS 공식 문서에서 확인하라. 리전별, 계정별로 다를 수 있다.

SES 샌드박스 모드가 작동하는 방식

AWS가 샌드박스를 두는 이유는 명확하다. 이메일 인프라는 스팸 발송자들이 가장 먼저 노리는 대상이고, 새로 생성된 AWS 계정에서 대량 스팸이 발송되면 SES 전체의 IP 평판이 훼손된다. 샌드박스는 그 방어선이다.

샌드박스 상태에서 SES가 이메일을 수락하는 조건은 두 가지다. 발신자 주소(From)가 SES에 검증된 이메일 또는 도메인이어야 하고, 수신자 주소(To) 역시 검증된 이메일 또는 도메인에 속해야 한다. 두 조건 중 하나라도 어긋나면 SES는 메시지 전송을 거부한다.

graph TD A["이메일 발송 요청"] --> B{"발신자 주소 검증 여부"} B -- "미검증" --> C["SES 거부 (발신자 오류)"] B -- "검증됨" --> D{"샌드박스 모드 여부"} D -- "프로덕션" --> E["임의 수신자에게 발송 가능"] D -- "샌드박스" --> F{"수신자 주소 검증 여부"} F -- "미검증" --> G["SES 거부 (수신자 오류)"] F -- "검증됨" --> H["발송 성공 (한도 내에서)"]
  1. 검증된 발신자: 샌드박스와 프로덕션 모두에서 From 주소는 반드시 SES에 검증되어 있어야 한다.
  2. 수신자 제한 (샌드박스 전용): 샌드박스에서는 To 주소도 검증된 이메일이나 도메인이어야 한다. 이 제한이 '내 이메일로는 되고 고객 이메일로는 안 되는' 현상의 원인이다.
  3. 프로덕션 전환 후: 수신자 제한이 해제되어 임의의 이메일 주소로 발송 가능해진다. 단, 발신자 검증 요건은 그대로 유지된다.
  4. 바운스/컴플레인 임계값: 프로덕션에서도 바운스율과 컴플레인율이 AWS 기준을 초과하면 계정이 일시 정지될 수 있다.

현재 샌드박스 상태 확인하기

콘솔에서 확인하는 것보다 CLI로 확인하는 게 더 빠르다. get-account 명령으로 현재 계정의 SES 상태를 즉시 확인할 수 있다.

aws sesv2 get-account \
  --region us-east-1

응답에서 ProductionAccessEnabled 필드를 확인하라. false이면 샌드박스 상태다.

{
  'ProductionAccessEnabled': false,
  'SendQuota': {
    'Max24HourSend': 200.0,
    'MaxSendRate': 1.0,
    'SentLast24Hours': 0.0
  },
  'SendingEnabled': true
}

ProductionAccessEnabled: false이면서 SendingEnabled: true인 상태가 전형적인 샌드박스 상태다. 이메일 자체는 보낼 수 있지만, 검증된 주소로만 가능하다.

검증된 이메일 주소 목록 확인

현재 어떤 주소가 검증되어 있는지 확인하는 것도 디버깅의 첫 단계다. 내가 보내려는 수신자 주소가 이 목록에 없다면, 샌드박스에서는 전송이 불가능하다.

aws sesv2 list-email-identities \
  --region us-east-1

새 이메일 주소를 검증하려면 아래 명령을 사용한다. 검증 이메일이 해당 주소로 발송되며, 링크 클릭 후 검증이 완료된다.

aws sesv2 create-email-identity \
  --email-identity user@example.com \
  --region us-east-1

SES 프로덕션 액세스 요청 방법

프로덕션 전환은 AWS Support 케이스를 통해 이루어진다. 자동화된 승인 프로세스가 아니라 AWS 팀이 직접 검토한다. 케이스 내용이 부실하면 반려되거나 추가 정보 요청이 온다.

콘솔에서 요청하기

  1. AWS 콘솔 → Amazon SES → 해당 리전 선택
  2. 왼쪽 메뉴에서 'Account dashboard' 클릭
  3. 'Request production access' 버튼 클릭
  4. 사용 사례, 예상 발송량, 바운스/컴플레인 처리 방법 작성 후 제출

CLI로 요청하기

콘솔 없이 CLI로도 프로덕션 액세스를 요청할 수 있다. put-account-details 명령을 사용한다.

🔽 CLI 프로덕션 액세스 요청 명령 펼치기 
aws sesv2 put-account-details \
  --mail-type TRANSACTIONAL \
  --website-url https://www.example.com \
  --use-case-description 'We send transactional emails (order confirmations, password resets) to registered users of our e-commerce platform. Users explicitly opt in during registration. We handle bounces and complaints via SNS notifications and immediately suppress affected addresses.' \
  --additional-contact-email-addresses admin@example.com \
  --production-access-enabled \
  --region us-east-1

요청 후 AWS에서 검토하는 데 보통 24시간 이내가 소요되지만, 케이스 내용에 따라 더 걸릴 수 있다. 승인 여부는 등록된 이메일로 통보된다.

승인 가능성을 높이는 요청서 작성법

AWS가 프로덕션 액세스 요청에서 실제로 보는 것은 세 가지다. 어떤 종류의 이메일을 보내는지, 수신자가 어떻게 수집되었는지, 바운스와 컴플레인을 어떻게 처리할 것인지다. 이 세 가지가 구체적으로 기술되어 있으면 반려 확률이 크게 낮아진다.

이메일 발송 시스템은 도로 위의 운전 면허와 비슷하다. 처음엔 제한된 구역에서만 운전할 수 있고, 실력과 책임감을 증명해야 일반 도로로 나올 수 있다. AWS가 보고 싶은 건 '얼마나 많이 보낼 것인가'가 아니라 '문제가 생겼을 때 어떻게 처리할 것인가'다.

항목부실한 답변 (반려 위험)구체적인 답변 (승인 가능성 높음)
메일 유형'마케팅 이메일을 보냅니다''주문 확인, 비밀번호 재설정 등 트랜잭셔널 이메일만 발송합니다'
수신자 수집'고객들에게 보냅니다''회원 가입 시 명시적 동의를 받으며, 더블 옵트인을 적용합니다'
바운스 처리'관리할 예정입니다''SNS + SQS로 바운스 알림을 수신하고, 하드 바운스 주소는 즉시 발송 목록에서 제거합니다'
컴플레인 처리언급 없음'컴플레인 피드백 루프를 설정하고, 컴플레인 발생 시 해당 주소를 즉시 억제 목록에 추가합니다'

바운스와 컴플레인 처리 — 프로덕션 전환 전에 반드시 설정해야 하는 것

프로덕션 전환 승인을 받았다고 끝이 아니다. 실제로 많이 보내다 보면 바운스율이나 컴플레인율이 올라가고, AWS 기준을 초과하면 발송이 일시 정지된다. 이 상황은 예고 없이 찾아온다.

SES는 바운스와 컴플레인 이벤트를 SNS 토픽으로 전달할 수 있다. 이 설정을 미리 해두지 않으면, 어떤 주소에서 문제가 발생하는지 파악조차 못한 채 발송이 중단되는 상황을 맞게 된다.

graph LR A["SES 이메일 발송"] --> B["수신 서버"] B -- "하드 바운스" --> C["SES 이벤트"] B -- "스팸 신고" --> C C --> D["SNS 토픽"] D --> E["SQS 큐"] E --> F["애플리케이션 처리 로직"] F --> G["억제 목록 업데이트 (SES / 자체 DB)"]
  1. SES 이벤트 발생: 이메일 발송 후 수신 서버에서 바운스 또는 수신자의 스팸 신고(컴플레인)가 발생한다.
  2. SNS 토픽 전달: SES가 해당 이벤트를 설정된 SNS 토픽으로 전달한다.
  3. SQS 큐 수신: SNS에서 SQS로 메시지가 전달되어 애플리케이션이 처리할 수 있다.
  4. 억제 목록 업데이트: 바운스/컴플레인 주소를 SES 억제 목록 또는 자체 DB에 추가하여 재발송을 방지한다.

SNS 알림 설정은 SES 구성 세트(Configuration Set)를 통해 이루어진다. 구성 세트 없이 이메일을 발송하면 이벤트 추적 자체가 되지 않는다.

aws sesv2 create-configuration-set \
  --configuration-set-name my-config-set \
  --region us-east-1
aws sesv2 create-configuration-set-event-destination \
  --configuration-set-name my-config-set \
  --event-destination-name bounce-complaint-handler \
  --event-destination '{
    "Enabled": true,
    "MatchingEventTypes": ["BOUNCE", "COMPLAINT"],
    "SnsDestination": {
      "TopicArn": "arn:aws:sns:us-east-1:123456789012:ses-bounce-complaint"
    }
  }' \
  --region us-east-1

실제 현장에서 겪은 패턴 — 승인 후 발송 중단

프로덕션 전환 승인을 받고 며칠 뒤, 갑자기 SES 발송이 중단됐다는 연락이 오는 경우가 있다. 콘솔을 열어보면 SendingEnabled: false 상태다. 처음엔 계정 문제나 결제 이슈를 의심하게 된다.

실제 원인은 대부분 바운스율 초과다. 오래된 이메일 목록을 정리하지 않고 대량 발송을 시작하면, 존재하지 않는 주소로 인한 하드 바운스가 급격히 쌓인다. AWS는 바운스율이 일정 임계값을 초과하면 계정 발송을 자동으로 일시 정지한다.

이 상태를 확인하는 방법은 간단하다.

aws sesv2 get-account \
  --region us-east-1

응답에서 SendingEnabled가 false이고 EnforcementStatus에 관련 내용이 있다면, AWS Support에 케이스를 열어 상황을 설명하고 억제 목록 정리 계획을 제출해야 한다. 자동으로 복구되지 않는다.

샌드박스 해제 이후에도 발송 목록 위생(list hygiene)을 유지하지 않으면 다시 같은 상황을 맞는다. 프로덕션 전환은 끝이 아니라 시작이다.

SES 억제 목록 확인 및 관리

SES에는 계정 수준의 억제 목록(account-level suppression list)이 있다. 바운스나 컴플레인이 발생한 주소는 이 목록에 자동으로 추가되며, 목록에 있는 주소로는 이메일이 발송되지 않는다. 이 동작을 모르면 특정 고객에게 이메일이 안 간다는 민원을 받고도 원인을 찾지 못하는 상황이 생긴다.

aws sesv2 list-suppressed-destinations \
  --region us-east-1

특정 주소를 억제 목록에서 제거하려면 아래 명령을 사용한다. 단, 제거 전에 해당 주소가 실제로 유효한지 확인하는 것이 선행되어야 한다.

aws sesv2 delete-suppressed-destination \
  --email-address user@example.com \
  --region us-east-1

SES 샌드박스 모드 — 마무리 및 다음 단계

SES 샌드박스 모드는 의도된 보호 장치다. 해제 자체는 어렵지 않지만, 해제 후 바운스/컴플레인 처리 체계를 갖추지 않으면 프로덕션에서 더 큰 문제를 만난다. 요청서를 제출하기 전에 SNS 알림 설정과 억제 목록 처리 로직을 먼저 구현해두는 것이 순서다.

핵심 용어 정리

용어설명
샌드박스 모드 (Sandbox Mode)SES 신규 계정의 기본 상태. 검증된 이메일/도메인으로만 발송 가능하며 일일 발송 한도가 제한된다.
이메일 검증 (Email Identity)SES에서 발신자 또는 수신자로 사용하기 위해 소유권을 확인하는 과정. 이메일 단위 또는 도메인 단위로 가능하다.
하드 바운스 (Hard Bounce)존재하지 않는 주소 등 영구적인 이유로 이메일 전달이 실패한 경우. 반복 발송 시 계정 평판에 직접 영향을 준다.
컴플레인 (Complaint)수신자가 이메일을 스팸으로 신고한 경우. 피드백 루프를 통해 SES에 전달된다.
억제 목록 (Suppression List)바운스/컴플레인이 발생한 주소를 자동으로 차단하는 계정 수준의 목록. 목록에 있는 주소로는 이메일이 발송되지 않는다.

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기