다른 시스템과 다른 지점
SAP나 대부분의 업무 시스템에서는 마스터 데이터에 ID(코드)와 설명(Description)이 분리되어 있습니다. 자재코드는 “MAT-00123”, 설명은 “스테인리스 볼트 M6″처럼 둘이 따로 존재하고, 코드는 사람이 마음대로 못 바꾸게 관리됩니다.
Palantir Ontology는 이 구조가 없습니다. Object Type이든 Property든, 있는 건 그냥 이름(Name) 하나뿐입니다. 코드 체계로 강제되는 부분이 없다 보니, 이름을 짓는 사람의 감이나 그날의 기분에 따라 결과물이 달라집니다.
왜 시간이 지나면 중구난방이 되는가
처음 몇 개월은 별문제가 없습니다. 만든 사람이 몇 명 안 되고, 서로 뭘 만들었는지 다 기억하기 때문입니다. 문제는 규모가 커지면서 시작됩니다.
- 같은 개념을 두 사람이 각각
Customer와Client로 따로 만든다 - 어떤 Object Type은 영문, 어떤 건 국문, 어떤 건 영문+국문이 뒤섞여 있다
- Property명이 원본 컬럼명을 그대로 붙여넣은 것과 비즈니스 용어로 다시 지은 것이 공존한다
이걸 뒤늦게 통일하려면, 이미 그 이름을 참조하고 있는 Workshop 앱·AIP 로직·Link 관계를 전부 손봐야 합니다. 초기에 표준을 세우는 것보다 몇 배 더 비용이 큽니다.
표준화 전략 — 최소한 이것만은
- 영문 우선, 국문 보조: Object Type/Property 이름은 영문으로 먼저 정의하고, 국문은 설명(Description)에 병기합니다. 이 블로그의 온톨로지 디자이너 도구도 이 원칙을 그대로 따르도록 만들었습니다.
- 표기 규칙을 문서 하나로 고정: PascalCase/camelCase 여부, 약어 허용 기준, 복수형 처리 방식 등을 한 페이지짜리 문서로 만들어 온톨로지를 만드는 모든 사람이 참조하게 합니다.
- 원본 컬럼명이 아니라 업무 용어로:
EKKO_MATNR같은 원본 컬럼명을 그대로 Property명으로 쓰지 않습니다. “이 필드가 업무상 무엇을 의미하는가”를 기준으로 다시 이름을 짓습니다. - 신규 생성 전 검색을 의무화: 새 Object Type을 만들기 전에 비슷한 게 이미 있는지 검색하는 절차를 팀 규칙으로 둡니다. 이미 있는데 몰라서 새로 만드는 중복이 가장 흔한 실패 패턴입니다.
실무에서 느낀 것
이 문제는 온톨로지가 “작을 때”는 절대 드러나지 않습니다. 오브젝트가 열 개, 스무 개일 때는 사람이 기억으로 관리할 수 있습니다. 문제는 백 개, 이백 개를 넘어가면서 시작되는데, 그때는 이미 표준을 되돌리기엔 늦은 시점입니다. 그래서 네이밍 표준은 “나중에 필요해지면 만들자”가 아니라, 온톨로지를 처음 설계하는 그날 같이 정해야 하는 것입니다.