"메일 서버는 절대 직접 운영하지 말고 SaaS를 써라"라는 말은 IT 업계의 오랜 격언입니다. 스팸 필터링, 발신자 평판 관리, DKIM·SPF·DMARC 설정, 24시간 가용성 유지 등 신경 쓸 거리가 너무 많기 때문입니다.
그럼에도 불구하고 저희는 사내 업무 메일 인프라를 쿠버네티스 클러스터 위에 직접 구축했고, 현재 전사 메일 시스템이 안정적으로 운영되고 있습니다.
판단의 근거: 이미 갖춰진 인프라 레이어의 재사용
"메일을 직접 돌리지 마라"는 조언의 전제는 메일 하나만을 위해 전담 서버를 세우고 모니터링과 백업 체계를 처음부터 만들어야 할 때 유효합니다.
하지만 저희에게는 이미 전사 서비스를 위한 쿠버네티스 클러스터, cert-manager 기반 인증서 자동 갱신 체계, GitOps 배포 파이프라인, 중앙화된 로깅/모니터링 체계가 완벽히 구축되어 있었습니다. 기존 인프라 위에 가벼운 모던 메일 서버(Stalwart) 차트를 올리는 것은 추가적인 운영 리소스를 거의 요구하지 않았습니다.
자체 호스팅으로 얻은 3가지 명확한 이점
- 계정 수 비례 구독료 제로: 상용 메일 서비스(Google Workspace, M365 등)는 조직 인원수가 늘어날 때마다 매월 고정 구독료가 선형으로 증가합니다. 자체 호스팅은 인원이 몇 배로 늘어나도 추가 비용이 거의 발생하지 않습니다.
- 사내 핵심 데이터 주권 확보: 견적서, 계약서 등 민감한 거래 정보가 외부 서드파티 저장소가 아닌 사내 통제 하의 전용 스토리지에 안전하게 보관됩니다.
- 인프라 관리 방식의 일원화: 별도의 메일 관리자 웹 콘솔을 헤맬 필요 없이, 다른 마이크로서비스들과 동일하게 Git 저장소의 매니페스트로 메일 설정을 코드로 관리(IaC)합니다.
구축 과정에서 해결한 난제들
- Secret 참조 구조 개선: 업스트림 Helm 차트의 조건문 버그로 인해 외부 시크릿 참조 시 설정이 유실되던 문제를 커스텀 밸류 패치로 해결했습니다.
- 네트워크 및 라우팅 구성: 메일 수신을 위한 고정 공인 IP 할당, MX/PTR 레코드 및 SPF/DKIM/DMARC 보안 인증 레코드를 체계적으로 정비하여 대외 수발신 신뢰도를 확보했습니다.
이 방식이 적합하지 않은 경우
- 대규모 마케팅/뉴스레터 발송 서비스: 수만 명에게 뉴스레터를 발송하는 용도라면 IP 발신 평판 관리가 본업이 되므로 SendGrid 같은 전문 발송 SaaS를 사용하는 것이 옳습니다. (저희는 소규모 사내 업무용 메일에 한정하여 구축했습니다.)
- 클러스터 운영 역량이 없는 팀: 인프라 기본기가 없다면 사소한 장애에도 메일이 장시간 중단될 수 있으므로 상용 서비스를 이용하는 것이 안전합니다.
요약
무조건적인 통념을 따르기보다, 우리 팀의 기존 인프라 역량과 비즈니스 특성을 냉정히 계산하여 최적의 가성비와 통제권을 확보하는 것이 엔지니어링의 본질입니다.