클라우드 정보 모델

(CIM)은 당사자, 제품, 주문, 결제 및 이들을 하나로 묶는 관계 등 현대 기업을 통해 이동하는 엔터티를 설명하기 위한 개방형 애플리케이션 독립적(application-agnostic) 스키마입니다. CIM은 모든 통합에 대해 맞춤형 데이터 모델을 고안하는 대신, CRM, ERP, 커머스 플랫폼 및 분석 웨어하우스가 “판매 주문(Sales Order)” 또는 “제품 관계 유형(Product Relationship Type)“이 실제로 무엇을 의미하는지에 대해 합의할 수 있도록 공유 어휘를 제공합니다. 이 기사에서는 모델을 구성하는 엔터티 그룹을 살펴본 다음, 대표적인 엔터티 하나인 ProductRelationshipType을 자세히 분석하여 CIM이 실제로 관계, 역할 및 키를 어떻게 표현하는지 보여줍니다.

주요 내용

• CIM은 엔터프라이즈 데이터를 한 번에 모두 채택하기보다 점진적으로 채택할 수 있는 엔터티 그룹(당사자, 제품, 판매 주문, 결제 등)으로 구성합니다.
• 각 엔터티는 용어 URI(Term URI), 설명, 스칼라 속성 및 링크 속성으로 정의되며, 이는 JSON-LD, RDF 및 속성 그래프 저장소에 깔끔하게 매핑되는 구조입니다.
• ProductRelationshipType과 같은 관계 엔터티는 역할(부모/자식)을 인코딩하므로, 비즈니스 로직을 하드 코딩하지 않고도 번들, 옵션 및 커버링을 모델링할 수 있습니다.
• 이 모델은 의도적으로 애플리케이션 독립적입니다. 특정 벤더가 데이터를 저장하는 방식이 아니라, 데이터가 무엇을 의미하는지를 설명합니다.
• CIM 채택은 전면 교체(rip-and-replace)가 아닌 매핑 작업입니다. 기존 시스템을 공유 용어에 맞게 정렬하고 격차를 조정하는 과정입니다.

공유 모델이 중요한 이유

엔터프라이즈 통합에는 익숙한 실패 패턴이 있습니다. 모든 시스템이 각자의 방언을 사용한다는 점입니다. Salesforce는 이를 Account라고 부르고, SAP는 Business Partner라고 하며, 자체 구축한 빌링 서비스는 Customer라고 부릅니다. 각 쌍 사이에 점대점(point-to-point) 매핑을 구축하면, 번역의 수는 관련 시스템 수의 제곱으로 증가하며, 새로운 시스템이 추가될 때마다 유지 관리 부담이 배가됩니다.

표준 모델(canonical model)은 이러한 이차 방정식 문제를 해결합니다. 각 시스템을 공유 모델에 한 번만 매핑하면 공유 모델이 허브가 됩니다. 이는 OAGIS(Open Applications Group Integration Specification), OMG의 Common Warehouse Metamodel, schema.org의 커머스 어휘와 같은 표준 뒤에 숨은 동일한 아키텍처적 본능입니다. CIM은 이러한 전통을 따르면서도 클라우드 시대의 상호 운용성에 맞게 범위를 설정했으며, 역참조 가능한 URI를 가진 공개 용어로 게시되었습니다.

실질적인 이점은 데이터 아키텍트가 단일 참조 지점을 사용하여 “어떤 시스템이 당사자(Party)에 대한 권위 있는 기록을 보유하고 있는가?” 또는 “카탈로그와 주문 전반에서 제품 번들을 어떻게 일관되게 표현하는가?”와 같은 질문에 답할 수 있다는 것입니다.

엔터티 그룹 개요

CIM은 단일 모놀리식 스키마가 아니라 느슨하게 결합된 그룹들의 집합입니다. 모델에 명명된 그룹은 다음과 같습니다.

• Account — 당사자의 상업적 관계 컨텍스트.
• Contact Point — 전화번호, 이메일 주소 및 유사한 연락 채널.
• Lead — 아직 자격이 검증되지 않은 잠재 당사자.
• Party 및 Party Role — 행위자라는 일반적인 개념과 그가 수행하는 역할(고객, 공급업체, 직원).
• Payment 및 Payment Method — 자금 이동 방식과 사용되는 수단.
• Product Attribute, Product Catalog, Product — 판매 및 설명 가능한 상품 및 서비스.
• Sales Order 및 그 방대한 하위 엔터티 제품군 — 모델의 트랜잭션 핵심.
• Shipment — 주문 처리 및 물류.

판매 주문 그룹은 단연 가장 세분화되어 있으며, 그 이유를 이해하는 것이 중요합니다. 주문은 가격 책정, 세금, 조정, 배송 그룹화, 라인별 메모 등 비즈니스 규칙이 집중되는 곳입니다. CIM은 주문을 하나의 넓은 테이블이 아니라 Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log 등 많은 작은 엔터티로 분해합니다. 이러한 분해는 의도적인 설계 선택입니다. 이를 통해 각 관심사가 독립적으로 발전할 수 있으며, 시스템은 자신이 필요로 하는 부분만 구독할 수 있습니다.

관련 항목: Boomi AtomSphere — 하이브리드 클라우드-온-프레미스 통합을 위한 Enterprise iPaaS.

CIM 엔터티 분석

CIM의 모든 엔터티는 동일한 형태를 따르므로, 프로그래밍 방식으로 모델을 예측 가능하게 소비할 수 있습니다. 두 제품이 왜 관련되어 있는지를 설명하는 엔터티인 ProductRelationshipType을 예로 들어 보겠습니다.

• 용어 URI(Term URI) — http://cloudinformationmodel.org/model/ProductRelationshipType. 이는 개념에 대한 전역적으로 고유한 식별자입니다. URI이므로 RDF/JSON-LD 그래프에서 직접 역참조하고 사용할 수 있습니다.
• 설명(Description) — “번들, 옵션 또는 커버링과 같이 제품이 연관되는 이유.” 이는 이 엔터티가 관계 인스턴스 자체가 아니라 유형 또는 분류임을 알려줍니다.
• 스칼라 속성(Scalar Properties) — 데이터를 담고 있는 기본 필드입니다.
• 링크 속성(Link Properties) — 다른 엔터티에 대한 참조입니다. ProductRelationshipType에는 링크 속성이 없으며, 이는 이 엔터티가 허브가 아니라 제어된 어휘(controlled vocabulary)인 리프(leaf) 엔터티라는 정보를 제공합니다.

스칼라 속성은 다음과 같습니다.

속성	용어 URI	범위	필수 여부	설명
id	.../model/id	guid	예	기본 키
parentProductRole	.../model/parentProductRole	string	예	관계의 첫 번째 역할, 예: “Consists of”
childProductRole	.../model/childProductRole	string	예	관계의 두 번째 역할, 예: “Component of”

id가 GUID라는 점은 의미 있는 관례입니다. 이는 시스템 간의 조정 없이도 식별자가 전역적으로 고유함을 의미하며, 이는 서로 다른 클라우드에서 레코드가 생성된 후 나중에 병합될 때 정확히 필요한 기능입니다.

우리의 선택: Workato — 비즈니스 팀이 실제로 구축할 수 있는 자동화 기반 iPaaS.

역할을 통한 관계 모델링

ProductRelationshipType에서 가장 유익한 부분은 한 쌍의 역할 속성입니다. 제품 관계는 방향성이 있으며, CIM은 단일하고 불투명한 “유형” 문자열 대신 두 개의 명명된 역할을 통해 그 방향성을 포착합니다.

번들을 생각해 보세요. “스타터 키트”는 “라우터”와 “케이블”로 구성됩니다. CIM 용어로 말하면 다음과 같습니다.

• **상위 제품(parent product)**은 parentProductRole에 설명된 역할을 수행합니다. 예를 들어, “구성됨(Consists of)“입니다.
• **하위 제품(child product)**은 childProductRole에 설명된 역할을 수행합니다. 예를 들어, “~의 구성 요소(Component of)“입니다.

두 역할을 모두 *유형(type)*에 문자열로 저장하면 재사용 가능한 정의를 얻을 수 있습니다. 실제 제품 간 링크는 얼마든지 동일한 ProductRelationshipType 행을 참조할 수 있으므로, 관계 인스턴스는 많아지더라도 어휘는 작고 일관되게 유지됩니다. 이는 관계의 유형을 인스턴스에서 분리하는 전형적인 정규화 패턴입니다.

설명에는 번들(bundle), 옵션(option), **커버링(covering)**이라는 세 가지 유형이 명시적으로 언급되어 있으며, 이는 모델이 다루고자 하는 상업적 의미의 범위를 암시합니다.

• 번들 — 하나의 단위로 함께 판매되는 제품(상위 제품이 하위 제품으로 “구성됨”).
• 옵션 — 기본 제품과 관련된 선택 사항 또는 추가 기능.
• 커버링 — 다른 제품을 감싸거나 보호하는 제품으로, 보험 및 보증 컨텍스트에서 일반적입니다.

역할 어휘를 결정하는 방법

parentProductRole 및 childProductRole은 자유 형식 문자열이므로, 모델이 정확한 문구를 지정하지 않습니다. 이러한 유연성은 장점이자 위험 요소이기도 합니다. 몇 가지 실무 규칙은 다음과 같습니다.

1. 통제된 어휘를 선택하고 고정하십시오. 역할 문구(“Consists of” / “Component of”, “Optional add-on to” / “Has option”)에 대해 합의하고 이를 문서화하십시오. 자유 텍스트는 의미의 변질(drift)을 초래합니다.
2. 역할을 대칭적으로 유지하고 양방향에서 읽기 쉽게 만드십시오. 좋은 테스트 방법은 관계를 양쪽 끝에서 소리 내어 읽었을 때 말이 되는지 확인하는 것입니다.
3. 역할에 비즈니스 로직을 과하게 담지 마십시오. 역할에 조건부 동작이 필요한 경우, 해당 로직은 문자열이 아니라 이를 사용하는 애플리케이션에 구현해야 합니다.
4. 어휘의 버전을 관리하십시오. 역할을 추가할 때는 임시 삽입이 아니라 마이그레이션 경로가 포함된 스키마 변경으로 처리하십시오.

실제 CIM 채택

표준 모델을 채택하는 것은 마이그레이션이 아니라 매핑의 규율(discipline)입니다. 실행 가능한 순서는 다음과 같습니다.

관련 항목: Matillion — 클라우드 데이터 웨어하우스용으로 구축된 푸시다운 ELT.

• 기록 시스템(systems of record)의 인벤토리를 작성하십시오. 각 엔터티 그룹에 대해 어떤 시스템이 권한을 갖는지 결정합니다. 예를 들어, 당사자(Party)는 CRM에, 제품(Product)은 PIM에, 판매 주문(Sales Order)은 ERP에 있을 수 있습니다.
• 각 소스를 CIM 용어에 매핑하십시오. 소스 필드 $\rightarrow$ CIM 속성 테이블을 구축합니다. 소스에 대응하는 항목이 없는 경우 그 간극을 기록하고, CIM에 대응하는 항목이 없는 경우 확장(extension) 사항을 기록하십시오.
• 식별자를 조정하십시오. CIM의 GUID 규칙에 따라, 일반적으로 기본 키와 CIM id 값 사이의 교차 참조 테이블(crosswalk)을 유지하게 됩니다.
• 직렬화 방식을 선택하십시오. CIM의 URI 기반 용어는 JSON-LD 및 RDF에 자연스럽게 매핑되며, 관계형 테이블이나 속성 그래프로도 깔끔하게 변환됩니다. 모델이 특정 저장 기술을 강제하지 않습니다.
• 어휘를 거버넌스하십시오. 추가하는 역할 문자열, 열거형(enumerations) 및 확장은 변질될 가능성이 가장 높은 부분이므로 변경 제어(change control) 하에 두십시오.

유용한 멘탈 모델은 CIM을 교환(interchange) 스키마로, 운영 저장소를 *기록 시스템(system of record)*으로 취급하는 것입니다. 모든 애플리케이션에 기본 모델을 포기하라고 요구하는 것이 아니라, 경계 지점에서 공유 모델을 게시하고 소비하도록 요청하는 것입니다.

주의사항 및 트레이드오프

어떤 표준 모델도 비용이 들지 않는 것은 아니며, CIM도 예외는 아닙니다.

• 추상화에는 대가가 따릅니다. 여러 산업을 아우를 만큼 일반적인 모델은 어느 한 산업에 완벽하게 들어맞지 않습니다. 확장 기능을 추가해야 할 상황이 생길 것입니다.
• 판매 주문 그룹은 무겁습니다. 세분화된 분해 방식은 강력하지만, 더 많은 조인과 매핑할 엔터티가 필요함을 의미합니다. 주문 흐름이 단순한 팀은 일부 하위 집합만 채택할 수 있습니다.
• 자유 형식 역할 문자열에는 거버넌스가 필요합니다. 언급했듯이, parentProductRole 및 childProductRole의 유연성은 이를 관리하는 규율이 있을 때만 가치가 있습니다.
• 개방형 모델은 진화합니다. CIM은 커뮤니티 중심이므로 시간이 지남에 따라 용어가 추가되거나 개선될 수 있습니다. 특정 버전에 고정하고 변경 사항을 신중하게 검토하십시오.

이 트레이드오프는 본질적으로 특정 시스템에 대한 충실도와 시스템 간 이식성 사이의 전형적인 선택 문제입니다. CIM은 이식성을 최적화하며, 이는 상호 운용성이 목표일 때 올바른 선택입니다.

우리가 시작할 곳: Fivetran — 계속 실행되는 완전 관리형 ELT 파이프라인.

자주 묻는 질문

클라우드 정보 모델(Cloud Information Model)이란 무엇입니까?

클라우드 정보 모델은 당사자, 제품, 주문, 결제와 같은 기업 데이터를 위한 공유 엔터티와 용어를 정의하는 개방형 애플리케이션 독립적 데이터 모델입니다. 이는 공통 어휘를 제공하여 서로 다른 클라우드 및 온프레미스 시스템이 개별적인 포인트-투-포인트 매핑 없이 데이터를 교환할 수 있게 합니다.

ProductRelationshipType은 어떤 용도로 사용되나요?

ProductRelationshipType은 두 제품이 관련된 이유(예: 번들, 옵션 또는 커버링)를 정의합니다. 상위 역할과 하위 역할을 저장함으로써, 제품 간 방향성 링크가 매번 의미론을 반복하는 대신 재사용 가능한 공유 정의를 참조할 수 있게 합니다.

CIM이 기본 키로 GUID를 사용하는 이유는 무엇입니까?

id 속성에 GUID를 사용하면 중앙 조정 없이도 식별자가 전역적으로 고유함을 보장할 수 있습니다. 이는 레코드가 서로 다른 시스템에서 생성되어 나중에 병합되는 멀티 클라우드 및 멀티 벤더 환경에서 충돌을 효과적으로 방지할 수 있기 때문에 중요합니다.

CIM은 데이터베이스 스키마인가요, 아니면 데이터 교환 형식인가요?

물리적 데이터베이스 스키마보다는 개념적 및 교환 모델로 이해하는 것이 가장 적절합니다. URI 기반 용어는 JSON-LD, RDF, 관계형 테이블 또는 속성 그래프에 자연스럽게 매핑되므로, 아키텍처에서 이미 사용 중인 어떤 저장 기술로도 구현할 수 있습니다.

CIM은 OAGIS나 schema.org와 같은 다른 표준과 어떤 관련이 있나요?

CIM은 이러한 노력의 목표인 상호 운용성을 위한 공유 어휘라는 점을 공유하지만, 클라우드 시대의 엔터프라이즈 통합을 대상으로 하며 개방적이고 역참조 가능한(dereferenceable) 용어로 게시됩니다. 실제로 파트너가 요구하는 접점(edges)에서 CIM을 다른 표준에 매핑하여 사용할 수 있습니다.

전체 모델을 한꺼번에 채택해야 하나요?

아니요. CIM은 느슨하게 결합된 엔터티 그룹으로 구성되어 있으므로, 필요한 그룹(예: Party 및 Product)을 먼저 채택하고 나중에 확장할 수 있습니다. 대부분의 팀은 통합 시 가장 많은 어려움을 일으키는 엔터티부터 시작하여 점진적으로 확장합니다.

추가 자료

• Sales order — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — 웹의 구조화된 데이터에 대한 공유 어휘