고객의 도메인을 모델로 — 유비쿼터스 언어에서 온톨로지까지

들어가며 — 고객의 모델은 대부분 사람 머릿속에 있다
가장 싼 첫걸음 — 유비쿼터스 언어
바운디드 컨텍스트 — 같은 단어가 다른 것을 뜻할 때
명사를 모델링하기 — 엔티티, 값 객체, 애그리게이트
세 단어를 구분하자 — 택소노미 vs 온톨로지 vs 지식 그래프
형식 스택 — RDF, RDFS, OWL, 그리고 schema.org
운영 스택 — 프로퍼티 그래프와 Palantir의 온톨로지
형식 온톨로지는 언제 값을 하는가
실패 모드 — 아름답지만 아무도 안 쓰는 온톨로지
마치며 — 개념이 아니라 질문에서
참고 자료

들어가며 — 고객의 모델은 대부분 사람 머릿속에 있다

Forward Deployed Engineer가 고객사에 처음 도착하면, 가장 값진 자산은 대개 어떤 데이터베이스에도 없습니다. 그것은 20년 현장을 지킨 정비 반장의 머릿속에, 클레임 심사역의 손끝 감각에, 배차 담당자가 "그건 원래 그렇게 안 해요"라고 말할 때의 그 암묵지에 있습니다.

FDE의 핵심 작업 하나는 이 흩어진 암묵지를 팀 전체가 공유하고 기계가 읽을 수 있는 명시적 모델로 바꾸는 것입니다. 이 글은 그 사다리를 아래에서 위로 올라갑니다 — 가장 싸고 값진 첫걸음인 유비쿼터스 언어에서, 형식 온톨로지(RDF/OWL)를 지나, 운영 온톨로지(프로퍼티 그래프와 Palantir식 객체+링크)까지. FDE라는 역할 자체는 FDE 크래프트 심화와 Forward Deployed Engineer 준비기에서 다뤘으니, 여기서는 "도메인을 모델로 바꾸는" 한 가지 기예에 집중합니다.

그리고 처음부터 정직하게 말해 두겠습니다. 온톨로지는 과설계되기 가장 쉬운 산출물이고, 가장 흔한 실패는 아름답지만 아무도 안 쓰는 온톨로지입니다. 이 글의 절반은 그 함정을 피하는 이야기입니다.

가장 싼 첫걸음 — 유비쿼터스 언어

형식 그래프를 그리기 훨씬 전에, 거의 공짜에 가까운 고레버리지 작업이 하나 있습니다. Eric Evans의 Domain-Driven Design이 말하는 유비쿼터스 언어(ubiquitous language) 입니다. Martin Fowler는 이를 "개발자와 사용자 사이에 공통의, 엄밀한 언어를 세우는 실천"이라고 정리합니다.

핵심은 엄밀함입니다. Evans의 표현대로 "소프트웨어는 모호함을 잘 다루지 못하기(software doesn't cope well with ambiguity)" 때문입니다. 현장에서 "설비", "장비", "자산", "호기"가 사람마다 다른 것을 가리키는데 아무도 그 차이를 명시하지 않는다면, 그 혼란은 고스란히 코드로 흘러 들어옵니다.

그래서 FDE의 첫 산출물은 그래프가 아니라 용어집입니다. 도메인 전문가와 마주 앉아 같은 단어를 반복해서 쓰고, 어색하거나 부정확한 지점을 서로 지적하며 다듬는 것. Fowler가 짚듯 도메인 전문가는 뜻이 뭉개지는 용어에 항의하고, 개발자는 설계를 무너뜨릴 모호함을 잡아냅니다. 이 대화 자체가 모델을 검증합니다. 그리고 이 언어는 회의에서, 코드에서, 화면 라벨에서, 데이터 컬럼 이름에서 똑같이 쓰여야 합니다. 번역 계층이 생기는 순간 버그가 태어납니다.

바운디드 컨텍스트 — 같은 단어가 다른 것을 뜻할 때

큰 조직에서 유비쿼터스 언어를 하나로 통일하려는 시도는 대개 실패합니다. Fowler는 이유를 분명히 합니다 — "큰 시스템에서 도메인 모델을 완전히 통일하는 것은 실현 가능하지도, 비용 대비 효과적이지도 않다."

그의 예시가 정확합니다. 어느 전력회사에서 "meter(계량기)"라는 단어는 "조직의 부분마다 미묘하게 다른 것"을 뜻했습니다 — 어떤 팀엔 그리드 접속점, 어떤 팀엔 고객과의 계약 관계, 어떤 팀엔 벽에 붙은 물리 장치. 대화에서는 뭉개고 넘어갈 수 있지만, "정밀한 컴퓨터의 세계에서는" 불가능합니다.

DDD의 답은 억지 통일이 아니라 바운디드 컨텍스트(bounded context) 입니다. 언어가 바뀌는 경계에서 모델을 나누고("언어가 바뀌면 다른 모델이 필요하다"), 컨텍스트 사이는 명시적 매핑으로 잇는 것. FDE에게 이건 사치가 아니라 생존 기술입니다. 정비 부서의 "작업지시"와 회계 부서의 "작업지시"가 다른 것을 뜻한다는 사실을 초반에 못 잡으면, 몇 달 뒤 통합 단계에서 그 대가를 치릅니다.

명사를 모델링하기 — 엔티티, 값 객체, 애그리게이트

언어가 잡히면 명사에 구조를 줍니다. DDD는 세 가지 도구를 줍니다.

엔티티(Entity). 시간에 걸쳐 이어지는 정체성을 가진 것. 펌프 A17은 부품을 갈고 위치를 옮겨도 여전히 같은 펌프입니다. 속성이 같아도 다른 개체라면, 그건 엔티티입니다.
값 객체(Value Object). 정체성 없이 속성으로만 정의되는 것. 금액(100, KRW)이나 GPS 좌표처럼 서로 교체 가능하고 보통 불변입니다. 같은 값이면 같은 것으로 취급합니다.
애그리게이트(Aggregate). Fowler의 정의로 "하나의 단위로 다룰 수 있는 도메인 객체들의 묶음". 주문과 주문 항목이 대표 예입니다. 묶음마다 애그리게이트 루트가 있고, "바깥에서의 참조는 오직 루트로만" 가야 하며, "트랜잭션은 애그리게이트 경계를 넘지 않아야" 합니다.

애그리게이트가 왜 중요하냐면, 그것이 곧 일관성 경계이기 때문입니다. 작업지시-정비항목-사용부품을 한 애그리게이트로 묶으면, 무엇을 원자적으로 바꿔야 하고 무엇이 독립적으로 변해도 되는지가 그대로 드러납니다. 이 결정은 나중에 그래프 스키마와 트랜잭션 설계로 그대로 이어집니다.

세 단어를 구분하자 — 택소노미 vs 온톨로지 vs 지식 그래프

여기서 사람들이 가장 자주 뒤섞습니다. 세 단어는 다른 것을 가리킵니다.

택소노미(taxonomy) 는 계층 분류입니다. is-a 관계 하나로 개념을 트리에 겁니다. 도서 분류나 상품 카테고리가 그렇습니다.
온톨로지(ontology) 는 Ontotext의 정의로 "한 도메인 안의 개념들과 그들 사이에 성립하는 관계를 형식적으로 기술한 것"입니다. 택소노미와 달리 "관계를 표현하고, 여러 개념을 다양한 방식으로 서로 연결"합니다. 즉 계층 하나가 아니라 다방향 관계망입니다.
지식 그래프(knowledge graph) 는 그 온톨로지를 실제 사실에 적용한 결과입니다. Ontotext의 말대로 "온톨로지 데이터 모델을 개별 사실의 집합에 적용해 지식 그래프를 만든다." 온톨로지는 스키마, 지식 그래프는 그 스키마로 채운 실제 데이터입니다.

택소노미 (분류): 계층 하나. is-a 관계만.
  Asset
   +- Pump
   +- Motor

온톨로지 (스키마): 개념 + 관계의 "종류". 다방향.
  Asset      --hasPart-->      Part
  WorkOrder  --services-->     Asset
  Technician --qualifiedFor--> AssetType

지식 그래프 (사실): 온톨로지를 실제 데이터에 적용.
  Pump#A17 --hasPart--> Seal#9        (개별 사실 = 노드 + 엣지)
  WO#4421  --services--> Pump#A17

한 문장으로: 온톨로지가 "구조를 정의해 지식 그래프가 데이터를 담을 무대를 마련한다"(Ontotext). 그러니 "온톨로지를 만들자"와 "지식 그래프를 만들자"는 다른 작업입니다. 전자는 스키마 설계, 후자는 데이터 파이프라인입니다.

형식 스택 — RDF, RDFS, OWL, 그리고 schema.org

형식 온톨로지를 제대로 하려면 시맨틱 웹 표준 세 층을 압니다.

RDF 는 트리플 모델입니다. 모든 사실을 (주어, 술어, 목적어)로 적고, 각 요소를 URI로 전역 식별합니다. "데이터를 그 스키마에서 떼어 내" 여러 출처를 하나로 잇는 게 핵심입니다.
RDFS(RDF Schema) 는 여기에 클래스와 프로퍼티, 그리고 subClassOf 같은 계층을 얹습니다. 즉 택소노미 수준의 스키마입니다.
OWL 은 논리를 더합니다. 클래스, 오브젝트 프로퍼티(개체-개체), 데이터타입 프로퍼티(개체-값), 그리고 개별자(individual). 여기에 논리 생성자(and/or/not로 "Mother = Woman AND Parent"), 카디널리티("hasChild max 4"), 역관계(inverse), 이행성(transitive), 함수성(functional), 대칭성(symmetric), 서로소(disjoint) 선언이 붙습니다. 결정적으로 추론기(reasoner) 가 이 규칙에서 "귀결을 자동으로 계산"해, 사람이 놓칠 사실을 발견합니다.

구체적 실물이 궁금하면 schema.org를 보면 됩니다. 2011년 6월 Bing·Google·Yahoo가 시작하고 그해 11월 Yandex가 합류한 이 어휘는 지금 타입 823개, 프로퍼티 1,529개를 담고 있으며, 웹 페이지에 구조화 데이터를 심는 사실상의 표준입니다. 온톨로지가 학술 장난감이 아니라 매일 검색을 굴리는 인프라라는 증거입니다.

운영 스택 — 프로퍼티 그래프와 Palantir의 온톨로지

FDE가 실제로 배포하는 것은 대개 OWL 파일이 아니라 프로퍼티 그래프입니다. Neo4j식 레이블드 프로퍼티 그래프(LPG)는 네 조각으로 이뤄집니다 — 노드(도메인의 개체), 레이블(노드의 종류 분류), 관계(방향과 타입을 가진 엣지), 그리고 노드와 관계 양쪽에 붙는 프로퍼티(키-값). RDF 트리플과의 결정적 차이가 바로 이것입니다. RDF에서 엣지에 속성을 달려면 우회(reification)가 필요하지만, LPG는 관계가 속성을 그냥 들고 있습니다. 운영 질의와 그래프 탐색에는 이게 훨씬 편합니다.

이 운영 온톨로지의 산업적 정점이 Palantir Foundry의 온톨로지입니다. Palantir 문서는 이를 "조직의 운영 계층"이자 "조직의 디지털 트윈"이라 부르고, 두 부류로 나눕니다.

시맨틱 요소 — 객체 타입(object type), 프로퍼티, 링크 타입(link type). "기존 데이터소스를 온톨로지의 객체·프로퍼티·링크로 매핑"해 조직의 의미를 정의합니다.
키네틱 요소 — 액션 타입(action type), 함수(function), 동적 보안. 여기가 보통의 그래프 DB와 갈리는 지점입니다. 액션 타입은 그래프를 읽을 뿐 아니라 운영자의 결정을 받아 그래프를 바꿉니다.

같은 사실: "작업지시 4421이 펌프 A17을 정비한다"

RDF 트리플:      wo:4421  ex:services  asset:A17 .
프로퍼티 그래프:  (:WorkOrder {id:4421})-[:SERVICES]->(:Asset {id:'A17'})
Palantir 객체:    WorkOrder(4421) --link:services--> Asset(A17)
                  + ActionType: "정비 완료 처리"가 상태를 바꿈

핵심 차이는 동사입니다. 형식 온톨로지는 세계가 어떤지를 서술하고, 운영 온톨로지는 그 위에서 무엇을 할 수 있는지까지 담습니다.

형식 온톨로지는 언제 값을 하는가

그래서 언제 무거운 OWL을 꺼내고, 언제 실용적 프로퍼티 그래프로 충분할까요. 정직한 결정 기준은 이렇습니다.

형식 온톨로지(RDF/OWL)가 값을 하는 경우:

여러 조직·시스템이 같은 의미를 공유해야 할 때. 표준 어휘, 규제 보고, 기관 간 데이터 교환처럼 상호운용성이 본질일 때. schema.org가 웹 전체에서 통하는 이유가 이것입니다.
추론이 실제 값을 만들 때. "이 규칙들에서 논리적으로 무엇이 따라 나오는가"가 업무 질문일 때. 분류가 규칙 기반이고 그 규칙이 자주 바뀌는 규제·컴플라이언스 영역이 대표적입니다.
의미가 오래 살아야 하고 여러 팀이 수년간 공유할 때.

실용적 프로퍼티 그래프로 충분한 경우:

한 조직 안에서, 정해진 질문에 빠르게 답하고 그래프를 탐색·운영하는 게 목적일 때. FDE 프로젝트의 대다수가 여기 속합니다.
관계에 속성이 많고(언제, 누가, 얼마나), 무엇보다 속도가 중요할 때.

대략적 규칙 하나: 추론기가 밤새 돌려서 발견해 줄 새 사실이 실제로 없다면, OWL의 논리 장치는 대부분 비용입니다. 그 경우 스키마 있는 프로퍼티 그래프가 더 정직한 선택입니다.

실패 모드 — 아름답지만 아무도 안 쓰는 온톨로지

이제 이 글에서 가장 중요한 절입니다. 온톨로지의 흔한 실패는 틀린 모델이 아니라 쓰이지 않는 완벽한 모델입니다.

증상은 늘 비슷합니다. 6개월짜리 온톨로지 위원회가 열리고, 세상의 모든 개념을 담은 우아한 클래스 계층이 그려지고, 발표는 박수를 받고, 그 뒤로 아무도 그것을 질의하지 않습니다. 데이터가 연결되지 않았거나, 비즈니스 질문과 무관하거나, 둘 다입니다. 완결성을 위해 모델링했지 사용을 위해 모델링하지 않은 것입니다.

처방은 방향을 뒤집는 것입니다. 개념이 아니라 질문에서 시작하십시오. 화이트보드의 클래스 다이어그램이 아니라, 비즈니스가 오늘 답을 못 얻어 답답해하는 질문 목록에서. 예컨대 — "다음 분기에 고장 확률이 가장 높은 설비는?", "이 작업지시에 지금 투입 가능한 유자격 정비공은?", "창고 X에 어떤 부품을 얼마나 쟁여야 하는가?" 이 질문에 답하는 데 필요한 개체와 관계만 모델링하고, 나머지는 질문이 생길 때까지 미룹니다.

또 하나의 규율: 온톨로지는 실제 데이터에 연결된 채로 자라야 합니다. 데이터에 닿지 않은 온톨로지는 검증되지 않은 가설일 뿐입니다. 유비쿼터스 언어처럼, 온톨로지도 계속 진화하는 살아 있는 산출물이어야 합니다.

마치며 — 개념이 아니라 질문에서

정리하면 이렇습니다. FDE가 도메인을 모델로 바꾸는 일은 사다리입니다. 바닥은 거의 공짜인 유비쿼터스 언어 — 도메인 전문가와 함께 엄밀한 공통 어휘를 세우는 일. 그 위에 바운디드 컨텍스트로 같은 단어의 충돌을 다루고, 엔티티·값 객체·애그리게이트로 명사에 구조와 일관성 경계를 줍니다. 더 위로 올라가면 형식 스택(RDF/RDFS/OWL)과 운영 스택(프로퍼티 그래프, Palantir식 객체+링크+액션)이 있고, 둘 중 무엇을 고를지는 상호운용성과 추론이 실제로 필요한가로 갈립니다.

그리고 가장 정직한 조언 하나. 사다리의 높은 칸을 향해 서두르지 마십시오. 대부분의 값은 맨 아래 두 칸 — 공유 언어와 명확한 경계 — 에서 나옵니다. 온톨로지를 짓고 싶은 유혹이 들 때마다 이렇게 물으십시오. "이 모델은 비즈니스가 실제로 던지는 어떤 질문에 답하는가?" 답이 없다면, 그것이 지금 지어야 할 것은 온톨로지가 아니라는 신호입니다.

여기서 잘 만든 지식 그래프는 그 자체로 끝이 아니라, 다음 단계의 기반이 됩니다. 이 그래프를 LLM 검색의 토대로 쓰는 Graph RAG와 지식 그래프 구축은 프로덕션 RAG 패턴에서 이어집니다.