팔란티어 온톨로지로 설계하는 판단과 실행

출처: https://www.youtube.com/watch?v=d_AqALJMs-U · 토크아이티(Talk IT) · 1:29:42 · 2026-04-29

요지

• 온톨로지를 업무에 활용하려면 데이터의 이름과 관계를 정의하는 데서 나아가, 어떤 상황에서 누가 무엇을 판단하고 실행할지 연결해야 한다.
• 출발점은 보유 데이터의 목록이 아니라 비용과 위험이 큰 의사 결정이며, 필요한 객체·관계·속성·시간 정보를 그 결정으로부터 역으로 찾아야 한다.
• 영상은 동적 온톨로지를 의미를 정의하는 시멘틱, 행동을 연결하는 키네틱, 결과를 평가하고 개선하는 다이나믹의 세 계층으로 설명한다.
• 운영 가능한 시스템에는 데이터 파이프라인, 판단 기준, 실행 권한, 근거 기록, 결과를 반영하는 피드백 과정이 함께 필요하다.
• LLM은 설계 초안과 사용자 인터페이스를 도울 수 있지만 업무 정의의 합의와 판단 기준의 검증을 대신하지 않으며, 온톨로지만으로 인과관계나 정답이 보장되지는 않는다.

개요

이현종 빅스터 대표가 팔란티어 파운드리 사용 경험을 바탕으로, 데이터를 모으는 시스템과 업무 판단을 실행으로 연결하는 시스템의 차이를 설명한 웨비나다. 발표자는 온톨로지를 ‘판단의 기준을 세우기 위한 데이터 구조’, 나아가 기업 운영을 연결하는 기반으로 해석한다. 핵심 질문은 ‘데이터가 얼마나 많은가’보다 ‘이 데이터로 어떤 결정을 반복적으로 내릴 수 있는가’다.

교안은 화장품 출하 판단과 가상의 식당 운영 사례를 통해 객체 정의, 동적 데이터 연결, 행동 실행, 결과 평가의 흐름을 설명한다. 영상에는 발표자의 제품 소개와 시장 전망도 포함되어 있다. 아래에서는 이를 발표자의 주장으로 구분하며, 코드와 검증 방법은 학습을 위해 보충했다. 제품의 현재 기능·가격·내부 구현을 별도로 검증한 문서는 아니다.

배경 / 사전 지식

기업의 업무 데이터는 여러 시스템에 흩어져 있다. ERP는 재무·구매·인사 등 전사 업무를, MES는 제조 현장의 생산 실행을, SCM은 공급망 관련 흐름을 관리한다. 각 시스템에 기록이 충분하더라도 서로 다른 식별자와 업무 정의를 쓰면 하나의 질문에 일관되게 답하기 어렵다. 예를 들어 영업팀의 ‘출하 가능’은 납기 준수를, 품질팀의 ‘출하 가능’은 검사 통과를 뜻할 수 있다.

데이터 웨어하우스나 데이터 레이크는 데이터를 통합·보관하고, BI는 집계와 시각화를 통해 현황을 파악하도록 돕는다. 그러나 ‘불량률이 올랐다’는 사실을 표시하는 것과 ‘어떤 배치를 보류하고 누가 승인할지’를 운영 절차로 만드는 것은 별도의 작업이다. 영상이 강조하는 온톨로지의 가치는 이 사이를 연결하는 데 있다. 기존 시스템에서도 이러한 기능을 구현할 수 있으므로, 도구의 이름보다 실제 연결 범위를 살펴야 한다.

기본 용어는 다음과 같다.

핵심 개념

온톨로지: 업무 의미를 공유하는 구조

온톨로지는 업무 대상과 그 의미, 관계를 명시적으로 표현하는 구조다. 단순히 테이블 이름을 객체 이름으로 바꾸는 것으로 완성되지 않는다. ‘배치’, ‘검사 완료’, ‘출하 가능’이 무엇인지와 어떤 조건에서 성립하는지 합의해야 한다.

발표자는 이를 기업의 운영체제에 비유한다. 여러 시스템의 데이터를 공통 의미로 연결하고, 그 위에서 판단과 행동이 이루어지게 한다는 뜻이다. 이는 영상의 설명을 위한 비유이며, 온톨로지라는 데이터 모델 자체가 모든 운영 기능을 제공한다는 의미는 아니다.

시멘틱·키네틱·다이나믹 계층

영상의 세 계층 설명은 ‘대상이 무엇인가 → 무엇을 할 것인가 → 결과를 보고 어떻게 바꿀 것인가’로 이해할 수 있다.

발표자는 특히 키네틱 계층의 구현이 어렵다고 말한다. 정적인 객체 몇 개를 연결하는 것과 달리, 실제 데이터가 계속 들어오는 환경에서 상태·조건·예측 결과·행동을 일관되게 연결해야 하기 때문이다. 이 표는 영상의 설명 틀이며 제품 API나 기능 명세를 대신하지 않는다.

데이터부터 시작하지 않는 역방향 설계

‘어떤 데이터가 있는가’부터 접근하면 수집과 시각화가 목표가 되기 쉽다. 영상은 ‘누가 어떤 결정을 내려야 하는가’를 먼저 정하도록 권한다.

예를 들어 출하 판단을 설계한다면 먼저 승인 책임자와 가능한 행동을 정한다. 이어서 판단에 필요한 검사 결과, 원료 추적 정보, 설비 상태를 찾는다. 마지막으로 해당 정보가 어느 시스템에 있는지 확인한다. 이 순서는 수집 범위를 줄이고, 필요한데 없는 데이터도 드러낸다.

시간 모델링과 인과 해석

같은 값이라도 언제 관측되었는지, 어느 기간을 대표하는지에 따라 의미가 달라진다. 순간 불량률과 최근 일주일의 평균 불량률은 서로 다른 판단 근거다. 이벤트 발생 시각과 시스템 수집 시각이 다를 수도 있으므로, 시간의 의미를 구분해야 한다.

영상은 아이스크림 판매와 익사 사고가 함께 증가하는 예로 상관관계와 인과관계를 구별한다. 함께 움직인다는 이유만으로 하나가 다른 하나의 원인이라고 할 수는 없다. 마찬가지로 온톨로지에 시간 순서와 관계를 기록해도 인과관계가 자동으로 증명되지는 않는다. 원인 후보를 추적하는 데 도움이 되지만, 교란 요인 검토와 실험 또는 적절한 분석이 추가로 필요하다.

데이터 리니지와 판단 이력

데이터 리니지는 판단 입력이 만들어진 경로를 보여준다. 판단 이력은 당시 어떤 입력과 규칙으로 어떤 결정을 내렸는지 보여준다. 두 기록을 연결해야 ‘왜 이 배치가 출하되었는가’라는 질문에 답할 수 있다.

원천 데이터 오류, 변환 오류, 기준 오류, 승인자의 예외 처리 등 실패 지점을 구분하는 것이 목적이다. 단순히 관계 그래프를 보기 좋게 그리는 것만으로는 이런 추적 가능성을 확보할 수 없다.

LLM과 업무 판단의 역할 분담

발표자는 LLM을 온톨로지 설계와 활용을 돕는 수단으로 설명한다. 인터뷰 내용을 객체·관계 후보로 정리하고, 설계안을 작성하고, 사용자 질문을 해석하는 데 활용할 수 있다. 그러나 초안의 타당성은 현업 담당자와 확인해야 한다.

규칙 기반 판단은 같은 입력과 규칙에 대해 같은 결과를 재현하기 쉽다. 그렇다고 그 결과가 현실에서도 항상 옳다는 뜻은 아니다. 잘못된 규칙은 잘못된 판단을 일관되게 반복한다. LLM과 온톨로지 모두 입력 품질, 평가, 변경 관리가 필요하다.

정의 합의와 책임의 명확화

발표자가 ‘정의 전쟁’이라고 부르는 문제는 부서마다 동일한 용어를 다르게 사용하는 상황이다. 기술팀이 임의로 하나를 고르면 특정 부서의 관점이 전체 시스템에 반영될 수 있다.

현업 담당자는 업무 의미와 예외를 설명하고, 기술 담당자는 이를 구현 가능한 구조로 옮기며, 권한 있는 의사 결정자는 충돌하는 정책을 조정한다. 영상에서 소개하는 FDE는 현장 문제 해결, 소통, 데이터 이해, 소프트웨어 역량을 연결하는 역할이다. 책임자를 정하는 목적은 실패를 처벌하는 데 그치지 않고, 결정과 결과를 다음 개선의 근거로 남기는 데 있다.

작동 원리

1. 비용이 큰 의사 결정 하나를 고른다

영상은 기업 전체를 한 번에 모델링하기보다 출하 판단이나 수율 개선처럼 손실이 큰 영역부터 시작하라고 권한다. 학습 예시에서는 ‘이번 생산 배치를 출하 승인할 것인가’를 대상으로 삼는다. 가능한 결과는 승인, 보류, 추가 검토로 제한한다.

2. 책임자와 업무 용어를 정한다

승인 책임자, 검사를 수행하는 사람, 예외를 허용할 수 있는 사람을 구분한다. ‘검사 완료’가 일부 항목 완료인지 모든 필수 항목 완료인지도 명시한다. 팀별 인터뷰로 차이를 찾고, 합의한 정의와 예외 조건을 문서로 남긴다.

3. 필요한 객체와 관계를 모델링한다

배치가 어떤 원료를 사용했는지, 어떤 설비에서 생산되었는지, 어떤 검사 결과와 연결되는지 정의한다. 객체마다 식별자가 있어야 하며, 서로 다른 시스템의 식별자를 연결할 규칙도 필요하다. 현재 결정에 영향을 주지 않는 객체까지 처음부터 모두 만들 필요는 없다.

4. 데이터를 정제하고 연결한다

영상은 원천 데이터에서 정제 데이터를 거쳐 온톨로지에 쓰이는 데이터로 이어지는 흐름을 강조한다. 이 과정에서 코드 체계, 단위, 시간대, 중복, 누락을 처리한다. 문서에만 있는 정보는 추출 후 검증하여 연결해야 한다. 정제 과정과 원천 위치를 기록해 입력의 출처를 추적한다.

5. 시간과 판단 조건을 결합한다

최근 검사인지, 해당 배치의 검사인지, 필요한 항목이 모두 있는지 확인한다. 그 뒤에 불량률이나 설비 이상 같은 판단 조건을 적용한다. 값이 없는 경우를 정상으로 간주하지 말고 별도의 검토 상태로 처리해야 한다.

6. 실행과 근거 기록을 연결한다

판단 결과가 승인 조건을 만족하더라도 실제 출하 실행에는 별도의 권한과 업무 절차가 필요할 수 있다. 누가 언제 어떤 근거로 실행했는지 남기고, 보류 시에는 담당자와 후속 작업을 연결한다. ‘추천을 생성함’, ‘승인받음’, ‘실행 완료됨’을 구분해야 운영 상태를 정확히 알 수 있다.

7. 결과를 평가하고 버전을 갱신한다

출하 이후 반품, 고객 불만, 재검사 결과를 원래 결정에 연결한다. 기준을 바꾸려면 과거 사례에서 효과와 부작용을 검토하고, 테스트 후 적용한다. 당시 사용한 규칙 버전은 유지하여 과거 판단을 재현할 수 있게 한다.

가상의 식당 사례도 같은 흐름이다. 고객 방문·직원 배치·서빙·대기 시간·매출을 연결한 다음, ‘숙련 직원 부족이 대기 시간을 늘렸는가’를 검토한다. 직원 추가 배치의 효과는 검증할 가설이며, 실제 운영 비교나 시뮬레이션의 가정을 확인해야 한다.

코드 예시

다음은 영상의 출하 판단을 학습용으로 단순화한 Python 3 코드다. 외부 패키지 없이 실행할 수 있으며, 파운드리 API를 사용하는 코드는 아니다. 객체 관계, 시간 조건, 규칙 버전, 판단 근거를 함께 남기는 구조를 보여준다. 수치와 데이터는 모두 설명용이다.

from dataclasses import dataclass, asdict
from datetime import datetime, timedelta, timezone
from typing import Optional
import json


@dataclass(frozen=True)
class Inspection:
    inspection_id: str
    batch_id: str
    measured_at: datetime
    defect_rate: float
    source_record: str


@dataclass(frozen=True)
class Batch:
    batch_id: str
    equipment_ok: bool
    inspection: Optional[Inspection]


@dataclass(frozen=True)
class Policy:
    version: str
    max_defect_rate: float
    max_age_hours: int


def evaluate(batch: Batch, policy: Policy, now: datetime) -> dict:
    inspection = batch.inspection
    review_reasons = []
    hold_reasons = []

    if not batch.equipment_ok:
        hold_reasons.append('설비 상태 확인 필요')

    if inspection is None:
        review_reasons.append('검사 데이터 없음')
    else:
        if inspection.batch_id != batch.batch_id:
            review_reasons.append('검사와 배치의 식별자 불일치')
        age = now - inspection.measured_at
        if age < timedelta(0):
            review_reasons.append('검사 시각이 미래임')
        elif age > timedelta(hours=policy.max_age_hours):
            review_reasons.append('검사 유효 기간 초과')

        if not 0 <= inspection.defect_rate <= 1:
            review_reasons.append('불량률 값이 유효하지 않음')
        elif inspection.defect_rate > policy.max_defect_rate:
            hold_reasons.append('허용 불량률 초과')

    if hold_reasons:
        recommendation = 'HOLD'
    elif review_reasons:
        recommendation = 'REVIEW'
    else:
        recommendation = 'READY_FOR_APPROVAL'

    return {
        'batch_id': batch.batch_id,
        'evaluated_at': now.isoformat(),
        'policy': asdict(policy),
        'input_snapshot': asdict(batch),
        'recommendation': recommendation,
        'reasons': hold_reasons + review_reasons or ['모든 예시 조건 충족'],
        'approval_role': '품질 책임자',
        'executed': False,
    }


now = datetime(2026, 4, 29, 12, 0, tzinfo=timezone.utc)
policy = Policy('release-v1', max_defect_rate=0.001, max_age_hours=24)
inspection = Inspection(
    inspection_id='QC-101',
    batch_id='B-101',
    measured_at=now - timedelta(hours=2),
    defect_rate=0.0005,
    source_record='quality-system/QC-101',
)

batches = [
    Batch('B-101', equipment_ok=True, inspection=inspection),
    Batch('B-102', equipment_ok=True, inspection=None),
]

for batch in batches:
    print(json.dumps(
        evaluate(batch, policy, now),
        ensure_ascii=False,
        default=str,
        indent=2,
    ))

첫 번째 배치는 예시 조건을 충족하므로 READY_FOR_APPROVAL, 두 번째 배치는 검사 데이터가 없어 REVIEW가 나온다. 두 경우 모두 executed는 false다. 판단 결과 생성과 실제 실행을 분리했기 때문이다.

input_snapshot은 판단 당시의 입력을, policy는 사용한 기준을 기록한다. source_record는 원천 기록을 가리키는 최소 연결 정보다. 실제 운영에서는 여기에 변환 이력, 권한 검사, 승인 기록, 중복 실행 방지, 실패 시 복구, 영속 저장을 추가해야 한다. 이 예시는 규칙 평가의 작은 부분만 구현하며 완전한 온톨로지 플랫폼이나 인과 추론 시스템은 아니다.

함정·실수

• 데이터를 모두 모은 뒤 용도를 찾는다. 수집·저장 비용이 늘어도 의사 결정은 여전히 수작업일 수 있다. 먼저 결정과 행동을 정하고 필요한 데이터 범위를 역으로 찾는다.
• 그래프 DB나 관계 시각화만으로 구현이 끝났다고 생각한다. 저장과 탐색만으로는 시간 조건, 권한, 실행, 피드백이 해결되지 않는다. 판단부터 결과 기록까지 한 흐름으로 검증한다.
• 시간 순서나 리니지를 인과관계의 증명으로 받아들인다. 앞서 발생한 사건이 반드시 원인은 아니고, 데이터 변환 경로가 현실의 원인 경로와 같지도 않다. 원인 후보와 검증된 원인을 구분한다.
• 결정론적 규칙이면 항상 정확하다고 믿는다. 누락된 예외, 오래된 데이터, 잘못 합의한 기준은 일관된 오판을 만든다. 입력 검증과 보류 경로를 마련한다.
• LLM이 작성한 업무 모델을 바로 적용한다. 그럴듯한 용어와 관계가 실제 업무를 반영하지 않을 수 있다. 현업 검토와 실제 사례 평가를 거친다.
• 책임자 지정만으로 조직 합의가 끝났다고 본다. 부서 간 정의 차이가 남으면 시스템 밖에서 예외 처리가 늘어난다. 결정 근거와 이견을 기록하고 변경 절차를 둔다.
• 발표자의 제품 평가를 검증된 일반 사실로 받아들인다. 대체 플랫폼이 없다는 주장, 특정 저장 방식에 대한 단정, 기업 성과를 특정 제품 도입으로 설명하는 주장은 별도 근거가 필요하다. 도입 판단에서는 실제 요구사항과 실증 결과를 확인한다.
• 데이터 유출과 공급업체 종속성을 같은 문제로 취급한다. 영상 말미의 기업 복제 가능성은 발표자의 강한 위험 표현이다. 실제 검토에서는 접근 권한·계약·배포 방식·데이터 반출 가능성·이전 비용을 나누어 평가한다.

베스트 프랙티스

1. 작은 결정 단위로 실증한다. 영상은 약 3개월 동안 한두 개 의사 결정을 대상으로 시작하는 방식을 제안한다. 이는 보편적인 일정 보장이 아니라 발표자의 권고다. 데이터 준비도에 맞춰 범위와 기간을 정한다.
2. 성공 기준을 먼저 만든다. 판단 소요 시간, 수작업 횟수, 잘못된 승인과 불필요한 보류, 근거를 재현할 수 있는 비율을 도입 전후로 비교한다. 보기 좋은 대시보드만으로 성공을 판정하지 않는다.
3. 업무 정의와 데이터 정의를 함께 관리한다. 용어, 식별자, 단위, 시간 의미, 결측 처리, 책임자, 예외 조건을 연결해서 기록한다. 현업·기술팀이 동일한 사례를 보고 검토하게 한다.
4. 초기에는 기존 결정과 병행 비교한다. 시스템 추천을 바로 자동 실행하기보다 담당자 판단과 비교해 차이를 분석한다. 실패 비용과 검증 수준에 따라 자동 실행 범위를 넓힌다.
5. 실패도 재현 가능한 기록으로 남긴다. 입력 스냅샷, 규칙 버전, 승인자, 실행 상태, 최종 결과를 연결한다. 결과가 나빴을 때 데이터·모델·정책·실행 중 무엇을 바꿀지 구분할 수 있어야 한다.
6. 피드백을 곧바로 자동 변경으로 연결하지 않는다. 임계치 조정에는 오탐·미탐 비용과 업무 제약이 따른다. 후보 기준을 평가하고 승인 후 적용하며 되돌릴 수 있게 한다.
7. 목적에 맞는 대안을 선택한다. 현황 조회는 BI, 문서 질의응답은 검색·RAG, 단순한 반복 판단은 규칙 엔진과 워크플로로도 해결할 수 있다. 여러 시스템의 객체·상태·권한·행동을 지속적으로 연결해야 하는지 확인한 뒤 플랫폼 범위를 정한다.
8. 내부의 운영 역량을 남긴다. 외부 전문가가 초기 모델링을 지원하더라도 업무 정의와 변경 판단을 전적으로 외주에 맡기지 않는다. 내부 담당자가 기준과 데이터 흐름을 이해하도록 공동 설계한다.

참고

• 원본 웨비나: 온톨로지와 팔란티어 파운드리에 대한 정말 쉬운 설명, 토크아이티(Talk IT), 이현종 빅스터 대표 출연.
• 이현종의 『온톨로지』: 영상에서 시간 모델링, 가상 식당 벨라로마 사례, 조직의 정의 합의를 설명한 책으로 언급한다.
• 『팔란티어 파운드리: 판단을 설계하라』: 자막에서 소개된 제목 기준. 화장품 제조 데이터로 출하 판단을 설계하고 파운드리를 사용하는 과정을 다룬다고 설명한다.
• Palantir Foundry, Gotham, AIP, Apollo: 영상에서 민간·국방 데이터 활용, LLM 연계, 배포 및 업데이트와 관련하여 언급한 제품이다. 세부 역할과 실제 기능 범위는 공식 문서로 별도 확인해야 한다.
• 빅스터의 ‘달핀통’: 발표자가 소개한 온톨로지 관련 솔루션. 방송 시점에 다음 달 출시 예정이라고 설명하며, 이 문서는 이후 출시 여부나 성능을 확인하지 않았다.
• RDF, OWL, LPG, 그래프 DB, Neo4j: 온톨로지 표현과 저장·탐색 기술을 설명하면서 언급한다. 저장 기술 선택과 업무 판단 시스템 전체의 설계는 구분해서 학습해야 한다.
• 보충 범위: 코드, 입력 검증, 인과 해석의 주의점, 평가 지표와 단계적 실행 권고는 자막의 논지를 학습 가능한 형태로 확장한 내용이다. 자막에 시각 정보가 없어 구간별 타임스탬프는 기재하지 않았다.