방송 아카이브에서 영상을 찾는 일을 생각해보자.

“2020년 이후 방송분 중에 출연자 A가 다른 사람과 야외에서 밥을 먹으며 이야기하는 장면을 찾아주세요. 서울에서 촬영한 것이면 좋겠고, 온라인에 다시 쓸 수 있는 클린본이 필요합니다.”

사람에게는 낯설지 않은 요청이다. 하지만 시스템에 넘기는 순간 여러 종류의 문제가 한꺼번에 들어온다. 화면에서 누구를 찾을 것인가. ‘같이 밥을 먹는다’는 것을 어느 시간 구간에서 확인할 것인가. 서울처럼 보이는 장소와 실제 서울에서 촬영한 장소를 어떻게 구분할 것인가. 검색한 장면에 대응하는 클린본은 어디에 있고, 온라인 재사용이 가능한지는 누가 확인할 것인가.

Video embedding으로 비슷한 장면을 찾을 수는 있다. 그렇다고 similarity score가 높다는 이유로 촬영지와 출연자와 권리까지 맞는 것은 아니다. 반대로 날짜와 인물 이름만 정확하게 필터링해도 ‘편하게 대화하는 분위기’까지 잘 찾기는 어렵다.

이 사이를 연결하는 방법으로 온톨로지가 자주 등장한다. 프로그램과 회차, 인물과 장면, 파일과 권리를 관계로 묶으면 Agent가 여러 시스템을 오가며 필요한 자료를 찾을 수 있다는 설명이다. 방향 자체에는 동의한다. 다만 관계를 그려놓은 그림을 볼 때마다 그다음 질문이 먼저 떠오른다.

그 화살표는 누가, 무엇을 보고 그었을까. 그리고 틀렸을 때는 어떻게 알 수 있을까.

이 글에서는 방송 아카이브를 예로 온톨로지의 기본 개념부터 짚어보려 한다. 무엇을 표현할 수 있는지와 실제로 무엇을 알 수 있는지를 구분하고, 도입 이후에 ‘좋아졌다’는 판단마저 왜 쉽지 않은지까지 다룬다. 아래 프로그램과 인물, 시간 구간은 설명을 위한 가상 사례다. 실험하지 않은 성능 수치를 방송 현장의 측정값처럼 사용하지는 않는다.

온톨로지는 무엇을 정하는가

온톨로지를 거창하게 받아들일 필요는 없다. 특정 업무에서 어떤 종류의 대상이 존재하고, 각각이 무엇을 의미하며, 서로 어떤 관계를 맺는지를 명시하는 일에서 시작한다. ‘영상’이라는 단어 하나를 쓰더라도 프로그램 전체를 말하는지, 특정 회차인지, 디스크에 저장된 파일인지부터 맞추는 것이다.

가령 화면에는 사람이 테이블에 앉아 컵을 들고 있다. 시청자는 이를 하나의 장면으로 보지만, 아카이브 담당자는 출연자와 촬영지를 보고, 편집자는 필요한 구간과 원본 파일을 본다. 같은 화면을 보고 있어도 업무에서 중요하게 다루는 대상은 다르다. 온톨로지를 만든다는 것은 이 가운데 무엇을 구분해 기록하고, 서로 어떻게 연결할지를 함께 정하는 일이다.

그래서 온톨로지는 현실을 그대로 복사한 것이 아니다. 업무에 필요한 관점으로 현실의 일부를 표현한 모델에 가깝다. 소품을 관리한다면 컵 하나하나를 식별해야 하겠지만, 출연자 검색이 목적이라면 컵의 개별 ID까지 필요하지 않을 수 있다. 세부 정보를 많이 넣을수록 좋은 모델이 되는 것은 아니다.

Noy와 McGuinness의 Ontology Development 101도 개념과 속성을 정의하고, 실제 개체를 채워 넣는 방식으로 설명한다. 먼저 지식베이스가 답해야 할 질문인 competency question을 정하라는 조언도 나온다. 처음부터 세상의 모든 관계를 그리라는 이야기가 아니다.

비슷하게 쓰이는 용어들을 방송 사례에 놓으면 차이가 조금 선명해진다.

완전히 배타적인 분류는 아니다. 잘 설계한 DB 스키마에도 업무 의미가 들어 있고, 온톨로지 안에 실제 개체를 함께 기술할 수도 있다. 다만 정의하는 층과 데이터를 채우는 층을 구분해야 어디에서 문제가 생겼는지 알 수 있다.

종류와 개별 대상을 나눈다

그림의 Person, Segment, Place는 대상의 종류인 class다. 인물 A와 장면 42, 서울은 그 종류에 속하는 구체적인 대상인 instance다. ‘사람’이라는 개념을 정의하는 것과 ‘이 사람은 A다’라고 특정 대상을 기록하는 것은 서로 다른 층의 작업이다.

여기서 class는 단순히 데이터를 담아두는 폴더가 아니다. 어떤 대상이 그 종류에 속한다는 말이 무엇을 의미하는지 정한다. 이 글의 단순한 모델에서는 Presenter를 진행 경험이 있는 사람들의 클래스로 둘 수 있다. 그러면 Presenter는 Person의 하위 클래스가 된다. 한편 실제로 어느 회차에서 진행을 맡았는지까지 관리하려면, 사람 자체의 분류와 별개로 회차별 역할을 기록해야 한다. 직업·역할·기간을 어디까지 표현할지도 모델링의 선택이다.

처음에는 아래 세 관계를 구분하는 것만으로도 도움이 된다.

세 문장 모두 일상적으로는 ‘속한다’고 말할 수 있지만 의미는 다르다. 장면이 방송본의 일부라고 해서 장면이 방송본의 하위 클래스가 되는 것은 아니다. 진행자의 하위 클래스가 인물 A인 것도 아니다. 이 차이가 흐려지면 관계를 따라가며 얻는 결과도 달라진다. 클래스 포함과 개체의 타입은 RDF Schema의 subclass와 type으로 표현할 수 있고, 부분 관계는 업무에 맞게 별도로 정의한다.

대상 사이의 관계와 대상이 가진 값을 구분한다

Segment_42 depictsPerson Person_A는 두 개체를 연결한다. 반면 Segment_42 startMs 751000은 한 개체에 숫자 값을 붙인다. OWL에서는 전자처럼 개체 사이를 연결하는 것을 object property, 후자처럼 데이터 값을 연결하는 것을 data property로 구분한다. OWL 2 Structural Specification

이 구분은 저장 형식 이상의 차이를 만든다. 촬영지를 문자열 "서울"로만 넣으면 일단 이름을 표시할 수 있다. 촬영지 개체 Place_Seoul에 연결하면 그 대상의 다른 이름이나 행정구역 정보를 함께 사용할 수 있다. 물론 ‘서울’이라는 글자를 읽었다는 것만으로 촬영지가 서울이라고 연결해도 되는 것은 아니다. 여기서는 표현 방식의 차이를 말하고 있다.

이름과 식별자도 나누는 편이 좋다. 한 인물을 부르는 활동명과 본명, 영문 표기가 달라도 같은 인물 ID의 이름들로 관리할 수 있다. 반대로 이름이 같다고 같은 사람으로 합쳐서는 안 된다. 온톨로지에 공통 ID가 중요한 이유는 철자가 같은 문자열을 모으기 위해서가 아니라, 여러 시스템이 같은 대상을 가리키도록 하기 위해서다.

공리를 정하면 무엇을 추론할 수 있는가

개념과 관계만 나열한 사전에서 한 걸음 더 나아가면 axiom, 즉 모델 안에서 성립한다고 명시하는 진술이 등장한다. ‘진행자는 사람의 한 종류다’가 그런 예다. 이 정의와 ‘A는 진행자다’라는 기록을 함께 사용하면, A를 사람으로도 다룰 수 있다.

일반적인 정의
  Presenter —subclass-of→ Person

개별 대상에 대한 기록
  Person_A —instance-of→ Presenter

위 둘로부터 따라오는 결론
  Person_A —instance-of→ Person

이때 시스템이 A의 얼굴을 새로 알아본 것은 아니다. 입력된 사실과 정의에서 따라오는 결과를 명시한 것이다. 해당 추론을 질의에 반영하면 ‘사람을 찾아라’는 요청에서 진행자로만 기록된 A도 포함할 수 있다. 이 동작을 추론기로 처리할지, 질의 시점에 관계를 확장할지는 구현에 따라 다르다.

관계의 방향에도 정의를 줄 수 있다. depictsPerson과 appearsInSegment를 서로 역관계라고 선언하면, ‘장면 42가 A를 보여준다’에서 ‘A가 장면 42에 등장한다’를 얻을 수 있다. 모든 관계가 저절로 이런 규칙을 가지는 것은 아니다. 어떤 의미를 갖는지 선언하고, 그 의미를 시스템이 사용하도록 해야 한다. OWL 2의 Inverse Properties

이런 종류·관계의 일반적인 정의를 설명할 때 TBox라는 말을 쓰고, 특정 개체에 대한 진술은 ABox로 구분하기도 한다. 개체에 대한 진술도 넓은 의미의 axiom에 포함될 수 있으므로, axiom이 오직 일반 규칙만을 뜻하는 것은 아니다. 중요한 것은 정의의 층과 실제 데이터의 층을 함께 사용한다는 점이다. OWL 2 Primer

개념과 관계의 정의
  Segment —depictsPerson→ Person

구체적인 데이터
  Segment_42 —depictsPerson→ Person_A
  Segment_42 —startMs→ 751000
  Segment_42 —endMs→ 766000

RDF에서는 이런 진술을 주어·술어·목적어의 triple로 나타낸다. Segment_42 / depictsPerson / Person_A가 한 개의 triple이다. 여러 진술이 같은 대상을 공유하면 그래프가 된다. 중요한 것은 RDF가 세상에 대한 주장을 표현한다는 점이다. 그 형식으로 저장했다고 해서 주장의 진위가 검증되는 것은 아니다. RDF Concepts

그럼 검색에서는 무엇이 달라지는가

‘진행자 A가 등장한 장면의 클린본을 찾아달라’는 요청을 다시 생각해보자. A가 등장한 구간을 찾고, 그 구간의 편집 버전과 회차를 확인하고, 대응하는 클린본 버전과 파일까지 따라가야 한다. 이 과정에서 사람과 구간, 회차와 버전이 무엇인지 공유되어 있으면 각 시스템이 반환한 ID를 같은 의미로 연결할 수 있다.

다만 관계를 따라가는 조회와 논리적 추론은 구분해야 한다. 저장된 관계를 조인해 클린본을 찾는 것은 조회이고, 하위 클래스 정의에서 A가 Person에 속한다고 도출하는 것은 추론이다. 온톨로지를 쓴다고 모든 검색에 복잡한 추론이 필요한 것은 아니다. 단어의 의미를 맞추고, ID를 연결하고, 조회 규칙을 일관되게 만드는 것만으로도 도움이 될 수 있다.

반대로 화살표가 하나 빠져 있으면 온톨로지가 자동으로 이어주지는 않는다. 클린본의 구간 매핑을 모르면 정확한 위치를 내보낼 수 없고, 촬영지 근거가 없으면 서울이라고 확정할 수 없다. 온톨로지는 질문을 더 명확하게 만들지만, 그 질문에 답할 데이터를 대신 만들어주지는 않는다.

방송에서는 같은 영상이라는 말부터 어렵다

온톨로지를 설계할 때 먼저 막히는 것은 의외로 복잡한 추론이 아니다. 무엇을 같은 대상으로 볼 것인가의 문제다.

프로그램 12회에 방송본, 자막 없는 클린본, 저해상도 프록시, 온라인용 재편집본이 있다고 하자. 모두 같은 회차와 관련 있지만 서로 같은 파일도, 같은 편집 결과도 아니다. 프록시는 동일한 편집본을 다른 해상도로 인코딩한 표현일 수 있다. 반면 온라인용 재편집본은 장면 순서와 음악과 길이가 달라진 별도의 버전이다. 이들을 전부 ‘같은 영상’으로 합치면 검색할 때는 편해 보여도 실제 구간을 내보내는 순간 문제가 생긴다.

그래서 아래 정도는 나눠두는 편이 좋다. 특정 표준의 클래스명을 그대로 옮긴 것이 아니라, 이 글에서 사용할 최소 모델이다.

Program → Episode → EditorialVersion → MediaFile
                         │
                         └→ Segment [start, end)

방송본 버전 → 방송본 MXF / 동일 타임라인의 프록시
클린본 버전 → 클린본 MOV
온라인 재편집 버전 → 웹 배포 MP4

Segment는 어느 버전의 어느 타임라인인지까지 가져야 한다. 방송본의 12분 31초가 클린본에서도 같은 장면이라는 보장은 없다. 앞부분의 슬레이트나 광고, 삭제된 컷 때문에 위치가 달라질 수 있다. 편집 정보를 이용한 구간 매핑이 필요하고, 정확한 매핑을 모르면 그 상태도 남겨야 한다.

인물도 마찬가지다. 출연자, 극중 인물, 화면에 나온 얼굴, 음성의 화자, 자막에서 언급한 사람을 하나의 Person 관계로 처리하면 금방 모호해진다. 배우 A가 인물 B를 연기하고, 다른 배우가 B를 언급하는 장면에서 ‘B가 나온 영상’은 무엇을 뜻하는가. 사용자가 실제 배우의 얼굴을 찾는지, 극중 인물이 등장하는 장면을 찾는지에 따라 검색 조건이 달라진다.

처음의 ‘두 사람이 함께 밥을 먹으며 대화한다’는 요청에도 시간축이 필요하다. A의 식사 장면과 B의 인터뷰 장면이 같은 회차에 있다는 이유로 두 사람이 같이 식사했다고 연결할 수는 없다. 식사나 대화의 event를 따로 두고 참여자와 구간, 근거를 붙이는 방법을 생각할 수 있다. 같은 시간대에 보인다는 조건도 최소한의 단서일 뿐, 교차편집까지 고려하면 실제 상호작용의 증명은 아니다.

방송사가 이 문제를 모두 처음부터 정의해야 하는 것은 아니다. EBU에는 미디어 기업을 위한 EBUCorePlus가 있다. 기존 EBUCore와 CCDM을 잇는 모델이고, 공개 저장소에서 개념과 관계를 살펴볼 수 있다. 다만 표준을 가져오는 일과 내부의 회차 번호, 파일 ID, 큐시트, 계약 원장을 정확히 매핑하는 일은 다르다. 표준은 공통 언어의 출발점이지, 사내 데이터의 빈칸을 채워주는 도구는 아니다.

논리적으로 맞는 데이터가 사실과도 맞는 것은 아니다

온톨로지에는 제약과 추론이 있으니 잘못된 데이터를 걸러줄 것이라는 기대가 있다. 어느 정도는 맞지만, 무엇을 걸러주는지 구분해야 한다.

예를 들어 depictsPerson의 domain을 Segment, range를 Person으로 선언했다고 하자. RDFS의 domain과 range는 일반적인 입력 폼의 타입 검사와 다르다. 해당 관계의 주어와 목적어가 그 클래스에 속한다고 추론하는 의미를 가진다. 입력을 자동으로 거부하는 규칙으로 생각하면 곤란하다. RDF Schema의 Domain과 Range

‘구간에는 기준 버전이 있어야 한다’, ‘시작 위치는 끝보다 작아야 한다’ 같은 데이터 조건은 별도의 validation으로 검사할 수 있다. RDF에서는 SHACL이 이런 역할을 맡는다. 하지만 스키마 검사를 통과한 Segment_42 depictsPerson Person_A에서 정말 A가 나오는지는 영상을 확인해야 한다. 이름이 B였더라도 형식은 완벽하게 맞을 수 있다.

동일 인물 연결은 더 조심해야 한다. owl:sameAs는 ‘닮았다’거나 ‘같은 사람일 확률이 높다’는 뜻이 아니다. 두 식별자가 동일한 개체를 가리킨다는 강한 선언이다. 해당 의미로 추론하면 한쪽의 정보가 다른 쪽에도 적용된다. OWL 2의 Individual Equality

얼굴 클러스터 자체는 사람도 아니다. 얼굴 관측을 묶은 데이터 객체이므로, 신원을 확인한 뒤에도 클러스터와 사람을 동일한 개체로 합치기보다 ‘이 클러스터가 묘사하는 사람’이라는 관계로 연결하는 편이 맞다. 검증 전에는 별도의 identity candidate로 남겨야 한다. sameAs를 먼저 확정하고 옆에 confidence 0.82를 붙인다고 일반적인 OWL 추론기가 그 동일성을 82%만 적용해주지는 않는다.

또 하나는 없음과 모름의 차이다. OWL의 open-world 관점에서는 기록되지 않은 사실이 곧 거짓은 아니다. ‘이 장면에 A가 등장한다는 기록이 없다’와 ‘A가 등장하지 않는다’는 다르다. OWL 2 Primer

실제 서비스가 특정 테이블을 완전한 목록으로 간주하고 closed-world 방식으로 질의할 수는 있다. 다만 그 완전성 가정은 명시해야 한다. 분석하지 않은 장면을 ‘인물 없음’으로 처리하거나, 계약을 찾지 못한 파일을 ‘제약 없음’으로 처리하는 것은 아주 다른 종류의 오류를 만든다.

Agent에게 필요한 것은 관계망보다 업무 의미다

Agent가 검색하고 파일을 찾아 편집 도구까지 호출하려면 시스템마다 쓰는 단어가 이어져야 한다. 검색 엔진의 clip ID와 MAM의 asset ID가 어떻게 연결되는지, clean이 자막만 없는 상태인지 음악까지 빠진 상태인지, 어떤 타임코드를 넘겨야 하는지 알아야 한다.

이 의미가 정리되어 있지 않으면 Agent는 매번 Tool 설명과 문서를 읽고 추측한다. 온톨로지는 그때그때의 추측 일부를 공유 가능한 정의와 관계로 옮기는 방법이다. 모델이 모든 API의 의미를 혼자 알아내도록 두지 않는다는 점에서 유용하다.

그렇다고 모든 Agent에 RDF와 OWL, Graph DB가 필수라는 뜻은 아니다. 범위가 작은 업무라면 잘 정의한 관계형 스키마, 공통 ID, 제한된 Tool과 정책 검사만으로 충분할 수 있다. 여러 부서와 시스템이 서로 다른 이름으로 같은 대상을 다루고, 복잡한 관계를 반복해서 따라가야 할수록 명시적인 온톨로지의 가치가 커진다. Graph DB는 저장·질의 수단이고, 온톨로지는 그 안에 무엇을 어떤 의미로 넣는지의 문제다.

GraphRAG 논문도 이 구분을 염두에 두고 볼 필요가 있다. 문서에서 개체 관계를 추출하고 community summary를 만들어, 문서 집합 전체를 묻는 질문에 답하는 접근이다. 그 성과를 곧바로 방송 장면의 인물 식별 정확도나 재사용 권리 판단의 근거로 가져올 수는 없다. 전체 주제를 잘 요약하는 것과 특정 15초를 안전하게 내보내는 것은 다른 평가 문제다.

특히 ‘재사용 가능’은 영상의 고정된 특징으로 보기 어렵다. 어떤 버전과 구간을, 어느 채널과 지역에서, 언제, 어떤 목적으로 쓰는지에 따라 확인할 조건이 달라진다. 음악이나 삽입 영상에 별도의 조건이 붙을 수도 있다. ODRL Information Model은 permission, prohibition, duty와 constraint를 표현할 수 있지만, 누락된 계약을 발견하거나 모든 권리 판단을 대신하는 것은 아니다.

내가 기대하는 구조는 검색 후보를 찾는 단계와 행동을 승인하는 단계를 분리하는 것이다. Agent는 근거가 부족한 후보도 검토 대상으로 가져올 수 있다. 그러나 실제 export나 배포 직전에는 권한 있는 원장과 현재 요청 조건을 다시 확인해야 한다. 알 수 없으면 확인을 요청하고, 금지된 경우에는 실행하지 않는 경계가 필요하다.

영상에서 관계를 채우는 순간 어려워진다

Segment depictsPerson Person이라는 정의를 만드는 일보다, 오래된 방송 수십만 시간에서 그 관계를 정확히 채우는 일이 훨씬 어렵다. 자동 분석 결과를 어디까지 사실로 사용할 것인지도 여기서 결정된다.

OCR부터 생각해보자. 예능 화면에는 발화 자막, 이름표, 효과 자막, 간판, 방송사 로고가 함께 나올 수 있다. 글자를 맞게 읽어도 그 글자가 무엇을 설명하는지 틀리면 엉뚱한 관계가 만들어진다. 화면 한쪽의 인물 이름이 지금 보이는 사람의 이름인지, 다음 출연자를 예고하는 자막인지도 다르다. 따라서 필요한 것은 문자열 하나가 아니라 검출 위치, 노출 구간, 자막 유형, 연결 대상이다.

얼굴에서는 검출, 추적·클러스터링, 실명 식별을 나눠야 한다. 얼굴이 있다는 것과 여러 컷의 얼굴이 같다는 것, 그 사람이 누구인지는 각각 다른 주장이다. ASR에서도 누군가 말한 문장을 얻는 것과 그 발화를 특정 인물에게 귀속하는 것은 별도의 문제다. 화면에 보이는 사람이 반드시 말하는 사람인 것도 아니다.

객체 검출과 장면 설명은 의미가 더 쉽게 넓어진다.

이 표는 특정 모델의 실패율을 보고하는 것이 아니다. 관측이 맞더라도 다음 주장을 위해 다른 증거가 필요하다는 뜻이다. 특히 계약이나 제작 의도는 화면만 오래 본다고 반드시 알아낼 수 있는 정보가 아니다.

VLM이 “두 사람이 서울의 카페에서 커피를 마시며 대화한다”고 자연스럽게 설명하면 이 경계가 잘 보이지 않는다. 사람 수, 장소 유형, 음료 종류, 정확한 지역, 상호작용이 하나의 문장에 붙어 있다. 이를 그대로 여러 개의 확정 관계로 쪼개 저장하면 한 문장의 추측이 정교한 데이터처럼 보이게 된다.

그래서 추출 단계에서는 더 풍부한 설명보다 어느 부분이 관측이고 어느 부분이 해석인지 되돌아볼 수 있는가를 먼저 보고 싶다. 사용자가 틀린 장소 하나를 고쳤을 때 원래 문장과 관련 관계를 함께 찾아 수정할 수 있어야 한다.

정확도만 높이면 되는 것도 아니다

드문 자막이나 짧은 행동까지 찾으려면 충분한 시간 해상도로 영상을 보아야 한다. 이 부분에는 모델 이전의 제약이 있다.

설명을 단순하게 하기 위해, 매 $\Delta$초마다 한 프레임을 읽고 자막이 $d$초 동안 계속 보인다고 하자. 자막 시작 시점이 샘플링 주기 안에서 균일하게 분포하며 영상 경계 효과가 없다는 가정에서는, 자막을 한 번이라도 볼 확률이 다음과 같다.

$$P(\text{sample hits subtitle}) = \min\left(1, \frac{d}{\Delta}\right)$$

2초마다 한 장을 읽는데 자막은 0.5초만 보인다면 이 단순 모형에서는 25%다. OCR이 완벽해도 읽지 않은 프레임의 글자는 인식할 기회가 없다. 실제 성능 수치가 아니라, 샘플링 누락과 인식 오류가 별개라는 것을 보여주는 계산이다.

조밀하게 읽으면 디코딩과 추론량이 늘어난다. 여기에 추적, 여러 모달리티의 대조, 사람 검수까지 더하면 비용은 GPU 시간으로 끝나지 않는다. Video Retrieval 파이프라인을 다룬 이전 글에서도 모델 밖의 디코딩과 장애 처리가 전체 처리량에 영향을 주었다.

연산 규모도 감각적으로 확인해볼 수 있다. 가상의 아카이브가 10만 시간이고, worker 하나가 전체 분석을 실시간의 20배 속도로 처리하며, 4개 worker가 완벽하게 병렬 동작한다고 가정하면 다음과 같다.

$$T_{\text{wall}} = \frac{100{,}000\ \text{h}}{20 \times 4} = 1{,}250\ \text{h} \approx 52\ \text{days}$$

이 값에는 입출력 병목, 실패 재시도, 사람이 검토하는 시간도 없다. 특정 모델의 성능 추정이 아니라 산술 예시다. 데모 몇 개를 처리하는 비용으로 전체 구축을 짐작하면 안 되는 이유다.

그렇다고 정확도와 속도가 영원히 고정된 trade-off라는 뜻은 아니다. 전처리 공유, 적응적 샘플링, 모델 개선으로 둘 다 좋아질 수 있다. 다만 제한된 자원에서 어떤 정보를 생략했는지, 그 생략이 어떤 업무의 실패로 이어지는지는 남는다. 그래서 영상 한 시간당 처리 비용과 함께, 검증된 유효 관계 한 건당 비용과 검수 시간을 봐야 한다.

confidence 하나로 신뢰를 표현할 수 있을까

얼굴 모델의 0.9와 OCR의 0.9, LLM이 문장으로 적어낸 90%는 같은 값이 아니다. 평가 데이터에서 calibration을 확인하지 않았다면, 같은 숫자라는 이유만으로 비교하거나 평균 낼 수 없다. 특히 같은 자막을 두 모델이 읽었다면 서로 독립적인 증거 두 개가 생긴 것도 아니다.

Calibration은 예를 들어 0.9라고 예측한 사례들이 실제로도 약 90% 맞는지를 보는 문제다. Guo 등의 On Calibration of Modern Neural Networks는 분류 정확도와 confidence의 보정이 별개임을 다룬다. 다만 그 연구의 보정 방법을 가져온다고 장르와 시대가 다른 방송 자료, 여러 종류의 관계 점수가 한꺼번에 보정되는 것은 아니다.

나는 관계 옆에 confidence 하나를 붙이는 것으로는 부족하다고 생각한다. 관계를 하나의 assertion, 즉 출처와 상태를 가진 주장으로 관리하는 편이 낫다.

이 축들을 하나의 상태 목록에 섞지 않는 것이 좋다. ‘공식 문서에서 추출됨’과 ‘사람이 확인함’은 동시에 참일 수 있고, 사람이 확인한 주장도 나중에 철회될 수 있다. 문서가 공식이라고 그 문서에서 OCR로 추출한 값까지 자동으로 공식 사실이 되는 것은 아니다.

예를 들어 얼굴 트랙에 대한 identity 후보는 다음 정도의 기록으로 시작할 수 있다. 숫자와 ID는 모두 가상이며, 표준 직렬화 형식이 아니라 필요한 필드를 보여주는 예시다.

{
  "claimId": "identity-019",
  "subject": "face-track-81",
  "predicate": "candidateIdentity",
  "candidateObject": "person-A",
  "reviewStatus": "unreviewed",
  "evidence": {
    "mediaFileId": "episode-12-broadcast-proxy",
    "editorialVersionId": "episode-12-broadcast-v1",
    "timebase": "milliseconds-from-file-start",
    "startMs": 751000,
    "endMs": 766000
  },
  "generatedBy": "identity-pipeline-v3",
  "rawModelScore": 0.82,
  "calibrationId": null
}

이 후보 기록이 확정된 신원 관계로 조용히 편입되어서는 안 된다. 실제로는 모델과 가중치, 프롬프트와 전처리 버전, 참조 얼굴이나 문서의 위치, 검토 이력까지 이어져야 한다. W3C의 PROV-O는 데이터와 처리 활동, 책임 주체 사이의 계보를 표현하는 기반을 제공한다. 다만 PROV-O를 쓴다고 confidence가 보정되거나 업무별 승인 기준이 생기지는 않는다. 그 부분은 별도로 설계해야 한다.

또한 근거가 필요한 것은 사람이 결과를 검토할 때만이 아니다. 잘못된 인물 연결 하나를 철회했을 때, 그 연결을 사용한 검색 인덱스와 요약과 캐시가 무엇인지 찾아야 한다. 관계를 계속 추가하는 것보다 잘못된 관계를 빼고 영향을 되돌리는 쪽이 더 어려울 수 있다.

한 번 만든 메타데이터도 계속 관리해야 한다

모델이 바뀌고 스키마가 바뀌며 실제 업무 조건도 바뀐다. 이를 모두 ‘메타데이터가 낡았다’고 묶으면 재처리 범위를 결정하기 어렵다.

새 얼굴 모델이 나왔다고 사람이 확인한 과거 출연 정보가 곧바로 무효가 되지는 않는다. 반면 계약의 적용 기간이 끝난 경우에는 얼굴을 다시 분석할 필요 없이 권리 판단을 갱신해야 한다. appearsIn을 화면 등장과 음성 등장으로 나누기로 했다면, 기존 데이터의 의미와 이를 조회하는 코드까지 바뀐다.

표준도 예외는 아니다. EBU의 TECH 3397 v2 안내는 이전 버전과의 비호환성을 명시한다. 표준을 선택하면 의미 변경이 사라지는 것이 아니라, 변경을 따라갈 기준이 생긴다고 보는 편이 맞다.

그래서 원시 관측과 파생 관계를 분리할 필요가 있다. 원본 프레임·오디오·문서, 모델이 추출한 관측, 정규화한 관계 후보, 현재 채택한 관계를 구분해두면 모델 전체를 다시 돌리지 않고도 매핑이나 검토 결과만 갱신할 여지가 생긴다.

시간도 최소한 둘이다. ‘계약 조건이 언제 유효한가’와 ‘시스템이 그 조건을 언제 알았는가’는 다르다. 9월 1일부터 적용되는 변경을 9월 3일에 입력했다면, 9월 2일의 판단을 사후 감사할 때 두 시점을 함께 봐야 한다. 모델 실행 시각을 저장하는 것만으로는 해결되지 않는다.

단, 모든 원시 데이터를 영구 보존하자는 뜻은 아니다. 얼굴 참조 이미지, 화자 정보, 계약 문서는 접근 권한과 보존 범위를 따로 관리해야 한다. 삭제나 정정 요청이 들어오면 파생 관계와 검색 인덱스까지 반영되어야 한다. 신뢰를 설명하려고 모은 데이터가 새로운 관리 부담이 되는 지점이다.

기존 DB가 없으면 그래프보다 목록이 먼저다

체계적인 메타데이터가 없는 아카이브에서는 온톨로지보다 파일 목록을 정리하는 일이 먼저일 수 있다. 어느 저장소에 무엇이 있고, 어떤 파일이 정상적으로 읽히며, 서로 어떤 버전 관계를 가지는지부터 알아야 한다.

파일명, 미디어 헤더, EPG, 자막 sidecar, 큐시트, NLE 편집 정보, 제작 스프레드시트에 단서가 흩어져 있을 수 있다. 영상에서 실명을 새로 추론하기 전에 이미 제작 과정에서 기록한 출연자와 촬영지 정보를 찾는 편이 나을 수도 있다. 체크섬이 같은 파일은 중복 여부를 확인하기 쉽지만, 화면이 비슷한 재편집본까지 같은 콘텐츠로 합쳐서는 안 된다.

시스템을 구성할 때도 모든 데이터를 Graph DB에 넣을 필요는 없다. 원본 미디어는 MAM이나 object storage에, 촘촘한 검출·트랙은 관계형 또는 컬럼형 저장소에, 자막은 전문 검색에 두고 연결할 수 있다. 벡터 인덱스는 의미가 비슷한 후보를 찾고, 관계 질의는 인물과 버전과 기간 조건을 좁힌다. 주장과 근거의 관리도 반드시 별도의 제품 하나여야 하는 것은 아니다. 논리적 역할을 나누는 것과 저장소 여섯 개를 운영하는 것은 다르다.

여기서 기술보다 오래 걸릴 수 있는 것은 담당 부서 사이의 합의다. 누가 인물 ID를 확정하는가. 제작 문서와 아카이브 기록이 다르면 무엇을 우선하는가. 계약 원장이 변경될 때 누가 알림을 주는가. 검색에 쓰는 ‘클린본’의 정의를 바꾸면 어느 도구까지 고쳐야 하는가.

업무 의미를 공유한다는 것은 결국 변경 권한과 책임도 공유한다는 뜻이다. 스키마 파일만 배포한다고 합의가 생기지는 않는다.

도입 효과는 왜 평가하기 어려운가

어렵게 만들었으면 이제 성능을 비교하면 될 것 같지만, 평가에도 같은 문제가 따라온다. 무엇이 정답이고 무엇을 개선했다고 볼 것인지부터 정해야 한다.

정답을 만드는 데에도 아카이브 지식이 필요하다

처음의 요청에 맞는 장면이 전체 아카이브에 몇 개 있는지 알고 있는 사람은 대개 없다. 검색된 상위 20개를 검토해서 그중 몇 개가 맞는지는 평가할 수 있다. 하지만 검색되지 않은 수만 시간에 얼마나 많은 정답이 남아 있는지 알아야 전체 recall을 계산할 수 있다.

여러 검색 방식의 결과를 모아 후보 풀을 만들고 사람이 판정하는 방법은 현실적인 출발점이다. 그래도 그 풀 밖에 있는 영상은 검토되지 않았다. 미판정 결과를 곧바로 오답으로 넣으면 새로운 방식이 찾아낸 좋은 장면이 오히려 불이익을 받을 수 있다. 평가 문서에는 정답의 범위와 미확인 데이터 처리 방식을 함께 적어야 한다.

이 문제는 Agent 이전의 검색 평가에서도 다뤄졌다. Buckley와 Voorhees의 Retrieval Evaluation with Incomplete Information은 불완전한 적합성 판정이 평가 지표에 미치는 영향을 분석한다. 방송 아카이브에 적용할 때도 정답 집합이 불완전하다는 조건을 지표 해석에서 빼서는 안 된다.

판정자끼리도 기준이 다를 수 있다. 한 사람은 ‘야외에서 대화’를 원하고 다른 사람은 편집에 쓸 수 있는 리액션과 여유 프레임까지 요구한다. 영상의 의미적 적합성, 구간의 편집 가능성, 재사용 조건을 나누어 판정해야 불일치의 원인을 알 수 있다. 계약 기록이 없어서 모르는 것과 장면이 틀린 것도 구분해야 한다.

온톨로지 설계의 정답도 하나가 아니다. 대화를 하나의 event로 묶을지 여러 turn으로 나눌지에 따라 노드 수와 관계 수는 달라진다. 둘 중 하나가 무조건 더 정확한 것은 아니다. 실제로 답해야 하는 질문을 표현할 수 있는지부터 봐야 한다.

좋아진 이유가 온톨로지인지도 분리해야 한다

기존 시스템에는 파일명만 있었는데 새 시스템에 ASR, 얼굴 인식, VLM 설명과 그래프를 한꺼번에 넣었다고 하자. 검색이 좋아졌더라도 그것만으로 온톨로지의 효과를 입증할 수는 없다. 데이터가 풍부해졌기 때문인지, 인물 ID를 정리했기 때문인지, 그래프 추론이 도움이 된 것인지 분리되지 않는다.

가능하다면 아래처럼 비교 범위를 나눠보고 싶다. 아래 표는 실험 결과가 아니라 평가 설계안이다.

비교하려는 요소 외에는 모델, 검색 후보 수, 검수된 근거, UI, 응답 예산을 가능한 한 맞춰야 한다. 그래프 저장소 자체의 효과를 보려면 같은 의미와 규칙을 SQL로 구현한 경우와도 비교해야 한다. 반대로 실제 도입안 전체의 효용을 보려는 실험이라면 결합된 개선으로 보고하되, 특정 구성 요소의 공으로 돌리지 않는 편이 맞다.

데이터를 어떻게 나누는지도 중요하다. 같은 인물이나 같은 회차의 인접 장면을 학습·조정용과 평가용에 섞으면 이미 정리해둔 identity나 거의 같은 컷의 이점을 재사용할 수 있다. 기존 인물을 찾는 성능과 새로운 인물·프로그램·과거 저화질 자료로 확장하는 성능을 따로 봐야 한다.

작은 관계 오류가 작은 업무 오류인 것은 아니다

인물 A와 잘못 연결된 얼굴 클러스터 하나가 수백 개 장면에 사용되었다고 하자. identity 오류는 한 건이지만 검색 결과와 인물별 통계, 추천과 요약에는 여러 번 나타날 수 있다. 전체 triple 중 틀린 비율이 낮다는 설명으로는 이 영향을 표현하기 어렵다.

반대로 관계를 보수적으로 적게 만들면 precision은 높아질 수 있다. 어려운 요청을 전부 ‘모름’으로 돌려주면 오답도 줄어든다. 그러나 사용자가 매번 다시 찾고 확인해야 한다면 업무가 개선되었다고 하기 어렵다. 따라서 자동으로 답한 비율인 coverage와 그 안의 오류를 함께 보고, 보류된 요청을 처리하는 사람의 시간도 계산해야 한다.

권리 판단처럼 오류 비용이 다른 업무는 더욱 그렇다. 잘못 허용하는 경우, 사용할 수 있는 자료를 잘못 제외하는 경우, 미확인으로 남기는 경우를 별도로 집계해야 한다. 작은 테스트에서 사고가 없었다는 것만으로 드문 고위험 오류가 없다고 결론 내릴 수는 없다.

LLM이 채점하면 해결될까

장면 설명과 답변을 LLM으로 채점하는 방법은 검토를 보조하는 데 유용할 수 있다. 하지만 관계를 생성한 모델이 만든 설명을 다시 모델에게 주고 ‘타당한가’를 묻는 것은 원본 근거를 검증한 것과 다르다.

LLM-as-a-Judge 연구는 평가의 확장 가능성과 함께 위치, 답변 길이, 자기 선호 등의 편향을 다룬다. 이것이 모든 평가 모델이 쓸모없다는 뜻은 아니다. 방송 업무에 적용한다면 원본 구간과 필요한 제작 기록을 보게 하고, 시스템 이름을 가린 비교와 제시 순서 변경, 사람 판정과의 불일치 분석을 함께 해야 한다는 뜻이다.

‘그럴듯한 답변’과 ‘근거에 맞는 답변’, ‘실제로 사용할 수 있는 클립’은 별도 점수로 남기는 편이 낫다. 인용 링크가 있다는 사실도 충분하지 않다. 그 링크의 어느 구간이 답변의 어느 주장을 뒷받침하는지 확인해야 한다.

결국 어디까지를 성과로 셀 것인가

검색 결과가 빨리 뜨는 것보다, 제작자가 쓸 수 있는 클립을 확보하기까지 얼마나 걸렸는지가 더 중요하다. 검색 시간을 줄여놓고 검수와 수정 시간을 더 늘렸을 수도 있다. 반대로 검색 정확도는 비슷해도 잘못된 인물 연결의 원인을 빨리 찾아 고칠 수 있다면 운영에서는 가치가 있다.

이들을 숫자 하나로 합치면 비용이 큰 실패가 평균에 가려질 수 있다. 업무별로 허용 가능한 오류와 보류 수준을 먼저 정하는 편이 좋다. 사용자 테스트도 같은 사람이 이미 정답을 본 영상을 다시 찾으면 두 번째 시스템이 유리하다. 유사한 난이도의 다른 과업을 배정하거나 순서를 바꾸어 학습 효과를 줄여야 한다.

이 정도의 평가도 완전하지는 않다. 드문 사고, 새로운 프로그램의 형식, 실제 사용자의 질의 변화는 짧은 PoC에서 다 볼 수 없다. 그래서 평가가 어렵다는 말은 평가할 수 없다는 뜻이 아니라, 지금 확인한 효용의 범위를 좁혀 말해야 한다는 뜻에 가깝다.

그래도 시작한다면 어디까지 할 것인가

나는 처음부터 모든 장면에 인물·장소·행동·상품·감정을 채우는 방식으로 시작하지는 않을 것 같다. 먼저 실제 제작자가 반복해서 하는 요청을 모으고, 무엇을 자동으로 결정하면 안 되는지도 함께 정하고 싶다.

파일과 버전, 회차와 타임라인을 정리하고 기존 자막과 제작 기록을 연결한다. 그 위에 텍스트·영상 검색을 얹어 최소한의 기준선을 만든다. 특정 인물 검색이 자주 실패한다면 얼굴 트랙과 identity 검토를 보강하고, 클린본을 찾는 데 시간이 오래 걸린다면 버전 관계와 구간 매핑부터 개선한다. 필요하지 않은 관계를 풍부하게 만드는 것보다 실패하는 업무 하나를 줄이는 편이 낫다.

고비용 분석은 자주 쓰이거나 실제 요청이 들어온 자료에 선택적으로 적용할 수 있다. 다만 검색 상위 후보에만 새 메타데이터를 붙이면 이미 잘 검색되는 자료만 더 잘 검색되는 편향이 생긴다. 후보 밖의 자료를 무작위·층화 표본으로 점검하는 경로도 남겨야 한다.

과거 아카이브와 앞으로 만들 콘텐츠도 접근을 달리할 필요가 있다. 과거 영상은 흩어진 기록을 복원하는 작업이다. 신규 콘텐츠는 제작 시점부터 인물·촬영·편집 버전의 ID를 남기고 큐시트와 계약 원장을 연결할 수 있다. 나중에 AI가 화면을 보고 추정해야 할 일을 애초에 기록해두는 것이다.

이렇게 해도 검수와 유지보수는 사라지지 않는다. 모델이 좋아지면 후보를 만드는 비용은 줄어들 수 있지만, 부서별 정의를 맞추고 권리 변경을 반영하며 문제가 있는 관계를 철회하는 일은 남는다. PoC가 끝난 뒤 그 일을 누가 맡는지 정하지 않았다면 아직 도입 비용을 다 계산한 것이 아니다.

관계가 많아질수록 책임도 선명해져야 한다

온톨로지를 불필요한 작업이라고 생각하지는 않는다. 오히려 Agent가 여러 시스템의 데이터를 조합하고 행동하기 시작하면, 조직이 암묵적으로 알고 있던 의미를 명시해야 할 필요는 더 커진다. 파일과 콘텐츠를 구분하고, 관측과 추정을 나누고, 어떤 근거로 무엇을 허용했는지 남기는 일이다.

다만 관계를 명시했다고 불확실성이 사라지는 것은 아니다. 잘못된 연결도 더 쉽게 재사용되고 전파될 수 있다. 그래프가 촘촘해질수록 시스템이 많이 안다는 인상을 주지만, 실제로는 같은 추측을 여러 경로로 반복하고 있을 수도 있다.

그래서 방송 영상 온톨로지의 성과를 ‘몇 개의 노드와 관계를 만들었다’로 끝내고 싶지는 않다. 제작자가 필요한 장면을 찾았는지, 그 장면을 쓸 수 있는지, 틀렸을 때 원인과 영향을 찾아 고칠 수 있는지를 보고 싶다. 그 확인에 드는 사람의 시간도 성과의 바깥으로 밀어내서는 안 된다.

결국 내가 원하는 것은 아카이브의 모든 관계를 아는 시스템이 아니다. 무엇을 근거로 알고 있다고 말하는지, 어디까지는 아직 모르는지, 그리고 그 상태에서 어떤 행동을 해도 되는지 설명할 수 있는 시스템이다. 온톨로지는 그 설명을 가능하게 하는 기반이 될 수 있다. 설명에 필요한 근거와 책임까지 대신 만들어주지는 않는다.