지식그래프 온톨로지, 처음부터 다시 한다면 뭘 다르게 할까

온톨로지 거버넌스, 유사 타입 감지, 재임포트 원칙, 롤백, 도메인 관리, 그리고 온톨로지의 필요성까지. 지식그래프와 온톨로지에 대해 여러 편을 쓰면서, 한 가지 질문이 계속 머릿속에 남더라고요.

"처음으로 돌아간다면, 뭘 다르게 할까?"

지금까지 쓴 글들은 전부 겪고 나서 정리한 것이거든요. 삽질을 하고, 설계를 고치고, 그 과정을 기록한 거예요. 그런데 만약 이 경험을 가지고 처음부터 다시 시작한다면, 같은 순서로 하진 않을 것 같았습니다.

돌아보면서 정리한 건 크게 네 가지였어요.

첫째, 기술보다 언어를 먼저 맞추는게 유리하다

온톨로지 설계를 처음 시작했을 때, "어떤 엔티티 타입을 정의할까"부터 고민했습니다. System, Service, Person, Document... 기술적으로 어떤 노드 라벨을 쓸지, 어떤 관계 타입을 만들지에 집중했거든요.

그런데 실제로 부딪힌 문제는 기술이 아니었습니다. 같은 것을 다르게 부르는 문제였어요.

한 팀에서는 "서버"라고 부르는 걸 다른 팀에서는 "시스템"이라고 불렀습니다. 어떤 문서에서는 "모듈"이라고 쓰고, 어떤 문서에서는 "컴포넌트"라고 쓰더라고요. LLM이 문서마다 다른 이름으로 추출하는 게 LLM의 문제가 아니라, 원래 문서부터 용어가 통일되지 않았던 거였습니다.

이걸 나중에 깨닫고 온톨로지를 고치는 건 비용이 컸어요. 이미 수백 개의 노드가 잘못된 라벨로 들어가 있으니까, 전부 재임포트해야 하거든요.

처음부터 다시 한다면, Neo4j를 열기 전에 팀 내에서 "우리가 쓰는 핵심 용어 10~20개"를 먼저 합의하겠습니다. "서버와 시스템 중에 뭘 쓸 건지", "연결과 의존 중에 뭘 쓸 건지"를 사람끼리 먼저 정하는 거예요.

온톨로지 설계의 본질은 그래프 스키마를 짜는 게 아니라, 팀의 언어를 정하는 것이었거든요. 언어가 맞으면 LLM 추출도, 질의도, 거버넌스도 자연스럽게 따라옵니다. 언어가 안 맞으면 아무리 정교한 파이프라인을 만들어도 결과가 엉킵니다.

둘째, 작게 시작하고 거버넌스로 키우기

처음 온톨로지를 설계할 때, 가능한 모든 타입을 미리 정의하려고 했습니다. "나중에 추가하면 기존 데이터와 안 맞을 수 있으니까, 처음부터 빠짐없이 만들어놓자"는 생각이었거든요.

결과적으로 이건 시간 낭비였어요. 어떤 문서가 들어올지, 어떤 개념이 나올지 미리 알 수 없으니까 예측해서 만든 타입의 절반 이상은 실제로 쓰이지 않았습니다. 반대로 예상 못 한 타입은 계속 나왔고요.

이 시리즈에서 온톨로지 거버넌스를 만들면서 배운 게, 온톨로지는 처음에 완벽하게 만드는 게 아니라 문서가 쌓이면서 함께 키우는 것이라는 점이었어요.

처음부터 다시 한다면 핵심 타입 10~15개만 정의하고 바로 시작하겠습니다. 나머지는 LLM이 발견하면 pending으로 대기시키고, 시그널이 누적되면 승격하는 거버넌스 프로세스를 초기부터 갖추는 거예요.

시리즈 첫 번째 글에서 "급하게 승격하지 않는 게 기본 전략"이라고 썼는데, 이건 온톨로지 설계 자체에도 적용되는 원칙이더라고요. 급하게 타입을 만들지 않는 것. 데이터가 근거를 보여줄 때까지 기다리는 것.

셋째, 추출보다 관리에 더 시간을 쓰겠다

시간 배분을 돌이켜보면, 초반에는 LLM 추출 파이프라인에 80% 이상의 시간을 썼습니다. 프롬프트를 다듬고, 청킹 전략을 바꿔보고, 추출 정확도를 올리는 데 집중했거든요.

그런데 실제로 운영해보니까 추출이 아무리 정확해도, 관리가 안 되면 소용이 없더라고요. 정확하게 추출한 타입이 중복으로 등록되고, 유사 타입이 걸러지지 않고, 재임포트할 때 시그널이 날아가면 결국 그래프를 신뢰할 수가 없어집니다.

이 시리즈에서 다룬 거의 모든 글이 "관리" 쪽이었어요.

시그널 누적으로 승격 판단 근거를 만드는 것

문자열 + LLM 2단계로 유사 타입을 감지하는 것

재임포트 시 추출 데이터와 거버넌스 데이터를 분리하는 것

롤백 시 타입 상태를 자동 동기화하는 것

도메인 태깅으로 교차 분석을 가능하게 하는 것

추출 파이프라인을 만드는 건 일주일이면 됐는데, 거버넌스를 안정화하는 데는 몇 배의 시간이 걸렸거든요.

처음부터 다시 한다면 추출 파이프라인은 "동작하는 수준"으로 빠르게 만들고, 남는 시간을 거버넌스 설계에 쓰겠습니다. 추출 정확도는 나중에 점진적으로 올릴 수 있지만, 관리 체계 없이 쌓인 데이터를 나중에 정리하는 건 훨씬 비용이 크거든요.

넷째, 도메인 구분을 처음부터 하겠다

도메인 관리를 나중에 추가하면서 깨달은 건데, 이건 처음부터 했어야 합니다.

도메인 구분 없이 문서를 넣으면 질의 시 다른 팀 데이터가 섞여서 엉뚱한 답변이 나오고, 특정 도메인 데이터만 삭제할 수도 없고, 거버넌스에서 미매핑 타입이 어느 도메인에서 나왔는지도 추적이 안 됩니다. 이 문제들은 데이터가 쌓인 뒤에 발견되는데, 그때 가서 도메인을 붙이려면 기존 데이터를 전부 재처리해야 하거든요.

처음부터 업로드 시점에 도메인을 선택하게 하면, 이 비용이 0이에요. 드롭다운 하나 추가하는 정도니까요. 그런데 나중에 추가하면 기존 문서 전체에 도메인을 소급 적용해야 합니다.

그리고 도메인 시리즈에서 썼듯이, 도메인을 나누면 "정리"만 되는 게 아니라 교차 분석이 공짜로 따라옵니다. 어떤 엔티티가 여러 도메인에 걸쳐 있는지, 팀 간 공유 시스템이 뭔지가 그래프 구조에서 자연스럽게 드러나거든요.

결국 돌아보면

이 네 가지를 한 줄로 줄이면 이렇습니다.

언어 먼저 — Neo4j를 열기 전에 팀 용어 10~20개를 합의한다

작게 시작 — 핵심 타입만 정의하고, 나머지는 거버넌스로 키운다

관리에 투자 — 추출 파이프라인보다 거버넌스 설계에 시간을 더 쓴다

도메인은 처음부터 — 업로드 시점에 도메인을 선택하게 한다

돌이켜보면, 이 네 가지 중 하나라도 처음부터 했으면 시리즈에서 다룬 삽질의 절반은 안 겪었을 겁니다.

특히 첫 번째가 가장 중요했어요. 온톨로지는 기술적인 스키마처럼 보이지만, 본질은 "우리 팀이 이 도메인을 어떤 언어로 이해하고 있는가"의 합의거든요. 그 합의가 먼저 있으면 추출도, 질의도, 거버넌스도 그 위에서 자연스럽게 돌아갑니다.

지식그래프를 처음 시작하려는 분이 계시다면, 그래프DB를 설치하기 전에 화이트보드 앞에서 팀 용어부터 맞춰보는 걸 추천합니다.