Helo — 전 Postmark 팀이 만든 독립 이메일 API

AI 요약

Helo는 애플리케이션에서 비밀번호 재설정 메일, 영수증, 알림, 뉴스레터 같은 트랜잭션·마케팅 이메일을 보내는 개발자용 서비스입니다. Postmark에서 함께 일했던 팀원들이 만들었으며, 부트스트랩 방식으로 운영하고 독립성을 유지하겠다고 밝혔습니다.

플랫폼의 테넌트별 발송 지원

Helo는 고객사를 대신해 이메일을 발송하는 멀티테넌트 플랫폼을 겨냥합니다. 고객 한 곳의 스팸 발송이 다른 고객의 전달률까지 떨어뜨리지 않도록 발신자를 분리하고, 고객별 도메인 발송과 통계·수신 거부·인증 정보를 따로 관리합니다. 도메인, 웹훅, 인증 정보가 테넌트와 맺는 관계도 유연하게 설정하도록 설계했다고 설명합니다.

기본 기능으로 REST API와 SMTP, Ruby·JavaScript·C#·Python·Go SDK를 제공합니다. 트랜잭션 메일과 대량 발송 메일은 전달률 최적화를 위해 인프라를 분리합니다. 이벤트 로그, 통계, 웹훅, 억제 목록, 수신 거부 관리, 세밀한 권한 설정도 지원합니다. 모든 기능을 포함한 사용량 기반 요금은 이메일당 0.00035달러부터 시작합니다.

Product Hunt 반응

• @bettina_specht1 — 안녕하세요, Product Hunt 여러분. 저는 Helo를 함께 만든 Bettina입니다. Helo는 애플리케이션에서 트랜잭션 및 마케팅 이메일을 보내는 API입니다. 비밀번호 재설정, 영수증, 알림, 뉴스레터 등을 보낼 수 있습니다. 팀원 대부분은 Postmark에서 여러 해 함께 일했기에 안정적인 이메일 서비스를 만드는 데 필요한 일을 잘 압니다. 좋아하던 제품이 인수되는 모습을 지켜본 적이 있다면 그 뒤 이야기도 아실 겁니다. 우리가 잘하는 제품을 계속 만들고, 배운 점을 반영해 개선하고, 고객을 잘 돌보면서 독립성을 유지하려고 Helo를 시작했습니다. 부트스트랩으로 운영하며 앞으로도 그 방식을 유지할 계획입니다.

개발자용 이메일 서비스에서 기대하는 기능을 제공합니다. REST API와 SMTP, Ruby·JavaScript·C#·Python·Go SDK가 있고 SDK는 더 추가할 예정입니다. 트랜잭션 메일과 대량 발송 메일의 인프라를 나눠 두 유형의 전달률을 각각 최적화합니다. 이벤트 로그, 통계, 웹훅, 억제 목록, 수신 거부, 유연한 권한 설정도 지원합니다. 임의로 기능을 제한하지 않는 사용량 기반 요금제를 적용합니다.

여기에 더해 멀티테넌트 발송을 완전히 지원하도록 설계했습니다. 대부분의 이메일 서비스는 한 회사가 자기 고객에게 이메일을 보내는 일반적인 상황을 기준으로 만듭니다. 하지만 플랫폼에서 고객을 대신해 발송한다면 이야기가 달라집니다. 예를 들어 음식점 관리 도구에서 음식점 주인이 뉴스레터를 보내게 하려면 여러 문제가 생깁니다. 고객 한 곳이 스팸을 보내면 어떻게 감지하고, 그 발송자가 제품 전체의 전달률을 망치지 않게 할까요? 고객이 자기 도메인으로 쉽게 발송하게 하려면 어떻게 해야 할까요? 음식점 A의 뉴스레터를 수신 거부한 사람이 음식점 B의 메일은 계속 받게 하려면 어떻게 해야 할까요? 이런 문제는 더 있습니다. Helo는 각 테넌트의 도메인, 웹훅, 인증 정보 등의 관계를 유연하게 설정하면서 이 문제들을 해결하도록 만들었습니다. 멀티테넌트 발송을 구축해 본 분들은 무엇이 가장 힘들었나요? 이메일 서비스가 대신 처리해 주길 바랐지만 직접 만들어야 했던 기능이 있나요? 의견을 듣고 싶습니다. Helo도 한번 사용해 주시면 좋겠습니다.

↳ @singh_abinashi — 가장 힘들었던 건 발신 평판 격리였습니다. 한 테넌트가 품질이 나쁜 목록에 대량 발송하면 다른 테넌트의 전달률까지 떨어집니다. 테넌트별 억제 목록과 문제가 되는 발신자를 위한 별도 하위 계정으로 해결했지만, 테넌트별 반송 및 스팸 신고 처리는 아무도 만들고 싶어 하지 않는 번거로운 작업입니다.

• @petrkovacik — 전 Postmark 팀원들이 다시 이메일 API를 만들다니 좋네요 📬 전달률은 무엇을 다르게 하시나요?
• @alan_tippins1 — Helo 팀 축하합니다! 제 프로젝트에서 써보길 기대합니다.
  • @rkaczanowski — 감사합니다! 🧡
• @galdayan — 부트스트랩으로 시작해 독립성을 유지한다는 말이, Postmark가 인수되는 일을 지켜본 뒤라 더 와닿네요. 테넌트별 격리는 고객별 전용 IP를 쓰나요, 아니면 발신자별 평판을 관리하는 공유 풀을 쓰나요? 공유 풀이 운영 비용은 훨씬 낮지만 내부적으로 잘 추적해도 나쁜 테넌트 하나가 실제로는 풀 전체에 영향을 줄 수 있어서 여쭤봅니다.
  • @rkaczanowski — 좋은 질문입니다! 예전 Postmark 시절처럼, 제공업체가 깨끗한 공유 IP 풀을 관리할 책임이 있다고 생각합니다. 제공업체가 그 책임을 다하지 않고 고객에게 전용 IP를 팔려는 경우가 너무 많습니다. 전용 IP도 잘못 쓰면 오히려 전달률을 해칠 수 있어 만능 해결책은 아닙니다. 주요 ISP 전반에서 고객의 발송량이 매우 큰 경우에만 자체 전용 IP를 쓰는 편이 타당합니다. 질문으로 돌아가면, Helo의 멀티테넌트 발송 기능인 ‘Channels’를 쓸 때 각 채널은 공유 풀 안에서 별도 발송 경로를 받습니다. 여러 고객의 발송이 단일 계정에 합쳐져 평판을 떨어뜨리고 나쁜 발신자가 묻히지 않도록 채널별 발신자를 미리 감지하는 도구도 만들었습니다. 이메일이 받은편지함에 도착하도록 하는 일은 궁극적으로 저희 책임입니다. Helo 같은 이메일 서비스를 쓰면서 메일이 도착하지 않는다면 무슨 의미가 있겠습니까?
• @victor_pratti — 이 문제는 저에게도 익숙합니다. 저는 Postmark를 쓰는 작은 SaaS를 혼자 개발했는데, 수동 계정 승인 절차 때문에 몇 주 동안 제 도메인으로만 발송할 수 있었습니다. 실제 고객에게 메일을 보내야 할 시점에 막힌 셈입니다. 출시를 막지 않으려고 결국 Resend로 옮겼습니다. Helo도 임의의 수신자에게 발송하려면 그런 수동 승인을 거쳐야 하나요? 아니면 일반적인 악용 방지 제한 안에서 새 계정도 바로 넓게 발송할 수 있나요? 이 문제는 인디 개발자가 출시 중에 감당하기 어렵습니다.
  • @bettina_specht1 — 네, 수동 승인에 막히는 일은 답답합니다. Helo가 다르게 하려는 점 중 하나도 바로 그것입니다. 저희가 보기에 정상적인 발신자라면 시작할 때 승인 절차에 막히지 않습니다. SaaS를 출시한 뒤 이메일 발송이 잘 되고 있길 바랍니다. 나중에 대안을 찾게 되면 Helo를 기억해 주세요. :)

원문: Product Hunt / 번역·요약: Trawling