"우리 회사 챗봇은 '2023년 A거래처 계약서 어디 있어?'는 잘 찾는데, 'A거래처랑 맺은 계약 중에 신규 하도급법 개정안에 걸리는 조항 있어?'라고 물으면 완전히 바보가 됩니다."
— 중견 제조사 법무팀장이 상담에서 던진 한 문장
이 질문 하나에 사내 챗봇 시장의 '진짜 돈'이 숨어 있습니다. 대부분의 사내 챗봇은 단일 문서 검색은 잘합니다. 문서 하나 안에 답이 통째로 들어 있으면 벡터 검색(일반 RAG)으로 충분하니까요. 문제는 현실의 업무 질문이 거의 항상 여러 문서를 '엮어야' 답이 나오는 멀티홉(multi-hop) 질문이라는 데 있습니다.
계약서 → 거래처 마스터 → 사내 규정 → 개정 법령. 이 네 개를 연결해야 답이 나오는 질문을 일반 RAG에 던지면, 네 문서 조각을 각각 긁어오긴 하지만 그 사이의 관계를 읽지 못해 엉뚱한 답을 내놓습니다. 바로 이 틈을 메우는 것이 지식그래프 RAG(Knowledge Graph RAG)이고, 과거엔 온톨로지 설계 전문가가 몇 달을 붙어야 했던 이 작업을 NVIDIA의 auto-ontology 오픈소스가 자동화해 버렸습니다.
왜 챗봇이 '엮는 질문'에서 멍청해질까
원리를 먼저 그림으로 보겠습니다. 일반 RAG와 지식그래프 RAG는 '검색하는 대상'이 근본적으로 다릅니다.
멀티홉 질문의 답은 문서 '안'이 아니라 문서와 문서 '사이'에 있습니다. 벡터 검색은 문서 안을 뒤지고, 지식그래프는 문서 사이의 선(관계)을 따라갑니다. 이 차이가 "자료가 부족합니다"와 "이 조항이 걸립니다"를 가릅니다.
온톨로지, 더 이상 수작업이 아니다
과거에 지식그래프의 진입장벽은 온톨로지 설계였습니다. "어떤 개체(계약·거래처·조항)를 노드로 둘지, 어떤 관계(체결·위반·적용)를 엣지로 둘지"를 사람이 일일이 정의해야 했죠. 중소기업 문서 체계 하나 설계하는 데 전문가 투입 수백만 원이 깨졌습니다.
NVIDIA가 공개한 auto-ontology 계열 오픈소스(NeMo·cuGraph 생태계와 연동되는 LLM 기반 온톨로지 추출 파이프라인)는 이 과정을 뒤집습니다. 문서 더미를 넣으면 LLM이 개체·관계·스키마를 스스로 추론해 온톨로지 초안을 자동 생성합니다. 비전공자가 할 일은 '검수와 보정'으로 줄어듭니다.
건당 150만원 받는 5단계 실전 플로우
1단계 — 문서 수집·정제
고객사에서 받는 것은 대개 PDF와 한글 문서 더미입니다. 계약서, 사내 규정집, 거래처 마스터 엑셀, 관련 법령. 이걸 텍스트로 파싱하고 주민번호·계좌 같은 민감정보를 마스킹합니다. 이 단계의 품질이 전체 정확도의 절반을 결정합니다.
2단계 — auto-ontology 자동 추출
정제된 텍스트를 NVIDIA auto-ontology 파이프라인에 투입합니다. "㈜한빛물산은 2024년 공급계약의 '을'이다", "해당 계약은 하도급법 제13조의 적용을 받는다" 같은 (개체)-(관계)-(개체) 트리플을 자동으로 뽑아냅니다. 비전공자는 결과를 표로 확인하며 오추출만 걸러내면 됩니다.
3단계 — 그래프 DB 적재
추출된 트리플을 Neo4j 같은 그래프 DB에 노드·엣지로 넣고, 동시에 원문 조각은 벡터 임베딩으로 저장합니다. 이 하이브리드 구조가 "관계 추론(그래프) + 세부 문맥(벡터)"을 모두 커버합니다.
4단계 — 멀티홉 검색 챗봇 연결
사용자 질문이 들어오면 챗봇은 ①그래프에서 관련 개체를 타고 이동하며 경로를 찾고 ②그 경로 위 문서 원문을 벡터로 끌어와 ③LLM이 출처가 표시된 답변을 생성합니다. "A거래처 계약 중 개정 하도급법에 걸리는 조항은 제7조이며, 근거는 규정집 p.12입니다" 같은 식입니다.
5단계 — 검수·납품·유지보수 계약
초기 오답을 고객과 함께 교정하고 납품합니다. 핵심은 여기서 끝내지 않는 것 — 문서는 계속 늘어나므로 '월 유지보수 리텐션'을 붙여야 1회성 150만 원이 매월 꽂히는 수익으로 바뀝니다.
제조사: 수백 개 거래처 계약의 규제 리스크를 한 번에 조회 · 로펌: 유사 판례·계약 조항 연결 분석 · 세무법인: 거래처-전표-세법 규정 연결 검증 · 유통사: 공급사 계약-단가표-정산 규정 교차 확인. 모두 '사람이 문서를 손으로 엮던 일'이라 시간당 인건비가 명확합니다.
어디까지가 당신의 일이고, 어디부터가 '진입장벽'인가
솔직하게 말하면, 이 비즈니스의 기술적 난이도는 '중'입니다. 엔진은 오픈소스라 공짜이고 핵심 로직은 공개돼 있습니다. 진짜 장벽은 ①고객 문서 구조를 이해하고 온톨로지를 검수하는 도메인 감각과 ②그래프+벡터 하이브리드를 안정적으로 배포하는 운영력입니다. 이 두 가지는 '해본 사람'과 '글만 읽은 사람'의 격차가 극명합니다.
혼자서 NVIDIA 파이프라인 세팅부터 Neo4j 스키마, LLM 프롬프트, 배포까지 맨땅에 부딪히면 보통 2~3주를 삽질로 날립니다. 그래서 투더제이(TTJ) 코딩클래스 정규반에서는 바로 이 5단계 파이프라인을 실제 샘플 문서(계약·규정 세트)로 처음부터 끝까지 구축해보며, '검수 노하우'와 '고객 납품·리텐션 계약서 템플릿'까지 함께 다룹니다. 기술이 아니라 돈이 되는 결과물을 만들어 나가고 싶다면, 정규반 커리큘럼을 한번 들여다보시길 권합니다. 멍청한 챗봇을 '관계까지 읽는 챗봇'으로 바꾸는 일, 생각보다 가까이 있습니다.