반년 전, 나는 사내 지식(Knowledge)용으로 RAG 파이프라인을 구축하고 있었습니다. LangChain, 벡터 DB는 Qdrant, embedding은 OpenAI, 리랭커(Reranker)는 Cohere, 청크(Chunk) 사이즈는 512 토큰. 3주에 걸쳐 구축했고, 사내 QA의 정밀도가 체감상 40%에서 65%로 올라갔을 즈음 "이것으로 지식 검색은 완벽하다"라고 생각했습니다.

하지만 Claude Code를 업무에 사용하기 시작한 지 2주 만에 그 인식은 흔들렸습니다. Claude Code는 코드베이스의 인덱스(Index)를 전혀 만들지 않습니다. 그런데도 내가 3주 동안 만든 RAG보다 코드 검색의 정밀도가 확실히 높았습니다. 내부에서 무엇이 일어나고 있는지 조사한 끝에 도달한 것이 바로 "Agentic Search"라는 단어였습니다.

대략적으로 말하자면 다음과 같습니다.

RAG: 사전에 벡터 인덱스(Vector Index)를 만들고, 쿼리(Query)와 유사한 벡터를 가져와 LLM에 전달함
Agentic Search: 모델 스스로가 glob, grep, read를 조합하여 필요한 정보를 그때그때 찾아 나섬

Claude Code를 만든 Boris Cherny 씨는 초기에 RAG를 포함한 상태에서 양자를 비교했을 때, Agentic Search가 "압도적인 차이로 이겼다"라고 말했습니다. 이는 최근의 유행이 아니라, 실측에 기반한 선택이었습니다.

나의 체감도 이와 비슷하여, Claude Code에게 "인증 관련 버그를 봐줘"라고 부탁했을 때, 먼저 glob src/**/*auth*를 실행하고, 이어서 grep -n "validateToken"을 수행한 뒤, 마지막으로 해당 파일을 Read 하는 등 인간 엔지니어와 동일한 조사 프로세스를 밟고 있었습니다. 인덱스는 어디에도 없습니다.

RAG의 최대 약점은 **embedding 유래의 fuzzy match(모호한 일치)**입니다. 의미적으로 가까운 것을 가져오기 때문에 어휘가 달라도 찾아낼 수 있는 반면, 완전 일치(Exact Match)가 필요할 때 다른 것을 반환할 때가 있습니다.

나의 사례에서는 validateToken 함수의 참조 위치를 찾고 싶을 때, RAG는 verifyJWT, checkSession, authMiddleware를 상위에 내놓았습니다. 의미적으로는 올바른 유연 관계입니다. 다만 내가 원한 것은 validateToken의 **정확한 호출부(Caller)**였습니다.

# Agentic Search가 배후에서 실행하는 조사
$ grep -rn "validateToken(" src/ --include="*.ts"
src/auth/middleware.ts:42: if (!validateToken(token)) {
...

3건이 핀포인트로 반환됩니다. embedding의 유사도에 의존하지 않기 때문에, validate의 오타가 validte라면 전혀 걸리지 않는 대신, "호출되는 장소는 여기"라는 사실을 놓치지 않습니다.

이것은 "모호한 일치가 가능하다"는 점이 RAG의 장점이었을 텐데, 코드 검색이라는 용도에서는 오히려 약점이었던 것입니다. 나는 반년이 걸려서야 겨우 납득할 수 있었습니다.

embedding은 "자연어의 의미적 근접성"을 포착하는 데 능숙하며, "코드 심볼(Symbol)의 엄격한 일치"에는 서툽니다. getUserById와 findUserBy는 의미적으로 가깝기 때문에 embedding 공간에서는 인접한 벡터가 됩니다. 하지만 코드 검색에서는 getUserById의 참조 위치가 필요하므로, findUserBy를 "가까운 후보"로 반환받으면 곤란합니다. 코드는 애초에 식별자(Identifier)의 엄격성으로 성립하는 언어이기에, fuzzy한 검색은 구조적으로 상성이 좋지 않습니다.

RAG의 두 번째 고충은 **인덱스의 부패(Decay)**입니다. 코드베이스는 항상 움직이기 때문에 벡터 인덱스는 계속해서 낡아갑니다. 나의 운용 방식에서는 하루에 한 번 cron으로 재-embedding을 수행하고 있었지만, 오전에 작성한 함수가 오후 검색에서 나오지 않는 현상이 일상적으로 발생했습니다.

Agentic Search는 파일 시스템 자체가 인덱스입니다. grep도 read도, 방금 전의 파일을 봅니다. git checkout으로 브랜치를 전환한 직후라도 검색 결과가 즉시 해당 브랜치의 내용으로 전환됩니다.

나의 사내 QA bot(RAG 버전)은 "git pull...

「...하고 나서 30분 정도는 오래된 답변이 섞인다」라는 운영상의 허용을 강요해야 했습니다. Agentic Search 기반으로 다시 만들자, 그 허용 자체가 사라졌습니다. 「최신 상태」를 별도로 관리할 필요가 없다는 것은 상상 이상으로 편합니다.

Anthropic Engineering Blog는 2025년 Claude Code release notes에서 "No vector database. No embedding pipeline. The filesystem is the index."라고 적고 있습니다. 인덱스를 가지지 않는 것이 Claude Code 디자인 원칙 중 하나가 되었습니다.

RAG를 사내에 구축할 때 가장 번거로운 논쟁은, embedding API에 코드를 보내는 것에 대한 우려입니다. Voyage, Cohere, OpenAI 모두 입력 데이터를 보내야 합니다 (no-retention 계약이 있다 하더라도).

보안 부서로부터는 "기밀성이 높은 리포지토리는 외부 API로 보낼 수 없다"라는 말을 들었고, 저의 RAG 구축 작업 중 절반은 sentinel routing (기밀 파일만 로컬 embedding으로 분리하는 메커니즘)에 소비되었습니다.

Agentic Search는 코드베이스 전체를 로컬에서 탐색하며, LLM에 전달하는 것은 사용자가 필요하다고 판단한 함수 본체뿐입니다. 인덱싱 목적으로 전체 코드를 보낼 필요가 없습니다. Claude Code의 경우, 사용자가 허가한 범위의 파일만 context에 들어가는 설계로 되어 있습니다.

이는 「인덱스 불필요」와 더불어, 사내 도입의 장벽을 낮추는 큰 효과였습니다. 제가 속한 조직에서도 RAG 도입으로 인해 반년 동안 멈춰 있던 리포지토리가, Claude Code 도입은 1주일 만에 승인이 내려졌습니다.

Agentic Search를 「코드 버전 RAG」라고 칭찬하기만 하는 것은 불공평합니다. 최대의 약점은 토큰 소비입니다.

• RAG는 사전에 청크(Chunk)를 필터링하여 전달하므로, 입력 토큰이 적음
• Agentic Search는 여러 번의 grep / read를 거쳐 정보를 수집하므로, 입력 토큰이 많음

제가 실측한 범위 내에서, 동일한 사내 QA 코드 검색 태스크의 결과는 다음과 같습니다.

응답 시간과 토큰은 2~3배 증가하지만, 정답률은 68%에서 84%로 올라갔습니다. 코드베이스의 규모가 중규모(수천 파일 이하)라면 이 트레이드오프(Trade-off)는 서로 상쇄된다고 느낍니다.

반대로 수십만 건의 문서를 찾아야 하는 지식 Bot이라면, Agentic Search는 현실적인 토큰량을 초과합니다. "코드 검색은 Agentic Search, 대규모 문서 검색은 RAG"가 2026년 5월 시점의 저의 구분법입니다.

토큰 소비의 증가는 Claude Code 1M context GA(2026년 3월 Opus 4.6/Sonnet 4.6에서 정식 이용 가능)로 인해 실무상의 영향이 한 단계 낮아졌습니다. 중규모 리포지토리라면 디렉토리 단위로 Read를 해도 context에 들어옵니다. 비용 측면에서는 prompt caching으로 히트율을 높이는 기법이 정착되어, 반복해서 읽히는 파일은 거의 캐시 가격으로 해결할 수 있게 되었습니다. Agentic Search의 「토큰을 너무 많이 사용한다」는 약점은 에코시스템 전체의 진화로 흡수되고 있습니다.

RAG vs Agentic Search의 이분법적 대립으로 끝나지 않는 것이 최근의 흐름입니다. LangChain, LlamaIndex, Anthropic 스스로도 Agentic RAG라는 용어를 사용하기 시작했습니다.

Agentic RAG:
쿼리 → 에이전트가 판단
├── 벡터 검색이 적절한가? → RAG
...

「최적의 검색 수단을 에이전트가 선택한다」는 것이 핵심이며, 인간이 "이것은 RAG, 저것은 grep"이라고 미리 단정 지을 필요가 없게 됩니다. 저희 팀은 사내 QA를 이것으로 전환하는 검증을 진행 중이며, 코드 관련 질문은 내부적으로 Agentic Search, 운영 문서 질문은 RAG를 자동으로 분류하는 구성으로 하고 있습니다.

마지막으로, Boris Cherny 씨의 인터뷰에서 가장 와닿았던 한마디를 소개합니다.

" "

로 충분하지 않을까?

저는 이 말을 들은 이후로, 사내의 RAG 제안 리뷰에서 가장 먼저 이 질문을 던지곤 합니다.

• 지식(Knowledge)이 코드베이스 내에 있는가? → grep/glob으로 충분할 수도 있음 - 파일 수가 수천 개 이하인가? → 위와 동일
• 의미적으로 유사한 것을 찾아낼 필요가 있는가? → 여기서부터 비로소 RAG - 다국어 의미 검색(Semantic Search)이 필요한가? → RAG
• PDF/이미지 등 비정형 데이터(Unstructured Data)의 교차 검색인가? → RAG

"LLM의 컨텍스트 윈도우(Context Window)가 100K에서 1M로 확장된 지금, 전부 집어넣기로 해결 가능한 규모가 늘어났다"는 점도 배경입니다. 반년 전이라면 "이것은 RAG로 해야 합니다"라고 즉답했을 규모감이, 지금은 "아니, 이건 전부 읽게 해도 들어갑니다"로 바뀌었습니다.

Claude Code의 에이전틱 서치(Agentic Search)를 사용하며 알게 된 세 가지 차이점입니다.

• 정확도(Precision): 임베딩(Embedding)의 퍼지 매칭(Fuzzy Match)이 사라지고, 핀포인트로 놓치는 부분 없이 찾아냄
• 최신성(Freshness): 인덱스 재구축(Index Rebuilding) 과정이 사라지고, 최신 파일이 그대로 검색 대상이 됨
• 개인정보 보호(Privacy): 임베딩 목적의 외부 API 사용이 사라져, 사내 도입 장벽이 낮아짐

"RAG는 이제 구식이다"라고 할 만큼 단순한 문제는 아니지만, 코드 검색이라는 특정 용도에서는 에이전틱 서치(Agentic Search)가 명확하게 승리합니다. 제가 반년에 걸쳐 만든 RAG 파이프라인은 코드 관련 부분을 전부 에이전틱 서치로 교체했습니다. 남은 것은 온보딩 자료와 운영 문서의 검색뿐이며, 그것은 지금도 여전히 RAG 방식입니다.

앞으로 지식 검색(Knowledge Search) 시스템을 구축하려는 분들은, RAG를 도입하기 전에 먼저 grep으로 충분한지를 자문해 보시기 바랍니다. 저의 경우에는 절반 이상이 "grep으로 충분"했습니다.