온톨로지 설계 원칙
온톨로지(Ontology)의 객체 유형(Object type), 속성(Property)과 링크 유형(Link type)은 사람들이 업무를 이해하는 방식에 맞춰야 합니다. 원천 시스템의 구조를 그대로 노출하기보다 실제 대상, 관계와 허용할 업무 동작을 먼저 정의합니다.
설계 시 확인할 항목
- 객체 유형은 부서나 원천 시스템의 표현이 아니라 실제 업무 실체를 나타내게 합니다.
- 모든 속성에 명확한 업무 또는 기술 목적을 둡니다.
- 여러 팀의 관계자를 설계에 참여시켜 같은 개념의 중복을 줄입니다.
- 객체 유형 하나가 구분되는 실체 하나를 표현하도록 범위를 정합니다.
- 사람이나 에이전트의 결정은 액션 유형(Action type), 자동 데이터 변환은 파이프라인처럼 작업에 맞는 도구를 선택합니다.
- 공통 구조는 인터페이스(Interface)로 추상화하여 넓고 빈 값이 많은 유형을 피합니다.
- Ontology Manager에 유형, 속성과 링크의 의미 및 설계 결정을 기록합니다.
- 실제 업무 질문으로 사람이든 에이전트든 필요한 경로를 찾을 수 있는지 검증합니다.
원칙의 우선순위
| 순서 | 원칙 | 판단 기준 |
|---|---|---|
| 1 | 도메인 주도 설계(Domain-driven design) | 업무의 실제 대상과 관계를 표현합니다. |
| 2 | 중복 제거(Do not repeat yourself) | 같은 것을 세 번 구현했다면 공통화할 시점인지 검토합니다. |
| 3 | 확장에는 열고 핵심 변경에는 신중하기 | 검증된 핵심 모델을 안정적으로 유지하고 다른 팀이 확장하도록 합니다. |
| 4 | 깊은 상속보다 조합 | 역할별 인터페이스를 여러 개 구현하여 필요한 기능을 조합합니다. |
원칙이 충돌하면 위쪽 원칙을 우선합니다. 속성이 비슷하다는 이유만으로 의미가 다른 실체를 하나로 합치는 식으로 중복 제거가 도메인 구분을 훼손해서는 안 됩니다.
업무 실체를 먼저 정의
Patient, WorkOrder와 Vessel 같은 의미 있는 대상을 모델링합니다. 링크(Link)는 환자가 시설을 방문했다는 관계처럼 업무의 질문에 답해야 합니다. 데이터베이스 테이블, API 응답이나 스프레드시트 탭 자체를 실체로 취급하지 않습니다.
다음 징후가 있으면 원천 스키마를 그대로 옮겼는지 살펴봅니다.
- 테이블마다 객체 유형을 만들었습니다.
- 원천 열을 검토 없이 모두 속성으로 옮겼습니다.
- lastInspectionDate 대신 dtLastInspMod 같은 시스템 약어를 사용합니다.
- 업무 관계자보다 원천 데이터만 보고 모델을 정의했습니다.
- 한 행에 포함된 여러 실체를 객체 유형 하나로 취급합니다.
예를 들어 order_id, customer_name, customer_email, product_sku와 quantity 열이 있는 CSV는 주문, 고객과 상품을 함께 설명합니다. 단순한 단일 상품 주문 예에서는 다음처럼 구분할 수 있습니다.
| 유형 | 속성과 관계 |
|---|---|
| Order | order_id와 quantity를 가지며 Customer 및 Product로 연결합니다. |
| Customer | name과 email을 가집니다. |
| Product | sku를 가집니다. |
모든 열을 OrderData에 두면 고객을 독립적으로 검색하거나 다른 업무에서 연결하기 어렵습니다. 원천 스키마 변경도 소비자에게 직접 전파되기 쉽고 다른 팀이 재사용하기 어렵습니다. 실제 주문에 여러 품목이 있다면 수량이 속할 실체도 업무 정의에 맞춰 구분해야 합니다.
원천 스키마를 보기 전에 관계자와 중요한 실체를 정합니다. 측정값이나 사건을 나타내는 행은 그 대상의 정체성과 별개일 수 있으므로 실체와 관측을 나눕니다. person.children 및 equipment.lastInspectionDate처럼 사람이 읽어 이해할 이름을 사용한 뒤 데이터를 매핑합니다.
기술적 목적 때문에 비업무 유형이 필요하면 기본 탐색 보기를 정리하도록 Hidden으로 표시할 수 있습니다. 구축자는 여전히 이를 앱에서 사용할 수 있으므로 숨김을 보안 권한의 대체로 취급하지 않습니다.
중복을 공통 계약으로 정리
같은 실체와 같은 동작의 기준 표현을 유지하면 변경을 여러 복사본에 반복하는 일을 줄일 수 있습니다. 비슷한 구조와 링크, 같은 파생 속성(Derived property) 및 액션 로직, 사소한 차이만 있는 업무 복사본이 여러 팀에서 생겼는지 살펴봅니다.
Sales Customer, Support Customer와 Billing Customer가 name, email 및 phone을 반복한다면 두 경우를 구분합니다.
| 상황 | 구성 |
|---|---|
| 같은 고객을 표현 | 하나의 Customer에 공통 정보와 salesStatus, supportTier 및 billingAccountId를 두고 필요한 권한 및 필터를 적용합니다. |
| 실제 구조와 실체가 다름 | name, email과 phone을 가진 CustomerBase 인터페이스를 정의하고 SalesLead, SupportContact 및 BillingAccount 같은 구체 유형이 구현하게 합니다. |
중복은 어느 것이 기준인지 알기 어렵게 하고, 액션과 파생 로직이 서로 달라지거나 한쪽 수정이 누락되는 원인이 됩니다. 구조를 비교하여 같은 유형으로 합칠지 공통 인터페이스를 구현할지 정합니다. 같은 로직은 인터페이스를 대상으로 하는 공유 함수나 액션으로 모읍니다.
같은 구현이 세 번 나타나는 것은 공통화를 검토할 실용적인 신호입니다. 횟수만으로 의미가 다른 유형을 강제로 합치는 규칙은 아닙니다.
핵심 구조를 보호하고 확장
운영에서 검증한 객체 유형, 인터페이스와 업무는 핵심 구조를 안정적으로 유지합니다. 새 요구가 생길 때마다 공통 유형을 바꾸기보다 새 유형, 인터페이스 구현이나 기존 객체를 사용하는 업무를 추가할 수 있는지 봅니다.
예를 들어 Equipment의 serialNumber와 manufacturer는 공통 핵심 정보입니다. 일부 장비에만 필요한 인증 정보를 모두 같은 유형에 추가하면 다른 장비에는 빈 값이 생기고 공통 변경 범위가 넓어집니다.
| 요소 | 예시 구성 |
|---|---|
| Equipment | 기존 핵심 속성을 유지하고 Equipment Certification과 연결합니다. |
| Equipment Certification | certificationAuthority, certificationExpiry, certificationStatus와 lastCertificationAudit를 가집니다. |
| Certifiable 인터페이스 | certificationStatus 및 certificationExpiry라는 공통 인증 능력을 표현합니다. |
먼저 실체에 필수적인 속성과 링크를 정하고 확장 경계를 남깁니다. 새 정보가 핵심 유형에 속하는지, 연결된 확장 유형이나 새 인터페이스 구현 및 구분된 속성 이름 영역에 속하는지 판단합니다. 핵심을 계속 키우면 여러 개념을 담은 거대 유형, 팀 간 수정 충돌과 불명확한 책임이 생길 수 있습니다.
확장할 때에도 보안 경계를 유지해야 합니다. 새 속성이나 관계를 추가하는 과정에서 의도하지 않은 정보 접근 범위가 넓어지지 않도록 검토합니다.
인터페이스로 기능 조합
인터페이스는 여러 개를 구현할 수 있으므로 기능 조합마다 상속 중간 유형을 만드는 방식을 피할 수 있습니다.
Arena에 건물 및 예약 기능이 필요하다면 다음처럼 나눕니다.
| 정의 | 내용 |
|---|---|
| Building 인터페이스 | address와 squareFootage |
| SchedulableResource 인터페이스 | schedulingCalendar와 bookingPolicy |
| Arena | 두 인터페이스를 구현하고 arenaName 및 seatingCapacity를 추가 |
Asset, PhysicalAsset, Building, SchedulableBuilding, Arena로 이어지는 깊은 단일 상속은 다른 조합이 필요할 때마다 중간 유형을 늘립니다. 창고에 예약 기능을 추가하는 경우에도 같은 두 계약을 구현하는 방식이면 새로운 계층을 만들 필요가 줄어듭니다.
Inspectable, Schedulable, Billable과 Depreciable처럼 역할이나 기능에 맞춰 인터페이스를 정합니다. MilitaryAsset을 Aircraft, Vessel과 GroundVehicle이 구현하는 분류 목적의 인터페이스도 탐색에 사용할 수 있습니다. 실제 앱, 함수 및 집계에서 인터페이스를 사용할 수 있는지는 지원 범위를 확인합니다.
공통 기능을 제공하는 유형을 같은 업무에서 사용할 수 있도록 인터페이스를 대상으로 구성합니다. 특정 계층 깊숙한 유형에 업무를 묶으면 재사용이 어려워지고 상위 변경이 여러 하위 유형에 영향을 줄 수 있습니다.
제약과 타협
일정, 기존 시스템, 플랫폼 지원 범위와 사용자 숙련도에 따라 이상적인 구조를 한 번에 만들기 어려울 수 있습니다.
| 판단 | 적용 방식 |
|---|---|
| 현실적인 시작 | 당장 필요한 업무를 동작시키되 개선할 경로를 명확히 합니다. |
| 타협의 명시 | 성능을 위해 값을 복사했다면 기준 값과 동기화 전략 및 규모가 커질 때의 영향을 기록합니다. |
| 점진적 개선 | 한 번에 전체를 바꾸기보다 실제 사용 중인 업무를 유지하며 개선합니다. |
| 중요한 조건 유지 | 이름의 명확성, 의미 구분과 보안 설계는 구현 편의 때문에 미루지 않습니다. |
구조 설계에서 정규화, 구조체와 링크 및 보안의 선택 조건을 확인하고 안티패턴과 업무 검증으로 실제 사용에서 드러나는 문제를 찾습니다.