클라우드 정보 모델

통합을 단순화하고 혁신을 가속화하는 애플리케이션-애그노스틱(application-agnostic) 데이터 모델인 CIM에 오신 것을 환영합니다.

주요 내용

• CIM은 개방형 애플리케이션-애그노스틱 데이터 모델입니다. 즉, 다양한 클라우드 및 온프레미스 시스템이 맞춤형 지점 간(point-to-point) 매핑 없이 데이터를 교환할 수 있게 해주는 비즈니스 개념(고객, 주문, 제품 등)의 공유 어휘입니다.
• 특정하고 비용이 많이 드는 문제를 해결하기 위해 존재합니다. 모든 애플리케이션은 자체 데이터 모델을 제공하므로, 통합 팀은 결국 취약하고 혁신을 지연시키는 사용자 정의 변환 코드를 작성하고 유지 관리하게 됩니다.
• 개방형 표준으로 관리되며, 컨소시엄에 의해 제작되고 Linux Foundation의 일부인 Joint Development Foundation 하에 오픈 소스로 제공되므로 누구나 기여, 검토 및 채택할 수 있습니다.
• 콘텐츠는 주제 영역(Subject Areas, 도메인)으로 구성되며, 각 주제 영역은 주요 비즈니스 개념을 나타내고, 디자인은 예제 다이어그램을 포함한 다양한 형식으로 게시됩니다.
• CIM은 제품이 아니라 모델입니다. 의미와 구조를 정의하며, 자신의 시스템에서 데이터를 매핑, 저장 및 이동하는 방법은 여전히 사용자가 선택합니다.

데이터 상호 운용성을 위한 새로운 표준

CIM은 기업 제품 연결을 위한 표준 기반 솔루션을 제공하기 위해 구성된 개방형 컨소시엄에 의해 제작되었습니다. CIM을 사용하면 클라우드 네이티브 애플리케이션 전반에 걸쳐 원활하고 맞춤화된 개인 경험을 만들 수 있습니다.

디지털 혁신을 가속화하고 모든 채널에서 고객에게 개인화된 참여를 제공하기 위해 많은 기업이 여러 클라우드 및 온프레미스 애플리케이션을 채택합니다. 각 애플리케이션은 자체 데이터 모델을 가지고 있으며, 이로 인해 개발자는 서로 다른 시스템 간에 데이터를 매핑하고 변환하는 데 필요한 사용자 지정 코드를 구축, 테스트 및 관리해야 합니다. 이 프로세스는 디지털 혁신을 가속화하는 대신 혁신을 지연시키고 취약한 통합으로 이어집니다.

CIM은 데이터 통합의 어려움을 덜어주기 위한 현대적인 개방형 사양입니다. CIM은 서로 다른 데이터 형식 간에 쉽게 통신할 수 있도록 정의된 표준을 제공합니다. Joint Development Foundation(Linux Foundation 산하)의 일부로 오픈 소스화되었으며, 모든 기여자를 환영합니다.

애플리케이션별 데이터 모델이 무너지는 이유

CIM이 해결하려는 핵심 문제는 특정 애플리케이션의 데이터 모델이 잘못되었다는 것이 아닙니다. 대부분의 모델은 그 자체의 경계 내에서는 완벽하게 합리적입니다. 문제는 여러 모델을 연결할 때 발생하는 조합 폭발(combinatorial explosion)입니다.

전형적인 엔터프라이즈 스택을 생각해 보십시오. CRM, ERP, 마케팅 자동화 플랫폼, 지원 데스크, 데이터 웨어하우스, 그리고 몇 가지 LOB(line-of-business) SaaS 도구들이 있습니다. 각 시스템이 “고객”, “계정”, “주문”, “제품”에 대해 각기 다른 개념을 가지고 있다면, 데이터를 공유해야 하는 모든 시스템 쌍마다 고유한 매핑이 필요합니다. 통합의 수는 대략 시스템 수의 제곱에 비례하여 증가하며, 각 매핑은 누군가가 영원히 유지 관리해야 하는 작고 문서화되지 않았으며 소유권이 없는 로직 조각이 됩니다.

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

통합 실무를 수행해 본 사람이라면 누구에게나 익숙한 증상들은 다음과 같습니다.

• 의미적 드리프트(Semantic drift). CRM에서 “고객”은 청구 엔터티를 의미하지만, 지원 데스크에서는 티켓을 접수하는 사람을 의미합니다. 같은 단어지만 두 가지 의미를 가지며, 아무도 작성한 기억이 없는 매핑에 의해 조용히 조정됩니다.
• 취약한 파이프라인. 공급업체가 필드 이름을 바꾸거나 열거형(enum)을 변경하면, 매핑이 이전 형태에 맞게 하드 코딩되어 있었기 때문에 새벽 2시에 ETL 작업이 실패합니다.
• 중복된 노력. 참조할 공유 기준이 없기 때문에 두 팀이 동일한 두 시스템 간에 거의 동일한 변환 로직을 독립적으로 구축합니다.
• 데이터에 의한 벤더 록인(Vendor lock-in). 플랫폼을 마이그레이션하는 비용이 많이 드는 이유는 소프트웨어 때문이 아니라, 해당 스키마에 묶여 누적된 변환 로직 때문입니다.

공유된 애플리케이션-애그노스틱 모델은 근본 원인을 해결합니다. N-to-N 매핑 대신, 각 시스템은 공통 모델에 한 번만 매핑하고, 공통 모델이 의미를 전달합니다.

”애플리케이션-애그노스틱”의 실제 의미

“애그노스틱(agnostic)“이라는 용어가 종종 느슨하게 사용되기 때문에, 설계 철학을 정확히 짚고 넘어갈 필요가 있습니다.

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

애플리케이션-애그노스틱 모델은 어떤 단일 벤더의 제품에 의해 소유되거나 특정 제품에 최적화되지 않습니다. 이는 특정 애플리케이션의 내부 테이블을 반영하는 용어가 아니라, 도메인 전문가가 인식할 수 있는 용어(고객, 주문, 제품, 위치 등)로 비즈니스 개념을 설명합니다. 이러한 중립성이 바로 이 모델을 유용한 허브로 만드는 핵심입니다. 어떤 참여자도 상호 운용을 위해 경쟁사의 세계관을 채택할 필요가 없습니다.

이는 다른 중립 교환 표준들의 아키텍처적 본능과 동일합니다. **Resource Description Framework (RDF)**와 schema.org가 웹에 사물을 설명하기 위한 공유 어휘를 제공하고, EDI와 이후의 UBL (Universal Business Language, OASIS 표준)이 공급망에 거래를 위한 공유 형식을 제공한 것처럼, CIM은 엔터프라이즈 애플리케이션에 핵심 비즈니스 엔터티를 위한 공유 어휘를 제공하는 것을 목표로 합니다. 차이점은 범위와 현대성입니다. CIM은 배치 파일 교환이 아니라 연결된 API 기반의 클라우드 및 온프레미스 환경을 대상으로 합니다.

유용한 멘탈 모델은 Gregor Hohpe와 Bobby Woolf의 Enterprise Integration Patterns에서 대중화된 엔터프라이즈 통합의 표준 데이터 모델(canonical data model) 패턴입니다. 사실상 CIM은 공동으로 유지 관리되는 표준 모델(허브 앤 스포크 통합 토폴로지의 “허브”)이지만, 한 회사 내부에서 비공개로 개발된 것이 아니라 조직 간에 공유되고 버전 관리되는 개방형 모델입니다.

CIM 구성 방법: 주제 영역 및 도메인

공동으로 정의된 콘텐츠는 도메인, 즉 **주제 영역(Subject Areas)**으로 구성됩니다. 각 주제 영역은 주요 비즈니스 개념을 나타냅니다. CIM 디자인은 예제 다이어그램을 포함하여 각 도메인에 대해 다양한 형식으로 제공됩니다. 주제 영역의 수와 범위는 컨소시엄과 기여가 늘어남에 따라 확장될 것입니다.

실제로 이는 CIM을 단일 모놀리식 스키마가 아닌 관련 모델의 라이브러리로 생각해야 함을 의미합니다. 일반적인 주제 영역(Subject Areas)은 인식 가능한 비즈니스 관심사(예: 당사자 및 계정, 제품 및 카탈로그, 주문 및 거래, 그리고 이들을 하나로 묶는 관계)를 중심으로 클러스터됩니다. 각 영역은 다이어그램과 기계 판독 가능한 정의와 함께 게시되므로, 전체 모델이 완료될 때까지 기다리지 않고도 여러 팀이 서로 다른 시점에 서로 다른 영역을 채택할 수 있습니다.

이 구조에서 몇 가지 실질적인 시사점이 도출됩니다.

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

• 점진적으로 채택하세요. 첫날부터 기업 전체를 CIM에 매핑할 필요는 없습니다. 가장 문제가 심각한 주제 영역(일반적으로 고객 또는 주문 도메인)부터 시작하여 확장하세요.
• 포크(fork)보다는 확장(extend)하세요. CIM에 필요한 개념이 부족한 경우, 이 개방형 모델은 확장 가능하도록 설계되었습니다. 포크는 시간이 흐르며 원래 모델과 멀어지고 상호 운용성 이점을 잃기 때문에, 개인적인 포크를 유지하는 것보다 확장 내용을 다시 기여(contributing back)하는 것이 바람직합니다.
• 다이어그램을 진실의 원천(source of truth)이 아닌 문서로 취급하십시오. 예제 다이어그램은 사람을 위한 것입니다. 여러분의 툴링이 소비해야 할 것은 기계 판독 가능한 정의입니다.

통합 환경에서의 CIM: 결정 방법

CIM은 통합 복잡성을 해결하기 위한 여러 옵션 중 하나입니다. 올바른 선택을 위해서는 도구를 문제에 맞춰야 합니다. 아래 표는 엔터프라이즈 데이터 아키텍트가 일반적으로 검토하는 주요 접근 방식들을 대조한 것입니다.

접근 방식	정의	최적의 상황	주요 트레이드오프
점대점(Point-to-point) 매핑	두 시스템 간에 직접 변환하는 사용자 정의 코드	시스템이 단 두 개뿐이고, 스키마가 안정적이며, 단기적인 관점일 때	확장 불가능; N-to-N 폭발적 증가; 취약함
표준 모델 (예: CIM)	각 시스템이 한 번만 매핑되는 공유된 중립 모델	시스템이 많고, 벤더가 다양하며, 장기적인 통합이 필요할 때	초기 모델링 노력 필요; 거버넌스 필요
벤더 iPaaS 커넥터	통합 플랫폼에서 제공하는 사전 구축된 커넥터	일반적인 SaaS 쌍, 제어보다 속도가 중요할 때	커넥터별로 상이한 의미론; 잠재적인 벤더 종속(lock-in)
산업 교환 표준 (EDI, UBL, HL7 등)	도메인별 메시지 형식	규제 대상이거나 잘 확립된 수직 시장(verticals)	좁은 범위; 주로 배치(batch) 지향적
데이터 가상화 / 연합(federation)	중앙 집중화 없이 소스 전반에 걸쳐 쿼리	분석, 주로 읽기 전용 액세스	의미론적 충돌을 자체적으로 해결하지 못함

의사 결정 휴리스틱은 간단합니다. 공유 엔터티의 의미에 합의해야 하는 시스템이 몇 개 이상이고, 그 시스템들이 서로 다른 벤더 제품인 경우, 표준 모델은 그 자체로 가치를 증명합니다. 시스템이 두 개뿐이고 추가 계획이 없다면 점대점 방식이 괜찮습니다. 순수하게 분석적이고 읽기 전용인 요구사항이라면 연합(federation)으로 충분할 수 있습니다. 하지만 연합은 의미론적 문제를 해결하는 것이 아니라 단순히 옮기는 것뿐이라는 점에 유의하십시오.

CIM은 주변 도구들을 대체하는 것이 아니라 보완합니다. ETL 또는 ELT 파이프라인(Apache Airflow, dbt 또는 상용 플랫폼 등으로 구축된)은 여전히 데이터 이동을 수행하며, CIM은 데이터가 도착했을 때 그 데이터가 무엇을 의미하는지를 정의합니다. Apache Kafka와 같은 메시지 브로커는 여전히 전송을 수행하며, CIM은 이벤트의 형태를 정의합니다. 모델은 계약(contract)이고, 툴링은 배관(plumbing)입니다.

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

거버넌스, 라이선스, 그리고 재단이 중요한 이유

CIM은 Linux Foundation 산하에서 운영되는 Joint Development Foundation의 일부로 오픈 소스화되었습니다. 이는 사소한 세부 사항이 아니라, 기업이 CIM을 기반으로 안전하게 구축할 수 있는 핵심 이유입니다.

Linux Foundation은 협력적인 오픈 소스 프로젝트를 위한 잘 확립된 중립적 거점이며, Joint Development Foundation은 표준 및 사양을 공동으로 개발하기 위한 가벼운 법적 구조를 제공합니다. CIM이 이곳에서 호스팅된다는 것은 다음을 의미합니다.

• 중립적 관리. 단일 벤더가 모델을 제어하지 않으므로, 이를 채택하는 것이 경쟁사의 로드맵을 따르는 것을 의미하지 않습니다.
• 개방적 기여. 벤더, 기업, 개인 기여자 등 누구나 변경 사항을 제안할 수 있으며 그 과정은 투명합니다.
• 예측 가능한 라이선스. 재단이 호스팅하는 사양은 일반적으로 광범위하고 로열티 친화적인 채택을 위해 설계된 조건을 따르며, 이는 표준을 평가하는 법무 및 조달 팀에 매우 중요합니다.

내부적으로 설득해야 하는 아키텍트에게 이러한 거버넌스 스토리는 기술적 내용만큼이나 중요한 경우가 많습니다. “Linux Foundation 산하의 개방형 표준입니다”라는 말은 표준 채택을 가로막는 질문들—누가 제어하는가? 벤더가 사업을 접으면 어떻게 되는가? 우리의 확장 기능을 기여할 수 있는가?—에 대한 답이 됩니다.

시작하기: 실용적인 채택 경로

공유 모델을 채택하는 것은 기술적인 작업인 동시에 조직적인 작업이기도 합니다. 실용적인 순서는 다음과 같습니다.

1. 공유 엔터티 목록을 작성하십시오. 둘 이상의 시스템에 나타나는 비즈니스 개념(일반적으로 고객, 제품, 주문, 위치)을 식별하십시오. 이것들이 후보가 됩니다.
2. 하나의 주제 영역과 하나의 통합 사례를 선택하십시오. 모델을 검증하기 위해 고통은 가장 크지만 영향 범위(blast-radius)는 가장 낮은 통합 사례를 선택하십시오. 단일 보고 파이프라인이나 하나의 새로운 애플리케이션 온보딩이 이상적입니다.
3. 각 시스템을 CIM에 한 번만 매핑하십시오. 각 소스 시스템에서 CIM 표현으로, 그리고 CIM에서 각 타겟으로의 변환을 구축하십시오. 시스템 간에 직접 매핑하려는 유혹을 뿌리치십시오.
4. 확장 내용을 문서화하십시오. CIM이 특정 개념을 다루지 않는 경우, 확장 내용을 명시적으로 기록하고 이를 다시 기여하는 것을 고려하십시오.
5. 소유권을 확립하십시오. 관리자(steward)가 없는 표준 모델은 퇴보합니다. 매핑과 업스트림 변경 사항 추적을 책임질 팀이나 역할을 지정하십시오.
6. 버전 관리 및 테스트를 수행하십시오. 애플리케이션 코드와 마찬가지로, 모델과 해당 매핑을 테스트가 포함된 버전 관리 아티팩트로 취급하십시오.

가장 일반적인 실패 사례는 CIM을 살아있는 계약이 아닌 일회성 모델링 작업으로 취급하는 것입니다. 성공하는 조직은 모델을 API와 동일하게 취급합니다. 즉, 의도적으로 버전 관리하고, 테스트하고, 소유하며, 발전시킵니다.

CIM에 기여하는 파트너

CIM은 컨소시엄의 노력이며, 참여가 늘어날수록 그 가치도 커집니다. 파트너는 주제 영역(Subject Area) 콘텐츠를 제공하고, 제안서를 검토하며, 모델의 방향을 설정하는 데 도움을 줍니다. 작업 과정이 공개되어 있으므로 기여는 대규모 벤더에만 국한되지 않습니다. 실제 통합 과정에서 어려움을 겪는 기업과 도메인 전문 지식을 갖춘 개별 실무자 모두 동일하게 환영합니다.

연락하기

CIM 이니셔티브에 참여하는 데 관심이 있으신가요? 좋습니다! 자세한 내용은 언제든지 이메일로 문의해 주세요. [이메일 보내기].

자주 묻는 질문

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

CIM은 기업이 클라우드 및 온프레미스 애플리케이션 간에 교환해야 하는 비즈니스 개념에 대해 공유된 표준 기반 어휘를 제공하는 애플리케이션 불가지론적(application-agnostic) 오픈 소스 데이터 모델입니다. 이는 개방형 컨소시엄에 의해 제작되었으며, Linux Foundation의 일부인 Joint Development Foundation에서 호스팅됩니다. 그 목적은 취약한 포인트 투 포인트(point-to-point) 통합에 필요한 커스텀 매핑 코드를 줄이는 것입니다.

CIM은 제품인가요, 사양인가요?

CIM은 실행 가능한 제품이 아니라 사양(specification), 즉 모델과 정의의 집합입니다. CIM은 공유 엔터티의 의미와 구조를 정의하며, ETL/ELT 도구, 메시지 브로커 및 저장소는 사용자가 직접 선택합니다. CIM을 배관 그 자체가 아니라, 통합 배관이 구현해야 하는 ‘계약’이라고 생각하십시오.

CIM은 벤더의 통합 플랫폼과 어떻게 다릅니까?

통합 플랫폼(iPaaS 또는 커넥터 라이브러리)은 데이터를 이동시키고 종종 사전 구축된 커넥터를 제공하지만, 이러한 커넥터에는 벤더 전용 시맨틱이 인코딩되어 있습니다. CIM은 중립적이고 벤더 독립적이므로 특정 플랫폼의 세계관에 종속되지 않습니다. 이 둘은 상호 보완적입니다. 모든 통합 플랫폼 내부에서 CIM을 표준 모델(canonical model)로 사용할 수 있습니다.

CIM의 주제 영역(Subject Areas)이란 무엇입니까?

주제 영역(도메인이라고도 함)은 모델의 구성 단위로, 각각 고객, 제품 또는 주문과 같은 주요 비즈니스 개념을 나타냅니다. 설계 내용은 예제 다이어그램을 포함한 여러 형식으로 게시되며, 컨소시엄과 커뮤니티가 더 많은 콘텐츠를 기여함에 따라 주제 영역 세트가 계속 확장될 예정입니다.

CIM이 저희의 개념을 다루지 않는 경우 확장할 수 있나요?

네. CIM은 확장 가능하도록 설계되었으며, 중립적인 재단 산하의 오픈 소스이므로 기여 프로세스를 통해 추가 사항을 제안할 수 있습니다. 공유 모델을 확장하고 다시 기여하는 것이 개인적인 포크(private fork)를 유지하는 것보다 훨씬 바람직합니다. 개인 포크는 시간이 지남에 따라 원본과 괴리되며, 애초에 CIM을 채택하게 만든 동기인 상호 운용성 이점을 상실하게 됩니다.

누가 CIM을 채택해야 하나요?

공유 엔터티의 의미에 대해 합의해야 하는 다양한 벤더의 수많은 애플리케이션을 운영하는 조직에 가장 가치가 있으며, 이는 엔터프라이즈 데이터 아키텍트와 통합 엔지니어들이 겪는 전형적인 상황입니다. 애플리케이션 및 플랫폼 벤더 또한 스키마를 중립 모델에 맞춤으로써 고객이 제품을 더 쉽게 통합할 수 있게 된다는 이점이 있습니다. 만약 안정적인 시스템이 두 개뿐이라면, 더 간단한 포인트 투 포인트 매핑으로도 충분할 수 있습니다.

추가 자료

• Linux Foundation — 위키피디아
• Joint Development Foundation — 위키피디아
• Enterprise Integration Patterns — 위키피디아
• Resource Description Framework (RDF) — 위키피디아