취소선 하나가 오답을 만든다 — 비정형 이력 데이터를 지식화할 때 생기는 문제

이력 관리 문서함을 열어보면 낯익은 장면과 마주치게 됩니다. 어떤 항목은 취소선이 그어져 있고, 바로 옆 항목은 글자만 옅은 회색으로 흐려져 있고, 또 다른 항목은 기울임체로만 표시돼 있습니다. 세 가지 표기 모두 담당자 나름대로는 "이제 유효하지 않다"는 뜻으로 넣은 것인데, 문서를 처음 접하는 사람은 어떤 규칙으로 읽어야 하는지 알 길이 없습니다. 작성자가 바뀔 때마다, 심지어 같은 작성자라도 시기가 다르면 표기 방식이 슬쩍 달라져 있곤 합니다. 이런 문서를 그대로 지식관리시스템(KMS)에 넣어 자동으로 지식화하면 어떤 일이 벌어질까요.

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

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

← 이전: 11-1 KMS 프로젝트가 실사 이후로 밀리는 이유 / 다음 → 11-3 하이브리드·에이전트·그래프 3단 검색 구조

전체 목차 펼치기 (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편)

취소선·회색글씨·기울임 — 표기가 제각각인 이유

현업 조직의 이력 문서에서 표기가 제각각인 데는 나름의 배경이 있습니다. 폐기·변경 항목을 표시할 공식 규칙이 애초에 없었던 경우가 대부분입니다. 취소선, 글자색, 기울임 중 손에 잡히는 대로 표시해 온 것이 몇 년간 누적되면서 같은 문서 안에서도 표기가 뒤섞입니다. 담당자가 바뀔 때마다 전임자의 습관을 그대로 이어받지 않는 경우도 많아, 시기별로 표기 스타일이 또 한 겹 달라집니다. 사람은 대충 맥락으로 걸러 읽지만, 이건 그 문서의 히스토리를 아는 사람에게만 통하는 암묵적 규칙일 뿐입니다.

자동 지식화 파이프라인이 만드는 오인식

문제는 이 암묵적 규칙이 자동 지식화 파이프라인 앞에서는 아무 의미가 없다는 점입니다. 텍스트를 추출해 임베딩하고 색인하는 과정에서, 취소선이 그어진 글자든 멀쩡한 본문이든 결국 같은 '텍스트'로 처리됩니다. 서식 정보가 유실되면 폐기된 내용과 유효한 내용이 구분 없이 같은 비중으로 지식베이스에 들어가고, 챗봇이나 검색 결과가 폐기된 조항을 정답처럼 인용하는 사고가 생깁니다. 더 곤란한 건 답변이 그럴듯한 문장으로 나오기 때문에, 실제 업무에 쓰기 전까지는 폐기된 정보가 섞여 있다는 걸 알아채기 어렵다는 점입니다.

해법 ① 표기 규칙 단일화 — "폐기는 취소선"으로 통일

실무에서 가장 먼저 적용하는 해법은 표기 규칙을 하나로 통일하는 것입니다. 예컨대 "폐기·변경 항목은 반드시 취소선으로만 표시한다"처럼 단일 규칙을 정하고, 회색 글씨나 기울임은 폐기 표시 용도로 더는 쓰지 않기로 합의합니다. 규칙이 하나로 좁혀지면 지식화 파이프라인 쪽에서도 "취소선 서식이 남은 구간은 제외하거나 별도 표시한다"는 단순한 처리 로직 하나만 넣으면 되어 대응이 훨씬 쉬워집니다. 여기서 한 걸음 더 나아가는 조직은 앞으로 신규 작성 문서에서는 취소선 자체를 지양하도록 권고합니다. 폐기 표시를 서식에 의존하는 관행 자체가 근본 원인이므로, 신규 문서부터는 서식이 아니라 구조로 그 문제를 풀자는 방향입니다.

해법 ② 변경이력은 버전관리로, 본문은 언제나 최신본만

구조로 푼다는 건 변경 이력과 현재 본문을 물리적으로 분리하는 것을 말합니다. 본문에는 언제나 지금 유효한 최신 내용만 남기고, 무엇이 언제 왜 바뀌었는지는 별도의 버전관리 이력에 기록합니다. 이력을 없애자는 게 아니라, 취소선으로 뒤섞여 있던 것을 본문은 최신 상태 하나만 보여주고 이력은 별도 화면에서 조회하도록 갈라놓는 것입니다. 이렇게 분리하면 지식화 파이프라인이 참조할 대상도 명확해집니다. 지식베이스에 넣을 원천은 항상 본문의 최신 버전 하나뿐이고, 이력은 지식화 대상에서 제외하면 됩니다.

원본-재사용 콘텐츠의 이중관리 문제

비정형 표기 문제를 정리하고 나면 옆에서 함께 발견되는 문제가 하나 더 있습니다. 같은 정보를 여러 문서에 복사해 붙여넣어 두는 원본-재사용 콘텐츠의 이중관리 문제입니다. 정책이 하나 바뀌면 그 내용을 담은 문서 여러 개를 전부 찾아 고쳐야 하는데, 실제로는 몇 개만 수정되고 나머지는 옛 내용 그대로 방치되는 사고가 반복됩니다. 문서마다 답이 다른 상황은 대체로 여기서 비롯됩니다. 해소하는 구조는 "최소 단위 원본 + 여러 상위 문서가 그 원본을 참조"하는 방식입니다. 공통 소제목이나 문단을 독립된 스니펫으로 만들어 두고, 이를 쓰는 문서들은 그 스니펫을 불러와 참조만 합니다. 원본 한 곳만 수정하면 참조하는 모든 문서에 자동 반영되므로, 일부만 고치고 나머지를 놓치는 사고가 구조적으로 발생하지 않습니다.

자주 묻는 질문

Q. 이미 쌓여 있는 이력 문서의 취소선 표기를 소급해서 전부 통일해야 하나요?
과거 문서 전체를 일괄 재작업하는 건 공수가 크기 때문에, 실무에서는 앞으로 작성할 신규 문서부터 새 규칙을 적용하고, 기존 문서는 지식화 대상으로 올릴 때만 우선순위를 두고 정리하는 방식을 더 많이 택합니다.

Q. 원본-스니펫 참조 구조를 도입하면 검색 결과가 파편화되지 않나요?
참조 구조는 원본 조각의 위치를 하나로 고정하는 것이지, 사용자에게 조각 단위로 노출하는 것과는 별개입니다. 상위 문서를 보여줄 때는 참조된 스니펫을 그대로 이어붙여 한 편의 완결된 글처럼 보여주고, 수정 관리만 원본 쪽에서 일원화합니다.

결국 두 문제 모두 밑바닥에는 같은 질문이 깔려 있습니다. 지금 보이는 내용 중 어디까지가 '현재 유효한 진실'인지를 시스템이 스스로 구분할 수 있느냐는 것입니다. 다음 편에서는 이렇게 정리된 지식을 실제로 어떻게 찾아내게 할지, 검색 구조 자체를 다뤄 보겠습니다.

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

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링