출석체크 애플리케이션 프로젝트를 하면서, 경험한 고민과 해결과정에 대한 글입니다
이번에는 AWS SES에서 Mailgun으로 전환한 과정에 대한 내용입니다.
발단: AWS SES 프로덕션 전환 요청 반려
Free-tier로 비용절감 + 100달러 크레딧이 있는점을 고려하여 AWS SES를 사용했습니다.
개발 과정에서는 많은 이메일을 발송하지 않기 때문에, 샌드박스 환경에서 테스트를 진행했습니다
AWS SES SandBox 상태란?
AWS SES의 기능은 모두 사용할 수 있지만, 사용량은 제한된 상태입니다.
하루에 200개 메일만 발송 가능하며, 등록된 사용자만 주고받을 수 있습니다
또한 동시 발송 이메일 수도 제한됩니다.
AWS SES 이메일 발송 서비스 개발과 테스트가 순조롭게 완료되었고,
운영환경을 고려한 AWS SES 프로덕션 전환만을 앞두고 있었습니다.
AWS SES 샌드박스 환경에서 프로덕션으로 전환하려면
AWS에 승인 요청을 보낸 뒤 프로덕션 전환 요청이 허가되어야 합니다.
처음에는 한글로 1000자 정도 작성하여 승인 요청을 전달했습니다
첫번째 요청: 반려
첫번째 요청은 반려되었습니다.
요약하면, AWS에 좋지 않은 영향을 미칠 수 있기 때문에 허용하지 않는다는 내용이었습니다.
원인 분석
첫번째 요청은 반려될 것을 예상했습니다.
이미 신청하기 전에 프로덕션 전환 심사는 쉽게 통과할 수 없다는 글을 많이 보았기 때문입니다.
반려 사유를 분석하고 다시 작성했습니다
먼저, 한글로 보냈기 때문에, 영어권 관리자 입장에서는 불편할 수 있을 것이라 생각했습니다.
따라서 두번째 요청에서는 영어로 내용을 작성했습니다
두번째는, 디테일한 정보가 부족해서 반려됐을 수 있겠다는 생각을 했습니다
따라서 두 번째 요청에서는 더 자세하게 적어서 8천자를 넘기는 내용을 작성했습니다
내용도 디테일하게 작성했고, 영어로도 작성했으니
두 번째는 무난히 통과할 것이라는 생각으로 승인 요청했습니다
두 번째 요청: 반려
하지만 기대와는 다르게 두 번째 요청도 반려됐습니다
이번에 받은 응답도 결국 똑같은 의미로 승인을 거부한다는 의미인데,
첫번째 응답과는 다르게 두번째 응답에서는
이후 요청에도 절대 승인하지 않겠다는 느낌을 받았습니다
요청한 서비스에서 AWS SES를 이용할 경우,
발송 도메인에 평판 시스템에 악영향을 미칠 가능성이 크고
다른 AWS 서비스까지 사용할 수 없을 것이라는 내용이 포함되어 있었기에
승인 받을 수 없다는 느낌을 크게 받았습니다
느낌은 느낌일 뿐, 승인해줄 때까지 프로젝트를 보완해서 다시 요청해야할까?
다른 서비스로 전환해야하나?
위험하더라도 개인 이메일 시스템을 사용할까?
두 번째 반려 요청을 받고 많은 고민을 하였습니다
전개: 새로운 선택의 순간
선택할 수 있는 방법을 세 가지로 정리했습니다.
1. 승인해줄때까지 AWS SES에 요청을 보낸다
2. 다른 이메일 발송 서비스로 전환해서 사용한다
3. 내 개인 이메일로 직접 발송하는 메일 서버환경을 구성한다
혼자서 어떤 선택을 해야할까 고민했습니다.
관련 자료도 알아보고, 더 나은 선택지가 없을까에 대한 고민도 했습니다.
하지만 이 프로젝트는 팀 프로젝트이고, 팀원의 도움을 받을 수 있습니다.
혼자 고민하는 것보다 여러명이 고민하는 것이 더 좋은 성과를 낼 수 있기 때문에,
팀원에게 문제상황을 전달하고 해결방법에 대한 논의를 진행했습니다
3번은 탈락!
제일 먼저 후보에서 지운 것은 3번이었습니다
개인 이메일을 사용하는 것은 발송한도량 제한도 있고, 스펨계정으로 분류되어 정지될 수 있습니다
개인 이메일이 차단되는 것은 생각도 하기 싫기 때문에 제외했습니다
1번 선택지 VS 2번 선택지
이제 두 가지 선택지만이 남았습니다.
먼저 각 선택지를 선택했을 때의 장단점을 만들어 놓고 비교했습니다
| 1번 선택지 (AWS SES) | 2번 선택지 (다른 서비스) | |
|---|---|---|
| 장점 | - 추가개발 없음, 비용 발생 적음 | - 승인 신청 불필요 |
| 단점 1 | - 승인까지 대기시간 발생 | - 추가 개발, 탐색 필요 |
| 단점 2 | - 승인여부 미확정 | - 추가 비용 발생 가능성 존재 |
팀원과 상의한 결과,
"기약없이 기다리는 것보다 비용이 발생하더라도 빠르게 다른 서비스로 전환하는 것이
프로젝트 완성에 도움이 될 것이다"
라는 결론을 내렸습니다.
따라서 2번 선택지를 선택했습니다
새로운 이메일 발송 서비스 탐색
이메일 발송을 지원해주는 새로운 발송 서비스를 찾기 시작했습니다.
일단 사용할 수 있는 발송 서비스를 최대한 찾은 뒤,
우선순위를 매겨서 최적의 발송 서비스를 선택하기로 결정했습니다
찾은 발송 서비스는 다음과 같습니다
- Mailgun
- Firebase Authentication
- Forward Email
- ImproveMX
- 다음 스마트워크
- 네이버 라인웍스
총 6가지 찾았습니다. 아마 시간을 더 두고 찾았으면, 6개보다 더 많이 찾았을 것 같습니다
우선순위 계산
이어서 우선순위를 산정하는 방식에 대해 팀원과 논의했습니다
프로젝트 완성까지 남은 시간과 운영상황을 고려했을 때,
최적의 판단이 되도록 몇 가지 기준을 만들었습니다
- 이메일 발송 한도 초과 차단 여부
- 발송 허용량 대비 비용
- API 학습/구현 난이도
- 문서화 여부
- 사용 승인 대기 여부
우선순위 기준을 세운 뒤, 세부 분류가 필요한 항목에 대해서는 상중하로 분류했습니다
상이 제일 좋은 조건이고 하가 제일 안 좋은 조건입니다
| 발송 허용량 대비 비용 | API학습/구현 난이도 | |
|---|---|---|
| 상 | 비용 X ~ 5$ | Gradle 의존성 지원 + API 사용 복잡도 낮음 |
| 중 | 5$ ~ 15$ | Java API 사용 방법 제공 + API 사용 복잡도 보통 |
| 하 | 15$ 초과 | API 사용 복잡도 높음 + 사용방법 미제공 |
1번과 4번은 단순 존재 여부에 따라 O, X로 나뉘기 때문에 세분화하지 않았습니다.
1번과 4번은 1점과 0점으로 나눴으며,
2번과 3번은 상중하 순서대로 3, 1, 0점을 점수로 설정했습니다.
5번은 매우 중요한 항목으로,
만약 AWS SES와 동일하게 승인하는 절차를 밟아야 한다면
부적격으로 선택지에서 제외하도록 설정했습니다.
이어서 우선순위 기준 여부를 중심으로 정보를 수집하였고, 기준에 따라 평점를 매겼습니다
우선순위 평가표 작성
아래는 팀원과 의논하여 작성한 우선순위 평가 표입니다.
첫 평가표를 작성했을 때, 가장 우선순위가 높은 이메일 발송 서비스는
Firebase Authentication 이었습니다
위기: Firebase Authentication 선택
Firebase SDK 의존성을 Gradle에 추가해서 간편하게 사용할 수 있으며,
Blaze 요금제로 비용을 절감할 수 있기 때문에 최적의 선택지였습니다!
하지만 Firebase SDK는 이 프로젝트에서 선택되지 않았습니다.
이유는 다음과 같습니다
1. 이메일 인증을 위해서는 Firebase에 사용자를 등록해야합니다.
해당과정에서 불필요한 추가 데이터가 필요했습니다 (비밀번호)
2. 사용자 데이터 관리 포인트가 Spring boot서버와
Firebase 두곳으로 나뉘어져 관리가 복잡해졌습니다
3. 반송 메일 관리 서비스를 제공하지 않습니다.
프로젝트는...
해당 프로젝트는 서버의 DB에서 회원 데이터를 관리하고,
요청에 대한 회원가입/로그인 여부도 서버에서 판단합니다.
이메일 발송 서비스는 인증에 대한 역할을 하지 않고,
서버의 메일 탬플릿을 발송하는 기능만 제공하도록 계획했습니다.
Firebase Auth는...
Firebase Authentication의 이메일 인증 방식은 위 설계와 방향이 맞지 않습니다.
해당 서비스는 회원가입 과정에서 유저데이터를 Firebase에 등록한 뒤,
이후 로그인에서 해당 데이터를 가지고 Firebase에서 인증하는 로직입니다.
이렇게 될 경우, Firebase와 Spring boot 서버에서
유저 데이터를 관리하기에 생각해야할 관리포인트가 늘어납니다.
또한 회원을 등록하는 과정에서 비밀번호가 필요합니다.
이메일 인증 방식을 도입한 이유 중 하나가 비밀번호 관리에 대한 고민을 없애기 위함이었는데,
Firebase Authentication을 사용할 경우, 고민해야할 포인트가 오히려 늘어났습니다.
마지막으로 반송 메일에 대한 자체적인 서비스를 제공해주지 않습니다.
도메인에 대한 평판도 고려하여 반송 메일 관리가 필요한데,
해당 서비스에서는 제공해주지 않아 추가적인 개발을 고민해야합니다.
결론
프로젝트의 방향성에 따라 매력적인 선택지가 될 수 있겠지만,
현재 진행하는 프로젝트의 방향성과는 맞지 않은 서비스라고 생각했습니다.
AWS SES 고민을 해결하기 위해 더 많은 고민을 해야하는 것은 알맞지 않다고 생각했고,
다른 서비스로 전환하는 것에 대해 고민했습니다.
두 번째 선택지 고민
Firebase Auth를 포기하게 된다면 남은 선택지는 두가지입니다.
우선순위 점수가 동률인 Mailgun과 Forward Email입니다.
두 후보 선택지 중 최종 선택을 위해 몇가지 비교사항을 두고 다시 고민했습니다.
1. 관리 서비스 UI
2. 구현 복잡도
구현 복잡도에 대해 비교할 당시에는
Mailgun은 API를 제공해주기 때문에 편하게 구현할 수 있지만
ForwardEmail은 okhttp를 이용해서 복잡하게 구현하는 방식이라서 Mailgun에 힘을 실어줬습니다
다만 이후, openfeign 방식으로 전환되어서... 구현복잡도 측면은 큰 의미가 없어졌습니다.
그 다음은 관리 서비스 UI에 대해 확인했습니다.
처음에는 메일 발송 서비스를 이용하는 만큼
반송 메일 관리와 이용량 분석 등에 대한 기능을 제공받을 수 있는지를 고려했습니다.
하지만 해당 기능은 두 서비스에서 모두 제공해주기 때문에,
관리를 돕는 편리한 UI 제공여부를 고려하여 서비스를 선택하기로 했습니다.
그 결과 두 서비스를 비교했을 때,
팀의 선택은 직관적인 UI로 통계정보를 제공하는 Mailgun이었습니다.
결말: Mailgun 선택
여러 서비스를 비교한 끝에 Mailgun 서비스가 선택되었습니다.
추가로 팀원의 Mailgun 계정에 가격 인상 전 9$ 가격으로 결제해둔 내역이 있어서
15$ 라는 비용도 9$로 절감할 수 있었습니다!
결과
Mailgun 서비스로 전환한 뒤에도
기존 AWS SES 서비스를 이용할 때처럼 정상적으로 작동했습니다.
이제 발송 한도량 제한도 해제되었고, 서비스에 등록하지 않은 이메일로도 발송이 가능해졌습니다
따라서 운영환경에서도 해당 메일 인증 서비스를 정상적으로 사용할 수 있게 되었습니다
마치며
AWS SES 반려 메일을 두번이나 받고 걱정 많이했는데, 좋은 결과가 나와서 다행입니다!
특히 팀원과 협업하여, 이뤄낸 성과라서 그런지 더 기쁘네요 ㅎㅎ
이번에 해결한 방법은 앞으로도 잘 활용할 수 있을 것 같습니다
"다수의 선택지가 있을 때는 우선순위 기준을 세운 뒤 평가해서 최적의 방법을 선택하자!"
"프로젝트 고민은 혼자 하지 말고 팀원과 함께하자!"
이 두 가지를 크게 배울 수 있는 과정이었습니다!
참고
