기업 에이전트에게 “지연된 프로젝트의 고객에게 새 일정을 안내하라”고 요청하면 데이터 조회만으로 일이 끝나지 않는다. 에이전트는 프로젝트와 고객의 관계, 일정 변경 권한, 계약상 통지 조건, 승인 상태와 연락 가능한 담당자를 확인해야 한다. 각 정보의 출처와 유효 시점도 알아야 한다.
온톨지는 업무에 등장하는 개체, 속성, 관계와 제약을 기계가 다룰 수 있는 형태로 정의한다. W3C의 OWL은 복잡한 지식과 관계를 표현하는 표준 언어다. 논리 기반 의미를 사용해 지식의 일관성을 검사하고, 명시한 사실에서 따라오는 관계를 계산할 수 있다. 기업 에이전트에는 이 의미 계층과 실제 API의 권한 검사가 함께 필요하다.
테이블 위에 업무 의미를 연결한다
다음 테이블은 프로젝트의 현재 상태를 저장하기에 충분하다.
| project_id | owner_id | status |
|---|---|---|
| P-17 | U-3 | delayed |
에이전트가 고객 통지까지 실행하려면 다음 정보도 필요하다.
U-3의 유형과 공식 식별자- 프로젝트와 계약, 고객 조직의 연결 관계
delayed판정 규칙과 판정 시각- 일정 변경을 승인할 역할과 현재 승인 상태
- 고객 통지 채널과 계약별 기한
- 각 사실의 원천 시스템과 마지막 갱신 시각
관계형 데이터베이스도 외래키, 제약 조건과 정책 테이블로 이 정보를 표현할 수 있다. 온톨지는 여러 시스템에서 서로 다른 이름으로 쓰는 개념을 하나의 업무 언어로 연결할 때 유용하다. CRM의 account, 결제 시스템의 customer, 계약 시스템의 legal_entity가 어떤 조건에서 같은 조직을 가리키는지 명시할 수 있다.
데이터베이스를 그래프로 옮기는 작업만으로 의미 계층이 생기지는 않는다. 식별 규칙, 관계의 방향, 유효 기간과 출처가 정의돼야 한다. 원천 시스템의 값을 보존하면서 통합 식별자와 관계를 별도 계층에 두면 정정과 추적이 쉬워진다.
작은 객체 모델부터 만든다
첫 모델은 에이전트가 수행할 한 가지 업무만 다룬다. 프로젝트 지연 통지를 예로 들면 다음 객체와 관계로 시작할 수 있다.
Project(P-17)
Customer(C-21)
Contract(K-8)
Employee(U-3)
P-17 serves C-21
P-17 governed_by K-8
P-17 owned_by U-3
K-8 requires_notice_within 2_business_days
각 사실에는 값 외에 운영 메타데이터가 붙는다.
source_system: contract-api
source_record_id: K-8
valid_from: 2026-04-01T00:00:00+09:00
valid_until: null
observed_at: 2026-08-17T09:10:00+09:00
confidence: verified
valid_from은 업무상 사실이 효력을 가진 시점이고 observed_at은 시스템이 그 사실을 읽은 시점이다. 두 시점을 구분하면 늦게 도착한 갱신과 과거 상태를 다룰 수 있다. 추론으로 얻은 관계에는 사용한 규칙과 원본 사실을 함께 기록한다.
동일 인물이나 조직을 합칠 때도 근거가 필요하다. 이름이 같다는 이유로 객체를 병합하면 동명이인과 계열사를 혼동할 수 있다. 공식 고객 번호, 사업자 식별자와 검증된 매핑 테이블을 우선하고, 불확실한 후보는 검토 상태로 둔다.
조회 모델과 실행 권한을 분리한다
Palantir의 Ontology 문서는 객체와 관계에 로직과 행동을 연결하는 구성을 설명한다. 이 접근에서 배울 점은 읽기 가능한 지식과 실행 가능한 행동을 구분하는 것이다. 에이전트가 Project를 읽을 수 있어도 ChangeDeadline을 실행할 권한까지 생기지는 않는다.
Object: Project
Properties: deadline, status, risk_level
Links: owned_by Team, serves Customer
Action: ChangeDeadline
Precondition: approver has schedule_admin role
Required input: project_id, proposed_deadline, reason
Audit: actor, approver, old_value, new_value, timestamp
자연어 요청은 허용된 도구의 구조화된 입력으로 변환한다. 도구 실행 시점에는 API나 정책 엔진이 사용자 신원, 역할, 객체 범위와 승인 상태를 다시 검사한다. 온톨로지에 schedule_admin 관계를 적었다는 사실만으로 보안 통제가 완성되지는 않는다. 실제 데이터 접근 계층이 권한을 강제해야 한다.
실행은 다음 상태를 거치게 만들 수 있다.
proposed -> validated -> approved -> executed -> verified
\-> rejected
각 전이에는 담당 주체와 조건을 둔다. 금전, 외부 발송과 권한 변경은 사람 승인을 요구하고, 실행 뒤 원천 시스템의 값을 다시 읽어 결과를 확인한다. 실패하면 재시도 횟수와 복구 담당자를 감사 로그에 남긴다.
OWL의 추론 규칙을 업무 정책과 혼동하지 않는다
OWL은 개방 세계 가정을 사용한다. 지식베이스에 사실이 없다는 이유만으로 그 사실이 거짓이라고 결론 내리지 않는다. U-3 has_role schedule_admin 문장이 없으면 권한이 없다고 추론되는 구조가 아니다. 접근 제어처럼 기본 거부가 필요한 정책은 별도의 명시적 규칙과 정책 엔진에서 처리해야 한다.
서로 다른 식별자를 자동으로 다른 객체로 간주하지 않는 점도 주의해야 한다. 통합 과정에서 동일성 규칙을 잘못 쓰면 두 고객이 합쳐지거나 한 고객이 중복될 수 있다. OWL 추론은 정의한 공리 안에서 작동한다. 부정확한 정의를 운영 데이터가 자동으로 바로잡아 주지는 않는다.
온톨로지 추론이 잘 맞는 영역은 분류, 관계 일관성 검사와 명시된 규칙에서 파생 사실을 찾는 일이다. 결제 승인, 개인정보 접근과 고객 발송처럼 즉시 강제해야 하는 정책은 트랜잭션 시스템의 검증 로직으로 유지한다.
LLM이 만든 후보는 검토 큐로 보낸다
LLM은 문서와 스키마에서 개체, 관계와 동의어 후보를 뽑는 데 유용하다. 같은 고객을 두 객체로 만들거나, 시간에 따라 바뀌는 관계를 영구 사실로 저장할 수도 있다. 자동 생성 결과는 운영 지식베이스에 바로 쓰지 않고 검토 큐에 넣는다.
검토할 항목은 다음과 같다.
- 개념마다 공식 식별자와 담당 부서가 있는가
- 관계의 방향, 카디널리티와 유효 기간이 명확한가
- 사실의 출처, 갱신 주기와 정정 주체가 있는가
- 추론 결과와 원본 사실을 구분해 저장하는가
- 삭제와 정정 요청이 파생 데이터에 전파되는가
- 권한 변경이 캐시와 검색 인덱스에도 반영되는가
검토자는 이름이 자연스러운지만 보지 않는다. 실제 질문과 행동이 모델에서 올바르게 처리되는지 확인한다. 다음과 같은 역량 질문을 테스트로 관리할 수 있다.
지연 프로젝트와 영향을 받는 계약을 찾을 수 있는가
통지 기한 계산에 사용한 계약 조항을 추적할 수 있는가
현재 일정 변경 승인자를 한 명으로 확정할 수 있는가
권한이 없는 사용자의 실행 요청을 거부하는가
과거 시점의 프로젝트 소유자를 재현할 수 있는가
각 질문에 예상 결과, 허용 오차와 근거 레코드를 붙인다. 스키마나 규칙을 바꿀 때 이 회귀 테스트를 다시 실행한다.
도입은 용어집과 한 개의 행동에서 시작한다
처음부터 전사 지식 그래프를 만들면 개념 합의와 데이터 정리에 시간이 몰린다. 작은 도입은 다음 순서로 진행할 수 있다.
- 한 업무 흐름과 책임자를 정한다.
- 핵심 용어, 식별자와 원천 시스템을 표로 만든다.
- 에이전트가 답해야 할 역량 질문을 10개 안팎으로 쓴다.
- 필요한 객체, 관계와 시간 속성만 모델링한다.
- 읽기 전용 조회로 정확도와 출처 추적을 검증한다.
- 위험이 낮은 행동 한 개에 승인과 감사 로그를 붙인다.
- 오류, 정정 시간과 수동 개입률을 매주 확인한다.
성공 기준도 답변의 자연스러움에서 분리한다. 올바른 객체를 찾은 비율, 근거 레코드 추적률, 권한 거부 정확도, 오래된 사실의 비율과 정정에 걸린 시간을 측정한다. 이 지표가 안정된 뒤 연결할 시스템과 행동을 늘린다.
온톨로지가 과한 경우
데이터 원천이 하나이고 관계가 단순하며 쿼리가 안정적이면 잘 설계된 테이블과 API로 충분하다. 온톨지는 이름을 합의하고 관계를 유지하며 오류를 정정할 운영 책임자를 요구한다. 그래프 데이터베이스를 추가하면 배포, 관찰과 장애 복구 비용도 생긴다.
나는 같은 개념이 여러 시스템에서 다른 이름으로 쓰이고, 에이전트가 여러 데이터와 행동을 연결하며, 권한과 근거를 추적해야 할 때 온톨로지를 검토한다. 초기에는 용어집, 통합 식별자와 명시적인 API 계약만으로 문제를 풀 수 있는지 확인한다. 관계와 규칙이 반복해서 여러 제품에 복제될 때 공통 의미 계층의 편익이 커진다.
기업 에이전트의 품질은 그래프 크기로 결정되지 않는다. 객체와 관계의 정의, 사실의 출처와 유효 시점, 실행 권한과 정정 책임이 분명해야 한다. 한 개의 읽기 흐름과 한 개의 승인된 행동에서 이 조건을 검증하면 온톨로지가 필요한 범위와 유지 비용을 현실적으로 판단할 수 있다.