온톨로지 설계의 반복되는 문제
온톨로지(Ontology)의 객체 유형(Object type), 속성(Property)과 링크(Link)가 원천 시스템이나 조직의 임시 구조를 그대로 닮으면 사용자는 실제 업무 관계를 찾기 어려워집니다. 아래 패턴은 설계 검토에서 원인과 영향을 찾는 기준이며 숫자 예시를 플랫폼의 강제 한도로 해석하지 않습니다.
원천 시스템별 분리: System Silos
같은 직원을 HR System Employee, Badge System Employee와 Project Management Employee로 각각 만드는 경우입니다. 서로 다른 팀이 원천을 관리하거나, 결합 방법과 충돌 우선순위를 정하지 못했거나, 모든 시스템 필드를 그대로 남기려 할 때 생깁니다.
사용자는 직원의 전체 정보를 보려고 여러 유형을 찾아야 합니다. 같은 개념의 액션 유형(Action type), 링크 유형(Link type)과 앱을 반복해서 만들고, 서로 다른 값 중 어느 것이 기준인지 판단하기 어려워집니다. 업무 로직 변경도 여러 곳에 반영해야 합니다.
통합할 때에는 먼저 시스템 간 같은 직원을 유일하게 식별할 기준을 정합니다. 직원 ID가 예가 될 수 있습니다. 파이프라인에서 원천을 결합하고 직함은 HR을 기준으로 한다는 식으로 충돌 해결 규칙을 정한 뒤 통합한 기반 데이터셋(Backing dataset)을 Employee에 연결합니다.
불필요한 속성의 누적: The Kitchen Sink
나중에 쓸지도 모른다는 이유로 모든 원천 열을 속성에 옮기는 패턴입니다. 필요한 필드가 불명확하거나 속성으로 노출하지 않으면 데이터를 잃는다고 생각할 때 생깁니다.
CRM의 Customer 예에서 customer_id, customer_name과 email은 업무에 필요할 수 있습니다. 반면 _crm_extracted_at, _crm_received_at, _crm_batched_at, _crm_sequence, _crm_table_version, _crm_internal_record_id 및 last_etl_update_timestamp가 단순 수집 및 디버깅용이라면 모두 고객 속성으로 노출할 필요는 없습니다.
불필요한 속성은 중요한 정보를 가리고 데이터 규모, 연산 및 인덱스 부담을 늘려 검색에도 영향을 줄 수 있습니다.
| 포함할 이유 | 기본적으로 원천에 남길 정보 |
|---|---|
| 고객 ID나 주문 번호 같은 업무 식별 | 파이프라인 메타데이터 |
| 이름과 설명처럼 사람이 읽는 정보 | 업무 의미가 없는 내부 시스템 ID |
| 업무 과정에서 필요한 날짜 | 데이터 엔지니어링에만 필요한 시각 |
| 필터나 액션에 필요한 상태 | 파이프라인 디버깅용 감사 열 |
각 열을 누가 보고, 검색하거나 필터링할지 확인합니다. 기술 메타데이터는 기반 데이터셋에 남겨 디버깅에 사용할 수 있습니다. 명확한 용도 때문에 속성이 필요하지만 드물게 사용한다면 표시 설정으로 기본 보기에서 숨길 수 있습니다. 표시 숨김은 접근 권한의 대체가 아닙니다. 각 속성의 목적과 사용자를 기록합니다.
부서별 복사본: Department Silos
영업, 지원, 재무와 마케팅이 각각 Sales Customer, Support Customer, Billing Customer 및 Marketing Contact를 만들지만 모두 같은 실제 고객을 나타내는 경우입니다. 팀 간 협의가 없거나 각자 자율성과 소유권을 확보하려고 하면서 중복이 생길 수 있습니다.
고객의 기준 정보가 나뉘고 영업, 지원 및 청구 이력을 함께 보는 업무가 어려워집니다. 액션, 링크와 앱을 반복해서 만들며 한쪽의 품질 수정이 다른 복사본에 반영되지 않습니다.
공통 Customer에 salesStatus, supportTier 및 billingAccountId를 두고 Sales Opportunities, Support Tickets와 Invoices 같은 부서별 실체에 연결하는 방식을 검토합니다. 여러 부서의 실무 그룹이 공통 정의를 정하고, 서로 다른 화면이 필요하면 객체 뷰(Object view), Workshop 또는 OSDK 앱을 별도로 구성합니다. 정보 접근 범위는 객체 및 속성 정책과 필요한 제한 뷰(Restricted view) 등의 데이터 접근 설정으로 관리합니다.
여러 실체를 하나로 묶기: The God Object
모두 가치 있는 대상이라는 이유로 차량과 장비, 소프트웨어 라이선스, 부동산, 금융 상품 및 직원을 Asset 하나에 담는 예입니다. 유형 수를 줄이려는 추상화나 계속 추가되는 요구 때문에 생깁니다.
예시 Asset은 150개가 넘는 속성을 가지며 객체 대부분에서 많은 값이 비어 있습니다. value, location과 status의 의미도 assetType이나 category에 따라 달라집니다. 이 숫자는 문제를 설명하는 규모 예시이며 속성 개수 제한이 아닙니다.
같은 화면에서 어떤 종류의 Asset인지 먼저 알아야 하고, 검색 결과에는 관련 없는 대상이 섞입니다. 업무 규칙과 액션은 유형별 분기가 많아져 이해 및 검증이 어려워집니다.
실제로 구분되는 Equipment, Vehicle, Software License, 부동산, Financial Instrument와 Employee 같은 유형으로 나눕니다. 진짜 공통인 특징만 인터페이스(Interface)로 표현합니다. 예를 들어 감가상각이 적용되는 유형은 purchaseDate, purchaseValue와 depreciationSchedule을 가진 Depreciable Asset 계약을 사용할 수 있습니다.
현재 유형이 포함한 실체를 목록화하고 각각의 정의 및 공유 특성을 정한 뒤 기존 객체를 맞는 새 유형으로 이전합니다.
한 도구의 과용: The Golden Hammer
익숙한 도구 하나로 데이터 처리, 사건 반응과 사용자 판단을 모두 구현하는 패턴입니다. 계산 시점을 사용자에게 맡기려 하거나 파이프라인, 자동화와 함수의 차이를 충분히 검토하지 않을 때 생깁니다.
지역별 매출 합계를 보려고 사용자가 매번 Calculate Regional Sales Totals 액션을 누르는 방식, 새 경보의 당직자 배정을 데이터 수집 파이프라인에 섞는 방식, 안정적인 이름 연결을 함수 기반 열로 매번 계산하는 방식이 예입니다.
이렇게 하면 사용자가 불필요한 단계를 수행하고 실행 한도와 성능 제약에 일찍 부딪힐 수 있습니다. 로직의 위치가 흩어져 유지와 원인 조사도 어려워집니다.
| 도구 | 적합한 작업 | 덜 적합한 작업 |
|---|---|---|
| 액션 유형 | 사람이나 에이전트의 결정, 입력에 따른 명시적 변경, 한 개 또는 적은 객체의 즉시 편집 | 대규모 반복 계산 및 일정이나 이벤트 탐지 자체를 대신하는 구현 |
| 배치 파이프라인 | 수집 자료의 정제, 결합, 집계, 보강과 미리 계산할 값 | 객체 한 건의 변화에 대한 즉각적인 반응이나 사람의 판단 입력 |
| 스트리밍 파이프라인 | 원천에서 들어오는 데이터를 계속 처리하여 낮은 지연으로 결과 갱신 | 드문 변경에 충분한 배치를 대체하거나 온톨로지 사건에 업무 반응을 수행 |
| 자동화(Automation) | 객체 생성, 속성 변경이나 일정 조건에 반응하여 액션 또는 알림 실행 | 무거운 데이터 처리, 복잡한 다중 데이터셋 조인이나 사람의 판단 |
| 함수(Function) | 실시간 객체 상태를 사용하는 복잡한 계산과 유효성 검사 | 간단한 원천 열 계산이나 대규모 데이터 배치 처리 |
| 일정(Schedule) | 반복 빌드 및 시간 또는 데이터 이벤트에 따른 갱신 | 개별 객체의 변화에 즉시 반응하는 업무 |
자동화가 액션을 호출할 수 있으므로 액션을 자동 실행할 수 없다는 뜻은 아닙니다. 사건을 감지하는 역할과 실제 변경을 적용하는 역할을 구분합니다.
작업별 적용 예
| 처리할 일 | 검토할 구성 |
|---|---|
| 정기 지역 매출 합계 | 매일 집계하여 Regional Sales Summary를 공급하는 파이프라인 |
| 주소 형식 표준화 | 수집 시 정제 파이프라인 |
| 수량 기준 재고 상태 | 수량 동기화에서 상태를 계산하는 파이프라인 |
| 공식에 따른 위험 점수 | 파이프라인 또는 모델로 계산하여 기반 데이터에 기록 |
| 새 Alert의 당직자 배정 | 객체 생성에 반응하여 Assign Alert 액션을 호출하는 자동화 |
| 객체가 조건을 만족할 때 알림 | 조건을 감시하는 자동화 |
| IoT 새 값을 매분 배치 조회 | 데이터 도착을 계속 처리하는 스트리밍 파이프라인 |
| 안정적인 firstName과 lastName의 fullName | 같은 파이프라인에서 concat 계산 |
| 매분 객체 후속 조치 여부 조회 | 해당 객체 변화에 반응하는 자동화 |
미리 계산한 값의 권고는 관련 입력 변화가 파이프라인에 반영되는 조건을 따릅니다. 액션으로 값이 바뀌는 경우에는 동적 파생 값의 동기화 조건을 검토합니다.
도구를 고르기 전에 사람 판단이 필요한지, 데이터 변환인지 운영 업무인지, 현재 온톨로지 탐색이 필요한 계산인지 확인합니다. 폴링 대신 직접 반응할 사건이 있는지, 원천 데이터의 연속 처리가 필요한지도 구분합니다.
액션의 과도한 분할: Action Sprawl
업무 동작보다 데이터 열 업데이트를 기준으로 액션을 만들면 하나의 작업이 여러 제출로 나뉩니다. 화면을 조금씩 확장하거나 CRUD 동작을 그대로 옮길 때 발생할 수 있습니다.
한 유형에 액션이 10개를 넘거나 항상 연속으로 실행하는 액션이 많고, 이름이 Set 또는 Update와 속성 이름만으로 구성되며 사용자가 단계를 너무 많이 거친다고 느끼면 검토할 신호입니다. 10개는 기술적 한도가 아니며 한 필드를 바꾸는 액션 자체가 잘못된 것은 아닙니다.
직원의 이름, 성, 이메일, 전화번호, 부서와 관리자를 각각 바꾸는 액션에 비슷한 액션을 20개 더하면 목적을 찾기 어렵습니다. 변경 이력도 작은 제출들에 흩어져 한 업무의 이유를 이해하기 어려워집니다.
| 업무 동작 | 함께 다룰 값 및 후속 작업 |
|---|---|
| Update Employee Contact Information | firstName, lastName, email, phone |
| Transfer Employee to New Department | newDepartment, newManager, newLocation, effectiveDate |
| Onboard New Employee | 신규 채용의 필수 정보와 배지 배정 및 장비 요청 등의 후속 업무 |
실제 업무 과정을 정리하여 함께 바뀌는 정보를 한 동작에 묶습니다. 선택 입력은 매개변수(Parameter)로 구성하고 Transfer Employee, Approve Purchase Order 또는 Escalate Support Ticket처럼 업무 목적을 이름에 담습니다. 액션 규칙과 유효성 검사로 업무 제약을 적용합니다.
현재 실체와 버전 복사본의 혼합: The Time Machine
계약을 바꿀 때마다 Contract v1, Contract v2와 Contract v3 객체를 만들거나 Contract 2023, Contract 2024와 Contract 2025 유형을 따로 만드는 예입니다. Vendor와 Department 링크도 복사하면 어떤 계약에 연결해야 하는지 모호해집니다.
변경 수만큼 객체가 늘고 version, revision 또는 isCurrent로 복사본을 구분하며 사용자가 기준 객체를 고르기 어려우면 설계를 검토합니다. 시간별 보고에 필터와 중복 제거가 계속 필요해질 수 있습니다.
현재 계약은 한 객체에 currentValue, currentStatus와 effectiveDate로 표현하고, Contract Amendment 또는 Contract History 같은 연결된 유형에 변경 사건을 기록할 수 있습니다. 개정에는 amendmentDate, previousValue, newValue 및 changeReason을 둘 수 있습니다.
자주 변하는 값은 시계열 속성을 검토하고, 감사 목적의 전체 이력은 기반 데이터셋이나 편집 이력의 보존 조건을 정하여 관리합니다. 현재 실체와 그 실체에 관한 시간별 관측 또는 개정의 정체성을 분리합니다.
의미가 모호한 이름: The Misnomer
원천 시스템의 약어를 그대로 옮기거나 짧은 이름이면 문맥이 설명해 줄 것이라고 가정하는 패턴입니다. 사용자가 속성의 뜻을 계속 묻거나 같은 이름을 여러 개념으로 해석한다면 추가 설명만으로 해결하기 어렵습니다.
| 모호한 표현 | 명확히 할 방향 |
|---|---|
| Item | Product, Sales Order Line Item, Warehouse Inventory Record처럼 실체를 지정합니다. |
| value | monetaryValue, quantityOnHand 또는 riskScore로 의미를 구분합니다. |
| type | productCategory 또는 serviceTier처럼 분류 대상을 지정합니다. |
| date | orderPlacedDate 또는 contractEffectiveDate처럼 사건을 지정합니다. |
| Item과 Related Item의 관계 | Purchasing Customer, Supervisor, Manufacturing Facility처럼 관계의 의미를 표현합니다. |
모호한 이름은 잘못된 분석, 신규 사용자의 학습 부담과 팀별 해석 차이를 만듭니다. 이름을 이해하기 위한 필수 문서에만 의존하면 문서가 낡을 때 문제도 커집니다.
이름 규칙을 미리 정하고 거버넌스 검토에 적용합니다. 각 요소에 의미와 유효한 값을 설명하고 최종 사용자에게 이름이 자연스럽게 읽히는지 확인합니다. 업무 질문 검증으로 개선 후 실제로 더 쉽게 찾을 수 있는지 확인합니다.