이메일 발송 기능을 구현하라고 하면 대다수 주니어 개발자들은 뻔한 생각을 합니다. "SMTP 라이브러리 하나 붙이거나, AWS SES 같은 거 쓰면 되는 거 아니에요?" 솔직히 말해, 그렇게 접근했다가는 나중에 피눈물 흘립니다. 코드는 자산이 아니라 부채라는 말을 입이 닳도록 했습니다만, 외부 서비스에 대한 맹목적인 의존 역시 기술 부채의 또 다른 형태입니다. 오늘은 네덜란드의 Rust 전문 개발사 Tweede golf가 구축한 'Remails' 사례를 통해, 진짜 프로덕션 레벨의 이메일 시스템이 어떤 과정을 거쳐 진화하는지, 그리고 왜 'IP 평판'이 아키텍처를 결정하는 핵심 요소인지 뼈 때리는 이야기를 좀 해보겠습니다.
Remails는 유럽 내 데이터 주권 문제로 미국 빅테크 기업의 서비스를 걷어내고, 자체적인 Mail Transfer Agent(MTA)를 구축하려는 시도에서 시작되었습니다. 처음부터 거창한 마이크로서비스 아키텍처(MSA)를 도입했을까요? 아니요. 그들은 철저하게 실용주의적이었습니다. 초기에는 저렴한 VPS 한 대에 Docker Compose로 띄운 단일 바이너리와 PostgreSQL 컨테이너 하나가 전부였습니다. 저는 이런 접근을 매우 좋아합니다. 트래픽도 없는데 쿠버네티스(Kubernetes)부터 깔고 보는 '이력서 주도 개발'보다 백배 낫습니다. MVP 단계에서는 빠른 피드백 루프가 생명이기 때문입니다.
하지만 비즈니스 요구사항이 복잡해지면서 상황은 변합니다. 고가용성(High Availability)이 필요해지자, 이들은 관리형 쿠버네티스와 관리형 DB로 인프라를 확장했습니다. 여기서 흥미로운 점은 그들이 정의한 '가용성'의 우선순위입니다. 첫째는 데이터 보존(PITR 백업), 둘째는 메일 수신 대기 상태, 그리고 마지막이 메일 발송입니다. 발송이 조금 지연되는 건 허용되지만, 들어온 메일을 놓치거나 데이터를 날리는 건 치명적이라는 판단입니다. 이를 위해 애플리케이션을 Web API와 실제 SMTP 통신을 담당하는 MTA 파트로 분리하고, 로드 밸런서를 통해 트래픽을 분산시켰습니다.
여기까지는 교과서적인 내용입니다. 진짜 문제는 그다음입니다. 바로 'IP 평판(Reputation)'입니다. 클라우드 제공업체가 할당해 주는 공인 IP는 이미 스패머들이 더럽혀 놓은 경우가 태반입니다. 이런 IP로 메일을 보내면 여러분의 소중한 비즈니스 메일은 고객의 스팸함으로 직행합니다. 결국 Remails 팀은 'BYOIP(Bring Your Own IP)' 전략을 택했습니다. 깨끗한 IP 블록을 직접 확보해서 사용하는 것입니다.
문제는 쿠버네티스 환경에서 특정 IP를 특정 고객의 메일 발송에 할당하는 것이 기술적으로 까다롭다는 점입니다. 쿠버네티스는 기본적으로 노드(Node) 간에 포드(Pod)를 자유롭게 띄우는데, 이메일 발송 시 나가는 아웃바운드 IP는 해당 노드의 네트워크 인터페이스를 따르기 때문입니다. 대량 발송 고객에게 전용 IP를 제공하여 평판을 독립적으로 관리해주려면, 단순히 노드를 늘리는 것으로는 해결이 안 됩니다. 결국 이들은 고가용성을 유지하면서도 발신자별로 아웃바운드 IP를 통제할 수 있도록 쿠버네티스 아키텍처를 리팩터링해야 했습니다.
단순히 "메일을 보낸다"는 기능 하나를 위해 인프라 레벨까지 뜯어고쳐야 하는 이 상황, 이것이 바로 백엔드 개발의 현실입니다. 비즈니스 로직(특정 고객의 IP 평판 보호)이 인프라 구조를 결정짓는 아주 좋은 예시입니다. 남들이 다 쓴다고 무작정 유행하는 기술 스택을 가져다 쓰는 게 아니라, 내가 해결해야 할 문제(스팸 필터 회피, 데이터 주권)에 맞춰 기술을 깎아나가는 태도가 필요합니다.
개발자로서 성장하고 싶다면 "어떻게 구현하나요?"가 아니라 "왜 그렇게 구현했나요?"를 물어야 합니다. Remails 팀이 단일 바이너리에서 복잡한 쿠버네티스 설정으로 넘어간 건 멋있어 보이려고 한 게 아닙니다. 살아남기 위해서, 고객의 메일을 스팸통에 처박히지 않게 하기 위해서였습니다. 여러분이 지금 작성하고 있는 그 코드, 과연 비즈니스의 생존과 직결된 고민이 담겨 있습니까? 아니면 그저 튜토리얼을 따라 한 복제본입니까? 부디 전자이길 바랍니다.
