태그: #ontology

← 전체 글

• 팔란티어 온톨로지 — 데이터 위에 "행동" 을 얹은 운영 계층을 공식 문서로 읽는다 ♪ 들을 수 있어요

  팔란티어가 말하는 온톨로지는 철학 용어가 아니라 제품의 한 층이다. 객체·속성·링크(의미)와 액션·함수(운동)라는 여섯 조각, 데이터셋이 객체가 되는 경로, 사용자 편집이 원본과 충돌할 때의 규칙, 규모 상한과 OSv1 폐기 일정, 그리고 LLM 이 그 위에서 어떻게 도구를 쓰는지를 팔란티어 공식 문서의 문장으로만 정리한다.

  2026-09-11 · 15 분 읽기 #palantir#ontology#foundry#aip#data-platform

• 도메인 지식이 왜 방어선인가 — 업을 아는 엔지니어와 기술만 아는 엔지니어

  도메인 지식은 코드에도 문서에도 없고 사람과 관행에만 있습니다. 그래서 이 시리즈가 말해 온 검증 비용을 가장 비싸게 만드는 요인이자, 그 비용을 감당할 수 있는 사람이 남는 이유입니다. 이 글은 업을 아는 엔지니어가 질문과 예외와 요구 해석에서 무엇을 다르게 하는지, 회의에서 쓰는 말과 코드에 있는 이름이 어긋날 때 무엇이 깨지는지, 도메인을 익히는 여섯 단계 절차, 그리고 도메인 지식이

  2026-08-15 · 14 분 읽기 #career#skills#domain-knowledge#ddd#ontology

• 지식 그래프 도구·프레임워크 지도 — 무엇을 언제 고르나

  그래프 데이터베이스, RDF·온톨로지 스택, 그래프 RAG 프레임워크는 지난 2년 사이 폭발적으로 늘었습니다. 링크 목록은 이미 많으니, 이 글은 대신 정직하게 의견을 담은 지도를 그립니다. 카테고리마다 무엇에 쓰는지, 대표 도구 두세 개, 그리고 "언제 무엇을 고를지"를 분명히 말합니다 — 임베디드(Kùzu) vs 서버(Neo4j), 형식 OWL/RDF vs 실용 프로퍼티 그래프, 직접 짜

  2026-07-15 · 18 분 읽기 #tools#knowledge-graph#graph-rag#ontology#frameworks

• 고객의 도메인을 모델로 — 유비쿼터스 언어에서 온톨로지까지

  고객사의 도메인 지식은 대개 문서가 아니라 사람 머릿속에 암묵지로 있습니다. Forward Deployed Engineer의 핵심 작업 하나는 이 흩어진 암묵지를 팀이 공유하는 명시적 모델로 바꾸는 것입니다. 이 글은 가장 싸고 값진 첫걸음인 DDD의 유비쿼터스 언어에서 출발해, 바운디드 컨텍스트로 같은 단어의 충돌을 다루고, 엔티티·값 객체·애그리게이트로 명사를 모델링합니다. 그다음 사람들

  2026-07-15 · 21 분 읽기 #ontology#knowledge-graph#domain-driven-design#architecture#forward-deployed-engineer

• Palantir 비즈니스 모델, 온톨로지 플랫폼, 그리고 경쟁 해자 분석

  Palantir Technologies의 비즈니스 모델을 심층 분석합니다. Gotham, Foundry, AIP 세 가지 핵심 플랫폼부터 온톨로지(Ontology) 개념이 만드는 기술적 해자, 정부/상업 매출 구조, Forward Deployed Engineers 모델, 그리고 경쟁사 대비 포지셔닝까지 다룹니다.

  2026-03-07 · 25 분 읽기 #palantir#finance#business-model#ontology#competitive-moat