CIM 형식

(CIM)은 처음부터 고객, 주문, 제품, 계정 및 이들 간의 관계와 같은 비즈니스 개념에 대한 표준 기반의 애플리케이션 독립적(application-agnostic) 모델로 설계되었습니다. 하지만 개념적 모델은 이를 필요로 하는 시스템이 실제로 소비할 수 있을 때만 유용합니다. 그렇기 때문에 CIM은 단일 독점 아티팩트가 아니라, 각각 서로 다른 클래스의 도구, 런타임 및 대상을 타겟팅하는 직렬화(serializations) 제품군으로 게시됩니다.

이 페이지에서는 각 CIM 형식이 무엇인지, 용도가 무엇인지, 그리고 그 중에서 어떻게 선택하는지 설명합니다. 엔터프라이즈 데이터 아키텍트, 통합 또는 ETL 엔지니어, 애플리케이션 또는 플랫폼 벤더, 혹은 오픈 소스 기여자라면, 가장 먼저 선택하게 될 형식은 파이프라인의 어느 위치에 있느냐에 따라 달라집니다.

주요 내용

• CIM은 시맨틱 웹 형식(JSON-LD, RDF Schema, SHACL, R2RML)과 사람이 읽을 수 있는/관계형 형식(AML vocabulary, AML dialect, RAML types, JSON Schema, SQL DDL)의 두 가지 제품군으로 배포됩니다.
• 개념 모델(concepts.*)은 엔티티와 관계를 설명하며, 표준 스키마(schema.*)는 데이터 형태와 제약 조건을 설명합니다. 이들은 서로 다른 목적을 가진 별개의 아티팩트입니다.
• JSON-LD는 기계가 읽을 수 있는 표준 형식이며, AML은 동일한 콘텐츠의 사람이 읽을 수 있는 형식입니다. SQL DDL 및 JSON Schema는 대부분의 애플리케이션 및 ETL 팀이 직접 소비하는 형식입니다.
• R2RML은 브리지 역할을 합니다. 관계형 스키마를 RDF 그래프로 매핑하며, 이를 통해 기존 SQL 데이터베이스를 시맨틱 계층에 연결할 수 있습니다.
• 형식 선택은 선호도가 아닌 소비자의 문제입니다. 대상 툴체인이 기본적으로 수용하는 형식을 선택하고, 나머지는 교차 확인용으로 사용하십시오.

CIM이 여러 형식으로 출시되는 이유

대부분의 데이터 모델은 보통 ER 다이어그램, 스프레드시트 또는 벤더 전용 메타데이터 파일 등 정확히 한 가지 형태로 게시됩니다. 이는 서로 다른 스택을 사용하는 조직 간에 모델을 공유해야 할 때까지는 문제가 없습니다. 리테일 플랫폼은 PostgreSQL과 dbt를 사용할 수 있고, 파트너는 그래프 데이터베이스와 트리플 스토어를 사용할 수 있으며, SaaS 벤더는 JSON API를 노출하고 JSON Schema로 페이로드를 검증할 수 있습니다. 만약 공유 모델이 이러한 방언 중 하나로만 존재한다면, 다른 모든 사용자가 이를 번역해야 하며, 이 과정에서 번역의 괴리(drift)가 발생합니다.

CIM의 다중 형식 전략은 이 문제에 대한 의도적인 해답입니다. 모델은 한 번 작성된 후 인정된 표준에 깔끔하게 매핑되는 형식으로 변환되므로, 각 소비자는 이미 보유한 도구를 사용하여 CIM을 채택할 수 있습니다. 이는 CIM이 재창조하는 대신 재사용하는 RDF, SHACL, R2RML과 같은 사양을 게시하는 World Wide Web Consortium (W3C)와 같은 표준 기구의 철학과 동일합니다. 또한 이는 CIM 프로젝트가 운영되는 Linux Foundation의 광범위한 상호 운용성 미션과도 일치합니다.

실질적인 이점은 두 가지입니다. 다양한 기술을 보유한 기업은 기존 시스템을 완전히 교체(rip-and-replace)하지 않고도 CIM을 채택할 수 있으며, 기여자는 다른 직렬화 파일들을 재생성할 수 있다는 점을 알고 자신의 전문 지식에 맞는 형식으로 모델을 확장할 수 있습니다.

개념적 모델 vs. 표준 스키마

파일 형식을 비교하기 전에, CIM이 별개로 유지하고 있으며 신규 사용자가 자주 혼동하는 두 레이어를 구분하는 것이 도움이 됩니다.

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

• 개념적 모델은 무엇이 존재하고 어떻게 관련되는가에 답합니다. 엔티티(Customer, Order, Product), 해당 속성 및 이들 간의 관계를 정의합니다. 의도적으로 비즈니스 어휘에 가깝게 설계되었으며 물리적 세부 사항은 의도적으로 배제했습니다.
• 표준 스키마는 유효한 인스턴스가 어떤 모습인가에 답합니다. 시스템이 검증할 수 있는 데이터 형태와 제약 조건(카디널리티, 유형, 필수 필드, 값 범위)을 추가합니다.

CIM 배포판에서 이들은 두 개의 파일 이름 어간으로 매핑됩니다. 개념 계층은 concepts.*, 표준 계층은 schema.*입니다. 이를 분리함으로써 비즈니스 분석가는 제약 조건 구문을 훑지 않고도 개념 모델을 읽을 수 있고, 엔지니어는 전체 개념적 서술 없이도 스키마를 통해 페이로드를 검증할 수 있습니다.

시맨틱 웹 형식

이 형식들은 CIM을 RDF 기반 그래프로 표현합니다. 소비자에 트리플 스토어, 지식 그래프, 온톨로지 도구 또는 연결된 데이터(linked data)를 추론하는 시스템이 포함된 경우 적절한 선택입니다.

JSON-LD — concepts.json 및 schema.json

JSON-LD는 연결된 데이터 컨텍스트가 포함된 JSON으로, 일반 웹 API와 시맨틱 웹 사이의 실용적인 다리 역할을 합니다. CIM은 두 개의 JSON-LD 아티팩트를 게시합니다.

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

• concepts.json — RDF Schema로 표현된 엔티티 및 관계의 개념적 설명입니다.
• schema.json — SHACL로 표현된 표준 데이터 형태 및 추가 제약 조건입니다.

유효한 JSON이기 때문에 concepts.json 및 schema.json은 일반 JSON 도구로 로드할 수 있지만, @context를 포함하고 있어 전체 RDF 트리플로 확장될 수도 있습니다. 이러한 이중적 특성 덕분에 JSON-LD는 첫날부터 전문적인 RDF 스택을 도입하지 않고도 시맨틱 충실도를 원하는 팀에게 가장 적합한 기본값이 되는 경우가 많습니다.

RDF Schema — schema.json

RDF Schema(RDFS)는 클래스와 속성을 설명하기 위한 어휘를 제공합니다. 즉, rdfs:Class, rdfs:subClassOf, rdfs:domain/rdfs:range 구성을 통해 기계가 Order가 비즈니스 문서(business document)이며, 그 customer 속성이 Customer를 가리킨다는 점을 이해할 수 있게 합니다. CIM은 RDFS를 사용하여 개념 모델에 공식적인 의미론(semantics)을 부여함으로써, 하위 클래스 계층 구조와 속성 도메인이 단순히 문서화되는 것에 그치지 않고 기계가 해석 가능하도록 합니다.

SHACL — schema.json

Shapes Constraint Language (SHACL)은 ‘셰이프(shapes)‘라고 불리는 일련의 조건에 대해 RDF 그래프를 검증하기 위한 W3C 표준입니다. RDFS가 클래스가 무엇인지를 정의한다면, SHACL은 유효한 인스턴스가 만족해야 하는 조건(필수 속성, 허용되는 값 유형, 카디널리티 제한)을 정의합니다. CIM의 표준 데이터 셰이프는 SHACL로 표현되며, 이는 모든 SHACL 프로세서가 별도의 사용자 정의 코드 없이 CIM 준수 데이터의 유효성을 검사할 수 있음을 의미합니다.

R2RML — schema.rdml

R2RML은 관계형 데이터베이스 스키마를 RDF 그래프로 매핑하기 위한 W3C 표준입니다. 이는 통합 및 ETL 엔지니어에게 가장 중요한 형식인데, 테이블, 열, 외래 키를 가진 기존 SQL 데이터베이스를 CIM 준수 연결 데이터(linked data)로 노출하는 메커니즘이기 때문입니다. 운영 데이터베이스를 수작업으로 다시 모델링하는 대신, 각 테이블과 열이 CIM 엔터티 및 속성에 어떻게 대응하는지 선언하는 R2RML 매핑을 작성(또는 생성)합니다. 그 결과로 기존 관계형 데이터 위에 가상 RDF 그래프가 생성됩니다.

사람이 읽을 수 있는 형식 및 관계형 형식

모든 소비자가 RDF를 원하는 것은 아닙니다. 애플리케이션 개발자, 데이터 모델러 및 DBA는 텍스트 편집기에서 읽을 수 있거나 데이터베이스에 직접 로드할 수 있는 형식을 원하는 경우가 많습니다. CIM은 이를 위해 AML, RAML, JSON Schema 및 SQL DDL 직렬화를 제공합니다.

AML — concepts.yaml, schema.yaml, schema.raml

여기서 모델링 방언으로 사용된 AnyLogic Modeling Language 계보인 AML은 CIM의 사람이 읽을 수 있는 표현 방식입니다. CIM은 세 가지 AML 아티팩트를 게시합니다.

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

• concepts.yaml — 개념 모델의 사람이 읽을 수 있는 버전인 AML **어휘(vocabulary)**입니다.
• schema.yaml — 표준 데이터 셰이프의 사람이 읽을 수 있는 버전인 AML **방언(dialect)**입니다.
• schema.raml — 표준 셰이프를 RAML 데이터 유형으로 렌더링한 것입니다.

어휘와 방언의 차이를 이해하는 것이 중요합니다. 어휘는 용어(모델의 명사와 동사)를 정의하는 반면, 방언은 해당 용어들이 어떻게 결합되어 유효한 구조를 이루는지를 정의합니다. CIM을 처음 검토하신다면, 일반적으로 concepts.yaml이 가장 접근하기 쉬운 진입점입니다.

JSON Schema — schema.json

JSON Schema는 JSON 문서 검증을 위한 사실상의 표준으로, 거의 모든 현대 언어에서 기본적으로 또는 라이브러리를 통해 지원됩니다. CIM의 JSON Schema 아티팩트는 표준 데이터 셰이프를 JSON Schema로 표현하므로, 이미 JSON 페이로드를 검증하고 있는 API 게이트웨이, 메시지 브로커 및 CI 파이프라인에서 직접 사용할 수 있습니다. 통합 접점이 REST 또는 이벤트 기반 JSON인 경우, 대개 이 형식이 가장 적합합니다.

SQL DDL — schema.sql

SQL DDL은 관계형 데이터베이스에서 표준 셰이프를 구체화하는 CREATE TABLE, CREATE VIEW 및 제약 조건문의 집합입니다. CIM은 주요 관계형 엔진 간에 DDL 이식성을 유지하기 위해 SQL 2008 구문을 대상으로 합니다. 이는 DBA와 ETL 엔지니어가 CIM을 준수하는 물리적 스키마(예: 표준 모델을 미러링하는 스테이징 또는 통합 데이터베이스)를 구축하려 할 때 사용하는 형식입니다.

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

형식 선택: 실용 가이드

단 하나의 “정답” 형식은 없습니다. 적절한 선택은 모델을 다음에 소비하는 주체가 누구인지, 혹은 무엇인지에 따라 결정됩니다. 아래 표를 의사결정 보조 자료로 활용하십시오.

소비자가…	다음으로 시작하세요…	이유…
모델을 검토하는 비즈니스 분석가 또는 데이터 모델러	AML 어휘 (concepts.yaml)	사람이 읽을 수 있으며, 비즈니스 어휘 중심임
트리플 스토어, 지식 그래프 또는 온톨로지 도구	JSON-LD (concepts.json, schema.json)	JSON 온램프를 갖춘 네이티브 RDF
SHACL 검증기 또는 시맨틱 데이터 품질 파이프라인	SHACL (schema.json)	RDF에 대한 표준 제약 조건 검증
연결 데이터로 노출하려는 기존 관계형 데이터베이스	R2RML (schema.rdml)	리모델링 없이 테이블/열을 CIM 엔터티에 매핑
REST 또는 이벤트 기반 JSON API	JSON Schema (schema.json)	JSON 페이로드를 직접 검증
CIM을 준수하려는 관계형 데이터베이스	SQL DDL (schema.sql)	이식 가능한 SQL 2008 DDL
RAML로 기술된 API	RAML 유형 (schema.raml)	RAML 툴체인에 네이티브함

몇 가지 실무적인 주의 사항:

• 각 형식을 독립적인 모델로 취급하지 마십시오. 이들은 모두 동일한 기본 CIM의 직렬화 결과물입니다. 예를 들어 schema.json (JSON Schema)과 schema.json (SHACL) 사이에 불일치가 발견된다면, 이는 설계상의 선택이 아니라 버그 또는 버전 불일치이므로 보고해 주시기 바랍니다.
• 파일명 충돌에 주의하십시오. 여러 형식이 서로 다른 확장자(schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml)를 가지면서 schema라는 동일한 파일 이름을 공유합니다. 전체 배포판을 다운로드할 때, 한 직렬화 파일이 다른 파일에 의해 덮어씌워지지 않도록 형식별 디렉토리를 분리하여 유지하십시오.
• 검증 단계에 맞는 형식을 사용하십시오. 설계 단계의 검토에는 개념적(conceptual) 형식을 사용하고, 런타임 검증에는 표준(canonical) 형식을 사용하십시오. 개념적 모델을 대상으로 유효성을 검사하는 것은 제약 조건이 부족하므로 의미가 없습니다.
• 수작업 편집보다 자동 생성을 선호하십시오. CIM을 확장하는 경우, 각 형식을 일일이 수작업으로 편집하기보다 소스를 확장한 후 다른 직렬화 파일들을 다시 생성하십시오. 그렇지 않으면 각 형식 간의 동기화가 깨질 수 있습니다.

전체 CIM 배포판 다운로드

CIM은 사용 가능한 각 형식의 완전한 정의로 배포되므로, 조각조각 모을 필요 없이 필요한 직렬화 방식으로 전체 모델을 한 번에 내려받을 수 있습니다. 게시된 다운로드 옵션은 다음과 같습니다.

• AML (vocabulary) — 사람이 읽을 수 있는 개념 모델입니다.
• AML (dialect) — 사람이 읽을 수 있는 표준 셰이프(canonical shapes)입니다.
• JSON-LD (vocabulary & schema) — 기계가 읽을 수 있는 시맨틱 모델입니다.
• R2RML — 관계형-RDF 매핑입니다.
• RAML Types — RAML 데이터 유형으로 표현된 표준 셰이프입니다.
• SQL DDL — 이식 가능한 SQL로 표현된 표준 셰이프입니다.

각 다운로드에는 해당 형식의 전체 CIM 정의가 포함되어 있습니다. 즉, CIM을 점진적으로 채택할 수 있습니다. 현재 도구 체인이 지원하는 형식으로 시작하고, 상호 운용성 요구 사항이 증가함에 따라 다른 형식을 추가하십시오.

다양한 형식에 기여

CIM은 오픈 프로젝트이므로 기여를 환영하며, 멀티 포맷 구조가 기여 방식의 틀을 형성합니다. 기여자는 일반적으로 다음 두 그룹으로 나뉩니다.

• 모델 기여자는 새로운 엔터티, 관계 또는 제약 조건을 제안합니다. 이러한 변경 사항은 한 번 작성된 후 다른 직렬화 형식으로 전파됩니다.
• 형식 기여자는 특정 직렬화의 충실도나 도구를 개선합니다. 예를 들어, R2RML 매핑이나 SQL DDL의 이식성을 개선하는 작업이 이에 해당합니다.

기여 시 실질적인 규칙은 자신이 변경하려는 레이어(개념적 vs 표준)가 무엇인지, 그리고 그 결과로 어떤 형식을 다시 생성해야 하는지를 이해하는 것입니다. 프로젝트의 GitHub 저장소와 기여자 웹 양식이 참여를 위한 진입점입니다.

자주 묻는 질문

CIM에서 concepts.json과 schema.json의 차이점은 무엇인가요?

concepts.json은 개념적 모델로, CIM의 엔터티와 관계를 RDF 스키마 시맨틱을 가진 JSON-LD로 표현한 것입니다. schema.json은 표준 스키마로, 데이터 셰이프와 추가 제약 조건을 SHACL 시맨틱을 가진 JSON-LD로 표현한 것입니다. 간단히 말해, concepts는 무엇이 존재하는지를 설명하고, schema는 유효한 인스턴스가 어떤 모습이어야 하는지를 설명합니다.

CIM이 동일한 모델을 왜 이렇게 많은 형식으로 게시하나요?

사용자마다 사용하는 기술이 다르기 때문입니다. 트리플 스토어에는 RDF가 필요하고, JSON API에는 JSON 스키마가 필요하며, DBA에게는 SQL DDL이, 비즈니스 분석가에게는 사람이 읽을 수 있는 형식이 필요합니다. CIM을 여러 표준 형식으로 게시함으로써, 모든 사용자에게 단일 스택을 강요하는 대신 각 사용자가 이미 보유한 도구로 모델을 채택할 수 있게 합니다.

CIM에서 R2RML은 어떤 용도로 사용되나요?

R2RML은 관계형 데이터베이스 스키마를 RDF 그래프로 매핑하기 위한 W3C 표준입니다. CIM에서 R2RML은 기존 SQL 데이터베이스를 CIM 준수 연결 데이터(linked data)로 노출하는 브리지 역할을 하여, 운영 관계형 시스템을 수동으로 다시 모델링하지 않고도 시맨틱 레이어에 연결할 수 있게 합니다.

AML은 JSON-LD 형식과 동일한가요?

아니요. AML은 CIM의 사람이 읽을 수 있는 표현으로, 어휘(concepts.yaml)와 방언(schema.yaml, schema.raml)을 의미합니다. JSON-LD는 기계가 읽을 수 있는 RDF 기반 표현입니다. 두 가지 모두 동일한 모델을 설명하지만, 대상 독자와 도구 체인이 다릅니다.

어떤 CIM 형식부터 시작해야 하나요?

사용 목적에 따라 다릅니다. 모델을 검토하는 중이라면 AML 어휘부터 시작하십시오. JSON API를 구축하는 중이라면 JSON 스키마로 시작하십시오. 관계형 데이터베이스를 연결하는 중이라면 R2RML 또는 SQL DDL로 시작하십시오. 지식 그래프를 다루는 중이라면 JSON-LD 및 SHACL로 시작하십시오.

다른 CIM 형식을 업데이트하지 않고 하나의 형식만 편집할 수 있나요?

가능은 하지만 권장하지 않습니다. 각 형식은 하나의 기본 모델을 직렬화한 것이므로, 단일 형식을 수동으로 편집하면 전체 형식 간의 동기화가 깨지게 됩니다. 대신 소스 모델을 확장하고 다른 직렬화 형식들을 다시 생성하십시오.

추가 자료

• World Wide Web Consortium (W3C) — CIM이 기반으로 하는 사양인 RDF, RDF 스키마, SHACL 및 R2RML의 표준 기구입니다.
• Shapes Constraint Language (SHACL) — CIM의 표준 데이터 셰이프에 사용되는 제약 언어에 대한 배경 정보입니다.
• Linux Foundation — CIM 프로젝트가 운영되는 재단입니다.