SENDM 문자발송 플랫폼
문자를 '보내는 기능'이 아니라
'멈추지 않는 발송 시스템'을 만드는 일
SENDM은 미션비가 구축해 운영해 온 문자발송 플랫폼입니다. 대량 발송에서 어려운 부분은 메시지를 보내는 API 호출 자체가 아니라, 요청이 몰려도 순서대로 처리되고, 결과가 뒤늦게 도착해도 정확히 반영되며, 일부 실패가 전체를 멈추지 않게 만드는 것입니다.
| 구분 | 자사 서비스 — 문자발송 플랫폼 (개발 · 운영 모두 미션비) |
|---|---|
| 메시지 종류 | SMS(단문) · LMS(장문) · MMS(이미지) |
| 담당 범위 | 발송 시스템 설계 · 개발 · 관리자 · 서버/DB 운영 |
| 서비스 상태 | 운영 중 (2026-09-16 확인) |
| 서비스 | sendm.co.kr |
해결해야 했던 문제
요청과 발송의 분리
사용자가 수만 건을 한 번에 요청해도 화면은 즉시 응답해야 합니다. 접수는 큐에 적재하는 것으로 끝내고, 실제 발송은 별도로 처리하는 구조가 필요했습니다.
뒤늦게 오는 결과
발송 결과는 즉시 오지 않습니다. 요청 시점과 결과 시점을 각각 저장하고, 결과가 도착하면 해당 건을 찾아 갱신하는 방식으로 통계를 정확하게 유지합니다.
실패의 격리
특정 수신번호나 모듈에서 문제가 생겨도 전체 발송이 멈추면 안 됩니다. 건 단위로 상태를 관리하고 실패 건만 따로 재처리할 수 있게 만들었습니다.
구축 목적
- 개인·기업 고객이 웹에서 직접 문자를 보내고, 발송 결과와 비용을 스스로 확인할 수 있는 서비스
- 등록·확인된 발신번호로만 보낼 수 있게 하는 등 문자 서비스에 요구되는 절차를 시스템으로 강제
- 외부 서비스가 API 로 발송을 요청하고 결과를 받아 갈 수 있는 구조
구축 범위와 주요 기능
발송
- SMS/LMS/MMS 발송, 본문 길이에 따른 종류 판정
- 대량 발송과 예약 발송
- 발송 큐 적재 후 순차 처리(요청/발송 분리)
- 건별 상태 관리와 실패 건 재처리
운영 데이터
- 발신번호 등록·검증(등록되지 않은 번호 차단)
- 주소록/그룹 관리와 대량 업로드
- 충전·과금 처리와 잔액 관리
- 발송내역 조회와 기간별 통계
연동
- 외부 서비스에서 호출하는 발송 API
- 통신사·중계사 모듈 교체 가능한 구조
- 수신거부 처리 연동
운영 · 보안
- 관리자 권한 분리와 작업 이력
- 발송 로그를 업무 로그와 분리해 추적
- 서버·DB 운영, 배포, 백업
기술 구조
| 애플리케이션 | Java · Spring Boot, MyBatis, 발송 큐 기반 비동기 처리 |
|---|---|
| 발송 데이터 | 발송 요청 1건(마스터: 전체·대기·성공·실패 건수)과 수신번호별 상세를 분리. 상세는 월 단위 테이블로 나눠 최근 데이터 조회가 느려지지 않게 함 |
| 결과 처리 | 통신사·중계사마다 다른 결과 코드를 코드표로 매핑해 사용자에게는 같은 기준의 결과명으로 안내 |
| 데이터베이스 | MariaDB |
운영 방식
내 데이터만 보이게
주소록·발송내역·발신번호 같은 모든 조회와 변경은 로그인한 사용자 소유 범위로 조건을 겁니다. 다른 계정의 데이터 번호를 넣어 보는 교차 접근 시험으로 확인합니다.
발신번호는 확인된 번호만
발신번호 등록은 증빙 서류를 첨부해 요청하고, 승인된 번호만 발송에 쓸 수 있습니다. 본인인증 결과가 있는 경우에만 가입자 본인 번호를 자동 등록합니다.
지우기 전에 남기기
주소록을 삭제할 때는 삭제 직전 상태를 이력으로 남겨, 사용자가 실수로 지운 경우에도 무엇이 언제 지워졌는지 확인할 수 있습니다.
부가 처리 실패 격리
가입 직후 기본 설정 생성처럼 부가적인 처리가 실패해도 가입 자체는 되돌리지 않고 기록만 남깁니다. 핵심 업무가 부가 기능 때문에 막히는 쪽이 더 위험하기 때문입니다.
결과
- 센드엠은 2026-09-16 기준 운영 중인 서비스이며, 미션비가 개발과 서버·DB 운영을 계속 맡고 있습니다.
- 미션비 홈페이지도 같은 방식(큐에 적재한 뒤 별도 처리)으로 문의 알림과 관리자 2단계 인증 문자를 보냅니다.
- 발송 건수·매출·회원 수 같은 수치는 공개하지 않습니다.
함께 보면 좋은 내용
문자 시스템을 새로 만들거나 붙이려 하시나요?
플랫폼을 통째로 구축하는 방식과, 기존 서비스에 발송 기능만 API로 붙이는 방식 중
어느 쪽이 맞는지부터 정리해 드립니다.