클라우드 정보 모델

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

주요 내용

• CIM은 제품이 아니라 공유 개방형 데이터 모델입니다. 이는 공통 비즈니스 개념과 그 관계를 정의하여, 서로 다른 애플리케이션이 맞춤형 일회성 매핑 없이 데이터를 교환할 수 있도록 합니다.
• 개방형 표준으로 관리됩니다. CIM은 Linux Foundation의 일부인 Joint Development Foundation 산하에서 오픈 소스로 제공되며, 벤더, 기업 및 더 넓은 커뮤니티의 기여자를 환영합니다.
• 콘텐츠는 주제 영역(Subject Areas, 도메인)으로 구성됩니다. 각 도메인은 주요 비즈니스 개념을 나타내며, 아키텍트와 엔지니어가 점진적으로 채택할 수 있도록 다이어그램을 포함한 다양한 형식으로 게시됩니다.
• 핵심 가치는 통합의 취약성(brittleness)을 줄이는 것입니다. 정형 모델(canonical model)은 지점 간(point-to-point) 변환 코드를 많은 시스템이 매핑할 수 있는 안정적인 대상으로 대체합니다.
• 채택은 스위치를 켜는 것이 아니라 설계 결정의 문제입니다. 어떤 도메인을 채택할지, 소스 시스템을 어떻게 매핑할지, 그리고 시간이 지남에 따라 확장을 어떻게 관리할지를 직접 선택합니다.

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

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

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

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

CIM이 해결하려는 문제는 부수적인 것이 아니라 구조적인 것입니다. 모든 시스템이 각자의 방언으로 말할 때(어떤 시스템은 고객을 “Contact”라 부르고, 다른 시스템은 “Party”, 세 번째 시스템은 “Account”라고 부를 때), 통합 팀은 결국 기하급수적으로 늘어나는 쌍별(pairwise) 매핑 네트워크를 유지 관리하게 됩니다. 새로운 애플리케이션이 추가될 때마다 필요한 변환 수가 배로 늘어나며, 어느 한 시스템의 스키마 변경만으로도 파급 효과가 발생하여 다운스트림 파이프라인이 중단될 수 있습니다. 정형 모델은 이 문제의 형태를 바꿉니다. N개의 시스템이 서로 매핑되는 대신, 각 시스템이 공유 어휘에 한 번만 매핑하면 됩니다.

지점 간(Point-to-Point) 통합이 실패하는 이유

공유 모델의 필요성을 뒷받침하는 실패 모드를 구체적으로 살펴보는 것이 도움이 됩니다.

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

• 조합적 성장. 지점 간 매핑을 사용하면 변환 경로의 수가 대략 시스템 수의 제곱에 비례하여 증가합니다. 10번째 애플리케이션을 추가하는 비용은 두 번째 애플리케이션을 추가하는 것보다 훨씬 더 큽니다.
• 의미적 드리프트(Semantic drift). 두 팀이 모두 “고객 매핑”을 수행하더라도, 고객이 개인인지, 조직인지, 아니면 청구 관계인지에 대해 서로 의견이 다를 수 있습니다. 데이터는 흐르지만 의미는 어긋나게 됩니다.
• 취약한 변경 관리. 한 소스 시스템에서 필드 이름이 변경되거나 새로운 필수 속성이 추가되면, 해당 데이터를 사용하는 모든 소비자 측의 수정이 강제됩니다.
• 중복된 로직. 유효성 검사, 중복 제거 및 ID 확인 규칙이 한 번 정의되어 공유되는 것이 아니라, 각 통합 단계에서 매번 다시 구현됩니다.
• 벤더 종속(Vendor lock-in) 압박. 통합 로직이 특정 벤더의 스키마와 얽혀 있으면, 벤더를 교체하거나 추가하는 것이 플랫폼 전체를 바꾸는 프로젝트가 됩니다.

CIM과 같은 정형 모델이 매핑 작업 자체를 없애는 것은 아닙니다. 모든 소스 시스템은 여전히 모델에 대한 매핑이 필요합니다. 하지만 이 모델이 없애는 것은 그 작업의 증식입니다. 시스템당 공유 모델로 향하는 매핑을 하나만 구축하면, 모델 자체가 시스템 간의 안정적인 계약(contract) 역할을 합니다.

CIM의 구성 방식: 주제 영역

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

이러한 도메인 중심 구조는 채택 과정에서 매우 중요합니다. 한 번에 전체 모델이 필요한 경우는 거의 없습니다. 일반적인 기업은 가장 고통스러운 통합 지점과 관련된 도메인부터 시작하여 접근 방식을 입증하고 점차 확장합니다. 일반적인 시작점은 거의 모든 시스템에 등장하는 다음과 같은 개념들입니다.

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

• 당사자 / 고객(Party / Customer) — 비즈니스를 함께 하는 사람 및 조직, 그리고 그들이 수행하는 역할.
• 제품(Product) — 카탈로그 및 분류를 포함하여 판매, 제공 또는 관리하는 대상.
• 계정 및 관계(Account and relationship) — 당사자가 제품, 계약 및 서로와 관계를 맺는 방식.
• 상호작용 및 활동(Interaction and activity) — 위의 요소들을 연결하는 이벤트, 트랜잭션 및 참여.

각 주제 영역은 다이어그램과 다양한 표현 형식으로 게시되므로, 아키텍트는 개념 모델을 검토하고, 엔지니어는 기계 판독 가능 형식을 사용하며, 비즈니스 이해관계자는 개념이 실제 현실과 일치하는지 검증할 수 있습니다. 이러한 다중 형식 접근 방식은 의도적인 설계 선택입니다. 엔지니어만 읽을 수 있는 모델은 비즈니스적 의미에서 멀어지는 경향이 있기 때문입니다.

CIM과 다른 접근 방식의 비교

CIM은 상호 운용성을 달성하기 위한 여러 옵션 중 하나입니다. 최선의 선택을 하려면 각 방식의 트레이드오프를 이해해야 합니다.

접근 방식	정의	강점	트레이드오프
점대점 매핑 (Point-to-point mapping)	각 시스템 쌍 간의 직접 번역	두 시스템 간의 구성 시 간단함; 공유 거버넌스가 필요 없음	조합적으로 증가함; 취약함; 로직 중복
표준 모델 (CIM 스타일)	각 시스템이 매핑되는 애플리케이션 불가지론적 공유 어휘	선형적인 매핑 노력; 안정적인 계약; 프로젝트 전반에 걸쳐 재사용 가능	거버넌스와 합의가 필요함; 시스템별 매핑은 여전히 필요함
산업 데이터 표준	특정 부문(예: 의료, 금융)을 위한 수직적 표준	깊은 도메인 커버리지; 규제 준수	좁은 범위; 산업 간 엔터프라이즈 개념을 다루지 못할 수 있음
벤더 데이터 모델	통합 허브로 노출되는 플랫폼의 네이티브 스키마	긴밀한 툴링 통합; 단일 벤더 생태계 내에서 빠른 속도	락인 위험; 다른 벤더가 한 쪽의 모델에 맞춰야 함
API 우선 / 읽기 시 스키마 (schema-on-read)	API별로 정의된 계약; 소비 시점에 의미 해결	유연함; 시작 속도가 빠름	의미론적 일관성이 규율에 따라 달라짐; 대규모 거버넌스가 더 어려움

실무 지침: 시스템이 많고, 교차 도메인 개념이 있으며, 통합 환경이 장기간 유지되는 경우 표준 모델을 사용하십시오. 범위가 실제로 두 시스템뿐이고 단기적인 경우 점대점 매핑을 사용하십시오. 산업 표준과 CIM은 상호 보완적입니다. 수직적 표준은 특정 도메인에 정보를 제공할 수 있으며, CIM은 전사적인 공통 어휘를 제공합니다.

실제로 CIM을 채택하는 방법

채택은 단일 마이그레이션이 아니라 일련의 신중한 결정 과정입니다. 실행 가능한 패턴은 다음과 같습니다.

1. 페인 포인트가 크고 경계가 명확한 통합을 선택하세요. 매핑의 고충이 실재하며, 가치를 빠르게 입증할 수 있을 만큼 범위가 작은 도메인을 선택하십시오.
2. 소스 시스템과 해당 스키마의 목록을 작성합니다. 선택한 주제 영역(Subject Area)에서 각 시스템이 개념을 어떻게 정의하는지, 그리고 서로 일치하지 않는 부분은 어디인지 문서화하십시오.
3. 각 시스템을 CIM 도메인에 매핑합니다. 시스템당 하나의 매핑을 공유 모델에 구축하십시오. 이러한 매핑을 일회용 스크립트가 아닌 버전 관리되는 아티팩트로 취급하십시오.
4. 확장 정책을 미리 정의합니다. CIM이 아직 다루지 않는 개념을 어떻게 처리할지 결정하십시오. 확장은 문서화되어야 하고, 일관되게 명명되어야 하며, 광범위하게 유용한 경우 컨소시엄에 다시 제안되어야 합니다.
5. 거버넌스를 설정합니다. 매핑에 대한 소유권, 변경 사항 검토 프로세스, 업스트림 CIM 업데이트와의 동기화 주기를 할당하십시오.
6. 도메인별로 확장합니다. 첫 번째 도메인에서 얻은 매핑 패턴과 거버넌스를 재사용하여 다음 도메인의 비용을 낮추십시오.

두 가지 주의 사항을 분명히 말씀드립니다. 첫째, 표준 모델은 레이어를 하나 더 추가합니다. 이는 공짜가 아니며, 단일 통합이 아니라 여러 통합에 걸친 재사용을 통해 보상을 얻게 됩니다. 둘째, 실제 작업은 매핑 단계에서 이루어집니다. 모델은 안정적인 목표를 제공하지만, 각 소스 필드가 모델의 어느 부분에 대응하는지는 누군가가 결정해야 하며, 이 결정에는 엔지니어링뿐만 아니라 비즈니스 관점의 입력이 필요합니다.

거버넌스, 라이선스 및 기여

CIM은 Linux Foundation 산하에서 운영되는 Joint Development Foundation의 일부로 오픈 소스로 제공됩니다. 이러한 구조는 이를 평가하는 기업에 중요합니다. Linux Foundation은 협력적이고 벤더 중립적인 오픈 소스 프로젝트를 위한 잘 정립된 본거지이며, Joint Development Foundation은 표준 및 사양 프로젝트를 개발하고 운영하기 위해 특별히 설계된 법적 프레임워크를 제공합니다.

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

엔터프라이즈 데이터 아키텍트에게 이 거버넌스 모델의 실질적인 의미는 다음과 같습니다.

• 벤더 중립성. 단일 벤더가 사양을 제어하지 않으므로, 모델이 특정 플랫폼에 유리하게 형성될 위험이 줄어듭니다.
• 개방형 기여. 누구나 변경 사항을 제안할 수 있으며, 이는 모델이 단일 로드맵이 아닌 실제 통합 요구 사항을 반영하며 진화할 수 있음을 의미합니다.
• 사양 중심 프로세스. Joint Development Foundation 모델은 사양의 생성 및 유지 관리를 중심으로 구축되었으며, 이는 조달 및 아키텍처 검토 시 표준이 채택되고 참조되는 방식과 일치합니다.

기여는 권장되며 모두에게 열려 있습니다. 기여는 일반적으로 새로운 또는 개선된 주제 영역, 수정 및 명확화, 예시 다이어그램, 실제 통합 프로젝트의 피드백 형태로 이루어집니다. 가장 가치 있는 기여는 종종 특정 매핑 문제에 직면하여 이를 해결하는 개념을 설명할 수 있는 실무자로부터 나옵니다.

참여하기

CIM 이니셔티브에 참여하는 데 관심이 있으신가요? 좋습니다! 더 자세한 정보는 이메일로 문의해 주시기 바랍니다.

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

이메일 외에도, 관심 있는 도메인의 게시된 주제 영역을 검토하고, 시스템 중 하나를 도메인에 매핑해 보며, 발견한 격차를 커뮤니티에 다시 제안하는 것이 자연스러운 참여 방법입니다. 컨소시엄과 기여가 늘어남에 따라 주제 영역의 수와 범위가 확장되므로, 모델은 사용자가 가져오는 실제 통합 문제의 수에 비례하여 향상됩니다.

자주 묻는 질문

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

CIM은 서로 다른 애플리케이션이 공유 어휘를 통해 데이터를 교환할 수 있도록 공통 비즈니스 개념과 그 관계를 정의하는 애플리케이션 불가지론적인 개방형 데이터 모델입니다. 이는 개방형 컨소시엄에 의해 제작되었으며 개방형 사양으로 게시되었습니다. 설치하는 제품이 아니라, 귀하의 시스템을 매핑하는 모델입니다.

CIM은 누구를 위한 것인가요?

엔터프라이즈 데이터 아키텍트, 통합 및 ETL 엔지니어, 애플리케이션 및 플랫폼 벤더, 그리고 오픈 소스 기여자를 대상으로 합니다. 서로 다른 스키마를 가진 여러 클라우드 및 온프레미스 시스템을 연결해야 하는 사람이라면 누구나 잠재적인 사용자입니다. 벤더의 경우, 공유 모델을 통해 자사 제품과 통합하는 데 필요한 커스텀 작업이 줄어들기 때문에 이점을 얻습니다.

CIM은 어떻게 거버넌스되고 라이선스가 부여되나요?

CIM은 Linux Foundation 산하에서 운영되는 Joint Development Foundation의 일부로 오픈 소스화되었습니다. 이는 벤더 중립적이고 사양 중심적인 거버넌스 프레임워크를 제공합니다. 이러한 구조는 모델을 기여에 개방적으로 유지하고, 특정 단일 벤더의 통제로부터 독립시키기 위해 설계되었습니다.

CIM은 벤더의 네이티브 데이터 모델과 어떻게 다릅니까?

벤더의 네이티브 모델은 해당 벤더의 제품과 생태계에 최적화되어 있으며, 이를 통합 허브로 채택하면 벤더 종속(lock-in) 현상이 발생하는 경향이 있습니다. CIM은 애플리케이션에 구애받지 않도록(application-agnostic) 설계되었으므로, 단일 플랫폼이 어휘를 정의하지 않습니다. 이에 따른 트레이드오프는 벤더 모델이 해당 벤더의 툴링 내에서 즉시 사용 가능한 반면, CIM은 여러 팀 간의 거버넌스와 합의가 필요하다는 점입니다.

CIM을 사용하더라도 여전히 매핑을 작성해야 합니까?

네. 모든 소스 시스템은 여전히 공유 모델에 대한 매핑이 필요합니다. 이점은 모든 시스템 쌍마다 별도의 변환을 만드는 대신, 시스템당 하나의 매핑만 CIM으로 작성하면 된다는 것입니다. 이를 통해 조합론적인 매핑 노력을 대략 선형적인 노력으로 전환할 수 있으며, 개별 시스템의 변경 사항에도 영향을 받지 않는 안정적인 계약(contract)을 확보할 수 있습니다.

CIM 도입을 어떻게 시작하나요?

하나의 주제 영역(Subject Area) 내에서 페인 포인트가 크고 경계가 명확한 단일 통합 사례부터 시작하십시오. 소스 스키마를 인벤토리화하고, 각 시스템을 CIM 도메인에 매핑하며, 확장 및 거버넌스 정책을 정의하고, 매핑을 버전 관리되는 아티팩트로 취급하십시오. 첫 번째 도메인의 가치가 입증되면, 구축한 패턴과 거버넌스를 재사용하여 도메인별로 확장해 나가십시오.

추가 자료

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia