리소스

작성자: Cloud Information Model Content Collective · 업데이트: 2026년 9월 23일

페이지는 CIM(Cloud Information Model)을 이해, 채택 또는 기여하려는 모든 사람을 위한 진입점입니다. CIM은 Linux Foundation에서 관리하는 애플리케이션에 구애받지 않는(application-agnostic) 오픈 소스 데이터 모델로, 각 통합 팀이 자체 스키마를 매번 새로 만들지 않고도 클라우드와 온프레미스 시스템이 데이터를 교환할 수 있도록 비즈니스 엔터티의 공유 어휘를 정의합니다. 이 페이지에서는 CIM을 평가하는 데 필요한 아티팩트, 지원되는 형식, 모델이 저장된 저장소 및 참여 채널을 수집합니다.

주요 내용

CIM은 제품이나 데이터베이스가 아니라 공급업체 중립적인 공유 데이터 모델입니다. 즉, 여러 애플리케이션이 매핑할 수 있는 엔터티, 속성 및 관계를 설명합니다.
주요 기술 자산은 CIM GitHub 조직에 있으며, 이곳에서 모델 정의와 도구의 버전이 관리되고 공개 라이선스가 부여됩니다.
CIM은 여러 표준 형식으로 표현되므로, 특정 직렬화 방식에 종속되지 않고 다양한 도구 체인에서 사용할 수 있습니다.
프레젠테이션, FAQ 및 뉴스 페이지는 기술적인 심층 분석에 앞서 비즈니스 케이스를 구축하고 이해관계자의 질문에 답변할 수 있는 가장 빠른 방법입니다.
기여는 GitHub 저장소와 기여자 웹 양식을 통해 이루어집니다. 모델은 단일 공급업체의 로드맵이 아닌 커뮤니티 검토를 통해 발전합니다.

클라우드 정보 모델(CIM)의 실제 정의

CIM은 *표준 모델(canonical model)*로 이해하는 것이 가장 좋습니다. 즉, 이미 운영 중인 시스템들 사이에 위치하며 비즈니스 개념(고객, 계정, 주문, 제품, 연락처 및 이들 간의 관계)을 중립적이고 합의된 방식으로 표현한 것입니다. 모든 애플리케이션이 다른 모든 애플리케이션의 방언을 사용하도록 강제하는 대신, 각 시스템을 CIM에 한 번만 매핑하면 CIM이 상호 교환 지점이 됩니다.

이는 엔터프라이즈 통합에서 반복적으로 나타나는 동일한 아키텍처 패턴입니다. 즉, 지점 간(point-to-point) 매핑의 그물망 대신 허브 앤 스포크(hub-and-spoke) 방식의 표준 스키마를 사용하는 것입니다. 이는 개념적으로 문서용 OASIS UBL(Universal Business Language), 비즈니스 메시지용 OAGIS(Open Applications Group Integration Specification), 웹 규모 어휘용 schema.org와 같은 노력과 관련이 있습니다. CIM의 차별화된 강조점은 애플리케이션에 구애받지 않으며, 대부분의 기업이 실제로 운영하는 ‘클라우드 및 온프레미스 병행’ 현실에 맞게 설계되었다는 점입니다.

실질적인 이점은 매핑 확산(mapping sprawl)의 감소입니다. n개의 시스템이 있고 각각이 서로 통신해야 한다면, 약 n²개의 매핑이 필요합니다. 하지만 표준 모델을 도입하면 작업량이 n개의 매핑(시스템당 하나씩 공유 모델에 매핑)으로 줄어듭니다. 이러한 감소가 CIM 채택의 핵심적인 경제적 논거입니다.

CIM 프레젠테이션

CIM 프레젠테이션은 내부적으로 비즈니스 케이스를 구축하려는 모든 분께 권장되는 시작 아티팩트입니다. 이는 아키텍트, 데이터 거버넌스 리더, 비즈니스 스폰서 등 다양한 청중에게 보여주도록 설계되었으며, 공유 모델의 도입 동기, CIM이 정의하는 범위, 그리고 기존 통합 환경에 어떻게 적용되는지를 다룹니다.

다음과 같이 활용하십시오:

관련 항목: — 계속 실행되는 완전 관리형 ELT 파이프라인.

임원 및 스폰서 대상: 매핑 확산 문제와 공급업체 중립성 논거를 중심으로 설명하십시오. 이 프레젠테이션은 CIM을 ‘전면 교체(rip-and-replace)‘가 아닌 ‘리스크 감소’의 관점에서 제시합니다.
아키텍트 및 엔지니어 대상: 컨텍스트를 설정하는 용도로 사용한 후, 실제 모델 정의가 있는 GitHub 저장소로 즉시 안내하십시오.
거버넌스 및 컴플라이언스 이해관계자 대상: 소유권, 버전 관리, 모델 변경 사항의 검토 방식에 대한 논의를 시작하는 용도로 사용하십시오.

프레젠테이션은 대화의 시작점일 뿐 사양서(specification)가 아닙니다. 프레젠테이션은 진입로로, 저장소는 진실의 원천(source of truth)으로 취급하십시오.

CIM 형식

CIM은 단일 독점 직렬화 방식 대신 의도적으로 여러 표준과 형식을 지원합니다. 엔터프라이즈 도구 체인은 이기종(heterogeneous)이기 때문에 이는 매우 중요합니다. 모델링 도구, ETL 플랫폼, API 게이트웨이, 문서 생성기가 각각 서로 다른 표현 방식을 선호할 수 있기 때문입니다.

이 분야에서 일반적으로 관련 있는 형식 계열은 다음과 같습니다:

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

인적 검토 및 디자인 워크숍을 위한 엔터티-관계(ER) 및 개념 표기법.
API 및 애플리케이션 소비를 위한 JSON 기반 스키마 표현.
시맨틱 및 지식 그래프 사용 사례를 위한 RDF 및 온톨로지 스타일 표현.
데이터 웨어하우스 및 ETL 파이프라인을 위한 관계형 및 테이블 형식 매핑.

설계 원칙은 이식성입니다. 개방형 형식으로 표현된 모델은 표준 도구를 사용하여 변환, 비교(diff), 버전 제어 및 검증이 가능합니다. 조직에서 CIM을 평가할 때 던져야 할 질문은 “어떤 형식을 사용하는가?”가 아니라, “내 도구가 요구하는 형식을 통해 모델을 손실 없이 왕복(round-trip)할 수 있는가?”입니다. 형식 변환 과정에서 관계 카디널리티(cardinality)나 속성 제약 조건이 소리 없이 누락된다면, 이는 조기에 테스트해야 할 실제적인 통합 리스크입니다.

채택할 형식을 결정하는 방법

다음의 빠른 결정 가이드를 참조하십시오:

주요 소비자가… 인 경우	다음과 같은 표현을 선호하십시오…	주의 사항…
애플리케이션/API 개발자	JSON 스타일 스키마	플랫 JSON에서의 관계 시맨틱 손실
데이터 웨어하우스 / ETL 팀	관계형 또는 테이블 형식 매핑	브리지 테이블이 필요한 다대다 관계
지식 그래프 / 시맨틱 팀	RDF/온톨로지 표현	도구 성숙도 및 쿼리 성능
디자인 및 거버넌스 워크숍	개념적/ER 표기법	다이어그램과 기계 판독 가능 모델 간의 괴리(drift)

마지막 행이 가장 흔한 실패 사례입니다. 팀이 버전 관리되는 모델과 더 이상 일치하지 않는 화려한 다이어그램을 유지하는 경우입니다. 다이어그램은 저장소 아티팩트로부터 생성하거나, 최소한 저장소와 일치하도록 조정하십시오.

뉴스 속의 CIM

“CIM in the News” 섹션에서는 공지 사항, 분석가 논평, 커뮤니티 게시글 등 외부 보도를 집계하여 프로젝트 외부에서 CIM이 어떻게 받아들여지고 있는지 확인할 수 있습니다. 이는 다음 두 가지 이유로 유용합니다.

첫째, 제3자 검증을 제공합니다. 공유 모델 채택을 제안할 때 프로젝트 자체의 마케팅을 인용하는 것보다 독립적인 보도 내용을 인용하는 것이 더 설득력이 있습니다. 둘째, 핵심 문서에서 다루지 않을 수 있는 실제 채택 사례와 통합 패턴을 보여줍니다.

뉴스 보도를 비판적으로 읽으십시오. 공지 사항에서는 실제 배포된 프로덕션 사용 사례보다는 의도와 파트너십을 설명하는 경우가 많습니다. “조직 X가 노력에 참여했다”는 것과 “조직 X가 시스템 Y의 프로덕션 환경에서 CIM을 운영한다”는 것을 구별하십시오. 전자는 흔한 일이지만, 후자가 바로 ‘자체 구축(build) 대 채택(adopt)’ 결정에 있어 중요한 증거가 됩니다.

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

CIM GitHub 조직

GitHub 조직은 실질적인 내용이 담겨 있는 곳입니다. 기술적인 독자들에게는 이곳이 가장 중요한 목적지입니다. 다음 내용들을 찾으실 수 있습니다:

모델 정의 — CIM을 구성하는 엔터티, 속성, 관계 및 제약 조건입니다.
툴링 — 모델로부터 아티팩트를 검증, 변환 및 생성하기 위한 스크립트와 유틸리티입니다.
버전 관리 및 이력 — 모델이 어떻게 발전해 왔고 그 이유는 무엇인지 보여주는 커밋 이력입니다.
이슈 및 토론 — 제안, 질문 및 결정 사항에 대한 작업 기록입니다.

몇 가지 실용적인 습관을 들이면 저장소를 훨씬 더 유용하게 활용할 수 있습니다:

기본 브랜치를 추적하는 대신 릴리스 또는 태그에 고정하십시오. 그래야 프로젝트 도중에 매핑이 변경되어 곤란해지는 일을 방지할 수 있습니다.
엔터티를 채택하기 전에 해당 엔터티의 커밋 이력을 읽어보십시오. 1년에 세 번이나 변경된 필드는 불안정한 영역임을 나타냅니다.
각 저장소의 라이선스를 확인하십시오. 오픈 소스 프로젝트는 때때로 툴링과 모델 콘텐츠에 서로 다른 라이선스를 혼용합니다.
모호한 점이 있다면 이슈를 제기하십시오. 관계의 카디널리티(cardinality)가 불분명하다면, 그 모호함은 모든 다운스트림 팀에 영향을 미칠 것입니다. 이를 조기에 제기하면 모두를 위해 모델을 개선할 수 있습니다.

엄격한 공급망 또는 출처 요구 사항이 있는 조직의 경우, 라이선스, 유지 관리 활동, 기여자 다양성 및 릴리스 주기 등 일반적인 제3자 종속성을 검토하는 것과 동일한 방식으로 저장소를 검토하십시오. 단일 유지관리자에게 의존하는 모델은 광범위한 조직의 지원을 받는 모델과는 위험 프로필이 다릅니다.

쇼핑하는 경우: — 하이브리드 클라우드-온-프레미스 통합을 위한 Enterprise iPaaS.

자주 묻는 질문

Cloud Information Model은 구매할 수 있는 제품인가요?

아니요. CIM은 Linux Foundation에서 관리하는 오픈 소스 데이터 모델(정의 및 지원 아티팩트 세트)입니다. 시스템을 CIM에 매핑하고 게시된 모델 정의를 사용함으로써 이를 채택하게 되며, 모델 자체에 대한 라이선스 비용은 없습니다. 벤더가 CIM을 지원하거나 내장한 제품을 만들 수는 있지만, 모델 자체가 상업적 상품은 아닙니다.

CIM을 사용하려면 기존 시스템을 교체해야 합니까?

아니요, 바로 그 점이 핵심입니다. CIM은 시스템 사이에서 표준 교환 모델(canonical interchange model) 역할을 하도록 설계되었습니다. 기존의 애플리케이션, 데이터베이스, 웨어하우스를 그대로 유지하면서 각 시스템에서 CIM으로의 매핑을 구축하면 됩니다. 이는 점진적으로 가능합니다. 단일한 고가치 통합부터 시작하여 시간이 지남에 따라 적용 범위를 확장할 수 있습니다.

CIM을 사용할 때 어떤 형식을 사용해야 하나요?

사용 주체에 따라 다릅니다. API 및 애플리케이션 팀은 일반적으로 JSON 스타일의 스키마 표현을 선호하고, 웨어하우스 및 ETL 팀은 관계형 또는 테이블 형식의 매핑을 선호하며, 시맨틱 및 지식 그래프 팀은 RDF/온톨로지 표현을 선호합니다. 핵심 테스트는 ‘무손실 왕복(lossless round-tripping)‘입니다. 최종 확정 전, 형식 간 변환 시 관계와 제약 조건이 그대로 유지되는지 확인하십시오.

CIM은 UBL이나 OAGIS 같은 다른 표준과 어떤 관계가 있나요?

이들은 인접한 문제 영역을 다룹니다. UBL과 OAGIS는 당사자 간에 교환되는 비즈니스 문서와 메시지에 집중하는 반면, CIM은 애플리케이션이 매핑되는 공유 엔터티 모델을 강조합니다. 실제로 이들은 상호 보완적일 수 있습니다. 표준 엔터티 모델은 문서 표준을 어떻게 채울지에 대한 근거가 될 수 있습니다. 하나가 다른 하나를 대체한다고 가정하기보다, 구체적인 사용 사례에 따라 중복되는 부분을 평가하십시오.

CIM에 어떻게 기여할 수 있나요?

기여는 주로 CIM GitHub 조직(이슈, 풀 리퀘스트, 토론)과 이 사이트에 링크된 기여자 웹 양식을 통해 이루어집니다. 모델은 커뮤니티에 의해 거버넌스되므로 제안 사항은 공개적으로 검토됩니다. 작게 시작하십시오. 모호한 정의를 명확히 하거나 명확한 근거와 함께 누락된 속성을 추가하는 것부터 시작하고, 대규모 구조 변경을 제안하기 전에 유지관리자와 협의하십시오.

기술 지식이 없는 이해관계자는 어디서부터 시작해야 합니까?

CIM 프레젠테이션과 FAQ로 시작한 다음, “뉴스 속의 CIM”을 훑어보며 제3자 관점의 맥락을 파악하십시오. 이를 통해 모델 정의를 직접 읽지 않고도 동기 부여와 기본 어휘를 익힐 수 있습니다. 파일럿으로 시도할 통합 후보가 정해지면 기술 팀을 참여시켜 GitHub 저장소에서 작업하도록 하십시오.

참여 및 추가 읽기

공유 모델의 채택은 기술적인 노력만큼이나 조직적인 노력이 필요합니다. 가장 성공적인 CIM 이니셔티브는 대개 현재 두 시스템 사이에 취약한 커스텀 매핑이 필요한, 경계가 명확한 단일 통합 사례에서 시작하여 표준 모델 접근 방식을 입증한 후 확장하는 경향이 있습니다. 거버넌스가 중요합니다. 내부 CIM 매핑의 소유권은 누구에게 있는지, 모델 버전 업그레이드는 어떻게 처리하는지, 비즈니스 정의 간의 충돌은 어떻게 해결할지를 조기에 결정하십시오.

관리 및 개방형 거버넌스 맥락에 대한 배경 정보는 Wikipedia의 Linux Foundation을 참조하십시오. 관련 표준 작업의 경우, OASIS Universal Business Language와 schema.org가 표준 모델 접근 방식을 비교할 때 유용한 참조 지점이 됩니다. 시맨틱 모델링에 대해 더 자세히 알아보려면, 온톨로지 스타일 표현의 기반이 되는 RDF 및 OWL 사양을 게시하는 World Wide Web Consortium (W3C)를 확인하십시오.

이 사이트의 내비게이션을 통해 프레젠테이션, FAQ, 형식 문서, 뉴스 요약 및 GitHub 저장소에 접속할 수 있으며, 모델 형성에 참여할 준비가 되었다면 기여자 웹 양식을 사용하십시오.

Boomi가 하이브리드 통합 맵을 처리하는 방법을 알아보세요.

하이브리드 클라우드-온-프레미스 통합을 위한 Enterprise iPaaS