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 동적 컨텍스트 윈도우 관리
- 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편)
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편)
왜 전담 인력이 오히려 늘어나는가
AI 검색의 정확도는 결국 지식베이스 정비 수준을 넘어서지 못합니다. 모델이 아무리 좋아도 근거로 삼을 문서가 낡았거나 서로 충돌하면 답변도 그만큼 흔들립니다. 그래서 여러 프로젝트에서 공통적으로 나온 결론은 하나였습니다. AI 도입 이후에도 콘텐츠를 지속적으로 다듬는 전담 인력이 반드시 있어야 하고, 그 규모는 고객센터 규모에 비례해 수 명 단위로 배치된다는 점입니다.
이 결론은 "AI를 넣으면 사람이 준다"는 기대와 정면으로 부딪힙니다. 실제로는 초기 구간에서 관리 인력 투입이 오히려 늘어나는 경우가 많습니다. 이유는 단순합니다. AI는 스스로 지식을 새로 만들지 않습니다. 기존 문서를 검색하고 조합할 뿐이라서, 그 재료가 되는 지식베이스를 누군가 계속 갱신하고 정리하지 않으면 검색 품질은 시간이 지날수록 떨어집니다. 사람을 줄이는 도구가 아니라, 사람이 해야 할 일의 성격을 바꾸는 도구에 가깝다는 뜻입니다.
이 사실은 예산 계획을 세우는 단계에서도 자주 오해를 부릅니다. AI 도입을 상담 인력 축소의 근거로 삼았던 계획이라면, 정작 축소해야 할 대상은 상담 인력이 아니라 다른 반복 업무일 가능성이 큽니다. KMS 전담 인력은 도입 이후 새로 생기는 역할에 가깝고, 이 역할을 처음부터 예산과 조직도에 반영해 두지 않으면 도입 직후에 콘텐츠 품질이 급격히 떨어지는 상황을 맞기 쉽습니다.
비공식 채널의 유혹과 정식 등록 파이프라인
현장에서는 사내 메신저 단체방이나 게시판에 올라오는 "꿀팁"이 실제로 요긴한 경우가 많습니다. 문제는 이런 정보가 검증 절차를 거치지 않았다는 점입니다. 상담사 한 명의 경험담이 마치 공식 지침처럼 퍼지면, AI가 그걸 근거로 답변을 만들었을 때 책임 소재가 애매해집니다. 그래서 검증·승인된 지식만 AI 답변의 근거로 삼는다는 원칙이 리스크 관리의 기본값으로 자리잡고 있습니다.
다만 비공식 채널의 정보를 통째로 무시하는 것도 낭비입니다. 대안으로 제시되는 방식은 파이프라인화입니다. 비공식 채널에 올라온 유용한 정보를 발견하면 버튼 하나로 정식 등록을 요청하고, 관리자가 이를 검수·승인한 뒤에야 정식 지식으로 편입시키는 흐름입니다. 현장의 생생한 정보를 버리지 않으면서도, 검증되지 않은 내용이 그대로 AI 답변에 흘러 들어가는 경로는 차단하는 절충안입니다.
문단 단위 권한이라는 기술적 함정
권한 설계에서 자주 부딪히는 벽은 단위의 크기입니다. 문서 하나를 통째로 특정 직군에게 열어 주거나 막는 건 비교적 쉽습니다. 그런데 한 문서 안에서 특정 문단만 어떤 직군에게 보이지 않게 하려면 이야기가 달라집니다. 여러 조직에서 공통적으로 겪는 기술적 제약이라, 결국 소제목으로 문단을 분리하거나, 특수기호로 노출 규칙을 표시하거나, 별도 주석 처리로 우회하는 세 가지 방식 중 하나를 택해야 했습니다. 어느 쪽도 매끄럽지 않고, 문서를 만들 때부터 권한 구조를 염두에 두고 작성해야 한다는 부담이 남습니다.
권한 못지않게 반복적으로 논의된 주제가 담당 체계입니다. 특정 지식을 개인 한 명이 전담하는 방식은 그 사람이 퇴사하거나 휴가를 가는 순간 공백이 생깁니다. 그래서 여러 조직이 채택한 대안은 팀·업무 단위 책임제였습니다. 업무 단위로 담당 팀을 먼저 지정하고, 팀장이 그 안에서 개인별로 업무를 배분하며 최종 검수까지 맡는 구조입니다. 담당자가 자리를 비워도 팀 전체가 그 지식을 알고 있으니 공백이 곧바로 서비스 품질 저하로 이어지지 않습니다.
지식관리시스템엔 개인정보가 없어야 한다
개인정보 문제는 권한 설계보다 더 근본적인 원칙으로 다뤄집니다. 핵심은 "지식관리시스템 자체에는 개인정보가 애초에 없어야 한다"는 전제입니다. 권한으로 가리거나 마스킹으로 지우는 것도 필요하지만, 그보다 먼저 개인정보가 지식베이스 안으로 들어오지 않도록 막는 편이 훨씬 확실하다는 판단입니다.
이 원칙은 이중 방어선으로 구현됩니다. 첫 번째는 수집 단계의 전처리 탐지·마스킹입니다. 상담 이력이나 문서가 지식베이스로 들어오기 전에 개인정보로 의심되는 패턴을 걸러내고 가립니다. 두 번째는 AI가 답변을 생성하는 순간의 가드레일입니다. 설령 전처리를 뚫고 남은 개인정보가 있더라도, 답변 생성 단계에서 한 번 더 걸러내는 안전망을 둡니다. 한쪽 방어선이 뚫려도 다른 쪽이 잡아내도록 설계하는 것이 표준으로 자리잡고 있습니다.
UI 설계의 이상과 현장 워크플로우의 충돌
최신 솔루션일수록 팝업을 지양하고 하나의 화면 안에서 전환이 이뤄지는 설계를 지향합니다. 이론적으로는 맞는 방향입니다. 그런데 실제 상담 업무는 여러 시스템을 동시에 오가며 진행됩니다. 이런 패턴에서는 오히려 팝업으로 정보를 띄워 두고 원래 화면은 그대로 유지하는 쪽을 선호하는 경우가 있습니다. 설계자가 그리는 이상적인 화면과 현장의 실제 작업 방식이 어긋나는 지점입니다.
고령·시니어 사용자를 배려한 확대 기능에서도 비슷한 함정이 있습니다. 화면 전체를 확대하면 글자는 커지지만 레이아웃이 무너져 오히려 쓰기 어려워집니다. 실무에서 더 유효했던 방식은 화면 전체가 아니라 본문 콘텐츠만 개인별로 확대하는 것이었습니다. 위젯 기반 개인화 화면도 마찬가지 교훈을 남겼습니다. 사용자에게 완전히 자유로운 구성을 맡기면 오히려 사용률이 낮았고, 기본 세팅을 먼저 제공한 뒤 일부만 바꾸도록 유도했을 때 채택률이 더 높았습니다. 자유도가 높다고 늘 더 나은 설계는 아니라는 뜻입니다.
자주 묻는 질문
Q. AI 도입 초기에 KMS 전담 인력을 늘려야 한다면, 이건 일시적인 투자인가요 아니면 계속 유지해야 하는 비용인가요?
여러 프로젝트를 보면 초기 구간에서 늘어난 인력이 시간이 지나며 조금씩 줄어드는 경우는 있지만, 완전히 사라지는 경우는 드뭅니다. AI 검색의 품질이 지식베이스 정비 수준에 계속 종속되기 때문에, 콘텐츠를 다듬는 역할 자체는 상시로 남습니다. 다만 초반에는 오래된 문서 정비와 중복 정리처럼 밀린 작업이 몰려 있어 인력 부담이 크고, 이 몫을 어느 정도 소화한 뒤에는 신규 문서 반영과 검수 위주로 업무 강도가 낮아지는 흐름이 일반적입니다. 그러니 초기 투입은 일시적 프로젝트 비용이 아니라, 규모를 조정해 가며 계속 안고 가야 하는 운영 비용으로 보는 편이 현실에 가깝습니다.
여기까지가 KMS 실무를 다룬 Part 11에서 지금까지 정리한 내용입니다. 전담 인력의 필요성부터 비공식 채널 관리, 권한과 담당 체계, 개인정보 이중 방어선, UI 설계의 함정까지 짚어 봤습니다. KMS 운영은 한 번 세팅하고 끝나는 일이 아니라, 이런 크고 작은 판단이 계속 쌓이는 과정이라는 걸 다시 한번 느끼게 됩니다.
댓글
댓글 쓰기