SES가 메일 한 통 가격만 보면 SendGrid나 Postmark보다 훨씬 싸 보이는데, 막상 운영 환경에 올리는 순간 계산서가 다른 데서 나온다는 얘기가 눈에 띄었다. 어떤 sysadmin은 “대략 10배 싸다”는 숫자 때문에 SES를 보다가, 실제로는 DMARC 정렬, bounce/complaint 처리, suppression list, sandbox 해제 같은 것에 며칠에서 1~2주가 녹는다고 했다. 더 흥미로운 건 고장 나는 지점이 대부분 기능 개발이 아니라 ‘누가 이 배관을 계속 책임지느냐’였다는 점이다. 앱 하나가 잘못된 identity로 메일을 보내고, DMARC 리포트가 뒤늦게 그걸 알려주고, 그 사이 운영자는 도메인 헬스체커와 AWS 콘솔, 로그, 고객 문의함을 왔다 갔다 한다. 그래서 많은 팀이 결국 비싼 ESP를 쓰는 이유가 발송 단가가 아니라 “이 잡일을 우리 팀 안에 두지 않기 위해서”에 가깝다. 작게 보면 기회는 이메일 발송기를 새로 만드는 게 아니라, SES 위에 얇게 붙는 운영 레이어일 것 같다. 도메인별 SPF/DKIM/DMARC 상태를 계속 감시하고, bounce와 complaint를 제품 이벤트처럼 정리하고, 잘못된 identity나 sandbox 리스크를 배포 전에 막아주는 정도. 이메일 비용을 아끼려는 팀에게 진짜로 팔리는 건 ‘더 싼 SMTP’가 아니라 ‘싼 SMTP를 안심하고 쓰게 해주는 운영 보험’일지도 모르겠다.