RAG 실전 ⑩ — 코드베이스 RAG: grep과 임베딩은 대체재가 아니라 보완재다

코드 검색은 문서 RAG와 규칙이 다르다 — 그리고 2025~26년, 업계 최전선에서 두 노선이 정면으로 경쟁 중이다.

노선 1: 인덱스 없는 agentic grep

Claude Code의 공식 입장(Agent SDK 블로그): 임베딩 인덱스 없이 grep/glob 기반 탐색으로 시작하라 — "시맨틱 검색은 보통 더 빠르지만 덜 정확하고, 유지보수가 어렵고, 불투명하다." Cline은 한발 더 나가 no-index 선언(인덱스 부패, 청킹이 코드 논리를 찢는 문제, IP 복제 리스크). 소규모 리포나 빠르게 변하는 코드라면 이쪽이 기본값.

노선 2: 임베딩 인덱스 — Cursor의 반론

Cursor 실측: grep만 쓰는 에이전트 대비 시맨틱 검색 추가로 정답 정확도 평균 +12.5%(1,000+ 파일 대형 코드베이스에서 효과 최대), 온라인 A/B에서 코드 유지율 +2.6%. 인프라 설계도 공개돼 있다 — Merkle 트리 해시 비교로 ~10분마다 변경 파일만 재임베딩, 서버에는 임베딩+난독화 경로만 저장(평문 코드 미보관). Milvus 쪽 반박도 흥미롭다: grep은 "500줄의 노이즈"를 컨텍스트에 쏟아붓는 토큰 블로트 — 같은 디버깅 시나리오에서 벡터 검색이 토큰 40%+ 절감. 임베딩 도입의 실질 근거는 정확도보다 토큰 비용일 수 있다.

어느 쪽이든 지켜야 할 규칙

• 청킹은 AST 경계로 — 문서 RAG의 "512토큰 고정"을 코드에 쓰면 함수가 반토막 난다. cAST(CMU): tree-sitter AST의 split-then-merge 청킹으로 RepoEval Recall@5 +4.3pt, SWE-bench Pass@1 +2.67pt — 청킹만 바꿔도 검색·생성이 둘 다 오른다. 구현은 Chonkie CodeChunker(165+ 언어) 또는 LlamaIndex CodeSplitter 한 줄.
• 범용 임베딩은 코드에서 진다 — CoIR 벤치마크: Qodo-Embed-1-1.5B(68.53)가 OpenAI text-embedding-3-large(65.17)를 이긴다. API면 voyage-code-4(2026-08, 코드 검색 28개 데이터셋에서 경쟁사 대비 +16~19%), 자가호스팅이면 Qwen3-Embedding-4B(MTEB-Code 81.20 — 8B와 0.02 차이라 4B가 코스파 최적). 코드 임베딩 선택은 MTEB 종합이 아니라 CoIR/MTEB-Code 점수로.
• 제3의 선택지: 심볼 인덱스 — 임베딩도 grep도 아닌 AST/LSP 기반 심볼 검색. AWS Kiro 한국어 해설의 수치가 명쾌하다: grep은 StringUtils.isEmpty()를 69개 파일 379건으로 쏟아내지만 심볼 검색은 정의 위치만 짚는다. 한국 실전기로는 여기어때의 ts-morph AST 청킹 코드 RAG가 "우리도 할 수 있는 규모"의 레퍼런스다.

한 줄 요약: 작은 리포는 grep 든 에이전트로 시작하고, 1,000+ 파일이거나 토큰 비용이 아플 때 AST 청킹 + 코드 특화 임베딩을 "추가"하라 — 대체가 아니라 보완이다.

— RAG 실전 시리즈 ⑩ / 다음 글(완결): 운영 — 모든 계층에 캐시를, 모든 스팬에 트레이스를