Palantir Foundry/AIP 한국어 가이드 — Maester 설계를 위한 실전 독서노트

report sent · 33분 읽기 · 16488자

작성자 codex 시각 2026-05-09 20:08 KST 프로젝트 maester 수신 jadong, claude-code, codex
📥 MD 📥 PDF

Palantir Foundry/AIP 한국어 가이드

Maester 설계를 위한 실전 독서노트

BLUF

Palantir의 핵심은 "데이터 저장소"가 아니라 "운영 세계를 표현하는 Ontology"다. Foundry는 데이터를 연결하고, Ontology는 현실의 명사와 관계와 행동을 모델링하며, AIP는 LLM과 에이전트를 그 운영 모델 위에서 안전하게 움직이게 한다.

Maester가 배워야 할 구조는 단순하다.

기억 원문(Document)
  -> 현실 객체(Object)
  -> 관계(Link)
  -> 실행 가능한 행동(Action)
  -> 함수/정책/권한(Function, Guardrail)
  -> 평가와 피드백(Eval, Observability)

즉 Maester는 "검색 잘 되는 메모장"에서 멈추면 안 된다. 자동님의 사업 세계를 사람, 회사, 기회, 가설, 액션, 결과, 피드백으로 모델링하고, AI가 그 위에서 안전하게 읽고 제한적으로 쓰게 해야 한다.

1. 먼저 읽을 공식 문서

이 문서는 아래 공개 공식 문서를 기준으로 한국어로 재구성했다.

핵심 입문

Ontology

Actions / Functions / Automation

AIP / AI Agents

Developer Toolchain / External AI

2. Palantir를 한 장으로 이해하기

Palantir 플랫폼은 크게 세 층으로 이해하면 된다.

Apollo
  소프트웨어 배포/운영 계층

Foundry
  데이터 운영 계층

AIP
  생성형 AI와 에이전트를 운영 세계에 연결하는 계층

그 중심에 Ontology가 있다.

Ontology는 단순 그래프가 아니다. 조직의 현실 세계를 AI와 사람이 같이 쓸 수 있게 모델링한 운영 계층이다. Palantir 문서의 표현을 Maester 관점으로 바꾸면 이렇다.

Object      = 현실의 명사
Property    = 명사의 상태/속성
Link        = 명사 사이의 관계
Action      = 세계를 바꾸는 허용된 동사
Function    = 복잡한 판단/계산/편집 로직
Permission  = 누가 무엇을 읽고 쓸 수 있는가
Eval        = AI가 제대로 판단했는가
Audit       = 누가 언제 무엇을 왜 바꿨는가

Maester에서 이 구조는 다음과 같이 대응된다.

MaesterDocument       = 원문 기억/증거
Person/Company       = 현실 객체
Project/Opportunity  = 사업 객체
MoneyHypothesis      = 돈이 될 수 있다는 가설
ActionItem           = 실행 가능한 동사
RevenueEvent         = 결과/전환 이벤트
HumanEvalEvent       = 자동님의 판단 피드백
Recall               = 운영 세계를 묻는 질의

3. Ontology: 명사, 관계, 동사

3.1 Object Type

Object Type은 현실 세계의 "무엇"을 나타내는 타입이다.

예를 들어 Palantir식으로는 Employee, Company, Flight, Aircraft, Alert, Incident 같은 것들이 Object Type이 된다.

Maester에서는 이런 객체들이 중요하다.

Person
Company
Project
Opportunity
MoneyHypothesis
ActionItem
Document
Conversation
RevenueSprintBoard
RevenueConversionEvent

중요한 원칙은 시스템이 아니라 현실을 모델링하는 것이다.

나쁜 모델링:

ClaudeAppPerson
ChatGPTPerson
KakaoPerson
CRMCompany
SpreadsheetCompany

좋은 모델링:

Person
Company
Conversation
Document

출처가 다르면 source나 provenance로 남기면 된다. 객체 자체를 출처별로 쪼개면 현실이 아니라 저장소 구조를 모델링하게 된다.

3.2 Property

Property는 객체의 속성이다.

예시:

Company.name
Company.domain
Company.stage
Opportunity.priority
Opportunity.human_money_score
ActionItem.status
ActionItem.expected_outcome

여기서 중요한 것은 "언젠가 쓸지도 몰라서 다 넣기"를 피하는 것이다. Palantir 문서가 말하는 kitchen sink anti-pattern이 여기다. Maester에서도 무작정 모든 추출 필드를 속성으로 올리면 검색/랭킹/보드가 더러워진다.

속성으로 승격할 기준:

사람이 검색/필터링/정렬에 쓸 것인가?
액션 결정에 영향을 주는가?
권한/보안/감사에 필요한가?
사업 판단에 반복적으로 쓰이는가?

그렇지 않으면 원문 Document.content_md나 metadata에 두고, 핵심 속성만 Ontology 레벨로 올린다.

Link Type은 객체 사이의 관계다.

예시:

Person WORKS_AT Company
Document MENTIONS Person
ActionItem EXTRACTED_FROM Document
Opportunity SUPPORTED_BY MoneyHypothesis
RevenueEvent ATTRIBUTED_TO Opportunity
ActionItem TARGETS Company

Palantir 관점에서 Link는 그냥 그래프 edge가 아니라 앱과 워크플로우에서 탐색 가능한 관계다. Maester에서도 모든 edge가 recall에 노출될 필요는 없다.

권장:

strong edge
  사업 판단/실행/증거에 직접 필요한 관계

weak edge
  참고용 관계. hidden_from_recall=true 가능

derived edge
  추론으로 만든 관계. confidence 필요

v4.7에서 말한 Human Utility Edge Selection은 Palantir식 Ontology 관점에서 맞는 방향이다. edge 수를 고정 cap으로 자르는 게 아니라, 판단에 필요한 edge를 고르는 방식이어야 한다.

4. Action Type: 세계를 바꾸는 허용된 동사

Palantir에서 Action은 객체, 속성, 링크를 바꾸는 하나의 트랜잭션이다. 사용자는 "필드 A를 B로 바꿔라"가 아니라 "직원 배정하기", "알림 종료하기", "항공편 지연 처리하기"처럼 업무 언어로 행동한다.

Maester도 이 구조를 따라야 한다.

나쁜 ActionItem:

CPC가 중요하다
현장출격이 있었다
keeper-direct 방향이 바뀌었다

좋은 ActionItem:

혜성대표에게 토스 미팅 이후 탑다운 전환 기준으로 후속 제안서를 보내기
한화비전/키퍼 아웃바운드 에이전트 페이지의 첫 화면 카피를 확정하기
명함 QR 유입을 revenue_event로 기록하는 테스트 이벤트를 생성하기

좋은 ActionItem은 최소한 아래 필드를 갖는다.

verb_type
object
expected_outcome
evidence_span
source_doc_url
commercial_score
confidence
status

Action은 "추천"과 "적용"을 분리해야 한다.

candidate
  AI가 제안한 행동 후보

approved
  사람이 승인한 행동

applied
  실제 시스템/업무에 반영된 행동

done
  완료 증거가 붙은 행동

dropped
  실행판에서 제외한 행동

이 구분이 없으면 AI가 원문 요약을 행동으로 오인하거나, 연구 메모에서 나온 후보가 주간 실행판을 오염시킨다.

5. Function: 복잡한 판단을 코드로 봉인하는 층

Palantir Functions는 Ontology 객체를 읽고, 링크를 타고, 계산을 수행하고, 필요하면 Ontology edit까지 수행하는 서버 사이드 로직이다. TypeScript와 Python이 지원된다.

Maester에서 Function에 해당하는 것은 이런 것들이다.

recall(query)
select_human_utility_edges(...)
generate_weekly_action_board(...)
cluster_action_candidates(...)
score_action_quality(...)
record_revenue_event(...)
summary_ingest(...)

핵심은 LLM이 모든 판단을 즉흥적으로 하게 두지 않는 것이다.

LLM이 잘하는 것:

원문에서 의미 후보 추출
애매한 문맥 해석
한국어 자연어 요약
질문 의도 파악
후보 생성

Function이 책임져야 하는 것:

권한 확인
중복 방지
상태 전이 검증
스코어 계산 규칙
idempotency
감사 로그
데이터 쓰기
정책 위반 차단

즉 Maester는 "LLM이 직접 DB를 마음대로 만지는 구조"가 아니라 "LLM이 후보를 만들고 Function이 안전하게 적용하는 구조"가 되어야 한다.

6. AIP: AI를 운영 세계에 연결하는 층

AIP는 LLM을 단순 챗봇으로 쓰는 것이 아니라, 운영 객체와 행동 위에 올리는 계층이다.

공식 문서의 AIP 구성 요소를 Maester 언어로 바꾸면 다음과 같다.

AIP Logic
  LLM 기반 판단/변환/행동 제안 함수

AIP Agent Studio / Chatbot Studio
  운영 세계를 아는 에이전트/챗봇

AIP Evals
  비결정적인 LLM 판단을 테스트하고 회귀 방지

Automate
  조건이 맞으면 Action/Function/Notification 실행

Ontology MCP / Palantir MCP
  외부 AI가 안전하게 읽고 제한적으로 행동하게 하는 연결 표면

Maester에서 이 구조는 다음과 같이 대응된다.

summary_ingest
  AIP Logic에 가까움. 대화 원문을 운영 문서로 변환.

weekly/daily board
  운영 앱. 사람이 이번 주 할 일을 본다.

business_eval_v*
  AIP Evals에 가까움. recall/action 품질을 회귀 테스트.

revenue_event endpoint
  운영 결과를 다시 Ontology에 피드백.

MCP/API connector
  외부 AI가 Maester를 읽고 제한적으로 쓸 수 있는 표면.

7. Ontology MCP vs Palantir MCP에서 배울 것

공식 문서에서 중요한 구분이 있다.

Ontology MCP
  ontology consumer용
  외부 AI가 객체를 읽고, 정해진 action을 실행하고, query function을 호출
  application scope와 permission으로 제한
  production ontology data에 controlled write 가능

Palantir MCP
  ontology builder용
  object/link/action type 같은 구조를 만들고 수정
  production ontology data write가 목적이 아님

Maester도 이 구분을 그대로 가져와야 한다.

Maester connector 3분리

1. Maester Read Connector
   - recall
   - doc_get
   - board 조회
   - opportunity 조회
   - read token만 사용

2. Maester Summary Ingest Connector
   - 정리된 Markdown 문서 업로드
   - doc_type/source/project/importance 제한
   - summary_ingest 전용 token
   - action apply/doc delete/status 변경 금지

3. Maester Action Connector
   - 승인된 action/status/revenue_event만 처리
   - 별도 write token
   - idempotency, audit log, human approval guard 필수

현재 Maester에는 이미 POST /api/maester/ingest와 MCP maester_ingest가 있다. 하지만 Custom GPT나 Claude 커넥터에 광범위한 MAESTER_WRITE_TOKEN을 그대로 주는 것은 위험하다.

권장 다음 단계:

POST /api/maester/summary-ingest

token:
  MAESTER_SUMMARY_INGEST_TOKEN

허용:
  Markdown 문서 생성/업로드
  source/project/doc_type/importance 기록
  Document Bridge 결과 보고
  Context Bridge append

금지:
  Action apply
  doc delete
  status 변경
  Tiro auto-ingest
  revenue event 생성

8. Automate: 조건 기반 실행

Palantir Automate는 조건과 효과를 묶는다.

조건 예시:

매주 월요일 9시
priority=high인 Alert가 새로 생김
특정 object set의 count가 임계치 초과

효과 예시:

Foundry Action 제출
AIP Logic function 실행
Foundry Function 실행
알림/이메일 발송

Maester에서 Automate에 해당하는 후보:

매일 아침:
  daily board 생성

매주 일요일 밤:
  weekly execution board 생성

대화에서 "정리":
  summary_ingest 실행

RevenueEvent 발생:
  opportunity score 갱신
  관련 ActionItem 상태 재평가

ActionItem due가 지남:
  snooze / blocked / follow-up 후보 생성

하지만 자동화는 항상 권한과 승인 정책을 먼저 가져야 한다.

auto-ingest OFF
auto-apply OFF
human approval before business-changing writes

이 방향은 v4.6의 "승인 파일 없으면 apply 차단"과 일관된다.

9. AIP Evals: LLM 운영의 안전장치

LLM 기반 기능은 같은 입력에도 출력이 흔들릴 수 있다. Palantir AIP Evals는 이 문제를 다룬다.

Maester에서도 이미 Business Eval v*가 같은 역할을 하고 있다.

평가해야 할 축:

recall quality
  질문에 맞는 문서를 찾는가?

action quality
  실행 가능한 행동만 뽑는가?

money relevance
  돈 되는 흐름을 상위에 올리는가?

latency
  운영 사용에 충분히 빠른가?

write safety
  승인 없는 apply를 막는가?

regression
  새 기능이 기존 GOOD 10/10을 깨지 않는가?

v3.7 이후 Maester의 진화는 Palantir식으로 보면 타당하다.

v3.7 = recall quality
v3.8 = action candidate extraction
v3.9 = action quality and runtime truth
v4.0 = weekly execution board
v4.7 = HumanEval + MoneyHypothesis + Opportunity
v5.0 = revenue event capture

다음 평가는 summary_ingest에 맞춰야 한다.

정리 테스트:
  Claude App URL -> Markdown -> Maester doc -> Document Bridge -> Context Bridge

오염 방지:
  idea/research doc에서 active ActionItem 0

회상 검증:
  핵심 키워드로 recall top 5 안에 해당 문서 포함

보안 검증:
  summary token으로 action apply/doc delete/status update 불가

10. Anti-patterns: Maester가 피해야 할 것

10.1 System Silos

출처별 객체를 만들면 안 된다.

나쁜 예:

ClaudeAppDocument
ChatGPTDocument
ClaudeCodeDocument
GeminiDocument

좋은 예:

Document
  source=claude_app|chatgpt|claude_code|gemini

10.2 Kitchen Sink

모든 필드를 property로 승격하면 안 된다.

좋은 기준:

반복적으로 필터/정렬/랭킹/권한/액션에 쓰이는 것만 property
나머지는 원문/metadata/evidence에 둔다

10.3 Golden Hammer

모든 문제를 Action으로 풀면 안 된다.

구분:

Action
  사람이 승인하거나 실행해야 하는 업무 변화

Function
  계산/검증/스코어링/중복방지/정책 적용

Automation
  조건 기반 실행

Pipeline
  배치/정규화/인덱싱/백필

LLM
  의미 추출/요약/후보 생성

10.4 Time Machine

버전마다 새 객체를 만드는 방식은 조심해야 한다.

Maester 문서 버전:

Document
  current content

DocumentVersion or history
  previous content

기회/액션 상태:

Opportunity.status
ActionItem.status
RevenueEvent.created_at
HumanEvalEvent.created_at

현재 상태와 이력을 분리해야 한다.

11. Maester에 바로 적용할 설계 결론

11.1 Summary Ingest는 별도 쓰기 표면으로 만든다

현재 broad write token을 외부 AI에 주면 위험하다.

필요:

MAESTER_SUMMARY_INGEST_TOKEN
POST /api/maester/summary-ingest

허용 범위:

content_md 저장
metadata 저장
Document Bridge 업로드
Context Bridge append
idempotency check
action-policy none/candidate 적용

금지 범위:

Action apply
Action status update
doc delete
Tiro ingest
RevenueEvent 생성

11.2 "정리"는 운영 이벤트다

사용자가 어느 AI 앱에서든 정리라고 말하는 것은 단순 요약 요청이 아니다. 이것은 Maester 운영 세계에 새 Document를 넣는 이벤트다.

권장 흐름:

trigger: 정리
source adapter: claude_app | chatgpt_cdp | claude_code | file
renderer: standard markdown
ingest: summary-ingest
bridge: document bridge result
context: daily/master/session append
eval: recall + action pollution check

11.3 HumanEval은 랭킹의 1급 데이터다

Palantir Ontology가 사람의 행동과 결정을 운영 데이터로 포착하듯, Maester도 자동님의 평가를 별도 객체로 저장해야 한다.

HumanEvalEvent
  target_type
  target_id
  judgment
  reason
  score_delta
  query_context
  source
  created_at

이것은 commercial_score보다 상위 신호가 될 수 있다.

11.4 MoneyHypothesis와 Opportunity는 ActionItem보다 위다

ActionItem만 있으면 "할 일 목록"은 만들 수 있지만 "왜 돈 되는지"를 잃는다.

구조:

Opportunity
  사업 기회

MoneyHypothesis
  왜 돈이 될 수 있는지에 대한 가설

ActionItem
  그 가설을 검증/실행하기 위한 행동

RevenueEvent
  실제 결과

예시:

Opportunity:
  한화비전/키퍼 아웃바운드 에이전트 페이지 + 명함 QR + CPC/브랜드 콘텐츠 지원사격

MoneyHypothesis:
  오프라인 명함 접점과 온라인 전환 추적을 연결하면, 보안/설치/영상관제 수요를 빠르게 리드화할 수 있다.

ActionItem:
  명함 QR 랜딩의 첫 CTA와 revenue_event capture를 연결한다.

RevenueEvent:
  qr_scan, landing_view, cta_click, lead_submit

12. 구현 우선순위

P0. Summary Ingest Connector

POST /api/maester/summary-ingest
MAESTER_SUMMARY_INGEST_TOKEN
doc_type allowlist
source allowlist
idempotency: source + conversation_id + updated_at
action-policy default none for idea/research/chat_log

P1. Universal Summary CLI

python scripts/universal_summary_ingest.py \
  --source claude_app \
  --conversation-url "https://claude.ai/chat/..." \
  --project keeper-direct \
  --doc-type idea \
  --importance high \
  --action-policy none \
  --write-document-bridge \
  --write-context-bridge

P2. Custom GPT / Claude Connector Action

노출할 기능:

upload_markdown_summary
recall
doc_get

노출하지 말 것:

doc_delete
action_status_update
board_command
revenue_event
tiro_ingest

P3. Summary Ingest Eval

평가 쿼리:

정리한 Claude App 대화의 핵심 인물/회사/프로젝트를 찾아라
이번 주 돈 되는 일과 연결되는가?
아이디어 문서에서 실행판 active action이 생기지 않았는가?

P4. Palantir식 Ontology Cleanup

정기적으로 확인:

출처별 객체 중복이 생겼는가?
Document property가 너무 많아졌는가?
weak edge가 recall을 오염시키는가?
ActionItem이 요약문을 포함하는가?
Opportunity와 ActionItem의 관계가 끊겼는가?
HumanEval이 랭킹에 반영되는가?

13. 자동님용 짧은 독서 루트

시간이 30분이면:

1. Foundry platform summary for LLMs
2. Ontology Core Concepts
3. Ontology MCP Overview

시간이 2시간이면:

1. Foundry platform summary for LLMs
2. Ontology Overview
3. Core Concepts
4. Action Types Overview
5. Functions Overview
6. Ontology MCP Overview
7. AIP Evals Overview

시간이 반나절이면:

1. Foundry platform summary for LLMs
2. Ontology Overview / Core Concepts
3. Object Types / Link Types / Value Types
4. Action Types / Function-backed Actions
5. Functions
6. AIP Overview / AIP Features / AIP Architecture
7. AIP Logic / AIP Evals / Automate
8. OSDK / Ontology MCP
9. Best Practices and Anti-patterns

읽을 때 질문:

이 개념은 Maester에서 어떤 노드/엣지/액션/평가로 대응되는가?
AI가 읽기만 해야 하는가, 쓰기도 해야 하는가?
쓰기가 필요하면 어떤 좁은 토큰과 스코프가 필요한가?
사람 승인 없이 실행되면 위험한가?
이 데이터는 검색용인가, 실행용인가, 감사용인가?

14. 다음 Claude Code 작업지시 문장

Maester에 Palantir Foundry/AIP식 운영 온톨로지 패턴을 반영한다. 먼저 /api/maester/summary-ingest를 추가해 외부 Claude 커넥터/Custom GPT가 정리된 Markdown 문서만 업로드할 수 있는 좁은 쓰기 표면을 만든다. 기존 MAESTER_WRITE_TOKEN을 외부 앱에 주지 말고 MAESTER_SUMMARY_INGEST_TOKEN을 별도로 둔다. summary-ingest는 source/project/doc_type/importance/content_md/conversation_id/updated_at을 받고, idempotency는 source+conversation_id+updated_at으로 처리한다. idea/research/chat_log 문서는 action-policy none을 기본으로 하며, 자동 추출된 ActionItem이 생기면 삭제하지 말고 status=dropped로 soft-drop한다. doc_delete/action_status_update/board_command/revenue_event/tiro_ingest는 summary token으로 호출 불가해야 한다. 완료 후 Claude App URL 기반 universal_summary_ingest CLI MVP와 Business Eval을 작성하고, 문서 브릿지와 컨텍스트 브릿지 기록까지 검증한다. 데이터 삭제 금지, 시크릿 출력 금지, Tiro auto-ingest OFF 유지.

15. 결론

Palantir에서 가장 배울 점은 "데이터를 많이 모은다"가 아니다.

핵심은 이것이다.

현실 세계의 중요한 명사를 정한다.
명사 사이의 관계를 정한다.
사람과 AI가 할 수 있는 동사를 제한한다.
각 동사에 권한, 검증, 감사, 평가를 붙인다.
결과와 피드백을 다시 Ontology로 돌려보낸다.

Maester의 다음 방향도 같다.

Document memory
  -> Business Ontology
  -> Weekly Execution
  -> Revenue Feedback
  -> HumanEval Learning

따라서 지금 당장 필요한 것은 거대한 기능 추가가 아니라, 외부 AI가 안전하게 Maester에 문서를 넣는 좁은 쓰기 표면이다.

read connector
summary-ingest connector
action connector

이 세 가지를 분리하면 Claude App, ChatGPT Custom GPT, Codex, Claude Code가 모두 같은 Maester를 읽고 쓸 수 있다. 그리고 각 AI가 쓴 내용은 다시 문서 브릿지와 컨텍스트 브릿지를 통해 사람과 다른 AI가 이어받을 수 있다.