영상 링크: Why the Best AI Coding Tools Abandoned RAG (And What They Use Instead)
채널명: Cole Medin
최고의 AI 코딩 도구들이 RAG를 버린 이유와 이들이 대신 사용하는 전략 핵심 요약
- 최근 인터넷에서 “RAG(검색 증강 생성, Retrieval Augmented Generation)는 죽었다”는 말이 많이 회자되지만, 이는 일부 코딩 분야에서만 해당되는 사실임
- RAG의 전통적 형태(문서 청킹 후 벡터 DB에 임베딩하는 방식)는 구조화된 데이터(코드)에는 덜 필요하지만, 대부분의 비정형 데이터 환경에서는 여전히 필수적임
- 코드베이스처럼 데이터 구조가 명확한 환경에서는 에이전트가 직접 파일 구조 탐색, 키워드/정규식 검색 등 기존 도구만으로 충분히 효과적임
- 대표적인 AI 코딩 에이전트(예: Claude Code, Archan, Aider 등)는 전통적 RAG를 버리고, OS 내장 검색 툴과 파일 탐색을 결합한 ‘에이전틱 검색’으로 전환함
- 전통적 RAG가 코드 환경에서 불필요한 오버엔지니어링이라는 인식도 확산되고 있음(“RAG 내러티브는 마인드 바이러스”라는 표현 인용)
- 하지만, 고객지원, 컴플라이언스, 법률문서 등 비정형 대규모 데이터베이스에서는 동의어나 개념 유사성 검색이 반드시 필요해 여전히 RAG가 핵심 전략임
- 대형 문서 셋에서는 RAG로 문서를 청크 단위로 관리하면 검색 속도/비용 측면에서 비약적인 효율(최대 100배 절감)이 있음
- 앞으로는 AI 에이전트가 쿼리 상황에 따라 RAG와 기타 검색 전략(예: 정규식, 파일 탐색 등)을 동적으로 선택하는 ‘지능적 혼합 검색’ 방향성이 주목받음
- 결론적으로, 코드등 구조화된 환경에서는 전통적 RAG는 사실상 사망, 그 외 거의 모든 실무환경에서는 여전히 중요한 역할을 수행함
세부 요약 - 주제별 정리
인터넷에 확산된 “RAG는 죽었다”는 내러티브는 코드 분야에만 국한된 절반의 진실임
- 최근 LinkedIn, X(Twitter) 등에서 ‘RAG는 죽었다’라는 담론이 다수 등장함
- 발표자는 과거 매주 RAG 관련 콘텐츠를 제작했으나, 최근 들어 해당 주제의 비중이 줄어든 것에 대해 언급
- 실상은 일부 에이전트(특히 코딩 에이전트)의 특정 사례에 한정되며, 전체 AI 활용 사례로 확대해석 되기 어려움
- ‘RAG’의 의미 자체가 폭넓게 사용되어 혼동이 생김(전통적 의미와 확장적 의미 구분 필요)
- 전통적 RAG: 문서를 청크로 나눠 벡터 DB에 임베딩, 의미 유사성에 기반해 검색
- 확장적 RAG: LLM이 외부정보를 컨텍스트로 받아 증강하는 모든 검색 방식
- 코드 분야(구조적 데이터)에선 전통적 RAG가 대체되는 경향, 그러나 기타 비정형 데이터 분야에선 여전히 필수적임을 강조
RAG의 필요성은 데이터의 구조화 정도에 따라 완전히 달라짐
- 코드는 함수명, 식별자 등 규칙적으로 구성된 데이터이기 때문에 ‘정확 검색’ 기반 도구로 충분히 탐색 가능
- 구글 드라이브, SharePoint, SQL DB 등의 대규모 내부 문서(비정형 데이터)에는 유사어, 개념 연관성 등 의미기반 탐색이 필요
- 이때 임베딩 모델과 벡터 DB 기반 전통적 RAG가 강력하게 요구됨
- 숫자 기반, 구조화가 잘된 데이터의 경우 에이전트가 내장 탐색 도구만으로도 충분(특허번호, 파일패스 등)
코드베이스에서 전통적 RAG의 효용이 거의 사라진 이유를 구체적으로 설명함
- 코드베이스는 변수/함수명, 문법, 파일구조 등 체계적으로 구성되어 모든 항목이 ‘정확히’ 존재함
- 오타가 있다면 아예 코드가 동작하지 않으므로, 실제 배포된 코드는 오타 없이 완전한 구조를 가짐
- 키워드, 정규표현식, 파일 네비게이션 도구(grep, ripgrep, glob 등)을 이용해 빠르고 효과적으로 원하는 코드를 탐색 가능
- 코드 탐색 과정에서 비정형 자연어, 유사개념 추론 등의 요소가 필요치 않으므로, 의미 기반 임베딩·벡터DB는 불필요하게 됨
- 오로지 전통적 RAG(벡터 DB 인덱싱) 없이 단순 탐색 도구 및 파일구조만으로도 에이전트가 충분히 동작
코드 에이전트들은 OS 내장 검색 및 파일탐색 도구를 활용하는 ‘에이전틱 검색’을 채택함
- 대표적 코딩 에이전트(AI Assistant)는 ripgrep, glob 등 OS 터미널 도구를 주요 탐색 수단으로 채택
- 실제 운영에서 벡터 DB를 통한 인덱싱, 임베딩 검색 없이 파일 탐색 명령어(예: cat, sed, grep 등 쉘 명령어)만으로 성능이 확보됨
- 검색 파이프라인(RAG 인덱싱) 유지의 부담과 코드베이스 변경 동기화의 어려움도 해결됨
- Archan, Claude Code 등은 실제로 전통적 RAG에서 이런 방식으로 전환(또는 처음부터 인덱싱 미도입)했고, 이로 인해 유지·성능 모두 개선
코드베이스 인덱싱은 유지보수가 어렵고, 코드 변경이 빈번해 실효성이 떨어짐
- 코드는 빈번히 수정되어 벡터 DB 인덱스와 동기화가 어려움
- 전통적 문서(서류, 가이드 문서) 등은 날마다 변동이 거의 없지만, 코드는 커밋/PR 등으로 수시로 구조가 바뀜
- 인덱싱 파이프라인 구축, 관리, 싱크 유지는 코딩 에이전트의 오버엔지니어링 요소로 지적됨
업계의 주요 코딩 에이전트들이 전통적 RAG를 버린 실제 사례와 인용을 소개
- Claude Code (Boris Churnney)
- 초창기엔 로컬 벡터 DB 기반 RAG 도입, 곧 ‘에이전틱 검색’(터미널 탐색툴 활용)이 더 효과적이라 전환
- 실제 데모에서 cat, sed, grep 등 OS 명령만으로 에러 응답 코드 흐름 분석, 임베딩·벡터 DB 없이 최적 결과 도출
- Nick Pash (Klein 창시자)
- ‘Autonomous coding agents에 RAG 비추천’ 기사에서 “RAG 내러티브는 마인드 바이러스”라 극단적 표현
- 2023~2024년 ‘모든 에이전트는 전통적 RAG 필수’라는 분위기를 비판, 불필요한 오버엔지니어링 주장
- Aider
- Tree-sitter를 통해 코드베이스의 파일/클래스/함수 리스트를 시스템 프롬프트에 정의, 전체 구조를 한눈에 제공
- 벡터 인덱스가 아닌, 파일구조 및 상위(overview)만 전달, 탐색 효율 극대화
- 자체 경험(Archon 개발 경험)에서도 RAG는 오히려 LLM의 혼란만 야기함을 체감
코드 외 대부분의 실무 도메인은 여전히 RAG가 필수임을 강조함
- 비정형 데이터는 고객지원, 법률, 교육, 내부 지식베이스 등 광범위한 영역에 존재
- 이 영역에서는 정규식이나 파일명, 키워드만으로는 의미적 유사성 혹은 동의어를 반영하지 못해 전통적 RAG가 유일한 해법
- 특히 수십/수백만 문서 단위의 검색에서는 의미 기반 유사성 검색이 없어서는 안 됨
RAG 파이프라인 유지·운영에는 부담이 있지만, 대용량 문서셋에서 압도적 비용·속도 이점이 있음
- 청킹, 임베딩, 벡터 DB 구축 등 RAG 운영에 부가 비용이 추가되나, 문서 단위 검색보다는 월등히 효율적임
- 대용량 DB에서 필요한 작은 정보(chunk)만 추출해 LLM에 넣으면 검색비용이 최대 100배까지 절감(거친 추산임)
- 소규모 DB에는 오히려 파이프라인 유지비가 비효율성 유발 가능성이 있으나, 대규모 확장시엔 필수로 자리 잡음
코드 환경에서 임베딩 없는 탐색은 유효하지만, 대형 비정형 데이터셋에는 실질적으로 불가능함
- cat, grep, sed 등 명령은 소규모/구조화 데이터엔 강력하지만, 수십만 문서의 비정형 텍스트엔 처리가 너무 느리고 비효율적임
- 실질적으로 대규모 지식베이스 검색/탐색엔 “청크 기반 RAG”가 유일한 방법임을 예시로 설명
기존 RAG와 검색 툴 방식을 AI 에이전트가 상황에 따라 동적으로 선택하는 ‘스마트 혼합 검색’이 차세대 트렌드임
- 쿼리 종류나 지식베이스 상황에 따라 RAG 혹은 기타 빠른 탐색 툴 양쪽 경로 모두를 AI 에이전트에게 개방
- 예: 정규식, 키워드 탐색이 정답일 때는 ‘비전통적 RAG 도구’에, 의미 기반 유사성 필요한 케이스엔 임베딩RAG로 자동 분기
- 최근 LLM 및 harness 기술 진화로 이런 혼합·분기 전략이 점차 현업화되는 사례 증가
결론적으로, 전통적 RAG는 코딩 분야에선 소멸했으나 대다수 비정형 데이터 활용엔 여전히 대체 불가능함
- 코드처럼 완벽히 구조화된 환경에선 에이전틱 검색, 파일탐색, 정규식, tree-sitter 등 새로운 전략이 우위
- 그 밖의 비정형, 대규모 문서·지식베이스 환경에서는 기존 RAG 파이프라인이 필수적 위치에 있음
- 향후엔, AI에이전트가 양쪽 방법론을 적절히 혼합해 상황별 최적의 검색 경로를 선택하는 방향이 주류가 될 전망임