CIM 모델

(CIM)은 CRM, ERP, 마케팅, 서비스 및 분석 시스템 전반에 걸쳐 나타나는 엔터티에 대해 기업이 공유 어휘를 가질 수 있도록 설계된 개방형 애플리케이션 독립적(application-agnostic) 데이터 모델입니다. 각 공급업체가 자체적인 개체 이름과 관계를 정의하는 대신, CIM은 모든 시스템이 매핑할 수 있는 공통의 주제 영역, 엔터티 및 속성 집합을 정의합니다. 이 모델은 광범위한 협업 데이터 및 인프라 프로젝트 포트폴리오를 호스팅하는 Linux Foundation 산하의 오픈 소스 프로젝트로 관리됩니다.

이 문서에서는 CIM의 구조, 구성 요소 간의 관계, 상위 유형(supertype)과 하위 유형(subtype)의 작동 방식, 그리고 주제 영역의 구성 방식에 대해 설명합니다. 또한 매핑, 거버넌스, 버전 관리, 확장 등 아키텍트가 CIM을 채택할 때 직면하는 실질적인 결정 사항과 다른 업계 표준 대비 모델의 위치에 대해서도 다룹니다.

주요 내용

• CIM은 비즈니스 개념을 **주제 영역(Subject Areas)**으로 구성하며, 각 주제 영역은 엔터티 그룹(Entity Groups), 엔터티(Entities), **속성(Attributes)**을 포함합니다. 이 계층 구조는 스키마, 테이블 및 열에 깔끔하게 매핑됩니다.
• 상위 유형 및 하위 유형을 통해 모델은 전문화를 허용하면서도 공유 특성(사람 또는 조직인 당사자/Party)을 표현할 수 있습니다.
• 이 모델은 의도적으로 애플리케이션 독립적입니다. 즉, 특정 공급업체의 구현 방식이 아닌 비즈니스 개념 자체를 설명합니다.
• CIM은 예제 다이어그램과 함께 다양한 형식으로 게시되므로 모델링 도구, 코드 생성기 및 문서에서 동일하게 활용할 수 있습니다.
• 주제 영역의 수와 범위는 컨소시엄 및 커뮤니티의 기여에 따라 증가하므로, 채택 시 버전 관리 및 변경 관리를 고려해야 합니다.
• CIM은 여러 옵션 중 하나입니다. 적절한 선택은 광범위한 교차 도메인 모델이 필요한지, 아니면 특정 산업을 위한 좁고 깊은 표준이 필요한지에 따라 달라집니다.

CIM의 구조

CIM은 콘텐츠를 더 쉽게 탐색하고 활용할 수 있도록 구성 요소별로 조직되어 있습니다. 계층 구조의 각 수준은 서로 다른 질문에 답하며, 이 계층 구조를 이해하는 것이 모델을 제대로 사용하기 위한 첫 번째 단계입니다.

• 주제 영역(Subject Area) — Party와 같이 CIM 컨소시엄에서 식별한 주요 비즈니스 개념입니다. 각 주제 영역에는 하나 이상의 엔터티 그룹이 포함됩니다. 주제 영역을 바운디드 컨텍스트(bounded context)로 생각하십시오. 즉, 비즈니스가 하나의 광범위한 테마에 대해 알아야 하는 모든 것을 그룹화한 것입니다.
• 엔터티 그룹(Entity Group) — Account와 같이 주제 영역 내에서 관련된 엔터티들의 논리적 그룹입니다. 엔터티 그룹은 대규모 주제 영역의 탐색 가능성을 유지하며, 팀에 소유권을 할당하기 위한 자연스러운 단위를 제공합니다.
• 엔터티(Entity) — Account Contact와 같이 조직이 정보를 수집하는 고유한 개체입니다. 엔터티는 표준 데이터베이스 테이블과 유사합니다.
• 속성(Attribute) — Account Id 또는 Contact Email과 같이 엔터티의 고유한 특성입니다. 속성은 테이블 내의 표준 데이터베이스 필드와 유사합니다.

이 4단계 계층 구조는 의도적으로 친숙하게 설계되었습니다. 관계형 모델링, 차원 모델링 또는 엔터티-관계 다이어그램(ERD)을 다뤄본 데이터 아키텍트라면 이 패턴을 즉시 인식할 것입니다. CIM이 제공하는 가치는 새로운 모델링 기술이 아니라, 여러 조직과 공급업체가 합의할 수 있는 공유되고 사전 협상된 이름 및 관계 세트입니다.

유용한 멘탈 모델: 주제 영역은 대략적으로 스키마 또는 도메인이고, 엔터티 그룹은 대략적으로 네임스페이스 또는 모듈이며, 엔터티는 테이블, 속성은 열입니다. 이 매핑은 근사치입니다. CIM은 물리적 모델이 아닌 개념적 및 논리적 모델이지만, CIM을 물리적 구현으로 변환할 때 도움이 됩니다.

상위 유형 및 하위 유형

네 가지 핵심 구성 요소 외에도, CIM 설계는 상위 유형과 하위 유형을 사용하여 엔터티를 추가적인 그룹으로 사용자 정의하고 확장합니다. 이 지점에서 모델의 표현력이 크게 향상됩니다.

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

• 상위 유형(Supertype) — 하위 유형 엔터티에 의해 확장되며, 유사한 개념들에 대한 공통 속성을 정의하는 엔터티입니다.
• 하위 유형(Subtype) — 다른 엔터티를 확장하며, 상위 유형 엔터티로부터 속성을 상속받는 엔터티입니다.

전형적인 예는 **Party(당사자)**입니다. Party는 비즈니스가 거래하는 모든 사람 또는 모든 것을 의미합니다. 사람(Person)과 조직(Organization)은 모두 Party이며 이름, 식별자, 연락처 등의 속성을 공유하지만, 각각 상대방이 갖지 않는 고유한 속성도 가지고 있습니다. Party를 상위 유형으로, Person과 Organization을 하위 유형으로 모델링하면 공유 속성의 중복을 방지하고, 어떤 하위 유형이 관여하든 관계(예: “이 기회는 이 Party에 속함”)를 일관되게 유지할 수 있습니다.

이러한 상속은 데이터 모델링에서 잘 확립된 개념이며, Object Management Group의 UML과 같은 표준 및 업계 전반에서 사용되는 엔터티-관계 규칙에 나타납니다. CIM을 물리적으로 구현할 때는 상속을 어떻게 표현할지 결정해야 합니다.

• 단일 테이블(Single table) — 판별자(discriminator) 열이 있는 하나의 테이블에 모든 하위 유형을 저장합니다. 쿼리가 간단하지만, Null 허용 열이 많이 생길 수 있습니다.
• 클래스 테이블 상속(Class table inheritance) — 상위 유형을 위한 테이블 하나와 하위 유형별 테이블을 각각 두고 공유 키로 조인합니다. 정규화되어 깔끔하지만 조인이 필요합니다.
• 구체적 테이블 상속(Concrete table inheritance) — 하위 유형별로 별도의 독립된 테이블을 둡니다. 하위 유형 전용 쿼리에는 빠르지만 공유 속성이 중복됩니다.

보편적으로 정답인 방법은 없습니다. 올바른 선택은 쿼리 패턴, 하위 유형의 수, 그리고 공유 속성을 얼마나 자주 함께 읽는지에 따라 달라집니다. 이 결정은 모든 다운스트림 통합에 영향을 미치므로 반드시 문서화하십시오.

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

CIM 주제 영역

주제 영역은 지금까지 컨소시엄이 모델링한 주요 비즈니스 개념을 나타냅니다. 각각은 자체 다이어그램과 형식으로 게시되며, 일부는 일부 영역이 다른 영역보다 더 성숙하다는 것을 반영하여 명시적인 버전 표시(예: v1.0 또는 v0.1.1)를 포함합니다.

Setup(설정) — 고객, 공급업체, 판매자 등 거래 대상을 정의합니다. 또한 소프트웨어 호스트, 소프트웨어 테넌트, 소프트웨어 사용자, 소프트웨어 앱, 소프트웨어 테스트, 소프트웨어 서비스, 소프트웨어 일괄 작업 및 IoT 장치 등 조직이 운영하는 소프트웨어 및 인프라 개념도 다룹니다.

Data Model(데이터 모델) — 기본 모델링 개념 자체입니다.

Hire(고용) — 내부 사업부 및 직원 등 비즈니스 설립과 관련된 활동입니다. 엔터티 그룹에는 입사 지원서, 직원, 보상, 교육, 위치, 작업 영역 및 작업 보고서가 포함됩니다.

Biz Process(비즈니스 프로세스) — 비즈니스 프로세스 및 비즈니스 연속성 개념입니다.

Produce(생산) — 구매, 이동, 판매할 자재(예: 제품 및 재고 제품)의 처리를 다룹니다. 엔터티 그룹에는 공급업체 제품, 수령된 재고, 재고 제품, 재고 이전, 전자 미디어, 구매 주문 및 판매 계약이 포함됩니다.

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

Market(시장) — 마케팅 캠페인, 웹 스토어 등 제품 홍보에 사용되는 활동입니다. 엔터티 그룹에는 당사자 식별(Party Resolution), 개인 정보 보호 동의, 시장 대상자, 캠페인, 판촉, 거래 이벤트, 광고 구매 및 웹 사이트가 포함됩니다.

Sell(판매) — 견적 및 기회 생성 등 제품 판매에 사용되는 활동입니다. 엔터티 그룹에는 가격 목록, 장바구니, 견적, 계약, 기회, 기회 예측, 판매 주문, 충성도 프로그램 및 경쟁사가 포함됩니다.

Service(서비스) — 판매 또는 서비스되는 제품에 대한 지원을 제공하는 활동(예: 케이스 또는 설문 조사)입니다. 엔터티 그룹에는 AI Assistant, 자산, 자산 구독, 웹 콘텐츠, 케이스, 작업 및 이벤트가 포함됩니다.

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

Fulfill(이행) — 배송 및 반품 주문과 같이 고객에 대한 주문을 이행하기 위해 수행하는 활동입니다. 엔터티 그룹에는 이행 주문, 배송, 반품 주문, 작업 주문, 작업 자원 및 작업 예측이 포함됩니다.

Interact(상호작용) — 최종 사용자 또는 다른 시스템과의 참여를 추적하는 활동입니다. 엔터티 그룹에는 참여, 대화, 약속, 소프트웨어 이벤트, 데이터 커넥터, 데이터 이동, 충성도 여정 및 충성도가 포함됩니다.

Finance(재무) — 결제, 송장, 비용 보고서 등 회사의 재무 정보를 추적하는 활동입니다. 엔터티 그룹에는 예산, 송장, 결제 방법, 결제, 대변 메모, 재무 원장 계정, 예측, 달력 및 세금 정책이 포함됩니다.

Analyze(분석) — 패턴 분석, 제품 사용, 데이터 이동, 데이터 변경, 고객 만족도 등 데이터 분석과 관련된 활동입니다. 엔터티 그룹에는 AI 모델, AI 애플리케이션, IoT 장치 사용, 데이터 계보, 블록체인, 설문 조사, 충성도 및 저널이 포함됩니다.

주제 영역이 어떻게 운영 관련 관심사(Sell, Fulfill, Service)와 분석 관련 관심사(Analyze, Finance) 모두를 아우르는지 확인하십시오. 이러한 폭넓은 범위가 핵심입니다. 공유 모델은 데이터가 트랜잭션 시스템에 있든 데이터 웨어하우스에 있든 상관없이 동일한 고객, 제품 또는 주문을 일관되게 설명할 수 있을 때 가장 가치가 있습니다.

CIM과 다른 표준 중에서 선택하기

CIM은 기업 내의 유일한 공유 모델이 아닙니다. 확립된 여러 표준이 그 범위의 일부와 겹치며, 성숙한 아키텍처는 종종 둘 이상의 표준을 사용합니다. 결정은 단순히 승자를 선택하는 것이 아니라, 모델의 범위와 거버넌스를 해결하려는 문제에 맞추는 것입니다.

표준	주요 초점	일반적인 강점	CIM과의 차이점
CIM	도메인 간 비즈니스 개념	CRM/ERP/마케팅/서비스에 대한 광범위하고 애플리케이션에 구애받지 않는 적용 범위	도메인 전반에 걸친 공유 우산(umbrella)으로 설계됨
OMG 공통 핵심 온톨로지 / UML 기반 모델	개념적 모델링 표기법 및 상위 온톨로지	엄격한 형식적 의미론	CIM은 보다 직접적으로 비즈니스 지향적임
산업별 모델(예: 소매, 의료, 금융 수직 시장)	한 섹터에 대한 심층적인 적용 범위	해당 수직 시장 내의 정밀도	CIM은 깊이 대신 폭을 선택함
벤더 데이터 모델(CRM/ERP 플랫폼)	단일 제품의 객체	해당 제품과의 긴밀한 통합	CIM은 설계 단계부터 벤더 중립적임

실용적인 경험 법칙:

• 여러 시스템과 벤더에 걸쳐 공유되는 어휘가 필요한 경우, CIM과 같은 광범위한 모델이 적합합니다.
• 심층적이고 규제된 산업별 의미론이 필요한 경우, 일반적으로 수직적 표준이 더 정확하며, 이를 경계 지점에서 CIM에 매핑할 수 있습니다.
• 단일 벤더의 생태계 내에서 통합하는 경우, 해당 벤더의 자체 모델로 충분할 수 있습니다. 하지만 이는 다음 벤더와 연결하는 데는 도움이 되지 않습니다.

가장 일반적인 실제 패턴은 허브 앤 스포크(hub-and-spoke) 접근 방식입니다. CIM(또는 다른 표준 모델)이 중앙에 위치하고, 각 소스 시스템이 여기에 매핑됩니다. 이는 마스터 데이터 관리(MDM)의 표준 데이터 모델(canonical data models)과 Ralph Kimball이 차원 모델링에서 대중화한 “정형 차원(conformed dimension)” 개념의 기반이 되는 동일한 원리입니다.

CIM 도입을 위한 실무 지침

공유 모델을 채택하는 것은 기술적인 작업인 동시에 조직적인 작업이기도 합니다. 몇 가지 결정에 따라 노력의 성과가 결정됩니다.

제한된 범위로 시작하십시오. 모든 시스템을 모든 주제 영역에 한꺼번에 매핑하려고 시도하지 마십시오. 하나의 고가치 도메인을 선택하십시오. 고객 및 기회 데이터가 광범위하게 중복되므로 Party와 Sell이 일반적인 시작점이며, 매핑을 엔드 투 엔드로 증명하십시오.

확장 정책을 조기에 결정하십시오. CIM은 컨소시엄과 기여를 통해 성장하도록 설계되었지만, 조직에서는 필연적으로 모델이 아직 정의하지 않은 속성이 필요하게 됩니다. 사용자 정의 속성이 표준 속성과 명확하게 구별되고 나중에 조정될 수 있도록 로컬 확장(예: 네임스페이스 접두사)에 대한 규칙을 설정하십시오.

버전 관리를 최우선 과제로 취급하십시오. 주제 영역에는 모델이 진화하고 있음을 나타내는 v1.0 및 v0.1.1과 같은 버전 표시가 있습니다. 빌드 기준이 되는 버전을 고정하고, 변경 사항을 추적하며, 마이그레이션을 계획하십시오. 이는 모든 종속성에 적용하는 것과 동일한 원칙입니다.

복사하지 말고 매핑하십시오. CIM은 개념적 및 논리적 모델입니다. 데이터를 소비할 시스템의 성능, 인덱싱 및 액세스 패턴을 고려하지 않고 물리적 스키마를 직접 생성하려는 유혹을 뿌리치십시오. 모델을 사용하여 의미를 맞춘 다음, 워크로드에 맞는 물리적 스토리지를 설계하십시오.

매핑을 거버넌스하십시오. 소스 시스템과 CIM 간의 매핑은 그 자체로 하나의 자산입니다. 버전을 관리하고, 검토하며, 소유권을 할당하십시오. 데이터 통합 분야의 도구(ETL 및 ELT 플랫폼, 데이터 카탈로그, 리니지 도구)는 각 속성의 출처와 흐름 방식을 추적하는 데 도움이 되며, 이는 Analyze 주제 영역이 Data Lineage와 같은 엔터티를 통해 예상하는 메타데이터의 종류와 정확히 일치합니다.

커뮤니티에 참여하십시오. CIM은 오픈 소스이며 컨소시엄 중심으로 운영되므로, 귀하가 발견한 공백은 다른 사람들도 발견했을 가능성이 큽니다. 제안된 엔터티나 속성을 프로젝트에 다시 기여하는 것은 좋은 시민 정신일 뿐만 아니라 장기적인 유지 관리 부담을 줄이는 방법이기도 합니다.

형식, 다이어그램 및 소비

CIM 설계는 예제 다이어그램을 포함하여 각 도메인에 대해 여러 형식으로 제공됩니다. 이는 대상마다 데이터 모델을 소비하는 방식이 다르기 때문에 중요합니다.

• 아키텍트는 구조를 추론하기 위해 다이어그램과 관계 뷰를 원합니다.
• 엔지니어는 코드 생성, 스키마 검증 또는 매핑 도구에 입력할 수 있는 기계 판독 가능한 정의를 원합니다.
• 분석가 및 스튜어드는 각 엔터티와 속성이 비즈니스 용어로 무엇을 의미하는지 설명하는 문서를 원합니다.

여러 형식으로 게시하는 것은 채택 장벽을 낮추기 위한 의도적인 설계 선택입니다. 공유 모델을 평가할 때, 사용 중인 툴체인이 실제로 수집할 수 있는 형식으로 제공되는지 확인하십시오. PDF로만 존재하는 모델은 구조화된 정의가 있는 모델보다 훨씬 덜 유용합니다.

자주 묻는 질문

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

클라우드 정보 모델은 다양한 클라우드 및 온프레미스 시스템이 공통 어휘를 사용하여 데이터를 교환할 수 있도록 Party, Account, Sales Order와 같은 공유 비즈니스 개념을 정의하는 개방형 애플리케이션 독립적 데이터 모델입니다. 이는 주제 영역, 엔터티 그룹, 엔터티 및 속성으로 구성되며, Linux Foundation 산하의 오픈 소스 프로젝트로 관리됩니다.

CIM에서 상위 유형(supertype)과 하위 유형(subtype)의 차이점은 무엇입니까?

상위 유형은 하위 유형 엔터티에 의해 확장되며 유사한 개념에 공통적인 속성을 정의하는 엔터티입니다. 하위 유형은 다른 엔터티를 확장하고 상위 유형의 속성을 상속합니다. 예를 들어, Party가 상위 유형으로 작동하고 Person과 Organization이 하위 유형이 될 수 있으며, 이를 통해 공유 속성은 한 번만 정의되고 특수 속성은 하위 유형에 배치됩니다.

CIM은 데이터베이스 스키마와 어떤 관련이 있나요?

CIM은 물리적 스키마가 아니라 개념적 및 논리적 모델입니다. CIM의 엔터티는 데이터베이스 테이블에, 속성은 필드에 대응하므로 변환이 직관적이지만, 모델을 문자 그대로 복사하기보다는 자체 쿼리 패턴에 맞춰 물리적 스토리지(인덱싱, 파티셔닝, 비정규화)를 설계해야 합니다.

CIM이 산업별 데이터 표준을 대체하는 것입니까?

아니요. CIM은 광범위하고 교차 도메인적인 반면, 수직적 표준은 심층적이고 특정 섹터에 특화되어 있습니다. 많은 조직이 CIM을 중앙의 표준(canonical) 모델로 사용하고 산업 표준이나 벤더 모델을 가장자리에서 이에 매핑하는 허브 앤 스포크(hub-and-spoke) 방식을 사용합니다.

CIM 주제 영역에 버전 번호가 있는 이유는 무엇입니까?

v1.0 및 v0.1.1과 같은 버전 표시는 모델이 진화하고 있으며 일부 주제 영역이 다른 영역보다 더 성숙했음을 나타냅니다. 버전을 고정하고, 변경 사항을 추적하며, 마이그레이션을 계획하는 것은 공유 라이브러리나 스키마에 적용하는 것과 동일한 종속성 관리 원칙입니다.

CIM이 정의하지 않은 속성은 어떻게 처리하나요?

네임스페이스 접두사와 같이 문서화된 확장 규칙을 설정하여 사용자 정의 속성이 표준 속성과 명확하게 구별되도록 하십시오. 그 후, 모델이 컨소시엄과 커뮤니티의 기여를 통해 성장하도록 설계되었으므로 해당 공백을 프로젝트에 다시 기여하는 것을 고려하십시오.