knadh/listmonk이 오늘 GitHub 트렌딩에서 15위, 하루 +222 stars를 기록했다. 표면적으로는 "자체 호스팅 뉴스레터 매니저"지만, 이 프로젝트의 진짜 주장은 README 한 줄에 박혀 있다. High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app. 마지막 네 단어가 전부다.
대부분의 메일러 스택은 캠페인 매니저, 워커, 큐, 템플릿 렌더러, bounce 처리기, 구독자 DB가 각자 다른 프로세스로 분리된다. 운영자는 그 사이의 네트워크 경계, 버전 드리프트, 큐 백프레셔를 평생 돌본다. listmonk은 이 모든 책임을 하나의 Go 바이너리 안에 묶고, 외부 의존성은 Postgres 단 하나로 줄였다. 정적 바이너리이기 때문에 Alpine 이미지에 그대로 넣을 수 있고, staging과 prod의 동일성이 자연스럽게 따라온다. 백업은 Postgres dump 한 줄이 사실상 전부다.
흥미로운 설계는 세그먼트 모델이다. 구독자의 임의 attribute를 JSONB로 저장하고, 세그먼트 자체를 저장된 SQL 쿼리로 다룬다. 대형 ESP들이 클릭형 빌더 뒤에 숨겨둔 로직을 listmonk은 그대로 노출하는데, 이게 디버깅 가능성과 재현성 측면에서 훨씬 정직하다. 어떤 구독자가 왜 특정 캠페인에 들어갔는지 EXPLAIN 한 줄로 답할 수 있는 메일러는 생각보다 드물다.
물론 트레이드오프가 있다. 단일 바이너리 모델은 수평 확장 측면에서 SaaS형 메일러만큼 매끄럽지 않고, 실제 SMTP fan-out은 SES나 Postmark, 자체 Postfix 같은 릴레이에 위임해야 IP reputation 문제를 피한다. bounce 처리는 IMAP과 Webhook 두 모드를 지원하지만, 어느 쪽을 쓰든 전용 부메일박스 분리가 사실상 필수다. listmonk을 "메일을 보내는 엔진"으로 오해하면 운영이 금방 무너진다. 정확한 위치는 "리스트와 캠페인의 통제권을 자기 서버 안에 두는 도구"다.
그래서 이 프로젝트는 ESP 비용 곡선이 꺾이는 5만~50만 구독자 구간의 인디 미디어, 구독자 데이터를 EU 자체 서버에 둬야 하는 GDPR-민감 팀, ESP 락인에서 빠져나오려는 SaaS 운영자에게 가장 잘 맞는다. 하루 222 stars라는 숫자는 뉴스레터 도구가 다시 self-hosted 쪽으로 회귀하는 흐름의 한 단면이고, listmonk은 그 회귀의 가장 단정한 형태에 가깝다.