UDDI로 관리하는 웹서비스 레지스트리와 SOA 거버넌스

서비스를 호출하려면 주소만 알아서는 부족하다. 어떤 조직이 제공하는지, 어떤 기술 규약을 따르는지, 현재 사용할 수 있는 바인딩이 무엇인지까지 찾아야 한다. UDDI(Universal Description, Discovery and Integration)는 이 정보를 표준 XML 형식으로 등록하고 검색하기 위한 웹서비스 레지스트리다.

WSDL과 SOAP 기반 서비스 환경에서 UDDI는 서비스의 위치·바인딩·분류 정보를 연결해, 이기종 플랫폼 사이의 상호운용성을 뒷받침한다. 표준 API는 SOAP over HTTP로 제공된다.

서비스 정보를 페이지별로 나누는 방식

UDDI는 레지스트리 정보를 성격에 따라 White Page, Yellow Page, Green Page로 구분한다. White Page에는 기본 식별정보를, Yellow Page에는 분류와 산업코드 같은 기업 상세정보를, Green Page에는 서비스 스펙과 바인딩 정보를 둔다.

이 구분은 식별정보에서 분류정보, 기술 스펙으로 이어지는 계층을 만든다. 검색하는 쪽은 목적에 맞는 페이지 범위를 선택해 결과를 필터링할 수 있다.

레지스트리를 구성하는 주요 데이터 구조는 다음과 같다.

BusinessEntity: 업체 또는 개체
BusinessService: 제공 서비스
BindingTemplate: 엔드포인트, 프로토콜, 보안 정보
tModel: 기술 스펙 메타데이터
PublisherAssertion: 파트너 관계

운영상태와 예약 정보, 전자서명 같은 거버넌스 필드도 지원한다. XML 표현과 SOAP/HTTP API, NAICS·UNSPSC 등의 분류체계를 활용하므로 플랫폼이 달라도 정보를 일관되게 관리할 수 있다. 레지스트리 간 연계와 복제도 가능하다.

게시 요청이 서비스 호출로 이어지는 흐름

서비스 제공자는 WSDL URL, 분류코드, 조직정보와 보안자격 증명을 등록한다. 레지스트리는 WSDL 파싱과 스키마 규칙으로 유효성을 확인하고, 승인·서명·저장·인덱싱을 거쳐 서비스 키와 바인딩 키, 검색 가능 상태, 감사 로그를 남긴다.

⤢✕

등록은 원자적으로 커밋하고, 인덱싱은 비동기로 최적화할 수 있다. 실패하면 롤백과 감사 로그 기록이 필요하다. 스키마 위반, 서명 불일치, 중복 키 충돌, 사용할 수 없는 엔드포인트에는 재시도 또는 격리 정책을 적용한다.

검색은 find_xxx와 get_xxx 쿼리로 수행한다. 키워드, categoryBag, tModelKey를 기준으로 찾고 페이징과 정렬을 적용할 수 있다. 결과는 서비스 키와 바인딩 정보를 반환하므로 소비자가 실제 호출 단계로 연결할 수 있다.

SOA 카탈로그와 파트너 통합에서의 역할

엔터프라이즈 SOA 환경에서는 내부 수백 개 SOAP/WSDL 서비스를 표준화된 방식으로 검색하고 재사용하는 서비스 카탈로그로 쓸 수 있다.

B2B 통합에서는 거래처 API 엔드포인트와 계약된 보안 프로파일을 tModel로 표준화해 온보딩 시간을 줄인다. 레거시 환경에서는 기존 ESB/SOAP 자산을 Private UDDI에 정리하고 API Gateway와 메타데이터를 동기화하는 브리지 역할도 가능하다.

변경이력, 전자서명, 승인흐름을 남기면 규제와 감사 대응을 위한 컴플라이언스 증빙에도 활용할 수 있다.

공개 범위에 따라 달라지는 운영 특성

유형	접근성	보안	거버넌스/일관성	확장성	운영 편의	주요 사용처
Public	전 세계 공개	낮음~중간	제한적	높음	쉬움	공개 표준/테스트
Private	조직 내부	높음	강함	중간~높음	중간	엔터프라이즈 SOA
Semi-Private	검색 공개/등록 제한	중간	중간	중간	중간	파트너 생태계

Public UDDI는 역사적으로 축소 추세다. 최신 도입 시에는 최신 정보 확인이 필요하며, Private 또는 Semi-Private 중심의 운영이 권장된다.

분류와 승인 체계를 운영에 연결하기

분류체계는 산업코드와 도메인 태깅 가이드, tModel 재사용 규칙까지 포함해 표준화한다. 퍼블리셔 역할, 4-eyes 승인, 키 로테이션 정책을 두고 등록의 무결성을 관리한다.

수명주기는 등록, 검증, 승인, 배포, 사용중, 폐기 흐름으로 관리하며 버전과 호환성도 명시한다. 복제 노드와 주기 백업, 인덱스 재빌드 절차, 헬스체크 연동은 가용성과 복구를 위한 운영 항목이다. 등록·조회 감사 로그, 엔드포인트 상태 모니터링, 조회 성공률과 평균 탐색시간 같은 품질 메트릭도 함께 관측한다.

이 체계는 초기 비용과 거버넌스 부담을 늘리고 조직 성숙도를 요구한다. REST/OpenAPI, 서비스 메시(Consul/Eureka/Envoy)와 기능이 겹칠 수 있으므로 혼합 아키텍처의 역할 분담이 필요하다.

UDDI v3 Inquiry API로 서비스 찾기

전제: UDDI v3, SOAP over HTTP, Inquiry API 엔드포인트 https://uddi.example.com/inquiry

서비스 검색(find_service)은 다음과 같이 요청할 수 있다.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:uddi="urn:uddi-org:api_v3">
  <soapenv:Body>
    <uddi:find_service maxRows="10">
      <uddi:name>Invoice*</uddi:name>
      <uddi:categoryBag>
        <uddi:keyedReference tModelKey="uddi:uddi.org:categorization:types"
                             keyName="industry"
                             keyValue="NAICS:541512"/>
      </uddi:categoryBag>
    </uddi:find_service>
  </soapenv:Body>
</soapenv:Envelope>

get_serviceDetail로 바인딩 상세를 조회해 엔드포인트를 얻은 뒤 WSDL/SOAP 호출로 이어간다.

서비스 재사용과 감사 대응에 남는 효과

서비스 검색과 검증을 자동화하면 탐색·온보딩 시간이 평균 50~~80% 감소한다. 재사용이 늘면서 중복 개발은 20~~40% 감소하고 유지보수 비용을 절감할 수 있다.

잘못된 엔드포인트나 스펙 사용을 줄이면 호출 실패율은 30%+ 개선된다. 서명과 감사 추적성을 확보해 컴플라이언스를 강화하고 감사 대응 시간도 단축할 수 있다.

SOAP/WSDL 자산이 남아 있거나 파트너 통합 요구가 있는 조직이라면 UDDI를 점진적으로 도입할 수 있다. REST 중심 환경에서는 UDDI가 맡던 메타데이터 관리와 발견 기능을 API Gateway, 서비스 디스커버리와 어떻게 나눌지 먼저 정해야 한다.