Ontology는 사내 시스템의 데이터를 하나로 만드는 게 아니라, 질문 가능한 세계를 정의한다

사내 Ontology를 구축한다는 말을 들으면, 많은 팀이 먼저 “모든 데이터를 하나의 모델로 옮겨야 하나?”라고 생각한다. 그럴 필요는 없다. Ontology의 핵심은 테이블을 통일하는 일이 아니라, 서로 다른 시스템의 데이터를 같은 질문으로 해석할 수 있게 하는 약속을 만드는 일이다.

고객지원 시스템의 account, CRM의 company, ERP의 sold_to_party는 컬럼명도 식별자도 다를 수 있다. 그런데 운영자는 “이 고객의 장애 문의와 미처리 주문을 함께 보고 싶다”고 묻는다. 이 질문이 가능하려면 시스템별 스키마보다 한 단계 위에서 고객, 주문, 티켓, 계약이 무엇이고 어떻게 이어지는지 정의해야 한다.

---

질문 가능한 세계를 먼저 정의한다

작은 ontology는 거창한 클래스 목록이 아니라, 실제 질문에서 반복되는 명사·관계·제약으로 시작한다.

Organization
├─ hasSupportTicket → SupportTicket
├─ hasOrder → Order
└─ hasContract → Contract

SupportTicket
├─ category: Incident | Inquiry | Request
└─ openedAt: DateTime

Order
└─ fulfilmentStatus: Pending | Processing | Shipped | Completed

이 약속 덕분에 CRM의 company_id, 지원 도구의 requester_org_id, ERP의 customer_no는 각자의 원본 필드를 유지하면서도 모두 Organization에 연결될 수 있다. 미처리도 ERP의 원시 상태를 그대로 덮어쓰는 값이 아니라, Pending과 Processing을 포함한다는 업무 정의로 표현할 수 있다.

Ontology는 “데이터가 실제로 이렇다”라고 주장하는 장부가 아니다. “우리 시스템이 이 데이터를 이런 종류의 질문에 쓸 때, 이 의미로 취급한다”는 계약이다. 그래서 데이터 원본을 바꾸지 않고도 새 시스템을 접속할 수 있고, 정의가 바뀌면 매핑과 규칙을 검토할 위치가 명확해진다.

---

작동 예제: 같은 고객을 억지로 합치지 않아도 된다

세 시스템에 다음 값이 있다고 하자.

CRM      company_id=42, name="A 주식회사"
Support  org_key=acme,  display_name="A Corp."
ERP      customer_no=C-1042, buyer_name="A사"

이를 한 테이블로 병합하고 새 ID를 강제하는 방식은 처음에는 편해 보인다. 그러나 원본의 변경 주기와 책임이 다르면 금세 동기화 문제가 생긴다. Semantic Data Integration 관점에서는 다음처럼 매핑한다.

crm:company/42        rdf:type Organization
support:org/acme      sameAs crm:company/42
erp:customer/C-1042   sameAs crm:company/42
erp:order/7781        rdf:type Order
erp:order/7781        orderedBy erp:customer/C-1042
erp:order/7781        fulfilmentStatus Processing

여기서 sameAs는 무조건 쓰기보다, 동일성 확정 근거와 검토 절차를 갖춰야 한다. 자동 매칭의 신뢰도가 낮다면 possibleMatch로 두고 사람 확인을 거치는 편이 낫다. Ontology는 불확실성을 지우는 도구가 아니라, 불확실성의 종류도 표현할 수 있는 언어다.

이제 “A사의 미처리 주문”이라는 질문은 ERP의 어느 컬럼명을 직접 알아야만 답할 수 있는 질문이 아니다. Organization → hasOrder → Order → fulfilmentStatus라는 의미 경로를 따라 답할 수 있다.

---

좋은 ontology는 작고, 질문에서 자란다

초기 구축에서 흔한 실패는 조직도처럼 거대한 분류 체계를 먼저 만드는 것이다. 실제로는 다음 순서가 더 낫다.

1. 반복되는 운영 질문 10~20개를 모은다.

2. 각 질문의 대상·사건·상태·기간·관계를 표시한다.

3. 서로 다른 시스템의 필드를 그 개념으로 매핑한다.

4. 모호하거나 충돌하는 업무 용어를 규칙으로 합의한다.

5. 새 질문이 생길 때만 ontology를 확장한다.

“장애 문의가 많다” 역시 ontology만으로 완결되지 않는다. Incident라는 분류는 정의할 수 있지만 많다의 임계값은 운영 정책이다. 예를 들어 최근 7일 incident 티켓이 5건 이상이라는 규칙을 정책 레이어로 둬야 한다. 이 구분이 없으면 데이터 모델에 일시적 운영 판단이 섞이고, 기준 변경이 일어날 때마다 구조가 흔들린다.

Ontology가 만든 것은 하나의 중앙 데이터베이스가 아니다. 고객의 말과 사내 시스템이 만나기 위한 공용 어휘와 관계의 지도다. 다음 글에서는 이 지도를 실제 질문으로 실행하는 SPARQL을 보겠다.

---

의미 매핑은 소유권을 바꾸지 않는다

Semantic Data Integration에서 특히 중요한 원칙은 원천 시스템의 책임을 빼앗지 않는 것이다. ERP 팀은 주문 상태의 정의와 정합성을 책임지고, 지원 팀은 티켓 분류를 책임진다. ontology 팀은 각 체계가 운영 질문에서 어떻게 연결되는지와, 경계에서 어떤 변환을 허용하는지를 책임진다.

그래서 매핑에는 반드시 소유자와 버전을 둔다. Processing을 미처리에 포함한다는 규칙이 바뀌면 ERP의 데이터를 고치는 것이 아니라 정책과 매핑의 버전을 갱신한다. 이 덕분에 과거 답변을 재현할 수 있고, 변경의 영향 범위도 질문 단위로 추적할 수 있다.

좋은 출발점은 ‘전사 표준화’가 아니라 한 가지 교차 시스템 질문이다. 고객지원과 주문을 함께 보는 질문 하나가 안정되면, 그때 계약·청구·배송으로 의미 경로를 넓힌다. Ontology는 앞서 만든 것을 부정하지 않고 질문의 범위를 늘리는 방식으로 성장해야 한다.