사내 문서 AI 검색, 지식베이스 2,582건 중 90건만 들어갔습니다

실무지식 2,582건을 넣었습니다. 검색 근거 테이블에 실제로 들어간 건 90건이었습니다.

가져오기 스크립트는 끝까지 돌았습니다. 오류 메시지도 경고도 없었습니다.

넣은 문서의 3.5%만 AI가 볼 수 있는 상태였던 셈입니다. 나머지 2,492건은 흔적 없이 빠져 있었습니다.

2026년 8월, 보험대리점(GA) 지사가 쓰는 계약관리 시스템에 AI 비서를 붙였습니다.

설계사가 물으면 사내 실무지식과 약관을 찾아 근거와 함께 답하는 기능입니다.

근거 자료는 두 덩어리였습니다. 회사별 청구·전산 절차를 모은 실무지식 2,582건과 약관 11,236개 조항입니다.

그때 문서가 조용히 빠진 경위와 그 뒤 검색 품질을 다듬은 과정을 옮깁니다. 사내 매뉴얼을 AI에게 맡기려는 분은 맨 끝 점검표부터 보셔도 됩니다.

오류 없이 끝난 가져오기

실무지식은 원래 다른 곳에서 쌓이던 JSON 묶음이었습니다. 항목마다 주제, 본문, 회사, 태그 같은 필드가 붙어 있습니다.

이걸 시스템 DB로 옮기는 쿼리에 조건을 하나 걸었습니다. 회사 필드와 태그 필드가 배열인 항목만 받는다는 조건입니다.

검색 때 회사와 태그로 걸러야 하니 모양이 맞는 것만 받겠다는 생각이었습니다.

실제 데이터는 달랐습니다. 그 필드가 아예 없거나 배열이 아닌 모양으로 들어간 항목이 훨씬 많았습니다.

조건절은 그런 행을 오류로 내지 않습니다. 맞지 않는 행을 말없이 걸러 낼 뿐입니다.

같은 날 난 다른 오류

같은 작업 중에 오류가 하나 더 났습니다. 임시 테이블을 만들고 다음 줄에서 데이터를 넣는데 "relation does not exist"가 떴습니다.

커밋 시점에 지워지도록 만든 임시 테이블이 자동 커밋 때문에 만들자마자 사라진 탓이었습니다. BEGIN과 COMMIT으로 감싸자 바로 풀렸습니다.

이쪽은 화면에 오류가 떴으니 금방 끝났습니다. 90건 쪽은 아무것도 뜨지 않았습니다.

지식 검색에서 무서운 쪽은 두 번째입니다. 틀린 답은 읽는 사람이 알아채기도 하지만, 빠진 문서는 정상 응답처럼 보입니다.

2,582와 90

건수를 맞춰 보니 원본은 2,582건, 테이블은 90건이었습니다.

고친 방법은 조건을 걷어 내고 필드 모양을 그 자리에서 확인하는 쪽이었습니다.

배열이면 그대로 쓰고, 없거나 배열이 아니면 빈 배열로 바꿔 넣었습니다.

CASE WHEN jsonb_typeof(item->'tags') = 'array'
     THEN item->'tags' ELSE '[]'::jsonb END

다시 돌리자 2,582건이 전부 들어갔습니다.

엄격한 조건에도 장점은 있습니다. 모양이 깨진 데이터를 아예 받지 않으니 검색 코드가 단순해집니다.

사내 지식은 사람이 쌓은 기록이라 필드가 고르지 않습니다. 저는 사라지는 쪽을 더 큰 손해로 보고 두 번째를 골랐습니다.

"근거에 없다"가 정상일 때

AI 비서는 근거에 없는 질문에 지어내지 않도록 만들었습니다. 신약 하나를 물었을 때 실제로 그렇게 답했습니다.

근거에 없어 지어내지 않겠다고 밝힌 뒤 실무에서 확인할 방법을 안내했습니다.

정보가 최신이 아닐 수 있다는 면책도 붙였는데, 의도한 동작입니다.

문제는 이 응답이 90건 상태에서도 똑같이 나온다는 점입니다. 문서가 2,492건 빠져 있어도 AI는 정중하게 근거에 없다고 말합니다.

그러니 '모른다' 시험보다 건수 대조가 먼저입니다.

다 들어간 뒤의 노이즈

전량이 들어가자 반대 문제가 생겼습니다. AI 비서가 보험 뉴스로 점검 제안을 낼 때 관련 실무지식을 곁들이게 했는데, 엉뚱한 조각이 붙었습니다.

설계사 화면, 백엔드와 데이터, 보안과 개인정보, 제품 관점으로 나눈 전문가 4렌즈 리뷰에서 잡혔습니다. 'b.bb' 같은 의미 없는 조각과 URL 파편이 섞여 있었습니다.

관련성 기준을 넘는 항목만 붙이고, 지식 본문을 정리하는 함수를 세 경로에 같이 걸었습니다. 다시 화면을 보니 노이즈 조각은 사라졌습니다.

그 재검증에서 두 건이 더 나왔습니다. '건강' 같은 두 글자 키워드가 너무 많은 문서와 일치했고, 여러 제안에 같은 문서가 반복해 붙었습니다.

키워드는 세 글자 이상만 쓰게 했습니다. 한 번 실행하는 동안 이미 붙인 문서는 다시 붙이지 않습니다.

검색이 닿지 않는 문서

들어가 있어도 검색이 못 닿으면 결과는 같습니다. 같은 지식베이스를 쓰는 다른 검색 경로에서 그런 사례를 봤습니다.

카드 자동이체 절차를 담은 항목이 상위 3건 안에 잡히지 않았습니다. 질문 속 낱말은 '카드자동이체'인데 주제명은 '카드이체'였고, 태그에도 '카드'가 없었습니다.

저는 주제명 띄어쓰기와 태그를 한꺼번에 고쳤습니다. 1순위로 올라오자 띄어쓰기를 원인으로 적었습니다.

다시 재 보니 비교 전에 공백을 지우는 구조라 띄어쓰기는 상관이 없었습니다. 카드 태그를 빼자 9~10위로 내려갔고, 효과를 낸 건 태그였습니다.

두 가지를 같이 바꾸면 무엇이 효과를 냈는지 알 수 없습니다. 원인을 짚으려면 한 번에 하나만 바꾸세요.

검색 쪽에서도 비슷한 실수를 했습니다. 검색어 하나로만 찾아보고 관련 항목이 없다고 잘못 보고했습니다.

없다고 결론 내리기 전에는 붙여쓰기, 약칭, 동의어를 같이 훑으세요. 한 검색어로 0건이면 그 검색어로 0건이라고만 적으세요.

갱신 주기와 메뉴

원본 지식베이스는 밤사이 갱신됩니다. 시스템은 자기 사본을 따로 두고 바뀐 부분만 증분으로 받습니다.

동기화는 매일 09:45에 자동으로 돕니다. 여러 번 돌아도 결과가 같게 만들어서, 사람이 기억해서 올리는 단계를 없앴습니다.

지식 검색 경로에서 모델로 가는 건 실무지식, 약관, 뉴스뿐입니다. 고객 쪽은 이름과 연락처 없이 계약 구조만 가는데, 그 설계는 개인정보 유출 없이 AI 쓰기에서 다룹니다.

실무지식 검색을 별도 메뉴로 두지 않은 것도 이때 정했습니다.

처음엔 검색 화면이 따로 있었는데, 메뉴에서 빼고 AI 비서 대화 안으로 접었습니다.

설계사 입장에서는 어디서 찾을지 고민할 필요가 없어집니다. 물으면 대화가 지식을 찾아오고, 답 아래에 근거가 붙습니다.

우리 팀 문서에 붙인다면

근거를 보여 주는 화면이 어떤 모양인지는 보험 실무 질문 답변 데모에 있습니다. 답 아래 근거 문서가 몇 건 붙는지 세어 보세요.

회사별 실무 절차와 약관 조항을 근거로 붙여 답합니다.

데모에는 답변 속 전화번호와 URL을 코퍼스 전체와 대조하는 인용 가드도 들어 있습니다.

한 시연 예시는 초안에 섞인 번호가 어디에도 없어서 가드가 걸러 내는 장면입니다. 데이터는 모두 시연용 더미입니다.

사내 매뉴얼이 엑셀, 메신저, 공유 폴더에 흩어져 있다면 한곳에 모으는 일이 먼저입니다. 팀이 직접 노트를 쌓는 방법은 AI 지식관리 강의에서 다룹니다.

이미 쌓인 문서를 업무 시스템의 AI 검색으로 붙이고 싶다면 AI 자동화 상담에서 문서 양과 갱신 방식부터 같이 보면 됩니다.

문서가 수백 건 수준이고 거의 바뀌지 않는다면 시스템 없이 정리된 문서 묶음만으로 충분한 경우도 있습니다.

도입 전 점검표

• 넣은 문서 수와 검색 테이블 행 수를 나란히 세어 보세요. 가져오기가 오류 없이 끝나도 2,582건 중 90건만 들어갈 수 있습니다.
• 근거에 없는 질문 3개를 일부러 던져 보세요. 지어내지 않고 근거에 없다고 답하는지, 확인할 경로를 안내하는지 봅니다.
• 두 글자 키워드로 물어보세요. '건강' 같은 짧은 낱말에 엉뚱한 문서가 줄줄이 붙으면 매칭 기준을 손봐야 합니다.
• 답 옆에 근거 문서 제목이 보이는지 확인하세요. 근거가 보여야 담당자가 틀린 답을 바로 집어냅니다.
• 갱신 주기와 담당자를 정하세요. 자동 동기화 시각과, 그게 실패했을 때 누가 보는지까지 적어 둡니다.
• 개인정보가 든 문서는 처음부터 넣지 마세요. 고객 이름과 연락처가 섞인 상담 기록은 지식베이스와 따로 둡니다.