추천의 근거는 어디서 오는가 — 상담어시스트의 KMS·RAG 지식 그라운딩


상담어시스트 도입 사례들을 나란히 놓고 비교해 보면, 화면에 뜨는 추천 답변의 품질을 가르는 것은 화려한 LLM이 아니라 그 뒤에 있는 KMS(지식관리시스템)라는 점이 두드러집니다. 어느 공공기관 상담 창구에서는 종이 매뉴얼을 스캔해 화면에 그대로 띄워 놓고 상담사가 눈으로 찾아 읽는 수준의 지식 관리를 목격하기도 했습니다. STT와 인텐트 분석이 아무리 정확해도, 검색할 지식 저장소가 부실하면 어시스트는 빈손으로 상담사 앞에 섭니다. 이 글은 상담어시스트 추천의 근거가 되는 KMS·RAG 지식 그라운딩을 실무 관점에서 정리합니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 9-3편

← 이전: 9-2 상담어시스트의 뼈대 — STT·인텐트·KMS 파이프라인 / 다음 → 9-4 통화 중 놓친 고지를 잡는 실시간 필수 안내 체크

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

추천 품질은 KMS 품질에 종속됩니다

상담어시스트의 파이프라인은 실시간 STT로 통화를 텍스트화하고, LLM이 고객 의도를 파악한 뒤, KMS를 검색해 답변과 지식을 상담사 화면에 추천하는 구조입니다. 여러 도입 사례의 체인을 서로 비교해 보면 확인되는 사실은 단순합니다. 전체 품질은 가장 약한 링크가 결정하고, 그 약한 링크는 대부분 KMS라는 것입니다. STT 인식률을 끌어올리고 인텐트 분류를 정교하게 다듬어도, 정작 검색 대상인 지식 저장소에 낡은 문서와 정리되지 않은 매뉴얼만 있다면 어시스트는 틀린 근거를 자신 있게 추천하거나 아무것도 찾지 못합니다.

공공기관 사례와 금융권 사례를 나란히 놓고 보면, 이 문제는 특히 공공 쪽에서 두드러졌습니다. 지식 관리가 사실상 종이 매뉴얼을 화면에 표시하는 수준에 머물러 있는 곳에서는, 어시스트 도입 이전에 KMS 구축 자체가 선결 과제였습니다. 흥미로운 점은 상담사들이 체감하는 핵심 가치도 바로 이 지점이라는 것입니다. 화면에 뜨는 AI 추천의 정확도 이전에, "찾을 수 있는 형태로 정리된 지식"이 생기는 것 자체가 현장에는 큰 변화였습니다. 어시스트 프로젝트가 실제로는 지식 정비 프로젝트를 품고 있는 셈입니다.

이런 사례들이 쌓이며 굳어진 원칙은, KMS가 모든 채널의 단일 원천(single source of truth)이어야 한다는 것입니다. 사업부가 1차 작성한 지식이 KMS에 먼저 쌓이고, 홈페이지에는 대고객 요약이, 어시스트에는 상담사용 상세가, AI에는 검색·학습용 정제분이 계층적으로 분배되는 구조입니다. 채널별 안내를 나란히 놓고 비교해 보면, 그 불일치 자체가 민원을 만든다는 패턴이 반복해서 나타났습니다.

[지식 계층 분배 — KMS 단일 원천]

 사업부 1차 작성
        ↓
  KMS (단일 원천)
        ↓
 ├ 홈페이지 — 대고객 요약
 ├ 어시스트 — 상담사용 상세
 └ AI — 검색·학습용 정제분

게시판형 KMS와 AI가 검색하는 KMS는 다릅니다

여기서 많은 현장이 오해하는 지점이 있습니다. "우리도 KMS 있어요. 사내 게시판에 매뉴얼 다 올려놨어요"라는 반응입니다. 그러나 사람이 열람하는 게시판형 KMS와 AI가 검색·평가에 쓰는 KMS는 요구 조건이 근본적으로 다릅니다. 후자는 문서를 잘게 쪼개고(청킹) 각 조각을 벡터로 변환(임베딩)해 저장해야 AI가 의미 기반으로 검색할 수 있습니다. 단순히 글을 올리는 게시판이 아니라, 문서 처리 파이프라인과 벡터 검색 인프라를 갖춘 별도 솔루션 급의 시스템입니다.

구분게시판형 KMSAI가 검색하는 KMS
저장 단위문서·게시글 통째의미 단위 청크
검색 방식제목·키워드 매칭임베딩 기반 의미 검색
결과 형태문서 링크 목록해당 섹션 하이라이트 + 출처
등록 절차파일 업로드로 끝파싱→청킹→임베딩 파이프라인 통과
요구 인프라일반 웹 게시판문서 처리 + 벡터 검색(별도 솔루션 급)

이 차이를 도입 초기에 인식하지 못하면, 기존 게시판을 그대로 두고 어시스트만 얹으려다 추천 품질이 나오지 않아 프로젝트 전체가 흔들립니다. 그래서 제안 단계에서는 이 구분을 반드시 먼저 설명하고, KMS 전환 공수를 일정에 명시적으로 잡는 것을 원칙으로 삼게 되었습니다.

문서 파이프라인 — 한글 파일에서 임베딩까지

실제 상담 지식의 원천은 대부분 한글(.hwp) 문서와 PDF입니다. 공공과 금융 현장일수록 이 비중이 압도적입니다. 이 문서들이 AI가 검색 가능한 지식이 되기까지는 다음 단계를 거칩니다.

[상담 지식 문서 파이프라인]

 .hwp / PDF 업로드
        ↓
 OCR·파싱 (레이아웃·표 해석)
        ↓
 마크다운 변환 (구조 보존)
        ↓
 청킹 (의미 단위 분할)
        ↓
 임베딩 (벡터화)
        ↓
 KMS 등록 → 검색 인덱스 반영

이 파이프라인에서 추천 품질을 좌우하는 단계는 의외로 임베딩이 아니라 파싱입니다. 일반적인 RAG 구축에서 파싱은 지저분해지기 쉬운 단계입니다. 업무 매뉴얼에는 다단 표, 각주, 서식이 뒤섞여 있는데, 이것이 깨진 채로 마크다운이 되면 그 뒤의 청킹과 임베딩이 아무리 정교해도 검색 결과에 반쪽짜리 문장과 뒤엉킨 표가 올라옵니다. 상담사 화면에 그런 조각이 추천으로 뜨는 순간 어시스트에 대한 현장의 신뢰는 급격히 떨어집니다. 파싱이 꼼꼼했던 사례와 그렇지 않았던 사례를 나란히 놓고 보면, 파싱 품질이 곧 추천 품질이라는 결론에 이르게 됩니다.

기존 KMS는 어디까지나 사람이 읽는 매뉴얼이었으므로, 이를 RAG가 읽는 형태로 전환하는 과정이 반드시 필요합니다. 이때 임베딩 모델·파서·이미지/도형 인식 모듈은 정답이 하나로 정해져 있지 않고, 고객 문서가 HTML 위주인지 PDF·엑셀 위주인지에 따라 선택이 달라집니다. 어떤 조합이든 문서를 업로드하면 자동으로 구조화되는 파이프라인까지 갖춰야 운영이 굴러갑니다.

키워드 매칭이 아니라 섹션 하이라이트까지

파이프라인을 갖췄다면, 다음은 검색 결과를 상담사에게 어떤 형태로 보여 주는가입니다. 통화는 실시간으로 흐르고 있습니다. 문서 제목과 링크만 던져 주는 방식이라면, 상담사는 고객을 기다리게 한 채 수십 페이지 문서를 열어 해당 부분을 눈으로 찾아야 합니다. 그것은 기존 게시판 검색과 다를 게 없고, 실무에서는 쓰이지 않게 됩니다.

필자도 이 실패를 직접 겪었습니다. 초기에 KMS 원문을 그대로 화면에 띄웠더니, 상담사가 원하는 페이지를 찾는 데 오히려 10~20초가 더 걸렸습니다. 요약 형태로 제공하는 방식으로 전환한 것이 실사용 만족의 전환점이었고, 이후 상담사가 지식 검색에 쓰는 시간은 절반 이하로 줄었습니다.

쓸 만한 어시스트는 문서 내 특정 파트, 즉 질문과 관련된 섹션까지 찾아 들어가 해당 구간을 하이라이트해 제시합니다. 여러 화면 구성을 견주어 봐도 이 원칙은 공통적으로 따르고 있었습니다. 상단에는 답변 추천이, 그 아래에는 문서 출처와 근거 제목이 색상 태그로 구분되어 표시되고, 하단에는 대화 맥락 기반의 지식 추천이 이어지는 구조였습니다. 답변만 던지는 것이 아니라 "이 답변이 어느 문서의 어느 부분에서 왔는가"를 함께 보여 주는 것입니다. 이 출처 제시가 있어야 상담사가 추천을 검증하고 신뢰할 수 있고, 잘못된 추천이 나왔을 때도 원인이 되는 문서를 바로 특정할 수 있습니다. 검색이 청킹 단위로 이뤄지기 때문에 가능한 형태이기도 합니다. 문서 통째가 아니라 의미 조각 단위로 저장되어 있으니, 매칭된 조각이 곧 하이라이트할 섹션이 됩니다.

실시간 지식 등록 — 그 자리에서 등록하고 즉시 반영

KMS는 한 번 구축하고 끝나는 저장소가 아닙니다. 실제 운영에서는 신상품 출시나 정책 변경으로 아직 등록되지 않은 지식이 매일 생깁니다. 여러 기능을 비교해 봤을 때 특히 유용했던 것이 실시간 지식 등록입니다. 상담 중 미등록 상품이나 지식이 확인되면 그 자리에서 등록하고, 등록 즉시 추천에 반영되는 흐름입니다.

물론 평시의 최신화는 데일리 배치가 담당합니다. 실시간 등록과 데일리 배치, 두 경로를 놓고 비교하면, 지켜본 운영 구조에서는 신상품 출시나 정책 변경이 생기면 전사 공지가 나가고, 담당자가 KMS를 수정하면 파이프라인이 익일 어시스트에 자동 반영합니다. 같은 지식이 여러 버전 존재하면 최신 버전을 우선 추천하도록 잡아 둡니다. 실시간 등록은 이 배치 주기조차 기다릴 수 없는 공백을 그 자리에서 메우는 보완 경로인 셈입니다.

이것이 가능하려면 등록이 곧 파이프라인 실행이어야 합니다. 관리자가 문서를 올리면 파싱·청킹·임베딩·인덱스 반영이 자동으로 이어져야, 배치 주기를 기다리지 않고 다음 콜부터 새 지식이 검색됩니다. 운영 관점에서 이 기능의 진짜 가치는 지식 공백의 발견과 보수가 선순환된다는 점입니다. 어시스트가 추천에 실패한 지점이 곧 KMS에 빠져 있는 지식이고, 그 자리에서 메우면 같은 실패가 반복되지 않습니다. 게시판형 운영에서는 이 루프가 문서 담당자의 손을 거쳐 며칠씩 걸리던 일입니다.

KMS는 결국 사람과 피드백 루프가 지킵니다

"AI가 도입되면 KMS는 알아서 관리되지 않느냐"는 질문을 자주 받습니다. 답은 아니라는 것입니다. AI 도입 전후의 KMS 운영 인력을 비교해 보면, 도입 후에도 KMS 전담 인력이 상시 수 명 있고, 기존에 공지를 담당하던 인력이 겸임하는 형태로 운영되는 경우가 많았습니다. AI 도입 후에도 이 역할은 사라지지 않았습니다.

대신 사람의 역할은 AI 인더루프의 축으로 이동합니다. 도입 초기 추천 정확도는 70%대에서 출발했지만, 오답을 매일 수집해 재학습하는 데일리 피드백 루프를 돌리자 두세 달 만에 90%대 중후반까지 올라왔습니다. 지금은 이 루프 자체를 AI로 자동화하는 단계 — 오분류를 자동 수집하고, 의도를 파악해, 지식에 재매핑하는 — 로 진화시키는 중입니다. 다만 자동 학습도 결국 GPU 비용이라는 현실은 남습니다. 지식은 공짜로 최신·정확해지지 않습니다.

원칙 1: KMS는 채널보다 먼저 단일 원천으로 세웁니다. 홈페이지·어시스트·AI 학습용 데이터가 각자 별도 지식을 관리하면 채널마다 안내가 달라지고 그 불일치 자체가 민원을 만듭니다. 사업부가 KMS에 먼저 작성하고 각 채널은 필요한 계층만 분배받는 구조를 먼저 확립해야 어시스트 추천이 일관성을 가집니다.

원칙 2: 파싱 품질이 추천 품질의 상한선입니다. 임베딩 모델이나 청킹 전략을 아무리 정교하게 다듬어도, 파싱 단계에서 표 구조가 무너지거나 문단 경계가 뒤섞이면 그 뒤의 단계는 오염된 조각을 정확하게 저장하는 것에 불과합니다. 문서 파이프라인 설계에서 가장 먼저, 가장 많은 검증 시간을 투입해야 할 지점은 파싱입니다.

원칙 3: 지식의 최신성은 사람과 피드백 루프가 지킵니다. 실시간 등록과 데일리 배치가 갖춰져 있어도, 어시스트가 실패한 지점을 수집해 KMS로 되돌리는 루프를 사람이 운영해야 정확도가 올라갑니다. 이 루프가 없으면 지식 공백은 발견되지 않은 채 반복되고, AI가 자동으로 채워 주는 일은 일어나지 않습니다. 이 세 가지 원칙은 2026년 7월 시점에 공개 가능한 일반론과 익명화한 현장 경험만으로 정리한 것이며, 특정 회사·고객사의 정보나 계약 수치는 담지 않았습니다.

댓글

이 블로그의 인기 게시물

STT 인식률 93%의 함정 — 왜 그 숫자는 콜봇 목표가 될 수 없는가

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

음성 토큰(Audio Token)이란? LLM이 소리를 이해하는 원리