KMS 전문 vs LLM/RAG 전문 — 벤더 선정에서 반복되는 구조적 갈등

---

이번 벤더 선정에서는 레거시 KMS 강자와 신생 LLM/RAG 플랫폼 업체를 같은 테이블에 동시에 앉히기로 했습니다. 한쪽은 고객센터 지식관리 시장에서 수년간 검증된 전통 KMS 업체, 다른 한쪽은 LLM과 RAG 기술을 앞세운 신생 플랫폼 업체입니다. 계보가 다른 두 진영을 나란히 경쟁시켜 학습하는 전략은 실무에서 자주 쓰이지만, 이번에도 예상대로 프로젝트 후반부에 갈등의 불씨가 됐습니다.

이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다.

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

← 이전: 11-4 버전관리와 온톨로지의 역할 분담 / 다음 → 11-6 AI 지식베이스와 System of Record 정합성

• 11-3 하이브리드·에이전트·그래프 3단 검색 구조
• 11-4 버전관리와 온톨로지의 역할 분담
• 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 (현재 글)
• 11-6 AI 지식베이스와 System of Record 정합성
• 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등

전체 목차 펼치기 (63편)

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

• 1-1 AI 보이스봇이 답답한 이유 — Cascaded 레이턴시
• 1-2 1초의 벽 — 지연이 UX를 결정하는 이유
• 1-3 지연 줄이기 — 스트리밍·청크로 TTFT 단축
• 1-4 RAG 병목과 오디오 버퍼링 제어

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

• 2-1 End-to-End S2S 작동 원리
• 2-2 OpenAI Realtime API vs 오픈소스 S2S
• 2-3 음성 토큰(Audio Token)이란
• 2-4 감정·톤 조절이 CS를 바꾸는 이유

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

• 3-1 실시간 인터럽트(끼어들기) 감지
• 3-2 실시간 음성에 MCP가 필요한 이유
• 3-3 스트리밍 중 MCP 초고속 데이터 룩업
• 3-4 통화 중 외부 API 도구 호출
• 3-5 실시간 세션 관리 — 통화 맥락·고객 데이터

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

• 4-1 동적 컨텍스트 윈도우 관리
• 4-2 WebRTC·WebSocket 초저지연 음성
• 4-3 비동기 이벤트 루프와 동시 콜 처리
• 4-4 트래픽 스파이크를 견디는 확장성 설계
• 4-5 실시간 음성 보안 — 암호화·PII 마스킹

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

• 5-1 에이전틱 워크플로우 — 응대를 넘어 완결로
• 5-2 상용화의 한계와 트러블슈팅
• 5-3 보이스 에이전트 평가(Eval) 설계
• 5-4 관측성(Observability) — 어디서 끊기나
• 5-5 가드레일과 환각 제어
• 5-6 상담사 전환(Handoff) 설계
• 5-7 프롬프트 A/B 테스트와 튜닝

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

• 6-1 한국어 음성 AI의 난관 — 존댓말·코드스위칭
• 6-2 턴테이킹과 시맨틱 VAD
• 6-3 보이스 페르소나 디자인
• 6-4 SIP·PSTN 전화망 연동
• 6-5 온디바이스·엣지 S2S와 프라이버시

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

• 7-1 음성 결제와 멀티모달의 한계
• 7-2 온프레미스 vs 클라우드 S2S 경제학
• 7-3 글로벌 보이스 에이전트 지형도
• 7-4 S2S 도입 검토자가 묻는 질문

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

• 8-1 LLM 콜봇 PoC — 검증의 갭
• 8-2 STT 정확도 93% 목표가 부족한 이유
• 8-3 금융 콜봇에서 소수점이 중요한 이유
• 8-4 TTFT 1.5초, 콜봇 스트리밍 파이프라인 설계
• 8-5 콜봇 SLM: 30B vs 70B 트레이드오프
• 8-6 PoC와 본사업 사이의 성능 괴리

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

• 9-1 상담어시스트란 무엇인가 — 실시간 STT가 상담사 화면을 바꾸는 구조
• 9-2 상담어시스트의 뼈대 — STT·인텐트·KMS 파이프라인
• 9-3 추천의 근거 — KMS·RAG 지식 그라운딩
• 9-4 통화 중 놓친 고지를 잡는 실시간 필수 안내 체크
• 9-5 AI가 상담 품질을 자동 채점하는 법 — AutoQA
• 9-6 신입 상담사에게 어시스트가 더 필요한 이유
• 9-7 온프레미스 상담어시스트 — GPU 제약과 모델 선택

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

• 10-1 왜 롤플레이 챗봇을 직접 만들었나
• 10-2 전체 아키텍처 한 장
• 10-3 RAG 파이프라인과 로컬 임베딩
• 10-4 멀티 LLM 백엔드 스위칭
• 10-5 AI 고객 페르소나 프롬프트 엔지니어링
• 10-6 퀴즈 풀 사전생성
• 10-7 대화가 끝나면 채점한다
• 10-8 혼자 쓰는 챗봇의 현실

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

• 11-1 KMS 프로젝트가 실사 이후로 밀리는 이유
• 11-2 비정형 이력 데이터 지식화의 함정
• 11-3 하이브리드·에이전트·그래프 3단 검색 구조
• 11-4 버전관리와 온톨로지의 역할 분담
• 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 (현재 글)
• 11-6 AI 지식베이스와 System of Record 정합성
• 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등
• 11-8 AI 넣으면 사람이 준다는 착각

왜 동시 경쟁 구도를 택했는가

KMS 전문 업체와 LLM/RAG 전문 업체를 동시에 붙이는 이유는 단순합니다. 한쪽만 불러서는 시장 전체 그림이 안 보이기 때문입니다. 레거시 KMS 업체는 권한 체계·버전 관리·검색 안정성 같은 기본기가 탄탄하지만 최신 생성형 AI 대응은 상대적으로 더딥니다. 반대로 신생 LLM/RAG 업체는 자연어 질의응답과 답변 생성은 강하지만, 엔터프라이즈 조직이 요구하는 문서 관리 체계나 운영 이력은 아직 얇습니다. 두 유형을 같은 요건서로 동시에 검토하면 이 격차가 명확히 드러나고, 고객 입장에서도 가격과 기능을 맞비교할 지렛대가 생깁니다. 여기에 더해 두 진영이 서로의 약점을 의식하면서 제안 내용을 더 촘촘하게 다듬어 오는 부수 효과도 있어서, 담당자 입장에서는 이 구도를 포기하기 어려운 학습 수단이 됩니다.

아키텍처 철학이 다르다 — 문서함이 먼저냐, AI 엔진이 먼저냐

문제는 두 유형이 애초에 다른 철학 위에서 설계됐다는 점입니다. KMS 전문 업체는 "문서함이 먼저"라는 전제로 움직입니다. 문서를 체계적으로 저장·분류·버전 관리하는 것이 핵심이고, 검색이나 AI 응답은 그 위에 얹는 부가 기능입니다. 반면 LLM/RAG 전문 업체는 "AI 엔진이 먼저"입니다. 임베딩과 검색 증강 생성이 중심이고, 문서 저장소는 AI 엔진이 참조하는 재료 창고에 가깝습니다. 같은 "KMS"라는 이름으로 불려도 무엇을 코어로 보느냐가 정반대라서, 견적 구조도 기능 우선순위도 처음부터 다르게 짜여 있습니다.

예산을 나누려는 순간 구조적으로 성립하지 않는 이유

이 차이가 실무에서 부딪히는 지점은 예산 분리 발주입니다. 고객이 "문서 관리는 A사, AI 검색은 B사"처럼 역할을 나눠 예산을 쪼개려는 시도가 흔히 나옵니다. 그런데 문서함이 먼저인 업체와 AI 엔진이 먼저인 업체는 서로의 코어 영역을 상대에게 넘기라는 요구를 받는 셈이 됩니다. KMS 업체 입장에서는 저장소를 남에게 내주고 부가 기능만 파는 구조가 되고, LLM/RAG 업체 입장에서는 자사 엔진의 핵심 자산인 데이터 파이프라인을 통째로 넘기는 구조가 됩니다. 어느 쪽도 이 조건으로는 정상적인 견적을 내기 어렵고, 결국 분리 발주 자체가 성립하지 않는 경우가 많습니다.

사전 설명 없이 넘어가면 후반부에 반드시 갈등이 터진다

이 불일치를 킥오프 단계에서 고객에게 명확히 설명하지 않으면, 문제는 항상 뒤로 미뤄질 뿐 사라지지 않습니다. 초반에는 "일단 두 업체 다 붙여서 비교해 보자"는 합의만 있고, 예산과 역할 분담에 대한 구체적 합의는 없는 채로 프로젝트가 진행됩니다. 그러다 계약 조건을 확정해야 하는 시점, 즉 견적서에 숫자를 채워 넣어야 하는 후반부에 가서야 이 아키텍처 불일치가 표면으로 올라옵니다. 이 시점의 갈등은 단순한 의견 차이가 아니라 일정 전체를 되돌리는 재협상으로 이어지기 쉽습니다. 그래서 두 유형을 동시에 경쟁시키기로 한 순간, 이 구조적 한계를 먼저 고객에게 짚어주는 것이 실무에서는 필수 단계로 취급됩니다.

중간 사업자의 포지션 리스크 — 소개했다가 밀려나는 구조

이원 경쟁 구도에는 또 하나의 갈등 축이 있습니다. SI사나 총판 역할의 중간 사업자가 전문 솔루션 업체를 고객에 소개하는 경우, 고객이 그 솔루션에 만족할수록 중간 사업자의 역할은 오히려 옅어지는 딜레마가 생깁니다. 고객과 솔루션 업체가 직접 소통하는 빈도가 늘어날수록, 중간 사업자는 처음 다리를 놓은 역할 이후로는 존재감이 흐려집니다. 이 구조는 특정 프로젝트 한 건의 문제가 아니라, 여러 건에서 공통으로 관찰되는 패턴입니다. 소개를 잘할수록, 그리고 소개한 솔루션이 실제로 고객 요구에 잘 맞을수록 이 딜레마는 오히려 더 빨리 드러납니다.

"가두리 관리"의 한계와 저가 수주 경계

이 리스크에 대한 실무 대응책으로 흔히 쓰이는 방법이 "가두리 관리"입니다. 고객과 솔루션 업체의 직접 접촉을 최소화하고, 모든 소통을 중간 사업자를 거치도록 통제하는 방식입니다. 다만 이건 근본 해법이라기보다 시간을 버는 임시방편에 가깝습니다. 고객이 솔루션에 만족하고 신뢰가 쌓일수록 직접 접촉 욕구는 결국 커지기 때문입니다. 여기에 더해 경계해야 할 패턴이 하나 더 있습니다. 핵심 기술인 LLM 엔진 등을 무상으로 얹어주면서 저가로 들어오는 영업 방식입니다. 당장의 수주율은 올라갈 수 있지만, 후속 사업 확장 여지와 시장에서의 신뢰도 측면에서는 오히려 리스크로 평가되는 경우가 많습니다.

자주 묻는 질문(FAQ)

Q1. KMS 전문 업체와 LLM/RAG 전문 업체를 반드시 동시에 붙여야 하나요?
필수는 아니지만 비교 검토 효과가 커서 실무에서 선호됩니다. 다만 동시 경쟁을 택한다면 아키텍처 철학이 다르다는 점과 예산 분리가 구조적으로 어렵다는 점을 초반에 고객에게 명확히 설명해야, 후반부 재협상 리스크를 줄일 수 있습니다.

Q2. 예산을 정말 나눌 방법이 전혀 없나요?
완전히 불가능하지는 않지만, 문서 저장소와 AI 엔진 중 어느 쪽을 코어로 볼지에 대한 합의가 먼저 있어야 합니다. 이 합의 없이 역할만 기계적으로 나누면 두 업체 모두 정상적인 견적을 내기 어려운 구조가 됩니다.

Q3. 중간 사업자의 포지션 리스크는 어떻게 관리하는 게 최선인가요?
"가두리 관리"는 단기 대응책일 뿐 근본 해법은 아닙니다. 장기적으로는 중간 사업자가 소개·연결 역할을 넘어 운영·통합·유지보수처럼 솔루션 업체가 대체하기 어려운 영역에서 별도의 가치를 만들어야 포지션이 유지됩니다.

다음 편에서는 벤더 선정 이후 실제 시스템을 도입하는 단계에서 반복적으로 드러나는 시스템 정합성 문제를 다루겠습니다.