SOAP — 계약과 정책으로 통신을 보증하는 XML 메시징 프로토콜
SOAP의 Envelope/Header/Body 구조와 WS-* 확장 스택으로 보안·신뢰성·트랜잭션을 보장하는 메시징 프로토콜의 개념과 운영 실무를 정리한다
2026-08-13 · 최초 발행 2025-12-03
REST API가 표준이 된 지 오래지만, 은행 코어 시스템이나 공공기관 연계 사업에서는 여전히 SOAP 계약서를 받아 드는 일이 흔하다. 메시지 하나하나에 서명이 붙고, 실패하면 정해진 형식의 오류가 돌아오고, 전송이 끊겨도 재전송 규칙이 정해져 있어야 하는 자리이기 때문이다. SOAP(Simple Object Access Protocol)은 이런 요구를 표준으로 묶어낸 XML 기반 메시징 프로토콜이다.
Envelope 안에서 벌어지는 일
SOAP 메시지는 Envelope/Header/Body/Fault로 구성이 고정된다. Envelope가 메시지의 경계를 잡고, Header는 보안·주소·정책 같은 메타데이터를 실어 나르며, Body는 실제 페이로드를 담는다. 오류가 나면 Fault가 표준화된 형식으로 원인을 표현한다. 이 구조는 XML Schema로 타입을 검증하고 네임스페이스로 충돌을 관리하는데, 스키마가 바뀌는 시점마다 버전 호환성 전략을 따로 세워야 한다.
전송 방식도 특정 프로토콜에 묶이지 않는다. HTTP/HTTPS는 물론 SMTP, JMS 같은 메시지 브로커 위에서도 동작해서 방화벽·게이트웨이·브로커를 넘나드는 통합에 잘 맞는다.
계약이 먼저, 코드는 그다음
SOAP 서비스의 인터페이스는 WSDL(Web Services Description Language)로 먼저 명세한다. 어떤 오퍼레이션을 제공하는지, 메시지 타입이 무엇인지, HTTP나 JMS 중 어디에 바인딩되는지를 계약으로 고정한 뒤에야 구현이 시작되는 계약 우선(contract-first) 방식이다. 이 계약을 wsimport·svcutil·wsdl2java 같은 도구에 넣으면 클라이언트·서버 스텁이 자동 생성되고, 팀 간 타입 매핑과 예외 처리가 일관되게 맞춰진다.
보안·정책·신뢰성을 표준으로 얹다
SOAP 자체는 메시지 봉투일 뿐이고, 실제 엔터프라이즈 요구사항은 WS-* 확장 스택이 채운다. WS-Security는 서명·암호화·토큰(SAML, UsernameToken)으로 메시지 레벨 보안을 종단 간 보장한다. WS-Policy와 WS-Addressing은 정책 협상과 주소 지정을 표준화하고, WS-ReliableMessaging은 중복 제거·순서 보장·재전송을 제어한다. 분산 트랜잭션이 필요하면 WS-Transaction/WS-Coordination을 얹어 보상 트랜잭션까지 설계할 수 있다. 이기종 스택(.NET, Java, 메인프레임) 간 호환성은 WS-I Basic Profile을 따르는 구현 가이드와 상호운용 테스트로 확보한다.
요청 하나가 지나가는 경로
검증 실패는 Fault로 떨어지고, WS-RM이 걸려 있으면 재시도 큐로 들어간다. 멱등 연산인지 아닌지를 구분하고 중복 감지 키를 붙여야 재전송이 부작용을 만들지 않는다.
어디서 아직 SOAP을 고르는가
금융·공공 규제 환경은 메시지 무결성·부인방지·감사 추적을 요구하므로 WS-Security의 서명·암호화·타임스탬프가 사실상 필수다. 사전 검증을 도입하면 인터페이스 오류가 30% 이상 줄어드는 사례가 보고되는데, 이 수치는 현장별 지표 설계가 뒤따라야 한다는 전제가 붙는다. 메인프레임(CICS)·ERP·SI 패키지 같은 이기종 레거시 연계에서는 WSDL 계약이 장기 유지보수를 쉽게 만들어준다. 파트너 간 신뢰성과 순서 보장이 필요한 B2B/ESB 허브에서는 WS-RM과 JMS 바인딩을 함께 쓰고, 메시지 손실률을 0%에 가깝게 설계하는 목표를 세우기도 하지만 이는 브로커·네트워크 상태에 크게 좌우된다. 의료·보험처럼 대용량 첨부가 오가는 문서 교환에는 MTOM/XOP로 바이너리를 효율적으로 실어 나른다.
계약 우선으로 구현이 흘러가는 순서
- XML Schema와 네임스페이스·버전 정책을 먼저 설계하고 WSDL 계약 초안에 WS-Policy를 명시한다.
- WS-Security 프로파일(서명·암호화 알고리즘)과 토큰 유형을 정하고, TLS·상호 인증(mTLS)·키 관리(KMS/HSM) 계획을 세운다.
- wsimport·svcutil·wsdl2java로 클라이언트/서버 스텁을 생성하고, Fault 예외 모델과 멱등성 키·상관 ID를 설계한다.
- HTTP/HTTPS 또는 JMS 바인딩을 고르고 큐·토픽을 설계한 뒤 API 게이트웨이/ESB 라우팅과 스로틀링·캐싱 정책을 붙인다.
- WS-I Test Tools로 스키마·서명·타임스탬프 유효성을 검증하고, 부하·장애·재시도·순서 보장 시나리오를 테스트한다.
- 헤더 상관 ID로 메시지를 트레이스하고 대기열 적체를 알림으로 잡으며, 성공률·지연시간·Fault 코드별 실패 유형을 SLO 대시보드로 관리한다.
운영에서 부딪히는 트레이드오프
메시지 레벨 보안과 TLS를 이중으로 구성하고 키·인증서 회전을 자동화하는 것이 기본이다. 재플레이 공격은 Nonce+Timestamp로 막고 클록 스큐 허용 범위를 정해둔다. WS-RM의 재전송·순서 보장은 지연을 늘릴 수 있으므로 중요 트랜잭션에만 선택적으로 적용하고, MTOM·압축·Keep-Alive·커넥션 풀·XML 스트리밍(StAX)으로 파싱 비용을 줄인다. 스키마는 확장 포인트(any)와 선택 필드(minOccurs=0)로 호환성을 유지하고, 계약이 바뀌면 신규 네임스페이스로 병행 운영해 소비자 영향을 최소화한다. 결국 강한 계약·보안·신뢰성·상호운용성이라는 장점과 XML 오버헤드·복잡한 툴체인·운영 디버깅 비용이라는 단점을 맞바꾸는 선택이다.
Python으로 SOAP 서비스 호출해보기
전제조건은 Python 3.11+, pip, 그리고 네트워크에서 WSDL에 접근 가능한 환경이다. pip install zeep requests로 준비한다.
# 환경: Python 3.11, zeep==4.*, requests==2.*
from zeep import Client, Settings
from zeep.transports import Transport
from zeep.exceptions import Fault
from requests import Session
from requests.auth import HTTPBasicAuth
WSDL_URL = "https://example.com/service?wsdl"
session = Session()
session.verify = True # 사설 CA 사용 시 CA 번들 지정
session.auth = HTTPBasicAuth("user", "pass")
settings = Settings(strict=True, xml_huge_tree=True)
transport = Transport(session=session, timeout=10)
client = Client(wsdl=WSDL_URL, settings=settings, transport=transport)
try:
# 계약에 정의된 오퍼레이션과 파라미터 사용
resp = client.service.GetCustomer(id=12345)
print(resp)
except Fault as e:
# SOAP Fault 표준 처리
print(f"SOAP Fault: {e.message}")세션과 커넥션 풀을 재사용하고, WS-RM을 안 쓰는 구간이라면 애플리케이션 레벨에서 타임아웃·재시도 정책을 따로 구현해야 한다. 로그에는 WS-Addressing의 MessageID/RelatesTo 같은 상관 ID를 남겨야 나중에 요청을 추적할 수 있다.
SOAP·REST·gRPC를 나란히 보면
| 항목 | SOAP | REST | gRPC |
|---|---|---|---|
| 성능 | XML 파싱/헤더로 오버헤드 큼. MTOM/압축으로 완화 | 경량 JSON/HTTP/캐싱으로 일반적 우수 | 바이너리(Protobuf)로 최고 성능 및 저지연 |
| 확장성 | WS-* 정책·보안·신뢰성 확장 용이 | 하이퍼미디어/버전 전략 중심 | 스트리밍·양방향·로드 밸런싱 용이 |
| 일관성(계약) | 강한 스키마/WSDL 계약 | 스키마 느슨, OpenAPI로 보강 | 강한 IDL(Protobuf) 계약 |
| 안정성/신뢰성 | WS-RM/트랜잭션으로 고신뢰 | 전송 재시도·일부 패턴 자체 구현 | HTTP/2 스트리밍, 리트라이/데드라인 내장 가능 |
| 운영 편의 | 도구/정책 복잡, 관측성 설계 중요 | 단순, 광범위 툴 지원 | 고성능이나 디버깅/게이트웨이 구성 난이도 |
핵심 트랜잭션에 좁혀 쓴다
SOAP은 강한 계약·보안·정책·신뢰성이 필요한 엔터프라이즈·규제 도메인에서 여전히 유효한 선택지다. 계약 우선 설계를 지키되 WS-* 확장은 필요한 만큼만 최소로 도입하고, 전송·보안·신뢰성은 단계적으로 얹는 편이 낫다. 성능과 운영 복잡성이라는 대가를 감안하면, 시스템 전체가 아니라 감사·규제·신뢰성이 실제로 걸린 핵심 트랜잭션에만 적용을 좁히는 전략이 현실적이다.