적시형 온톨로지: 저렴해진 지능은 데이터에 어떤 의미일까요?

URL: https://www.youtube.com/watch?v=8uG4ZY7G2r8 원제: Just-in-Time Ontologies: What Cheap Intelligence Means for Data — Hrishi Olickel, Southbridge AI 원본 발표: https://www.youtube.com/watch?v=Fa3hQVIKShw 날짜: 2026-10-17 채널: Tech Bridge 발표자: Hrishi Olickel, Southbridge AI 길이: 20분 54초

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==범용 스키마를 데이터에 먼저 씌우는 대신, 구체적인 결정을 내리는 순간에 필요한 온톨로지(ontology)를 구성하고 그 근거와 검증을 함께 보존해야 한다.==

• 데이터의 의미는 원천이 기록할 수 있는 것, 저장소가 담을 수 있는 것, 결정이 요구하는 것, 모델이 당연시하는 가정이 만나는 지점에서 달라진다.
• 저렴해진 지능은 대규모 데이터 변환을 값싸게 만들지만, 모델의 사전 가정이 만든 조용한 오류까지 없애지는 않는다.
• 답변 생성비보다 검증·불일치 조정·감사에 더 많은 비용이 들 수 있으므로, 파이프라인은 실패 정의와 독립 검증부터 설계해야 한다.

데이터를 하나의 정적 스키마로 통합하면 서로 다른 업무의 의미와 맥락이 누락된다. 질문이 정해진 시점에 출처·저장 제약·판단 목적을 모아 필요한 구조를 만들고, 결과와 증거를 재사용할 수 있도록 보존해야 한다. Ohio 선거자금 기부자 데이터의 엔터티 해소(entity resolution)는 이 접근을 203,317건 규모에서 시험한 사례다.

1. 데이터 의미는 결정 맥락에 따라 달라진다

1.1. 보편 스키마가 놓치는 업무별 의미

1. Customer라는 이름도 업무마다 다른 대상을 가리킨다

   1. 청구(billing): 비용을 지불하는 사람이 고객이다.
   2. 지원(support): 문의 전화를 걸거나 문제를 제기하는 사람이 고객이다.
   3. 컴플라이언스(compliance): 회사가 법적 책임을 지는 법인이나 관계자가 고객이다.
   4. 결정 의존성: 환불 여부를 판단할 때 필요한 고객 정의는 청구·지원·컴플라이언스 중 어떤 결정을 내리는지에 따라 달라진다.

2. 하나의 마스터 스키마는 질문이 나오기 전에 의미를 고정한다

   1. 선행 통합의 위험: Customer 같은 단일 필드는 어떤 뜻을 채택할지 미리 결정하게 만들어, 나중에 필요한 의미를 표현하지 못할 수 있다.
   2. 현장 괴리: 필수 정보가 마스터 모델에 없으면 팀은 스프레드시트를 옆에 두고 실제 결정을 내리게 된다.
   3. 도입률만으로 설명되지 않는 실패: 팀이 새 모델로 옮겨가지 않는 문제도 있지만, 모두가 즉시 이전하더라도 질문과 맞지 않는 스키마는 여전히 잘못된 답을 낳는다.

1.2. 같은 관측값도 출처·시점·목적에 따라 달라진다

1. 측정값은 관측 조건을 함께 보존해야 한다

   1. 센서 차이: 휴대전화, 책상 센서, 손목시계는 서로 다른 온도값을 기록할 수 있다.
   2. 맥락 손실: 숫자만 남기면 측정한 기기와 정확한 시점이 사라져 차이를 해석할 근거가 없어진다.
   3. 목적별 해석: 개인의 쾌적함 조절, 일기예보 지도 작성, 민감 장비 배치에는 각각 다른 측정과 정밀도가 필요하다.

2. 결정 시점에 필요한 의미 구조를 만들어야 한다

   1. 질문 우선: 필요한 데이터와 정의는 어떤 결정을 내릴지 정해진 뒤에 구체화한다.
   2. 증거 동봉: 답변에 사용한 출처, 해석, 확인 범위를 함께 기록해야 결과를 검토할 수 있다.
   3. 재사용 가능한 문맥: 검증된 결정별 구조는 다음 작업에서 재사용하되, 모든 업무에 적용되는 단일 의미 체계로 과장하지 않는다.

2. 네 가지 스키마가 결정 시점에 만난다

2.1. 데이터 변환에는 서로 다른 네 가지 구조가 작동한다

1. 원천이 기록할 수 있는 구조

   1. 원천 스키마(source schema): 데이터 수집 시스템과 원본 파일이 실제로 표현하는 필드·레이블·형식이다.
   2. 표현 한계: 원천에 저장된 표기와 구조가 업무상 의도한 의미를 항상 명료하게 전달하지는 않는다.

2. 저장소가 담을 수 있는 구조

   1. 저장 제약(storage schema): 데이터베이스와 파이프라인이 허용하는 자료형·필드·형식이다.
   2. 변환 손실: 원천 표기를 저장소 규칙에 맞추는 과정에서 부호·기호·세부 맥락이 탈락할 수 있다.

3. 결정이 요구하는 구조

   1. 결정 스키마(decision schema): 환불, 지급, 신원 연결처럼 실제 판단에 필요한 사실과 구분이다.
   2. 목적 의존성: 같은 원천 레코드라도 결정의 종류에 따라 필요한 필드와 해석이 달라진다.

4. 모델이 이미 가정하는 구조

   1. 모델 사전(prior): 모델이 흔한 표기법·형식·관계라고 추정하는 선행 가정이다.
   2. 조용한 오류의 원인: 사전 가정은 데이터와 맞지 않아도 모델이 자연스럽게 보정해 버릴 수 있어, 기본 집계만으로 발견하기 어렵다.

2.2. 네 구조의 충돌을 결정마다 명시한다

1. 원천·저장·결정의 연결을 구체화한다

   1. 필드의 의미: 각 값이 어떤 원천에서 왔고, 저장 중 어떤 변환을 거쳤으며, 결정에서 어떤 역할을 하는지 연결한다.
   2. 가정의 노출: 모델이 채워 넣거나 표준화한 의미를 사실처럼 취급하지 말고, 확인할 가정으로 분리한다.

2. 필요한 온톨로지를 적시에 만든다

   1. Just-in-time ontology: 질문이 주어졌을 때 그 결정에 맞는 개체·관계·규칙을 구성한다.
   2. 영구 대형 모델 대신 작업별 구조: 모든 필드를 사전에 하나의 보편 모델로 통합하지 않고, 당면한 질문을 정확히 표현한다.
   3. 결과와 영수증 보존: 해석, 근거, 검증 결과를 결과와 함께 보관해 다음 변환에 활용한다.

3. Ohio 선거자금 데이터에서 시험한 엔터티 해소

3.1. 대규모 기부자 중복 식별을 작은 예산으로 수행한다

1. 문제는 같은 실체를 가리키는 기록을 연결하는 일이다

   1. 엔터티 해소(entity resolution): 이름과 기록이 달라도 동일한 개인·회사·위원회를 가리키는 데이터 행을 찾아 연결한다.
   2. 도메인 사례: Ohio 선거자금 기록에서 기부자 관련 사례를 분류·연결하는 파이프라인이 작업 대상이다.

2. 작은 표본으로 설계를 비교한 뒤 전체 규모로 확장한다

   1. 아키텍처 비교: 팀은 약 200개 가족(family) 사례로 세 가지 아키텍처를 시험했다.
   2. 전체 처리량: Ohio 기부자 사례 203,317건을 약 10일 동안 라벨링했다.
   3. 비용: 약 10,000달러로 추정했던 작업을 800달러 예산 안에서 795달러에 마쳤다.

3. 답변 생성과 검증에 든 비용을 구분한다

   1. 최초 답변: 첫 결과 생성에는 128달러가 들었다.
   2. 검증과 조정: 545달러는 2차 의견, 불일치 해소, 감사에 사용됐다.
   3. 예산의 의미: 검증 비용이 첫 답변 비용보다 훨씬 컸으므로, 모델 호출량만 예산에 넣으면 신뢰 가능한 결과의 실제 비용을 놓친다.

3.2. 설계자·작업자·최적화자가 반복 루프를 구성한다

1. 서로 다른 역할의 모델을 분리한다

   1. 설계자(designer): 데이터 작업을 하위 단계와 파이프라인 설계로 나눈다.
   2. 작업자(worker): 정의된 개별 변환과 판정 작업을 수행한다.
   3. 최적화자(optimizer): 측정 결과에 따라 파이프라인의 구성과 비용·속도를 조정한다.

2. 후보 설계는 알려진 표본과 예산 안에서 비교한다

   1. 반복 실험: 고정된 예산으로 작은 파일럿을 돌려 서로 다른 설계의 품질과 비용을 비교한다.
   2. 반복 규모: Ohio 작업은 10일 동안 열두 가지가 넘는 설계를 시도한 것으로 요약됐다.
   3. 측정 목표: 속도와 비용만이 아니라 정확도까지 함께 비교해야 최적화가 의미를 갖는다.

4. 모델의 사전 가정이 만드는 오류와 검증 방법

4.1. 기본 집계가 정상이어도 중요한 값은 틀릴 수 있다

1. 표기 차이가 15,658건의 분류를 바꿨다

   1. 원천 표기: 파일은 현물 기부를 “In-Kind”로 표기했다.
   2. 모델의 기대: 파이프라인은 “in_kind”라는 표기만 찾았다.
   3. 오류 결과: 표기 차이를 같은 뜻으로 연결하지 못해 현물 기부 15,658건을 일반 금전 기부로 분류했다.

2. 예상 밖 날짜 형식이 날짜 대부분을 지웠다

   1. 지원 범위: 파이프라인은 날짜 형식 네 가지를 처리하도록 만들어졌다.
   2. 실제 형식: 원천 파일에는 다섯 번째 형식이 들어 있었다.
   3. 오류 결과: 날짜의 99.4%가 빈 값으로 바뀌었지만 행 수와 달러 합계는 맞아 기본 점검을 통과했다.

3. 마이너스 부호가 사라져 대출 규모가 뒤집혔다

   1. 입력 의미: 대출의 음수 부호는 순부채를 계산하는 데 필요했다.
   2. 모델의 보정: 여러 실행에서 마이너스가 불필요하다고 판단해 절댓값으로 저장했다.
   3. 금액 왜곡: 순액 78만 4천 달러가 530만 달러의 부채로 바뀌었고, 다른 모델들도 같은 잘못된 결과에 동의했다.

4.2. 독립 모델 비교는 검토 대상을 좁히지만 만능 증명은 아니다

1. 서로 다른 모델 계열의 결과를 비교한다

   1. 검증 표본: 200개 보류(held-out) 가족 사례에서 두 모델 계열을 대조했다.
   2. 일치 결과: 두 모델은 194개 사례에서 일치했고, 그 일치 항목에서는 공동 오류가 발견되지 않았다.
   3. 사람의 검토 범위: 나머지 여섯 개 불일치 사례에 검토를 집중할 수 있었다.

2. 합의보다 독립성과 표본 조건을 확인한다

   1. 공유 편향: 모델이 같은 데이터와 유사한 가정을 공유하면 같은 잘못을 반복할 수 있다.
   2. 표본 한계: 200개 사례에서 얻은 결과는 유용한 신호이지, 다른 데이터에도 오류가 절대 없다는 법칙은 아니다.
   3. 검토 효율: 전량을 사람이 재검토하는 대신 독립 검증이 찾아낸 불일치에 우선순위를 둘 수 있다.

3. 행 수와 총액 외에 의미 보존을 검사한다

   1. 정밀 검사: 부호, 레이블, 날짜 파싱, 결측 비율처럼 의사결정에 중요한 필드를 별도로 비교한다.
   2. 전후 차이(diff): 에이전트 작업 전후 데이터의 값을 직접 대조하면 조용한 변환 오류를 발견할 수 있다.
   3. 감사 흔적: 오류가 생긴 단계와 입력·출력을 따라갈 수 있도록 각 변환의 증거를 남긴다.

5. 실패 정의를 먼저 세우고 최적화를 허용한다

5.1. 여섯 단계가 안전한 자동 최적화 루프를 만든다

1. 작업을 명세하고 사례와 타입이 있는 질문으로 쪼갠다

   1. 명확한 단위: 파이프라인이 처리할 사례와 각 단계의 입력·출력을 정의한다.
   2. 타입 질문: 각 하위 작업이 답해야 하는 질문과 요구되는 자료형을 명시한다.

2. 실패가 무엇인지 정하고 수작업 기준선을 만든다

   1. 실패 표면(failure surface): 어떤 값과 판단이 틀리면 실패인지 사전에 정의한다.
   2. 기준선(baseline): 사람이 직접 확인한 소규모 표본으로 자동화 결과를 비교할 기준을 만든다.
   3. 핵심 조건: 실패 정의가 빠지면 최적화가 잘못된 답을 더 빠르고 싸게 만드는 방향으로 진행될 수 있다.

3. 고정된 비용으로 작은 파일럿을 비교한다

   1. 예산 제한: 후보 아키텍처를 무제한 확장하기 전에 파일럿 한도를 정한다.
   2. 증거 기반 선택: 성능과 비용을 기준선에 대조한 뒤 다음 단계로 넘긴다.

4. 통과한 검사를 코드로 바꿔 에이전트 사이에 실행한다

   1. 반복 검증: 사람이 발견한 오류 유형을 재현 가능한 검사로 만들고 다음 실행마다 적용한다.
   2. 단계별 확인: 전체 작업이 끝난 뒤 한 번만 확인하지 않고 변환 단계 사이에서 점검한다.

5. 알려진 결과를 유지하면서 더 싸고 빠른 구성요소를 시험한다

   1. 대체 실험: 더 저렴하거나 빠른 모델·단계를 바꿔 끼운다.
   2. 동일 기준 비교: 변경 결과를 보류 사례와 기존 기준선에 대조한다.

6. 배포 후에도 근거를 보존하며 개선한다

   1. 운영 중 학습: 새 오류와 예외를 다음 검사와 작업 설계에 반영한다.
   2. 독립 검증 조각: 확인된 작업 세그먼트를 나누어 두면 변경을 검토하고 필요할 때 되돌리기 쉽다.

5.2. 최적화 목표와 실행 기반을 함께 제한한다

1. 비용·속도·정확도 사이의 Pareto 균형을 다룬다

   1. 목표 간 충돌: 가장 빠른 설계가 가장 정확하거나 가장 싼 설계와 같지 않을 수 있다.
   2. 최적화의 순서: 실패 기준과 신뢰 가능한 실행 표면을 먼저 마련한 뒤 균형점을 찾는다.

2. 자기 최적화가 작동할 네 가지 기반을 갖춘다

   1. 안정적 실행 표면: 반복 실험에서 동일 조건으로 파이프라인을 실행할 수 있어야 한다.
   2. 제한된 예산: 에이전트가 후보를 무한히 시험하지 않도록 비용 경계를 둔다.
   3. 재사용 가능한 방법: 검증된 도구와 체크를 다른 실행에서도 적용할 수 있어야 한다.
   4. 명시적 실패 기준: 성공과 실패를 판정할 수 있는 표면이 있어야 최적화 방향을 평가할 수 있다.

주요 발언·논점 모음

• 범용 온톨로지를 먼저 만드는 대신 결정에 필요한 구조를 그 결정이 나타나는 시점에 구성한다.
• 최초 답변을 생성하는 비용보다 그 답변을 믿어도 되는지 확인하는 비용이 더 클 수 있다.
• 여러 모델이 같은 답을 내더라도 그 합의가 공통 가정에 기대고 있으면 오류가 남을 수 있다.
• 자동화의 최적화는 무엇이 실패인지 정의하고 확인 가능한 기준선을 세운 뒤에 시작한다.

핵심 데이터 & 수치

• 203,317건: 10일 동안 라벨링한 Ohio 선거자금 기부자 사례 규모다.
• 약 10일: 대규모 기부자 사례의 처리 기간이다.
• 795달러 / 800달러: 과거 10,000달러로 추산한 작업의 실제 비용과 설정 예산이다.
• 128달러: 최초 답변 생성 비용이다.
• 545달러: 2차 의견·불일치 해결·감사에 사용된 비용이다.
• 15,658건: “In-Kind”와 “in_kind”의 표기 차이로 현물 기부 분류가 틀린 사례다.
• 99.4%: 다섯 번째 날짜 형식을 처리하지 못해 비어 버린 날짜의 비율이다.
• 78만 4천 달러 → 530만 달러: 마이너스 부호 제거로 순 대출액이 부채 규모로 왜곡된 사례다.
• 200건 중 194건 일치: 두 모델 계열의 보류 표본 비교 결과이며 나머지 6건은 불일치 검토 대상이었다.
• 세 가지 아키텍처, 열두 가지 초과 설계: 소규모 비교와 10일간의 반복 실험에서 다룬 후보 규모다.

결론 및 시사점

1. 데이터 통합은 모든 의미를 미리 하나로 합치는 대신 실제 의사결정이 내려지는 지점에서 필요한 구조를 구성해야 한다.
2. 변환 결과에는 출처, 모델의 해석, 확인 범위와 검사 결과를 함께 보존해야 다음 작업에서 신뢰와 재사용이 가능하다.
3. 자동화 예산은 첫 답변 생성비만 세지 말고 독립 검증·불일치 해결·감사 비용을 별도로 편성해야 한다.
4. 배포 전에는 날짜 형식, 레이블, 부호, 결측률처럼 총 행 수와 합계만으로 보이지 않는 실패를 검사해야 한다.
5. 모델 간 불일치는 사람의 검토를 집중시키는 신호로 활용하되, 모델의 합의가 오류 부재를 보증한다고 간주하지 않아야 한다.
6. 실패 정의와 기준선이 마련되기 전에는 모델이 파이프라인을 자율 최적화하도록 두지 않아야 한다.

자료 상태 및 참고 출처

요청된 한국어·영어 자동 자막 다운로드는 YouTube의 HTTP 429 응답으로 실패했고, 원본 오디오 다운로드도 HTTP 403으로 차단됐다. 따라서 세부 내용은 원본 발표의 공개 설명과 발표를 재구성한 공개 글을 대조해 정리했으며, 자막을 직접 대조하지 못한 표현·전개가 있을 수 있다.

• 원본 발표 제목·발행 정보와 타임스탬프별 개요: AI Engineer 발표 페이지
• 발표 요약 및 타임스탬프: daily.dev 발표 요약
• 개념과 Ohio 사례의 재구성: Your Data Model Should Wait for the Question
• 비용·오류 사례의 추가 요약: Southbridge says ontologies must be just in time