RAG가 맞게 찾았어도, 오래된 지식이면 실패다
논문 『ContextNest: Verifiable Context Governance for Autonomous AI Agent』를 읽고
에이전트가 검색한 지식의 출처, 버전, 승인 상태, 재현 가능성을 관리해야 한다는 ContextNest 논문을 읽었다.
제일 먼저 든 생각
RAG 시스템을 만들 때 우리는 보통 “잘 찾는가”를 먼저 묻는다. 검색 점수, chunking, embedding, reranker, 답변 품질 같은 것들이다. 그런데 에이전트가 실제 업무를 대신하기 시작하면 더 불편한 질문이 생긴다. 그 문서는 최신인가? 누가 승인했는가? 답변에 들어간 지식 버전을 나중에 다시 재현할 수 있는가?
ContextNest 논문은 이 문제를 검색 품질이 아니라 맥락 거버넌스(context governance)의 문제로 부른다. RAG를 대체하자는 주장이 아니다. 검색이 작동하기 전에, 어떤 지식이 AI가 소비해도 되는 승인된 현재 버전인지, 출처와 무결성이 확인되는지, 사용 흔적을 남길 수 있는지를 정하는 하부 계층이 필요하다는 제안이다.

이 논문은 검색 성능보다 먼저 “검색해도 되는 지식의 상태”를 묻는다.
검색은 맞았지만 판단은 틀릴 수 있다
논문 첫머리의 예시는 실무적으로 익숙하다. 구매 에이전트가 조직의 위험 기준 정책을 검색해 공급업체를 승인했는데, 나중에 감사 과정에서 그 정책이 이미 18개월 전에 바뀐 예전 버전이었다는 사실이 드러난다. 검색은 텍스트상으로 관련 문서를 찾았다. 하지만 시스템은 그 문서가 현재 승인된 버전인지, 당시 AI 사용 대상이었는지, 실제 답변에 어떤 버전이 들어갔는지 말하지 못한다.
“ContextNest는 검색증강생성(RAG)을 대체하지 않는다. 검색 아래에서 어떤 산출물이 승인되었고, 현재 유효하며, 출처가 있고, 무결성이 확인되었는지를 정하는 거버넌스 계층이다.”
“ContextNest is not a replacement for Retrieval-Augmented Generation (RAG); it is a governance layer beneath retrieval.”
이 구분이 중요하다. RAG 실패를 모두 더 좋은 embedding이나 더 긴 context로 해결하려고 하면, “관련 있지만 쓰면 안 되는 문서” 문제를 놓친다. 업무 에이전트는 관련성(relevance)만으로 움직이면 안 된다. 승인 상태, 버전, 출처, 해시, 사용 시점이 함께 붙어야 한다.
에이전트가 본 지식을 나중에 다시 꺼낼 수 있어야 한다
논문이 제안하는 사양은 typed Markdown, 구조화된 메타데이터, 결정적 selector, contextnest:// URI, SHA-256 해시 체인 버전 이력, 그래프 checkpoint, MCP(Model Context Protocol)를 통한 live data source, agent context consumption audit trace 등을 묶는다. 말은 기술적이지만 핵심은 단순하다. 에이전트가 어떤 문서를 보고 행동했는지, 그 문서가 그때 승인된 지식이었는지, 나중에 같은 맥락을 재구성할 수 있어야 한다는 것이다.
논문은 stale-version attack 실험에서 governed selection이 BM25보다 높은 답변 품질 통과율을 보였고, 입력 토큰 비용은 약 3분의 1 수준이었다고 보고한다. 또 1,060개 문서 corpus에서 결정적 selector와 BM25는 반복 질의에서 안정적 문서 집합을 반환했지만, dense+HNSW baseline은 상당수 질의에서 비결정성을 보였다고 설명한다. 이 결과는 모든 환경에서 ContextNest가 우월하다는 뜻이라기보다, 검색 품질과 거버넌스 품질이 서로 다른 실패 모드를 다룬다는 점을 보여준다.
“이 메커니즘들은 조직이 어떤 지식 버전이 에이전트 출력에 영향을 주었는지, 그리고 그 버전이 소비 시점에 AI 사용 가능 상태였는지를 재구성할 수 있게 한다.”
“These mechanisms let organizations reconstruct which knowledge versions informed an agent output and whether those versions were AI-eligible when consumed.”

원문 첫 페이지. ContextNest는 RAG의 검색 계층 위아래가 아니라, 검색이 참조할 지식 저장소의 승인·버전·감사 구조를 다룬다.
내 일에 붙여본다면
Deciflow 실무 와일드카드로 보면, 이 논문은 사내 에이전트/RAG 구축 체크리스트로 바로 내려온다.
- 문서마다
현재 사용 가능,보관,폐기,검토 필요같은 AI 사용 상태가 있는가? - 정책·절차·FAQ 문서는 버전과 승인자를 기록하고 있는가?
- 에이전트 답변 로그에 “어떤 문서의 어떤 버전”이 들어갔는가?
- 검색 index를 재생성해도 같은 시점의 맥락을 재현할 수 있는가?
- live data를 MCP나 API로 붙일 때, 출처와 시점이 audit trace에 남는가?
작게 시작한다면 벡터DB를 바꾸기 전에 문서 frontmatter부터 바꾸는 게 낫다. owner, approved_at, expires_at, ai_eligible, version, source_url, hash 같은 필드를 정하고, 에이전트가 검색하기 전 이 조건을 통과한 문서만 보게 하는 것이다. “잘 찾는 RAG”보다 “찾아도 되는 문서만 찾는 RAG”가 먼저일 때가 있다.
조심해서 읽을 점
논문은 사양과 reference implementation, 통제 실험을 함께 제시하지만, 모든 조직 지식관리 문제를 이 구조 하나로 해결한다는 뜻은 아니다. 거버넌스 필드가 많아질수록 운영 부담도 늘고, 잘못 관리된 메타데이터는 오히려 가짜 안정감을 줄 수 있다. 실무 적용에서는 고위험 지식부터 좁게 시작해야 한다.
그래도 남는 질문은 선명하다. 에이전트가 정확하게 검색했는가보다 먼저, 검색한 지식이 그 시점에 사용 가능한 지식이었는가를 물어야 한다. RAG의 다음 과제는 더 많은 문서를 넣는 일이 아니라, 에이전트가 먹어도 되는 지식을 관리하는 일이다.
원문 정보
- 제목: ContextNest: Verifiable Context Governance for Autonomous AI Agent
- 저자: Misha Sulpovar, Benn R. Konsynski, Qaish Kanchwala, Gabe Goodhart
- 연도/게시일: 2026
- 게재/출처: arXiv
- arXiv: 2607.02116v1
- PDF: https://arxiv.org/pdf/2607.02116