글

AI를 넣으면 사람이 준다는 착각 — KMS 전담 인력이 오히려 늘어나는 이유

AI를 도입하면 사람이 준다는 통념과 달리, KMS(지식관리시스템) 운영 현장에서는 정반대의 일이 자주 벌어집니다. AI 검색을 붙이고 나면 오히려 콘텐츠를 손보는 전담 인력이 새로 필요해지고, 그 인원이 도입 이전보다 늘어나는 경우도 드물지 않습니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-8편 (최종편) ← 이전: 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등 / 다음 → 시리즈 완결 11-6 AI 지식베이스와 System of Record 정합성 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등 11-8 AI 넣으면 사람이 준다는 착각 (현재 글 · 최종편) 전체 목차 펼치기 (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 동적 ...
댓글 쓰기
자세한 내용 보기

검색 실패율이 오르는 이유는 두 가지다 — 지식 공백 vs 이벤트성 급등

검색 실패율이 갑자기 오르면 무엇부터 봐야 할까요? 대시보드에 뜬 숫자 하나만 보고 "지식베이스에 구멍이 났다"고 단정하면, 절반은 맞고 절반은 틀린 진단이 됩니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-7편 ← 이전: 11-6 AI 지식베이스와 System of Record 정합성 / 다음 → 11-8 AI 넣으면 사람이 준다는 착각 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 11-6 AI 지식베이스와 System of Record 정합성 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등 (현재 글) 11-8 AI 넣으면 사람이 준다는 착각 전체 목차 펼치기 (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편) ...
댓글 쓰기
자세한 내용 보기

AI 지식베이스는 회사 시스템과 왜 자꾸 어긋나는가 — System of Record 정합성 문제

상담사가 화면에 뜬 안내를 그대로 읽었습니다. "네, 고객님. 해당 옵션으로 변경 가능합니다." 지식베이스 검색창에 옵션명을 치자 나온 문서에는 분명히 "가능"이라고 적혀 있었습니다. 그런데 실제 처리 화면으로 넘어가는 순간, 백엔드 시스템은 그 옵션을 막아 놓고 있었습니다. 상담사도, 고객도 잠시 어리둥절해졌고, 결국 "확인 후 다시 안내드리겠다"는 말로 통화를 마무리해야 했습니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-6편 ← 이전: 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 / 다음 → 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등 11-4 버전관리와 온톨로지의 역할 분담 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 11-6 AI 지식베이스와 System of Record 정합성 (현재 글) 11-7 검색 실패율 — 지식 공백 vs 이벤트성 급등 11-8 AI 넣으면 사람이 준다는 착각 전체 목차 펼치기 (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...
댓글 쓰기
자세한 내용 보기

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 실시간 인터럽트(끼어...
댓글 쓰기
자세한 내용 보기

최신본만 남기면 과거 이력 검색이 안 된다 — 버전관리와 온톨로지의 역할 분담

최신 정보만 정확하게 유지하면 충분하다고 생각하기 쉽지만, 실제 운영 현장에서는 정반대의 질문이 자주 나옵니다. "지난번엔 왜 안 됐던 거죠?", "그때 안내받은 조건이랑 지금이랑 다른데 어느 시점 기준이 맞나요?" 같은 질문입니다. 콘텐츠를 최신본 하나로만 정리해 두면 이런 과거 시점 기준 질의에는 답을 할 수가 없습니다. 최신본은 "지금"에 대한 답만 갖고 있을 뿐, "그때"에 대한 답은 이미 지워진 뒤이기 때문입니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-4편 ← 이전: 11-3 하이브리드·에이전트·그래프 3단 검색 구조 / 다음 → 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 11-2 비정형 이력 데이터 지식화의 함정 11-3 하이브리드·에이전트·그래프 3단 검색 구조 11-4 버전관리와 온톨로지의 역할 분담 (현재 글) 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 11-6 AI 지식베이스와 System of Record 정합성 전체 목차 펼치기 (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를 바꾸는 이유 P...
댓글 쓰기
자세한 내용 보기

하이브리드·에이전트·그래프, 3단 검색 구조는 왜 표준이 됐나

하이브리드 검색이란 키워드 매칭 기반 검색과 벡터 임베딩 기반 의미 검색을 하나의 파이프라인에서 함께 쓰는 검색 방식을 말합니다. 여기에 복합 질의를 여러 하위 질의로 쪼개 처리하는 에이전트 검색, 그리고 개체 간 관계를 다루는 온톨로지·그래프 기반 검색을 얹은 3단 구조가, 최근 KMS(지식관리시스템) 프로젝트에서 벤더를 가리지 않고 공통적으로 제안되는 표준 패턴으로 자리잡고 있습니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다. [시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-3편 ← 이전: 11-2 비정형 이력 데이터 지식화의 함정 / 다음 → 11-4 버전관리와 온톨로지의 역할 분담 11-1 KMS 프로젝트가 실사 이후로 밀리는 이유 11-2 비정형 이력 데이터 지식화의 함정 11-3 하이브리드·에이전트·그래프 3단 검색 구조 (현재 글) 11-4 버전관리와 온톨로지의 역할 분담 11-5 KMS vs LLM/RAG 벤더 선정에서 반복되는 갈등 전체 목차 펼치기 (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가 필요한 이...
댓글 쓰기
자세한 내용 보기