메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

IT/모바일

UBL(Universal Business Language)에 대한 높은 기대감

한빛미디어

|

2001-11-16

|

by HANBIT

7,801

By Edd Dumbil DocBook, ebXML, RELAX NG를 포함하는 XML 기반의 산업용 스팩을 개발하는 국제적 컨소시엄인 OASIS는 최근 UBL(Universal Business Language)의 개발을 도모하는 새로운 기술 위원회(Technical Committee)의 설립을 발표했다. 산업용 XML 스펙과 관련된 신조어의 홍수 속에 살고 있는 사람들에게 또다른 XML 언어와 관련된 소식이 전혀 새롭게 느껴지지 않을지도 모른다. 그러나 이번만큼은 다음과 같은 두 가지 이유로 차별성을 지니게 된다. 첫째는 UBL이 XML 스펙에 덧붙여지는 것이 아니라 혼란스러운 현재 상황을 청산하는데 목적을 두고 있기 때문이며 둘째는 UBL의 선도자가 W3C에서 XML 1.0 개발에 최고 전문가였던 존 보삭(Jon Bosak)이라는 점이다. 아래의 기사는 새로운 UBL 활동과 관련한 존 보삭과의 인터뷰 내용으로 ebXML과의 관계 및 지적 재산권과 관련된 현재의 상황에 대해 다루고 있다. 에드 덤빌: 어떤 이유로 UBL 설립에 노력을 기울이셨습니까? 존 보삭: 기본적으로 두 가지라고 볼 수 있습니다. 첫째는 현재 XML 비즈니스 논리가 가지고 있는 복잡성(cXML, xCBL, RosettaNet, OAGIS 등등...)의 문제가 시스템 관리자와 IT 종사자들에게 골칫거리가 되었다는 것입니다. 이러한 복잡성은 포맷 간에 차이를 번역해줄 수용자에 대한 수요를 증가 시켰기 때문에 전문적인 서비스와 변형 소프트웨어를 판매하는 회사에게는 상당한 이익이 있었지만 그 이외의 사람들에겐 고통만 가져다 주었으며 기술적으로도 완전히 쓸모없는 것들이었습니다. 디트로이트의 자동화 산업에서 나타나는 구매 주문과 브라질의 신발 산업에서 나타나는 구매 주문이 서로 똑같지 않다는 것을 설명할 이유는 많이 있습니다. 그렇지만 똑같은 일을 하는 신발 제조업체가 왜 상이한 구매 주문 포맷을 사용하는지 그리고 그 두 제조업체와 사업을 하기위해 도매상이 거래를 수월하게 해줄 소프트웨어를 구입해야만 하는지에 대한 이유는 설명할 수 없습니다. 동종업계간 사업 운영은 같은 포맷의 데이터 표현을 사용 할 수 있어야 합니다. UBL을 사용하는 두 번째 이유는 기존의 비즈니스 프로세스로부터 전자 상거래로 세계적 전환을 시작했기 때문입니다. 이제까지는 거대한 다국적 기업이 서로 어떤 방법으로 거래를 하느냐에 초점이 맞추어져 있었습니다. 반면에 작은 회사들이 동일한 가상 비즈니스 환경에서 어떻게 경쟁하는냐에 대한 관심은 상대적으로 작았습니다. 사실 전 세계 비즈니스의 대부분은 작은 회사에서 이루어지는 데도 말입니다. 나는 GM이 백만 개의 시트 커버를 납품할 입찰 공고를 내면 5명으로 구성된 파키스탄의 섬유 제조업자도 입찰을 할 수 있게 하고 싶습니다. 입찰 당사자 모두가 이러한 거래 과정을 볼 수 있다면 둘 다 이득을 보는 것이며 바로 이런 상황이 내가 의도하고 바라는 것입니다. 나는 지난 4,000여년간 이미 우리가 국제 교역 시스템을 이룩했다는 사실을 대다수의 기술자들이 간과하고 있다고 생각합니다. 만약 우리가 이와 같은 변화 속에서 성공하고 싶다면 서서히 증량시키는 접근 방식을 채택해야만 한다고 생각합니다. 객체라는 측면에서 생각해 볼 때 기존 시스템이 전혀 다른 것으로 대체되어서는 안됩니다. 쉽게 자동화 될 수 있는 부분부터 서서히 자동화를 진행시키는 것이 시스템에 있어 더 효율적이죠. 기본적인 비즈니스 문서의 XML 버전을 표준화하는 것은 이러한 것을 하는 가장 쉬우면서도 빠른 방법입니다. 그리고 부담할 수 없을 정도로 고가인 신기술에 투자한다거나 거대한 독점 소프트웨어 벤더에게 전 사업체를 위임하는 위험부담 없이 영세한 업체가 살아 남을 수 있는 유일한 방법이라고 볼 수 있습니다. 에드 덤빌: UBL을 구축한 의도는 무엇입니까? 존 보삭: UBL은 기존의 XML 비즈니스 문서 라이브러리의 복합어가 될 "범용 비즈니스 언어"가 될 것입니다. 우리는 xCBL 3.0이 이미 널리 배포되어 법적인 문제 없이 자유롭게 사용되고 있기 때문에 xCBL 3.0으로 시작하려고 합니다. 그리고 이렇게 시작된 xCBL 3.0을 조금씩 변경함으로써 UBL로 진화시킬 것입니다. 널리 사용되고 있는 다른 XML 비즈니스 언어, EDI와 ebXML에서 이루어지는 핵심 컴포넌트 데이터 사전 작업이 있는 라인과 함께 xCBL을 정렬시키는 작업이 UBL로의 전환이 되겠지요. 이러한 작업의 결과는 XML 비즈니스 논리의 표준이 될 것입니다. 따라서 어떤 소유권의 문제나 특권 사용료 지불의 문제 없이 누구나 어디에서도 다운로드해서 사용할 수 있게 될 것입니다. 에드 덤빌: 그렇다면 ebXML의 실패로 UBL이 개발되었다는 말입니까? 존 보삭: 아니오, 전혀 그런 뜻은 아닙니다. ebXML은 비즈니스 프로세스 모델링, 핵심 컴포넌트 정의, 몇몇 임계 인프라스트럭처 스펙의 개발에만 집중되어 있었습니다. 전달체로서 특정 XML 비즈니스 논리의 개발과는 거리가 멀었죠. 사실 ebXML는 특정 XML 문법과 중립적인 관계에 있습니다. 첫 단계의 종료시점인 2001년 5월에 ebXML 은 XML 기반의 전자 상거래를 위한 최초 인프라스트럭처의 기본 컴포넌트(총 3가지: XML 메시징을 위한 스펙, 교역 파트너 동의를 위한 스펙, 레지스트리를 위한 스펙)를 고안해냈습니다. 이러한 3가지 스펙은 이제 OASIS 기술 위원회에서 관리합니다. 이 세가지 스펙은 각기 따로 또는 3개가 함께 사용될 수 있게끔 설계되었습니다. 그렇지만 전자 상거래의 완벽한 출발을 위해서는 2개의 스펙을 더해야 한다고 생각합니다. 이 두 스펙은 XML 비즈니스 문서의 표준이며 이러한 문서를 교환하는 방법의 표준입니다. UBL은 표준 문서를 제공하는 것을 의도하고 있습니다. 에드 덤빌: UBL이 실행되는데 시간이 어느 정도 걸릴 것 같습니까? 존 보삭: UBL은 성취해야 할 두 가지 커다란 임무가 있습니다. 첫째는 xCBL로부터 계승받은 어휘와 이 프로세스로의 다른 입력 어휘(EDI, ebXML, cXML, RosettaNet, OAGIS 등등…)를 정렬하는 것입니다. 둘째는 특정 업계에서 사용되는 구매 주문이라도 핵심 라이브러리에 있는 일반 구문에 적용되어 사용 할 수 있는 컴포넌트 어셈블리를 구현하는 것입니다. 만약 이 두 가지를 연속해서 수행한다면 지금 현재 예상할 수 있는 최단 시간은 각각의 프로젝트를 끝내는데 1년 씩 총 2년이라는 계산이 나옵니다. 하지만 이 두 가지를 병행해서 수행할 수 있다면 1년에서 2년 정도의 시간이 걸릴 것으로 예상됩니다. 에드 덤빌: 언뜻 보니까 마이크로소프트가 최초 위원회 멤버 리스트에는 없던데요. 마이크로소프트가 이 위원회에 가입하길 원하십니까? 가입 여부가 중요하나요? 존 보삭: 마이크로소프트를 UBL로 영입하는 것은 확실한 우리의 염원 중 하나입니다. 우리가 이 단체를 창립한 이후로 계속해서 우리를 관찰하고 있으며 나는 결국에는 그들이 우리와 손을 잡을 것이라고 생각합니다. 에드 덤빌: 어떻게 UBL의 성공을 확인할 수 있습니까? 존 보삭: 중소기업에서의 UBL 채택 비율로 알 수 있죠. 에드 덤빌: 기술 위원회 멤버들이 그들의 개발과 함께 병행해서 UBL을 구현하고 테스트할 것으로 기대하십니까? 존 보삭: 네. 사실 UBL을 이미 사용되고 있는 구문으로 시작한 이유이기도 하죠. xCBL에 기반을 둔 시스템을 이용하는 사용자와 벤더는 우리가 언어를 발전시켜 나감에 따라 시스템이 계속해서 잘 작동하는지 테스트해야만 할 것입니다. 에드 덤빌: 특허 기술과 관련된 UBL 기술 위원회의 입장은 무엇입니까? 존 보삭: OASIS 사이트에서 현재 OASIS IPR 정책을 보실 수 있습니다. 기본적으로 IETF IPR 정책과 똑같다고 할 수 있습니다. UBL 기술 위원회의 특허권이 명확해짐에 따라 UBL에 가입한 사람들은 "라이센스이나 기타 수수료 없이 누구나 자유롭게" 이용할 수 있으며 이러한 결과는 UBL을 이해하는데 공헌할 것으로 보입니다. 구매 주문이나 송장과 같은 문서들은 오래 전부터 사용되었던 것들이기 때문에 이러한 것을 소프트웨어로 만들어 단순히 특허로 발행하겠다면 이것을 이해할 사람은 없습니다. 거래가 사업 절차보다 계약 문서에 의존하는 것은 이와 같은 실질적인 이유 때문일 것입니다. 송장과 같은 문서는 다양하고 자세한 사업 절차를 거치지만 특정 절차를 표현한다거나 형태화 되는 것은 아닙니다. 비즈니스 형식에 대한 큰 문제는 특허보다는 저작권과 관련된 것이 될 것입니다. 이미 첨부파일로 무료로 사용할 수 있는 스펙에서 UBL을 시작한 이유가 바로 이 문제에 있습니다. 이미 확실한 법적 권리를 가지고 있는 문서로 시작했기 때문에 이 문서를 사용해서 다른 작업을 한다고 하더라도 법적 문제의 소지가 없으며 기관들 누구나 무료로 사용할 수 있는 스펙을 개발하는데 헌신할 것입니다. 따라서 나는 우리가 지적 재산권과 관련된 문제까지도 함께 방지할 수 있을 것으로 생각합니다.
TAG :
댓글 입력
자료실

최근 본 책0