AI를 도입한 기업의 70% 이상이 적어도 하나의 업무 기능에 AI를 붙였다. 그런데 프로덕션 규모로 성공적으로 배포한 곳은 11%에 불과하다는 조사 결과가 있다. 파일럿에서 멈추는 이유는 대부분 모델이 나빠서가 아니다. 모델에 들어가는 데이터가 준비가 안 돼 있어서다.
Graphwise는 이 문제를 정면으로 겨냥한 플랫폼이다. 2024년 Ontotext와 Semantic Web Company가 합병해서 만들어진 회사인데, 두 곳 모두 20년 넘게 지식 그래프와 온톨로지 분야를 해온 곳이다. 그래서 Graphwise가 말하는 “AI 준비된 데이터”는 단순한 마케팅 문구가 아니라, 오랜 기간 엔터프라이즈 현장에서 검증된 기술 위에 서있다.
이 글은 Graphwise가 무엇인지, 어떤 구조로 동작하는지, 실무에서 어떻게 쓸 수 있는지를 한 자리에 정리한다. 개별 기술 하나씩을 깊게 파고드는 글은 별도로 있으니, 여기서는 전체 그림을 잡는 데 집중한다.
Graphwise가 나온 배경 – 왜 지금인가
RAG가 LLM 환각을 줄이는 기술로 주목받으면서 수많은 기업이 RAG 파이프라인을 구축했다. 문서를 청크로 잘라서 벡터 임베딩으로 변환하고, 유사도 검색으로 컨텍스트를 뽑아서 LLM에 넘기는 방식이다. 처음에는 잘 됐다. 아무 컨텍스트 없이 LLM에게만 묻던 때보다 확연히 나아졌다.
문제는 조금만 복잡해지면 벡터 RAG가 무너진다는 점이다. 여러 개체 사이의 관계를 추론해야 하거나, 전체 데이터에서 패턴을 파악해야 하거나, 부서마다 다른 용어를 쓰는 환경에서 검색 정확도가 급격히 떨어진다. 청크로 쪼갠 문서에는 관계 정보가 없다. 문서가 얼마나 비슷한지는 알아도, 개체들이 서로 어떻게 연결돼 있는지는 모른다.
Graphwise가 접근하는 방식이 다른 이유가 여기 있다. 데이터를 청크로 평탄화하는 게 아니라, 데이터 안의 개체와 관계를 추출해서 지식 그래프로 구조화한다. 그 구조화된 지식을 LLM이 추론의 기반으로 쓴다. 이걸 GraphRAG라고 부른다. Graphwise는 2026년 2월에 이 GraphRAG를 로우코드 AI 워크플로 엔진으로 공식 출시했다.
Graphwise 플랫폼의 세 가지 핵심 구성
Graphwise 플랫폼은 크게 세 개의 레이어로 이해하면 된다.
첫 번째가 GraphDB다. Ontotext가 20년 이상 개발해온 RDF 기반 그래프 데이터베이스다. BBC에서 하루 100만 건 이상의 SPARQL 쿼리를 처리하는 환경에서 검증된 엔진이다. GraphDB에서 데이터는 “주어-서술어-목적어” 형태의 트리플로 저장된다. “삼성전자 → 자회사 → 삼성SDI”처럼 모든 데이터가 노드와 엣지로 연결된 그래프가 된다. 이 그래프 위에서 SPARQL 쿼리로 복잡한 다단계 관계를 탐색할 수 있다.
두 번째가 PoolParty다. Semantic Web Company가 개발한 택소노미 및 지식 관리 도구다. 180개 이상의 기업에서 사용하고 있으며, 기업 내 용어를 정리하고 개념 간 관계를 명시적으로 정의하는 데 쓴다. 영업팀이 “고객사”라고 부르고 개발팀이 “클라이언트”라고 부르는 개념을 하나로 묶는 작업이 여기서 시작된다. 다국어 지원이 되기 때문에 여러 언어를 쓰는 글로벌 기업에서도 일관된 개념 체계를 유지할 수 있다.
세 번째가 GraphRAG 워크플로 엔진이다. 2026년 2월 공식 출시된 가장 최신 레이어다. LLM, 기업 데이터, GraphDB 지식 그래프, 벡터 검색, 키워드 검색을 하나의 파이프라인으로 묶는다. 로우코드 시각적 엔진으로 구성돼 있어서, Python 개발자가 아닌 업무 담당자도 AI 로직을 조정할 수 있다. OpenAI, Claude, Azure AI, Amazon Bedrock 등 주요 LLM을 모두 지원하고, OpenSearch나 Elasticsearch 같은 기존 벡터 스토어와도 통합된다.
GraphRAG가 일반 RAG와 다른 결정적 차이
Graphwise의 GraphRAG가 내세우는 핵심 차별점은 설명 가능성과 감사 가능성이다. 일반 RAG는 왜 이 청크가 검색됐는지, 어떤 근거로 이 답변이 나왔는지를 추적하기 어렵다. 블랙박스처럼 동작한다.
GraphRAG는 이 파이프라인을 투명하게 만든다. 사용자가 “이 답변의 근거가 뭐야”라고 물으면, 어떤 문서와 그래프 노드에서 정보가 왔는지, 어떤 관계를 따라 추론했는지를 보여준다. 금융, 의료, 법률처럼 AI 출력을 감사하거나 규제 기관에 설명해야 하는 환경에서 이 추적 가능성이 결정적이다.
검색 방식도 단일 벡터 검색에 의존하지 않는다. GraphRAG는 벡터 유사도 검색, SPARQL 그래프 탐색, 키워드 검색을 질문 유형에 따라 적절히 조합한다. 사용자의 질문에서 온톨로지 기반으로 개념을 확장해서 쿼리를 보강하기 때문에, 짧고 모호한 질문에도 도메인 맥락을 반영한 검색이 가능하다. 이걸 쿼리 확장이라고 부르는데, “Paris Hilton”을 파리(도시)로 혼동하지 않는 것처럼 개체 링킹 정확도가 올라간다.
실제 고객 사례에서 전통 RAG 방식의 답변 정확도가 60% 수준이었던 게 Graphwise GraphRAG를 적용한 후 90% 이상으로 올라갔다는 결과가 나왔다. MuSiQue 벤치마크에서는 온톨로지 기반 지식 그래프를 추가했을 때 오답이 두 배 이상 줄었다는 결과도 있다.
실무에서 Graphwise를 쓰는 흐름
처음 Graphwise를 도입하는 흐름은 대략 이렇게 된다.
먼저 PoolParty로 택소노미를 잡는다. 조직 내 주요 개념과 용어를 정리하고, 부서 간 용어 불일치를 해소하는 작업이다. 이 과정이 시간이 걸리는데, 기술 작업보다 조직 내 합의가 더 오래 걸린다는 걸 미리 알고 시작하는 게 좋다.
택소노미가 잡히면 GraphDB에 지식 그래프를 구축한다. 기존 문서, DB, CRM, ERP에서 개체와 관계를 추출해서 RDF 트리플로 저장한다. GraphDB는 GraphQL, JDBC, Kafka를 통한 외부 시스템 연동을 지원하기 때문에 기존 스택에 붙이는 방식으로 통합할 수 있다.
지식 그래프가 구축되면 GraphRAG 워크플로 엔진을 얹는다. 로우코드 시각적 인터페이스로 RAG 파이프라인을 구성하고, LLM과 검색 방식을 연결한다. Talk-to-Your-Graph 기능을 활성화하면 비기술 사용자도 자연어로 그래프에 질문할 수 있다. 내부적으로 SPARQL 쿼리가 자동 생성돼서 지식 그래프를 탐색하고 답을 가져온다. 사내 지식 관리에 Graphwise를 적용한 실무 경험에서 이 과정의 디테일을 더 자세히 다뤘다.
Graphwise가 맞는 상황과 아닌 상황
Graphwise를 도입할 때 먼저 짚어야 할 게 있다. 이 플랫폼이 모든 RAG 문제의 정답은 아니라는 점이다.
데이터가 단순하고 단일 시스템에 잘 정리돼 있으며, 사용자 질문이 대부분 단순 사실 조회라면 벡터 RAG와 BM25 하이브리드 검색으로 충분하다. 인프라를 추가하고 SPARQL을 배우는 비용을 치를 필요가 없다. GraphDB와 pgvector를 실무에서 비교한 경험에서 어느 쪽이 맞는지 판단하는 기준을 자세히 정리했다.
반면 이런 상황이라면 Graphwise를 진지하게 고려할 만하다. 부서마다 다른 용어를 쓰고 여러 시스템에 데이터가 흩어져 있어서 AI가 이 경계를 넘나들며 답해야 한다면. 여러 개체의 관계를 추론하는 multi-hop 질문이 많다면. 금융, 의료, 법률처럼 AI 답변의 근거를 추적하고 감사해야 한다면. 이 세 가지 중 하나라도 해당된다면 Graphwise가 제공하는 지식 그래프 레이어가 의미 있는 차이를 만든다.
도입 전에 현실적으로 확인할 것들
GraphRAG 워크플로 엔진이 2026년 2월에 공식 출시됐다는 건 아직 독립적인 장기 운영 검증 사례가 많지 않다는 뜻이다. GraphDB와 PoolParty 자체는 20년 이상의 프로덕션 검증이 있지만, 통합된 GraphRAG 엔진은 비교적 새로운 제품이다. 도입을 결정하기 전에 자체 데이터로 POC를 먼저 해보는 게 맞다.
SPARQL을 다룰 수 있는 인력이 필요하다. Talk-to-Your-Graph가 비기술 사용자 접근성을 높여주지만, 온톨로지를 설계하고 시스템을 구축하는 단계에서는 시맨틱 웹 기술에 익숙한 인력이 필요하다. 조직 내에 이 역량이 없다면 초기에 전문 파트너사 도움이 필요하다.
비용 구조도 엔터프라이즈 라이선스 기반이라 조직 규모에 따라 차이가 크다. GraphDB는 무료 버전도 있지만 고가용성 클러스터나 멀티리전 배포는 유료 라이선스에서 지원된다. graphwise.ai에서 직접 데모를 요청하고 견적을 받아보는 게 현실적인 첫 단계다.
AI 파일럿이 프로덕션으로 가지 못하는 진짜 이유
Graphwise가 자주 언급하는 개념 중에 “Prototype Plateau”가 있다. AI 파일럿은 잘 되는데 프로덕션으로 못 가는 현상이다. 이 정체의 원인으로 Graphwise는 RAG 파이프라인의 구조적 한계를 꼽는다. 얕은 검색, 답변 표류, 비즈니스 로직 소실, 사일로에 갇힌 지식.
이 문제들은 모델을 바꾼다고 해결되지 않는다. 모델에 들어가는 데이터와 그 데이터의 구조가 바뀌어야 한다. 지식 그래프는 이 구조를 만드는 방법이다. 흩어진 데이터를 개체와 관계로 연결하고, 그 연결된 지식을 AI가 추론의 기반으로 쓰게 만드는 것이다.
RAG를 도입했는데도 AI 답변이 기대에 못 미치는 상황이라면, 청킹 전략을 더 정교하게 만드는 방향보다 검색 구조 자체를 바꾸는 방향을 먼저 점검해볼 필요가 있다. 그 방향의 끝에 Graphwise가 있다. GraphRAG와 일반 RAG의 구조적 차이에서 이 판단의 기준을 더 자세히 다뤘다.