표현의 문제: RAG 대 Agentic Search 논쟁이 잘못된 이유

업계는 잘못된 질문을 던져왔습니다.

Claude Code의 제작자이자 책임자인 Boris Cherny가 Latent Space 팟캐스트에서 Anthropic의 플래그십 코딩 에이전트가 RAG를 완전히 버리고 그가 "Agentic Search"라고 부르는 방식으로 전환했다고 밝혔을 때, 담론은 예상대로 분열되었습니다. 한 진영은 RAG가 죽었으며 구식이라고 선언했습니다. 다른 진영은 대부분의 애플리케이션에서 RAG가 여전히 완벽하게 유효하다고 반박했습니다. 새로운 접근 방식에 대한 비판론자들은 Agentic Search가 단순한 벡터 조회 (Vector lookup)보다 훨씬 더 많은 토큰을 소모하고 응답 시간이 더 오래 걸린다는 점을 지적했습니다. 옹호자들은 RAG 인덱스가 기초 데이터가 변경되는 순간 노후화되어, 동적인 환경에서는 검색 (Retrieval)의 신뢰성을 떨어뜨린다고 맞섰습니다. 양측 모두 실질적인 논거를 제시했지만, 이는 서로 다른 문제, 서로 다른 데이터, 서로 다른 맥락에 관한 것이었습니다. 논쟁은 마치 모든 시스템이 한쪽을 선택해야 하는 것처럼, 구식 검색 (Retrieval) 대 신식 에이전트 (Agents)라는 잘못된 이분법으로 굳어졌습니다.

하지만 그러한 프레임은 실제로 일어나고 있는 더 흥미로운 현상을 놓치고 있습니다. 이 분야는 두 진영으로 나뉘는 것이 아닙니다. 다섯 진영으로 나뉘고 있습니다. 그리고 그 이유는 특정 검색 방법이 다른 방법보다 더 낫기 때문이 아닙니다. 데이터 유형마다 근본적으로 다른 자연적 표현 (Natural representations)을 가지고 있으며, 우리는 마침내 이를 존중하는 시스템을 구축하고 있기 때문입니다.

살아있는 코드베이스 (Codebase)는 문서 코퍼스 (Document corpus)가 아닙니다. 재무 보고서는 텍스트 청크 (Text chunks)의 묶음이 아닙니다. 수개월에 걸쳐 구축된 개인 지식 베이스는 정적인 FAQ가 아닙니다. 이 모든 것을 동일한 파이프라인 — 임베딩 (Embed), 청킹 (Chunk), 벡터 데이터베이스 (Vector database)에 저장, 코사인 유사도 (Cosine similarity)에 의한 검색 — 을 통해 강제로 처리하려 한다면, 쿼리를 실행하기도 전에 구조적으로 가장 유용한 정보를 버리는 셈이 됩니다.

이것이 바로 표현의 문제 (Representation problem)입니다. 그리고 이를 해결하는 것이 파편화를 가속화하는 동력입니다.

대화를 시작하게 만든 것

2025년 5월, Boris Cherny는 Latent Space 팟캐스트에 출연하여 Claude Code가 왜 아키텍처에서 RAG를 제외했는지 공개적으로 설명했습니다. 이것이 중요한 이유는 단순히 특정 도구의 선택 문제 때문이 아니라, 누가 그 결정을 내렸느냐 때문입니다. Claude Code는 현재 사용 가능한 가장 유능한 코딩 에이전트 (coding agent)로 널리 간주되며, 이를 개발한 팀은 해당 방식을 포기하기 전 진지하게 실험을 수행했습니다.

Cherny의 설명은 명확했습니다. Claude Code는 원래 표준적인 패턴을 사용했습니다. 즉, 코드베이스를 벡터 인덱싱 (vector-index)하고, 사용자가 질문을 하면 의미론적으로 관련 있는 스니펫 (snippets)을 검색하여, 이를 프롬프트 (prompt)에 결합하는 방식이었습니다. 실제로는 세 가지 요소가 이 방식을 무너뜨렸습니다.

첫째, 지능의 한계 (intelligence ceiling)입니다. RAG 검색은 쿼리 벡터 (query vector)와 유사한 것들을 찾아내지만, 코드 작업은 종종 쿼리와 의미론적으로 전혀 인접하지 않은 것들에 대한 추론을 요구합니다. 인증 함수 (authentication function)의 버그는 세 단계의 간접 참조 (indirection)를 거쳐, 원래의 에러 메시지와 어휘를 거의 공유하지 않는 설정 파일 (configuration file)까지 추적될 수 있습니다. 벡터 유사성 (vector similarity)은 인과 관계 (causality)나 호출 체인 (call chains)을 모델링하지 못합니다.

둘째, 최신성 (freshness)입니다. 활발하게 운영되는 기업의 코드베이스는 끊임없이 변하며, 많은 팀에서 하루에도 수십 개의 커밋 (commits)이 발생합니다. 오늘 아침에 구축된 인덱스 (index)는 오늘 오후에 변경된 함수 시그니처 (function signature)를 반영하지 못할 수 있습니다. 코딩 에이전트에서의 오래된 컨텍스트 (stale context)는 단순히 틀린 답을 내놓는 것에 그치지 않고, 그럴듯해 보이는 버그를 유발할 수 있습니다.

셋째, 보안 (security)입니다. 전체 코드베이스를 쿼리 가능한 벡터 스토어 (vector store)에 인덱싱하는 것은 가장 민감한 비즈니스 로직에 대한 상세하고 구조화된 지도를 만드는 것과 같습니다. 만약 해당 스토어가 침해된다면, 공격자는 단순한 소스 파일 그 이상을 갖게 됩니다. 즉, 모든 것이 무엇을 하고 어떻게 연결되어 있는지에 대한 조직화된 인덱스를 갖게 되는 것입니다.

이에 대한 대응은 인덱스를 패치하는 것이 아니라, 인덱스를 제거하는 것이었습니다.

두 개가 아닌 다섯 가지 패러다임

Claude Code의 피벗(pivot)은 더 넓은 질문을 던졌습니다. RAG가 아니라면, 무엇인가? 그리고 그 답은 당신이 어떤 종류의 데이터를 다루고 있는지에 전적으로 달려 있다는 것이 밝혀졌습니다. 오늘날 실제 운영 환경에서 사용되는 최소 다섯 가지의 뚜렷한 검색 패러다임(retrieval paradigms)이 존재하며, 각 패러다임은 서로 다른 데이터 유형과 쿼리(query) 구조에 맞춰져 있습니다.

패러다임 1: 벡터 RAG (Vector RAG)

이것은 대부분의 엔지니어들이 알고 있는 기본 방식입니다. 문서는 청크(chunk)로 나뉘고, 고차원 벡터(high-dimensional vectors)로 임베딩(embedding)되어 벡터 데이터베이스(vector database)에 저장됩니다. 쿼리 시점에는 쿼리가 임베딩되고, 코사인 유사도(cosine similarity)를 통해 가장 가까운 벡터들이 검색됩니다.

이 카테고리에 속하는 도구로는 Pinecone, Weaviate, Qdrant, Chroma와 같은 표준 벡터 데이터베이스가 있으며, 여기에 OpenAI, Cohere의 임베딩 모델(embedding models) 또는 오픈 소스 대안들이 결합됩니다.

효과적인 경우: 내용이 비교적 안정적이고 정보 요구 사항이 단순한 비정형 텍스트 코퍼스(unstructured text corpora). FAQ 시스템, 고객 지원 지식 베이스, 광범위한 문서 검색, 뉴스 아카이브에 대한 시맨틱 검색(semantic search) 등이 해당됩니다. 사용자가 "비밀번호를 어떻게 재설정하나요?"라고 물었을 때 그 답이 지원 위키(support wiki) 어딘가에 있다면, 청크화된 텍스트에 대한 코사인 유사도는 완벽하게 적절한 도구입니다.

한계가 있는 경우: 구조가 중요한 모든 경우입니다. 200페이지 분량의 재무 보고서에는 섹션 제목, 표, 번호가 매겨진 항목 간의 상호 참조, 그리고 의미를 전달하는 계층적 조직이 포함되어 있습니다. 이를 512개 토큰(token) 단위의 세그먼트로 나누고 임베딩하면, 구조화된 논증을 파편들의 주머니(bag of fragments)로 만들어 버리는 셈입니다. 검색 시스템은 더 이상 47페이지의 각주에서 표 3B가 참조되고 있다는 사실을 알지 못하며, 단지 두 곳 모두에 숫자와 "revenue"라는 단어가 포함되어 있다는 사실만 알게 됩니다.

벡터 RAG는 또한 인덱스 업데이트 주기보다 빠르게 변하는 모든 데이터, 그리고 단일 사실 조회(single-fact lookup)가 아닌 멀티홉 추론(multi-hop reasoning)이 필요한 쿼리에서도 어려움을 겪습니다.

패러다임 2: 에이전틱 검색 (Agentic Search)

이것이 바로 Claude Code가 전환한 방식입니다. 미리 구축된 인덱스 (index)에 쿼리를 날리는 대신, 모델은 도구(tools)를 사용합니다. 구체적으로는 파일 경로의 패턴 매칭을 위한 Glob와 파일 내 전체 텍스트 검색을 위한 Grep을 사용하여, ReAct 루프 (Reason, Act, Observe, repeat)를 통해 실시간으로 코드베이스를 탐색합니다.

구체적인 메커니즘은 다음과 같습니다: 에이전트 (agent)가 작업을 수신하면, 관련 코드가 어디에 있을지에 대한 가설을 세우고, 타겟팅된 검색을 실행하며, 결과를 읽고, 자신의 이해도를 업데이트한 뒤, 필요하다면 다시 검색합니다. 이것은 숙련된 개발자가 실제로 디버깅하는 방식과 정확히 일치합니다. 코드베이스의 시맨틱 인덱스 (semantic index)에 쿼리를 던지는 것이 아니라, 문제에 대해 추론하고 적절한 위치를 찾아보는 방식 말입니다.

Cline (이전의 Claude Dev)도 동일한 접근 방식을 사용합니다. 이 에이전트는 데이터가 노후화될 인덱스도 없고, 외부 벡터 저장소 (vector store)로 인한 공격 표면 (attack surface)도 없으며, 임베딩 모델 (embedding model)의 품질에 의해 제한되는 한계도 없습니다.

효과적인 경우: 끊임없이 변화하는 라이브 코드베이스. 심볼 (symbol)의 정의 찾기, 호출자 (callers) 추적하기, 인접 모듈의 부작용 (side effects) 식별하기와 같이 멀티홉 추론 (multi-hop reasoning)이 필요한 작업. 조회 속도보다 탐색의 지능이 더 중요한 모든 시나리오.

실질적인 트레이드오프 (tradeoff): Cherny는 이를 지능을 위해 시간을 맞바꾸는 것이라고 설명했습니다. 에이전틱 검색 (Agentic search)은 벡터 조회 (vector lookup)보다 쿼리당 더 많은 토큰을 소비하며 시간이 더 오래 걸립니다. 사용자가 어차피 수 초의 응답 시간을 예상하는 코딩 에이전트의 경우, 이는 수용 가능한 거래입니다. 하지만 초당 수천 개의 쿼리를 처리하는 고처리량 검색 시스템 (high-throughput retrieval system)의 경우에는 그렇지 않습니다.

패러다임 3: 그래프 및 AST 인덱싱

"인덱스 없음"과 "벡터 인덱스" 사이에는 세 번째 접근 방식이 있습니다. 시맨틱 내용 대신 코드의 _구조 (structure)_를 인덱싱하는 것입니다.

두 가지 도구가 이 패러다임을 잘 보여줍니다.

codebase-memory-mcp (DeusData 제작)는 tree-sitter를 사용하여 155개의 프로그래밍 언어에 걸쳐 소스 파일을 추상 구문 트리 (Abstract Syntax Trees, AST)로 파싱한 다음, 함수, 클래스, 모듈이 노드(node)가 되고 호출 관계, 상속, 임포트(import)가 타입이 지정된 엣지(edge)가 되는 지속 가능한 지식 그래프 (knowledge graph)를 구축합니다. 쿼리는 임베딩 (embeddings)에 대한 코사인 유사도 (cosine similarity)를 계산하는 대신 이 그래프를 탐색합니다. 성능 수치는 놀랍습니다. 2,800만 줄의 코드인 Linux 커널이 약 3분 만에 인덱싱됩니다. 쿼리가 파일 내용을 LLM에 보내는 대신 그래프를 직접 타격하기 때문에, 이 방식은 단순한 파일별 분석보다 토큰을 약 99% 적게 사용합니다. 쿼리 지연 시간 (latency)은 1밀리초 미만입니다.

Understand-Anything은 코드베이스를 지식 그래프로 변환한다는 동일한 기본 아이디어를 취하지만, 대상 사용자를 다르게 최적화합니다. codebase-memory-mcp가 활발한 개발 중에 프로그래밍 방식으로 코드를 쿼리하는 AI 에이전트 (AI agents)를 위해 구축되었다면, Understand-Anything은 자신이 작성하지 않은 코드베이스를 이해하려는 _사람 (humans)_을 위해 구축되었습니다. 이는 브라우저에서 팬(pan), 줌(zoom), 검색이 가능한 대화형 시각화 대시보드를 생성합니다. 아키텍처를 통한 가이드형 학습 투어를 생성하고, 코드가 비즈니스 프로세스에 어떻게 매핑되는지 설명하며, 새로운 팀원을 위한 온보딩 가이드를 제작할 수 있습니다. 또한 순수 코드를 넘어섭니다. LLM이 관리하는 마크다운 (markdown) 위키를 대상으로 지정하면 — 이는 AI 에이전트가 일반 텍스트 파일로부터 개인 지식 베이스를 점진적으로 구축하고 상호 참조하는 방식으로, Andrej Karpathy에 의해 대중화된 형식입니다 — 여러분의 노트와 연구에 대한 탐색 가능한 지식 그래프를 구축합니다.

오픈 소스 코딩 어시스턴트인 Aider는 이와 유사한 접근 방식을 이전에 개척했습니다. 파일, 클래스, 함수의 저장소 맵 (repository map)을 구축하기 위해 AST 파싱을 사용하며, 이는 전체 파일 내용 대신 컨텍스트 (context)로서 모델에 전달됩니다.

codebase-memory-mcp와 Understand-Anything 중 선택하기: 이들은 서로 다른 주요 유스케이스 (use cases)를 제공하며 상호 배타적이지 않습니다.

• codebase-memory-mcp를 사용하세요: 주요 사용자가 활발한 코딩 작업 중인 AI 에이전트(AI agent)인 경우에 적합합니다. 이 방식은 더 빠르고 가벼우며(의존성이 없는 단일 바이너리), 에이전트가 작업 중간에 필요로 하는 구조적 쿼리(structural queries)에 최적화되어 있습니다. 예를 들어 호출 그래프(call graphs), 데드 코드 탐지(dead code detection), 서비스 간 HTTP 링크, 리팩터링(refactor) 전 영향 분석(impact analysis) 등이 이에 해당합니다. 또한 토큰(token) 사용량이 훨씬 적은데, 이는 하루에 수백 개의 에이전트 쿼리를 실행할 때 매우 중요한 요소입니다.

• Understand-Anything를 사용하세요: 주요 사용자가 낯선 코드베이스에서 방향을 잡으려는 사람(onboarding, 아키텍처 리뷰, 또는 비기술적 이해관계자에게 시스템을 설명하는 경우 등)인 경우에 적합합니다. 이 도구의 시각적 대시보드(visual dashboard)와 가이드 투어(guided tours)는 프로그래밍 방식의 조회(programmatic lookup)가 아닌, 탐색과 이해를 위해 설계되었습니다.

실제 상황에서 팀은 두 가지를 모두 사용할 수 있습니다. 예를 들어, 백그라운드에서는 AI 코딩 에이전트를 구동하기 위해 codebase-memory-mcp를 사용하고, 새로운 엔지니어가 합류하거나 팀에 아키텍처에 대한 공유 지도가 필요할 때 Understand-Anything을 한 번 실행하는 방식입니다.

효과적인 경우: 구조적 관계(structural relationships)를 주로 쿼리하는 대규모의 비교적 안정적인 코드베이스에서 효과적입니다. "어떤 함수가 authenticate()를 호출하는가?"와 같은 질문은 그래프 순회(graph traversal)를 통해 간단히 답할 수 있습니다. "이 인터페이스를 변경하면 무엇이 깨질까?"는 도달 가능성 쿼리(reachability query)입니다. 이러한 질문들은 벡터 유사도(vector similarity)만으로는 답할 수 없는 질문들입니다. 이는 임베딩 모델(embedding models)이 나빠서가 아니라, 질문의 본질이 의미론적 근접성(semantic proximity)이 아닌 그래프 구조(graph structure)에 있기 때문입니다.

한계가 있는 경우: 아직 재색인(re-indexed)되지 않은 아주 최근에 변경된 코드(증분 색인(incremental indexing)으로 완화할 수는 있음)와 구조 자체가 계속 변하는 매우 동적인 코드베이스에서는 한계가 있습니다. 또한 그래프는 런타임 동작(runtime behavior)을 모델링하지 않으며, 오직 정적 구조(static structure)만을 모델링합니다.

패러다임 4: 추론 기반 트리 색인 RAG (Reasoning-Based Tree-Indexed RAG)

이 패러다임은 길고 계층적인 문서에 대한 벡터 청킹(vector chunking)의 구조적 한계를 해결하며, 그 결과가 매우 놀라워 이 분야의 기본 가정들을 재정립할 정도입니다.

VectifyAI에서 개발한 PageIndex는 문서 검색(document retrieval)에 대해 근본적으로 다른 접근 방식을 취합니다. 이 방식은 청킹(chunking)과 임베딩(embedding)을 수행하는 대신, 문서로부터 계층적인 "목차(table of contents)" 트리를 구축합니다. 이를 통해 섹션 구조, 하위 섹션 간의 관계, 그리고 저자가 콘텐츠에 실제로 부여한 논리적 구조를 포착합니다. 쿼리 시점에는 LLM이 평면적인 청크(flat chunks)에 대해 최근접 이웃 유사도(nearest-neighbor similarity)를 계산하는 대신, 이 트리를 바탕으로 추론하여 올바른 섹션으로 이동합니다.

벡터(vectors)도 없습니다. 청킹(chunking)도 없습니다. 임베딩 모델(embedding model)조차 전혀 사용하지 않습니다.

벤치마크 결과: 실제 SEC 공시 자료(10-K, 10-Q, 8-K 및 실적 발표 자료)에 대한 질문 데이터셋인 FinanceBench에서 98.7%의 정확도를 기록했습니다. 동일한 벤치마크에서 벡터 RAG 베이스라인(baselines)은 약 30~50%의 점수를 기록하며, 이는 상당한 성능 향상임을 보여줍니다.