UDDI — 서비스를 게시·검색·바인딩하던 표준 레지스트리

서비스가 수십 개를 넘어가면 "이 기능은 어느 서비스가 제공하는가"라는 질문에 답할 방법이 필요해진다. 2000년대 초반 SOA 진영이 이 문제에 내놓은 답이 UDDI(Universal Description Discovery and Integration)였다. 서비스 제공자가 자신의 기술·비즈니스 정보를 표준 형식으로 등록하면, 소비자는 표준 API로 그것을 찾아 바로 호출까지 이어갈 수 있게 설계된 레지스트리다.

등록하고, 찾고, 연결한다

UDDI는 웹 서비스의 기술·비즈니스 메타데이터를 레지스트리에 저장하고 게시(Publish)·검색(Discover)·바인딩(Bind)이라는 표준 API로 다루는 OASIS 표준이다. 흐름은 단순하다. 서비스 제공자가 메타데이터를 게시하면, 소비자가 이를 질의·검색하고, 검색 결과로 받은 바인딩 정보를 가지고 실제 서비스를 호출한다.

businessEntity에서 tModel까지, 데이터가 쌓이는 구조

데이터 모델은 businessEntity(조직)·businessService(서비스)·bindingTemplate(엔드포인트)·tModel(기술 지문)이 계층과 참조 관계로 얽혀 있다. 고유 키와 분류 체계(keyedReference/identifierBag)로 기술 표준, 버전, NAICS/UNSPSC 같은 산업 분류를 표현한다.

API는 SOAP/HTTP 기반의 표준 오퍼레이션으로 제공된다. save_business, save_service, find_service, get_bindingDetail 같은 이름이 대표적이고, 게시 시점에는 유효성 검사·트랜잭션 경계·액세스 제어 정책이 함께 걸린다.

tModel은 WSDL, XML 스키마, 정책 같은 인터페이스 규약을 추상화해 재사용하고 표준 준수 여부를 판단하는 단위다. 기술 버전과 호환성 메타데이터가 여기에 체계적으로 연결된다.

배포 모델은 퍼블릭 레지스트리와 프라이빗(엔터프라이즈) 레지스트리를 모두 지원했고, UDDI v3에서는 레지스트리 복제, 구독/알림, 디지털 서명 기능이 추가됐다. 상호운용성은 WS-Security·WS-Policy 같은 WS-* 스택과 결합한 인증·무결성·정책 부과로, 그리고 디렉터리 스키마의 고정성과 SOAP 기반 표준 인터페이스로 이기종 환경 간에 확보됐다.

게시부터 호출까지, 한 번의 요청이 지나가는 길

⤢✕

게시 쪽은 유효성 검사·트랜잭션·키 발급을 거치고, 질의 쪽은 결과를 캐시하거나 폴백 경로를 두는 편이 안전하다. 레지스트리 복제 전파가 지연되면 일시적으로 읽기-쓰기 불일치가 생길 수 있어, 클라이언트에 재시도·백오프 전략을 넣어야 한다.

실제로 어디에 쓰였나

엔터프라이즈 SOA 서비스 카탈로그에서는 중앙 레지스트리로 서비스 메타데이터·버전·분류 체계를 일원화하고, 배포 파이프라인에 게시 자동화와 승인 워크플로우를 연결했다.

규제 산업의 거버넌스·감리에서는 tModel과 taxonomy 같은 표준 분류체계로 컴플라이언스 태깅과 감사 추적성을 확보했고, 변경 이력·의존성 맵으로 영향도 분석을 자동화했다.

이기종·B2B 통합에서는 파트너 간 WSDL·정책 같은 기술 계약을 공유하고 바인딩 템플릿을 교환했다. 엔드포인트가 바뀌거나 장애가 나도 소비자 쪽에서 무코드로 대응할 여지가 있었다.

지금은 이 개념이 API 카탈로그(포털), 서비스 디스커버리(Consul/Eureka), 서비스 메시(Envoy)의 메타데이터 모델로 재구성돼 있다. tModel의 자리는 OpenAPI/AsyncAPI 스키마 레지스트리가 이어받아 지속적 검증 체계를 만든다.

재사용률과 리드타임으로 본 도입 효과

중복 서비스 개발 건수가 2040% 줄어드는 재사용률 향상, 서비스 검색부터 바인딩까지 평균 소요시간이 3060% 단축되는 탐색·온보딩 리드타임 개선이 UDDI 도입 효과로 제시된다. 의존성이 눈에 보이면서 배포 실패율이 15~25% 감소하는 변경 리스크 완화, 감사 증적 수집 시간이 50% 이상 줄어드는 감리 대응 효율도 함께 보고된다.

UDDI v3와 현대 대안을 나란히 보면

항목	UDDI v3 레지스트리	현대 서비스 디스커버리(Consul/Eureka 등)	API 카탈로그/게이트웨이
성능	SOAP/HTTP 및 XML 파싱 오버헤드 존재	경량 HTTP/gRPC, 인-메모리 인덱스로 저지연	관리 UI/정책 엔진 포함으로 오버헤드 중간
확장성	복제/동기화 지원이나 운영 복잡도 높음	수평 확장 용이, 헬스체크 내장	멀티리전 지원, 카탈로그 샤딩으로 확장
일관성	복제 지연에 따른 최종적 일관성 패턴 빈번	리더-팔로워 또는 AP 선택 가능	카탈로그-게이트웨이 캐시로 조정 가능
안정성	표준 기반 신뢰성 높으나 동적 환경 민감	장애 감지/자동 제거로 회복력 우수	정책/레이트리밋/재시도로 보호 강함
운영 편의	스키마·분류 관리 부담, SOAP 툴링 필요	에이전트 기반 자동 등록, DevOps 친화	UI 포털·승인 흐름·마켓플레이스 기능 제공

표준 분류와 승인 절차, 그 사이의 대가

표준 분류·명명 규칙을 세우고 필수 메타데이터 스키마를 정의하는 것이 출발점이다. 게시 파이프라인에는 OpenAPI/Schema lint 같은 자동 유효성 검사를 넣고, 역할 기반 액세스 제어·서명/무결성 검증·감사 로깅을 일원화한다. 복제 토폴로지는 단순하게 유지하고 SLA 기반 헬스체크·재시도 전략을 세워야 한다. 다만 엄격한 스키마·승인 절차는 초기 온보딩 속도를 떨어뜨릴 수 있고, 동적인 마이크로서비스 환경에서는 등록·해제가 잦아 오버헤드가 커진다. SOAP 중심 툴링과 운영 지식이 요구되는 것도 현대 HTTP/JSON 생태계와의 간극으로 남는다.

원칙은 남고 구현은 바뀌었다

UDDI의 핵심 가치는 서비스 메타데이터 표준화, 게시·발견 절차화, 거버넌스 강화에 있었다. 마이크로서비스·클라우드 네이티브 환경이라면 이 원칙 자체를 API 카탈로그·서비스 디스커버리·서비스 메시로 재구현하는 접근이 현실적이다. 규제 산업이나 엄격한 표준 준수, 이기종 통합이 많은 엔터프라이즈 환경이라면 UDDI 방식이 여전히 적합하지만, 현대적 인터페이스와의 하이브리드 운영을 함께 설계해야 한다.