서론
출석체크 애플리케이션 프로젝트에 이메일 인증 시스템을 도입하기로 결졍했습니다.
목표는 대학교 교직원과 학생만 참여하도록 제한해서 외부 인원의 참여를 막고,
대학교 학생들만이 서비스를 이용하게 만드는 것이었습니다.
UnivCert API의 한계
대학교 이메일 인증 API, UnivCert
대학교 이메일 인증을 위해 관련 API를 탐색하던 중, UnivCert라는 서비스를 발견했습니다.
간단한 사용법 덕분에 인증을 쉽게 구현할 수 있어 해당 API를 선택했습니다.
하루 API 호출 제한 문제 발생
하지만 이후 구현 과정에서 생각하지 못한 문제를 발견했습니다
하루 API 호출량이 200회로 제한되어 있다는 것입니다!
해당 프로젝트의 행사기간 예상 API 호출 수는 5000회 이상입니다.
따라서 하루 200회 제한으로는 서비스 운영을 진행할 수 없습니다
대안 고민
현재 문제상황을 팀원에게 전달하였고, 대안을 고민하였습니다.
먼저 생각한 대안은 메일서버를 직접 구축하는 방법과
개인 이메일을 활용하여, SMTP 서버를 연결한 뒤 발송하는 방법이었습니다
하지만 해당 방식은 모두 무산되었습니다.
팀원이 준 피드백을 요약하면 다음과 같습니다.
메일 발송에는 평판시스템이 적용됩니다.
메일 서버를 직접 개발한다면, 평판시스템 때문에 차단될 가능성이 존재합니다.
개인 이메일을 이용하는 방식은 계정 정지 위험과 메일 발송 한도량 제한이 있습니다.
따라서 두가지 방법 모두 리스크가 너무 크기 떄문에 다른 대안을 찾아야 할 것 같습니다.
이메일 평판 시스템
팀원의 피드백 덕분에 평판시스템이라는 개념을 처음알게 되었습니다.
이메일 평판 시스템이란, ISP가 발송자의 이메일 품질을 평가하는 지표입니다.
발신자의 평판 점수에 영향을 미치는 대표적인 요소는 다음과 같습니다.
이메일 발송량
이메일 반송률
수신자의 스팸처리율
이메일 열람률
이외 많은 요소가 있지만, 발신자가 고려해야할 대표적인 요소로는 위와 같습니다
평판이 낮으면 스팸메일로 분류되거나 다른 서비스에서 차단될 가능성이 존재합니다.
또한 이메일 서버를 직접 구축하려면 개발 및 관리에 많은 시간이 필요합니다
따라서 이메일 서버를 직접 구축하는 방법은 선택지에서 제외했습니다
개인 이메일을 이용한다면?
Spring boot의 'spring-boot-starter-mail' 을 이용하면,
SMTP 메일 서버와 연결해서 메일을 발송할 수 있습니다.
즉, 개인 Gmail 계정을 연결하거나 다른 사이트의 개인 이메일 계정을 이용해서
이메일을 발송할 수 있습니다.
구현방법도 어렵지 않고, 서버에서 발송방법을 관리할 수 있기 때문에
기능 확장성도 고려할 수 있는 좋은 방법이라 생각했습니다.
하지만 해당 방법은 매우매우매우 위험합니다!
앞서 살펴본 평판시스템과 비슷하게 스팸 메일로 분류되고
이런 악영향이 누적된다면 개인 메일 계정이 정지될 수도 있기 때문입니다
또한 하루 메일 전송 한도량이 매우 적다는 문제도 겪고 있습니다.
Gmail 전송한도
Gmail은 하루에 최대 500개 메세지를 보낼 수 있으며,
유료 Google Workspace 계정을 사용하여 최대 2천개까지 메세지를 보낼 수 있습니다.
메일 발송 한도에 도달하면, 당일 발송이 차단되며 다음날 다시 발송할 수 있습니다.
Gmail 이용약관
전송한도를 초과하거나 스팸 메일로 인식될 경우, 계정이 정지될 수 있습니다
네이버 이메일 전송한도
하루 발송 한도는 정확히 알 수 없으나, Gmail과 비슷할 것으로 예상됩니다.
또한 스팸 메일로 분류될 경우 이용제한될 수 있습니다
다음 이메일 전송한도
다음 이메일은 조금 예외입니다. 하루 전송한도가 1만명입니다
하지만 스패머로 추정되는 경우, 이용이 제한되거나 하루 전송 한도가 다르게 적용될 수 있습니다.
종합
다음을 제외한 구글과 네이버는 하루 전송한도량이 매우 적으며,
스팸메일로 분류될 경우, 계정이 차단될 위험이 있습니다
개발자의 개인 이메일 계정이 차단되는 것은 원하치 않습니다.
따라서 개인 이메일로 발송하는 방법도 선택지에서 제외했습니다
이메일 발송 서비스의 발견
앞서 생각한 대안이 모두 무산되었기에 다시 새로운 해결책을 고민했습니다.
다음과 같은 도움으로 이메일 발송 서비스라는 키워드를 찾을 수 있었습니다.
팀원의 Firebase Authentication 사용 언급
Google Workspace 전송 한도 우회방법
두 과정에서 공통으로 외부 이메일 발송 서비스를 언급하고 있습니다.
따라서 외부 이메일 발송 서비스에 대해 탐색하였고,
앞선 대안의 문제점을 해결할 수 있는 최적의 선택지라고 판단하였습니다.
발송 한도해제 가능
개인 이메일 발송 방식의 문제점은 발송 한도량이 존재한다는 것이었습니다.
하지만 외부 이메일 발송 서비스는 비용만 부담한다면 발송한도 제한을 해제할 수 있습니다
효율적인 평판시스템 관리 지원
외부 이메일 발송 서비스에서는 대부분 반송메일, 스팸처리된 메일에 대한 분석 기능을
제공해주기 때문에, 평판 시스템에 대한 부담을 줄일 수 있습니다.
개인 이메일 차단 대처 방법 미존재
하지만 이메일 발송 서비스에서 개인 이메일을 사용한다면
스팸 계정으로 분류되어 차단될 가능성이 여전히 존재합니다.
따라서 개인 이메일에 의존하지 않는 방법을 고려할 필요가 있습니다.
도메인 이메일 사용
새롭게 발견한 방법은 개인 이메일로 발송하는 방법이 아닌,
도메인을 등록하여 이메일을 발송하는 것입니다.
이 방법을 사용할 경우, 개발자 개인에게 부담되는 리스크가 줄어듭니다
또한 확장성에서도 효과적인 방법입니다.
개인 이메일 계정이 정지될 경우 확장의 한계가 존재하며, 리스크 부담도 커집니다
하지만 도메인의 경우, 서브 도메인을 이용하여 쉽게 확장 가능하므로 유연하게 대처할 수 있습니다
이메일 발송 ip 확대 가능
만약 IP가 차단된다면 어떻게 대처할 수 있을까요?
IP Pool 방식을 이용하여,
사용중인 IP가 차단되었을 때 대체할 수 있는 전용 IP를 등록하여 대처할 수 있습니다
IP Pool도 많은 이메일 발송 서비스에서 제공해주는 방식입니다
AWS SES 선택
결과적으로 이메일 발송 서비스를 사용하여,
대학교 이메일 인증 시스템을 개발하는 것으로 결정되었습니다
남은 과제는 어떤 이메일 발송 서비스를 이용할 것인가 입니다.
가장 최적의 선택은 적은 비용으로 많은 이메일을 발송할 수 있으면서
평판 시스템을 관리할 수 있는 환경을 제공하는 서비스일 것입니다.
이 점을 고려했을 때, AWS SES가 가장 합리적이라고 판단했습니다.
AWS 프리티어인 경우 이메일 3천건 발송까지 무료이고
추가 이메일 발송도 1천건당 0.1$라는 합리적인 비용으로 이용할 수 있습니다.
또한 통계시스템과 평판지표를 제공해주기 때문에 평판시스템 관리도 용이하다는 장점이 있습니다.
유일한 문제점이 샌드박스 환경에서 프로덕션 환경으로 전환하는데 승인을 받아야한다는 점인데,
일단 개발환경은 샌드박스 환경만으로 큰 문제가 없기 때문에
프로덕션 환경 전환과정에서 문제가 생길 경우, 다시 대안을 찾는 방향으로 정리하였습니다.
종합하여, AWS SES를 현재 프로젝트의 이메일 발송 서비스로 선택하였습니다
개발 과정
AWS SDK를 이용하면, 쉽게 이메일 발송 서비스를 개발할 수 있습니다.
샌드박스 환경에서는 등록된 이메일로만 테스트할 수 있었기 때문에,
다중 사용자를 받는 환경은 프로덕션 전환 이후로 생각하고 일단 기능 구현에 집중했습니다
그 결과 AWS SES를 이용하여, 정상 작동하는 대학교 이메일 인증 시스템을 개발하였습니다
하지만...
우려했던 샌드박스 환경에서 프로덕션 환경으로 전환하는 과정에서 문제가 발생하였고...
다시 새로운 대안을 찾아야했습니다.
참고
