핵심 인력이 퇴사하면 그 사람이 갖고 있던 지식도 함께 나간다는 게 조직에서 오래된 고민이다. 문서화를 열심히 해도 해결이 안 되는 이유가 있다. 문서는 텍스트로 저장되지만, 그 텍스트들이 서로 어떻게 연결되는지는 저장이 안 된다. 담당자가 머릿속에서 연결하고 있던 맥락과 관계가 사라지는 거다.
AI가 사내 문서를 다루면 이 문제가 더 선명하게 드러난다. RAG를 붙여서 사내 문서를 검색하게 만들어도, 부서마다 다른 용어를 쓰거나 데이터가 여러 시스템에 흩어져 있으면 AI가 제대로 된 답을 내놓지 못한다. “영업팀에서는 고객사라고 부르고 개발팀에서는 클라이언트라고 부르는” 같은 용어 불일치 하나가 검색 결과를 망가뜨린다.
이 문제를 본격적으로 풀려고 Graphwise를 들여다봤다.
데이터 사일로 문제 – 왜 이렇게 됐는가
대부분의 조직에서 데이터가 흩어지는 건 의도가 아니라 성장의 결과다. 처음엔 엑셀 파일 하나, 공유 폴더 하나로 시작한다. 팀이 늘고 시스템이 추가되면서 CRM, ERP, 문서 관리 시스템, 슬랙 채널, 컨플루언스 페이지가 각자 자라난다. 각 시스템 안에서는 잘 정리돼 있지만, 시스템을 넘나드는 질문에는 아무도 바로 답을 못 한다.
AI를 도입하면 이 문제가 증폭된다. LLM은 사내 데이터에 접근하려면 RAG 파이프라인을 통해야 하는데, 데이터가 사일로별로 나뉘어 있으면 AI도 그 경계를 넘지 못한다. 각 시스템에서 따로 RAG를 구축하는 방식은 결국 사일로를 AI 레이어에서도 그대로 재현하는 거다.
Graphwise가 접근하는 방식은 이 사일로들 위에 공통 의미 레이어를 만드는 것이다. 각 시스템의 데이터를 옮기는 게 아니라, 그 데이터들을 연결하는 공통 개념 체계를 지식 그래프로 정의하고, 그 위에 AI를 얹는 방식이다.
PoolParty로 택소노미부터 잡는다
Graphwise 플랫폼에서 지식 관리의 시작점은 PoolParty다. Semantic Web Company가 개발한 택소노미 관리 도구인데, Graphwise 합병 이후 GraphDB와 통합된 형태로 제공된다.
택소노미는 쉽게 말해 개념의 계층 구조다. “고객사, 클라이언트, 거래처”가 같은 개념의 다른 이름이라는 걸 시스템이 이해하게 만드는 것에서 시작한다. 영업팀이 쓰는 용어와 개발팀이 쓰는 용어를 하나의 개념으로 묶어서, 어느 팀의 문서를 검색하든 같은 결과가 나오게 만드는 작업이다.
PoolParty가 이 과정에서 하는 일이 구체적으로는 세 가지다. 기존 문서에서 주요 개념을 자동으로 추출해서 택소노미 초안을 잡아준다. 유사어와 관련어를 제안해서 개념 간 관계를 풍부하게 만든다. 그리고 이 구조를 여러 부서가 협업해서 수정하고 유지할 수 있게 인터페이스를 제공한다.
내가 실제로 접해본 케이스에서 가장 시간이 걸린 부분이 이 택소노미 합의 과정이었다. 기술적인 작업보다 “영업팀과 개발팀이 같은 개념을 다른 이름으로 부른다는 걸 인정하고, 공통 용어를 정하는” 조직 내 합의가 더 오래 걸렸다. PoolParty는 이 과정을 도구로 지원해주지만, 결국 사람이 해야 할 일이 있다는 건 기억해두는 게 좋다.
GraphDB로 관계를 연결한다
택소노미가 잡히면 GraphDB에 지식 그래프를 구축한다. 각 부서의 데이터에서 개체와 관계를 추출해서 RDF 트리플로 저장하는 과정이다.
실제로 이 과정에서 보이는 것들이 있다. “A 프로젝트는 B 고객사를 위한 것이고, B 고객사의 담당 영업은 C 팀장이고, C 팀장이 이전에 담당한 D 프로젝트의 기술 스펙이 A 프로젝트와 겹친다”는 관계가 그래프 안에 저장되면, 이 연결을 AI가 추론에 활용할 수 있게 된다. 각 시스템 안에는 다 있는 데이터인데, 시스템을 넘나드는 연결이 없어서 사람이 직접 머릿속에서 연결하던 것들이다.
GraphDB가 하루에 BBC에서 처리하는 SPARQL 쿼리가 100만 건이 넘는다는 건 이 시스템이 프로덕션 규모에서 검증됐다는 의미다. 미디어 회사에서 수천 명의 기자가 매일 방대한 아카이브를 탐색하는 환경에서 이 규모가 나온다. 엔터프라이즈 운영 안정성 측면에서 참고할 수 있는 수치다.
GraphRAG를 붙이면 AI가 달라진다
지식 그래프가 구축되면 그 위에 GraphRAG를 얹는다. 2026년 2월에 Graphwise가 공식 출시한 GraphRAG 플랫폼은 로우코드 방식의 AI 워크플로 엔진으로, Python 프로토타입을 프로덕션 시스템으로 빠르게 전환하는 걸 목표로 만들어졌다.
여기서 수치가 하나 있다. 전통 RAG 방식에서 60% 수준이던 답변 정확도가 Graphwise GraphRAG를 적용한 후 90% 이상으로 올라간 고객 사례가 있다. 이 차이가 어디서 나오는지는 구조를 보면 이해가 된다. 일반 RAG는 청크 단위로 문서를 쪼개서 유사도 검색을 하는데, 청크를 넘나드는 관계 정보가 손실된다. GraphRAG는 지식 그래프에 명시적으로 저장된 관계를 활용하기 때문에 이 손실이 없다.
GraphDB 10.8에서 나온 Talk-to-Your-Graph 2.0 기능이 이걸 실무에서 어떻게 쓰는지 보여준다. 비기술 사용자가 자연어로 “우리 회사 AI 프로젝트 중 예산이 겹치는 것들 찾아줘”라고 입력하면, 내부적으로 LLM이 SPARQL 쿼리를 생성하고, 지식 그래프를 탐색해서 답을 가져온다. 데이터 팀에 요청서를 넣고 기다릴 필요 없이, 현업 담당자가 직접 복잡한 데이터 질문에 답을 얻을 수 있게 되는 거다.
어떤 조직에 맞는가
Graphwise 도입을 고민할 때 먼저 짚어야 할 건 조직의 데이터 상황이다.
부서마다 쓰는 용어가 다르고, 같은 개념을 다른 이름으로 부르는 상황이 잦다면 PoolParty의 택소노미 관리가 바로 가치를 만든다. 여러 시스템에 데이터가 나뉘어 있고 AI가 이 경계를 넘나들며 질문에 답해야 한다면 GraphDB 기반 지식 그래프가 필요하다. 그리고 AI 답변의 근거를 추적하고 설명해야 하는 규제 환경, 즉 금융, 의료, 법률 도메인에서는 그래프 기반 추론의 추적 가능성이 결정적인 요소가 된다.
반면 문서가 잘 정리돼 있고 단순한 사실 조회 수준의 질문이 대부분이라면 Graphwise까지 갈 필요가 없다. 벡터 RAG와 BM25 하이브리드 검색으로 충분한 경우가 많다. Graphwise는 데이터가 복잡하게 얽히고 관계 추론이 필요한 상황에서 가치가 극대화되는 플랫폼이다.
도입 전에 알아야 할 현실적인 부분
Graphwise의 GraphRAG 플랫폼이 2026년 2월에 공식 출시됐다는 건 아직 독립적인 검증 사례가 많지 않다는 뜻이다. GraphDB와 PoolParty 자체는 20년이 넘는 프로덕션 검증이 있지만, GraphRAG 워크플로 엔진은 비교적 새로운 제품이다. 도입 전에 자체 데이터로 POC를 먼저 해보는 게 맞다.
SPARQL을 다룰 수 있는 인력이 필요하다는 점도 현실적인 제약이다. Talk-to-Your-Graph가 비기술 사용자의 접근성을 높여주지만, 시스템을 구축하고 온톨로지를 설계하는 단계에서는 시맨틱 웹 기술에 익숙한 인력이 필요하다. 이 역량이 조직 내에 없다면 도입 초기에 전문 파트너사의 도움이 필요하다.
비용 구조도 엔터프라이즈 라이선스 기반이라 규모에 따라 차이가 크다. Graphwise 홈페이지에서 직접 데모를 요청하고 견적을 받아보는 게 현실적인 첫 단계다.
지식은 연결될 때 자산이 된다
McKinsey 조사에서 AI를 적어도 하나의 비즈니스 기능에 도입한 조직이 70%를 넘는데, 프로덕션 규모로 성공적으로 배포한 곳은 11%에 불과하다는 통계가 있다. 이 간극의 원인 중 하나가 데이터 품질과 구조다. AI 모델이 아무리 좋아도, 그 모델에 들어가는 데이터가 사일로에 갇혀 있고 관계가 끊겨 있으면 좋은 결과가 나오지 않는다.
Graphwise가 말하는 “지식 그래프는 AI의 GPS”라는 표현이 이 상황을 잘 설명한다. 아무리 좋은 차라도 지도가 없으면 목적지에 못 간다. LLM은 강력한 언어 능력을 갖고 있지만, 조직의 데이터가 어떻게 연결되는지를 모르면 제대로 된 답을 내놓을 수 없다. 지식 그래프는 그 지도 역할을 한다.
사내 지식 관리 문제를 AI로 풀려는 시도가 늘어나는 지금, 벡터 검색으로 시작해서 한계에 부딪히고 있다면 지식 그래프 레이어를 더하는 방향이 다음 단계다. Graphwise는 그 방향에서 가장 완성도 높은 플랫폼 중 하나다.