메일전송 기능 개발하면서 느낀점

가입인증용 메일전송기능 개발 사례

영프런 프로젝트에서 회원가입 API를 개발하면서 가입메일 전송을 개발해야했습니다.
메일전송 전용서비스(SendGrid, Mailgun), smtp 프로토콜, AWS SES 등의 방법중 smtp 프로토콜 방식을 선택한 이유는 아래와 같습니다.

• 비용이 무료이며 가장 익숙하고 간단한방식 입니다.

• 기업용이 아닌 개인 메일로 발신할 수 있는 개수가 일일 500개라는 제한(기업용 이메일의 경우 2000개)이 있지만, 실제 사용자를 받으려는 프로젝트가 아니었기에, 토이프로젝트임을 가정하면 충분하다고 판단하였습니다.

  • 혹여나, 예정과 다르게 실 서비스로 운영되어 더 많은 메일을 보내야 한다면 여러 gmail 계정을 만들어 메일 한도초과 예외를 try-catch로 잡아 세컨계정으로 메일전송 해주는 방법이있습니다. 하지만 이 방법은 코드의 복잡도를 고려했을때 일일 1000개정도의 메일전송까지만 커버하는것이 좋아보입니다.
  • 일정 비용을 지급하여 GMass을 이용해 일일 최대 10,000명의 수신자로 늘릴 수 있습니다.

잠재적 문제

메일서버에 문제가 생겨 메일전송에 문제가 생기더라도 사용자가 재요청하지 않게끔 하려는 요구사항이 있었기 때문에 한번 요청한 가입메일전송은 메일서버에 문제가 발생하더라도 어떻게든 전송이 되어야하는 상황이었습니다.

결론적으로, 이 문제를 해결하기 위해 retry를 도입하게 되었는데 도입하게 된 배경과 구체적인 구현과 개선사항은 여기서 확인가능합니다.

문제 인식 후 우선순위를 고려해 해야할 일을 조절한 사례

20초 내에 4번의 retry를 거치는 방식으로 retry를 구현하고 나서 메일서버의 큰 장애상황이라면 retry를 시도하는것 조차 오버헤드가 아닐까?라는 의구심이 들었습니다.

해결방법을 탐색하던중 fallback과 서킷브레이커 라는 키워드를 알게되었으나 공부하고 구현을 시도해보기전에 아래와 같은 생각을 먼저 했습니다.

• 내 프로젝트에서 정말로 일어날 수 있는 일인가?
• 과연 이런 문제가 일어난다면 정말 사용자에게 치명적인걸까?
• 일정 내에 가입메일전송 보다 사용자가 가장 많이 몰릴 인기글 조회관련 부분을 먼저 개선해야하지 않을까?

위 사고를 거쳐 문제가 될수있는 부분을 잠재적으로 인식만 해두고 기록을 해둔뒤 다른 작업을 수행하게 되었습니다.

느낀 점

• 요구사항을 해결하기위한 여러 솔루션들을 탐색했을 때, 다양한 옵션들을 매번 일일히 하나씩 테스트 해볼 수 없다는것을 느꼈습니다.

  • 예를들면, AWS SES, Sendgrid같은 메일전송 서비스는 이번에 처음 알게되었고 조사과정에서는 이론적인 장/단점 부분에 대해서만 알수밖에 없었습니다.

  • 좋은 제품을 만드려면 적극적으로 의견을 제시할줄도 알아야하는데, 위와같은 상황이라면 AWS SES같은 메인전송 서비스를 도입해보려고한다. 어떻게 생각하니? 라고 한다면 이론적인 이야기말고는 적극적으로 내세울만한 근거가 저에겐 없었습니다.

  • 위와같은 문제를 극복하기위해선 해당 방법을 사용해 본 경험이 있는 사람과 SMTP 프로토콜로 구현했을땐 나는 어떤 장단점이 있었는데 AWS SES는 어땠는지 등의 노하우를 들어보거나, 사이드 프로젝트에 직접 적용해보는 방법이 있을것 같다는 생각이 들었고 꾸준한 학습과 경험, 그리고 주변에 개발이야기를 할수있는 사람들과 커뮤니케이션의 중요성을 깨달았습니다.

• 우선순위를 먼저 고려한후 해결방법을 찾는게 아니라 해결방법을 탐색/구현하고 나서 우선순위를 고려하는 실수를 했습니다.

  • 프로젝트 내에서 트래픽이 가장 몰리는 API는 인기글에 대한 조회 API였어서 그쪽에서 조금더 고민하는 시간을 가졌어야 했는데 메일 전송을 개발하면서 생길수있는 다양한 상황들에대한 가정을 먼저 생각하다보니 시간분배에 실패했고 생각했던 것 보다 일정이 길어졌습니다.

  • 이번 프로젝트를 계기로 다양하게 생각하는것은 물론좋지만, 우선순위를 먼저 고려하는 것의 중요성을 직접 깨달았습니다.