UBL의 기초

UBL이 어떻게 공급망 내에서 로컬 사용자 정의를 허용하는지를 포함하여, UBL의 기원과 몇 가지 특징을 살펴보자. 그런 다음, 실제 비즈니스 환경에서 UBL이 어떻게 사용되고 있는지 알아볼 것이다.

UBL의 창시자 중 한 명인 Tim McGrath는 "UBL이 획기적인 기술은 아니며, 기술의 응용이라는 관점에서 획기적인 것"이라고 지적했다(참고자료 참조).

Bower와 Christensen은 확고하게 자리를 잡고 있던 존속성 기술을 예상치 못하게 대체하는 기술을 묘사하기 위해 파괴적 기술이라는 신조어를 처음 사용했다. 존속성 기술은 보통 점진적인 개선을 근간으로 하지만, 파괴적 기술은 최종적으로 기존의 다른 기술을 밀어내고 그 자리를 차지하려는 목적으로 설계한 것은 아닌 소스로부터 비롯될 수 있다.

그런 까닭에, 만약 UBL이 파괴적 기술이 아니라면 UBL은 Christensen이 이후에 "완전히 새로운 소비자 계층이 과거에는 돈이 많거나 기술력이 우수한 소비자만이 접근할 수 있었던 제품이나 서비스를 이용할 수 있을" 잠재력을 가진 파괴적 혁신이라 부른 것이 확실하다(참고자료 참조).

백그라운드

UBL은 신기술이 아니며, 그 기초 역시 전혀 새로운 것이 아니다. UBL은 2004년에 OASIS 표준이 되었으며, 그 이후로 몇 년 동안 후속 릴리스가 계속 나왔다. 표 1에 UBL 릴리스의 연대기가 나와 있다.

UBL은 1986년에 국제표준기구(ISO)의 표준이 된 SGML(Standard Generalized Markup Language)을 바탕으로 한 XML(Extensible Markup Language) 권장사항(V1.0 - World Wide Web Consortium 권장사항, 1998년)을 준수한다. SGML은 1960년대에 Charles Goldfarb, Edward Mosher 및 Raymond Lorie가 개발한 IBM의 GML(General Markup Language)에서 비롯되었으며, 범용 마크업 언어 영역에서는 거의 반세기 동안 확고한 기술 발전의 역사가 있다.

SGML은 군사, 항공우주 및 자동차 산업과 대형 출판사에서 처리해야 하는 초대규모의 문서화 작업에 따른 문제점을 해결하는 데 초점을 맞추었다. 예를 들어, 미 국방부(DoD)는 수천 개에 달하는 공급업체로부터 수많은 독점 소유 형식으로 작성된 기술 정보를 받았다. 따라서 이 모든 정보를 공통의 전자 프레임워크로 통합하는 작업을 하면서 큰 문제점에 직면했다. 당시의 해결책은 모든 공급업체에서 SGML을 사용하도록 요구하는 것이었다. 공급업체들은 CALS(Continuous Acquisition and Life-cycle Support, 지속적 획득 및 라이프사이클 지원) 정의를 기반으로 하는 SGML 형식의 기술 정보를 제공해야 했으며, 국방부에서는 이를 따르지 않는 공급업체와는 거래를 하지 않으려 했다. 그 결과, 미 국방부는 모든 정보를 공통 마크업 언어 형식으로 받았으며, 많은 문제점이 사라졌다. 우리는 현재 비즈니스 문서를 교환하면서 이와 비슷한 상황에 처해 있다.

UBL은 인터넷 상에서 기업 간에 교환되는 비즈니스 문서를 겨냥한 XML 마크업 언어이다. 이런 UBL의 개발은 기존에 비즈니스 정보를 종이 문서로 많이 교환하던 방식을 간소화하여 세계적인 전자상거래를 활성화하기 위한 노력의 일환으로 진행되었다. UBL 2.0에서는 구매 주문서, 청구서 및 세계적으로 어디서나 사용할 수 있는 수십 가지의 기타 표준 비즈니스 문서와 같은 31가지 표준 전자 XML 비즈니스 문서로 구성되어 있고 사용료가 없는 개방형 라이브러리를 정의한다. (개발 중인) UBL 2.1에는 60여 가지의 문서가 있다. UBL의 설계 목적은 기존의 비즈니스, 법률, 감사 및 기록 관리 관행에 직접 연결하고, 기존의 팩스와 종이 문서 기반의 공급망에서 데이터의 키 변경을 제거하며, 중소기업을 위한 전자상거래의 시작점을 제공하는 것이다.

UBL 솔루션을 구현할 때 현재의 비즈니스 방식을 변경할 필요도, 현재 사용하는 소프트웨어 애플리케이션을 변경할 필요도 없다는 점을 이해하는 것이 중요하다. UBL은 종이로 된 비즈니스 문서 교환 방식을 전 세계적으로 어디서나 이해할 수 있는 안정적인 전자 문서 교환 방식으로 바꿀 수 있다. 많은 경우 일반 사용자는 현재 사용 중인 애플리케이션을 사용하여 자신의 태스크를 정상적으로 수행하므로 UBL을 사용한다는 사실조차 인식하지 못할 수도 있다. 오랜 세월에 걸쳐 다듬어진 비즈니스 사례는 전자 환경에도 간단히 적용된다.

위로

비즈니스 정보 엔티티

UBL은 기존 표준을 바탕으로 구현된다. 예를 들어, UBL은 Core Components Technical Specification의 파트 8에 정의된 것처럼 UN/CEFACT(United Nations Centre for Trade Facilitation and Electronic Business) Core Component를 사용한다(참고자료 참조). 이 스펙에서는 Core Component 솔루션을 "오늘날 사용되는 일반적인 유형의 비즈니스 데이터를 표시하고 새로운 비즈니스 용어의 작성과 기존 비즈니스 어휘의 재구조화를 대비하는 공통적인 시맨틱 구성 요소 세트를 개발하기 위한 방법론"으로 정의한다.

코어 컴포넌트는 데이터 및 정보 모델링과 교환의 모든 측면에 사용 가능한 시맨틱 구성 요소이다. 코어 컴포넌트는 상호 운용성 있는 비즈니스 프로세스 모델과 비즈니스 문서를 작성하기 위한 핵심 요소이다. 코어 컴포넌트는 사실상 개념적인 것으로서, 컨텍스트에 따른 BIE(Business Information Entities)를 작성하는 데 사용된다.

UBL은 이런 코어 컴포넌트를 기초로 활용하는 비즈니스 정의 세트를 정의한다. 그림 1은 UBL이 이런 코어 컴포넌트로 맵핑되는 방식을 나타낸 것이다.

BIE는 UBL 어셈블리 프로세스의 핵심 개념이다. BIE는 BBIE(Basic BIE), ABIE(Aggregate BIE) 또는 ASBIE(Association BIE)일 수 있다.

Basic BIE는 다른 엔티티로 구성되지 않는 단 하나의 원자적 엔티티이다. Aggregate BIE는 Basic BIE와 기타 Aggregate BIE로 구성될 수 있다. Association BIE는 ABIE와 다른 ABIE 간의 연관을 정의한다. 구매 주문서 및 청구서와 같은 표준 비즈니스 문서 세트는 BIE에서 어셈블된다. 자세한 내용은 그림 1을 참조한다.

앞서 언급한 바와 같이, BIE는 코어 컴포넌트가 코어 컴포넌트 어셈블리 프로세스에 있는 것과 마찬가지로 UBL 어셈블리 프로세스에서 핵심 개념이다. BIE는 BBIE(Basic BIE), ABIE(Aggregate BIE) 또는 ASBIE(Association BIE)의 3가지 형식을 취한다. BIE는 고유한 비즈니스 시맨틱 정의를 가진 비즈니스 데이터 또는 비즈니스 데이터 그룹이다. 구매 주문서나 청구서와 같은 다양한 문서 유형을 위해 예약된 Document ABIE라는 특수한 ABIE가 있다. 이들은 각각 차례대로 ABIE, ASBIE 및 BBIE의 세트로 구성된다.

BBIE는 다른 어떤 엔티티로도 구성되지 않는 단 하나의 원자적 엔티티이다. BBIE는 시맨틱 구성 요소를 표시하며 Basic Core Component에 직접 맵핑한다. 사무실 주소나 자택 주소와 같은 주소의 유형을 지정하는 코드인 AddressTypeCode를 BBIE의 예로 들 수 있다. Address는 어떤 주소에 대한 정보의 구조적 세트인 ABIE이다. DeliveryAddress 또는 AddressLine은 ASBIE의 예로 들 수 있다. DeliveryAddress는 더 일반적인 Address의 특성을 상속하는 반면, AddressLine은 더 일반적인 Line의 특성을 상속한다.

비즈니스 정보 엔티티 샘플

다양한 양식의 BIE가 어떻게 구성되고 관계를 맺는지 보여주는 UBL-CommonAggregateComponents-2.0.xsd의 코드 중 일부를 보려면 목록 1. 비즈니스 정보 엔티티 샘플을 참조한다. Address 및 AddressLine에 대한 요소 정의를 포함하여, 주소의 개념을 다루는 데이터 조각이 추출되었다.

BIE가 기초를 두고 있는 공통적인 기본 코어 컴포넌트는 XML 네임스페이스 cbc에 속한다. AddressLine(ASBIE) 역시 type="AddressLineType" 속성을 가진 AddressType의 정의에 속한다.

type="AddressLineType" 속성을 가진 AddressLine은 하나 이상의 Line 요소로 구성된 ABIE이다(BBIE는 XML 네임스페이스 cbc에도 속함). Line은 "비정형 텍스트로 표현되는 주소 행"으로 정의된다.

이 코드는 전부 AddressLine(ASBIE)을 포함한 다양한 선택적 요소(BBIE)로 구성된 Address(ABIE)를 정의한다. AddressLine(ABIE)은 하나 이상의 Line 요소(BBIE)로 구성된다.

위로

UBL 사용자 정의

UBL 설계자들은 모든 것을 포괄하고 중앙에서 관리되는 단일 솔루션으로 모든 사용자를 강제로 통합하려고 하지 않았다. 그보다는, 글로벌 요구사항의 80-90% 정도를 충족하도록 UBL을 설계했으며 사용자가 사용자 정의를 통해 관리해야 하는 로컬 요구사항이 있다고 인식했다.

예를 들어, 어떤 커뮤니티 내에서 특정 UBL 문서만 사용할지도 모른다. 이때, 해당 UBL 문서의 특정 부분만 필요할 수도 있다. 그리고 사용자가 속한 커뮤니티를 위해 이런 특정 부분에 사용자 정의 확장을 추가할 수 있다. 개별 정보 항목에서 취할 수 있는 값을 제한할 수도 있다.

UBL 설계자들은 독창적으로 구조 및 어휘 유효성 검증을 값 유효성 검증과 분리한다는 결정을 내렸다. 이는 이 두 가지 유효성 검증을 단일 스키마로 융합하는 다른 XML 기반 비즈니스 용어와는 사뭇 다르다.

UBL에서는 구조 및 어휘 제한조건이 스키마를 통해 정의 및 유효성 검증되며, (Xpath, genericode 및 컨텍스트-값 연관을 사용하는) 코드 목록의 보조 추상 표현식과 다른 값 제한조건이 값 유효성 검증에 사용된다. 그림 2는 이런 분리를 도식화한 것이다. 이 보조 값 유효성 검증 단계를 통해 관심 대상 커뮤니티(한 공급업체와 일단의 고객이라고 하자.)는 그 커뮤니티 내부에서만 사용할 값 세트에 동의하고 지정할 수 있다. 예를 들어, 제품 코드가 해당 공급업체에서 제공하는 제품 세트로 제한될 수 있다.

그림 2에서는 구조 및 어휘 유효성 검증을 위한 표준 W3C XSD 스키마가 어떻게 되어 있는지 알 수 있다. 모든 XML에서와 같이, 입력 인스턴스가 W3C Schema에서 공식적으로 설명하는 문서 클래스에 속한 경우 그 인스턴스가 유효한 것으로 선언할 수 있다.

값 유효성 검증에는 코드 목록이 관련된다. 코드 목록 또는 제어되는 용어는 특히 정보 요소에 대해 허용되는 값을 제한하는 데 사용된다. 코드 목록은 2자로 된 국가 코드와 같이 글로벌하게 관리하거나 카탈로그에 있는 공급업체의 제품 코드 목록과 같이 로컬에서 관리할 수 있다.

여기서 코드 목록을 길게 설명하지는 않겠지만, UBL 2.0 FAQ에 코드 목록의 처리 방식이 다음과 같이 설명되어 있다.

"UBL 2.0에는 코드 목록 관리 문제에 대한 해답도 포함되어 있다. UBL 2.0에서는 기본 코드 목록 값을 문서 스키마에 직접 바인드하여 거래 파트너별로 따로 코드 목록을 조정하기가 사실상 불가능하도록 하지 않고, 새로운 genericode(제네릭코드) 형식을 사용하여 별개의 파일에 코드 목록 값을 표시한다. 기본값은 표준 스키마와는 무관하게 코드 값을 유효성 검증하는 XSLT 스크립트를 생성하는 데 사용된다. 이런 2단계 접근 방식을 통해 대부분의 코드 목록 관리 문제점을 해결할 뿐 아니라, 다른 코드 목록 서브세트를 같은 문서 인스턴스에 있는 다른 컨텍스트와 연관할 수 있도록 허용하고, 각각의 거래 관계에서 허용되는 코드 값을 지정할 때 상당한 유연성을 제공하고, 정교한 비즈니스 규칙 구현을 위한 토대를 확립할 수도 있으며, 이 모두가 표준 UBL 2.0 스키마를 수정하지 않고도 가능하다."

UBL 2.0 FAQ에 대한 링크는 참고자료를 참조한다.

OASIS UBL 2 Guidelines for Customization(첫 번째 에디션)에 사용자 정의 문제를 다루는 방법이 자세히 설명되어 있다(참고자료의 링크 참조).

위로

비즈니스 문서 교환 시의 문제점

이제 한 공급망에 속한 여러 회사들 사이에 비즈니스 데이터를 교환할 때의 문제점을 살펴보자. 공급업체의 입장에서는 각 회사가 고객과 같을 수 있으며, 공급업체는 고객이 각자의 비즈니스 수행에 필요한 상품이나 서비스를 고객에게 제공한다. 그림 3에서 보는 바와 같이, 각 고객은 N개의 공급업체와 거래한다.

표 2는 이런 비즈니스 관계에서 전형적인 활동을 나타낸 것이다.

세로축이 공급업체 수를 나타내고 가로축이 거래 관계에 있는 공급업체의 수를 기준으로 한 모든 고객의 순서별 나열을 나타내는 고객 회사 분포도를 생성하면, 일반적인 파레토(Pareto) 곡선으로 나타나는 것을 볼 수 있다. 즉, 전체 고객 중 약 20%는 거래하는 공급업체 수가 많고 일반적으로 이런 다수의 공급업체를 상대로 한 거래를 처리하기 위해 대규모 애플리케이션을 설치하여 사용한다. 이런 애플리케이션은 다른 EDI(전자 데이터 교환) 사용자에게 청구서와 같은 트랜잭션을 전자적으로 배달할 수 있는 EDI 시스템일 수 있다(그림 4 참조).

고객 중 나머지 80%는 거래하는 공급업체 수가 적고 덜 정교한 애플리케이션이나 심지어는 스프레드시트 또는 워드 프로세서와 같은 사무용 도구를 사용하여 청구서와 같은 비즈니스 트랜잭션을 생성한다. 이런 고객 중 다수는 공급업체에게 비즈니스 트랜잭션을 전송하기 위한 매체로 종이 문서를 사용한다.

거래하는 공급업체 수가 매우 많은 고객이 안고 있는 문제점은 각 공급업체의 시스템에 청구서 데이터를 전자적으로 입력해야 한다는 점이다. 공급업체로부터 정기 우편을 통해 인쇄된 문서 형태나 이메일을 통해 전송된 PDF로 청구서를 받는 고객은 해당 정보를 전자 양식으로 관리하기 위해 정보를 다시 입력하거나 스캔 및 OCR 작업을 수행하느라 시간과 자원을 낭비하게 된다. 유럽에서는 통상적인 청구서 한 건을 처리하기 위한 비용이 약 7-15유로나 되는 것으로 추정된다. 대기업의 경우 이런 불필요한 비용만 없애더라도 막대한 비용 절감 효과를 거둘 수 있을 것이다.

무려 440,000개의 공급업체로부터 매달 140만 건의 청구서를 받아서 처리해야 하는 덴마크 정부를 예로 들어 보자. 이런 비용 절감 노력을 통해 매우 비용 효율적인 비즈니스 환경을 조성할 수 있다. 2003년도의 덴마크 정부 현황을 토대로 실시한 공식 분석에서, KPMG는 청구서당 처리 시간을 최소 10분씩 절약하여 무려 9,400만 유로의 비용 절감 효과를 거둘 수 있었을 것이라고 밝혔다. 청구서와 구매 주문서를 대조하는 데 걸리는 17분의 낭비 시간을 없애면 1억 6,000만 유로의 비용을 추가로 절약할 수도 있다.

거래하는 공급업체 수가 매우 적은 고객이 안고 있는 문제점은 기존의 많은 시스템이 요구에 부응하기에는 너무 복잡하고 비싸다는 점이다.

위로

UBL의 응용

일반적으로, 두 회사가 비즈니스 문서를 효과적으로 교환하려면 문서에서 사용하는 언어가 같아야 하고 기존의 비즈니스 프로세스를 변경하지 않고 이런 문서를 전자적으로 교환할 수단이 있어야 한다. 그리고 매우 작은 회사부터 정부나 대기업까지, 해당 비즈니스의 규모에 맞춰 프로세스의 규모를 조정할 수 있어야 한다.

UBL은 공통적인 시맨틱 표준 세트를 바탕으로 비즈니스 문서 교환을 위한 표준 언어를 제공한다. 모든 회사가 다른 회사와 비즈니스 문서를 교환하고 해당 문서를 서로 이해할 수 있다.

예를 들어, OASIS(2006)는 여러 가지 UBL 문서 샘플을 제공한다. 목록 2는 100kg의 밀랍 주문서에서 LineItem에 대한 내용을 발췌한 것이다.

<cac:LineItem> 
    <cbc:ID>1</cbc:ID> 
    <cbc:SalesOrderID>A</cbc:SalesOrderID> 
    <cbc:LineStatusCode>NoStatus</cbc:LineStatusCode> 
    <cbc:Quantity unitCode="KG">100</cbc:Quantity> 
    <cbc:LineExtensionAmount currencyID="GBP">
        100.00    
    </cbc:LineExtensionAmount> 
    <cbc:TotalTaxAmount currencyID="GBP">17.50</cbc:TotalTaxAmount> 
    <cac:Price> 
        <cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount> 
        <cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity> 
    </cac:Price> 
    <cac:Item> 
        <cbc:Description>Acme beeswax</cbc:Description> 
        <cbc:Name>beeswax</cbc:Name> 
        <cac:BuyersItemIdentification> 
            <cbc:ID>6578489</cbc:ID> 
        </cac:BuyersItemIdentification> 
        <cac:SellersItemIdentification> 
            <cbc:ID>17589683</cbc:ID> 
        </cac:SellersItemIdentification> 
    </cac:Item> 
</cac:LineItem>

이 내용은 사람이 읽고 이해할 수 있다. 이 주문서가 총 가격 100파운드에 17.50파운드의 세금이 붙은 100kg의 밀랍에 대한 주문서임을 매우 쉽게 알 수 있다. XML로 작성되어 있으므로 기성 컴포넌트로 처리할 수 있다.

cbc와 cac라는 두 네임스페이스는 각각 기본 및 집합 컴포넌트를 가리킨다. 위에서 <cbc:Name>은 기본 컴포넌트이고, <cac:BuyersItemIdentification>은 기본 컴포넌트인 <cbc:ID>로 구성된 집합 컴포넌트임을 알 수 있다. <cbc:ID>는 <cac:SellersItemIdentification>에서도 사용되고 시맨틱상 동일하지만 다른 컨텍스트에서 사용된다는 사실도 알 수 있다.

여기서 스키마 외부에서 로컬로 제어되는 코드 목록의 중요성을 설명할 수 있다. 스키마 정의에서 SellersItemIdentification에 대해 유효한 값의 목록을 포함하려 한 경우 각각의 사용자 커뮤니티에 대해 별개의 스키마가 필요하고 유효한 값의 목록이 변경됨에 따라 각각의 목록을 지속적으로 유지보수해야 했을 것이다.

그림 6에서는 각 회사에서 기존 시스템을 변경하지 않고 인쇄에서 전자 교환까지 비즈니스 데이터의 백엔드 변환을 단순히 플러그인하는 것만으로도 비즈니스 데이터의 전자 교환 방식을 얼마나 쉽게 변경할 수 있는지 알 수 있다.

위로

유럽의 UBL

이제 다양한 UBL 솔루션을 구현하여 달성할 수 있는 비용 절감 및 파급 효과를 더욱 잘 이해하기 위해 다양한 국가에서 어떻게 UBL을 채택했는지 살펴보자.

덴마크의 경험

덴마크에서는 전자상거래를 위한 솔루션으로서 UBL을 매우 일찍부터 채택했다. 덴마크 정부는 모든 청구서를 표준 양식으로 받을 수 있다면 청구서 처리 비용을 대폭 절감할 수 있을 것으로 인식했고, UBL이 바로 그런 구현을 위한 표준을 제공했다. 덴마크 정부는 정부가 지닌 권한으로 UBL 사용을 법제화했다.

덴마크 정부는 단순히 UBL 사용을 법제화한 데서 한 걸음 더 나아가, 크고 작은 모든 기업이 법률을 준수할 수 있는 인프라를 제공해야 했다. 그래서 공공 조달용 포털, 덴마크의 모든 공공 구매자 및 공급업체가 액세스할 수 있는 전자 마켓플레이스 및 종이 문서를 UBL 기반 문서로 변환하기 위한 스캐닝 에이전시를 개발했다.

덴마크에서 취급한 최초의 UBL 문서는 청구서였지만, 이는 사실상 조달망의 마지막 부분이다. 입찰부터 청구서 처리에 이르는 조달망에서 작성되는 다른 문서들을 전자 처리하면 효율성과 비용 절감에 대단한 성과를 거둘 수 있다. 이런 목표를 향한 작업과 UBL 2.0의 채택은 OIOUBL이라는 UBL 2.0의 덴마크어 버전 서브세트의 채택으로 이어졌다.

유럽 연합의 경험

덴마크의 주도하에, 덴마크, 스웨덴, 노르웨이, 핀란드, 영국 및 아이슬란드의 대표자들은 UBL 2.0 문서의 NES(Northern European Subset)를 개발하기 위한 작업 그룹을 구성했다.

NES 서브세트의 목적은 이미 UBL을 사용하고 있거나 UBL 2.0 문서 사용을 고려 중인 국가에서 작성되는 다양한 유형의 전자 조달 문서를 용이하게 일치시키자는 것이다. 이를 통해 조정된 NES 서브세트를 바탕으로 전자 조달 문서 및 프로세스를 구현할 수 있는 기회가 생긴다.

UBL은 PEPPOL(Pan European Public Procurement On-Line) 프로젝트의 기초가 될 것이다(참고자료 참조). PEPPOL의 명백한 비전은 중소기업을 포함한 유럽 연합 국가 내 어떤 회사라도 모든 조달 프로세스에 대해 모든 유럽 연합 국가 기관과 전자 통신할 수 있게 한다는 것이다.

북미의 UBL

놀랍게도, 북미에서는 UBL이 거의 채택되지 않는 것으로 보인다. 마치 그 지역에 있는 어느 누구의 레이더 화면에도 UBL이란 존재가 잡히지 않는 것처럼 보인다. 한 가지 주목할 만한 예외는 미 교통부에서 수행 중인 작업이다. 미 교통부의 전자 화물 운송 관리 시범 프로젝트에서는 다음 UBL 문서를 사용한다.

• Transportation Status(교통 현황)
• Despatch Advice(급송 정보)
• Receipt Advice(수령 정보)

이 시범 프로젝트에서는 복잡한 실제 사용 환경을 고려하여 설정된 최첨단 전자 상거래 데모에 중국 의류 제조업체 2개, 화물 운송업체 2개, 항공 화물 터미널 운영업체 1개, 전세 항공 운수업체 2개, 미국 의류 구입업체 1개, 미국 3자 물류회사 1개, 수입 중개업체 1개를 연결했다. 프로젝트의 아키텍처에서는 기존의 중앙 집중식 데이터베이스 솔루션에서 흔히 볼 수 있었던 단일 장애 지점 및 데이터 중복 문제가 없는 연합 데이터베이스가 효과적으로 작성되었다.

위로

파괴적 혁신을 주도하는 UBL

UBL이 북미 대륙에 어떻게 전파되어 나갈 수 있을지 검토해보면, 유럽의 경험을 바탕으로 볼 때 다음과 같이 다양한 양상으로 전개될 수 있을 것이다.

• UBL 사용을 법제화한다. 각국 정부가 정부와의 모든 비즈니스 트랜잭션에 UBL을 의무적으로 사용할 것을 규정하는 법률을 통과시킬 수 있다.
• UBL 사용 법령을 포고한다. 군대와 같이 매우 규모가 큰 조직에서 UBL을 사용하지 않는 조직과의 비즈니스를 거부할 수 있다.
• UBL 사용 범위를 더욱 넓힌다. 현재 공급업체들은 현재 사용 중인 소프트웨어 오퍼링에서 선택사항으로 UBL 출력을 제공한다.

제3의 방법

다음 두 가지 방법이 있다.

1. 기존 전자 상거래 애플리케이션의 공급업체가 UBL 내보내기 및 가져오기 기능을 새로 추가할 수 있다.
2. 공급업체가 기존 애플리케이션과 연동할 수 있는 새로운 UBL 서비스를 제공할 수 있다.

첫 번째 선택사항은 Christensen이 존속적 혁신이라 부르는 사례이다. 하지만, 그 애플리케이션을 소유하고 있거나 구매하는 회사만 해당 기능을 사용할 수 있다.

두 번째 선택사항의 예를 하나 들자면, Tradeshift®에서 제공하는 다른 접근 방식이다(참고자료 참조). Tradeshift는 무료 전자 청구서 처리를 포함한 전자 UBL 비즈니스 문서의 교환을 위한 클라우드 컴퓨팅을 기반으로 하는 SaaS(Software as a Service)를 제공한다. 이 회사는 애플리케이션이 아니라 이런 형식의 UBL 문서 교환에 집중한다. 하위 레벨에서는 청구서를 생성하고 교환하기 위한 브라우저 기반 인터페이스를 제공하고, 상위 레벨에서는 기존 소프트웨어의 공급업체가 저렴한 비용으로 UBL 백엔드를 추가할 수 있도록 Open API를 제공한다(그림 6 참조). 흥미로운 점은, 모든 문서에 대해 "토론 스레드"를 구현하기 위한 "소셜 네트워킹" 기능을 추가했다는 사실이다.

위로

환경 개선을 위한 노력

마침내 종이 문서 기반 시스템에서 전자 교환 시스템으로 전환하면 환경 개선에 기여할 수 있다. 예를 들어, 청구서를 인쇄하기 위한 종이를 만드는 데 원료로 쓰이는 나무는 지구 상에서 벌목하는 나무 중 최대 10%에 이른다. 이런 종이를 쓸 필요성을 없애면 산림 벌채 감소에 도움이 되며, 이는 Smart2020 연구에서 정보 시대에 정보통신 기술이 저탄소 경제 환경에 기여할 수 있는 방법으로 제시한 이니셔티브 중 하나에 불과하다.

위로

결론

UBL은 일반 마크업 언어 영역에서 40여 년간 탄탄한 발전 과정을 거쳐온 XML을 기반으로 하는 기술이라는 점을 설명했다. UBL은 기존의 비즈니스, 법률, 감사 및 기록 관리 관행에 연결되도록 설계되었고, 종이 문서 사용량 감소를 통해 지구의 환경 개선에 기여할 수 있다.

금융 서비스 산업의 기존 애플리케이션을 대체하려 시도하는 대신, UBL을 사용하여 조직 간의 현행 비즈니스 문서 교환 방식을 종이 문서에서 국제 표준을 기반으로 하는 전자 양식으로 변환할 수 있다.

UBL은 공통적인 비즈니스 요구사항의 80-90%를 처리하고, 나머지는 UBL 사용자 정의를 통해 처리할 수 있도록 설계되었다. 사용자 정의에는 UBL에 의해 정의된 문서의 서브세트를 사용하는 것이 포함된다. 필요한 단일 UBL 문서 중에서 이처럼 선택한 부분만 사용하거나, UBL 문서를 확장하거나, 더 나아가 새 UBL 문서를 제안할 수도 있다. 그 밖에도, 고객 기반 코드 목록으로 정보 요소의 컨텐츠에 대한 유효성 검증을 로컬에서 관리할 수 있다.

UBL을 사용하면 결국 완전히 새로운 소비자 계층(현재 조직의 최대 80%까지)이 비즈니스 수행 시 종이 문서 대신 전자 교환 시스템에 액세스할 수 있으므로, 이를 파괴적 혁신으로 간주할 수 있다.

참고자료

교육

• CCTS(2003) — Core Components Technical Specification — Part 8 of the ebXML Framework: ebXML의 개념을 해석하거나 구현하는 데 필요한 안내 정보를 찾아보자.
  
  
• Disruptive Technologies: Catching the Wave(Joseph Bower 및 Clayton Christensen, Harvard Business Review, 1995년 1월-2월): Harvard Business Review에서 Joseph Bower와 Clayton Christensen이 쓴 독창적인 기사를 읽어보자.
  
  
• Disruptive Innovation: 어떤 제품이나 서비스가 처음에는 간단한 애플리케이션 형태로 시장 저변부에 정착했다가 거침없이 상급 시장으로 이동하여, 결국 기존에 확고한 지위를 차지하고 있던 경쟁 제품이나 서비스를 대체하는 과정을 설명하기 위해 Clayton Christensen이 제시한 이 신조어에 대해 더 자세히 알아보자.
  
  
• The Need for Disruptive Innovation (Part 1) — Computerworld Blog: 캐나다에서 일어나고 있는 혁신적 변화에 대한 기사를 읽을 수 있다.
  
  
• Cover Pages: XML 형태의 마크업 언어 표준을 지원하는 포괄적인 온라인 참조 콜렉션인 Cover Pages에서 UBL에 관해 자세히 배우자.
  
  
• Pan-European Public Procurement (PEPPOL): 자세한 정보는 Pan-European Public Procurement의 홈 페이지를 참조한다.
  
  
• Crane Softwrights — UBL 2.0 Model Summary Reports: 정보 항목과 문서 모델 스프레드시트가 전부 요약되어 있는 61개의 HTML 파일 세트를 참조한다.
  
  
• Electronic Freight Management: 웹 기술을 적용하여 공급망 파트너 간의 데이터 및 메시지 전송을 개선하기 위해 USDOT에서 후원하는 이 프로젝트에 대해 자세히 알아보자.
  
  
• OASIS UBL 2 Guidelines for Customization: UBL의 사용자 정의에 대한 내용을 읽을 수 있다.
  
  
• Core Components Technical Specification: UN/CEFACT(United Nations Centre for Trade Facilitation and Electronic Business)에서 Core Components Technical Specification을 확인하자.
  
  
• Oasis UBL FAQ: 질문과 대답에서 궁금한 점을 해결할 수 있다.
  
  
• SMART 2020: Enabling the low carbon economy in the information age: 지구 온난화 문제의 완화에 정보통신 기술이 발휘하는 효과를 살펴보자.
  
  
• Tradeshift: 고객 간의 UBL 문서 교환에 초점을 맞춘 클라우드 컴퓨팅 기반 SaaS(Software as a Service)를 찾아보자.
  
  
• IBM developerWorks Industry Zone: 개발자에게 필요한, 산업에 특화된 모든 최신 기술 자료는 이 사이트를 참조한다.
  
  
• developerWorks 팟캐스트: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트: developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  

제품 및 기술

• OASIS UBL 2.0 sample UBL documents: 이 디렉토리에서 샘플 문서를 다운로드할 수 있다.
  
  
• IBM 시험판 소프트웨어: 다운로드하거나 DVD로 제공받을 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 오픈 소스 개발 프로젝트를 구현해 보자.
  
  

토론

• developerWorks 블로그: developerWorks 커뮤니티에 참여하자.
  
  

필자소개

W. Hugh Chatfield는 CyberSpace Industries 2000 Inc.의 정보 시스템 전문가이자 사장으로 XML 교육과 컨설팅 및 멀티미디어 제품 서비스를 제공한다. 그는 물리학에서 우등 학사학위를 그리고 다큐멘터리 프로덕션 분야에서 명예상(Honors Certificate)를 받았다. 정보 기술 분야에서 40년 넘게 경험을 쌓았으며 마지막 17년은 일반 마크업 언어 도메인 분야에서 종사했다.

아티클 순위

의견

위로

목차

• UBL의 기초
• 비즈니스 정보 엔티티
• UBL 사용자 정의
• 비즈니스 문서 교환 시의 문제점
• UBL의 응용
• 유럽의 UBL
• 파괴적 혁신을 주도하는 UBL
• 환경 개선을 위한 노력
• 결론
• 참고자료
• 필자소개
• 의견