[AWS Hands-On] Supabase 이메일 6건 제한을 Route53, SES, SMTP로 해결한 기록

왜 이 설정을 하게 됐나

Mongle 웨딩 앱 프로젝트에서 회원가입 기능을 붙이면서 이메일 인증도 같이 만들고 있었다. 문제는 개발 단계에서 인증 메일을 계속 반복해서 보내야 한다는 점이었다. 회원가입, 로그아웃, 재가입, 비밀번호 재설정, 잘못 입력한 이메일 수정 같은 흐름을 조금만 확인해도 메일 발송 횟수가 금방 쌓였다.

그런데 Supabase 기본 이메일 Auth 전송은 하루에 6건 정도만 가능해서 몇 번 테스트하면 바로 막혔다. 실제 서비스 전인데도 답답한 수준이었고, 나중에 사용자가 붙으면 더는 기본 설정으로 버티기 어렵겠다는 생각이 들었다. 그래서 Supabase 기본 메일 발송 대신 직접 SMTP를 연결하는 방식으로 바꾸기로 했다.

SES만 붙이면 끝날 줄 알았는데 아니었다

처음에는 SES만 연결하면 금방 끝날 일이라고 생각했다. 그런데 막상 해보니 순서가 생각보다 길었다.

1. AWS를 유료 계정으로 전환한다.
2. Route53에서 도메인을 산다.
3. 도메인 DNS를 설정한다.
4. SES에서 발신 도메인을 검증한다.
5. SMTP 자격 증명을 만든다.
6. Supabase SMTP 설정과 연결한다.
7. 마지막으로 SES Sandbox를 해제한다.

즉, 단순히 메일 서비스 하나만 켜는 일이 아니라 도메인과 DNS부터 먼저 정리해야 하는 작업이었다. AWS를 만질 때 자주 느끼는 점인데, 기능 하나를 쓰려 해도 그 기능이 기대하는 전제 조건이 이미 깔려 있어야 한다.

Route53을 쓰려면 먼저 결제부터 해야 했다

가장 먼저 막힌 부분은 유료 계정 전환이었다. Route53에서 도메인을 구매하려면 당연히 결제 가능한 계정 상태가 필요했고, 그때부터 이 작업이 단순 테스트가 아니라 운영 환경 설정에 가깝다는 느낌이 들었다.

예전 같으면 무료 티어 안에서만 해결하려고 했겠지만, 이번에는 실제로 메일 인증 시스템을 굴려야 했기 때문에 결제를 피할 수 없었다. 결국 유료 계정으로 전환했고, Route53에서 evan-yoon.com 도메인을 1년 기준 15달러 정도에 구매했다.

도메인을 고를 때는 하이픈 유무와 .com, .dev, .site 같은 조합도 잠깐 둘러봤다. 그래도 가장 무난하고 설명하기 쉬운 건 역시 .com이었다. 서비스용 메일을 붙이려는 목적이 있었기 때문에 기억하기 쉽고 신뢰감 있는 쪽으로 정리했다.

도메인을 산 다음에 SES 설정이 이어졌다

도메인을 샀다고 바로 메일을 보낼 수 있는 것은 아니었다. SES에서는 이 도메인을 정말 내가 관리하고 있는지 먼저 확인해야 했다. 그래서 Route53에 생성된 도메인을 기준으로 SES 검증용 레코드를 연결하고, DNS가 전파되기를 기다려야 했다.

여기서 좋았던 점은 Route53과 SES를 같은 AWS 안에서 연결하니 동선이 비교적 단순했다는 것이다. 외부 DNS를 쓰는 상황이었다면 레코드를 복사해서 넣고 전파 상태를 따로 확인해야 했겠지만, 같은 콘솔 안에서 처리하니 훨씬 따라가기 쉬웠다.

SES SMTP를 Supabase와 연결했다

내가 원한 최종 구조는 단순했다.

• 실제 메일 발송은 AWS SES가 담당한다.
• Supabase Auth는 기존처럼 회원가입과 인증 흐름을 관리한다.
• 다만 메일 전송만 Supabase 기본 한도가 아니라 외부 SMTP를 타도록 바꾼다.

즉, Supabase를 버리는 것이 아니라 Supabase Auth + AWS SES SMTP 조합으로 재구성한 것이다. 이렇게 하면 앱 로직은 크게 흔들지 않으면서도 메일 발송 한도 문제를 우회할 수 있다.

SMTP 설정을 붙일 때는 서버 주소, 포트, 사용자 이름, 비밀번호 같은 값을 정확히 옮겨야 한다. 이런 연결 작업은 사소한 오타 하나로도 실패하기 때문에, 오히려 코드를 짤 때보다 더 천천히 보게 된다. 특히 비밀번호는 AWS 콘솔 로그인 비밀번호가 아니라 SMTP용 자격 증명이라는 점을 구분해야 했다.

가장 먼저 체감된 건 테스트 속도였다

이 설정을 한 이유는 거창한 대규모 메일 시스템 구축이 아니었다. 아주 현실적으로, 회원가입 인증을 마음 편하게 반복 테스트하고 싶었기 때문이다.

Supabase 기본 전송만 쓸 때는 메일 몇 번 보내고 나면 그날 테스트가 사실상 끝났다. 하지만 SES를 SMTP로 연결한 뒤에는 더 이상 “오늘 quota 다 썼나?”부터 걱정하지 않아도 됐다. 개발 흐름이 끊기지 않는다는 점 자체가 컸다.

결과적으로 하루 6건 정도만 가능하던 상태에서, 최종적으로는 하루 50,000건까지 보낼 수 있는 구조로 바뀌었다. 실제로 그만큼 보낼 일은 거의 없겠지만, 적어도 개발 중 테스트 때문에 발송 한도에 막히는 상황은 정리됐다.

의외로 오래 걸린 건 SES Sandbox 해제였다

여기까지 오면 끝난 줄 알았는데, 실제로는 SES Sandbox가 마지막 관문이었다. Sandbox 상태에서는 검증된 주소 위주로만 제한적으로 보낼 수 있어서 운영용 메일 시스템으로 쓰기 어렵다. 결국 제대로 쓰려면 별도로 해제 요청을 해야 했다.

이 단계가 인상적이었던 이유는 콘솔에서 몇 번 클릭하고 끝나는 일이 아니라, 사용 목적을 설명해야 하는 심사에 가까웠기 때문이다. 어떤 서비스에서 메일을 보내는지, 왜 필요한지, 스팸성 발송은 아닌지, 수신 동의 구조는 어떤지 같은 내용을 적어서 제출해야 했다.

영어와 일본어만 된다는 점도 조금 신기했다

Sandbox 해제 사유를 제출할 때 언어 선택이 영어와 일본어 위주라는 점도 인상적이었다. 보통 글로벌 서비스라면 영어만 있어도 이상하지 않은데, 일본어가 같이 보이는 구성이 조금 의외였다.

순간 “일본 사용자들은 영어를 많이 안 써서 그런가?”라는 생각도 들었고, 반대로 “AWS 안에서 일본 시장 비중이 그만큼 큰 건가?”라는 생각도 들었다. 정확한 이유는 모르겠지만, 한국어가 아니라 영어와 일본어가 같이 보인다는 점은 꽤 흥미로웠다.

결국 담당자와 직접 메일을 주고받았다

요청만 넣으면 끝날 줄 알았는데, 이후에는 담당자와 실제로 메일을 주고받으며 추가 설명을 했다. 어떤 서비스인지, Mongle 웨딩 앱에서 회원가입 인증용으로 사용하는 메일이라는 점, 반복 테스트와 향후 사용자 인증 메일 발송이 목적이라는 점, 그리고 악성 대량 발송이 아니라는 점을 분명히 설명했다.

이 과정에서 느낀 점은 AWS가 메일 발송 쪽에서는 꽤 보수적이라는 것이다. 생각해보면 당연하다. SES는 잘못 쓰이면 스팸 발송 도구가 되기 쉬워서, 신규 계정이 아무 설명 없이 대량 발송 권한을 얻는 구조보다 지금 방식이 더 맞다.

최종 결과: 메일 인증 테스트가 막히지 않게 됐다

정리하면 이번 작업으로 바뀐 것은 아래와 같다.

• Mongle 회원가입 이메일 인증을 Supabase 기본 메일 한도에 의존하지 않게 됐다.
• Route53에서 구매한 evan-yoon.com 도메인을 SES 발신 도메인으로 연결했다.
• SES SMTP를 Supabase Auth와 붙여서 인증 메일 발송 경로를 외부 메일러로 바꿨다.
• Sandbox 해제까지 마쳐 하루 50,000건 수준의 발송 한도를 확보했다.

개발자 입장에서는 “이메일 인증이 된다”보다 “이제 인증 메일을 마음 놓고 반복 테스트할 수 있다”가 더 큰 변화였다. 기능 하나를 구현하는 과정에서 도메인, DNS, 메일 인증, SMTP, 운영 승인 프로세스까지 한 번에 경험하게 된 셈이라 AWS Hands-On 기록으로 남기기에도 적당한 작업이었다.

마무리

처음에는 Supabase의 하루 6건 제한이 그냥 조금 불편한 정도라고 생각했다. 그런데 실제 프로젝트에서 회원가입 인증을 붙이고 반복 테스트를 하다 보니, 그 제한은 바로 개발 속도를 막는 병목이었다. 그래서 AWS SES를 직접 붙이게 됐고, 그 과정에서 Route53 도메인 구매, 유료 계정 전환, DNS 검증, SMTP 연결, Sandbox 해제까지 한 번에 경험하게 됐다.

결과만 보면 “하루 6건에서 50,000건으로 늘렸다”는 한 줄이지만, 실제 체감은 그보다 훨씬 컸다. 이제는 메일 인증 테스트를 할 때 발송 횟수부터 계산하지 않아도 되고, 나중에 실제 사용자 흐름으로 넘어가도 구조를 다시 뜯어고칠 필요가 없기 때문이다. 작은 설정 하나를 바꾼 것 같지만, 운영 환경에 한 발 더 들어간 느낌은 분명했다.

+ 4월 15일 업데이트

4월 15일에 evan-yoon.com 도메인이 suspended 되었다는 메일을 받고 꽤 놀랐다. 제목이 생각보다 강해서, 순간 내가 정책을 위반했거나 뭔가 큰 실수를 한 줄 알았다. 돈도 냈고 이미 Route53이랑 SES까지 연결해서 쓰고 있었기 때문에, 당연히 별문제 없이 유지되고 있다고 생각하고 있었기 때문이다.

얼른 메일 내용을 확인해보니 문제는 정책 위반이 아니라 이메일 인증 미완료였다. 메일에 첨부된 링크를 통해 AWS 콘솔로 들어갔는데, 안내받은 화면에서는 바로 인증할 수 있는 메뉴가 보이지 않았다. 결국 콘솔 안에서 인증 화면이 어디 있는지 직접 다시 찾아야 했고, 그 뒤에 인증 메일을 다시 보내서 확인 절차를 마무리했다.

인증을 마치고 나서 든 생각은 “내가 이걸 언제 놓친 거지?”였다. 그래서 메일함을 다시 살펴봤는데, 3월 30일 당시에는 관련 인증 메일이 온 기록이 보이지 않았다. 적어도 내가 확인한 범위에서는 그날 바로 처리할 수 있었던 단서가 없었다는 뜻이다.

이 경험이 조금 인상적이었던 이유는, 이런 부분은 문서만 읽어서는 체감하기 어려운 종류의 이슈라는 점 때문이다. 자동으로 메일이 와서 클릭만 하면 끝나는 줄 알았는데, 실제로는 사용자가 직접 인증 메일을 다시 보내고, 인증 화면도 찾아 들어가야 도메인 소유가 완전히 정리되는 구조였다. 이걸 모르면 나처럼 “돈을 냈으니 당연히 내 거겠지”라고 생각하고 넘어가기 쉽다.

결국 이번 일은 도메인을 샀다는 것과 도메인 소유 검증이 끝났다는 것이 같은 말이 아니라는 점을 확실하게 알려줬다. AWS Hands-On을 직접 해봐야 하는 이유가 바로 이런 데 있는 것 같다. 설정 자체보다도, 예상하지 못한 운영 이슈가 실제로 터졌을 때 어디를 봐야 하고 무엇을 다시 확인해야 하는지를 몸으로 배우게 되기 때문이다.