Skip to content

Ontology

  • Published on
    고객사의 도메인 지식은 대개 문서가 아니라 사람 머릿속에 암묵지로 있습니다. Forward Deployed Engineer의 핵심 작업 하나는 이 흩어진 암묵지를 팀이 공유하는 명시적 모델로 바꾸는 것입니다. 이 글은 가장 싸고 값진 첫걸음인 DDD의 유비쿼터스 언어에서 출발해, 바운디드 컨텍스트로 같은 단어의 충돌을 다루고, 엔티티·값 객체·애그리게이트로 명사를 모델링합니다. 그다음 사람들이 자주 뒤섞는 세 단어 — 택소노미, 온톨로지, 지식 그래프 — 를 구분하고, 형식 스택(RDF/RDFS/OWL과 schema.org)과 운영 스택(프로퍼티 그래프와 Palantir Foundry의 객체·링크·액션)을 나란히 놓습니다. 마지막으로 정직하게 말합니다. 온톨로지는 과설계되기 가장 쉬운 산출물이고, 가장 흔한 실패는 아름답지만 아무도 안 쓰는 온톨로지라는 것. 그래서 개념이 아니라 비즈니스가 실제로 던지는 질문에서 시작해야 한다는 것.
  • Published on
    그래프 데이터베이스, RDF·온톨로지 스택, 그래프 RAG 프레임워크는 지난 2년 사이 폭발적으로 늘었습니다. 링크 목록은 이미 많으니, 이 글은 대신 정직하게 의견을 담은 지도를 그립니다. 카테고리마다 무엇에 쓰는지, 대표 도구 두세 개, 그리고 "언제 무엇을 고를지"를 분명히 말합니다 — 임베디드(Kùzu) vs 서버(Neo4j), 형식 OWL/RDF vs 실용 프로퍼티 그래프, 직접 짜는 추출 파이프라인 vs Microsoft GraphRAG의 배터리 포함 파이프라인. 그리고 가장 중요한 질문: 애초에 그래프를 쓰지 말아야 할 때(벡터 RAG로 충분한 경우)는 언제인가. 작은 결정 흐름으로 시리즈를 닫습니다. 모든 도구는 실제로 존재하는지 확인했고, 성숙도와 포지셔닝을 부풀리지 않았습니다 — Kùzu가 2025년 아카이브된 사실까지 포함해서.
  • Published on
    Palantir Technologies의 비즈니스 모델을 심층 분석합니다. Gotham, Foundry, AIP 세 가지 핵심 플랫폼부터 온톨로지(Ontology) 개념이 만드는 기술적 해자, 정부/상업 매출 구조, Forward Deployed Engineers 모델, 그리고 경쟁사 대비 포지셔닝까지 다룹니다.