Data Eng Wiki

Closing the Context Gap - Ontology plus LLM for Data Modernization

11 min read

Closing the context gap: An ontology + LLM approach to data modernization

Author: Zichuan Xiong (Thoughtworks) | Source: thoughtworks.com/insights/blog | Published: 2026-07-22

한 줄 요약

온톨로지 없는 LLM은 빠르지만 신뢰할 수 없고, AI 없는 온톨로지는 몇 달의 수작업 분석이 드는 모델링 연습이다 — 둘을 결합하면 전략가가 의도와 공급을 구조로 표현하고 에이전트가 그 사이의 격차를 빠르게, 검증 가능한 형태로 찾아낸다.

핵심 주장/내용

  • 문제: 데이터 현대화 프로그램 다수가 전달에 도달하기 훨씬 전에 멈춘다 — 팀이 자기 데이터가 실제로 무엇을 의미하는지 이해하려고 몇 달을 쓰기 때문이다. 기업 지식의 상당 부분이 시스템에 흩어져 있거나 SME의 머릿속에만 있어서 discovery가 느리고 수작업이며 확장이 어렵다
  • LLM만으로는 부족한 이유: 소스 시스템을 먹이고 유스케이스를 설명하고 격차를 찾으라고 하는 것이 합리적 출발이지만 실제 한계를 드러낸다. 명시적 시맨틱 컨텍스트 없이는 LLM이 스키마·컬럼명·샘플 값에서 관계를 추론해야 하고, 그 추론은 기업 규모에서 일관되게 검증하기 어렵다
  • 온톨로지가 raw 스키마 위에 더하는 것: 온톨로지는 의미의 스키마다 — 존재하는 엔티티, 속성, 그들 사이의 관계, 그것을 지배하는 규칙을 정의한다. 의미가 SME의 머릿속에 암묵적으로 살거나 즉석에서 추론되는 대신 컴퓨터가 도메인을 논리적·일관적·통제된 방식으로 추론할 방법을 준다. 지식 그래프의 스키마 레이어(인스턴스가 채워지기 전)이고, 사람과 기계 모두 읽을 수 있으며 편집·감사 가능하고 소스 컨트롤 하에 둘 수 있다
  • 서로의 약점을 덮는다: 온톨로지는 추론을 명시적 시맨틱에 grounding해 출력을 더 설명 가능하고 일관되고 검증하기 쉽게 만든다. LLM은 온톨로지를 손으로 만들 때 지루한 일을 대신한다 — 소스 시스템 읽기, 동의어 정렬, 조정 제안, 불일치 발견
  • 6단계 에이전틱 루프 (고객 이탈 예측 유스케이스 예시):
    • Step 1: 소스별 온톨로지 컨텍스트 구축 — 각 시스템의 샘플 파일을 주고 AI 에이전트가 엔티티·속성·관계·규칙을 추출. 에이전트는 스키마와 데이터 타입, 외래 키와 조인 패턴, 샘플 값, 주석·문서를 가로질러 신호를 읽고 후보 온톨로지를 추론하며 낮은 신뢰도의 추측은 SME 확인용으로 플래그. 출력은 슬라이드가 아니라 기계 판독 가능한 감사 가능 아티팩트
      • 예: 빌링 시스템(Account -Subscribes to-> Plan, Account -Has email-> EmailAddress)과 지원 티켓 시스템(Customer -Raises-> Ticket, Customer -Has email-> EmailAddress)
    • Step 2: 소스 간 컨텍스트 큐레이션 후 조정 — 여러 온톨로지를 조정하면 중복 identity, 충돌하는 정의, 겹치는 개념 같은 숨어 있던 불일치가 드러난다. 예시에서 세 격차: ① EmailAddress가 두 온톨로지에서 공유됨 ② Account와 Customer가 같은 실세계 엔티티일 수 있음 ③ BillingStatus와 TicketStatus가 Status 타입을 공유. 이 격차들은 유스케이스와 무관하게 존재한다 — 어떤 유스케이스가 신경 쓰든 안 쓰든 landscape에 있고, 바로 그래서 미리 인지시킬 수 있다
    • Step 3: 설계 컨텍스트를 큐레이션된 컨텍스트와 비교 — 소스 시스템은 방정식의 한쪽일 뿐이다. 비즈니스 유스케이스도 필요로 하는 엔티티·관계에 대한 암묵적 이해를 가지고 있고, 그 의도를 온톨로지로 표현하면 둘을 직접 비교할 수 있다. 이탈 예측은 하나의 모호하지 않은 Customer 엔티티를 요구한다 — 상업적 관계(어느 플랜, 결제가 최신인지, 얼마나 오래된 고객인지)와 행동 신호(최근 로그인, 지원 티켓 수, 해결 여부)를 하나의 해소된 identity에 키잉해 시간에 걸쳐 관측
    • Step 4: 격차 식별 — 이제 각 격차가 이 유스케이스에 실제로 무엇을 의미하는지 읽을 수 있다
      • Gap 1: EmailAddress가 빌링과 지원 이력을 한 고객으로 꿰매는 조인 키다. 노이즈가 아니라 모델이 의존하는 조정이고, identity-resolution 요구사항이 된다
      • Gap 2: Account vs Customer가 같은 비즈니스 엔티티인지가 예측 대상과 기저 데이터 모델을 함께 결정한다
      • Gap 3: 타입을 공유한다고 의미를 공유하지 않는다. Status = closed는 티켓에게는 건강한 결과이고 빌링에게는 이탈 신호다. 하나로 뭉개면 라벨이 오염된다 — 같은 타입, 반대 함의라는 semantic-collision 격차
    • Step 5: 조치 — 세 격차가 비용·오너·의존 순서가 다른 세 가지 계획으로 갈라진다: Gap 1은 내부 조정 규칙(email을 해소된 identity 키로 정의하고 조인을 큐레이션 — 빠르고 내부적), Gap 2는 코드 전에 사람의 판단이 필요한 SME의 고객 grain 결정 후 모델링 변경(엔지니어링 비용은 낮음), Gap 3은 공유 타입을 컨텍스트로 한정된 별개 개념으로 명확히 분리(disambiguation). 전략가는 분기를 빌드에 커밋하기 전에 이 모든 것을 안다
      • AI가 격차를 식별·분류할 수 있어도 거버넌스는 필수로 남는다 — 비즈니스 오너와 도메인 전문가가 엔티티 정의를 검증하고 시맨틱 충돌을 해소하고 전사 데이터 모델에 영향을 주는 변경을 승인할 책임이 있다
    • Step 6: 소스 컨텍스트 갱신 후 루프 — 조치를 취하면 기업의 이해 자체가 바뀐다. 컨텍스트는 정적이지 않다 — 스키마가 진화하고 새 시스템이 온라인이 되고 정의가 drift하며 Step 5의 조치 자체가 landscape를 바꾼다. EmailAddress를 공유 identity 키로 해소하고 Account와 Customer를 통합하고 Status를 분리한 것 모두가 큐레이션된 컨텍스트를 변형시키고, 그것이 다음 유스케이스와 다음 에이전트가 재발견하지 않고 상속할 새 baseline이 된다
  • 그래서 컨텍스트는 문서나 일회성 스냅샷이 아니라 landscape 레벨의 서비스로 관리되어야 한다. 정적 설계 문서에 기업 지식을 문서화하는 대신 모든 미래 프로젝트와 AI 에이전트가 재사용할 수 있는 살아있는 버전 관리된 시맨틱 자산으로 유지
  • 요약 arc: 명시적 컨텍스트가 들어가고, 분류되고 추적된 격차가 나오고, 조치가 붙고, 컨텍스트가 갱신되고, landscape가 전보다 더 유능해진 채 남는다. 가장 어렵고 느린 부분은 중간이다 — 흩어지고 암묵적인 의미의 조정된 이해를 구축하고 격차를 손으로 분석하는 것, 그리고 여기서 프로그램이 몇 달과 신뢰를 잃는다. AI를 전사적으로 채택할수록 성공은 단순히 더 많은 데이터가 아니라 시스템에 신뢰할 수 있는 비즈니스 컨텍스트를 제공하는 데 점점 더 달려 있다

관련 위키

Source: 원문 보기

그래프 뷰

백링크