길리랩blog

SOAP·WSDL·UDDI로 이해하는 웹서비스 통합 구조

SOAP, WSDL, UDDI 기반 웹서비스의 계약 중심 통합 구조와 운영 거버넌스, RESTful API와의 차이를 정리한다.

2026-08-14 · 최초 발행 2025-10-14

이기종 시스템을 계약으로 연결하는 웹서비스

웹서비스는 네트워크에 연결된 애플리케이션이 표준화된 방식으로 메시지를 주고받고 기능을 호출하도록 만드는 분산 컴퓨팅 아키텍처다. SOAP, WSDL, UDDI 같은 표준 기술 스택을 이용해 플랫폼과 언어가 다른 시스템 사이의 상호운용성을 확보하고, 인터페이스 계약과 운영 거버넌스를 함께 다룬다.

핵심은 XML 기반 메시지, WSDL로 정의하는 계약 중심 인터페이스, UDDI 기반 서비스 검색·카탈로그 모델이다. 이 조합은 느슨한 결합과 기능 재사용을 지원하며, 조직 경계를 넘는 통합에도 쓰인다.

표준과 계약이 만드는 통합 방식

XML, SOAP 1.1/1.2, WSDL 1.1/2.0, UDDI 같은 공개 표준을 따르면 특정 플랫폼이나 언어에 종속되지 않고 연계할 수 있다. HTTP/S 전송을 선택할 수 있어 방화벽과 프록시가 있는 환경에도 맞추기 쉽고, 레거시 및 엔터프라이즈 환경에서의 적용성을 높인다.

XML과 XSD는 메시지 구조를 표현하고 확장하는 기반이다. WS-* 헤더 확장은 보안, 트랜잭션, 신뢰성 요구를 단계적으로 붙일 수 있게 한다.

WSDL은 구현체와 분리된 인터페이스 계약이다. 이 계약을 기준으로 메시지, 포트타입, 바인딩, 서비스 엔드포인트를 명세하므로 구현과 배포를 독립적으로 관리할 수 있다. 도구 기반 코드 생성과 Contract-First 개발에도 연결되며, 버전 관리와 하위 호환성 전략을 세울 때 변경 영향을 줄이는 데 도움이 된다.

UDDI는 서비스 카탈로그와 메타데이터 검색, 라이프사이클 관리를 위한 레지스트리다. SLA, 보안 정책, Logging/Audit 같은 운영 정책을 서비스 단위로 적용하는 데도 활용할 수 있다.

SOAP·WSDL·UDDI가 맡는 역할

SOAP은 분산 환경에서 정보를 교환하는 XML 기반 프로토콜이다. Envelope, Header, Body 구조를 가지며 요청·응답 패턴과 Fault 처리 방식을 규정한다. HTTP, JMS 등 전송 방식과 결합할 수 있고 WS-Security, WS-ReliableMessaging 같은 확장도 적용할 수 있다.

WSDL은 서비스가 제공하는 인터페이스를 기술한다. 메시지, 포트타입(인터페이스), 바인딩(프로토콜/인코딩), 서비스 엔드포인트가 주요 명세 대상이다.

UDDI는 서비스 정보를 목록화하는 XML 기반 레지스트리다.

  • White Pages는 기업과 서비스 제공자의 기본 정보를 담는다.
  • Yellow Pages는 산업 분류와 분류체계 기반 카테고리를 다룬다.
  • Green Pages는 기술 바인딩, 접근 URL, WSDL 참조처럼 실행에 필요한 상세 정보를 제공한다.

기업 통합에서 개방형 생태계로

웹서비스는 통합 범위가 넓어지면서 기폐반계 단계의 비즈니스 모델 전환을 지원한다. 기업통합모델(기)에서는 사내 EAI와 애플리케이션 통합을 중심으로 내부 효율을 높인다. 폐쇄적 비즈니스 모델(폐)은 사전 계약과 전용 네트워크를 전제로 제한된 파트너 B2B 연계를 운영한다.

반개방적 비즈니스 모델(반)에서는 인증된 제3자의 참여를 허용하고 파트너 마켓플레이스를 운영한다. 개방적 비즈니스 모델(계)은 공개 카탈로그와 표준 계약을 제공하며 생태계 참여자 간 가치 공동 창출을 지향한다.

서비스 검색부터 응답 처리까지

서비스 소비자는 요구사항, 서비스 키워드·분류, 보안 자격증명을 바탕으로 서비스를 찾는다. UDDI에서 정보를 조회하고 WSDL을 가져온 뒤 클라이언트 스텁을 생성한다. 이후 WS-Security를 적용한 SOAP 요청을 보내고, 서버는 비즈니스 로직과 트랜잭션을 처리해 SOAP 응답 또는 Fault를 반환한다. 이 과정의 로그와 메트릭은 운영 판단에 사용된다.

UDDI 조회가 실패하면 캐시된 WSDL을 사용하거나 페일오버 레지스트리를 선택할 수 있다. 스키마 검증 실패는 SOAP Fault로 돌려주며 리트라이 정책을 적용하지 않는다. 트랜잭션 경계가 필요할 때는 WS-AtomicTransaction을 적용하고, 타임아웃 초과 시 롤백한다.

⤢✕Service ProviderUDDI RegistryService ConsumerService ProviderUDDI RegistryService Consumeralt[유효성 검증 실패][정상 처리]서비스 검색(키워드/분류)WSDL URL 반환WSDL 획득(HTTP GET)스텁 생성/스키마 검증SOAP 요청(WS-Security, TLS)SOAP Fault(XSD Validation Error)비즈니스 로직/트랜잭션 처리SOAP 응답로깅/메트릭, 리트라이 판단

통합 환경에서의 활용

사내 EAI와 레거시 시스템을 감쌀 때는 메인프레임이나 ERP 기능을 SOAP 서비스로 제공하고 업무 프로세스 오케스트레이션을 구성할 수 있다. 스키마를 표준화하면 중복 연계를 줄이고 변경 영향을 제한할 수 있다.

금융, 제조, 유통의 B2B 연계에서는 주문·정산·재고 조회용 표준 인터페이스를 제공해 파트너 온보딩 리드타임을 단축한다. 서명, 암호화, 타임스탬프 같은 보안 요구사항과 규제 준수도 함께 지원한다.

공공·전자정부 환경에서는 기관 간 민원·행정 데이터 교환을 표준화하고 상호 인증 체계를 적용할 수 있다. 변경 관리와 감사 추적을 중앙화해 가시성을 높이는 방식이다.

신규 파트너 연계 리드타임은 3050% 단축되고, 변경 배포 실패율은 2035% 감소하는 효과가 제시된다. 재사용률 증가에 따라 개발 공수는 15~30% 절감되며, 장애 평균 복구시간(MTTR)은 20% 개선된다. 표준 기반 거버넌스는 품질과 보안의 일관성을 뒷받침하고, 계약 중심 인터페이스는 팀 간 의존성을 낮춰 조직 민첩성 향상에 기여한다.

보안과 운영의 대가

TLS는 필수로 적용하고 메시지 수준에서는 WS-Security의 서명·암호화·토큰 적용을 권장한다. 무결성과 부인방지를 강화할 수 있지만 메시지 크기와 CPU 부하가 늘어 성능 튜닝이 필요하다.

XSD 검증을 강제하고 네임스페이스 및 미호환 변경을 금지하는 준칙을 둔다. vMajor/minor 체계로 버전을 운영하면 계약 변경을 통제하기 쉽지만, 변경 속도가 제한되고 초기 거버넌스 비용이 증가한다.

전송 신뢰성은 WS-ReliableMessaging 또는 지수 백오프와 멱등성 키 설계로 확보할 수 있다. 구현 복잡도는 올라가지만 전송 신뢰성은 높아진다.

Correlation ID, 분산 트레이싱, 중앙 로그·메트릭 수집은 관측성과 감사에 필요하다. PII 마스킹을 지켜야 하며, 저장 비용과 분석 부담도 함께 고려해야 한다. UDDI 또는 API 카탈로그로 메타데이터를 일원화하면 사용성과 재사용성을 높일 수 있지만, 메타데이터 품질을 관리할 책임과 운영 프로세스가 필요하다.

SOAP 기반 웹서비스와 RESTful API의 차이

지표 SOAP 기반 웹서비스 RESTful API
성능 XML 파싱·WS-* 오버헤드로 상대적 비용 높음 JSON/경량 프로토콜 채택 시 낮은 오버헤드
확장성 스키마·정책 기반 확장 용이, 메시지 크기 이슈 존재 수평 확장 용이, 캐싱 친화성 우수
일관성 계약(WSDL) 중심 강한 스키마 일관성 리소스 모델·스키마 유연성 높음
안정성 WS-RM·트랜잭션 등 신뢰성 기능 풍부 단순 재시도/멱등성 기반 안정성 확보
운영 편의 도구 기반 스텁·정책 관리, WS-* 복잡도 간결한 운영, 버전·문서 관리 중요

Python zeep로 SOAP 호출하기

전제조건은 Python 3.10+, pip install zeep, 인터넷 접속 가능 환경이다. 대상 WSDL은 가용성이 변동할 수 있는 예시 공개 서비스다.

# 환경: Python 3.10+, pip install zeep
from zeep import Client
from zeep.wsse.username import UsernameToken

WSDL = "http://www.dneonline.com/calculator.asmx?WSDL"  # 공개 데모 서비스
client = Client(wsdl=WSDL)

# 간단 연산 호출 예시
result = client.service.Add(intA=7, intB=5)
print("Add result:", result)  # 예상 출력: 12

# WS-Security(UsernameToken) 필요 시 예시
# secure_client = Client(wsdl=WSDL, wsse=UsernameToken('user', 'pass'))

WSDL은 다음처럼 서비스 계약을 표현한다.

<definitions name="Calculator"
             targetNamespace="http://tempuri.org/"
             xmlns:tns="http://tempuri.org/"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types>
    <xsd:schema targetNamespace="http://tempuri.org/"/>
  </types>
  <message name="AddRequest">
    <part name="intA" type="xsd:int"/>
    <part name="intB" type="xsd:int"/>
  </message>
  <message name="AddResponse">
    <part name="AddResult" type="xsd:int"/>
  </message>
  <portType name="CalculatorSoap">
    <operation name="Add">
      <input message="tns:AddRequest"/>
      <output message="tns:AddResponse"/>
    </operation>
  </portType>
  <binding name="CalculatorSoap" type="tns:CalculatorSoap">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
  </binding>
  <service name="Calculator">
    <port name="CalculatorSoap" binding="tns:CalculatorSoap">
      <soap:address location="http://www.dneonline.com/calculator.asmx"/>
    </port>
  </service>
</definitions>

고도 보안, 트랜잭션, 신뢰성 요구가 큰 통합 환경에서는 SOAP 기반 웹서비스가 계약과 정책 중심의 운영 구조를 제공한다. 다만 XML과 WS-*에서 생기는 성능 비용 및 복잡도를 감안해 운영 설계를 잡아야 한다.

웹서비스SOAPWSDLUDDISOA