지식그래프 재임포트, 뭘 지우고 뭘 남길지가 설계의 핵심인 이유

승격까지는 좋았는데, 그 다음이 문제다

온톨로지 거버넌스에서 타입을 승격하면, 온톨로지에 새 버전이 만들어집니다. 거버넌스 프로세스 자체는 이전 글에서 정리했는데, 요약하면 "LLM이 발견한 새 타입을 시그널이 누적된 후에 승격시키는 구조"입니다.

문제는 승격 직후에 생깁니다. 이미 임포트된 문서들은 이전 버전 온톨로지로 처리된 상태잖아요. 새로 추가된 타입 기준으로 그래프 데이터를 다시 뽑아야 합니다. 이걸 재임포트라고 부르는데, "그냥 전부 밀고 다시 돌리면 되는 거 아냐?"라고 생각하면 함정에 빠지더라고요.

전부 밀면 안 되는 이유

처음에는 단순하게 접근했습니다. 재임포트 = 해당 문서의 모든 데이터를 삭제하고 처음부터 다시 추출. 깔끔하고 직관적이죠.

그런데 실제로 돌려보니까 이상한 일이 벌어졌습니다. pending 타입 A, B, C가 있는 상태에서 A만 승격하고 재임포트를 돌렸거든요.

결과가 이랬습니다.

A는 승격됐으니까 이제 "매핑된 타입"으로 인식됩니다. 재임포트 시 정상적으로 그래프에 반영되고, 새 시그널은 안 생깁니다. 여기까진 의도한 대로예요.

문제는 B, C였습니다. 전부 밀고 다시 추출하면 B, C의 기존 시그널도 날아갑니다. 재추출 과정에서 B, C가 다시 발견되면 시그널이 새로 생기긴 하는데, 이전에 누적된 건수와 문서 수가 초기화돼요.

사용자 입장에서는 "아까 B가 15건, 3문서였는데 왜 갑자기 5건, 1문서가 됐지?"라는 혼란이 생깁니다.

시그널은 "이 타입이 왜 발견됐는지"의 근거 데이터인데, 재임포트 목적은 "새 온톨로지로 그래프를 다시 뽑는 것"이지 거버넌스 근거를 초기화하는 게 아니거든요.

뭘 지우고 뭘 남기나 — 설계 원칙

비유하자면, 이력서(시그널)는 남기고 면접(추출)만 다시 보는 겁니다. 재임포트한다고 "이 후보가 왜 면접 대상이 됐는지"의 근거가 바뀌지 않으니까요.

구체적으로 정리하면 이렇습니다.

Neo4j 바로가기
Qdrant 바로가기

중복 시그널은 어떻게 막는가

시그널을 보존하면 한 가지 걱정이 생깁니다. 재추출 과정에서 같은 타입이 또 발견되면 시그널이 중복으로 쌓이는 거 아닌가?

이건 간단하게 처리했습니다. 재추출 시 해당 문서의 시그널이 이미 있는 타입은 건너뛰거든요. 문서 A에서 CONTROLLED_BY가 발견됐던 시그널이 이미 있으면, 재임포트로 다시 추출할 때 같은 문서 + 같은 타입 조합은 스킵합니다.

결과적으로 시그널 건수가 재임포트 전후로 동일하게 유지됩니다.

문서 완전 삭제는 다른 규칙이다

재임포트와 문서 삭제를 혼동하기 쉬운데, 완전히 다른 케이스입니다.

문서를 아예 삭제하면 그 문서에서 나온 시그널도 전부 삭제합니다. 문서 자체가 사라졌는데 "이 문서에서 발견됐다"는 근거가 남아 있으면 안 되니까요.

이때 pending 타입 중에 해당 문서의 시그널만 갖고 있던 것들은 고아(orphan)가 됩니다. 다른 문서에서도 발견된 타입은 시그널이 남아 있으니 괜찮지만, 그 문서에서만 유일하게 발견된 타입은 시그널이 0건이 되거든요. 이런 고아 pending 타입은 자동으로 삭제합니다.

반면 promoted 타입은 문서를 삭제해도 보존합니다. 이미 온톨로지에 반영된 판단이니까, 출처 문서 하나가 사라졌다고 되돌릴 성격이 아니거든요.

정리하면 이렇습니다.

재임포트 설계에서 가장 중요했던 것

재임포트 로직을 짜면서 가장 많이 고민한 건 "어디까지가 추출 데이터이고, 어디부터가 거버넌스 데이터인가"의 경계를 긋는 거였습니다.

Neo4j 노드, Qdrant 벡터, raw_extraction은 추출 파이프라인의 산출물이고, 타입과 시그널은 거버넌스 프로세스의 산출물입니다. 재임포트는 추출을 다시 하는 것이지, 거버넌스를 다시 하는 게 아닙니다.

이 경계가 명확하지 않으면 "재임포트했더니 대기 목록이 이상해졌다", "건수가 초기화됐다" 같은 버그가 계속 생기거든요. 추출과 거버넌스의 라이프사이클을 분리한 뒤로 재임포트가 안정적으로 동작하게 됐습니다.