창고에 물건을 대충 던져 넣으면, 나중에 정작 필요한 걸 찾을 때 창고 전체를 뒤져야 한다 — 온톨로지도 똑같다
온톨로지 설계, 처음부터 잘하는 사람은 없다
온톨로지를 처음 설계할 때는 대개 “일단 데이터부터 넣고 보자”는 식으로 시작한다. 문제는 그렇게 쌓인 Object Type이 나중에 정리가 안 된 창고처럼 되어버린다는 점이다. 뭐가 어디 있는지, 같은 물건이 몇 군데 겹쳐 있는지 아무도 모른다.
Palantir 공식 문서는 이런 실수를 8가지 안티패턴으로 정리해두고 있다.[1] 이 중 “같은 고객을 세 가지 이름으로 부르는 문제”는 이미 다른 글에서 다뤘으니, 여기서는 나머지 실전에서 자주 마주치는 6가지를 정리한다.
실수 1: 뭐든 한 박스에 다 넣는다 — God Object
창고에 “자산”이라고 적힌 박스 하나를 만들어 놓고, 장비도 넣고, 소프트웨어 라이선스도 넣고, 부동산 문서도 넣고, 금융 상품 계약서도 넣는다고 해보자. 박스 하나만 열면 다 나오니 편해 보이지만, 실제로 뭘 찾으려면 박스 전체를 뒤져야 한다.
공식 문서가 드는 예시가 정확히 이거다 — 장비, 소프트웨어 라이선스, 부동산, 금융상품을 전부 하나의 Asset Object Type으로 욱여넣는 경우다.[1] 이게 바로 God Object다. 해결책은 각각을 별도 Object Type으로 쪼개고, 공통으로 필요한 속성(예: “감가상각 대상인가”)은 인터페이스로 묶는 것이다.[1]
실수 2: ETL 부산물까지 다 옮겨 담는다 — Kitchen Sink
창고 정리를 한다면서 이삿짐 상자에 붙어 있던 운송장 라벨, 포장 테이프 조각까지 같이 보관하는 사람은 없다. 그런데 온톨로지에서는 이게 자주 벌어진다. CRM 데이터를 온톨로지로 옮기면서 _crm_extracted_at, _crm_batched_at 같은 ETL 처리 메타데이터까지 그대로 속성으로 끌고 오는 경우다.[1]
이런 필드는 비즈니스 사용자에게 아무 의미가 없다. 원본 시스템의 기술적 흔적일 뿐이다. 공식 문서의 원칙은 명확하다 — 비즈니스 또는 기술적 가치가 분명한 속성만 의도적으로 선별해서 담는다.[1]
실수 3: 망치 하나로 모든 걸 두드린다 — Golden Hammer
정리를 잘하는 사람도 도구를 잘못 쓰면 창고가 엉망이 된다. 못을 박아야 할 곳에 스크루드라이버를 쓰고, 나사를 조여야 할 곳에 망치를 쓰는 식이다. 온톨로지에서는 Action Type과 파이프라인을 헷갈려 쓰는 경우가 여기에 해당한다.
공식 문서는 대량 배치 처리를 Action Type으로 구현하거나, 반대로 사용자가 직접 판단해야 하는 자동 할당 업무를 파이프라인으로 처리하는 걸 예로 든다.[1] 원칙은 이렇다 — 사람이 판단해서 결정을 내리는 일에는 Action Type, 자동화된 대량 변환에는 파이프라인.[1] 도구를 작업 성격에 맞게 골라야 한다.
실수 4: 서랍 하나에 손잡이를 열 개 만든다 — Action Sprawl
서랍 하나 여는데 손잡이가 열 개씩 달려 있으면 오히려 헷갈린다. 온톨로지에서 “직원 이름 업데이트”, “이메일 업데이트”, “부서 업데이트” 액션을 각각 따로 만드는 게 이 경우다.[1]
실제로는 “직원 정보 수정”이라는 하나의 비즈니스 작업 안에 이름·이메일·부서 변경이 같이 일어나는 경우가 대부분이다. 공식 문서의 해법은 관련된 변경사항을 하나의 비즈니스 작업 단위 Action으로 번들링하는 것이다.[1]
실수 5: 옛날 영수증도 창고에 그대로 쌓아둔다 — Time Machine
계약서를 개정할 때마다 v1, v2, v3를 전부 별도의 독립된 물건처럼 창고 선반에 나란히 올려두는 경우가 있다. 공식 문서는 계약의 각 버전을 별도 Object로 만드는 걸 Time Machine 안티패턴으로 부른다.[1]
해결책은 계약을 하나의 Object로 유지하면서, 이력은 연결된 별도 이력 Object Type이나 시계열 속성으로 관리하는 것이다.[1] 버전 자체가 새로운 엔티티인 것처럼 다루면, “지금 유효한 계약이 뭐냐”는 질문에 답하기 위해 매번 최신 버전을 찾아 헤매야 한다.
실수 6: 라벨에 “물건”이라고만 써 붙인다 — The Misnomer
창고 선반에 “물건”, “것”, “종류”라고만 적어놓으면 나중에 아무도 뭐가 들었는지 모른다. 온톨로지에서 Item, value, type, date 같은 모호한 이름을 쓰는 경우가 이거다.[1] 공식 문서는 Product, monetaryValue, orderPlacedDate처럼 구체적이고 사람이 읽어서 바로 이해되는 이름을 쓰라고 권한다.[1]
그래서 창고를 어떻게 정리할 것인가 — 4가지 원칙
공식 문서는 위 실수들을 피하기 위한 설계 원칙을 우선순위 순으로 정리해두고 있다.[2]
- 현실을 모델링하지, 원본 데이터를 모델링하지 않는다. CSV 한 줄을 그대로 옮기는 대신(“OrderData”에 고객명·이메일·상품코드가 뒤섞인 형태), 주문·고객·상품을 별도 엔티티로 나눈다.[2]
- 세 번째 반복되면 리팩토링한다. 같은 구조를 두 번은 우연일 수 있지만, 세 번째부터는 패턴이다 — 즉시 통합하거나 인터페이스로 추상화한다.[2]
- 핵심은 보호하고, 확장은 열어둔다. 기존 Object Type에 새 속성을 계속 추가하는 대신, 별도 연결 Object Type이나 인터페이스로 확장한다. 예를 들어 장비에 인증 정보가 필요하면
Equipment를 건드리지 않고Equipment Certification을 새로 연결한다.[2] - 깊은 상속 대신 조합을 쓴다. 하나의 대상이 여러 성격(건물이면서 동시에 예약 가능한 자원인 경우 등)을 가질 때, 상속 체인을 깊게 파지 말고
Building,SchedulableResource같은 인터페이스를 여러 개 조합한다.[2]
공식 문서는 이 원칙들이 “절대 법칙이 아니라 가이드”라고도 명시한다.[2] 마감이 급하면 일단 합리적인 선에서 구현하고 개선 계획을 남기는 것도 괜찮다 — 다만 명명, 의미의 명확성, 보안만큼은 타협하지 말라고 못박는다.[2]
FAQ
Q. 이 안티패턴들을 지금 당장 다 고쳐야 하나요? 아닙니다. 공식 문서도 트레이드오프를 인정합니다. 성능이나 마감 때문에 일부 타협은 가능하지만, 명명 규칙과 의미의 명확성만큼은 나중에 고치기가 훨씬 어려우니 초기에 신경 쓰는 게 낫습니다.
Q. God Object인지 아닌지 어떻게 판단하나요? “이 Object Type이 현실에서 서로 다른 두 가지 이상의 것을 가리키고 있는가”를 자문해보면 됩니다. 장비와 소프트웨어 라이선스를 둘 다 “Asset”이라 부르고 있다면 이미 God Object입니다.
Q. Kitchen Sink와 필요한 메타데이터는 어떻게 구분하나요? 비즈니스 사용자에게 그 속성의 의미를 설명할 수 있는지가 기준입니다. “이 값이 언제 배치 처리됐는지”는 엔지니어에게나 의미 있지, 현업 담당자에게는 의미가 없습니다.
참고자료
[1] Palantir, Ontology design: Anti-patterns, Foundry 공식 문서.
[2] Palantir, Ontology design: Best practices, Foundry 공식 문서.