코드 Q&A 봇, RAG 인덱싱 말고 그냥 에이전트가 grep으로 탐색하게 하는 게 나을까요?
사내 모노레포에 대해 질문하면 답해주는 봇 만들려고 합니다. 전형적으로는 코드를 청크로 쪼개 임베딩해서 벡터DB 넣고 RAG 하는 거잖아요. 근데 요즘은 그냥 에이전트한테 grep/파일읽기 툴 주고 알아서 탐색하게 하는 방식(agentic search)도 많이 보이더라고요.
저희 코드베이스가 그렇게 크진 않습니다(중간 규모, 한 수만 파일?). 어느 쪽이 나을까요? RAG 인덱싱 파이프라인 유지보수가 부담스럽긴 한데, agentic 방식은 매 질문마다 LLM 호출이 많아져서 느리고 비쌀 것 같기도 하고요. 둘 다 써본 분 의견 궁금합니다.
답변 3개
- 채택된 답변에디터 검증
둘 다 운영해봤는데, 코드 도메인에선 agentic search가 RAG보다 잘 맞는 경우가 많습니다. 이유가 꽤 명확해요.
코드는 의미적 유사도로 청크 뽑는 게 잘 안 먹힙니다. 어떤 함수 정의가 필요할 때 그 정의는 호출부랑 텍스트적으로 안 비슷한 경우가 많고, 임포트 따라가기/콜그래프 추적 같은 건 임베딩 유사도로 절대 안 잡혀요. 반면 에이전트한테 grep, 파일 읽기, 정의 점프 툴 쥐여주면 사람 개발자가 코드 읽듯이 정의 따라가고 레퍼런스 찾아가면서 정확히 필요한 거 끌어옵니다.
그리고 인덱싱 파이프라인 유지보수(코드 바뀔 때마다 재임베딩, 청킹 전략 튜닝)가 통째로 사라지는 게 큽니다. 중간 규모면 ripgrep 한 방이면 충분히 빨라요.
비용/속도 걱정은 이해되는데, 잘 짠 agentic 검색은 의외로 호출 수 많지 않습니다. "키워드 grep → 후보 파일 2~3개 읽기 → 답" 정도면 한 질문에 3~5 스텝이에요. 오히려 RAG가 top-k 잘못 뽑으면 엉뚱한 청크로 자신있게 환각하는데, 그게 디버깅 안 되는 더 비싼 실수입니다.
제가 정착한 형태는 이겁니다: 미시적 탐색은 agentic으로 가되, 자주 묻는 거시 질문("이 서비스 전체 아키텍처", "인증 흐름")용으로 사람이 미리 써둔 요약 문서 몇 장을 컨텍스트에 항상 같이 넣음. 미시 탐색은 에이전트, 거시 지도는 사전 문서. 이 조합이 실전에서 제일 안정적이었습니다.
유지보수 관점만. RAG 인덱싱 파이프라인이 "부담스럽다" 느껴지면 그 직감 보통 맞습니다. 임베딩 모델 버전 바뀌면 재인덱싱, 청킹 전략 바꾸면 재인덱싱, 코드 push마다 동기화... 이게 은근히 ops 부채로 쌓여요.
무엇보다 stale 인덱스로 옛날 코드 답하는 사고가 RAG에선 흔한데(어제 리팩터한 함수를 봇이 옛날 시그니처로 설명함), agentic은 코드가 곧 진실 소스라 구조적으로 그게 없습니다. 항상 최신이에요. 중간 규모면 저는 그냥 agentic 갑니다.
agentic 쪽에 한 표인데 반대 케이스도 짚을게요. 코드베이스가 "중간" 넘어 수십만 파일급 되면 순수 agentic 탐색은 길 잃기 쉽고 스텝이 폭증합니다. 막 grep 헛쳐서 10스텝씩 돌다 컨텍스트 터지는 거 봤어요.
그땐 "어디부터 봐야 하나"를 좁혀주는 인덱스(파일 경로/심볼 인덱스, 꼭 벡터일 필요 없음. ctags 수준도 됨)가 에이전트 1차 길잡이로 유용합니다. 그래서 RAG냐 agentic이냐 이분법보다, 에이전트한테 좋은 탐색 도구를 쥐여주느냐가 본질이라고 봐요. 벡터 검색도 그 도구 중 하나일 뿐이고, 질문자분처럼 중간 규모면 굳이 안 깔아도 됩니다.