뉴스레터 서비스, 직접 만들어 보려고 합니다

블로그를 다시 만들며 새롭게 시도해보고 싶었던 게 있어요. 바로 뉴스레터인데요.

새 글이 올라올 때마다 알리는 채널은 RSS만으로도 충분하지만, RSS는 도구가 따로 필요하잖아요? 제 블로그가 많은 트래픽이 있지는 않지만, 평소에 글을 받아 보고 싶어하는 분들에게 "Feedly나 Inoreader로 RSS 추가해서 확인해보세요."라고 안내하는 건 조금 무책임한 느낌이 들었어요. 그리고 RSS가 익숙하지 않은 분들에게는 그 자체가 진입 장벽이 될 수도 있고요. 이메일은 누구나 가지고 있는 채널이고, 가장 정직하게 "원하는 사람에게만" 닿는 도구이니까 뉴스레터를 한번 운영해볼까 싶더라고요.

외부 서비스를 잠깐 들여다봤어요

그래서 뉴스레터 적용을 위해 관련 서비스들을 한번 살펴봤어요. 1인 운영자가 뉴스레터를 시작할 때 흔히 고려하는 옵션들이 있죠.

한국 서비스 쪽에서는,

스티비(Stibee) — 한국에서 가장 인지도가 높은 뉴스레터 플랫폼. 500명까지 무료. 드래그앤드롭이라 비개발자도 부담 없이 시작할 수 있어요.

메일리(Maily) — 개인은 무료. 아카이빙과 구독자 커뮤니티, 유료 구독자 생성까지 한 번에 됩니다.

글로벌 서비스로는,

Buttondown — 가장 가볍습니다. 100명까지 무료, 이후 월 $9.

Beehiiv — 2,500명까지 무료. UI와 마케팅 기능이 더 풍부하고, 성장 도구 위주.

표면적으로는 위 옵션 중 하나를 선택하는 게 가장 무난하고 쉽게 뉴스레터 기능을 적용하는 길입니다. 셋업 30분, 무료 티어로 충분히 시작 가능, 발송과 바운스, 구독 해지, 법적 unsubscribe 페이지까지 다 처리해 주니까요.

그런데 손이 안 갔습니다

가만히 옵션 표를 비교해가며 고민을 하면 할수록, 뭐랄까.. 손이 잘 안 가더라고요. 여러 가지 이유가 있었지만,

먼저, 이 블로그는 개발자 정체성으로 운영하는 곳인데, 그 정체성으로 블로그를 시작하면서 인프라 한 조각을 외부 서비스로 처리하는 건 큰 모순까진 아니지만, 작은 찜찜함이 있었습니다.

그리고, "뉴스레터 직접 만들기" 자체가 좋은 글 소재가 될 것 같았어요. 영어권에는 indie hackers가 쌓아 둔 관련 글들이 많지만, 한국어로는 관련 정보들이 산발적이고 잘 정리된 글들을 찾기 쉽지 않더라고요.

진짜 어려운 부분이 어디인지

뉴스레터 서비스를 자체 구축하는 게 너무 어렵고 불가능해서 외부 서비스가 존재하고, 비싼 건 아닙니다. 제 생각에 정말 중요한 포인트, 비용을 지불할 가치가 발생하는 포인트는 바로 이메일 라이프사이클의 운영적 비용을 외부 서비스가 대신 처리해 주기 때문이라고 생각해요.

해야 할 일	직접 만들면 드는 시간
구독자 이메일 저장	5분
가입 확인 단계 (메일 → 링크 클릭 → 가입 완료)	한나절
한 번에 구독 해지 (정보통신망법·CAN-SPAM 의무)	한나절
반송된 주소 자동 제외 (Bounce 처리)	하루
스팸 신고한 사람 자동 차단 (Complaint 처리)	반나절
대량 발송 시 속도 조절 (Rate limit & 큐)	하루
받은편지함 도달률 관리 (SPF / DKIM / DMARC, 도메인 평판)	평생
환경별 이메일 디자인 (반응형, 다크모드, 텍스트 대체)	하루

구독자 메일 저장은 쉽습니다. 그 외의 나머지 작업들은 쉽지 않을 것 같아요. 그리고 한 번이라도 잘못된 발송으로 도메인 평판이 망가지면, 회복하는 게 쉽지 않죠. 발송한 메일이 스팸 폴더로 직행하기 시작하면 그 원인을 교정한다고 해도, 평판이 돌아오는 데는 엄청 긴 시간이 걸릴 거예요.

외부 서비스가 가장 효과적으로 줄여 주는 게 바로 이런 운영 사고로 인한 평판 손상 확률입니다. 도메인 평판 자체를 보호해 주는 건 아니지만, 운영 실수의 빈도를 낮춰서 결과적으로 평판을 지켜 주는 셈이죠.

그럼에도 자체 구현으로 가는 이유

이 운영적 비용을 돈이 아니라 시간으로 치르려고 합니다. 이유는 다음과 같아요.

규모가 작습니다. 제 블로그의 트래픽이나 규모가 작잖아요. 어쩌면 뉴스레터 기능을 잘 만들어둬도 사용할 일이 거의 없을 수도 있어요. 이 규모에선 자체 운영의 deliverability 리스크가 작을 거라서 경험 측면에서 시도해보기 가장 좋을 때라고 판단했어요. 작은 규모에서 부딪히면서 운영 노하우를 쌓고, 의미 있는 규모가 되면 그 시점에 외부 서비스로 마이그레이션하거나 계속 자체 운영하거나, 그때 결정해도 늦지 않다고 봤어요.

약점이 콘텐츠가 됩니다. SPF/DKIM/DMARC를 처음 셋업하면서 막힌 지점, 첫 발송 후 받은 바운스 웹훅을 어떻게 처리했는지, 1-click unsubscribe를 정보통신망법 기준으로 어떻게 만들었는지. 이 모든 기록과 공유가 좋은 정보가 될 수 있을 거라 생각합니다.

Vercel + Resend + Neon 조합이 의외로 가볍습니다. Resend는 SDK가 깔끔하고, 무료 티어로 월 3,000건 발송이 가능해요. (일일 100건 제한이 있긴 합니다. 폭주만 막으면 작은 뉴스레터에는 충분합니다.) Vercel Functions는 API 엔드포인트로 충분하고, 구독자 저장은 Neon이나 Supabase 둘 다 무료 티어로 인프라 비용 0에 가깝게 시작할 수 있습니다.

앞으로 진행은?

새로운 블로그 시작 시점에는 뉴스레터 폼을 "준비 중" 상태로 뒀어요. 그리고 단계별로 인프라를 짓습니다. 그동안 새 글은 RSS로 받을 수 있게 안내해 두었고요.

다음 글들로 다룰 윤곽은 확정은 아니지만, 이렇게 생각하고 있습니다.

(이번 글) 왜 외부 서비스가 아닌 자체 구현인가
이메일 인프라 기초 — SPF / DKIM / DMARC, 도메인 평판
Resend + Vercel로 구독 받기 — MVP
이중 옵트인 — 토큰 검증 + 확인 페이지
1-click Unsubscribe — 정보통신망법 + CAN-SPAM 준수
Bounce 처리 — Resend 웹훅으로 자동 suppression list
Complaint 처리 — 스팸 신고 자동 차단
Rate limit & 큐 — 대량 발송 throttling
HTML 이메일 템플릿 — 반응형, 다크모드 대응
첫 발송 회고 — 도달률, 반송률, 교훈

전부 다 쓰지 않을 수도 있어요. 작업하면서 막히는 지점이 자연스럽게 글로 풀려 나오는 게 더 좋을 것 같습니다. 매끄럽게 도착하는 가이드보다, 부딪히면서 정리한 기록이 비슷한 길을 가는 사람들에게 더 도움이 되겠죠?