AI 에이전트가 오래된 회사 지식을 믿지 않게 하려면: Source of Truth, 최신성, 충돌 해결 규칙

1. 개요: 오래된 진실은 무지보다 위험하다

많은 팀은 AI 에이전트가 없는 말을 지어낼까 봐 걱정합니다. 맞는 걱정입니다. 하지만 회사 운영에서는 더 조용한 실패가 생깁니다. 에이전트가 실제 문서를 찾고, 그 문서를 정확히 읽었는데, 문서 자체가 오래됐거나 폐기됐거나 초안이라서 틀린 답을 내는 경우입니다.

검색 도구는 회사 지식을 쓰기 쉽게 만듭니다. OpenAI file search, Microsoft Copilot Studio의 knowledge sources, Google grounding 같은 시스템은 모델을 문서와 데이터 소스에 연결할 수 있습니다. 하지만 세 문서가 서로 다를 때 어떤 문서가 최종 규칙인지까지 자동으로 결정해주지는 않습니다.

발행 업무를 예로 들면 바로 이해됩니다. 블로그 글이 로컬 저장소에는 있는데 라이브 사이트에는 예전 글 목록만 보인다면, 로컬 파일만으로는 발행이 끝난 것이 아닙니다. 독자에게 진짜 Source of Truth는 배포된 사이트, 라이브 URL, sitemap입니다. 회사 AI도 같은 규율이 필요합니다. 실제 운영 표면이 증명하기 전까지는 끝났다고 말하면 안 됩니다.

2. 쉬운 용어 정리: Source of Truth, 최신성, RAG, grounding, MCP

Source of Truth는 팀이 최종본으로 믿기로 한 장소입니다. 쉽게 말하면 다른 메모가 서로 다를 때 이기는 문서, 데이터베이스, 시스템입니다. 환불 정책 페이지가 회의록보다 우선일 수 있고, 서명된 계약서가 영업 메모보다 우선일 수 있으며, CRM 상태가 오래된 스프레드시트보다 우선일 수 있습니다.

최신성은 규칙이 아직 유효한지를 보는 신호입니다. 단순한 날짜가 아닙니다. 마지막 검토일, 담당자, 업데이트 트리거, 만료 규칙이 합쳐진 것입니다. 담당자가 어제 검토한 정책은 1년 동안 아무도 손대지 않은 위키 페이지보다 강한 근거입니다.

RAG는 retrieval-augmented generation의 줄임말입니다. AI가 답하기 전에 관련 회사 지식을 먼저 검색하는 방식입니다. Grounding은 답변이 검색된 출처에 묶여 있다는 뜻입니다. MCP, Model Context Protocol은 AI 도구가 외부 시스템에 연결되는 표준 플러그 같은 것입니다. 하지만 이런 기술이 출처 우선순위, 최신성 확인, 에스컬레이션 규칙을 대신하지는 못합니다.

• Source of Truth: 문서가 서로 다를 때 이기는 최종 규칙.
• 최신성: 규칙이 아직 유효하고 담당자가 있다는 신호.
• RAG: 답하기 전에 회사 지식을 검색하는 방식.
• Grounding: 답변을 검색된 근거에 연결하는 것.
• MCP: AI와 도구를 연결하는 표준이지, 연결된 데이터가 맞다는 보증은 아님.

3. 문서 수는 좋은 지표가 아니다

지식 베이스가 크면 성숙해 보일 수 있습니다. 하지만 오래된 제안서, 회의록, 온보딩 페이지, Slack 요약, Notion 페이지, PDF 내보내기 파일은 서로 비슷하지만 다른 규칙을 담고 있는 경우가 많습니다. AI가 이 모든 것을 검색할 수 있다고 해서 현재 답을 찾는 것은 아닙니다.

RAG의 원래 아이디어는 중요합니다. 외부 지식을 검색해 답변을 근거에 묶을 수 있기 때문입니다. 동시에 Lost in the Middle 연구는 유용한 경고를 줍니다. 컨텍스트를 더 많이 넣는다고 모델이 꼭 올바른 정보를 잘 쓰는 것은 아닙니다. 실제 운영에서는 더 작고 권위 있는 검색 단위를 설계해야 합니다.

Reddit과 AI 에이전트 빌더 커뮤니티에서도 반복해서 나오는 신호가 있습니다. 모델 품질만큼 context selection, provenance, trust가 중요하다는 점입니다. 이런 커뮤니티 글은 증명 자료가 아니라 현장 신호로만 다룹니다. 그래도 운영 결론은 분명합니다. 소유자가 분명한 최신 출처 몇 개가 거대한 과거 문서 더미보다 낫습니다.

4. 출처 우선순위: 에이전트가 읽기 전에 무엇이 이기는지 정하기

출처 우선순위는 도구를 연결하기 전에 적어야 합니다. 고객 응대라면 서명된 계약서, 현재 공개 정책, 내부 SOP, CRM 상태, 승인된 템플릿, 회의록 순서가 될 수 있습니다. 재무라면 회계 시스템, 청구서, 은행 기록, 스프레드시트 순서가 될 수 있습니다. 회사마다 순서는 다르지만, 순서 자체는 반드시 있어야 합니다.

이 규칙은 흔한 함정을 막아줍니다. 회의록에는 "환불 규칙을 바꾸는 것을 검토 중"이라고 쓰여 있고, 정책 페이지에는 "이 금액 이상은 승인 필요"라고 쓰여 있을 수 있습니다. 우선순위가 없으면 에이전트는 둘을 섞어 그럴싸하지만 공식이 아닌 답을 만들 수 있습니다.

• 업무별 출처 계층을 적는다.
• 초안과 회의록은 최종 규칙이 아니라 배경 자료로 표시한다.
• 고객에게 보이는 약속보다 계약서와 현재 정책을 우선한다.
• 에이전트가 사용한 출처 등급을 표시하게 한다.
• 상위 출처가 없으면 답변하지 말고 에스컬레이션한다.

5. 최신성: 담당자, 마지막 검토일, 만료 조건, 업데이트 트리거

최신성에는 네 가지 필드가 필요합니다. 담당자는 누가 규칙을 유지하는지 말합니다. 마지막 검토일은 사람이 언제 확인했는지 말합니다. 검토 주기는 얼마나 자주 봐야 하는지 말합니다. 업데이트 트리거는 가격 변경, 계약 변경, 정책 변경, 새 법적 요구사항, 반복된 리뷰어 수정처럼 어떤 일이 생기면 반드시 다시 봐야 하는지 말합니다.

많은 AI 지식 베이스가 여기서 조용히 낡아갑니다. 에이전트는 문서가 의미상 관련 있기 때문에 계속 가져옵니다. 하지만 관련 있다고 해서 지금도 맞는 것은 아닙니다. 잘 쓴 오래된 페이지는 공식처럼 보여서 빈 검색 결과보다 더 위험할 수 있습니다.

NIST AI RMF가 도움이 되는 이유도 여기에 있습니다. AI 위험을 한 번의 설정 문제가 아니라 조직과 생애주기 관리 문제로 보기 때문입니다. 작은 회사 버전으로 줄이면 간단합니다. 중요한 지식 자산마다 담당자와 검토 루프가 있어야 합니다.

6. 충돌 규칙: 에이전트는 추측하지 말고 멈춰야 한다

가장 가치 있는 행동이 답변 거절일 때가 있습니다. 에이전트가 관련성 높은 두 출처를 찾았는데 내용이 다르면, 둘을 보여주고 담당자에게 넘겨야 합니다. 입력 자체가 모순일 때 자신 있게 종합하는 것은 잘못된 행동입니다.

좋은 충돌 응답은 이렇게 말합니다. "서로 달라 보이는 규칙 두 개를 찾았습니다. 현재 정책 페이지는 A라고 말하고, 더 최근 회의 결정은 B라고 말합니다. 어느 쪽이 권위 있는지 판단할 수 없습니다. Source of Truth를 확인해주세요." 이 멈춤이 내부 혼란이 외부 피해로 바뀌는 것을 막습니다.

• 같은 주제의 출처가 서로 다른 규칙, 기준값, 날짜, 담당자를 말하는지 감지한다.
• 가장 높은 등급의 출처도 충분히 최신일 때만 우선한다.
• 최신성이나 권위가 불분명하면 근거를 표시하고 에스컬레이션한다.
• 해결된 충돌은 SOP와 eval 케이스로 바꾼다.

7. Guildex식 지식 준비 체크리스트

AI에게 회사 지식을 읽히기 전에 한 업무에 대한 작은 지식 통제표를 만드세요. 거대한 플랫폼이 없어도 됩니다. Notion, Google Sheets, GitHub, Obsidian의 표 하나로도 필드가 지켜진다면 충분히 시작할 수 있습니다.

이 체크리스트는 에이전트 결과를 검토하는 사람이 바로 볼 수 있어야 합니다. 리뷰어가 AI가 최신 규칙을 썼는지 오래된 메모를 썼는지 추측하게 만들면 안 됩니다.

• Workflow: 이 지식이 지원하는 업무.
• Allowed sources: 에이전트가 검색해도 되는 출처.
• Source priority: 출처가 다를 때 무엇이 이기는지.
• Owner: 각 규칙을 유지하는 사람.
• Freshness: 마지막 검토일, 검토 주기, 만료 트리거.
• Citation rule: 언제 출처를 보여줘야 하는지.
• Conflict rule: 언제 멈추고 사람에게 넘겨야 하는지.
• Eval cases: 출처 우선순위, 최신성, 충돌 처리를 테스트하는 예시.

8. 결론: 지식 접근은 저장소가 아니라 유지보수 시스템이다

AI 도입은 에이전트가 더 많이 읽는다고 안정해지지 않습니다. 어떤 출처가 이기는지, 어떤 규칙이 최신인지, 누가 소유하는지, 지식이 불명확할 때 에이전트가 무엇을 해야 하는지를 팀이 정할 때 안정해집니다.

지식 베이스를 저장 폴더가 아니라 유지보수 시스템으로 보세요. 하나의 업무에서 시작해 출처 계층, 최신성 규칙, 충돌 행동, 담당자, eval 케이스를 적으세요. 그 다음 에이전트가 읽게 하세요. 이 순서가 좋은 데모가 반복되는 비싼 실수로 바뀌는 것을 막습니다.