"지식베이스도 다 연결했는데, 고객이 질문을 조금만 비틀면 AI가 엉뚱한 문서를 읽어요." "지난달에 정책이 바뀌었는데, AI는 아직도 예전 답변을 그대로 하고 있더라고요.”
지난 글(happytalk AI Deep Dive 1편)에서는 AI 상담이 고객을 답답하게 만드는 원인을 짚고, 워크플로우와 AI의 맥락 공유, 지식베이스(RAG), API 실행 도구, 국내 상담 환경 최적화라는 해피톡의 네 가지 해결 방식을 소개했습니다.
이번 글은 그 다음 이야기입니다. 지식베이스를 갖추고 나서도 남는 답답함은 어디서 오는지 진단하고, 해피톡이 준비 중인 '그래프 관계 기반 지식 시스템'을 소개하려 합니다.
AI 상담의 지식 품질을 고민하는 CX 리더, 상담 운영 담당자라면 도움이 될 내용입니다.
지식베이스가 있는데도 왜 답답할까
현재 AI 상담의 지식 검색은 대부분 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 방식을 씁니다. 고객이 질문하면 지식베이스에서 관련 문서 조각을 찾아 AI에게 전달하고, AI는 그 조각을 읽고 답변을 만듭니다. 해피톡 역시 이 RAG 인프라를 자체 구축해 정확도를 높여왔습니다.
문제는 검색을 아무리 잘해도 이 구조 자체에 세 가지 한계가 남는다는 점입니다.
질문마다 처음부터 다시 찾습니다 검색은 매번 새로 시작됩니다. 어제 상담에서 확인한 내용이 오늘의 검색을 더 똑똑하게 만들어주지 못합니다.
문서를 ‘조각’으로만 읽습니다 문서 한 장은 정확히 찾아도, 그 문서가 다른 정책·상품·사례와 어떤 관계인지는 모릅니다. 문서와 문서 사이의 맥락이 빠져 있습니다.
지식이 쉽게 낡습니다 정책이 바뀌어 문서 간 내용이 어긋나도, 조각 단위 검색은 그 불일치를 스스로 알아채지 못합니다.
비유하자면 이렇습니다. 지금의 구조는 처음 출근한 직원에게 매뉴얼 한 페이지만 복사해서 쥐여 주는 것과 비슷합니다. 그 페이지 자체는 정확합니다. 하지만 고객이 "그런데 제 경우는 좀 달라서요"라고 말하는 순간부터 상황이 갈립니다.
옆 페이지와 지난달 공지, 비슷한 처리 사례까지 함께 알고 있는 3년 차 상담사는 막힘없이 답하지만, 매뉴얼 한 장만 쥔 신입 직원은 거기서 멈춰버립니다.
매뉴얼 한 장만 쥔 신입처럼, 기존 RAG는 매번 필요한 자료 한 조각만 검색해 LLM에 전달한다
그렇다고 RAG가 잘못됐다는 이야기는 아닙니다. RAG는 ‘필요조건’입니다. 관건은 그 위에 무엇을 더 얹느냐 입니다.
업계가 움직이는 방향, '더 많이 검색'이 아니라 '관계로 연결'
이런 한계는 상담 업계만의 고민이 아닙니다. 최근 개발자 생태계에서도 코드·문서·업무 지식을 낱장으로 검색하는 대신, 서로 연결되고 계속 갱신되는 '지식 그래프'나 위키 형태로 만들어 AI가 관계를 따라가며 찾게 하는 오픈소스 도구들이 빠르게 늘고 있습니다.
AI 도구를 가르는 기준이 ‘한 번에 얼마나 많은 문서를 읽는가’에서 ‘지식을 어떤 구조로 기억하는가’로 옮겨가는 중입니다.
💡
개념 정리: ‘그래프’와 ‘위키’
그래프(graph)는 점과 선으로 이루어진 구조입니다. 지식 하나하나가 점(노드)이 되고, 지식 사이의 관계가 선(연결)이 됩니다. 지하철 노선도를 떠올리면 이해하기 쉽습니다. 역 하나만 아는 것과 노선도 전체를 아는 것은 다릅니다. 역 하나(문서 한 장)를 정확히 아는 것도 중요하지만, "여기서 어디로 갈아탈 수 있는가"라는 연결을 알아야 목적지, 즉 고객 문제 해결에 도달할 수 있습니다.
그래프 (Graph)
위키(wiki)는 링크로 연결되어있고 계속 업데이트 되는 문서입니다. 위키피디아를 떠올리면 됩니다. 본문 속 파란 글자를 클릭하면 관련 문서로 바로 넘어가고, 내용은 계속 새로 고쳐집니다. ‘문서 + 링크’라는 이 구조는 곧 ‘점 + 선’, 즉 그래프 형태를 띱니다.
위키(Wiki)
위키와 지식 그래프는 같은 지식 구조를 서로 다르게 표현한 것입니다. 사람 눈에는 읽기 좋은 위키로 보이고, AI에게는 관계를 따라 탐색할 수 있는 지식 지도가 됩니다.
AI 연구자들이 먼저 도착한 결론, 카파시 (Karpathy)의 'LLM 위키'
이 흐름을 상징적으로 보여준 사례가 있습니다. AI 연구자 안드레이 카파시(Andrej Karpathy, OpenAI 창립 멤버·전 테슬라 AI 리드)가 공개한 'LLM 위키'라는 아이디어입니다.
여기서 LLM(거대 언어 모델)은 챗봇 AI의 두뇌에 해당하는 기술을 가리킵니다. ‘AI가 스스로 읽고 가꾸는 위키’라는 뜻이죠. 그가 든 비유는 해피톡의 문제의식과 정확히 맞닿아 있습니다.
지금의 검색(RAG) 방식은 배가 고플 때마다 매번 장을 보고 요리를 처음부터 하는 것과 같다. 한 번 요리한 지식을 서로 링크된 위키로 정리해 두면, 다음부터는 위키에 묻기만 하면 된다. 지식이 쌓이는 것이다.
카파시 (Karpathy) LLM 위키의 핵심 아이디어 (스레드 @reedo.dev)
결국 AI에게 원본 문서 더미를 매번 다시 읽히는 대신, AI가 읽고 갱신하기 좋은 자기만의 백과사전을 만들어 주자는 이야기입니다. 이 아이디어는 랭체인 (LangChain)의 오픈위키(OpenWiki) 같은, AI 에이전트를 위한 위키형 장기 기억 도구로 빠르게 구현되고 있습니다.
구글이 만드는 지식 표준, OKF(개방형 지식 포맷)
개별 도구를 넘어 표준화도 이미 시작됐습니다.
구글 클라우드(Google Cloud)는 OKF(Open Knowledge Format)라는 이름으로 ‘AI가 읽고 갱신하기 쉬운 지식 묶음의 형식’을 공개 사양으로 내놓았습니다. 문서 세계에 PDF라는 공통 형식이 있어 어떤 프로그램에서든 같은 문서를 열 수 있듯, AI용 지식 묶음에도 공통 형식을 만들자는 취지입니다.
이런 표준화는 기업에도 분명한 이점이 있습니다. OKF 같은 공통 형식으로 쌓은 지식은 특정 도구에 종속되지 않고, 온전히 회사의 지식 자산으로 남기 때문입니다.
이 흐름을 상담 도메인으로 옮겨보면 이렇게 번역됩니다.
상품, 정책, FAQ(자주 묻는 질문), 상담 이력이 개별 문서가 아니라 서로 연결된 지도가 됩니다. AI는 문서를 '검색'하는 것을 넘어, 지도 위의 관계를 '추적' 합니다.
구글 클라우드, AI 에이전트 지식을 마크다운 파일로 담는 개방형 표준 'OKF' 공개
그래프 관계 기반 지식이 상담 현장에서 하는 일
실제 상담 현장에서는 어떤 차이가 날까요? 예시로 보겠습니다.
💬 고객: "지난주에 산 신발, 한 번 신었는데 반품 되나요?"
평면 검색이라면 '반품 규정' 문서 조각을 찾아 이렇게 답합니다.
"구매 후 7일 이내 미사용 상품은 반품 가능합니다."
틀린 답은 아니지만, 고객은 이미 "한 번 신었다"고 말했습니다. 원론적인 답변 앞에서 고객의 다음 질문은 뻔하고, 상담은 한 바퀴를 돌게 됩니다.
반면 관계 기반으로 탐색하면 AI가 정보를 찾아가는 흐름 자체가 달라집니다.
이 고객의 주문에서 출발해 → 주문 속 상품의 카테고리(신발) → 카테고리별 반품 정책 → 정책에 연결된 '착용 시 예외 조항' → 그 예외 조항이 적용된 과거 유사 상담 사례까지 이어집니다.
다섯 개의 지식이 관계선을 따라 연결되고, AI는 ‘이 고객의 이 주문’에 맞는 답에 도달합니다. 착용 흔적 기준, 예외 접수 절차, 비슷한 사례의 처리 결과까지, 숙달된 상담사가 머릿속에서 자연스럽게 잇던 경로를 지식 그래프가 대신 연결해주는 것입니다.
"신발 반품 되나요?" 문의에 대한 평면 검색과 관계 기반 탐색의 처리 과정 비교
여기서 지난 글과 이야기가 이어집니다. ‘happytalk AI Deep Dive 1편’에서 강조한 것은 워크플로우와 AI의 맥락 공유, 즉 고객이 이미 입력한 주문번호를 AI가 다시 묻지 않는 구조였습니다. 워크플로우가 이미 아는 정보(주문번호, 고객 맥락)가 지식 그래프의 출발점과 연결될 때, 비로소 ‘다시 묻지 않고, 끝까지 해결하는’ AI 상담이 완성됩니다.
지식이 자동으로 쌓이면 오류도 자동으로 쌓입니다
여기까지 읽으면 "그럼 지식을 그래프로 자동으로 쌓으면 되겠다"는 생각이 들 수 있습니다.
하지만 분명히 짚어야 할 부분이 있습니다. 지식이 자동으로 쌓인다면 오류도 자동으로 쌓일 수 있다는 점입니다. 잘못 연결된 관계 하나가 잘못된 답변 열 개를 만들어낼 수 있습니다.
그래서 관계 기반 지식 시스템에는 반드시 ‘신뢰 장치’가 함께 설계돼야 합니다. 도입을 검토한다면 다음 네 가지를 확인해보시길 권합니다.
CHECK LIST
1. 출처 표시
이 답변이 어느 문서, 어느 정책에서 왔는지 추적할 수 있는가
2. 시간 정보
지식마다 생성일과 마지막 검증일이 남는가
3. 충돌 감지
정책 변경으로 지식끼리 어긋나면 시스템이 알아채는가
4. 사람의 검수 흐름
자동 생성된 지식이 상담에 반영되기 전, 운영자가 확인하는 단계가 있는가
생성형 AI의 유연함과 운영 구조의 단단함, 이 둘이 균형을 이룰 때 비로소 가치 있는 AI 상담이 완성됩니다. 지식 레이어도 다르지 않습니다. 유연하게 쌓이는 지식일수록 단단한 검증 위에 놓여야 합니다.
해피톡 AI 에이전트가 준비하고 있는 것
해피톡 AI 에이전트는 자체 RAG 지식베이스 위에 관계 기반 지식 시스템을 더하는 고도화를 진행하고 있습니다. 방향은 크게 세 가지입니다.
관계 레이어 : 상품, 정책, FAQ, 상담 이력을 낱장 문서가 아니라 연결된 지식 지도로 관리합니다.
워크플로우와의 결합 : 워크플로우가 이미 확보한 고객 맥락(주문, 이력)이 지식 추적의 출발점이 됩니다.
신뢰 가드레일 : 출처와 갱신 이력이 남는 지식, 운영자가 검수할 수 있는 지식을 원칙으로 합니다.
해피톡은 RAG 지식베이스 위에 관계 기반 지식 시스템을 더하는 고도화를 진행 중입니다
이 변화는 고객에게 ‘다시 설명하지 않아도 되는’ 상담으로, 상담사에게는 신규 입사자도 3년 차의 지식 경로를 그대로 활용하는 온보딩 단축으로, 운영 담당자에게는 정책이 바뀌어도 답변이 일관되게 유지되는 지식 관리로 이어집니다.
마치며 — AI 상담의 지식 시스템을 점검하는 4가지 질문
지금 쓰고 있는 AI 상담의 지식 시스템이 ‘관계 기반’으로 작동하는지, 아래 네 가지 질문으로 점검해보실 수 있습니다.
우리 AI는 지난 대화와 주문 맥락을 기억하는가, 아니면 매번 처음부터 묻는가?
우리 AI는 문서 한 장이 아니라 문서 사이의 관계를 알고 있는가?
정책이 바뀌면 관련 지식이 함께 바뀌는가, 아니면 낡은 답변이 남는가?
AI 답변의 출처와 검증일을 운영자가 반영 전에 확인할 수 있는가?
정리하면, 기존 평면 검색형 지식베이스는 단일 문서 조각을 질문마다 처음부터 다시 검색하다 보니 낡은 조각이 남을 수 있습니다. 반면 관계 기반 지식 시스템은 연결된 지식 경로를 워크플로우 및 이력과 함께 탐색하며, 지식 간 충돌 감지와 출처·검증일 기반의 검수 흐름을 제공합니다.
구분
평면 검색형 지식베이스
관계 기반 지식 시스템
검색 단위
문서 조각
연결된 지식 경로
맥락
질문마다 초기화
워크플로우·이력과 연결
정책 변경 시
낡은 조각이 남을 수 있음
연결된 지식의 충돌 감지
신뢰성
문서 단위 관리
출처·검증일·검수 흐름
생성형 AI의 유연함과 운영 구조의 단단함, 그 균형의 다음 단계는 결국 지식의 구조에 달려 있습니다. 고객의 문제를 끝까지 해결하는 AI 상담을 고민하고 계신다면, 해피톡과 함께 그 다음 단계를 준비해 보세요.
