사내 AI의 답변에는 유통기한이 있다: 지식 운영을 설계하는 법

사내 AI의 신뢰도를 높이려면 문서의 내용뿐 아니라 승인 상태, 적용일, 열람 권한, 관리 책임자를 함께 운영해야 합니다. 자료를 더 많이 연결하는 일과 지금 적용할 근거를 찾는 일은 다릅니다. 업무에 쓰는 AI는 어느 문서를 어떤 조건에서 답변의 근거로 삼았는지 설명할 수 있어야 합니다.

영업 담당자가 AI에게 묻습니다. “이 고객에게 적용할 할인 조건을 알려줘.” 답변은 빠르고 문장은 자연스럽습니다. 출처 링크도 달려 있습니다. 그런데 그 링크가 지난 분기에 폐기한 정책이라면 어떻게 될까요. 출처가 있다는 사실만으로 오늘의 업무에 맞는 답변이 되지는 않습니다.

이 글에서는 사내 검색과 AI 상담을 운영하는 팀이 문서의 생애주기를 어떻게 설계할지 다룹니다. 아래 정책 사례와 운영 도식은 LeanX의 가상 설계이며 실제 고객사 구축 성과가 아닙니다. 기술 원문에서 확인한 원칙과 우리 팀에 적용하기 위한 편집 제안을 구분했습니다.

1. 검색 정확도와 업무 유효성을 분리해서 봐야 한다

Anthropic의 Contextual Retrieval 글은 문서를 작은 조각으로 나눌 때 주변 맥락이 사라져 검색이 어려워질 수 있다고 설명합니다. 각 조각에 그 문서 안에서의 의미를 보충해 검색을 개선하는 접근을 소개합니다. 2024년 9월 발표한 설계 글이며, 이 글에서는 특정 성능 수치를 우리 회사의 기대 성과로 사용하지 않습니다.

이 문제는 사내 업무에서도 쉽게 떠올릴 수 있습니다. “20%까지 허용”이라는 문장만 검색하면 무엇의 20%인지 알 수 없습니다. 특정 제품의 할인인지, 특정 채널의 반품률인지, 한시적 프로모션인지가 함께 있어야 판단할 수 있습니다. 검색 시스템이 조각을 잘 찾았더라도 적용 대상과 조건이 빠지면 담당자는 다시 원문을 읽어야 합니다.

여기에 별도의 운영 문제가 더해집니다. 회사 이름과 정책 범위가 정확히 붙은 문서라도 효력이 끝났을 수 있습니다. 검색 관련성은 질문과 내용이 얼마나 맞는지를 다룹니다. 업무 유효성은 그 내용을 지금, 이 고객, 이 담당자에게 적용해도 되는지를 다룹니다. 두 항목을 따로 평가해야 검색 개선이 업무 품질 개선으로 이어졌는지 알 수 있습니다.

새로운 모델을 붙이기 전에 확인할 질문이 있습니다. 현재 문서 중 무엇이 승인본인지, 효력이 언제 시작되고 끝나는지, 예외는 누가 결정하는지 회사가 이미 알고 있나요. 사람이 답하기 어려운 이 질문을 AI만 정확히 풀도록 기대하면 운영 기준의 빈칸이 답변으로 드러납니다.

2. 문서에 책임과 적용 범위를 붙인다

LeanX는 처음부터 모든 사내 자료를 연결하기보다 반복 문의가 많은 업무 하나의 승인 문서부터 목록을 만들 것을 제안합니다. 할인 정책, 제품 사양, 교육 운영 안내처럼 답변의 근거가 비교적 분명한 범위를 골라 관리 규칙을 시험할 수 있습니다. 질문 수가 많더라도 책임자가 없는 문서라면 연결 범위를 넓히기 전에 확인할 일이 남아 있습니다.

문서별로 필요한 기록은 다음과 같습니다. 이 항목은 제품의 필수 기능 목록이 아니라 우리 조직이 정할 운영 계약입니다.

1. 원문 위치와 문서 식별자: 파일 이름을 바꿔도 같은 정책의 이력을 추적할 수 있게 합니다.
2. 승인 상태와 책임자: 초안인지 승인본인지, 내용 확인을 누구에게 요청할지 기록합니다.
3. 적용 범위와 효력 기간: 제품, 채널, 고객 유형, 시행일과 종료 조건을 표시합니다.
4. 열람 범위: 질문자가 확인할 수 있는 자료와 확인할 수 없는 자료를 구분합니다.
5. 최근 내용 검토일과 다음 검토 조건: 날짜 또는 가격 변경 같은 사건을 기준으로 정합니다.
6. 대체 관계: 어떤 새 문서가 이전 문서를 대신하는지 명시합니다.

여기서 수정일과 검토일을 구분해야 합니다. 오탈자를 고쳤다고 가격 조건을 재확인한 것은 아닙니다. 파일을 업로드한 날짜도 정책 시행일을 대신하지 않습니다. 담당자가 “이 내용이 여전히 맞다”고 확인한 기록을 따로 남겨야 기계적인 최신 파일 선택을 피할 수 있습니다.

검토 주기는 업무마다 달라야 합니다. 자주 바뀌는 가격표와 장기간 유지되는 제품 설명을 동일하게 취급하면 한쪽은 과도하게 관리하고 다른 쪽은 늦게 확인할 수 있습니다. 변경 빈도, 잘못된 답변의 영향, 관리 인력을 고려해 문서 소유자가 주기를 정하고 실제 수정 기록을 보며 조정합니다. 이 글은 업종 전체에 통하는 만료 기간을 제시하지 않습니다.

3. 접근 권한은 답변을 생성하기 전에 적용한다

Microsoft의 Azure AI Search 문서는 검색 단계에서 문서별 접근을 제한하는 여러 방식을 설명합니다. 색인에 보관된 권한 정보와 질문자의 신원을 연결하는 설계이며, 문서의 권한 정보를 동기화하는 조건도 중요합니다. 일부 방식은 미리보기 기능으로 표시돼 있으므로 실제 채택 시 지원 상태를 따로 확인해야 합니다.

보안 필터 설명은 문자열 비교 필터 자체가 인증을 수행하지 않는다는 점도 구분합니다. 따라서 로그인 확인, 신뢰할 수 있는 사용자 정보, 매 검색 요청의 권한 적용을 함께 설계해야 합니다. “문서에 그룹 이름을 저장했다”는 사실만으로 접근 통제가 완성됐다고 볼 수 없습니다.

사업 책임자가 알아야 할 핵심은 질문자가 읽을 수 없는 자료가 생성 입력에 들어가지 않게 하는 것입니다. AI에게 “민감한 내용은 말하지 마”라고 요청하는 것만으로 문서 접근 권한을 대신할 수 없습니다. 문서 본문뿐 아니라 제목, 요약, 인용 링크, 검색 결과 미리보기에도 같은 경계를 적용할 필요가 있습니다.

권한을 변경한 뒤에는 후속 경로까지 살펴야 합니다. 이전에 만들어 둔 요약, 응답 캐시, 검색 색인, 공유된 결과가 여전히 옛 권한을 기준으로 제공되고 있지 않은지 확인합니다. 권한 회수가 언제 각 경로에 반영됐는지 운영 기록에 남기면 변경 이후에도 내용이 노출되는 상황을 찾는 데 도움이 됩니다. 모든 시스템이 같은 방식으로 즉시 반영한다고 가정하지 않는 것이 좋습니다.

4. 답변 화면에 ‘적용 근거’를 보여준다

가상 예시를 보겠습니다. A회사의 판매 정책에는 같은 질문에 관련된 문서 세 개가 있습니다. 기존 할인 정책은 9월 말 효력이 끝났습니다. 새 정책은 10월부터 시행됩니다. 별도 고객 계약에는 일반 정책보다 우선하는 조건이 있으나 해당 고객 담당자만 읽을 수 있습니다.

이 경우 답변 시스템은 날짜가 가장 최근인 파일을 고르는 것만으로 판단을 끝낼 수 없습니다. 질문 대상이 어떤 고객인지, 어느 거래일 기준인지, 일반 정책과 계약의 관계를 누가 승인했는지 확인해야 합니다. 관계가 정리돼 있지 않다면 AI가 우선순위를 만들어 답하기보다 담당자에게 확인을 요청하도록 업무 규칙을 정할 수 있습니다.

실무자가 확인할 답변에는 적어도 네 가지를 표시할 것을 제안합니다. 적용하는 문서와 해당 구간, 정책 기준일, 적용 대상, 아직 확인하지 못한 조건입니다. “최신 정책에 따르면”이라는 문구보다 “10월 시행 승인본을 기준으로 일반 채널에 적용했으며, 개별 계약 조건은 확인이 필요하다”는 설명이 검토에 더 유용합니다.

기준일을 보여준다고 항상 정확해지는 것은 아닙니다. 실제로 그 기준일과 맞는 자료를 검색했는지, 인용 구간이 결론을 뒷받침하는지 확인해야 합니다. 자료가 없거나 서로 충돌하면 확인이 필요하다고 답할 수 있는 경로를 열어 둡니다. 이 보류는 무조건 줄일 오류가 아니라 팀이 정한 조건에서 올바른 결과일 수 있습니다.

5. 좋은 답변과 올바른 보류를 함께 평가한다

시험 질문을 만들 때 자주 묻는 쉬운 질문만 모으면 변경 상황을 놓치기 쉽습니다. 운영에서 실제로 판단이 갈리는 질문을 포함하고, 각 질문의 기준일과 질문자 역할, 기대 답변 또는 보류 이유를 사람이 먼저 정합니다. 이 기대 결과는 평가용 승인본이며 정책이 바뀌면 함께 검토해야 합니다.

평가 묶음에는 현재 승인본으로 답할 수 있는 질문, 폐기 문서와 새 문서가 동시에 검색되는 질문, 아직 시행하지 않은 정책을 묻는 질문, 권한이 없는 문서를 요구하는 질문, 문서 간 조건이 충돌하는 질문을 포함할 수 있습니다. 정상 사례와 예외 사례의 결과는 따로 봅니다. 전체 정답률 하나가 권한 실패나 폐기 문서 인용을 가리지 않게 해야 합니다.

운영 지표도 나눠 기록합니다. 검토한 답변 중 적용 근거가 맞는 비율, 폐기 문서를 근거로 사용한 사례 수, 권한 밖 자료가 노출된 사례 수, 보류 후 담당자가 해결한 시간, 문서 변경부터 검색 반영까지 걸린 시간입니다. 수치의 분모와 측정 기간을 함께 적고 테스트 결과와 실제 업무 결과를 구분합니다.

이 글은 모든 업무의 합격선을 하나로 정하지 않습니다. 조직이 노출 영향과 오류 영향을 고려해 승인 기준을 먼저 정하고 검증해야 합니다. 운영 중 관찰된 실패는 삭제하지 말고 어떤 문서와 조건에서 발생했는지 남깁니다. 단순한 “답변이 이상하다”보다 “효력 종료 문서가 후보에서 제외되지 않았다”는 기록이 다음 수정을 구체적으로 만듭니다.

6. 지식 운영의 책임자를 인수인계한다

첫 구축 담당자가 빠져도 문서를 유지할 수 있어야 합니다. 업무 담당자는 내용의 승인과 개정 관계를 관리합니다. 시스템 담당자는 색인, 권한 반영, 변경 실패와 회수를 확인합니다. 운영 책임자는 답변 보류를 누가 처리하고 어떤 상황에서 기능을 잠시 멈출지 정합니다. 한 사람이 여러 역할을 맡을 수 있어도 책임 항목은 분명해야 합니다.

인수인계 자료에는 현재 연결 문서 목록, 승인자, 변경 절차, 권한 테스트, 예외 처리 창구를 담습니다. 자동 반영이 실패하면 누가 알림을 받는지, 이전 버전으로 돌아가야 할 때 무엇을 복구할지, 문서 접근을 회수했을 때 파생 자료를 어떻게 처리할지도 기록합니다. 실제 담당자가 한 번 변경과 회수 절차를 수행해 보는 것이 문서 존재만 확인하는 것보다 유용합니다.

첫 실험은 크게 시작하지 않아도 됩니다. 업무 하나의 승인 자료를 정리하고 실제 질문과 예외 질문으로 시험합니다. 이후 정책 한 건을 바꾸고, 문서 한 건의 권한을 회수해 답변과 인용이 어떻게 바뀌는지 확인합니다. 무엇이 자동 반영되고 무엇은 사람이 조치해야 하는지 기록한 뒤 연결 범위를 넓힙니다.

LeanX는 AI 교육과 함께 업무에 필요한 자료, 승인 기준, 권한, 운영 책임을 정리하는 파일럿과 구축을 지원합니다. 현재 사내 AI가 가장 자주 참고하는 문서 하나를 가져오세요. 누가 승인하고 언제 바뀌며 어떤 질문에 적용하는지부터 범위를 정해볼 수 있습니다. 사내 지식 업무 적용 상담