알아야 할 모든 정보, 불필요한 정보는 없습니다.
SMPP의 단계별 작동 방식
ESME는 TCP(가급적 TLS) 연결을 열고 system_id과 비밀번호가 포함된 bind_transceiver을 전송합니다. 바인딩이 완료되면 각 메시지를 submit_sm PDU로 제출하며, SMSC는 message_id를 포함한 submit_sm_resp로 응답합니다. 전송 결과 보고는 동일한 소켓에서 deliver_sm PDU 형태로 비동기적으로 도착하며, message_id을 통해 매칭됩니다. 30초마다 수행되는 enquire_link 하트비트가 세션을 유지하며, 언바인딩(unbind) 시 세션이 깔끔하게 종료됩니다. /answers/what-is-smpp 및 /answers/what-is-esme 페이지를 참조하세요.
바인드 유형 및 버전
ESME는 송신 전용(Transmitter), 수신 전용(Receiver) 또는 단일 연결에서 양방향(Transceiver)으로 바인딩됩니다. SMPP 3.4 기반의 Transceiver가 현대적인 기본 설정입니다. SMPP 5.0은 Unicode-clean 헤더와 셀 브로드캐스트 지원을 추가했지만 거의 아무도 도입하지 않았으며, 설치 기반은 압도적으로 3.4입니다. BroadNet은 SMPP 3.4 바인드를 수용합니다. 호스트, 포트 및 인증 정보는 테스트 계정 신청 시 제공됩니다. /answers/smpp-3-4-vs-5-0 페이지를 참조하세요.
REST API 대비 장점
연결이 확립된 후 지속적인 바인딩(bind)은 메시지당 비용이 발생하지 않으므로, 지속적인 대량 발송 시 SMPP는 요청당 방식인 HTTPS에 비해 CPU의 약 10분의 1, 대역폭의 4분의 1만 사용합니다. 이는 SMSC에 대해 100ms 미만의 p99 지연 시간을 달성할 수 있는 유일한 방법입니다. 크리티컬 패스(critical path)에 HTTP 핸드셰이크가 없으며, DLR을 실시간으로 스트리밍합니다. /compare/sms-api-vs-smpp 페이지 참조
제한 사항 및 주의 사항
SMPP는 직접 운영해야 하는 바이너리 프로토콜입니다. 바인드 관리, 지수 백오프(exponential backoff)를 이용한 재연결, 시퀀스 번호 추적, 그리고 message_id에 따른 전송 결과 보고(DLR) 매칭(일부 SMSC에서는 16진수, 일부에서는 10진수로 반환됨)을 모두 직접 처리해야 합니다. 오류 처리는 간결합니다. 제출 실패 시 디코딩해야 하는 숫자형 command_status가 반환됩니다. /tools/smpp-error-codes 조회를 사용하여 해당 코드를 실제 동작으로 변환하세요. 프로덕션급 SMPP 클라이언트는 수천 줄에 달하는 코드베이스이므로, 직접 구축하기보다 구매하는 것이 효율적입니다.
REST 대신 SMPP를 선택해야 하는 경우는 언제인가요?
초당 수백 건의 메시지를 유지하거나 지속적인 바인딩(바인딩당 용량은 담당 팀과 협의)이 필요한 경우, 밀리초 단위의 속도가 중요한 지연 시간 민감형 OTP를 실행하는 경우, 또는 이미 모든 곳에서 SMPP를 사용하는 통신사/애그리게이터 생태계에 통합하는 경우에는 SMPP를 선택하세요. 그렇지 않은 경우, REST SMS API(BroadNet의 계정별 고정 API 속도 제한 없음)를 사용하면 운영이 더 간편하고 동일한 경로를 통해 전송됩니다. /developers/smpp 및 /products/sms-api를 참조하십시오.
SMPP는 어떤 포트를 사용하며, 2026년에도 여전히 사용되나요?
SMPP는 단일 예약 포트가 없습니다. 2775는 전통적인 평문(plaintext) 기본 포트이며, 통신사들은 일반적으로 전용 포트로 TLS를 제공합니다 (BroadNet은 계정과 함께 TLS 포트를 제공합니다). 또한 SMPP는 여전히 매우 유효한 표준입니다. 이는 거의 모든 A2P 상호 연결 계약의 핵심 프로토콜이며, BroadNet은 1,000개 이상의 통신사 연결을 통해 1,000개 이상의 활성 바인드(bind)를 운영하며, 2003년부터 99.99%의 가동률로 하루 3억 건 이상의 메시지를 처리하고 있습니다.