모든 제품은 언젠가 이메일을 보내야 하고, 가장 먼저 부딪히는 질문은 코드가 메일 시스템과 어떻게 통신해야 하느냐입니다. 답은 두 가지입니다. SMTP로 직접 통신하거나, HTTPS로 이메일 API를 호출하는 것입니다.
둘 다 작동합니다. 하지만 애플리케이션에 요구하는 것이 매우 다르며, 올바른 선택은 코드가 어디에서 실행되는지, 그리고 메일 관련 인프라를 얼마나 직접 관리하고 싶은지에 달려 있습니다.
SMTP의 강점
SMTP(Simple Mail Transfer Protocol)는 1980년대 초부터 메일 서버들이 이메일을 주고받아 온 방식입니다. 모든 메일함 제공업체가 지원하며, 거의 모든 프레임워크에 SMTP 메일러가 내장되어 있습니다. Nodemailer, Django의 send_mail, Laravel Mail, Rails의 Action Mailer 등입니다.
강점:
- 범용성. 모든 이메일 계정과 모든 언어에서 사용할 수 있습니다.
- 벤더 종속 없음. 호스트 이름과 비밀번호만 바꾸면 제공업체를 변경할 수 있습니다.
- 자체 도메인과 평판. 메일은 여러분이 관리하거나 임대한 서버를 통해, 여러분 도메인의 주소에서 발송됩니다.
앱 안에서 SMTP가 불편한 이유
SMTP는 주고받는 메시지가 많은 상태 기반(stateful) 프로토콜입니다. 메시지 하나를 보내려면 앱이 TCP 연결을 열고, 서버에 인사하고, TLS로 업그레이드하고, 인증한 다음, 발신자, 수신자, 데이터에 대해 일련의 명령과 응답을 주고받아야 합니다. 각 단계가 모두 네트워크 왕복입니다.
실제로는 다음과 같은 문제가 생깁니다.
- 느린 요청. 멀리 있는 서버와의 핸드셰이크만으로도 메시지 전송이 시작되기 전에 수백 밀리초가 걸릴 수 있습니다.
- 차단된 포트. 많은 클라우드 플랫폼과 서버리스 런타임은 스팸 방지를 위해 아웃바운드 25, 465, 587 포트를 제한합니다. 443 포트의 HTTPS는 거의 차단되지 않습니다.
- 곳곳에 흩어진 인증 정보. 메일을 보내는 서비스마다 메일함 비밀번호가 필요합니다. 비밀번호를 바꾸려면 모든 서비스를 다시 배포해야 합니다.
- 부족한 가시성. 문제가 생기면 오류는 한 서비스의 로그에만 남습니다. 그나마 로그가 남았다면 말입니다.
이메일 API가 바꾸는 것
이메일 API는 발송을 JSON 본문을 담은 HTTPS 요청 하나로 감쌉니다. 코드는 POST 한 번을 보내고 상태 코드를 돌려받습니다. SMTP 연결과 인증 정보는 API 서비스가 보유합니다.
강점:
- 컨테이너, 서버리스 함수, 엣지 런타임, CI 작업 등 어디에서든 443 포트로 빠른 요청 한 번.
- 비밀번호 대신 키. 각 서비스가 제한된 권한을 가진 자체 API 키를 받으며, 다른 키에 영향 없이 하나만 폐기하거나 교체할 수 있습니다.
- 중앙 집중식 가시성. API 호출과 전달 결과를 한곳에서 추적합니다.
- 단순한 HTTP 오류.
401이나429는 스택 트레이스 깊숙이 묻힌 SMTP 응답 코드보다 훨씬 다루기 쉽습니다.
트레이드오프: 대부분의 이메일 API에서는 메일이 그들의 서버를 통해 나가므로, 그들의 발신 도메인 설정과 IP 평판을 따르게 되고, 나중에 옮기려면 다른 곳에서 모든 것을 다시 인증해야 합니다.
Inbixio: SMTP 서버 앞에 놓인 API
Inbixio는 단순한 아이디어에서 출발했습니다. SMTP에서 가치 있는 부분, 즉 자체 메일 서버와 발신자 신원은 유지하고, 애플리케이션 안에서 불편한 부분만 대체하는 것입니다.
- 대시보드에서 SMTP 서버를 한 번만 연결합니다. 호스트, 포트, 사용자 이름, 비밀번호를 입력합니다.
- 서비스는 Inbixio API 키로
POST /api/send-email/를 호출합니다. - Inbixio가 TLS로 SMTP 서버에 로그인하고 여러분의 주소에서 메시지를 전달합니다.
- 대시보드에서 발송 수, 전달 실패율, 전달 지연 시간과 모든 API 호출 로그를 확인할 수 있습니다.
curl -X POST https://backend.inbixio.com/api/send-email/ \
-H "X-API-Key: $INBIXIO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'이를 통해 얻는 것:
- SMTP 비밀번호는 한곳에만 저장됩니다. 서비스들은 API 키만 다룹니다.
- 키를 특정 서버 하나에 고정할 수 있으므로, 결제 서비스는
billing@에서, 인증 서비스는security@에서 발송합니다. - 각 키의 권한이 명시적이며, 메일 서버에 손대지 않고 키를 갱신하거나 삭제할 수 있습니다.
- 발신 도메인, 제공업체, 평판을 그대로 유지합니다. 메일 제공업체를 바꾸더라도 서버 항목 하나만 수정하면 되고, 코드는 전혀 바뀌지 않습니다.
한눈에 비교
| SMTP 직접 연결 | 일반적인 이메일 API | Inbixio | |
|---|---|---|---|
| 앱에서의 전송 방식 | SMTP, 25/465/587 포트 | HTTPS, 443 포트 | HTTPS, 443 포트 |
| 메시지당 호출 | 여러 번의 왕복 | 요청 한 번 | 요청 한 번 |
| 서비스에 두는 인증 정보 | 메일함 비밀번호 | API 키 | API 키 |
| 발송 경로 | 자체 메일 서버 | 제공업체의 서버 | 자체 메일 서버 |
| 제공업체 변경 | 모든 곳의 설정 변경 | 도메인 재인증, 코드 변경 | 서버 항목 하나 수정 |
| 전달 가시성 | 직접 구축한 만큼 | 제공업체 대시보드 | Inbixio 대시보드: 발송 수, 실패율, 지연 시간, API 로그 |
그래서 무엇을 써야 할까?
- 아웃바운드 SMTP가 허용된 서버에서 작은 앱 하나를 운영하고, 그곳에서 인증 정보를 관리해도 괜찮다면 SMTP를 직접 사용하세요.
- 여러 서비스를 운영하거나, SMTP 포트를 차단하는 플랫폼에 배포하거나, 중앙 집중식 로그가 필요하거나, 메일함 비밀번호를 여기저기 전달하고 싶지 않다면 이메일 API를 사용하세요.
- API의 장점을 누리면서도 메일은 계속 자체 메일 서버와 도메인을 통해 보내고 싶다면 Inbixio를 사용하세요.
직접 써 보시겠어요? 5분 빠른 시작 가이드로 가입부터 이메일 전달까지 바로 경험할 수 있습니다.
