SMPP와 HTTP로 연결하기
바인드, 윈도우, 수신 확인을 깨뜨리지 않고 테스트 경로를 운영으로 전환하는 방법: 바인드, 처리량, keep-alive, 인코딩, 콜백, 장애 처리.
운영 메시징 연결은 단순한 엔드포인트가 아니라 운영 약정입니다. SMPP는 세션에 바인드 상태, 처리량 윈도우, keep-alive 트래픽, 수신 확인을 더합니다. HTTP는 요청별 인증과 콜백을 더합니다. 이 가이드는 두 방식을 테스트에서 운영까지의 순서로 정리합니다.
이 페이지의 목차
가장 먼저 관리해야 할 것은 바인드 상태입니다
바인드는 방향이 선언된 세션입니다. transmitter는 메시지를 제출하고, receiver는 수신 메시지와 수신 확인을 받으며, transceiver는 둘 다 수행합니다. 사업자는 필요한 바인드 유형에 맞는 자격 증명을 발급하며, 클라이언트는 바인드를 열림, 바인드됨, 스로틀링, 재연결 중, 닫힘과 같은 상태로 다루어야 합니다. 바인드가 항상 연결되어 있다고 가정하는 클라이언트는 첫 연결 끊김에서 메시지를 잃습니다.
바인드 상태를 명시적으로 추적하십시오. 모든 바인드 요청과 응답, 인터페이스 버전, system ID, 오류 코드를 기록하십시오. 연결이 끊기면 백오프를 적용해 재연결하고, 메시지 센터가 처리 중이던 제출을 수락했는지 확인하기 전에는 재전송하지 마십시오. 이를 확실하게 알 수 있는 유일한 방법은 submit_sm_resp의 message ID입니다.
바인드와 첫 번째 제출
- 애플리케이션(ESME)
- bind_transceiver 세션 열기
- SMSC
- submit_sm_resp 전달 접수됨
- 전달 확인
텍스트 설명
클라이언트는 바인드 요청을 보내고 바인드 응답을 받습니다. submit_sm으로 메시지를 제출하고 message ID가 담긴 submit_sm_resp를 받습니다. 이후 메시지 센터가 수신 확인이 담긴 deliver_sm PDU를 보내면 클라이언트는 deliver_sm_resp로 응답합니다. unbind로 세션을 닫습니다.
윈도우, 하트비트, 인코딩
윈도우는 메시지 센터가 하나의 바인드에서 받아들이는 미응답 요청의 수입니다. 처리 중인 요청 수를 윈도우 이하로 유지하고, 버스트 전에 윈도우가 비워지도록 하십시오. 스로틀링된 제출은 속도를 낮추라는 신호입니다. 같은 속도로 재시도하면 큐가 가득 차고, 느린 메시지 하나가 적체로 바뀝니다. 바인드 수는 월평균이 아니라 최대 속도를 기준으로 산정하십시오.
keep-alive 교환은 양쪽 끝에 세션이 살아 있음을 알립니다. 정해진 주기로 enquire_link를 보내고, 응답하지 않는 세션은 닫으십시오. 인코딩은 내용이 허용하면 GSM-7로, 그렇지 않으면 UCS-2로 보내십시오. GSM-7 문자 집합 밖의 문자 하나만 있어도 메시지 전체가 UCS-2로 바뀌고 세그먼트 수가 달라질 수 있습니다. 변수 값을 포함해 실제 템플릿 그대로 테스트하십시오.
전달 수신 확인
수신 확인은 deliver_sm PDU로 비동기적으로 도착합니다. 여기에는 원래 message ID, delivered, expired, undelivered, unknown과 같은 상태, 그리고 대개 네트워크 코드가 담겨 있습니다. message ID로 매칭하고 상태를 메시지 레코드와 함께 저장하십시오. 도착 순서로 매칭하지 말고, 수신 확인이 없다고 해서 메시지가 실패한 것으로 처리하지 마십시오.
수신 확인 형식은 다양합니다. 최신 메시지 센터는 message_state tag-length-value 필드를 사용하고, 오래된 메시지 센터는 short message 필드에 키-값 텍스트를 넣습니다. 두 형식을 모두 파싱하십시오. 애플리케이션에 필요한 상태로 정규화하되 원본 코드도 보관하여, 지원 문의가 생겼을 때 네트워크가 보낸 내용까지 추적할 수 있게 하십시오.
장애 유형과 첫 번째 대응
| 증상 | 가능한 원인 | 첫 번째 점검 |
|---|---|---|
| 바인드 거부 | 잘못된 자격 증명, 바인드 유형 또는 인터페이스 버전 | 바인드 응답 코드와 인터페이스 버전 확인 |
| 타임아웃 증가 | 윈도우 초과 또는 느린 경로 | 재시도 전에 처리 중인 요청 수와 응답 코드 확인 |
| 바인드는 열려 있으나 응답 없음 | 세션이 끊겼거나 클라이언트가 keep-alive를 중단함 | enquire_link를 보낸 뒤 백오프를 적용해 재연결 |
| 수신 확인 누락 | 수신 확인이 핸들러에 도달하지 못함 | 재전송 전에 세션 로그와 message ID 확인 |
| 문자 깨짐 | GSM-7 내용을 UCS-2로 보냈거나 그 반대 | 데이터 코딩과 세그먼트 수 확인 |
| 콜백 타임아웃 | 엔드포인트가 느리거나 연결할 수 없음 | 빠르게 응답하고 비동기로 처리하며 서명 검증 |
대응 순서가 중요합니다. 먼저 관찰한 다음 변수를 하나씩 바꾸십시오.
테스트 경로에서 운영으로
-
테스트 경로에 바인드
테스트 자격 증명과 운영에서 사용할 바인드 유형을 그대로 사용하십시오. 바인드 응답과 인터페이스 버전을 확인하십시오.
-
실제 템플릿 발송
링크, 변수, 가장 긴 메시지를 포함해 실제로 출시할 내용을 테스트하십시오. 인코딩과 세그먼트 수를 기록하십시오.
-
수신 확인 확인
모든 수신 확인을 message ID로 매칭하십시오. 애플리케이션이 받게 될 상태와 오류 코드를 확인하십시오.
-
장애 경로 테스트
유효하지 않은 번호, 저장 공간이 가득 찬 단말, 차단된 서비스로 발송하십시오. 수신 확인 상태와 애플리케이션의 처리 방식을 확인하십시오.
-
윈도우 산정
최대 속도 테스트를 실행하고 처리 중인 요청 수가 윈도우 이하로 유지되는지 확인하십시오. 그렇지 않으면 바인드를 추가하십시오.
-
모니터링 활성화
바인드 상태, 제출 지연, 수신 확인 지연, 수신 확인 상태 분포에 대해 알림을 설정하십시오. 각 알림에 대응할 담당자를 지정하십시오.
-
운영 트래픽 전환
먼저 일부 트래픽만 옮기고 수신 확인을 테스트 결과와 비교한 뒤 늘려 가십시오. 테스트 경로는 대체 경로로 계속 사용할 수 있게 유지하십시오.
HTTP 인증과 콜백
HTTP 연동은 온보딩 시 발급된 키로 각 요청을 인증합니다. 키가 만료되기 전에 교체하고, 교체 기간 동안 기존 키도 유효하게 유지하십시오. 발송 요청은 message ID가 담긴 수락 응답을 반환하며, 수신 확인과 수신 메시지는 콜백 URL로 도착합니다.
콜백 엔드포인트는 서명을 검증하고 빠르게 응답한 뒤, 응답 후에 이벤트를 처리해야 합니다. 엔드포인트가 느리면 재시도가 발생하고, 핸들러가 멱등적이지 않으면 재시도가 중복을 만듭니다. 인증서나 DNS가 바뀌어도 엔드포인트에 연결할 수 있도록 유지하고, 콜백 실패율이 오르면 알림을 보내십시오. 세션은 SMPP 해설에서, 방식 선택은 전송 방식 비교에서 다룹니다.
자주 묻는 질문
어떤 SMPP 버전을 사용해야 합니까?
바인드는 몇 개가 필요합니까?
콜백은 처리 전에 응답해야 합니까?
수신 확인이 끝내 도착하지 않으면 어떻게 합니까?
장애는 어떻게 테스트합니까?
관련 자료
- 글로벌 A2P 발신자 ID 플레이북
시장별 발신자 ID의 작동 방식: 영숫자, 숫자, 단축번호 경로, 등록 요건과 국가별 예시.
- A2P SMS
A2P(Application-to-person) SMS는 인증 코드나 거래 알림처럼 애플리케이션이 등록된 발신자를 통해 단말기로 보내는 트래픽입니다.
- DLR
DLR(전송 결과 수신 확인)은 발송된 SMS에 대한 모바일 네트워크의 상태를 전달 완료, 만료, 거부, 알 수 없음 등으로 알려줍니다.
제공 서비스와 인접한 항목
당사 서비스 이용 방식에 영향을 주므로 이곳에서 설명합니다.