지식그래프에서 도메인은 어디에 태깅해야 할까?
이 노드, 누가 올린 거야?
지식그래프에 문서를 계속 임포트하다 보면, 어느 순간 그래프가 꽤 커집니다. 노드가 수백 개가 되고, 관계가 수천 개가 되면 한 가지 질문이 생기더라고요.
"이 노드, 어느 팀에서 올린 거지?"
물류팀 문서 7개와 결제팀 문서 2개를 넣었는데, 그래프에는 그냥 섞여 있습니다.
이 상태에서 "물류 시스템의 장애 포인트를 알려줘"라고 질의하면, 결제팀 문서에서 추출된 노드까지 컨텍스트에 들어옵니다. 관련 없는 정보가 섞이면 RAG가 엉뚱한 근거로 답변을 만들거든요. 도메인이 다른 데이터가 노이즈로 작용하는 거예요.
운영 측면에서도 문제가 쌓입니다. "결제 데이터만 삭제하고 싶다" → 구분이 안 돼서 못 합니다. "물류팀은 물류 데이터만 보고 싶다" → 필터링이 안 됩니다. 온톨로지 거버넌스에서 미매핑 타입이 발견돼도, 그게 어느 도메인에서 나온 건지 알 수가 없어요.
도메인을 구분해서 관리해야겠다는 건 금방 결론이 났습니다. 문제는 어디에 태깅하느냐였거든요.
처음 떠오른 건 엔티티에 직접 붙이는 거였다
가장 직관적인 방법은 엔티티에 도메인 속성을 넣는 거였습니다. 물류 서버 logistics-web01에 domain: "물류"를 붙이고, 결제 게이트웨이 pg-gateway에 domain: "결제"를 붙이는 방식이요. 단순하고 명쾌해 보였어요.
그런데 실제 데이터를 보니까 바로 막혔습니다.
'상품관리'라는 서비스가 물류 문서에서도 나오고, 결제 문서에서도 나왔는데 두 팀이 같은 메시지 큐를 쓰고 있었던 겁니다. oracle, redis 같은 인프라도 마찬가지였고요. 공유 엔티티가 10건 가까이 발견됐습니다.
한 엔티티에 도메인을 하나만 붙일 수 있으면, '상품관리'는 물류인지 결제인지 정할 수가 없습니다. 그렇다고 배열로 여러 도메인을 넣으면 관리가 복잡해져요. 새 문서를 임포트할 때마다 엔티티의 도메인 배열을 갱신해야 하고, 문서를 삭제할 때도 어떤 도메인을 빼야 하는지 역추적해야 하거든요.
한 줄로 정리하면, 엔티티는 여러 도메인에 속할 수 있는데 속성은 하나밖에 못 담는다는 게 근본 문제였습니다.
문서에 붙이면 이 문제가 사라진다
시점을 바꿔서 생각해봤습니다. 엔티티가 아니라, 엔티티의 출처인 문서(Document)에 도메인을 태깅하면 어떨까.
서버현황.xlsx는 물류 도메인, 결제연동규격.pdf는 결제 도메인. 문서는 팀이 올리는 것이니까 도메인이 명확합니다. 한 문서가 두 도메인에 속하는 경우는 거의 없거든요.
그러면 엔티티는 어떻게 도메인을 알 수 있냐. 그래프 구조를 따라가면 됩니다. 엔티티는 문서에서 추출된 것이니까, Document → DocumentSheet → SOURCED_FROM 관계를 타면 어떤 도메인에서 나왔는지 추적이 돼요.
'상품관리'를 다시 보면, 물류 문서에서도 추출됐고 결제 문서에서도 추출됐으니까, 그래프 탐색만으로 두 도메인에 걸쳐 있다는 걸 자연스럽게 알 수 있습니다. 엔티티에 도메인 속성을 넣을 필요가 없어진 거예요.
이 구조의 장점이 하나 더 있는데, 재임포트해도 도메인이 유지된다는 점입니다. 도메인 정보는 MySQL의 document_upload.domain에 저장돼 있고, 재임포트는 Neo4j/Qdrant 그래프만 재생성하니까요. 이전 글에서 정리한 "추출 데이터와 거버넌스 데이터 분리" 원칙과 같은 맥락이더라고요.
이메일은 태깅할 필요가 없었다
이메일도 도메인을 붙여야 하나 고민했는데, 필요 없었습니다. 이메일이 MENTIONS_SYSTEM으로 시스템에 연결돼 있으니까, 시스템의 도메인을 따라가면 되거든요.
"물류 도메인 이메일 보기"는 Domain:물류 ← Document ← SOURCED_FROM ← System ← MENTIONS_SYSTEM ← Email 경로로 탐색하면 됩니다. 모든 데이터에 직접 도메인을 붙이지 않아도, 그래프 관계를 타고 가면 풀리는 게 지식그래프의 강점이에요.
팔란티어도 같은 방식 사용
Palantir Foundry가 Namespace/Project로 데이터를 도메인별로 관리하는 방식도 동일한 접근이었습니다. 데이터 연동 시 소속 프로젝트를 지정하고, Object Type별로 접근 권한을 프로젝트 단위로 제어하되, 도메인 간 교차 분석도 가능하게 하는 구조거든요.
결국 도메인 관리에서 가장 중요한 판단은 "도메인을 나누겠다"가 아니라 "어디에 태깅하느냐"였습니다. 엔티티에 직접 붙이면 다대다 관계 관리가 복잡해지고, 문서에 붙이면 그래프의 기존 구조를 그대로 활용할 수 있습니다.
도메인을 나눠서 넣으면 어떤 연결점이 자동으로 드러나는지는 다음 글에서 정리하겠습니다.
