--- title: "Palantir Foundry/AIP 한국어 가이드 — Maester 설계를 위한 실전 독서노트" from: codex to: ["jadong", "claude-code", "codex"] project: "maester" date: 2026-05-09T20:08:25.797770+09:00 status: sent type: report --- --- title: "Palantir Foundry/AIP 한국어 가이드: Maester 설계를 위한 실전 독서노트" created_at: "2026-05-09T20:05:00+09:00" updated_at: "2026-05-09T20:05:00+09:00" author: "Codex CLI" source_type: "official_docs_synthesis" language: "ko" project: "maester" doc_type: "research_guide" copyright_note: "공식 Palantir 문서의 원문 전체 번역이 아니라, 공개 문서를 근거로 한 한국어 해설/요약/설계 적용 노트다." --- # Palantir Foundry/AIP 한국어 가이드 ## Maester 설계를 위한 실전 독서노트 ### BLUF Palantir의 핵심은 "데이터 저장소"가 아니라 "운영 세계를 표현하는 Ontology"다. Foundry는 데이터를 연결하고, Ontology는 현실의 명사와 관계와 행동을 모델링하며, AIP는 LLM과 에이전트를 그 운영 모델 위에서 안전하게 움직이게 한다. Maester가 배워야 할 구조는 단순하다. ```text 기억 원문(Document) -> 현실 객체(Object) -> 관계(Link) -> 실행 가능한 행동(Action) -> 함수/정책/권한(Function, Guardrail) -> 평가와 피드백(Eval, Observability) ``` 즉 Maester는 "검색 잘 되는 메모장"에서 멈추면 안 된다. 자동님의 사업 세계를 `사람`, `회사`, `기회`, `가설`, `액션`, `결과`, `피드백`으로 모델링하고, AI가 그 위에서 안전하게 읽고 제한적으로 쓰게 해야 한다. --- # 1. 먼저 읽을 공식 문서 이 문서는 아래 공개 공식 문서를 기준으로 한국어로 재구성했다. ## 핵심 입문 - Foundry platform summary for LLMs https://www.palantir.com/docs/foundry/getting-started/foundry-platform-summary-llm - Palantir platform documentation home https://www.palantir.com/docs/ ## Ontology - Ontology Overview https://www.palantir.com/docs/foundry/ontology/overview - Ontology Core Concepts https://www.palantir.com/docs/foundry/ontology/core-concepts - Ontology Best Practices and Anti-patterns https://www.palantir.com/docs/foundry/ontology/ontology-best-practices-and-anti-patterns - Object Types Overview https://www.palantir.com/docs/foundry/object-link-types/object-types-overview - Link Types Overview https://www.palantir.com/docs/foundry/object-link-types/link-types-overview - Value Types Overview https://www.palantir.com/docs/foundry/object-link-types/value-types-overview ## Actions / Functions / Automation - Action Types Overview https://www.palantir.com/docs/foundry/action-types/overview - Workshop Actions Overview https://www.palantir.com/docs/foundry/workshop/actions-overview - Function-backed Actions Overview https://www.palantir.com/docs/foundry/action-types/function-actions-overview - Functions Overview https://www.palantir.com/docs/foundry/functions/overview - Automate Overview https://www.palantir.com/docs/foundry/automate/overview ## AIP / AI Agents - AIP Overview https://www.palantir.com/docs/foundry/aip/overview - AIP Features https://www.palantir.com/docs/foundry/aip/aip-features - AIP Architecture https://www.palantir.com/docs/foundry/architecture-center/aip-architecture - AIP Logic Overview https://www.palantir.com/docs/foundry/logic - AIP Evals Overview https://www.palantir.com/docs/foundry/aip-evals/overview ## Developer Toolchain / External AI - Ontology SDK Overview https://www.palantir.com/docs/foundry/ontology-sdk/overview - Ontology MCP Overview https://www.palantir.com/docs/foundry/ontology-mcp/overview --- # 2. Palantir를 한 장으로 이해하기 Palantir 플랫폼은 크게 세 층으로 이해하면 된다. ```text Apollo 소프트웨어 배포/운영 계층 Foundry 데이터 운영 계층 AIP 생성형 AI와 에이전트를 운영 세계에 연결하는 계층 ``` 그 중심에 Ontology가 있다. Ontology는 단순 그래프가 아니다. 조직의 현실 세계를 AI와 사람이 같이 쓸 수 있게 모델링한 운영 계층이다. Palantir 문서의 표현을 Maester 관점으로 바꾸면 이렇다. ```text Object = 현실의 명사 Property = 명사의 상태/속성 Link = 명사 사이의 관계 Action = 세계를 바꾸는 허용된 동사 Function = 복잡한 판단/계산/편집 로직 Permission = 누가 무엇을 읽고 쓸 수 있는가 Eval = AI가 제대로 판단했는가 Audit = 누가 언제 무엇을 왜 바꿨는가 ``` Maester에서 이 구조는 다음과 같이 대응된다. ```text 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에서는 이런 객체들이 중요하다. ```text Person Company Project Opportunity MoneyHypothesis ActionItem Document Conversation RevenueSprintBoard RevenueConversionEvent ``` 중요한 원칙은 시스템이 아니라 현실을 모델링하는 것이다. 나쁜 모델링: ```text ClaudeAppPerson ChatGPTPerson KakaoPerson CRMCompany SpreadsheetCompany ``` 좋은 모델링: ```text Person Company Conversation Document ``` 출처가 다르면 `source`나 `provenance`로 남기면 된다. 객체 자체를 출처별로 쪼개면 현실이 아니라 저장소 구조를 모델링하게 된다. ## 3.2 Property Property는 객체의 속성이다. 예시: ```text Company.name Company.domain Company.stage Opportunity.priority Opportunity.human_money_score ActionItem.status ActionItem.expected_outcome ``` 여기서 중요한 것은 "언젠가 쓸지도 몰라서 다 넣기"를 피하는 것이다. Palantir 문서가 말하는 kitchen sink anti-pattern이 여기다. Maester에서도 무작정 모든 추출 필드를 속성으로 올리면 검색/랭킹/보드가 더러워진다. 속성으로 승격할 기준: ```text 사람이 검색/필터링/정렬에 쓸 것인가? 액션 결정에 영향을 주는가? 권한/보안/감사에 필요한가? 사업 판단에 반복적으로 쓰이는가? ``` 그렇지 않으면 원문 `Document.content_md`나 `metadata`에 두고, 핵심 속성만 Ontology 레벨로 올린다. ## 3.3 Link Type Link Type은 객체 사이의 관계다. 예시: ```text 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에 노출될 필요는 없다. 권장: ```text 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: ```text CPC가 중요하다 현장출격이 있었다 keeper-direct 방향이 바뀌었다 ``` 좋은 ActionItem: ```text 혜성대표에게 토스 미팅 이후 탑다운 전환 기준으로 후속 제안서를 보내기 한화비전/키퍼 아웃바운드 에이전트 페이지의 첫 화면 카피를 확정하기 명함 QR 유입을 revenue_event로 기록하는 테스트 이벤트를 생성하기 ``` 좋은 ActionItem은 최소한 아래 필드를 갖는다. ```text verb_type object expected_outcome evidence_span source_doc_url commercial_score confidence status ``` Action은 "추천"과 "적용"을 분리해야 한다. ```text candidate AI가 제안한 행동 후보 approved 사람이 승인한 행동 applied 실제 시스템/업무에 반영된 행동 done 완료 증거가 붙은 행동 dropped 실행판에서 제외한 행동 ``` 이 구분이 없으면 AI가 원문 요약을 행동으로 오인하거나, 연구 메모에서 나온 후보가 주간 실행판을 오염시킨다. --- # 5. Function: 복잡한 판단을 코드로 봉인하는 층 Palantir Functions는 Ontology 객체를 읽고, 링크를 타고, 계산을 수행하고, 필요하면 Ontology edit까지 수행하는 서버 사이드 로직이다. TypeScript와 Python이 지원된다. Maester에서 Function에 해당하는 것은 이런 것들이다. ```text recall(query) select_human_utility_edges(...) generate_weekly_action_board(...) cluster_action_candidates(...) score_action_quality(...) record_revenue_event(...) summary_ingest(...) ``` 핵심은 LLM이 모든 판단을 즉흥적으로 하게 두지 않는 것이다. LLM이 잘하는 것: ```text 원문에서 의미 후보 추출 애매한 문맥 해석 한국어 자연어 요약 질문 의도 파악 후보 생성 ``` Function이 책임져야 하는 것: ```text 권한 확인 중복 방지 상태 전이 검증 스코어 계산 규칙 idempotency 감사 로그 데이터 쓰기 정책 위반 차단 ``` 즉 Maester는 "LLM이 직접 DB를 마음대로 만지는 구조"가 아니라 "LLM이 후보를 만들고 Function이 안전하게 적용하는 구조"가 되어야 한다. --- # 6. AIP: AI를 운영 세계에 연결하는 층 AIP는 LLM을 단순 챗봇으로 쓰는 것이 아니라, 운영 객체와 행동 위에 올리는 계층이다. 공식 문서의 AIP 구성 요소를 Maester 언어로 바꾸면 다음과 같다. ```text AIP Logic LLM 기반 판단/변환/행동 제안 함수 AIP Agent Studio / Chatbot Studio 운영 세계를 아는 에이전트/챗봇 AIP Evals 비결정적인 LLM 판단을 테스트하고 회귀 방지 Automate 조건이 맞으면 Action/Function/Notification 실행 Ontology MCP / Palantir MCP 외부 AI가 안전하게 읽고 제한적으로 행동하게 하는 연결 표면 ``` Maester에서 이 구조는 다음과 같이 대응된다. ```text 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에서 배울 것 공식 문서에서 중요한 구분이 있다. ```text 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분리 ```text 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`을 그대로 주는 것은 위험하다. 권장 다음 단계: ```text 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는 조건과 효과를 묶는다. 조건 예시: ```text 매주 월요일 9시 priority=high인 Alert가 새로 생김 특정 object set의 count가 임계치 초과 ``` 효과 예시: ```text Foundry Action 제출 AIP Logic function 실행 Foundry Function 실행 알림/이메일 발송 ``` Maester에서 Automate에 해당하는 후보: ```text 매일 아침: daily board 생성 매주 일요일 밤: weekly execution board 생성 대화에서 "정리": summary_ingest 실행 RevenueEvent 발생: opportunity score 갱신 관련 ActionItem 상태 재평가 ActionItem due가 지남: snooze / blocked / follow-up 후보 생성 ``` 하지만 자동화는 항상 권한과 승인 정책을 먼저 가져야 한다. ```text 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*`가 같은 역할을 하고 있다. 평가해야 할 축: ```text recall quality 질문에 맞는 문서를 찾는가? action quality 실행 가능한 행동만 뽑는가? money relevance 돈 되는 흐름을 상위에 올리는가? latency 운영 사용에 충분히 빠른가? write safety 승인 없는 apply를 막는가? regression 새 기능이 기존 GOOD 10/10을 깨지 않는가? ``` v3.7 이후 Maester의 진화는 Palantir식으로 보면 타당하다. ```text 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`에 맞춰야 한다. ```text 정리 테스트: 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 출처별 객체를 만들면 안 된다. 나쁜 예: ```text ClaudeAppDocument ChatGPTDocument ClaudeCodeDocument GeminiDocument ``` 좋은 예: ```text Document source=claude_app|chatgpt|claude_code|gemini ``` ## 10.2 Kitchen Sink 모든 필드를 property로 승격하면 안 된다. 좋은 기준: ```text 반복적으로 필터/정렬/랭킹/권한/액션에 쓰이는 것만 property 나머지는 원문/metadata/evidence에 둔다 ``` ## 10.3 Golden Hammer 모든 문제를 Action으로 풀면 안 된다. 구분: ```text Action 사람이 승인하거나 실행해야 하는 업무 변화 Function 계산/검증/스코어링/중복방지/정책 적용 Automation 조건 기반 실행 Pipeline 배치/정규화/인덱싱/백필 LLM 의미 추출/요약/후보 생성 ``` ## 10.4 Time Machine 버전마다 새 객체를 만드는 방식은 조심해야 한다. Maester 문서 버전: ```text Document current content DocumentVersion or history previous content ``` 기회/액션 상태: ```text Opportunity.status ActionItem.status RevenueEvent.created_at HumanEvalEvent.created_at ``` 현재 상태와 이력을 분리해야 한다. --- # 11. Maester에 바로 적용할 설계 결론 ## 11.1 Summary Ingest는 별도 쓰기 표면으로 만든다 현재 broad write token을 외부 AI에 주면 위험하다. 필요: ```text MAESTER_SUMMARY_INGEST_TOKEN POST /api/maester/summary-ingest ``` 허용 범위: ```text content_md 저장 metadata 저장 Document Bridge 업로드 Context Bridge append idempotency check action-policy none/candidate 적용 ``` 금지 범위: ```text Action apply Action status update doc delete Tiro ingest RevenueEvent 생성 ``` ## 11.2 "정리"는 운영 이벤트다 사용자가 어느 AI 앱에서든 `정리`라고 말하는 것은 단순 요약 요청이 아니다. 이것은 Maester 운영 세계에 새 `Document`를 넣는 이벤트다. 권장 흐름: ```text 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도 자동님의 평가를 별도 객체로 저장해야 한다. ```text HumanEvalEvent target_type target_id judgment reason score_delta query_context source created_at ``` 이것은 commercial_score보다 상위 신호가 될 수 있다. ## 11.4 MoneyHypothesis와 Opportunity는 ActionItem보다 위다 ActionItem만 있으면 "할 일 목록"은 만들 수 있지만 "왜 돈 되는지"를 잃는다. 구조: ```text Opportunity 사업 기회 MoneyHypothesis 왜 돈이 될 수 있는지에 대한 가설 ActionItem 그 가설을 검증/실행하기 위한 행동 RevenueEvent 실제 결과 ``` 예시: ```text Opportunity: 한화비전/키퍼 아웃바운드 에이전트 페이지 + 명함 QR + CPC/브랜드 콘텐츠 지원사격 MoneyHypothesis: 오프라인 명함 접점과 온라인 전환 추적을 연결하면, 보안/설치/영상관제 수요를 빠르게 리드화할 수 있다. ActionItem: 명함 QR 랜딩의 첫 CTA와 revenue_event capture를 연결한다. RevenueEvent: qr_scan, landing_view, cta_click, lead_submit ``` --- # 12. 구현 우선순위 ## P0. Summary Ingest Connector ```text 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 ```bash 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 노출할 기능: ```text upload_markdown_summary recall doc_get ``` 노출하지 말 것: ```text doc_delete action_status_update board_command revenue_event tiro_ingest ``` ## P3. Summary Ingest Eval 평가 쿼리: ```text 정리한 Claude App 대화의 핵심 인물/회사/프로젝트를 찾아라 이번 주 돈 되는 일과 연결되는가? 아이디어 문서에서 실행판 active action이 생기지 않았는가? ``` ## P4. Palantir식 Ontology Cleanup 정기적으로 확인: ```text 출처별 객체 중복이 생겼는가? Document property가 너무 많아졌는가? weak edge가 recall을 오염시키는가? ActionItem이 요약문을 포함하는가? Opportunity와 ActionItem의 관계가 끊겼는가? HumanEval이 랭킹에 반영되는가? ``` --- # 13. 자동님용 짧은 독서 루트 시간이 30분이면: ```text 1. Foundry platform summary for LLMs 2. Ontology Core Concepts 3. Ontology MCP Overview ``` 시간이 2시간이면: ```text 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 ``` 시간이 반나절이면: ```text 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 ``` 읽을 때 질문: ```text 이 개념은 Maester에서 어떤 노드/엣지/액션/평가로 대응되는가? AI가 읽기만 해야 하는가, 쓰기도 해야 하는가? 쓰기가 필요하면 어떤 좁은 토큰과 스코프가 필요한가? 사람 승인 없이 실행되면 위험한가? 이 데이터는 검색용인가, 실행용인가, 감사용인가? ``` --- # 14. 다음 Claude Code 작업지시 문장 ```text 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에서 가장 배울 점은 "데이터를 많이 모은다"가 아니다. 핵심은 이것이다. ```text 현실 세계의 중요한 명사를 정한다. 명사 사이의 관계를 정한다. 사람과 AI가 할 수 있는 동사를 제한한다. 각 동사에 권한, 검증, 감사, 평가를 붙인다. 결과와 피드백을 다시 Ontology로 돌려보낸다. ``` Maester의 다음 방향도 같다. ```text Document memory -> Business Ontology -> Weekly Execution -> Revenue Feedback -> HumanEval Learning ``` 따라서 지금 당장 필요한 것은 거대한 기능 추가가 아니라, 외부 AI가 안전하게 Maester에 문서를 넣는 좁은 쓰기 표면이다. ```text read connector summary-ingest connector action connector ``` 이 세 가지를 분리하면 Claude App, ChatGPT Custom GPT, Codex, Claude Code가 모두 같은 Maester를 읽고 쓸 수 있다. 그리고 각 AI가 쓴 내용은 다시 문서 브릿지와 컨텍스트 브릿지를 통해 사람과 다른 AI가 이어받을 수 있다.