온톨로지 빌드·검색 개선 대장정 3편 — 도입 전에 정해야 할 것들

편집자 노트 · B2B 도입 관점 — B2B 시스템의 성숙도는 기능 수만으로 판단하기 어렵습니다. 어떤 입력을 처리하지 못하는지, 오류가 생겼을 때 어디까지 추적할 수 있는지, 고객과 공급자가 각각 어떤 결정을 맡는지가 명확해야 운영 위험을 계산할 수 있습니다. 이 글은 현재 구현의 한계와 미결정 사항을 숨기지 않고, 이를 PoC의 수용 기준과 단계별 로드맵을 만드는 재료로 전환합니다.

아직 못 하는 것

여기까지가 되는 것입니다. 안 되는 것도 같은 무게로 적어두겠습니다.

삭제와 갱신이 반영되지 않습니다. 문서를 지우거나 고쳐도, 상류 DB의 행이 사라져도 그래프는 그대로이고 전체 재빌드가 필요합니다. 노드가 여러 청크를 공유하므로 청크 하나가 빠질 때 노드와 엣지를 어디까지 지울지 규칙이 필요한데 아직 없습니다. 이전 결정을 수리하는 기능도 없습니다. 한 번 접힌 조각이나 버려진 이름은 새 근거가 와도 되살아나지 않아서 결과가 문서 도착 순서에 의존합니다. 지운 이름의 근거를 어디에 남길지 설계가 먼저입니다.

값에 타입이 없습니다. 속성값이 타입 없는 문자열로 저장되어 수치 비교와 범위 질문을 그래프에서 처리하지 못하고, 이것이 수치 질문이 약한 원인의 하나입니다. 표 위에 "단위: 억원"이라고 주석으로만 적힌 단위를 어떻게 값에 붙일지가 표마다 달라 규칙으로 끝나지 않습니다. 출처는 노드 단위까지입니다. 답변에서 근거 노드로, 노드에서 출처 청크로, 청크에서 문서 위치까지는 이어지고 근거 청크마다 벡터 검색과 그래프 확장 중 어느 경로로 들어왔는지도 남기지만, 관계 하나가 어느 청크에서 왔는지는 없어서 양 끝 노드가 공유하는 청크로 근사합니다. 이것을 넣으려면 저장 마이그레이션과 추출기 출력 형식 변경이 함께 필요합니다. 개체의 정체성은 정규화된 이름이라 동명이인을 가르지 못합니다. 설명가능성으로 보면 지금 제공하는 것은 출처 추적 수준이고, 답변 문장과 청크의 대응, 신뢰도 점수, 추론 경로까지는 아직 없습니다.

그리고 측정 체계가 없습니다. 추출기의 임계값 15개가 전부 경험값이고 정답셋이 없습니다. 좋아졌는지 나빠졌는지 말할 수 없어서 사용자가 화면에서 이상한 이름을 발견할 때만 문제를 압니다. 이 글에 적은 개선도 전부 그런 식으로 시작됐습니다. 품질 점수는 인스턴스 있는 클래스 비율 0.4, 참조 무결성 0.25, 원문 근거율 0.2, 구조 위반 0.15로 내지만 사후에 만든 것이라 앞으로의 개선을 이끄는 지표는 아닙니다. 그래서 다음 작업의 첫 항목은 기능이 아니라 골드셋과 지표 스크립트입니다. 문서 다섯 개, 사람이 고른 용어 30개, 클래스 10개, 표 사실 20건입니다.

측정 체계 다음으로 손볼 것은 기본 빌드의 판정 위치입니다. 지금은 "이 문자열이 이름인가, 클래스인가, 같은 것인가"를 추출기와 적재와 후처리 세 층이 각자 다른 규칙으로 판단합니다. 그래서 한 곳을 고치면 다른 곳이 되돌리고, 빌드 끝의 정리 패스가 여덟 개까지 늘었습니다. 개체 판정을 청크 단위의 지역 정보로 하는데 그 판단에 필요한 근거는 코퍼스 전체라는 것도 같은 문제의 양면입니다. 작은 컬렉션에서는 등장 비율이 100%가 되어 문서를 잇는 핵심 개체가 먼저 버려졌고, 큰 컬렉션에서는 한 이름이 수백 개의 부모가 되는 허브가 생겼습니다. 그래서 구조 읽기, 후보 만들기, 코퍼스 판정, 층 배정의 네 단계로 나누고 버리는 결정을 코퍼스 판정 한 곳으로 모으는 재설계를 기획해 두었는데, 골드셋과 지표가 먼저라 그 뒤에 들어갑니다.

그 밖의 후속은 사용자가 확정한 클래스와 동의어를 빌드가 다시 읽는 스키마 편집 되먹임, 관계마다 출처 청크를 두는 엣지 출처, 이름 외의 신호로 동명이인을 가르는 개체 정체성, 필수 속성과 도메인·레인지·카디널리티 위반을 보고하는 SHACL 검증, 도메인별 역량 질문 세트를 빌드 입력이 아니라 측정 지표로 쓰는 CQ 커버리지, 그리고 RRF와 리랭커와 상하위 추론 확장 같은 검색 고도화입니다. 마지막 것은 골드셋 없이는 파라미터를 튜닝할 수 없어 순서가 뒤로 갑니다.

작업 방식에 대한 반성도 하나 남깁니다. 증상 하나에 수정 하나를 붙이는 식으로 진행해 배포를 여러 번 태웠습니다. 머리말이 새는 경로 넷 중 둘만 고치고 배포했다가 나머지 둘을 나중에 또 찾았고, 문서 500개 상한은 헛빌드를 먼저 고치고 배포한 뒤에야 원인이 그 위에 있었다는 것을 알았습니다. 그 뒤로는 고치기 전에 같은 유형의 결함을 코드 전체에서 먼저 훑고 한 번에 묶는 것을 기본으로 했습니다.

아직 정하지 못한 것

되는 것과 안 되는 것 사이에 결정하지 못한 것들이 있습니다. 기술로 풀리는 문제가 아니라 어느 쪽을 택하느냐에 따라 제품의 모양이 달라지는 것들이라 따로 적어둡니다.

지금 입장은 첫 줄부터 상향식 유도, 구조만, 추론 없음, 정형 워터마크 증분, 빌드 시 추출, 청크 출처입니다. 전부 가장 단순한 쪽입니다. 단순한 쪽을 고른 이유는 그것이 옳아서라기보다 아직 반대쪽이 필요하다는 증거를 못 봤기 때문이고, 그 증거를 보려면 앞 절의 측정 체계가 먼저 있어야 합니다. 첫 줄이 특히 그렇습니다. 사용자가 스키마를 편집하는 기능은 있지만 그 편집값이 다음 빌드에 반영되는 데까지는 이르지 못했고, 시드 스키마를 넣었을 때 결과가 좋아졌는지 판정할 골드셋이 없습니다. FIBO 같은 표준 온톨로지는 한국어 라벨을 직접 붙여야 한다는 조사 결과도 있어 비용이 큽니다. 고객사마다 어느 정도까지 스키마를 먼저 세우고 어디부터 자동 유도에 맡길지가 저희가 판단을 내리지 못하고 있는 지점입니다.

정한 것과 정하지 못한 것 사이에서

정한 것을 한 줄로 줄이면 세 번의 뺄셈입니다. 기본 빌드에서 LLM을 빼니 문서를 올리는 것만으로 그래프가 생기고 같은 문서에서 같은 그래프가 나옵니다. 검색에서 반복 루프를 빼니 탐색이 수백 밀리초에 끝나고 에이전트에 근거층만 넘길 수 있습니다. 정본에서 Fuseki를 빼니 빌드가 저장소 때문에 멈추지 않습니다.

뺄 때마다 그전에 믿고 있던 것이 재보니 달랐습니다. 빌드가 느린 것이 아니라 문서를 500개까지만 읽고 있었고, 표준 레시피가 안전한 것이 아니라 우리 문서에서 뜻을 가르는 글자를 버리고 있었고, 증분이 증분이 아니라 매번 전량을 읽고 있었습니다. 세 가지 모두 시스템은 정상이라고 보고하고 있었고, 결과물을 직접 열어보고 나서야 알았습니다.

그래서 이 구조에서 가장 값어치 있는 부분은 무엇을 뺐느냐가 아니라 뺀 뒤에 무엇이 달라졌는지를 잴 수 있게 된 것입니다. LLM을 빼니 같은 입력에 같은 출력이 나와 비교가 가능해졌고, 루프를 빼니 검색 시간과 답변 생성 시간이 갈라져 어디가 느린지 말할 수 있게 됐고, 저장을 옮기니 빌드 시간을 단계별로 잴 수 있게 됐습니다. 정하지 못한 것들은 전부 그 다음 자리에 있습니다. 시드 스키마가 필요한지, 값을 그래프에 올려야 하는지, 관계 추출을 질의 시점으로 미룰 수 있는지는 재봐야 아는 것이고, 재려면 정답셋이 먼저입니다.

기업에서 지식그래프를 검토하실 때 이 글에서 가져가실 것은 아마 두 가지일 것입니다. 하나는 온톨로지화가 자동으로 돌아야 한다는 조건을 먼저 세우면 LLM을 어디에 쓰고 어디에 안 쓸지가 대체로 따라 정해진다는 것입니다. 다른 하나는 널리 쓰이는 레시피든 자기 시스템의 성공 보고든, 자기 데이터로 직접 열어보기 전까지는 믿지 않는 편이 낫다는 것입니다. 저희가 찾은 문제는 전부 정상이라고 보고되던 곳에 있었습니다.

B2B 도입을 검토한다면

PoC를 시작하기 전에는 대표 질문과 정답이 포함된 골드 세트, 삭제·수정 반영 정책, 엔티티 식별 기준, 필요한 출처 추적 단위, 허용 가능한 오류율과 응답 시간을 문서로 합의하는 것이 좋습니다. 모든 문제를 한 번에 해결할 필요는 없지만, 이번 단계에서 지원하지 않는 범위와 다음 단계로 넘어가는 조건은 분명해야 합니다.

이 세 편이 전하는 핵심은 그래프 기술 자체보다 선택을 측정 가능한 운영 기준으로 바꾸는 과정에 있습니다. 자동 빌드의 보장 범위, 질문별 검색 채널, 데이터의 기준 저장소와 갱신 책임, 미지원 범위와 평가 지표를 고객과 함께 정할 때 온톨로지는 데모를 넘어 지속적으로 개선할 수 있는 업무 기반이 됩니다.

이전 편 → 온톨로지 빌드·검색 개선 대장정 2편 — 여덟 번의 탐색을 한 번의 융합으로

시리즈 처음 → 질문이 답의 범위까지 정하고 있었습니다 (1편)

시리즈 전체 보기 → 온톨로지 개발기