팔란티어 온톨로지로 보는 AI 환각 방지 3원칙
동료가 “AI 에이전트를 설계할 때는 상황과 액션을 명확히 정의해야 한다”고 말한 적이 있습니다. 이 말은 사실 팔란티어(Palantir)가 자사 AI 플랫폼 AIP에서 환각(Hallucination)을 줄이기 위해 쓰는 Ontology(온톨로지) 구조에서 나온 개념입니다.
이번 글에서는 온톨로지가 무엇인지, 팔란티어가 이 구조로 어떻게 환각을 줄이는지, 그리고 그 원칙을 우리가 만드는 AI 에이전트/스킬 설계에 어떻게 적용할 수 있는지 정리합니다.
1. 온톨로지(Ontology)란
1-1. 사전적 의미와 AI 맥락에서의 쓰임
온톨로지는 원래 철학에서 “존재론”을 뜻하는 단어지만, 컴퓨터 과학에서는 어떤 도메인(조직, 산업, 시스템)에 존재하는 개념들과 그 관계를 형식적으로 정의한 모델을 가리킵니다. “우리 회사에 어떤 대상들이 있고, 그것들이 서로 어떻게 연결되어 있는가”를 코드와 데이터로 표현한 것이라고 보면 됩니다.
1-2. 왜 지금 이 개념이 다시 주목받는가
LLM 기반 에이전트가 실제 업무 시스템에 연결되기 시작하면서, “지금 회사의 실제 상태가 무엇인지” LLM이 정확히 알아야 하는 상황이 늘었습니다. LLM은 학습 데이터에 기반한 확률적 다음 토큰 예측기일 뿐이라, 회사 내부 데이터나 실시간 상태는 원래 알 수 없습니다. 팔란티어는 이 문제를 풀기 위해 온톨로지를 LLM과 실제 조직 데이터 사이의 연결 계층으로 활용합니다.
2. 팔란티어 Ontology의 3층 구조
팔란티어 AIP의 온톨로지는 공식 문서 기준으로 세 계층으로 구성됩니다.
2-1. 데이터 레이어 — Object
조직의 실제 데이터를 객체(Object)로 모델링합니다. 유통센터, 트럭, 재고, 배송건 같은 실체가 각각 속성(Property)과 다른 객체와의 관계(Link)를 가진 객체로 존재합니다. 예를 들어 “트럭 A”라는 객체는 현재 위치, 적재량 같은 속성을 갖고, “배송건 B”라는 객체와 링크로 연결됩니다.
2-2. 로직 레이어 — Function
계산이나 판단이 필요한 부분은 LLM에게 맡기지 않고 결정론적 함수(Function)로 처리합니다. 거리 계산, 재고 최적화 같은 로직은 코드로 짜인 함수가 담당하고, LLM은 이 함수를 호출해서 결과만 받아옵니다.
2-3. 액션 레이어 — Action Type
조직의 상태를 바꾸는 행위는 미리 정의된 Action Type을 통해서만 가능합니다. Action Types 문서에 따르면 Action Type은 객체·속성·링크에 대한 변경 집합과, 그 변경이 실행될 때 따라오는 부수 효과(side effect)를 스키마로 정의한 것입니다. LLM이 “아무 API나 마음대로 호출”하는 게 아니라, 미리 정의되고 파라미터와 검증 규칙이 명확한 액션 목록 중에서만 선택하게 됩니다.
3. Ontology가 환각(Hallucination)을 줄이는 3가지 메커니즘
팔란티어는 자사 블로그에서 이 구조가 실제로 환각을 어떻게 줄이는지 두 가지 구체적인 사례로 설명합니다.
3-1. 추측 금지, 조회 우선
가상의 기업 “Titan Industries”에게 “미국 유통센터가 어디 있는지 알려줘”라고 물었을 때, 온톨로지에 접근하지 못하는 LLM은 학습 데이터에서 통계적으로 그럴듯한 도시 이름을 지어내 답합니다. 실제로 존재하지 않는 도시를 자신 있게 제시하는 식입니다.
반면 온톨로지를 쿼리할 수 있는 도구를 주면, LLM은 추측 대신 실제 데이터를 조회해서 정확한 위치를 가져옵니다. 즉 “지금 상황이 어떤지”는 LLM이 자기 지식으로 짐작하지 말고, 신뢰 가능한 소스에 물어서 확인하도록 강제하는 것입니다. 팔란티어는 이 방식을 Ontology Augmented Generation(OAG)이라 부릅니다.
3-2. 계산은 LLM이 아니라 신뢰 가능한 로직에 위임
두 번째 사례는 좌표 간 거리 계산입니다. “고립된 트럭에서 가장 가까운 유통센터가 어디인가”라는 질문에 LLM이 직접 계산하게 하면, 실제로는 더 멀리 있는 Albany, NY를 가장 가깝다고 잘못 답합니다.
이 계산을 Haversine 공식을 구현한 전용 Function에 위임하면, 실제로 가장 가까운 Providence, RI를 정확히 찾아냅니다. LLM은 원래 정밀한 수치 계산에 적합한 도구가 아니므로, 계산이 필요한 로직은 처음부터 LLM 밖으로 빼는 것이 핵심입니다.
3-3. 최종 실행은 반드시 사람 승인 큐를 통과
LLM이 재고 재배치 같은 액션을 제안하더라도, 곧바로 실행되지 않습니다. 제안은 “승인 대기” 큐에 들어가고, 도메인 전문가가 검토한 뒤에만 실제로 실행됩니다. 앞선 두 메커니즘으로 환각 가능성을 줄였다 해도, 조직 상태를 바꾸는 마지막 단계는 사람의 판단을 거치도록 설계한 것입니다.
4. “상황 → 액션” 프레임워크로 정리하기
세 가지 메커니즘을 하나로 묶으면, 결국 팔란티어의 접근은 상황(Situation)과 액션(Action)을 명확히 분리하고 각각을 엄격하게 다루는 것으로 요약됩니다.
4-1. 상황(Situation) = 지금 이 순간의 진짜 상태
재고가 얼마나 남았는지, 트럭이 어디 있는지 같은 “지금 상태”는 LLM의 기억이 아니라 온톨로지에 쿼리해서 얻은 값이어야 합니다.
4-2. 액션(Action) = 허용된 목록 안에서만 선택
시스템 상태를 바꾸는 행위는 아무 API나 자유 실행이 아니라, 파라미터와 검증 규칙이 명확한 “허용된 Action Type 목록” 중에서만 골라야 합니다. 즉 LLM에게 “뭐든 자유롭게 해봐”가 아니라 “지금 상태는 이거고, 할 수 있는 액션은 이 리스트 안에서만”으로 제한하는 것이 핵심입니다.
4-3. AI 에이전트/스킬 설계에 적용하기
이 원리는 팔란티어처럼 엔터프라이즈 데이터를 다루지 않아도 그대로 적용됩니다. Claude Code의 서브에이전트나 스킬을 설계할 때도 같은 구조가 유효합니다.
- 에이전트에게 “현재 상태”를 스스로 추측하게 두지 않고, 파일 읽기·
git status·API 조회 같은 도구로 직접 확인하게 합니다. - 정밀한 계산이나 결정론적 로직(가격 계산, 날짜 연산 등)은 LLM 프롬프트가 아니라 코드/함수 호출로 처리합니다.
- 파괴적이거나 되돌리기 어려운 작업은 자유 실행이 아니라 명확히 정의된 액션 목록과 사람의 승인 단계를 거치게 합니다.
Anthropic이 강조하는 “agent-computer interface”(툴 파라미터와 엣지케이스를 명확히 문서화하라는 원칙)도 근본적으로 같은 얘기입니다. 팔란티어는 엔터프라이즈 데이터 관점에서, Anthropic은 툴 설계 관점에서 같은 원리를 말하고 있는 셈입니다.
5. 팔란티어가 말하는 Best Practice 정리
- 상태는 조회하고, 추측하지 않는다: LLM이 알 수 없는 실시간/내부 데이터는 반드시 쿼리 도구를 통해 가져오게 한다.
- 계산은 코드에, 판단은 LLM에: 수치 계산이나 결정론적 로직은 별도 함수로 분리하고, LLM에게는 그 결과를 해석하고 판단하는 역할만 맡긴다.
- 액션은 화이트리스트 방식으로 제한한다: “무엇이든 가능”이 아니라 “이 목록 안에서만 가능”한 구조로 설계한다.
- 상태를 바꾸는 액션에는 사람 승인 단계를 둔다: 특히 되돌리기 어렵거나 영향 범위가 큰 액션은 승인 큐를 거치게 한다.
- 데이터·로직·액션 계층을 분리해서 설계한다: 세 계층이 섞여 있으면 어디서 환각이 생겼는지 추적하기 어렵다. 계층을 분리해두면 문제 원인을 좁히기도 쉬워진다.
핵심요약
- 팔란티어의 Ontology는 데이터(Object) · 로직(Function) · 액션(Action Type) 3층 구조로 조직을 모델링한 시스템입니다.
- 환각을 줄이는 핵심은 세 가지입니다: ① 상태는 추측 대신 조회, ② 계산은 결정론적 함수에 위임, ③ 최종 실행은 사람 승인 큐를 통과.
- 이를 한 문장으로 요약하면 “지금 상태를 정확히 알고, 할 수 있는 일의 목록이 명확히 제한된 AI가 실제로 안 틀린다”는 것입니다.
- 이 원칙은 엔터프라이즈 온톨로지뿐 아니라, 우리가 만드는 AI 에이전트/스킬의 도구 설계에도 그대로 적용할 수 있습니다.