# SMPP vs HTTP: 어떤 연결 방식이 맞는가

SMPP는 바인드마다 처리량 윈도우를 가진 지속 세션을 유지합니다. HTTP는 요청마다 인증하고 이벤트를 콜백으로 받습니다. 두 방식은 같은 메시지를 전달하고 같은 전달 상태를 보고합니다. 트래픽 형태와 팀이 운영할 수 있는 장애 유형을 기준으로 선택하십시오.

- SMPP는 하나의 세션을 열어 두고, 바인드마다 진행 중 요청 윈도우를 둡니다.

- HTTP는 전송할 때마다 인증된 새 요청을 시작하고, 전달 확인에는 콜백을 사용합니다.

- 두 모델은 같은 전달 상태를 반환합니다. 전송 방식에 따라 상태가 도착하는 방식이 달라집니다.

- 장애 유형은 다릅니다. SMPP에서는 바인드 윈도우 포화, HTTP에서는 느린 콜백입니다.

## 한 단락으로 보는 결정

트래픽량이 적고, 트래픽이 간헐적으로 몰리며, 팀이 이미 웹 엔드포인트를 운영하고 있다면 HTTP로 시작하십시오. 트래픽이 꾸준한 흐름일 때, 요청별 인증과 연결 설정이 눈에 띄는 비용이 될 때, 또는 전달 확인이 전송과 같은 트랜시버 세션으로 도착해야 할 때 SMPP로 전환하십시오. 많은 플랫폼이 두 방식을 함께 운영합니다. 전송 흐름에는 SMPP를, 수신 콜백에는 HTTP를 사용합니다.
프로토콜이 곧 제품은 아닙니다. 메시지가 도착하는지는 경로, 발신자 등록, 단말 검사가 결정합니다. SMPP와 HTTP는 같은 메시지 센터에 도달하는 두 가지 방법이며, 어느 쪽이든 잘 운영할 수도, 잘못 운영할 수도 있습니다.
올바른 질문은 어떤 프로토콜이 더 새로운가가 아닙니다. 트래픽이 만들어 내는 속도에 맞춰 팀이 어떤 장애를 발견하고 고칠 수 있는가입니다. 새벽 두 시에 응답이 없는 바인드도, 새벽 두 시에 실패하는 콜백도 모두 운영상의 문제입니다. 팀의 도구로 진단할 수 있는 쪽을 선택하십시오.

### 같은 작업, 두 가지 구조

|  | SMPP | HTTP |
| --- | --- | --- |
| 세션 | 인증된 바인드를 열린 상태로 유지 | 요청마다 키를 함께 전송 |
| 윈도우 | 바인드마다 고정된 진행 중 윈도우 | 클라이언트와 커넥션 풀이 정하는 동시성 |
| 전달 확인 | 트랜시버(또는 별도 리시버) 바인드의 deliver_sm PDU | 자체 엔드포인트로의 콜백 |
| 수신 메시지 | 리시버 또는 트랜시버 바인드의 deliver_sm | 자체 엔드포인트로의 콜백 |
| 재시도 | 클라이언트가 윈도우와 백오프를 관리 | 클라이언트는 요청을 재시도하고, 제공사는 콜백을 재시도 |

이 표는 제공사의 구현이 아니라 전송 방식을 설명합니다. 세부 사항은 온보딩 때 확인하십시오.

## 처리량은 트래픽 구조를 따릅니다

SMPP 바인드는 처리량 속도와 윈도우를 기준으로 할당됩니다. 세션이 열리면 제출 한 건의 비용은 새 핸드셰이크 없이 PDU 하나와 응답 하나입니다. 따라서 SMPP는 지속적인 흐름에 효율적이고 용량 계획을 예측하기 쉽습니다. 바인드 수를 세고, 할당량을 확인하고, 진행 중 요청을 윈도우 이하로 유지하면 됩니다.
HTTP는 요청마다 인증과 연결 설정 비용을 치르지만, 연결 재사용으로 그 비용을 줄일 수 있습니다. 용량은 바인드 윈도우가 아니라 동시성에서 나오므로, 클라이언트는 빠르게 트래픽을 몰아 보낸 뒤 속도 제한이나 큐에 부딪힐 수 있습니다. 이런 유연성은 캠페인과 소량 애플리케이션에 적합합니다. 다만 클라이언트가 동시성에 상한을 두지 않으면 피크를 예측하기 어려워집니다. 속도 제한과 윈도우는 서로 다른 제어 수단입니다. 하나는 초당 요청 수를, 다른 하나는 진행 중 요청 수를 제한합니다. 요청별 비용은 하루 수천 건 수준이 아니라 대량 트래픽에서 드러납니다.

속도와 윈도우를 바꿔 보십시오. 플래너는 브라우저에서 실행됩니다.

[Open the tool](/ko/tools/tps-planner/?src=learn-smpp-vs-http&scenario=campaign-50tps&tps=50&windowMin=60)

## 전달 확인과 수신 메시지가 연동 방식을 결정합니다

SMPP는 열린 세션으로 전달 확인과 수신 메시지를 전달합니다. 클라이언트는 이를 받기 위해 세션을 유지하고, 각 전달 확인을 저장된 메시지 ID와 매칭하고, deliver_sm_resp로 응답해야 합니다. 보안을 적용할 콜백 엔드포인트는 없지만, 상태를 지켜봐야 할 세션이 있습니다. 열려 있지만 응답이 없는 바인드도 하나의 장애 유형입니다.
HTTP는 전달 확인과 수신 메시지를 URL로 전달합니다. 수신 측은 서명을 검증하고, 빠르게 응답하고, 이벤트를 비동기로 처리합니다. 흔한 장애는 느린 콜백입니다. 제공사가 타임아웃 후 재시도하면 같은 이벤트가 두 번 처리됩니다. 멱등성 키와 빠른 확인 응답은 최적화가 아니라 연동의 일부입니다.
어느 경로로 전달 확인을 받든 원본 페이로드를 보관하십시오. 제공사의 해석은 바뀔 수 있으며, 기술 지원 문의는 원래 상태나 오류 코드에 따라 판가름 나는 경우가 많습니다. 메시지 ID, 경로, 시각과 함께 저장하십시오.

### 설계 단계에서 대비할 장애 유형

| 장애 | 나타나는 증상 | 대응 방법 |
| --- | --- | --- |
| 바인드 윈도우 포화 | 타임아웃과 재시도가 함께 늘고 큐가 커짐 | 재시도를 멈추고, 윈도우가 비워지게 한 뒤, 바인드를 추가 |
| 응답 없는 세션 | 바인드는 열려 있지만 응답이 오지 않음 | enquire_link를 보내고, 세션을 타임아웃 처리한 뒤, 백오프를 두고 재연결 |
| 전달 확인 불일치 | 상태가 엉뚱한 메시지에 연결됨 | 도착 순서가 아니라 메시지 ID로 매칭 |
| 느린 콜백 | 제공사가 재시도하고 중복이 발생함 | 빠르게 확인 응답하고, 비동기로 처리하며, 멱등성 키를 사용 |
| 멱등성 누락 | 네트워크 재시도로 메시지가 두 건 생성됨 | 클라이언트 참조값을 함께 보내고 이를 기준으로 중복 제거 |
| 인코딩 불일치 | 긴 메시지가 조각나서 도착하거나 문자가 깨짐 | GSM-7 또는 UCS-2를 명시적으로 설정하고 세그먼트 수를 시험 |

해결책은 운영 차원의 조치입니다. 어떤 전송 방식을 쓰더라도 이 조치는 필요합니다.

## 선택과 연동

전송 흐름이 지속적이고, 제공사가 크기를 맞출 수 있는 윈도우를 할당하며, 팀이 세션을 운영할 수 있다면 SMPP를 선택하십시오. 세션 운영에는 바인드 관리, 킵얼라이브, 재연결, PDU 수준 로그가 포함됩니다. 트래픽량이 크지 않고, 팀이 이미 보안 웹 엔드포인트를 운영하며, 콜백이 아키텍처에 맞는다면 HTTP를 선택하십시오. 전송 경로와 수신 경로의 담당자가 다르다면 두 방식을 함께 선택하십시오.
어느 쪽을 선택하든 같은 증거를 요청하십시오. 시험 경로, 처리량 할당량, 전달 확인 형식, 오류 코드 목록, 재시도 정책입니다. 세션은 [SMPP 설명](/ko/resources/learn/what-is-smpp/)에서, 운영 환경까지의 과정은 [연결 가이드](/ko/resources/guides/smpp-http-connection/)에서 다룹니다.
선택한 내용을 수치와 함께 기록하십시오. 피크 속도, 바인드당 윈도우, 콜백 타임아웃, 재시도 예산입니다. 이런 수치가 없는 결정은 선호에 불과합니다. 피크나 팀이 바뀌면 다시 검토하십시오.

### Check what you learned

**캠페인이 초당 40건으로 꾸준히 실행되고, 전달 확인이 같은 트랜시버 세션으로 도착해야 합니다. 어떤 전송 방식이 맞습니까?**

트랜시버 바인드를 사용하고, 충분한 수의 바인드와 속도에 맞춘 윈도우를 갖춘 SMPP입니다. HTTP도 이 트래픽량을 처리할 수 있지만, 전달 확인은 SMPP 세션이 아니라 콜백으로 도착합니다.

**콜백 엔드포인트가 응답하는 데 8초가 걸립니다. 무엇이 잘못됩니까?**

제공사가 타임아웃 후 재시도하므로 같은 이벤트가 다시 전달됩니다. 빠르게 응답하고, 응답한 뒤에 이벤트를 처리하십시오.

**응답 없는 바인드가 끊어진 바인드보다 왜 더 까다롭습니까?**

끊어진 바인드는 눈에 보이게 실패합니다. 응답 없는 바인드는 열려 있는 것처럼 보이므로, 타임아웃으로 드러날 때까지 클라이언트가 계속 전송합니다. 킵얼라이브 트래픽을 쓰면 더 일찍 발견할 수 있습니다.

## FAQ

**두 방식을 함께 운영할 수 있습니까?**

네. 많은 플랫폼이 마이그레이션 기간에 SMPP로 전송하고 HTTP로 콜백을 받습니다.

**어느 쪽이 더 빨리 연동됩니까?**

HTTP이며, 보통 반나절이면 됩니다. SMPP는 트래픽량이 지속 세션을 정당화할 만큼 커졌을 때 효과를 발휘합니다.

**어느 쪽이 더 안정적입니까?**

어느 쪽도 그 자체로 안정적이지는 않습니다. 안정성은 경로, 재시도 정책, 그리고 이를 둘러싼 운영에서 나옵니다.

**HTTP로 대량 트래픽을 처리할 수 있습니까?**

네. 동시성, 커넥션 풀링, 비동기 콜백을 사용하면 가능합니다. 다만 지속적인 흐름에는 세션과 전달 확인 채널이 이미 열려 있는 SMPP가 대개 더 효율적입니다.

**고정 IP가 필요합니까?**

SMPP는 제공사가 클라이언트 주소를 허용 목록에 등록하므로 고정 IP가 필요한 경우가 많습니다. HTTP 연동은 대개 그 대신 TLS와 키를 사용합니다. 구축 전에 요구 사항을 확인하십시오.

## Sources

- [smpp.org: SMPP 세션, PDU 동작 및 전달 확인](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110: HTTP 시맨틱](https://datatracker.ietf.org/doc/html/rfc9110) — Accessed: 2026-10-19
- [3GPP TS 23.040: 단문 메시지 서비스의 기술적 구현](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19