온톨로지의 속성, 관계와 보안 구조

온톨로지(Ontology)의 객체 유형(Object type)과 속성(Property), 링크 유형(Link type)을 구성할 때에는 사실을 어디에 보관할지, 무엇을 계산할지와 누가 볼 수 있는지를 함께 정합니다.

정규화와 파생 값

같은 값을 여러 객체에 복사하면 원래 값이 바뀔 때 모든 사본을 갱신해야 합니다. 사실을 의미상 적합한 객체 한곳에 저장하고, 연결된 값을 편리하게 조회할 때에는 파생 속성(Derived property)을 검토합니다.

값의 성격	선택 기준	예시
미리 계산할 값	같은 객체의 안정적인 입력이거나 같은 파이프라인에서만 갱신하는 값	firstName과 lastName을 같은 수집 파이프라인에서 관리한다면 fullName을 미리 계산합니다. 조회 때 같은 문자열 계산을 반복하지 않습니다.
동적으로 계산할 값	연결 객체 또는 액션, 자동화와 다른 온톨로지 동작으로 바뀌는 값에 의존	directReportCount는 직원의 입사, 퇴사와 재배치 후 현재 연결된 Employee 수를 조회 시 계산합니다.

액션으로 바뀌는 값에서 미리 계산한 결과를 유지하려면 그 결과에 영향을 주는 모든 액션이 갱신을 수행해야 합니다. 하나라도 누락하면 불일치가 남습니다.

Manager의 directReportCount를 수동 정수로 두거나 Employee에 managerName을 복사하면 직원 연결이나 관리자 이름이 바뀔 때 값이 낡을 수 있습니다. Manager와 Employee의 실제 관계를 저장하고 필요한 수 및 이름을 그 관계에서 읽는 구성을 검토합니다.

규모와 성능

파생 속성은 실행 시 계산합니다. 조회 대상이 대략 1만 객체 미만인 낮거나 중간 규모에서는 많은 업무에 적합합니다. 대략 1만을 넘는 조회에서는 집계 및 질의 경로의 비용으로 지연이 커질 수 있습니다. 이 수치는 설계 판단의 경험적 구간이며 플랫폼의 일률적인 최대 객체 수는 아닙니다.

규모가 커지면 실제 집계 및 질의 성능을 관찰합니다. 필요한 경우 일부 값을 비정규화할 수 있지만 기본 선택으로 삼지 않습니다. 복사 이유, 기준 원천과 모든 갱신 경로의 동기화 전략을 기록합니다.

구조체로 관련 값 묶기

구조체(Struct)는 의미상 한 값에 속하는 여러 필드를 묶습니다. 주소의 거리, 도시와 우편번호, 좌표와 고도 또는 모델 출력과 출처 및 신뢰도처럼 함께 쓰는 값을 표현할 때 사용합니다.

여러 값 중 대표로 노출할 값을 정하는 리듀서(Reducer)와 대표 필드(Main field)를 사용할 수 있습니다. 예를 들어 여러 전화번호에서 주번호를 노출하거나 여러 주소 중 최근 점유한 주소를 선택하는 경우입니다.

addressStreet, addressCity, addressState, addressPostalCode, addressCountry, addressGeopoint, addressLastOccupied, addressDatasource, addressLlmConfidence와 addressLlmReasoning을 각각 독립 속성으로 두기보다 address 구조체 배열에 묶을 수 있습니다.

구조체 필드	역할
street, city, state, postalCode, country	주소의 대표 필드로 지정할 수 있습니다.
geopoint	주소의 지리 좌표입니다.
lastOccupied	대표 주소를 선택할 때 정렬 기준으로 사용할 수 있습니다.
datasource	값의 출처입니다.
llmConfidence	모델이 제공한 신뢰도 관련 값입니다.
llmReasoning	모델이 출력한 설명입니다.

구조체는 값과 함께 출처, 신뢰도와 시각을 보관할 수 있습니다. 대표 필드를 하나 이상 지정하면 인터페이스와 질의에서 단순 속성 또는 필요한 필드만 가진 하위 구조처럼 다룰 수 있습니다. 리듀서는 여러 값 중 업무에 필요한 대표 값을 노출합니다.

필드를 묶기 전에 실제로 한 의미를 가지며 함께 쓰는지 확인합니다. 이름과 자료형을 명시하고 대표 필드 및 여러 값의 선택 규칙을 구성합니다. AI 결과의 설명과 출처도 결과와 같은 구조에 두면 관련 메타데이터가 흩어지지 않습니다.

인터페이스의 사용 범위

인터페이스(Interface)는 여러 유형이 구현하는 공통 속성, 관계와 동작의 계약입니다. 공통 계약을 대상으로 업무를 구성하면 같은 로직을 유형마다 반복할 필요가 줄어듭니다.

필요	구성 예
공통 속성 및 점검	Inspectable의 lastInspectionDate와 inspectionStatus를 Vehicle, Equipment와 Facility가 구현합니다.
공통 업무	SchedulableResource에 맞춘 예약 업무를 경기장, 회의실과 차량에 적용합니다.
분류와 탐색	MilitaryAsset을 Aircraft, Vessel과 GroundVehicle이 구현합니다.
여러 단계의 추상화	SchedulableResource가 Trackable을 확장하고 예약 관련 속성을 추가합니다.

점검 예에서는 유형별 Schedule Vehicle Inspection, Schedule Equipment Inspection과 Schedule Facility Inspection을 각각 복사하기보다 공통 점검 계약에 맞춘 동작을 검토합니다. 구체 유형은 자신의 make, model, mileage, serialNumber, warrantyExpiry, address 또는 capacity 같은 속성을 따로 유지합니다.

플랫폼 지원 범위가 충분하면 인터페이스를 직접 대상으로 사용합니다. 특정 앱이나 SDK에서 아직 지원하지 않는 경우에는 공통 인터페이스 정의를 유지하되 해당 업무를 실제 유형별로 구성할 수 있습니다. 지원이 추가되면 이 구현을 통합할 수 있도록 범위를 기록합니다. 인터페이스를 정의했다는 이유만으로 모든 앱과 연산이 즉시 지원되는 것은 아닙니다.

관계의 정보와 객체 기반 링크

링크(Link)는 실제 업무 관계를 설명해야 합니다. 환자가 방문한 시설, 직원의 소속 팀, 작업 지시에 사용한 장비처럼 어느 질문에 답하는 관계인지 정합니다. 같은 외래 키가 있다는 사실만으로 의미 없는 링크를 만들지 않습니다.

관계	선택
별도 관계 메타데이터가 없음	Employee와 Department 같은 직접 링크를 사용합니다.
관계마다 날짜, 역할, 상태나 배정량이 있음	객체 기반 링크(Object-backed link)를 사용하여 관계 정보를 별도 객체에 둡니다.

직원과 Venture의 배정에는 Venture Staffing 같은 객체를 두고 role, startDate, allocationPercentage와 status를 저장할 수 있습니다. 직원에게 ventureRole과 ventureStartDate만 두면 여러 Venture에 참여할 때 어떤 배정의 값인지 모호해집니다.

업무가 관계의 존재만 필요하면 Employee에서 Venture로 직접 탐색하는 보기를, 배정의 세부 정보가 필요하면 중간 Staffing 객체를 거치는 보기를 사용합니다. 각 방향의 링크 이름도 그 방향에서 읽히는 의미를 나타내야 합니다.

이름 규칙

이름은 사람과 에이전트가 실제 업무 용어로 찾을 수 있어야 합니다. 날짜, 상태, 식별자와 링크의 규칙을 시작 전에 합의하고 기존 온톨로지의 관례를 따릅니다.

대상	권장 예	피할 모호성
객체 유형	Patient, WorkOrder, FlightSegment	Data, Item, Record처럼 실체를 알기 어려운 이름
속성	age, status, lastInspectionDate	dtLastInspMod, nVAL01, fieldX 같은 구현 약어
링크	직원 쪽 department, 부서 쪽 employees	relatedItems, link1 같은 불명확한 관계
날짜	createdDate, updatedDate, effectiveDate	같은 의미에 createdDate와 dateOfCreation을 혼용
의미가 여러 개인 값	monetaryValue, quantityOnHand, riskScore	뜻을 구분하지 않은 value, quantity, score

짧은 이름도 문맥에서 자명하면 사용할 수 있습니다. 여러 의미가 가능한 단어에는 무엇의 값인지, 어떤 날짜인지가 드러나도록 이름을 붙입니다. 관계도 Product와 Supplier, Employee와 Supervisor처럼 무엇으로 연결되는지 표현합니다.

최종 사용자에게 이름을 검토받고 분석 연습에서 어떤 용어를 검색하며 어떤 관계를 예상하는지 관찰합니다.

보안 경계

최소 권한 원칙에 따라 업무 의미로 접근 조건을 정합니다. 누가 어떤 객체와 속성을 볼 수 있는지 조직의 역할과 관계로 설명할 수 있어야 합니다.

수준	제어 대상	가상 의료 데이터 예
행 수준(Row-level)	조회할 수 있는 객체	VIP 환자는 senior staff로 제한합니다.
열 수준(Column-level)	조회 가능한 객체의 속성	clinicalNotes는 care team으로 제한합니다.
셀 수준(Cell-level)	객체 및 속성 조건의 교집합	VIP 환자의 clinicalNotes는 두 조건을 모두 충족해야 볼 수 있습니다.

PublicPatient와 RestrictedPatient를 별도 유형으로 복사하면 name, dob와 diagnosis 정의가 서로 달라질 수 있습니다. 하나의 Patient 유형에서 diagnosis 및 clinicalNotes는 care team, mentalHealthRecords는 psychiatry team 같은 속성 정책으로 구분하고, VIP 객체에는 별도 행 조건을 적용하는 방식을 검토합니다. 이 예시는 추가 접근 조건의 구조이며 기본 리소스 권한을 모두 공개한다는 뜻은 아닙니다.

초기에는 제한적으로 구성한 뒤 필요에 맞춰 범위를 넓힙니다. 지역 관리자의 담당 지역이나 진료 팀의 대상 환자처럼 업무 경계를 관계와 정책으로 표현합니다. 앱 코드에 흩어진 필터로 보안 정책을 대신하지 않습니다.

새 객체 유형, 링크와 속성을 추가할 때에도 보호 대상의 접근 조건이 유지되는지 확인합니다. 접근 제어가 누가 사용할 수 있는지를 정한다면, 개인정보와 시민적 자유 관점에서는 그 업무가 왜 해당 데이터를 필요로 하며 더 적은 데이터로 수행할 수 있는지도 검토합니다.

팔란티어 플랫폼 한국어 해설