5.4 메타데이터 모델 - 소재, 파일, 구간을 어떻게 저장할까

#메타데이터의 네 종류

MAM이 다루는 메타데이터는 성격에 따라 네 가지로 나눌 수 있습니다.

이렇게 나누는 이유는 입력 책임이 다르기 때문입니다. 기술 메타데이터는 사람이 입력하면 안 되고(오류 발생), 서술 메타데이터는 자동화가 어렵습니다. 사용자의 입력 부담을 줄이려면 입력할 수 있는 것은 최대한 자동화하고, 사람이 입력할 것은 꼭 필요한 항목만 요구해야 합니다.

#계층 모델: 소재 - 파일 - 구간

가장 흔한 실수는 "영상 파일 하나 = 레코드 하나"로 모델링하는 것입니다. 실제 업무에서는 같은 영상에 여러 파일(원본, 프록시, 썸네일) 이 있고, 한 영상 안에 여러 구간(장면, 인터뷰) 이 있습니다.

소재(Asset)                        ← 사용자가 "영상 하나"로 인식하는 단위. 서술 메타데이터가 붙음
 ├─ 파일(Media File) × N           ← 원본(hires), 프록시, 썸네일... 기술 메타데이터가 붙음
 └─ 구간(Segment) × N              ← 타임코드 in/out. 구간별 서술 메타데이터(라벨, 키워드)

• 소재(Asset) 는 논리적 단위입니다. 사용자는 "어제 저녁 9시 뉴스 영상"을 찾지, a1.mxf를 찾지 않습니다.
• 파일은 소재의 물리적 표현입니다. 원본이 아카이브(테이프)로 이동해도 소재 레코드와 프록시는 남아 있어야 검색이 됩니다.
• 구간은 시작/끝 타임코드로 정의하며, 서브클립이나 마커의 기반입니다.

#관계형 스키마 예제

아래는 위 구조를 SQL로 옮긴 최소 스키마입니다. SQLite 3.51로 실제 실행해서 제약 조건과 조회를 확인했습니다.

CREATE TABLE asset (
  id         INTEGER PRIMARY KEY,
  title      TEXT NOT NULL,
  kind       TEXT,                       -- news, drama, ...
  created_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE media_file (
  id          INTEGER PRIMARY KEY,
  asset_id    INTEGER NOT NULL REFERENCES asset(id),
  role        TEXT NOT NULL CHECK (role IN ('hires','proxy','thumb')),
  path        TEXT NOT NULL,
  container   TEXT, codec TEXT,
  fps         TEXT,                      -- '30000/1001' 분수 문자열
  start_tc    TEXT,                      -- '01:00:00;00'
  duration_ms INTEGER, size_bytes INTEGER,
  sha256      TEXT
);

CREATE TABLE segment (
  id       INTEGER PRIMARY KEY,
  asset_id INTEGER NOT NULL REFERENCES asset(id),
  tc_in    TEXT NOT NULL, tc_out TEXT NOT NULL,
  label    TEXT,
  source   TEXT DEFAULT 'manual'         -- manual / auto(AI)
);

CREATE TABLE metadata (
  asset_id INTEGER NOT NULL REFERENCES asset(id),
  field    TEXT NOT NULL,                -- location, person, keyword ...
  value    TEXT,
  PRIMARY KEY (asset_id, field, value)
);

설계 포인트는 다음과 같습니다.

• role에 CHECK 제약을 걸어 허용되지 않는 값(예: 'bad')을 넣으면 DB가 거부합니다. 실행 결과 CHECK constraint failed: role IN ('hires','proxy','thumb')로 차단되는 것을 확인했습니다.
• 외래키는 연결(connection)마다 켜야 합니다. SQLite는 REFERENCES를 적어도 기본값에서는 검사하지 않습니다. 존재하지 않는 asset_id = 999로 media_file을 넣으면 PRAGMA foreign_keys = ON이 없을 때는 그대로 삽입되어 고아 행이 생겼고, 켠 뒤에는 FOREIGN KEY constraint failed로 거부되었습니다. DB에 접속하는 모든 코드에서 연결 직후 PRAGMA foreign_keys = ON을 실행하세요.
• 프레임레이트는 분수 문자열로 저장합니다(3장 정규화 원칙).
• 시작 타임코드를 파일에 저장합니다. 구간(tc_in, tc_out)은 타임코드로 표현하고, 시간 계산 시 파일의 프레임레이트와 시작 타임코드를 사용합니다.
• metadata 테이블은 키-값 구조로 같은 필드에 여러 값(출연자 여러 명)을 허용합니다(기본 키가 asset_id, field, value).
• 구간의 source로 사람이 입력한 것과 AI가 자동 생성한 것을 구분합니다. AI 결과는 틀릴 수 있으므로 신뢰도 표시와 검수 흐름이 필요합니다.

프록시 경로를 조회하는 쿼리는 다음과 같습니다.

SELECT a.title, f.role, f.path
FROM asset a JOIN media_file f ON f.asset_id = a.id
WHERE f.role = 'proxy';

#키-값 vs 고정 컬럼

위 스키마의 metadata 테이블은 유연성을 얻는 대신 쿼리가 복잡해지고 타입 검증이 어렵습니다. 선택 기준은 다음과 같습니다.

실무에서는 핵심은 고정 컬럼, 확장은 키-값 또는 JSON으로 섞어 씁니다.

#통제 어휘

"서울", "서울시", "Seoul"을 모두 다른 장소로 입력하면 검색에서 놓칩니다. 이를 막으려면 통제 어휘(Controlled Vocabulary), 즉 미리 정한 목록에서 고르게 하는 방식이 필요합니다.

• 장소, 인물, 프로그램, 카테고리처럼 반복되는 값은 별도 테이블(코드표)로 관리하고, 소재에서는 ID로 참조합니다.
• 동의어(예: "서울" = "서울특별시")는 코드표에서 대표어 1개와 별칭으로 관리합니다.
• 자유 입력(키워드)과 통제 입력(카테고리)을 구분해서 UI에 제공합니다.

#표준 스키마

처음부터 자체 필드를 만들기보다 기존 표준을 참고하면 다른 시스템과 교환할 때 편합니다.

내부 스키마를 이 표준과 매핑 표로 연결해 두면, 외부 전송과 교환 시 변환이 쉬워집니다.

#변경 이력

메타데이터는 계속 수정됩니다. 누가 언제 무엇을 바꿨는지 이력(감사 로그) 을 남기세요. 특히 다음은 반드시 남깁니다.

• 서술 메타데이터 수정(사람이 입력한 값의 보호)
• AI가 자동 생성한 값과 사람이 수정한 값의 구분
• 소재의 상태 변경(승인, 반려, 삭제)
• 권한 및 공개 범위 변경

#정리

• 메타데이터는 기술·서술·구조·관리로 나누고, 입력 책임을 구분합니다.
• 소재-파일-구간 계층으로 모델링해야 프록시, 아카이브, 구간 검색을 지원할 수 있습니다.
• 핵심은 고정 컬럼, 확장은 키-값/JSON, 반복되는 값은 통제 어휘로 관리합니다.
• 표준 스키마와의 매핑과 변경 이력을 처음부터 고려합니다.

#참고 자료

• SQLite 문서: 외래키 지원

링크는 2026-10-28에 열람이 되는 것을 확인했습니다. 규격과 도구 문서는 개정될 수 있으므로 적용하기 전에 최신 판을 확인하세요.