AI 에이전트를 위해 RAG를 고려 중이신가요? 대신 이것을 구축하세요.

핵심 요약 (Key Takeaways)

대부분의 SaaS AI 에이전트는 벡터 데이터베이스 (Vector Database)가 필요하지 않습니다. 파일 기반 메모리 (File-based memory)와 100만 토큰의 컨텍스트 윈도우 (Context windows), 그리고 도구 호출 (Tool calls)만으로도 일반적인 사례를 처리할 수 있습니다.

Anthropic의 공식적인 "적시 컨텍스트 검색 (Just-in-time context retrieval)을 위한 핵심 원시 요소 (Key primitive)"는 벡터 기반이 아닌 파일 시스템 (Filesystem) 기반입니다.

Claude Code의 패턴 — 인덱스 파일 (MEMORY.md)과 필요할 때 로드되는 주제별 마크다운 (Markdown) 파일의 조합 — 은 프로덕션 수준의 SaaS 에이전트에도 유효합니다.

RAG는 여전히 대규모 비정형 코퍼스 (Unstructured corpora), 규제가 필요한 멀티 테넌트 (Multi-tenant) 데이터, 그리고 빈번하게 갱신되는 외부 지식에는 유리합니다. 하지만 대부분의 SaaS 유스케이스 (Use cases)는 이러한 기준에 부합하지 않습니다.

2026년에 AI 에이전트를 위해 RAG를 고려하고 있다면, 가장 중요한 질문은 어떤 벡터 데이터베이스를 선택하느냐가 아닙니다. 과연 그것이 정말 필요한가 하는 점입니다.

제가 처음으로 고객 지원 에이전트를 구축했을 때, 저는 곧바로 기본 스택을 선택했습니다. 벡터 데이터베이스 (Vector database), 임베딩 파이프라인 (Embedding pipeline), 청커 (Chunker), 리랭커 (Reranker)를 말이죠. 몇 주간의 배관 작업 (Plumbing) 끝에, 에이전트는 여전히 제 앱의 자체 데이터베이스에 일반적인 SELECT 쿼리를 실행하여 대부분의 질문에 답변했습니다. 벡터 저장소 (Vector store)는 제 역할을 거의 하지 못했습니다. 저는 그것을 제거하고, 인덱스 파일과 에이전트가 필요할 때 읽을 수 있는 마크다운 (Markdown) 노트 디렉토리로 교체했습니다. 답변은 동일했지만, 움직이는 부품 4개가 사라졌습니다. 제가 필요하다고 생각했던 검색 (Retrieval)은 단일 파일 읽기만으로도 이미 처리할 수 있는 것이었습니다.

대부분의 SaaS 에이전트에게는 더 단순한 패턴인 **파일 기반 메모리 (File-based memory)**가 적합합니다. 에이전트가 학습한 내용을 마크다운 (Markdown) 파일에 저장하고 필요할 때 다시 읽어들이는 방식인데, 이는 Claude Code가 내부적으로 사용하는 방식이기도 합니다. 여기에 100만 토큰의 컨텍스트 윈도우 (Context windows)와 기존 데이터베이스에 대한 도구 호출 (Tool calls)을 추가하면, 벡터 DB 파이프라인보다 더 적은 구성 요소로도 일반적인 에이전트 업무를 처리할 수 있습니다.

이 글은 "RAG는 끝났다"는 주장을 하는 글이 아닙니다. Hamel Husain은 2025년 7월에 그러한 관점에 반박했으며, 그의 말이 맞습니다. 변하고 있는 것은 어떤 종류의 검색 (Retrieval) 방식을 가장 먼저 선택하느냐입니다. 만약 여러분이 Claude Code나 Cursor를 사용하여 바이브 코딩 (vibe coding)을 해왔다면, 이미 이름을 붙이지 않았을 뿐 파일 기반 메모리 (file-based memory)를 사용하고 있었던 것입니다.

기본 RAG 본능은 과도한 작업을 수행하고 있습니다

"AI 에이전트 구축하기" 튜토리얼을 아무거나 열어보면 아키텍처(Architecture)는 모두 동일합니다. 벡터 데이터베이스 (Vector database, Pinecone, ChromaDB, pgvector)를 선택하고, 임베딩 파이프라인 (Embedding pipeline)을 구축하며, 문서를 청킹 (Chunking)하고, 검색 (Retrieval) 로직을 작성하고, 리랭커 (Reranker)를 계층화한 뒤, 상위 k개의 청크 (top-k chunks)를 모델에 전달합니다. 각 구성 요소는 여러분이 직접 관리하고 운영 비용을 지불해야 하는 시스템입니다.

이러한 스택 (Stack)은 프런티어 모델 (Frontier models)의 컨텍스트 윈도우 (Context window)가 8K에서 32K 사이였고, 도구 호출 (Tool calling)이 실험적이었던 시절에는 타당했습니다. 하지만 Claude Sonnet 4.6이 1M 토큰 컨텍스트 윈도우를 출시하고 함수 호출 (Function calling)이 보편화된 2026년에는 이를 기본값으로 사용하는 것이 맞지 않습니다. 대부분의 SaaS 데이터는 이미 구조화된 데이터베이스 (Structured database)에 존재하며, 에이전트는 유사도 검색 (Similarity search)이 아닌 도구 호출 (Tool calls)을 통해 데이터에 접근합니다. 2023년 시대의 스택은 이 작업에 있어 과잉 엔지니어링 (Over-engineering)입니다.

RAG가 진정으로 승리하는 경우

기본적인 방식을 해체하기 전에, 전체 RAG 파이프라인 (RAG pipeline)이 정답인 사례들을 명시해 보겠습니다. 실제로 그러한 사례들이 존재합니다.

대규모 비정형 코퍼스 (Large unstructured corpora). 에이전트가 제목만으로는 내용을 알 수 없는 수만 개의 문서(제품 매뉴얼, 법률 아카이브, 과학 문헌, 엔터프라이즈 규모의 내부 위키 등)를 검색해야 할 때는 유사도 검색 (similarity search)이 필요합니다. 인덱스에 모든 문서를 나열하는 것은 컨텍스트 (context)에 담기에 한계가 있으며, 완전 일치 검색 (exact-match lookups)은 관련 있는 청크 (chunk)를 놓칠 수 있습니다.
규제 대상의 멀티 테넌트 격리 (Regulated, multi-tenant isolation). 테넌트별 데이터 경계가 엄격한 SaaS 애플리케이션(의료, 금융, 국방)은 벡터 스토어 (vector store)를 통해 행 수준 액세스 제어 (row-level access controls)와 감사 추적 (audit trails) 기능을 즉시 사용할 수 있습니다. 파일 시스템 메모리 (Filesystem memory)로도 이를 수행할 수 있지만, 이 경우 기본 구성 요소 (primitives)를 직접 구축해야 합니다.
빈번하게 갱신되는 외부 지식 (Frequently-refreshed external knowledge). 뉴스 피드, 시장 데이터, 규제 업데이트 등 코퍼스 (corpus)가 매시간 변하는 모든 경우입니다. 벡터 인덱스 (Vector indexes)는 점진적으로 업데이트되지만, 파일 시스템 메모리는 동일한 점진적 경로를 직접 구축하지 않는 한 데이터가 어긋나게 됩니다.
구조화된 도구 응답에 대한 에이전트 기반 검색 (Agentic search over structured tool responses). Jason Liu는 이를 날카롭게 지적합니다: "좋은 검색은 RAG 품질의 상한선입니다. 재현율 (recall)이 낮다면, 그 어떤 프롬프트 엔지니어링 (prompt engineering)이나 모델 업그레이드도 당신을 구원할 수 없습니다." 에이전트가 수천 개의 구조화된 레코드 (records)를 바탕으로 추론하고 다음에 무엇을 질문할지 결정할 때는, 패싯 메타데이터 (faceted metadata)를 갖춘 실제 검색 인프라가 필요합니다.

만약 당신의 유스케이스 (use case)가 이 중 하나에 해당한다면, RAG 스택을 구축하십시오. 이 포스트의 나머지 내용은 그 외의 모든 사례에 대해 다룹니다.

왜 대부분의 SaaS 에이전트는 해당 프로필에 맞지 않는가

전형적인 SaaS 에이전트는 _사용자 정의 구조화된 데이터 (structured data)_를 기반으로 작동합니다: 사용자, 계정, 주문, 티켓, 감사 로그(audit logs) 등이 이에 해당합니다. 사용자 기록을 찾기 위해 퍼지 유사도 검색 (fuzzy similarity search)이 필요하지 않습니다. 대신 SELECT * FROM users WHERE id = ?를 실행하는 도구 호출 (tool call)이 필요합니다. 도구 호출은 다음 세 가지 측면에서 벡터 검색 (vector retrieval)보다 우수합니다: 모델이 산문 조각보다 더 신뢰성 있게 처리할 수 있는 정밀한 구조화된 기록, 임베딩 파이프라인을 다시 실행할 필요 없이 데이터가 작성되는 즉시 반영되는 최신 데이터, 그리고 기존 데이터베이스의 액세스 제어 (access controls), 트랜잭션 (transactions), 감사 추적 (audit trail)입니다. 데이터베이스 옆에 병렬로 배치된 벡터 저장소 (vector store)는 이 중 어느 것도 충족하지 못합니다.

에이전트 컨텍스트 중 데이터베이스에 포함되지 않은 부분(시스템 지침, 관례, 사용자에 대해 축적된 학습 내용, 이전 대화 요약, 제품 문서 등)에 대해서도 수학적 계산 방식이 바뀌었습니다. 1M 토큰의 컨텍스트 윈도우 (context window)를 사용하면 엄청난 양의 상태 (state)를 인라인 (inline)으로 유지할 수 있습니다. 이미 들어갈 수 있는 정보를 굳이 검색할 필요가 없습니다.

파일 기반 메모리 패턴 (The File-Based Memory Pattern)

아키텍처는 간단합니다: 에이전트가 무엇을 알고 있는지 나열하는 인덱스 파일 (index file), 내용이 담긴 주제별 마크다운 (markdown) 파일 디렉토리, 그리고 에이전트가 이를 탐색하는 데 사용하는 **파일 읽기 및 파일 쓰기 도구 (file-read and file-write tools)**로 구성됩니다.

Anthropic의 공식 메모리 도구 (Memory tool) 문서에서는 이를 [

Anthropic의 2025년 9월 효과적인 컨텍스트 엔지니어링 (effective context engineering)에 관한 포스트에서는 이를 다음과 같이 공식화합니다: "Just-in-time 접근 방식으로 구축된 에이전트는 가벼운 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)를 유지하며, 도구 (tools)를 사용하여 런타임 (runtime) 시점에 이러한 참조를 통해 데이터를 컨텍스트 (context)로 동적으로 로드합니다." 동일한 포스트는 이 방식이 방지하는 실패 모드(failure mode)를 다음과 같이 명명합니다: "컨텍스트 부패 (context rot)", 즉 컨텍스트가 채워짐에 따라 모델의 회상 (recall) 능력이 저하되는 현상입니다. 파일 기반 메모리 (file-based memory)는 설계 단계부터 컨텍스트를 가볍게 유지합니다.

작업 메모리 (Working memory)는 작게 유지됩니다: 시스템 프롬프트 (system prompt), 대화 내용, 그리고 이번 단계에서 불러온 주제 파일들입니다. 그 외의 모든 것은 디스크 (disk)에 머뭅니다. 더 많은 정보가 필요하다면 더 읽어보세요. Harness engineering에서는 이를 피드포워드 제어 (feedforward control)라고 부릅니다: 에이전트가 추측할 필요가 없도록 입력을 구조화하는 것입니다.

Claude Code가 이를 구현하는 방식

참조 구현체는 모든 Claude Code 사용자의 머신에 설치되어 있습니다. Claude Code는 ~/.claude/projects/<project>/memory/ 경로에 메모리 디렉토리를 유지하며, 여기에는 단일 인덱스 파일(MEMORY.md)과 그 옆에 하나 이상의 주제별 마크다운 (markdown) 파일이 함께 존재합니다.

공식 문서 (official docs)에는 규칙이 명시되어 있습니다: MEMORY.md가 가장 먼저 로드되며, 처음 200줄 또는 25KB로 제한됩니다. 이 파일에는 주제별 메모리 파일을 가리키는 한 줄짜리 항목들이 포함되어 있습니다. 주제 파일은 에이전트가 요청하기 전까지는 로드되지 않습니다. /memory 명령어를 사용하면 현재 로드된 항목을 나열하고, 자동 메모리 (auto-memory)를 토글하며, 기반이 되는 폴더를 열 수 있습니다.

동일한 문서에서 놓치기 쉬운 가이드라인이 하나 있습니다: 메모리 파일당 200줄 미만을 목표로 하라는 것입니다. 그 이유는 파일이 길어질수록 더 많은 컨텍스트를 소비하고 준수 능력을 저하시키기 때문입니다. 이것이 파일 기반 메모리를 작동하게 만드는 원리입니다. 하나의 거대한 컨텍스트 덤프 (context dump)보다 작고 집중된 여러 개의 파일이 더 효과적입니다.

이것이 작동하는 이유

세 가지 속성이 에이전트가 필요로 하는 사항과 깔끔하게 일치합니다. 인덱스(index)는 _방향성 인식 (directional awareness)_을 제공합니다. 즉, 에이전트가 자신이 무엇을 알고 있는지 알게 해줍니다. 주제별 파일은 _적시 심층 정보 (just-in-time depth)_를 제공합니다. 해당 주제가 활성화될 때만 컨텍스트 (context)에 포함됩니다. 200행 제한은 _요약 규율 (summarization discipline)_을 강제합니다. 내용이 길어지는 주제는 분할해야 하며, 이를 통해 각 로드 (load)가 집중력을 유지할 수 있습니다.

이 중 새로운 인프라(infrastructure)는 없습니다. 이는 마크다운 (markdown) 파일들의 디렉토리와 이를 조직화하고 읽기 위한 규칙(convention)일 뿐입니다. 이 방식이 작동하는 이유는 해당 규칙이 모델이 관련성 (relevance)을 추론하는 방식과 일치하기 때문입니다.

이를 귀하의 SaaS 에이전트에 적용하기

이 패턴을 귀하의 SaaS 내부 에이전트에 맞게 조정하는 것은 대부분 동일한 규칙을 귀하의 스토리지 (storage)와 도구 (tools)에 매핑하는 문제입니다.

스토리지 계층 (Storage layer)

가장 간단한 백엔드 (backend)는 실제 파일 시스템 (filesystem)입니다 (단일 테넌트, 단일 머신 설정에는 적합합니다). 프로덕션 환경의 멀티 테넌트 (multi-tenant) SaaS의 경우, 이 패턴은 테넌트당 하나의 접두사 (prefix)를 사용하는 S3 또는 Cloudflare R2에 깔끔하게 적용되거나

두 가지 불변량(invariants)이 대부분의 작업을 수행합니다. 항상 인덱스(index)를 로드할 것. 대화에서 필요할 때만 토픽 파일(topic files)을 로드할 것. 에이전트는 그 순간 무엇을 저장할 가치가 있는지 결정할 수 있지만, 결정론적 캡처(deterministic capture)가 더 신뢰할 수 있습니다. 토픽 파일은 추가(append)되는 것이 아니라 전체가 다시 작성(rewrite)됩니다. 이를 통해 파일 길이를 200행 이내로 유지하고 요약을 강제합니다.

캡처 패턴: 훅(hooks)과 일기(daily diary)

흥미로운 설계 질문은 메모리가 어디에 저장되느냐가 아니라, 에이전트가 언제 메모리에 기록하느냐입니다. 두 가지 패턴이 결합되어 대부분의 작업을 처리합니다.

세션별 훅 (Per-session hooks). 세션이 종료된 후, 결정론적 트리거(deterministic trigger)가 memory/sessions/<session-id>.md에 짧은 항목을 기록합니다: 사용자가 무엇을 했는지, 무엇에 반대했는지, 어떤 선호도가 나타났는지, 무엇이 고장 났는지 등입니다. 에이전트는 세션 중간에 결정하지 않습니다. 훅은 세션 종료 시점에 캡처합니다. 이는 Claude Code의 자동 메모리(auto-memory)와 동일한 형태입니다. 모델이 대화 중에 새로운 관습(conventions)을 포착하면, 시스템이 종료 시점에 이를 영구 저장(persist)합니다.

일기 (A daily diary). 하루에 한 번, 예약된 작업(scheduled job)이 지난 24시간 동안의 세션 로그를 요약하여 memory/diary/2026-05-10.md에 하나의 짧은 항목으로 작성합니다. 한 단락이면 충분하며, 그 이상은 안 됩니다. 오래된 로그는 통합되어 아카이브(archive)됩니다. 한 달이 지나면 수천 개의 가공되지 않은 로그 대신 30개의 일기 항목을 갖게 됩니다. 1년 단위로 주간 요약과 월간 테마를 통해 더 압축하면, 에이전트는 인간이 기억하는 방식과 유사한 계층적 메모리(hierarchical memory)를 갖게 됩니다: 지난주는 생생하게, 지난달은 요약된 형태로, 작년은 테마 중심으로 기억하는 방식입니다.

일기가 작동하는 이유는 일기 쓰기(journaling)가 작동하는 이유와 같습니다. 요약을 강제하고, 이는 다시 관련성 순위 지정(relevance ranking)을 강제합니다. 당시 무엇이 중요했는지 결정하는 것은 나중에 비정형 데이터 더미에서 관련성을 재구성하는 것보다 훨씬 비용이 저렴합니다. 인간과 달리 에이전트는 이 작업을 잊어버리지 않습니다. 예약된 함수가 memory/sessions/를 읽고, 모델에게 "지난 24시간 동안의 세션을 지속 가능한 학습 내용에 집중하여 한 단락으로 요약하세요"라고 프롬프트(prompt)를 보낸 뒤, 결과를 작성하고 소스 파일을 아카이브합니다. 이는 인프라가 아니라 50줄짜리 크론 잡(cron job)입니다.

Andrej Karpathy의 2026년 4월 "LLM Wiki" gist는 동일한 형태를 세 가지 계층의 분리로 공식화합니다: 불변의 소스 문서가 담긴 raw/ 디렉토리, 원본 자료를 요약하고 상호 참조(cross-referencing)하는 LLM 관리 마크다운(markdown) 페이지가 담긴 wiki/ 디렉토리, 그리고 스키마(schema)와 업데이트 워크플로(workflow)를 정의하는 루트(root)의 CLAUDE.md입니다. 그의 프레임워크(framing)는 다음과 같습니다: "LLM은 지루해하지 않고, 상호 참조를 업데이트하는 것을 잊지 않으며, 한 번의 패스(pass)로 15개의 파일에 접근할 수 있습니다." 동일한 골격이며, 어휘만 다를 뿐입니다.