AI 지식베이스는 회사 시스템과 왜 자꾸 어긋나는가

상담사가 화면에 뜬 안내를 그대로 읽었습니다. "네, 고객님. 해당 옵션으로 변경 가능합니다." 지식베이스 검색창에 옵션명을 치자 나온 문서에는 분명히 "가능"이라고 적혀 있었습니다. 그런데 실제 처리 화면으로 넘어가는 순간, 백엔드 시스템은 그 옵션을 막아 놓고 있었습니다. 상담사도, 고객도 잠시 어리둥절해졌고, 결국 "확인 후 다시 안내드리겠다"는 말로 통화를 마무리해야 했습니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 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편)

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편)

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 넣으면 사람이 준다는 착각

지식과 실물이 어긋나는 순간

이런 어긋남은 드문 사고가 아니라 지식베이스를 운영하는 조직이라면 반복해서 마주치는 구조적 문제입니다. 원인은 단순합니다. 상품이나 서비스 정보는 대개 안내문서나 공지 형태로 먼저 만들어지고, 그것을 사람이 읽고 손으로 지식베이스에 입력합니다. 반면 실제로 무엇이 되고 무엇이 안 되는지를 최종적으로 결정하는 건 백엔드의 정합 데이터, 즉 실제 계정과 계약 조건을 들고 있는 시스템입니다. 이 둘은 같은 사실을 다루지만 서로 다른 경로로 만들어지기 때문에, 한쪽이 바뀌었는데 다른 쪽이 못 따라가는 순간이 생길 수밖에 없습니다. 안내문서 작성 시점과 시스템 반영 시점 사이에 시차가 생기거나, 사람이 옮겨 적는 과정에서 조건 하나를 놓치면 그대로 지식베이스에는 "가능"이 남게 됩니다. 문제는 이게 한 번의 실수로 끝나지 않고, 안내문서가 갱신될 때마다 같은 경로로 반복된다는 점입니다.

자동 연동이라는 해법, 그리고 벽

이 문제를 겪은 조직은 거의 예외 없이 같은 답에 도달합니다. "사람이 손으로 옮기니까 틀리는 거면, 시스템끼리 직접 연동하면 되지 않나." 맞는 방향입니다. 하지만 실제로 이 연동을 설계하는 단계에서 벽에 부딪힙니다. 지식베이스가 참조해야 할 진짜 데이터는 대개 계정계처럼 회사의 핵심 시스템에 있는데, 이런 시스템은 보안과 망분리 정책 때문에 외부, 심지어 사내의 다른 시스템에도 쉽게 문을 열어주지 않습니다. 인터페이스 하나를 새로 뚫으려면 보안 심사, 접근 통제, 장애 시 책임 소재까지 따져야 하고, 이 절차는 지식베이스 하나 정확하게 만들자는 목적치고는 무겁게 느껴지기 마련입니다. 그래서 많은 조직이 자동 연동을 검토만 하다가 보류하거나, 일부 항목만 제한적으로 연동하는 선에서 타협합니다.

보수적인 안전장치 — 최종 확인 후 게시

연동이 완전하지 않은 상태에서 조직이 택하는 현실적인 원칙은 "정합성 충돌이 감지되면 자동으로 반영하지 않는다"는 것입니다. 즉 시스템 쪽 정보와 지식베이스 쪽 정보가 다르게 나타나는 항목이 있으면, 그걸 곧바로 지식베이스에 밀어 넣어 고객 응대에 쓰이게 하는 대신 담당자의 눈을 한 번 거치게 합니다. 언뜻 느리고 비효율적으로 보이지만, 이 원칙에는 이유가 있습니다. 자동 반영은 틀린 정보가 퍼지는 속도도 함께 자동화한다는 뜻이기 때문입니다. 사람이 손으로 입력해서 틀리는 것과, 연동 로직의 결함으로 틀린 정보가 순식간에 전체 지식베이스에 퍼지는 것은 피해 규모가 다릅니다. 그래서 완전 자동화를 향해 가는 로드맵 위에서도, 충돌이 발생하는 구간만큼은 사람이 최종 게시 버튼을 누르게 남겨 두는 것이 안전장치로 작동합니다.

Push냐 Pull이냐 — 기술이 아니라 협상의 문제

연동을 어떻게든 진행하기로 했을 때 다음으로 부딪히는 질문은 방식입니다. 소스 시스템이 변경 사항을 API로 즉시 밀어주는 Push 방식과, 지식베이스 쪽이 주기적으로 데이터를 끌어오는 Pull(배치) 방식 중 무엇을 택할지입니다. 기술적으로만 보면 각각 장단점이 뚜렷합니다. Push는 반영이 빠른 대신 소스 시스템이 이벤트 발행 인터페이스를 새로 만들어야 하고, Pull은 소스 시스템을 건드리지 않아도 되는 대신 배치 주기만큼의 지연을 감수해야 합니다. 그런데 실무에서 이 선택은 기술 비교표로 끝나지 않습니다. 결국 "누가 인터페이스 개발 부담을 질 것인가"라는 조직 간 협상으로 귀결됩니다. 소스 시스템을 담당하는 쪽은 자신들의 일정과 리소스를 들여 Push용 인터페이스를 새로 만들어야 하고, 지식베이스 쪽이 Pull을 택하면 그 부담은 지식베이스 담당 쪽의 배치 개발과 운영으로 넘어옵니다. 어느 쪽이 더 우아한 아키텍처냐보다, 어느 쪽이 지금 그 개발 여력을 낼 수 있느냐가 실제 결정을 좌우하는 경우가 많습니다.

결국 남는 질문

정합성 문제는 기술로 완전히 없앨 수 있는 종류가 아닙니다. 지식이 만들어지는 경로와 시스템이 사실을 기록하는 경로가 애초에 다르게 설계되어 있는 한, 둘 사이의 간극은 어떤 형태로든 남습니다. 자동 연동은 그 간극을 줄이는 수단이지 없애는 수단은 아니고, Push와 Pull 중 무엇을 택하든 그 이면에는 항상 누군가의 개발 부담이 걸려 있습니다. 그래서 이 문제를 다루는 조직들이 결국 도달하는 지점은 비슷합니다. 간극을 완전히 메우려 하기보다, 간극이 생겼을 때 그것이 고객에게 그대로 전달되지 않도록 막는 마지막 확인 지점을 어디에 둘 것인가를 정하는 것입니다.

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

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링