무상태 RAG의 함정: 질의 시점 AI 아키텍처의 한계

By Mirko Peters · 2026-08-13

블로그에 다시 오신 것을 환영합니다! 엔터프라이즈 인공지능을 주제로 한 팟캐스트를 꾸준히 들어 주셨다면, 저희가 최신 생산성 도구의 초기 화제성 너머를 살펴보는 데 많은 시간을 들인다는 것을 아실 겁니다.

Automatically translated with AI from the original post. Read the English original

블로그에 다시 오신 것을 환영합니다! 엔터프라이즈 인공지능을 주제로 한 팟캐스트를 꾸준히 들어 주셨다면, 저희가 최신 생산성 도구의 초기 화제성 너머를 살펴보는 데 많은 시간을 들인다는 것을 아실 겁니다. 일반적인 데모에서는 Microsoft Copilot 같은 도구가 놀라울 만큼 똑똑해 보일 수 있습니다. 프로젝트 문서를 찾고, 정책을 요약하고, SharePoint에서 정보를 추출하고, 엔터프라이즈 콘텐츠를 연결해 그럴듯한 답변을 만들어 냅니다. 하지만 이 인상적인 사용자 경험 뒤에는 근본적인 아키텍처상의 한계가 숨어 있습니다. 바로 검색은 기억이 아니라는 점입니다. Copilot은 조직 전체를 검색할 수 있지만, 그렇다고 조직에 대한 지속적인 이해를 쌓아 두었다는 뜻은 아닙니다. 이 글에서는 RAG(Retrieval-Augmented Generation)의 작동 원리를 자세히 살펴보고, 청킹(chunking)과 무상태 질의 루프가 엔터프라이즈 상호작용 전반에서 누적된 컨텍스트를 AI가 유지하지 못하게 만드는 이유를 알아보겠습니다. 이 개념을 오디오로 더 깊이 다룬 관련 팟캐스트 에피소드 Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It도 꼭 확인해 보시기 바랍니다.

Copilot은 기억하지 않고, 검색합니다

Copilot을 사용하는 경험에는 중요한 착각이 하나 생깁니다. Microsoft 365의 정보를 성공적으로 연결하면 시스템이 조직에 대해 무언가를 학습한 것처럼 보일 수 있습니다. 하지만 나중에 비슷한 질문을 하면, 시스템은 이전에 형성한 이해를 떠올리는 것이 아니라 새로운 검색을 다시 수행하기 때문에 다른 결과를 낼 수도 있습니다. 조직이 기본적인 요약 단계를 넘어 AI가 실제 의사결정을 지원하기를 기대하기 시작하면, 이 차이가 결정적으로 중요해집니다.

본질적으로 동일한 질문이라도 어떤 정보가 검색되었는지에 따라 일관성 없는 답변이 나온다면, 사용자는 업무상 중요한 작업에 AI를 의존하기를 금세 꺼리게 됩니다. 그 결과는 단순한 기술적 문제가 아니라 도입 문제가 될 수 있습니다. 사용자는 예측 가능성을 원하며, 같은 프롬프트에 대해 어시스턴트가 월요일에는 한 답을, 목요일에는 모순된 답을 내놓으면 신뢰는 빠르게 무너지기 시작합니다.

검색 증강 생성(RAG)이 실제로 하는 일

RAG는 Retrieval-Augmented Generation의 약자입니다. 단순화해서 말하면, 엔터프라이즈 문서를 청크로 나누고, 그 청크를 임베딩으로 표현하며, 사용자의 질문도 같은 방식으로 변환한 뒤, 의미적으로 관련된 청크를 검색합니다. 그중 순위가 가장 높은 정보가 응답을 생성하기 위한 컨텍스트로 언어 모델에 전달됩니다.

이 아키텍처는 매우 유용합니다. 대규모 언어 모델이 원래 학습 데이터에 포함되지 않았던 정보를 활용해 질문에 답할 수 있게 해 주고, AI 응답을 엔터프라이즈 콘텐츠에 근거하게 만드는 실용적인 방법을 제공합니다. 하지만 동시에 중요한 아키텍처상의 제약도 만들어 냅니다. 모델은 현재 질의에 맞춰 선택된 조각들을 받을 뿐, 조직의 지식을 완전하고 지속적으로 담은 표현을 유지하지는 않습니다.

청킹 문제

엔터프라이즈 지식은 대개 독립된 문단으로만 존재하지 않습니다. 프로젝트 계획에는 수십 페이지에 걸쳐 흩어진 종속성이 들어 있을 수 있습니다. 정책이 다른 정책을 참조하기도 하고, 기술 아키텍처는 몇 달 전 모임 메모, Teams 대화, SharePoint 페이지, 설계 문서에 기록된 결정에 의존할 수도 있습니다.

기존 RAG는 이러한 소스를 더 작은 단위로 나눈 뒤, 현재 질문과 관련 있어 보이는 조각을 골라냅니다. 따라서 모델은 문서 전체와 그 안의 모든 관계를 반드시 이해하는 것이 아니라, 선택된 조각만 보게 됩니다. 단순한 정보 검색에는 이 방식이 매우 잘 작동할 수 있습니다. 하지만 관계, 과거 맥락, 종속성, 누적된 결정, 여러 소스에 걸친 추론이 필요한 질문에서는 이러한 한계가 훨씬 뚜렷하게 드러납니다.

무상태 RAG의 함정

기존의 검색 증강 워크플로에는 무언가가 이미 파악되었다는 개념이 본질적으로 없습니다. 질문이 들어오면 정보를 검색하고, 답변을 생성한 뒤, 다음 검색 작업을 위해 프로세스가 사실상 처음부터 다시 시작됩니다. 바로 이 지점에서 RAG의 무상태성(statelessness)이 큰 걸림돌이 됩니다.

한 번의 상호 작용에서 발견된 지식이 모든 향후 상호 작용에서 사용할 수 있는 지속적인 조직 지식이 되는 것은 아닙니다. 엔터프라이즈 AI에서 이 차이는 매우 큽니다. 조직에 필요한 것은 단순히 더 나은 검색이 아닙니다. 프로젝트, 프로세스, 정책, 기술, 사람, 의사 결정, 종속성, 그리고 이들을 잇는 관계에 대한 구조화된 이해를 유지할 수 있는 시스템이 점점 더 필요해지고 있습니다.

지식 검색 대 지식 컴파일

이는 최근 오디오 시리즈에서 다룬 핵심 아키텍처 아이디어로 이어집니다. 질의 시점마다 조직 지식을 반복해서 재구성하는 대신, AI가 미리 그 지식을 컴파일해 두면 어떨까요? LLM Wiki는 이러한 사고의 전환을 보여 줍니다.

모든 엔터프라이즈 문서를 검색되기를 기다리는 조각들의 모음으로 취급하는 대신, 인공지능은 정보를 종합하여 조직이 현재 이해하고 있는 내용을 표현하는 구조화된 지식 아티팩트로 만들 수 있습니다. 중요한 변화는 단순히 또 하나의 사용자 인터페이스가 아닙니다. 지능을 질의 시점의 재구성에서 지속적인 지식 종합으로 옮기는 것입니다.

LLM Wiki가 모델을 바꾸는 이유

같은 제품, 고객, 프로젝트, 정책 또는 아키텍처를 설명하는 수천 개의 문서를 떠올려 보십시오. 기존 RAG는 질문이 들어올 때까지 기다렸다가 답변에 가장 적합할 가능성이 높은 조각들을 찾습니다. 반면 LLM Wiki 접근 방식은 이렇게 흩어진 원본을 일관된 지식 페이지로 지속적으로 변환하려고 합니다.

관계, 의사 결정, 정의, 종속성, 과거 맥락, 그리고 근거가 되는 출처가 유지 관리되는 지식 표현의 일부가 될 수 있습니다. 그러면 Copilot이나 다른 AI 에이전트는 원시 문서에서 매번 이해를 재구성하려고 하는 대신, 종합된 조직 이해를 담은 계층에서 정보를 검색할 수 있습니다.

문서 저장소에서 지식 계층으로

이는 SharePoint와 같은 시스템의 역할을 바꿉니다. SharePoint는 문서, 페이지, 정책, 프레젠테이션, 회의 결과물, 협업 콘텐츠를 위한 신뢰할 수 있는 저장소 역할을 계속할 수 있습니다. 하지만 원시 엔터프라이즈 콘텐츠가 자동으로 유용한 조직 지식이 되는 것은 아닙니다.

AI가 생성한 지식 계층은 이러한 원본 시스템 위에 놓여, 흩어진 정보를 조직의 지도에 더 가까운 형태로 바꿀 수 있습니다. 프로젝트와 의사 결정이 연결되고, 정책과 프로세스가 연결되며, 시스템과 소유자가 연결되고, 개념과 그 뒷받침 근거가 연결됩니다. 목표는 원본 문서를 없애는 것이 아닙니다. 문서 안에 숨어 있는 관계를 명시적으로 드러내는 것입니다.

더 나은 프롬프트로 아키텍처 문제를 해결할 수 없는 이유

프롬프트 엔지니어링은 LLM이 검색된 컨텍스트를 해석하는 방식을 개선할 수 있지만, 애초에 올바른 컨텍스트가 검색되었다는 것은 보장하지 못합니다. 검색 계층이 불완전한 조각을 반환하거나, 중요한 종속성을 놓치거나, 오래된 문서를 가져온다면, 아무리 뛰어난 모델이라도 불완전한 정보 집합을 바탕으로 추론하게 됩니다.

그래서 모델만 개선해서는 모든 엔터프라이즈 AI 문제를 해결할 수 없습니다. 모델에 제공되는 지식의 품질과 구조가 여전히 근본적으로 중요합니다. 일시적인 검색 결과에 의존하고 구조화된 지속형 메모리가 없는 기반 아키텍처는 아무리 정교한 프롬프트 기법으로도 고칠 수 없습니다.

거버넌스 문제는 더 커집니다

이 아키텍처에는 중요한 경고도 따릅니다. 조직의 SharePoint 환경에 오래된 정책, 중복된 문서, 폐기된 프로세스, 상충하는 지침, 명확한 소유자가 없는 문서가 있다면, LLM Wiki는 좋은 정보를 종합할 때와 마찬가지로 효율적으로 잘못된 정보도 종합할 수 있습니다.

위험은 종합된 지식이 기반 콘텐츠가 받을 만한 수준보다 훨씬 깔끔하고 권위 있어 보일 수 있다는 점입니다. 따라서 AI는 기존의 정보 거버넌스를 덜 중요하게 만드는 것이 아니라 더 중요하게 만듭니다. 콘텐츠 소유권, 수명 주기 관리, 버전 관리, 보존, 보관 프로세스, 신뢰할 수 있는 원본, 메타데이터, 명확하게 정의된 기록 시스템은 AI 아키텍처의 기반 구성 요소가 됩니다.

AI 준비는 콘텐츠 품질에서 시작됩니다

많은 조직이 Copilot 준비를 라이선스, 보안, 배포, 교육 프로젝트로 접근합니다. 이러한 요소도 중요하지만, 그 바탕이 되는 지식 환경도 그에 못지않게 중요합니다. 현재 프로세스를 대표하는 문서가 무엇인지 아무도 모른다면, AI가 조직 내의 모호함을 마법처럼 해결해 줄 수는 없습니다.

세 개 부서가 같은 정책의 서로 모순되는 버전을 관리하고 있다면, AI는 세 가지 진실을 물려받은 셈입니다. 오래된 문서가 무기한으로 검색 가능한 상태로 남아 있다면, 그것은 여전히 잠재적인 근거 자료로 활용됩니다. 따라서 엔터프라이즈 AI는 조직이 그동안 외면할 수 있었던 지식 관리의 부채를 드러냅니다.

신뢰가 Copilot 도입을 좌우하는 이유

기술적 문제는 금세 업무상의 문제가 됩니다. 사용자는 이메일 초안을 작성하거나 모임 내용을 요약할 때 AI가 가끔 일관성이 없어도 어느 정도 참아 줄 수 있습니다. 그러나 AI에게 정책을 설명하고, 고객의 결정을 지원하고, 프로젝트 현황을 해석하고, 규정 준수 정보를 제공하거나 운영 프로세스를 안내하도록 기대하는 순간, 그 허용 범위는 훨씬 좁아집니다.

사용자가 중요한 질문에 대해 일관성 없는 답변을 한 번 경험하고 나면, 신뢰할 수 있는 사내 전문가나 기존의 수작업 프로세스로 돌아가는 경우가 많습니다. 겉보기에 성공적인 출시 이후에도 Copilot 사용량이 정체되는 주된 이유가 바로 여기에 있습니다. 따라서 신뢰는 단순한 도입 지표가 아니라 아키텍처상의 필수 요건이 됩니다.

결론

요약하면, 검색 증강 생성(Retrieval-Augmented Generation)은 외부 문서에 접근하는 강력한 방법을 엔터프라이즈 AI에 제공했지만, 상태를 저장하지 않는 쿼리 루프와 청킹(chunking)의 한계 때문에 진정한 조직의 기억 역할은 제대로 수행하지 못하는 경우가 많습니다. 지속적인 지식 컴파일 없이는 Copilot과 같은 시스템은 일관성, 깊이 있는 문맥 관계, 엔터프라이즈 신뢰 문제에서 계속 어려움을 겪을 것입니다. 원시 문서 저장소에서 LLM Wiki 접근 방식과 같이 새롭게 떠오르는 구조화된 컴파일 지식 계층으로 전환하는 것이, 화려한 데모와 신뢰할 수 있는 비즈니스 도구 사이의 간극을 메우는 핵심입니다. 이 주제를 더 깊이 살펴보고 엔터프라이즈 AI 메모리 문제 해결에 대한 전체 분석을 듣고 싶다면, Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It 에피소드 전편을 꼭 들어 보시기 바랍니다.