에이전틱 시스템은 데이터를 어떻게 배치해야 하는가 — 온톨로지 문제

에이전트 메모리 아키텍처 글에서 의미기억(semantic memory)을 “그래프·사실 테이블에 저장하고 사실 조회로 인출한다”고 한 줄로 적고 넘어갔다. 그 한 줄 안에 숨어 있던 질문이 이 글의 주제다 — 그 그래프의 노드는 무슨 타입이고, 엣지는 무슨 관계이며, 그 타입과 관계를 누가 정하는가. 이것이 온톨로지 문제이고, 메모리 문제보다 한 단계 위에 있다. 메모리는 “무엇을 저장할지”를 다루고, 온톨로지는 “저장할 수 있는 것의 형태 자체”를 다룬다.

1. 두 갈래 의미 — 정통 온톨로지와 업계 온톨로지

“온톨로지”라는 단어는 이 분야에서 두 가지 다른 것을 가리킨다.

정통적 의미. RDF·OWL·SHACL 같은 형식 언어로 쓰인 클래스·속성·관계· 제약·추론 규칙의 집합 — 논리적 추론과 일관성 검사를 지원하는 “설계도”다. 지식그래프는 그 설계도의 “인스턴스”(실제 데이터)이고, 택소노미는 is-a 계층만 있는 가장 단순한 특수 사례다.

2025~2026년 에이전틱 AI 업계에서 쓰는 느슨한 의미. OWL로 쓰였든 그냥 JSON 스키마나 Pydantic 모델이든 상관없이, 에이전트가 추론·행동할 수 있도록 허용된 타입화된 데이터 모델 전체를 가리킨다. Palantir, TypeDB, Zep이 이 어법을 쓴다. Palantir는 자사 Ontology를 object types(사물) · link types(관계) · action types(그 사물을 바꾸는 통제된 연산)라는 세 원소로 정의하면서, 이것이 “정적 데이터베이스 스키마”와 다른 이유는 동적 제어면(control surface)이기 때문이라고 명시한다. LLM·AIP 에이전트는 온톨로지의 객체·속성·링크에 명확한 비즈니스 의미가 부여돼 있기 때문에 자연어로 직접 질의하고 추론할 수 있다.

이 구분이 중요한 이유는, 메모리 포스트에서 만난 “의미기억”과 “지식그래프”가 사실은 저장 메커니즘이고, 온톨로지는 그 저장 메커니즘 위쪽의 설계 질문이라는 걸 분명히 해주기 때문이다 — 무엇을 저장할지 이전에, 저장 가능한 것의 형태 자체를 누가 정하느냐는 질문이다.

그라운딩과의 관계. LLM의 “고양이”라는 토큰과 실제 세계의 고양이가 안정적으로 연결되지 않으면, “고객 #4471”이라는 표현이 세션마다· 에이전트마다 다른 것을 가리킬 위험이 있다 — 상징 그라운딩 문제(symbol grounding problem)가 LLM 시대에 되살아난 형태다. 온톨로지는 이 문제에 대한 하나의 답이다 — 타입 있는 엔티티 ID와 관계를 부여함으로써, 에이전트가 매번 애매한 언어에서 정체성을 다시 유추하는 대신 고정된 참조 틀을 갖게 하는 것이다.

2. 쟁점 1 — 스키마 선결정 대 Emergent

가장 뜨거운 축이고, 구체적인 시스템들과 정확히 대응한다.

스키마 선결정(schema-first). Zep의 Entity Types는 Default(User, Preference 등 공통 타입)와 Custom(도메인별 Pydantic 모델로 정의) 두 층을 둔다. 커스텀 온톨로지를 정의하면 Zep의 추출 파이프라인이 그 타입을 우선해 추출하도록 초점을 좁혀, 더 관련성 높고 구조화된 데이터를 얻는다. Mem0도 대화에서 사실을 추출해 ADD/UPDATE/DELETE/NOOP로 관리하는 구조화된 파이프라인을 쓴다.

Emergent(schema-less). 메모리 포스트에서 다룬 A-Mem이 정반대 극단이다 — 제텔카스텐 방식으로, 새 메모리가 들어오면 문맥 기술·키워드· 태그를 담은 노트를 생성하고, 과거 메모리들과의 의미적 유사성을 분석해 링크를 형성하며, 새 메모리가 기존 메모리의 표현 자체를 갱신하기도 한다. 미리 정해진 스키마가 없고 네트워크 위상 자체가 창발한다.

절충. Zep의 엔진 Graphiti는 기본적으로 “들어오는 데이터를 기반으로 자동으로 온톨로지를 구축”하면서 노드 중복을 제거하고 엣지에 레이블을 붙인다 — schema-on-read를 기본값으로 하되, 커스텀 타입으로 선택적 제약을 걸 수 있는 중간 지점이다.

트레이드오프는 명확하다. schema-less/벡터 접근은 콜드스타트 비용이 0에 가깝고 이질적인 콘텐츠를 균일하게 다루지만 멀티홉 관계 추론에서 저하되고, schema-first/그래프 접근은 결정론적이고 감사 가능한 구조를 주지만 “그래프는 온톨로지 품질만큼만 좋다” — 온톨로지는 만들고 유지하는 비용이 크고, 스키마 진화는 전문가의 큐레이션을 요구하는데 대부분의 제품 팀에는 Cypher/SPARQL 전문성이 없다.

3. 쟁점 2 — 그래프 대 벡터 대 하이브리드

벡터DB는 임베딩 유사도 검색으로 빠르고 비정형 회상에 강하지만, 평평한 순위 목록만 반환할 뿐 관계를 순회할 수 없다 — “고객 X가 제품 Y를 쓰는데 그 제품에 심각한 장애 Z가 있었다” 같은 멀티홉 질의에서 막힌다. 지식그래프는 명시적 엔티티 관계를 순회해 결정론적이고 멀티홉이며 설명 가능하다.

GraphRAG는 이 둘을 결합한 하이브리드 응답으로 등장했다 — 그래프 순회와 벡터 검색을 결합해 비정형 콘텐츠 위에서 멀티홉 추론을 가능하게 한다. 전체 코퍼스의 의미 구조를 이해해야 하는 “전역적(global)” 질의에서 GraphRAG가 단순 RAG 대비 포괄성(comprehensiveness)·다양성 지표에서 70~80% 앞선다는 보고가 있다. 대가는 비용이다 — 초기 그래프 구축이 비싸다.

프로덕션에서 가장 흔한 패턴은, 대부분의 에이전트 프레임워크가 기본값 벡터 메모리(Pinecone, pgvector)로 시작해서 추론 요구가 커지면 하이브리드 (GraphRAG, Zep/Graphiti)로 넘어간다는 것 — 벡터로 넓은 후보군을 던지고 그래프 구조로 결과를 정제·관계 추론하는 순서다.

4. 쟁점 3 — 온톨로지 드리프트

메모리 포스트의 “의미 표류(semantic drift)”와 정확히 대응하는, 한 단계 위 레벨의 현상이다. 스키마 드리프트는 사람들이 그래프를 실제로 쓰는 방식이 바뀌는데 온톨로지가 그걸 따라가지 못할 때 일어난다 — 쿼리는 계속 돌아가고 결과도 그럴듯해 보이지만, 모델이 도메인과 조용히 어긋나기 시작한다. 온톨로지 기반 접근은 온톨로지 설계에 민감하고, 시간이 지날수록 유지 비용이 크며, 진화하는 용어와 코퍼스별 세분성 아래에서 깨지기 쉽다.

2026년의 연구적 대응은 KG 구축 자체를 에이전트화하는 것이다 — “스키마를 제안하는” 에이전트와 “기존 제약에 맞는지 검증하는” 에이전트를 분리해 수작업 ETL을 대체하려는 시도들이 나오고 있다. 다만 이건 문제를 없앤 게 아니라 한 단계 위로 미룬 것이다 — 이제는 에이전트가 온톨로지의 진화를 결정하고, 그 결정 자체에 다시 가드레일이 필요하다.

5. 쟁점 4 — 멀티에이전트 온톨로지 불일치

메모리 포스트가 단일 에이전트 관점이었다면, 이 쟁점은 여러 에이전트가 얽힐 때만 나타나는 문제라 상대적으로 덜 다뤄져 있다. TypeDB의 분석은 세 가지 구체적인 실패 양상을 짚는다.

툴 연합 격차(tool federation gap) — 두 에이전트가 같은 질문을 해도 서로 다른 도구 접근 권한을 가지고 있어 구조적으로 다른 답을 낸다.
온톨로지 버전 독립성 문제 — 한 에이전트는 “정거장 계층” 스키마 버전 1로 동작하고 다른 에이전트는 버전 2로 동작하는 걸 막을 메커니즘이 없다.
파라미터 자유 텍스트 편차(stringly-typed) — 도구 파라미터가 문자열 타입이면 에이전트마다 같은 개념을 “S1”, “CNC-Bay-1”, “North Machining Area”처럼 서로 다른 식별자로 부를 수 있다.

TypeDB는 에이전트가 안전하게 동작하려면 온톨로지가 명시적(에이전트가 직접 질의할 수 있어야), 질의 가능(질문하고 답을 받을 수 있어야), 강제 가능(잘못된 상태를 애초에 만들 수 없어야), 자기 탐색 가능(무슨 개념이 있고 어떻게 관계 맺는지 스스로 발견할 수 있어야) 네 조건을 만족해야 한다고 주장한다 — 지식그래프만으로는 에이전트가 자신의 행동을 검증할 하드코딩된 로직을 여전히 필요로 한다는 게 차이점이다.

학술적으로는 arXiv:2604.02369(Beyond Message Passing)가 A2A·MCP류를 포함한 18개 에이전트 통신 프로토콜을 통신·구문·의미 세 계층으로 나눠 분석한다. 결론은 전송·스트리밍·스키마 정의·생명주기 관리는 대부분 성숙해 있지만, 명료화·맥락 정합·검증 같은 의미 층위 메커니즘은 프로토콜 자체에 거의 없어서, 그 책임이 프롬프트나 임시방편적 오케스트레이션 코드로 떠밀리며 눈에 안 보이는 상호운용 비용을 만든다는 것이다. 이 논문은 1990년대의 KQML·FIPA-ACL — 의미적으로는 풍부했지만 개방적인 배포 환경엔 너무 경직됐던 과거의 멀티에이전트 통신 표준 — 을 역사적 선례로 다시 불러온다. “이 문제, 사실 처음이 아니다”라는 프레임이다.

6. 실무 답안들

Palantir Ontology — 온톨로지를 안전 계층으로 재정의

가장 눈에 띄는 실사례다. object types · link types · action types 세 원소로 구성되고, 모든 쓰기가 action type을 거쳐야 한다 — action type이 검증 규칙·승인·감사 추적·부작용 처리를 강제한다. 에이전트도 예외가 아니다: action type을 통해서만 행동할 수 있는 에이전트는 사람 운영자와 같은 검증·권한 범위 안에 갇히고, 그 행동은 같은 로그로 검토 가능하다. 즉 여기서 온톨로지는 지식 표현 문제가 아니라 접근 제어·감사(safety) 문제로 재정의된다 — 검색·추론 품질이 아니라 “에이전트가 세상을 바꿀 수 있는 유일한 문”을 정의하는 장치다.

TypeDB — “질의 가능한 인프라로서의 온톨로지”

타입 시스템 자체가 온톨로지이고, 규칙이 타입 시스템의 일부이기 때문에 잘못된 상태를 애초에 만들 수 없으며, 함수가 기존 관계에서 새 사실을 도출한다. 에이전트는 데이터뿐 아니라 “그 데이터에 의미를 부여하는 구조” 자체에 질의할 수 있다.

Zep / Graphiti — 시간 인식 그래프 + 선택적 제약

앞서 본 대로 기본은 자동 추론이지만, Default/Custom Entity Types로 도메인 정밀도를 얻을 수 있는 절충안. 메모리 포스트에서 다룬 시간 유효성(edge마다 유효 구간 타임스탬프)도 온톨로지 설계의 일부로 봐야 한다 — “이 관계가 언제까지 참이었는가”도 스키마가 표현해야 할 정보다.

Ontology-First Agent Design — “누가 온톨로지를 쓰는가”에 대한

가장 정교한 답

arXiv:2606.04903(Aaron Sterling, 2026)은 사람 전문가가 Basic Formal Ontology(BFO)로 문제 도메인을 온톨로지화하고, 그다음 LLM이 그 온톨로지에서 에이전트·human-in-the-loop 역할을 도출하는 4단계 방법론을 제시한다: (1) BFO로 문제 도메인 온톨로지화, (2) LLM이 그 온톨로지에서 자사 아키텍처(Agentic Redux)가 도울 수 있는 “도메인 지문”을 평가, (3) 지문이 있으면 LLM이 온톨로지를 코드(Domain Module)로 변환, (4) 그 모듈을 실행하고 결과를 관찰하며 필요하면 온톨로지를 다시 다듬는다. Agentic Redux는 타입 람다 계산으로 실행이 의미적으로 옳음을 증명하고, 모든 결정을 추가 전용(append-only) 원장에 기록한다 — 헬스케어 청구 컴플라이언스와 보안 취약점 공시라는 두 프로덕션급 도메인에서 검증됐다. 요약하면: 사람이 온톨로지의 뼈대를 한 번 설계하고, LLM이 그 안에서 추출·판단·실행을 맡는다.

AgentO — 프레임워크를 가로지르는 메타 온톨로지

앞의 셋이 “에이전트가 다룰 도메인 데이터”의 온톨로지라면, AgentO(ESWC 2026, Ekelhart 외, 빈 대학교)는 에이전틱 시스템 자체를 기술하는 OWL/RDF 온톨로지다 — 에이전트·태스크·워크플로·툴·자원 의존성 같은 개념. AutoGen·CrewAI·LangGraph·Mastra AI 저장소에서 수집한 에이전틱 패턴들을 LLM 기반 추출 파이프라인으로 RDF Turtle로 번역해 만들었다. 현재 프레임워크 구현 대부분이 “특정 모델 없이 임시방편적이고, 확장성·재사용성·상호운용성을 막는 단순한 자료구조와 모놀리식 설계에 의존한다”는 문제의식에서 출발한다 — 프레임워크 간에 통용되는 어휘를 표준화하려는 시도라는 점에서 5절의 멀티에이전트 불일치 문제와 직결된다.

7. 데이터는 실제로 어디에 배치되는가

사용자가 물은 질문 그 자체다. 온톨로지가 “사는” 곳은 세 가지 패턴으로 수렴한다.

별도의 스키마/컨텍스트 레지스트리. 용어·정의·출처·소유자·버전· 만료를 담은 정규 스키마를 데이터 자체와 분리해 질의 가능한 메타데이터 객체로 둔다. 에이전트는 행동하기 전에 이 레지스트리를 순회한다.
그래프 데이터베이스 안에 강제된 구조로. TypeDB식 접근 — 타입 시스템이 곧 온톨로지이므로 잘못된 상태 자체가 표현 불가능하다. 이와 대비되는 지식그래프는(타입 강제가 약하면) 에이전트가 자기 행동을 검증할 하드코딩된 로직을 여전히 따로 필요로 한다.
툴/API 스키마 자체가 사실상의 암묵적 온톨로지. function-calling 스키마(이름·설명·파라미터의 JSON Schema)가 실질적으로 에이전트가 추론할 수 있는 엔티티와 연산의 전체 집합을 정의한다 — LLM은 툴 정의가 서술하는 방식으로만 “무엇이 존재하는지” 알기 때문이다. 이 방식의 흥미로운 함의: 온톨로지가 매우 커지면, 실제 API/그래프 호출을 만들기 전에 온톨로지의 클래스·속성 설명 자체를 벡터 공간에 임베딩해 유사도 검색으로 관련 부분을 찾아내는 패턴이 나타난다 — 벡터가 온톨로지를 대체하는 게 아니라 온톨로지 위의 검색 인덱스로 쓰이는 것이다.

레이어드 아키텍처로 보면 세 소스가 독립적으로 같은 결론에 수렴한다: 상태/트랜잭션 레이어(관계형, 진행 중인 에이전트 상태와 동시 쓰기 처리) + 시맨틱/그래프 레이어(엔티티 관계, 멀티홉 순회) + 검색 레이어(벡터 인덱스, 넓은 의미 회상)를 하나 고르는 게 아니라 조합한다는 것이다. Neo4j의 “에이전틱 AI 세계의 시맨틱 레이어 여섯 차원” 프레임이 이걸 시간 순서로 정리한다: 정의(개념을 어떻게 정의하느냐가 에이전트가 무엇을 알 수 있는지 결정) → 발견(맥락이 얼마나 최신이고 완전한지 결정) → 표현(어떤 인출 패턴이 가능한지 결정) → 영속화(에이전트 응답의 회상률과 지연 결정) → 인출(응답의 관련성과 정확도 결정) → 관리(시맨틱 레이어가 신뢰할 수 있는 토대로 남을지, 혼란과 오류의 근원이 될지 결정). 벤더마다 어디에 무게를 두는지가 다르다 — RDF 중심 플랫폼은 형식적 엄밀성을, SQL 중심은 분석용 지표 일관성을, 그래프 네이티브는 관계 순회를, 벡터 우선은 대규모 의미 유사도를 우선시한다.

8. LLM은 온톨로지적 추론을 얼마나 잘하는가 — OntoURL이 보여준 것

“그냥 LLM이 알아서 스키마를 잡게 하면 안 되나”에 대한 실증적 반박 근거가 있다. OntoURL(arXiv:2505.11031)은 40개 실제 온톨로지(8개 도메인)에서 뽑은 57,303개 질문, 15개 과제로 LLM의 온톨로지 이해· 추론·학습 능력을 세 축으로 나눠 평가한 첫 종합 벤치마크다. 20개 오픈소스 LLM을 테스트한 결과, 현재 LLM은 온톨로지적 지식을 이해하는 데는 어느 정도 역량을 보이지만 추론과 학습 과제에서는 약점을 드러냈다. 사람과 비교한 실험에서는 LLM이 이해·추론 과제에서는 사람을 앞섰지만, 대부분의 학습 과제에서는 사람에 미치지 못했다. subsumption(상위 개념 포함 관계)이나 disjointness(배타성) 같은 형식적 의미론에 대한 LLM의 “타고난 감각”이 아직 제한적이라는 뜻이고, 이는 “스키마 자체를 LLM에게 통째로 맡기자”는 입장에 대한 구체적인 반례로 읽을 수 있다.

9. 열린 문제

누가 온톨로지를 쓰는가. Ontology-First Agent Design이 제시하는 분업 — 사람이 뼈대를 한 번 쓰고, LLM이 추출·유지·중간 판단을 전담하고, 사람이 피드백 루프로 다듬는다 — 이 현재로선 가장 정교한 답이지만, 이게 얼마나 스케일하는지는 검증되지 않았다.
침묵하는 실패. 여러 소스가 같은 이야기를 한다 — 나쁘거나 낡은(drift된) 온톨로지는 시스템을 크래시시키지 않는다. 쿼리는 계속 돌아가고 답은 그럴듯해 보인다. 메모리 포스트에서 본 “의미 표류”와 똑같은 결이지만, 이번엔 사실이 아니라 사실이 담기는 틀 자체가 조용히 어긋난다는 점이 더 근본적이다.
버저닝과 멀티에이전트 일관성. “에이전트들이 같은 버전의 도메인 정의를 공유하도록 보장하는 메커니즘이 없다”는 건 설계 선택의 문제가 아니라 아직 안 풀린 인프라 문제로 계속 지목되고 있다.
온톨로지 vs 세계 모델의 긴장. 더 철학적인 층위에서, 효율적으로 행동하도록 최적화된 에이전트가 온톨로지가 전제하는 “완전한” 상태 공간에서 점점 멀어질 수 있다는 지적도 있다 — 행동에 최적화된 모델과 세계를 충실히 표현하려는 모델은 다른 목적함수를 갖는다.

10. 한국어 자료 현황

디지털데일리·아이티데일리 등이 이미 “온톨로지 = 에이전틱 AI 필수 요소”라는 프레이밍을 다뤘고, 티타임즈의 김학래(중앙대) 교수 인터뷰가 가장 구체적이다 — AI에 투입되는 데이터를 색인·연결해 오류 없는 “지식”으로 바꾸는 작업이 온톨로지이며, 비즈니스 영역을 명시적으로 구축하고 정확한 규칙을 정해줘야만 에이전틱·피지컬 AI가 실제로 작동한다는 요지다. 다만 이런 기사들은 대체로 비즈니스 케이스·설명 수준에 머물러 있고, 이 글에서 다룬 schema-first 대 emergent, 온톨로지 드리프트, 멀티에이전트 스키마 불일치 같은 기술적 쟁점까지 들어가는 한국어 자료는 아직 눈에 띄지 않는다.

마무리

메모리 포스트가 “무엇을 어디에 저장할지”를 다뤘다면, 이 글은 그 저장소가 이해할 수 있는 형태를 누가 정하는지를 다룬다. 결론은 메모리 문제와 구조적으로 같다 — 스키마 선결정이냐 emergent냐, 그래프냐 벡터냐, 사람이 쓰느냐 LLM이 쓰느냐는 전부 아키텍처 결정이고, 기본값 으로는 올바르게 내려지지 않는다. 다른 점은, 온톨로지가 틀리면 실패가 개별 사실의 오류가 아니라 그 위에서 만들어지는 모든 추론의 오류로 번진다는 것이다.

References

Palantir. Ontology — Overview (Foundry docs). palantir.com/docs/foundry/ontology/overview
Palantir Blog. Connecting Agents to Decisions. blog.palantir.com
TypeDB Blog. Why agents need ontologies. typedb.com/blog/why-agents-need-ontologies
Zep Blog. Introducing Entity Types: Structured Memory for Agents. blog.getzep.com
Sterling, A. (2026). Provably Auditable and Safe LLM Agents from Human-Authored Ontologies. arXiv:2606.04903
Beyond Message Passing: A Semantic View of Agent Communication Protocols (2026). arXiv:2604.02369
Ekelhart, A., Kurniawan, K., Ekaputra, F. J., & Kiesling, E. (2026). AgentO: An Ontology for Modeling Agentic AI Systems. ESWC 2026. link.springer.com · project site
Zhang, X., Lai, H., Meng, Q., & Bos, J. (2025). OntoURL: A Benchmark for Evaluating Large Language Models on Symbolic Ontological Understanding, Reasoning and Learning. arXiv:2505.11031
Xu, W., et al. A-MEM: Agentic Memory for LLM Agents. arXiv:2502.12110
Dathar, P. (2026). Six Dimensions of the Semantic Layer in Agentic AI World. Neo4j Developer Blog. medium.com/neo4j
Atlan. Vector Database vs Knowledge Graph: Choosing for Agent Memory. atlan.com
티타임즈. “온톨로지를 알아야 에이젠틱AI 할 수 있다” — 김학래 중앙대 교수 인터뷰 (2026). ttimes.co.kr
이 블로그: 에이전트 메모리 아키텍처 — 의미기억·지식그래프를 저장 메커니즘으로 다룬 전편.