INDECS, 저작물 권리 정산이 어긋나는 진짜 원인은 메타데이터 모델이다

같은 앨범이 유통사 시스템에는 ISRC로, 저작권 단체 시스템에는 다른 내부 코드로, 스트리밍 플랫폼에는 또 다른 이름으로 등록되어 있다면 정산은 어긋날 수밖에 없다. INDECS(Interoperability of Data in E-Commerce Systems)는 1998~2000년 유럽 프로젝트에서 출발해, 음악·출판·영상 같은 저작물 전주기에서 식별·관계·이벤트를 일관되게 기술하는 프레임워크를 제시했다. DOI, DDEX, ONIX, ISNI/ORCID, MPEG-21 등 다수 표준이 이 개념적 토대 위에 서 있다. 최신 공식 명세와 조직 현황은 표준 문서 판본에 따라 다를 수 있어 최신 정보 확인이 필요하다.

무엇을 상호운용시키려는 표준인가

INDECS는 디지털 상거래에서 메타데이터의 의미적 상호운용성을 확보하기 위한 개념 프레임워크다. 엔터티(사물·작품·사람·장소·시간), 역할, 관계, 이벤트를 일관된 어휘와 모델로 표현하는 것이 핵심이다. 이를 뒷받침하는 원칙은 여섯 가지다. 고유식별(identification), 기능적 세분성(functional granularity), 관계 링크(linkage), 지속성(persistence), 출처(provenance), 권위(authority). 목적은 이질 시스템 간 매핑 가능성을 극대화하고, 권리·정산 이벤트를 기계가 읽을 수 있게 만들며, 충돌을 해결하고 감사 가능한 신뢰 체계를 확보하는 데 있다.

엔터티-역할-관계-이벤트 모델

INDECS의 뼈대는 E-R-R-E(엔터티-역할-관계-이벤트) 모델이다. 엔터티는 Party(사람·조직), Resource(작품·표현·매니페스트·파일), Place/Time으로 나뉜다. 역할과 관계는 "누가(Party)가 무엇(Resource)에게 어떤 역할로 어떤 관계를 맺는가"를 명시적으로 기술하며, 이벤트는 권리 부여·이전·이용 기록을 원자적 단위로 표현한다.

식별자 전략: 기능적 세분성과 지속 식별자

식별 단위는 의도적으로 분해해 설계한다. 작품→표현→구현→파일 순으로 계층을 나누고, 각 계층에 DOI/ISNI/ISRC/ISBN 같은 지속 식별자(PID)를 부여한 뒤 버전·파생 관계를 명시하면 서로 다른 시스템이 같은 작품을 다른 코드로 등록해 생기는 충돌을 최소화할 수 있다.

네임스페이스와 매핑 관리

컨트롤드 보캐뷸러리를 두고 ONIX, DDEX, Dublin Core 같은 타 표준과의 매핑 룰을 정의한다. 네임스페이스 충돌을 막기 위해 접두사를 관리하고, owl:sameAs 같은 의미 동등성 선언으로 서로 다른 식별자가 같은 대상을 가리킨다는 사실을 명시한다.

신뢰·프로비넌스·거버넌스

주장(assertion)의 주체·근거·시점을 기록하고 변경 이력을 불변 저장하는 것이 프로비넌스의 핵심이다. 권위 소스의 우선순위, 품질 규칙, 검증·승인 워크플로우를 운영해야 실제로 신뢰할 수 있는 메타데이터 허브가 된다.

도입 절차와 처리 흐름

원천 시스템(음원 메타, 계약, 카탈로그, 파일 시스템)에서 메타데이터를 수집한 뒤 정규화→PID 부여→역할/관계 해석→이벤트 기록→검증/중복해결을 거쳐, 검색/조회 API·권리 판단·정산 레포트·외부 표준 포맷(DDEX, ONIX) 발행으로 출력한다.

⤢✕

일관성은 이벤트 소싱으로 확보한다. 모든 변경을 이벤트로 append-only 저장하고 스냅샷으로 조회 성능을 보완한다. 중복·재시도는 멱등키(idempotency key), 동일성 규칙(정규화명+PID), 낙관적 잠금(버전 필드)으로 제어한다. 스키마가 어긋나면 격리 큐로 옮겨 수동 큐레이션 후 재처리하고, PID가 충돌하면 권위 점수·타임스탬프 기반의 승자 선정 규칙을 적용한다. 이런 구조를 갖추면 메타데이터 중복률을 30~60% 줄이고 동일성 해석 자동화율을 70% 이상까지 끌어올릴 수 있다.

실무에서 쓰이는 곳

음악 라이선싱·정산에서는 트랙(ISRC)–작품(ISWC)–참여자(ISNI/IPA) 관계의 정합성을 확보하고, DDEX ERN/MEAD 발행을 자동화해 사용 로그와 권리 윈도우 이벤트를 매칭한다. 이 구조를 적용하면 권리 클리어런스 리드타임을 30~50% 단축하고 정산 불일치 건수를 40% 이상 줄일 수 있다. 출판 메타데이터 허브에서는 ONIX를 인제스트한 뒤 DOI를 부여하고 저자 ORCID/ISNI를 링크해 판·번역·포맷 파생 관계를 관리하며, 서점·도서관·플랫폼 간 상호운용성이 개선된다. OTT·방송 콘텐츠 패키징에서는 타이틀–시즌–에피소드–컷·패키지 계층 모델과 지역·기간별 권리 이벤트를 관리해 어셋 재사용률을 높이고 릴리스 오류를 줄인다. 문화유산·아카이브 영역에서는 원본/복제/디지털화 이벤트 체인과 출처 기록을 남겨 장기 보존 정책과 연계하고 검색·연계 연구의 신뢰도를 높인다.

애드혹 스키마와 비교하면

항목	INDECS 지향 설계	애드혹/부서별 스키마
확장성	상: 엔터티/이벤트 분해로 수평 확장 용이	중: 필드 추가 시 파편화 증가
일관성	상: PID·프로비넌스·규칙 엔진	하: 중복·충돌 상시 발생
안정성	상: 이벤트 소싱·감사 추적	중: 로그 중심, 사후 추적 곤란
운영 편의	중상: 표준 매핑 자동화, 큐레이션 워크플로우	중하: 케이스별 수작업 증가
성능	중상: 스냅샷/캐시 병행	중: 조인 확산·배치 의존

성능은 설계·인덱싱·캐시 전략에 따라 달라질 수 있다. 외부 표준(DDEX/ONIX) 발행 실패율은 INDECS 지향 설계에서 80% 이상 줄어드는 것으로 보고된다.

구현 가이드

모델링은 최소 커널 스키마로 시작한다. Party, Resource(Work/Expression/Manifestation/File), Role, Relationship, Event를 두고, 기능적 세분성 수준과 파생 규칙을 먼저 합의한다. 식별자 전략은 외부 PID(ISBN/ISRC/DOI/ISNI)를 우선하고 내부 식별자로 보완하며, sameAs·exactMatch 같은 네임스페이스·동등성 맵을 유지한다. 레지스트리와 API는 이벤트 소싱 저장소와 읽기 최적화 인덱스(Read Model)를 병행하고, 멱등 POST와 버전 필드 기반 낙관적 잠금, 시점·버전 기준 증분 필터링을 지원해야 한다. 매핑·검증 단계에서는 ONIX↔내부, DDEX↔내부 표준 매핑 룰과 테스트 셋을 운영하고, 스키마 진화 전략으로 필드 추가는 후방 호환을, 의미 변경은 버전 업을 원칙으로 삼는다.

JSON-LD로 표현한 INDECS 개념 매핑

Node.js·파이썬 등 환경과 무관하게 JSON-LD 파서만 있으면 아래 예시를 그대로 처리할 수 있다.

{
  "@context": {
    "schema": "http://schema.org/",
    "id": "@id",
    "type": "@type",
    "role": "schema/roleName",
    "sameAs": "schema/sameAs",
    "eventTime": "schema/startDate",
    "agent": "schema/agent",
    "object": "schema/object"
  },
  "id": "doi:10.1234/album.5678",
  "type": "schema/MusicAlbum",
  "name": "Example Album",
  "sameAs": ["isrc:US-Z03-99-12345"],
  "contributor": [
    {
      "type": "schema/Role",
      "role": "Producer",
      "agent": {
        "id": "isni:0000000121032683",
        "type": "schema/Person",
        "name": "A. Producer"
      }
    }
  ],
  "isPartOf": { "id": "doi:10.1234/work.111", "type": "schema/CreativeWork" },
  "event": [
    {
      "type": "schema/Event",
      "name": "LicenseGranted",
      "eventTime": "2025-01-01T00:00:00Z",
      "agent": { "id": "party:label-xyz", "type": "schema/Organization" },
      "object": { "id": "territory:US-CA", "type": "schema/Place" }
    }
  ]
}

"무엇을, 누가, 언제, 어디서, 어떤 역할로, 어떤 관계·이벤트로" 기술했는지가 명확해지면 권리 판단과 정산의 정확도·속도가 함께 오른다. 데이터가 복잡하게 얽히는 음악·출판·OTT 도메인일수록 이 모델을 먼저 도입할 이유가 크다.