실제로 클로드 코드의 시작도 이랬습니다.

클코 창시자 Boris Cherny 왈:
"AI에게 bash 툴을 하나 줬을 뿐이에요.
혼자 파일시스템을 분석하고 읽기 시작했어요."

그리고 아직까지 클로드 코드에는 RAG를 네이티브로 제공하지 않습니다.
그럼에도 매우 강력하죠.
 

파일시스템+Bash 툴의 조합이 RAG의 강점을 어떻게 대체하고 있을까요?

우선 RAG의 단점부터 보겠습니다.

RAG는 벡터DB가 필요하고, 매번 인덱싱을 업데이트해야 합니다. 
여기서 지속적인 비용이 발생합니다.

RAG 기법이 복잡하거나 (chunking, split-and-merge 등) 문서가 많이 수정된다면, 수정 1번에도 인덱싱 비용이 크게 발생합니다. 또한, 문서마다 언제 인덱싱을 업데이트 해야하는지 기준도 애매하고요.

한번 인덱싱한 문서를 다시 수정할 필요가 없는 도메인에서는 유리하지만, 문서 
수정이 잦은 도메인에서는 오히려 지속적으로 비용이 발생합니다.
 

반면 파일 시스템은 그냥 파일을 저장하고 수정하면 됩니다.
파일을 저장하고 수정하는데 드는 비용은 0입니다.

그리고 AI 에이전트는 주어진 bash 툴을 활용해서 
직접 파일을 뒤지고 필요한 컨텍스트 '청크'만을 찾습니다.

RAG의 장점이 딱 필요한 컨텍스트만 가지고 와, 컨텍스트 윈도우를 효율적으로 활용할 수 있다는 점인데,

파일시스템+bash 툴 조합 또한 grep, glob 등의 강력한 검색 명령어 덕분에
수 많은 파일 속에서도 RAG처럼 원하는 청크만 가지고 올 수 있게 되었습니다.

감각적으로 느껴지기로는 임베딩 벡터에 녹아있는 의미맥락을 LLM+bash 툴의 조합이 대체하는 느낌입니다.

 

저도 한때는 컨텍스트 효율성을 위해서는 RAG가 필수라고 생각했었습니다.
컨텍스트 윈도우가 늘어나면서 RAG가 사라질 것이라는 시각 속에서도 여전히 필요하다는 생각이었습니다만, 점점 시스템이 복잡해지고 무거워진다고 느꼈습니다.

그러는 와중에 파일시스템과 bash 툴이 주는 간단함과 강력함을 보고,
앞으로는 RAG의 위상이 많이 떨어질 수 있겠다는 생각을 합니다.

더 나아가 어떻게 RAG 없이 구축할 수 있을까를 고민해보자면,
자신의 에이전트가 쉽게 "읽을 줄 아는" 구조로 데이터 레이어를 설계하는 게 핵심인 것 같습니다. 

예를 들면, supabase를 쓰더라도 pgvector로 벡터 데이터를 저장하기보다는, 
postgre가 가진 검색 기능을 tool로 만들어 제공하는 방향으로, 
일종의 supabase용 bash를 만드는거죠.

현재 쏘타의 기본적인 컨텍스트 엔지니어링도 이를 기반으로 고민하고 있습니다.

이번 포스팅에는 아래 논문도 참고가 되었습니다. 참고하시면 좋을거 같습니다.

https://arxiv.org/pdf/2512.05470

맺는 말

여러분들은 어떻게 생각하시나요? 
어떻게 파일시스템과 같은 구조를 설계할 수 있을지, RAG를 어떻게 함께 활용하면 좋을지, 아니면 아직 RAG는 강력하다는 의견 등등 댓글로 의견을 공유해주세요!

끝으로 최근에 저는 openclaw, claude code와 같은 최신 에이전트 시스템의 구조와 설계를 직접 까보고, 역설계를 해보고 있습니다.
더 나아가 이러한 시스템을 쏘타에 재현해보면서 더 쉽고 범용적인 Personal Agentic System을 고민하고 있습니다.

아! 이번에 뉴스레터를 시작합니다! 글이 재밌으셨다면 뉴스레터도 구독해주세요. 가장 빠르게 찾아가겠습니다.
구독하러 가기

종종 뉴스레터를 통해 고민의 과정을 공유드리겠습니다.

항상 건강하시고 읽어주셔서 감사합니다!

이번 주제가 재밌으셨다면, RAG와 파일시스템 주제를 좋아할 분들에게 공유해주세요:)