지식그래프에 온톨로지를 얹었더니, 같은 질의에서 답이 달라졌다
노드는 많은데, 질의가 안 먹힌다
지식그래프를 처음 만들 때는 단순하게 시작했습니다. 문서에서 엔티티를 추출하고, 관계를 뽑아서 Neo4j에 넣는 거예요. "Person → WORKS_AT → Organization" 같은 트리플이 쌓이면 그래프가 만들어지니까, 데이터만 충분하면 질의도 잘 될 거라고 생각했거든요.
노드가 수백 개, 관계가 수천 개가 되니까 그래프는 꽤 그럴듯해 보였습니다. 그런데 실제로 질의를 해보면 이상한 일이 생기더라고요.
"이 시스템에 연결된 서비스를 알려줘"라고 물으면, 기대한 답이 안 나옵니다. 어떤 노드는 System이라는 라벨이 붙어 있고, 어떤 노드는 Server라고 돼 있고, 또 어떤 노드는 Infrastructure로 잡혀 있어요. 같은 종류인데 LLM이 문서마다 다른 이름으로 추출한 겁니다.
관계도 마찬가지였어요. "연결된"이라는 의미를 어떤 문서에서는 CONNECTS_TO로, 어떤 문서에서는 LINKED_WITH로, 또 어떤 문서에서는 HAS_DEPENDENCY로 추출했거든요. 의미가 같은데 라벨이 다르니까, Cypher 쿼리를 써도 전체를 못 잡습니다.
사용자 입장에서는 "질문했는데 답이 빠져 있다"는 경험이 되고, 운영자 입장에서는 "왜 이 노드가 안 걸리지?"를 디버깅해야 하는 상황이 됩니다.
그래프DB에 데이터만 넣으면 생기는 일
이 문제를 겪으면서 정리해보니, 온톨로지 없이 그래프만 만들면 세 가지가 동시에 무너지더라고요.
첫째, 같은 개념이 여러 이름으로 존재합니다. LLM은 문서마다 독립적으로 추출하니까, "서버"를 Server라고 부르기도 하고 System이라고 부르기도 합니다. 사람이라면 문맥을 보고 같은 거라고 판단하겠지만, 그래프 쿼리는 라벨이 정확히 일치해야 결과가 나오거든요.
이게 누적되면 그래프가 커질수록 오히려 질의 품질이 떨어집니다. 노드가 100개일 때는 수동으로 고칠 수 있지만, 1,000개가 되면 어디가 꼬여 있는지도 파악이 안 돼요.
둘째, 관계의 방향과 의미가 일관되지 않습니다. A → MANAGES → B와 B → MANAGED_BY → A는 같은 관계인데 방향과 이름이 다릅니다. 한 방향으로 통일돼 있지 않으면, 탐색 쿼리가 한쪽 방향만 타고 가다가 중간에 끊기거든요.
"이 서버에 의존하는 서비스를 전부 찾아줘"라고 했을 때, DEPENDS_ON으로 연결된 건 나오는데 USES로 연결된 건 빠지는 식이에요. 사용자는 전체를 기대했는데 일부만 나오니까, 답변을 신뢰할 수가 없어집니다.
셋째, 추출 결과를 검증할 기준이 없습니다. LLM이 CONTROLS_RECOVERY라는 관계를 뽑아왔을 때, 이게 유효한 관계인지 아닌지를 판단할 기준이 없어요. 온톨로지가 없으면 "어떤 관계 타입이 존재해야 하는지"의 정의 자체가 없으니까, LLM이 뽑아주는 대로 다 들어가는 겁니다.
비유하자면, 도서관에 책을 분류 체계 없이 쌓아놓은 상태예요. 책이 100권일 때는 "아 그 빨간 표지"로 찾을 수 있지만, 10,000권이 되면 분류 체계 없이는 아무것도 찾을 수 없거든요. 그래프도 똑같습니다. 노드가 많아질수록 구조(온톨로지)가 없으면 오히려 혼란만 커집니다.
온톨로지는 "추출 전에 정하는 규칙"이다
온톨로지가 뭔지를 한마디로 설명하면, "이 그래프에 어떤 종류의 노드와 관계가 존재할 수 있는지를 미리 정의한 것"입니다.
예를 들면 이런 거예요.
엔티티 타입: System, Service, Person, Document
관계 타입: DEPENDS_ON, OPERATES, AUTHORED_BY
제약 조건: DEPENDS_ON은 System → System 또는 Service → System에만 쓴다
이게 있으면 문서에서 추출할 때 "이 목록에 있는 타입으로 매핑해라"는 가이드라인을 줄 수 있습니다. Server가 나와도 온톨로지에 System이 정의돼 있으면 System으로 매핑하는 거죠. LINKED_WITH가 나와도 의미상 DEPENDS_ON에 해당하면 통일됩니다.
비유하자면, 온톨로지는 도서관의 십진분류법 같은 겁니다. 책을 사기 전에 분류 체계를 먼저 만들어두면, 어떤 책이 들어와도 정해진 위치에 꽂히거든요. 분류 체계 없이 책을 먼저 사면, 나중에 정리하는 비용이 훨씬 큽니다.
실제로 온톨로지를 먼저 정의한 뒤에 같은 문서를 다시 임포트했을 때, 체감되는 차이가 컸습니다.
온톨로지를 얹은 뒤 달라진 것
같은 문서, 같은 LLM인데 온톨로지를 정의하고 나서 추출 결과가 확연히 달라졌습니다.
질의 정확도가 올라갔습니다. System이 하나의 라벨로 통일되니까, "이 시스템에 연결된 서비스를 알려줘"라는 질의에 빠지는 노드가 없어졌어요. 이전에는 Server, System, Infrastructure에 흩어져 있던 것들이 전부 System으로 잡히니까, 한 번의 쿼리로 전체가 나오거든요.
관계 탐색이 일관되게 동작합니다. DEPENDS_ON 하나로 통일되니까, "이 서비스에 의존하는 모든 시스템"을 재귀적으로 탐색할 수 있게 됐어요. 관계 이름이 3~4개로 흩어져 있을 때는 쿼리를 쓸 때마다 "혹시 빠진 관계 타입이 있나?" 걱정을 해야 했거든요.
미매핑 타입이 의미 있는 신호가 됐습니다. 온톨로지에 정의되지 않은 타입이 추출되면, 그건 "LLM이 아무거나 뽑은 것"이 아니라 "온톨로지에 아직 없는 새로운 개념을 발견한 것"이 됩니다. 이게 이전 시리즈에서 다뤘던 온톨로지 거버넌스의 출발점이기도 하거든요. 온톨로지가 있어야 "미매핑"이라는 개념 자체가 성립합니다.
그래프가 커질수록 온톨로지의 가치가 올라간다
노드 100개짜리 그래프에서는 온톨로지 없이도 어떻게든 돌아갑니다. 수동으로 라벨을 고치고, 관계를 정리하면 되니까요. 그런데 1,000개, 5,000개가 되면 수동 정리가 불가능해집니다.
이 시점에서 온톨로지가 하는 역할은 세 가지입니다.
추출의 가이드라인 역할. LLM에게 "이 타입 목록에 맞춰서 추출해라"고 지시할 수 있습니다. 자유롭게 추출하게 두면 문서마다 다른 이름이 나오는데, 온톨로지가 있으면 매핑 대상이 명확해지거든요.
검증의 기준 역할. 추출된 결과가 온톨로지에 정의된 타입이면 그대로 반영하고, 정의되지 않은 타입이면 pending으로 분류합니다. 이전 시리즈에서 다뤘던 시그널 누적, 유사 타입 감지, 승격/기각 프로세스가 전부 "온톨로지라는 기준이 있기 때문에" 가능한 거예요.
질의의 신뢰성 보장 역할. 라벨과 관계가 일관되면, 사용자가 질의했을 때 "빠진 건 없나?" 걱정을 안 해도 됩니다. RAG 파이프라인에서 컨텍스트를 구성할 때도 온톨로지 기반으로 관련 노드를 정확하게 수집할 수 있고요.
결국 온톨로지는 그래프의 규모가 커질수록 빛을 발하는 구조입니다. 작을 때는 없어도 버틸 수 있지만, 커지면 없으면 무너집니다.
그런데 온톨로지를 먼저 완벽하게 만들 필요는 없다
여기서 한 가지 오해를 짚어야 하는데, "온톨로지를 먼저 정의해야 한다"가 "온톨로지를 처음부터 완벽하게 만들어야 한다"는 뜻은 아닙니다.
처음부터 모든 엔티티 타입과 관계 타입을 다 정의하는 건 불가능해요. 어떤 문서가 들어올지, 어떤 개념이 나올지 미리 알 수 없으니까요. 그래서 온톨로지 거버넌스가 필요한 겁니다.
핵심 타입 10~20개로 시작하고, LLM이 새로운 타입을 발견하면 pending으로 대기시키고, 시그널이 쌓이면 승격하고, 유사 타입은 감지해서 걸러내는 거죠.
이 시리즈에서 다뤘던 내용들이 전부 이 흐름 위에 있습니다.
온톨로지를 정의한다 (핵심 타입으로 시작)
문서를 임포트하면 LLM이 온톨로지 기준으로 추출한다
온톨로지에 없는 타입이 발견되면 pending으로 대기
시그널이 누적되면 검토 → 승격 또는 기각
유사 타입은 2단계(문자열 + LLM)로 감지
승격 후 재임포트 → 추출 데이터만 재생성, 거버넌스 데이터는 보존
롤백 시 타입 상태 자동 동기화
온톨로지는 "한 번 정하고 끝"이 아니라, 문서가 쌓이면서 함께 진화하는 구조입니다. 거버넌스가 이 진화를 안전하게 만들어주는 장치이고요.
도서관의 십진분류법을 먼저 만들어야 한다
이 패턴은 Palantir Foundry에서 배운 겁니다. Palantir는 데이터를 플랫폼에 넣기 전에 Ontology를 먼저 정의하고, Object Type과 Link Type이라는 체계로 모든 데이터를 매핑하거든요. 데이터가 아무리 많아도 분류 체계가 있으니까 질의와 분석이 일관되게 동작합니다.
그래프DB를 쓰기로 했다면, 노드를 넣기 전에 온톨로지부터 정의하는 걸 추천합니다. 처음에는 핵심 타입 10~20개면 충분하고, 나머지는 거버넌스 프로세스가 채워줍니다.
노드가 100개일 때는 온톨로지 없이도 버틸 수 있습니다. 하지만 1,000개가 되면 온톨로지 없이는 질의가 무너지고, 5,000개가 되면 그래프 자체를 신뢰할 수 없게 됩니다. 분류 체계는 책이 많아진 뒤에 만드는 것보다, 책장을 놓기 전에 먼저 정하는 게 비용이 훨씬 적습니다.