Palantir Ontology란? Palantir가 2024년 공식 문서에서 정의한 의사결정 중심 소프트웨어 아키텍처입니다. 데이터(data), 논리(logic), 행동(action) 세 요소를 통합해 조직의 디지털 트윈을 구축하고, AI 기반 실시간 의사결정을 지원합니다. 2026년 2월 현재 Foundry 플랫폼의 핵심 구성요소로 Object types, Link types, Action types, Interfaces, Shared properties를 리소스로 제공합니다.
여러분 이거 경험 있죠?
온톨로지, 지식 그래프, PKM(Personal Knowledge Management) 글을 읽다가 “와, 이거 적용하면 내 노트가 완전 달라지겠다” 하고 설레서 시작했는데…
한 달 지나니까 노트는 쌓이는데 뭘 어디에 넣어야 할지부터 막히고, 관계 링크는 “나중에 연결하지” 하고 미뤄두다가 결국 연결 안 된 노트 100개가 되어 있는 거.
저도요.
2025년부터 Obsidian으로 개인 온톨로지를 운영하면서 Palantir 문서를 읽었을 때 “이거 개인용으로 줄이면 되겠다” 싶었어요. Object, Link, Action 삼각형이 멋있어 보였거든요. 근데 막상 적용하려니까 기업용 프레임이랑 개인 운영 규칙이랑 뭘 가져오고 뭘 버려야 할지가 애매했어요.
이 글은 그 경계선을 정리한 점검표입니다. Palantir Ontology의 기업형 프레임을 개인이 쓸 수 있는 규칙으로 바꿀 때, 어디까지 가져오고 어디서 멈출지를 실행 가능한 체크리스트로 정리했습니다.
1. Palantir Ontology가 기업에서 하는 일
Palantir Ontology… 이름부터 뭔 소린지 모르겠죠?
쉽게 말하면 **”조직의 의사결정을 디지털로 재현하는 운영 레이어”**예요.
1-1. 기업형 프레임의 핵심: Data + Logic + Action
Palantir 공식 블로그(2024)에 따르면, 전통적인 데이터 아키텍처는 데이터만 다룹니다. 근데 실제 의사결정은 세 가지가 필요해요:
| 요소 | 기업에서의 의미 | 개인에서의 번역 |
|---|---|---|
| Data | 정보(데이터셋, 리포트, 거래 내역) | 노트, 클리핑, 캡처 |
| Logic | 평가 과정(규칙, 모델, 검증 조건) | 리뷰 루프, confidence 점수, 승격 기준 |
| Action | 실행(변경, 승인, 알림) | 노트 수정, Notion 승격, 에이전트 트리거 |
기업은 이 셋을 Ontology에 통합해서 누가 언제 왜 결정했는지를 추적하고, AI가 그 맥락 위에서 동작하게 합니다.
1-2. 기업이 갖고 개인은 갖기 어려운 것들
Palantir Ontology 문서를 보면 이런 게 나와요:
- Object types, Link types, Action types — 스키마 정의
- Interfaces, Shared properties — 타입 재사용
- Submission criteria, Side effects — 액션 검증과 웹훅
- Branch/proposal 기반 변경 관리 — main 반영 전 검토
- Project-based permissions — 권한 모델
- OSDK, AIP Logic — 타입 안전 코드, LLM 함수 자동화
이거 전부 개인에게 필요한가요?
아니요. 데이터 통합 규모랑 의사결정 재사용 속도가 다릅니다. 기업은 수백 명이 같은 객체를 쓰고, 개인은 나 혼자 써요. 그래서 무엇을 가져오고 무엇을 버릴지가 핵심이 됩니다.
2. 개인 온톨로지의 경계선: 어디까지 가져올 것인가
제가 2026년 2월 캡처해둔 노트에 이런 한 줄이 있어요:
“개인용 온톨로지는 기업 온톨로지와 달리 데이터 통합보다 의사결정 재사용 속도에 초점을 둬야 한다.”
이게 경계선의 출발점입니다.
2-1. 가져올 것 (Must Have)
| 기업 개념 | 개인 적용 | 이유 |
|---|---|---|
| Object + Link + Action 삼각형 | 노트 타입 + 관계 동사 + 표준 액션 | 단순 메모를 “작동하는 의사결정 시스템”으로 바꿈 |
| 공통 속성(Shared property) | type, status, review, confidence 등 8개 | 에이전트가 일관되게 처리 가능 |
| 관계 동사 제한 | supports, depends_on, contrasts_with 등 6개 | “나중에 연결”을 막고 즉시 링크 강제 |
| Review 루프 | review <= today 노트 매일 처리 | 입력 속도만 빠르면 품질이 떨어짐. 링크와 리뷰가 같이 있어야 기억 시스템 |
| Action 로그 | 변경 이력, 승격 기록 | “왜 이렇게 바꿨지?” 나중에 추적 가능 |
2-2. 줄일 것 (Should Reduce)
| 기업 개념 | 개인 적용 | 이유 |
|---|---|---|
| Branch/proposal 변경 관리 | 실험용 노트는 experimental → 안정화 후 active | 개인은 PR 승인 프로세스까지는 과함 |
| 다중 권한 모델 | owner_user_id 1인 강결합 | 나 혼자 쓰니까 팀 권한 불필요 |
| 수십 개 Object type | Goal, Project, Task, Concept, Evidence, Decision 등 10개 내외 | 처음엔 최소 집합만 |
| OSDK 타입 안전 코드 | 템플릿 + QuickAdd로 대체 | 코드 유지보수 부담 줄이기 |
2-3. 버릴 것 (Don’t Need)
| 기업 개념 | 개인에서 버리는 이유 |
|---|---|
| Project-based permissions (Compass) | 1인 운영에 권한 분리는 오버킬 |
| AIP Logic 전체 파이프라인 | LLM 함수 자동화는 나중에, 먼저 Capture/Review 안정화 |
| 대규모 스키마 확장 | “새 DB 10개 만들자”보다 “기존 5개 잘 굴리자” |
| 무승인 write-back | Notion 자동 쓰기는 위험. 승인 큐 후 수동 반영 |
3. 과도한 시스템화 vs 실용적 운영의 균형
여기서 진짜 웃긴 게요.
Palantir 문서 읽으면 “Object 12개, Link 20개, Action 8개 정의하자” 하고 싶어지거든요. 근데 시스템 구축 자체가 목표가 되면, 매일 쓰는 건 뒷전이 됩니다.
3-1. 과도한 시스템화의 함정
- 입력 속도만 빠르면 품질이 떨어진다.
QuickAdd로 5초 만에 노트 만들 수 있어요. 근데 링크 안 걸고, review 날짜 안 넣고 저장하면? 나중에 “이거 뭐였지?”가 됩니다. - 링크와 review 루프가 같이 있어야 기억 시스템이 된다.
제텔카스텐이 좋다고 해도, 노트 1000개 쌓이고 연결은 10개면 그냥 폴더예요. 온톨로지가 아니에요. - 니클라스 루만도 하루 5장만 정리했다.
완벽한 시스템을 하루 만에 만들 수 없어요. 쓰는 시간보다 정리 시간이 더 길어지면 지속 불가능합니다.
3-2. 실용적 균형의 원칙
제가 2026년 2월 AI Agent 실행 계획서에 Out of Scope로 명시한 것들:
- 대규모 스키마 확장(신규 DB 다수 생성)
- Notion 자동 쓰기(무승인 write-back)
- 과도한 플러그인 추가
그리고 목적·사상·원칙 문서에 적어둔 것:
- 완벽한 설계보다, 매일 굴러가는 운영이 우선
- 시스템 확장보다 운영 안정화
- 새로운 기능보다 입력 품질 향상
- 자동화 속도보다 데이터 신뢰도
이게 실용적 균형입니다. “더 많은 타입”보다 “지금 있는 타입을 잘 쓰는 것”이 먼저예요.
4. 실행 가능한 점검표: 기업형 → 개인형 변환
기업 사례를 볼 때마다 **”이거 개인에 적용하려면 어떻게 바꿔야 하지?”**가 생깁니다. 아래 점검표로 한 번 걸러보세요.
4-1. 가져오기 전 점검 (Before Import)
| # | 질문 | Yes → 진행 | No → 스킵 또는 단순화 |
|---|---|---|---|
| 1 | 이 개념이 의사결정 재사용 속도를 높이는가? | ✅ | 데이터 통합만 목적이면 과함 |
| 2 | 나 혼자 매일 5분 안에 할 수 있는가? | ✅ | 30분씩 걸리면 유지 불가 |
| 3 | 기존 속성/관계로 대체 가능한가? | ✅ | 새 타입 추가 전에 기존 것 재활용 |
| 4 | 실패해도 원본 훼손 없이 되돌릴 수 있는가? | ✅ | 자동 덮어쓰기는 위험 |
4-2. 적용 후 점검 (After Apply)
| # | 질문 | 통과 기준 |
|---|---|---|
| 1 | 신규 노트 평균 생성 시간 | 30초 이내 |
| 2 | 24시간 내 링크 연결률 | 80% 이상 |
| 3 | due review 처리율 | 70% 이상 |
| 4 | 주간 통찰 → 실제 행동 전환율 | 50% 이상 |
이 수치들은 제가 목적·사상·원칙 문서에 적어둔 품질 기준이에요. 주간 리뷰에서 한 번씩 체크하면 “시스템이 나를 도와주는지” vs “내가 시스템을 유지보수하는지”가 보입니다.
4-3. 경계선 넘어섰을 때 신호
아래 중 하나라도 맞으면 과도한 시스템화 쪽으로 넘어간 겁니다:
- [ ] 새 Object type를 추가하려는 충동이 1주일에 2번 이상 생긴다
- [ ] “이 플러그인 하나만 더 넣으면”이 3번째다
- [ ] 노트 쓰는 시간보다 템플릿 수정하는 시간이 더 길다
- [ ] 리뷰 due가 50개 넘었는데 “시스템 개선”을 하고 있다
- [ ] Notion 자동 쓰기를 검토 중이다 (무승인 write-back)
이럴 때는 멈추고, 기존 타입/템플릿으로 2주만 굴려보세요. 부족한 게 진짜인지, 그냥 “더 하고 싶은 것”인지 구분됩니다.
5. 내가 느낀 점: 기업 프레임을 개인 규칙으로 바꿀 때
Palantir 문서 읽고 처음엔 “Object 12개, Link 20개 다 정의해야 하나?” 싶었어요. 근데 2주 운영해보니까 타입 수보다 일관성이 훨씬 중요하더라고요.
같은 의미를 supports랑 relates_to 둘 다 쓰기 시작하면, 에이전트가 “이 노트는 뭐랑 연결돼?” 할 때 혼란스러워요. 허용 동사 6개만 쓰자고 제한해두니까, “나중에 연결하지”가 줄었어요. 지금 당장 고르게 되거든요.
그리고 기업 사례를 가져올 때는 반드시 개인 운영 규칙으로 변환한 뒤 적용한다는 걸 노트에 적어뒀어요. Palantir가 branch/proposal 쓰는 건 팀 협업 때문이고, 나는 혼자니까 experimental → active 전환 규칙만 있으면 됩니다.
5-1. 앞으로 할 것들
- Object type 10개 고정 — 2주 동안 새 타입 추가 금지, 기존 것만 다듬기
- 주간 점검표 실행 — 4-2 항목 매주 일요일 체크
- 경계선 넘어섰을 때 신호 — 4-3 체크리스트 매주 확인
6. FAQ
Q: Palantir Ontology를 개인이 쓰려면 Foundry 구독이 필요한가요?
A: 아니요. Palantir Ontology의 개념(Object, Link, Action, 의사결정 중심 아키텍처)을 Obsidian, Notion, 로컬 그래프 DB 등으로 구현할 수 있습니다. Foundry는 기업용 SaaS 제품입니다.
Q: Object type을 몇 개 정의하는 게 적당한가요?
A: 처음엔 5~10개로 시작하세요. Goal, Project, Task, Concept, Evidence, Decision, Resource 정도면 개인 지식-행동-결정에 충분합니다. 15개 넘어가면 유지보수 부담이 커집니다.
Q: “의사결정 재사용 속도”가 정확히 뭔가요?
A: 비슷한 상황이 왔을 때, 과거에 한 판단(노트, 링크, confidence)을 얼마나 빨리 꺼내서 다시 쓰는지를 말합니다. 데이터가 많아도 “어디 있는지 모르면” 재사용 속도는 0입니다.
Q: review 루프를 안 하면 어떻게 되나요?
A: 노트가 쌓이기만 하고 연결이 안 됩니다. 링크와 review가 같이 있어야 “기억 시스템”이 됩니다. 입력 속도만 빠르면 품질이 떨어집니다.
Q: 기업 문서를 볼 때 어떤 순서로 변환하나요?
A: 1) 가져오기 전 점검(4-1) 적용 → 2) Must Have만 먼저 적용 → 3) 2주 운영 후 Should Reduce 검토 → 4) Don’t Need는 아예 스킵
7. 참고 자료
- Palantir Ontology 공식 — 기업형 프레임워크 개요
- Connecting AI to Decisions with the Palantir Ontology — Palantir 공식 블로그 (2024)
- Ontology building – Palantir Foundry — Object, Link, Action 타입 정의
- Personal Knowledge Graphs: A Research Agenda — 개인 vs 기업 지식 그래프 차이
8. 요약
| 구분 | 기업 (Palantir) | 개인 (Palantir-lite) |
|---|---|---|
| 초점 | 데이터 통합, 조직 일관성 | 의사결정 재사용 속도 |
| 가져올 것 | Object+Link+Action, 공통 속성, 관계 동사, Review 루프 | ✅ |
| 줄일 것 | Branch/proposal, 다중 권한, 수십 개 타입 | experimental→active, 1인 강결합, 10개 내외 |
| 버릴 것 | Project 권한, AIP Logic 전체, 무승인 write-back | ✅ |
| 균형 | — | 완벽한 설계 < 매일 굴러가는 운영 |