지식그래프에 도메인을 나눴을 뿐인데, 팀 간 연결점이 자동으로 보이기 시작했다
도메인을 나누는 건 정리용이라고 생각했다
이전 글에서 지식그래프에 도메인을 태깅할 때 엔티티가 아니라 문서에 붙여야 한다는 이야기를 했습니다.
솔직히 처음에는 도메인 구분이 "정리" 목적이라고 생각했거든요. "물류팀은 물류만, 결제팀은 결제만 보게 하자" 정도의 필터링 용도요. 질의 시 다른 도메인 데이터가 섞이지 않게 하고, 특정 도메인 데이터만 삭제할 수 있게 하는 것. 그 정도면 충분하다고 봤습니다.
그런데 실제로 도메인을 나눠서 문서를 넣어보니까, 예상 못한 게 하나 생겼습니다.
공유 엔티티가 자동으로 드러났다
물류팀 문서 7개와 결제팀 문서 2개를 각각 도메인 태깅해서 임포트했습니다. 그래프가 만들어지고 나서 교차점을 조회해봤더니, 양쪽 도메인 문서에서 동시에 추출된 엔티티가 10건 가까이 나오더라고요.
상품관리 시스템, 데이터베이스, 미들웨어 같은 인프라 요소들이 물류 문서에서도 결제 문서에서도 언급되고 있었습니다. 별도 분석을 한 게 아니에요. 도메인을 나눠서 넣었을 뿐인데, 그래프 구조 자체가 교차점을 보여준 겁니다.
도메인 구분 없이 넣었으면 이걸 발견할 수 없었습니다. 모든 노드가 하나의 그래프에 섞여 있으니까, 상품관리 시스템이 "두 팀이 공유하는 시스템"인지 "우연히 이름이 같은 건지" 구분할 방법이 없거든요.
도메인이 나뉘어 있어야 "물류 소속 문서에서도, 결제 소속 문서에서도 추출됐다"는 판단이 가능해집니다. 어떤 엔티티가 어떤 도메인에서 왔는지를 아는 것과 모르는 것의 차이가 생각보다 크더라고요.
교차 엔티티가 알려주는 것들
교차 도메인 엔티티가 보이기 시작하면, 단순한 겹침 이상의 정보가 나옵니다.
장애 전파 경로를 알 수 있습니다. 상품관리 시스템이 물류와 결제 양쪽에 걸쳐 있다면, 이 시스템에 장애가 나면 두 팀 모두 영향을 받습니다. 도메인 구분 없이 넣었으면 "이 시스템이 어디까지 영향을 주는지" 파악이 안 돼요. 그런데 교차 엔티티 목록을 뽑으면 영향 범위가 바로 보이거든요.
팀 간 커뮤니케이션 포인트가 드러납니다. 공유 엔티티가 있다는 건, 해당 시스템에 변경이 생길 때 물류팀과 결제팀이 서로 이야기해야 한다는 뜻입니다. "이거 우리만 쓰는 줄 알았는데 저쪽도 쓰고 있었어?" 같은 상황을 시스템이 자동으로 잡아주는 셈이에요.
온톨로지 거버넌스 판단에도 영향을 줍니다. 미매핑 타입이 발견됐을 때, 그게 한쪽 도메인에서만 나온 건지 양쪽에서 나온 건지에 따라 승격 판단이 달라질 수 있거든요. 한쪽에서만 나온 타입은 도메인 특화 타입일 가능성이 높고, 양쪽에서 나온 타입은 공통 온톨로지에 넣을 근거가 강해집니다. 이전 시리즈에서 다룬 시그널 누적과 같은 맥락인데, 도메인 정보가 추가되면 시그널의 맥락이 훨씬 풍부해지더라고요.
이메일은 그래프를 타면 된다
도메인 교차 분석을 하다 보면 "이메일도 도메인을 붙여야 하나?"라는 질문이 생깁니다. 결론부터 말하면, 필요 없었습니다.
이메일은 MENTIONS_SYSTEM으로 시스템에 연결돼 있습니다. 시스템은 문서에서 추출됐고, 문서에는 도메인이 태깅돼 있으니까, 그래프 경로를 따라가면 이메일의 도메인이 자동으로 결정됩니다.
"물류 도메인 관련 이메일만 보고 싶다"는 요구사항이 있었는데, Domain:물류 ← Document ← SOURCED_FROM ← System ← MENTIONS_SYSTEM ← Email 경로로 탐색하면 끝이었어요.
모든 데이터에 직접 도메인을 붙이지 않아도, 그래프 관계를 타고 가면 풀리는 거예요. 속성으로 관리하면 태깅·갱신·삭제를 매번 해야 하는데, 관계로 관리하면 구조가 알아서 전파합니다. 이게 지식그래프를 쓰는 이유이기도 하더라고요. 속성에 정보를 넣는 게 아니라, 관계에 정보를 담는 겁니다.
팔란티어에서 배운 점
이 접근은 Palantir Foundry에서 배운 겁니다. Palantir는 Namespace/Project 단위로 데이터를 도메인별로 관리하면서도 교차 분석을 가능하게 하는 구조를 쓰고 있거든요. 소속은 명확하게 유지하되, 도메인 간 연결점은 플랫폼이 자동으로 보여주는 방식이에요.
도메인을 나누는 게 분리가 아니라 연결점을 드러내는 출발점이라는 걸 거기서 확인하고, 우리 설계에 적용했습니다.
나누는 건 정리가 아니라 분석의 출발점
처음에는 도메인 구분을 "팀별 데이터 정리" 정도로 생각했는데, 실제 효과는 그보다 훨씬 컸습니다. 필터링과 삭제 편의성은 기본이고, 교차 분석·장애 전파 추적·온톨로지 거버넌스 맥락 강화까지 따라오더라고요.
분석을 따로 하는 게 아니라, 데이터를 넣는 방식 자체가 분석을 가능하게 만드는 겁니다. 지식그래프에 도메인을 도입하려고 한다면, "필터링이 되겠지" 수준에서 멈추지 말고 교차 분석까지 염두에 두고 설계하는 걸 추천합니다.