Claude Code에 시맨틱 코드 검색을 더하면 어떻게 달라지는가
📺 원본 영상: Benchmarking semantic code retrieval on Claude Code — Kuba Rogut, Turbopuffer 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-06-04 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 강연은 서버리스 벡터 검색 데이터베이스 Turbopuffer의 Kuba Rogut이 발표한 짧지만 밀도 높은 엔지니어링 세션이다. 핵심 질문은 단순하다. “Claude Code에 시맨틱 코드 검색(Semantic Code Retrieval)을 붙이면 실제로 얼마나 나아지는가?” 강연자는 단순한 주장에 머무르지 않고, ContextBench라는 공개 벤치마크 프레임워크를 활용해 세 가지 조건을 정량적으로 비교한 실험 결과를 공유한다. 결론은 도구의 효과는 분명히 존재하지만, 시맨틱 검색과 키워드 검색이 각각 잘하는 영역이 다르며, 궁극적으로 두 방식의 조합이 필요하다는 것이다.
Claude Code는 왜 기본적으로 시맨틱 검색을 쓰지 않는가
Claude Code의 탄생 초기로 거슬러 올라가면, 시맨틱 검색은 한 번 시도되었다가 제거된 기능이다. 강연자에 따르면, Claude Code의 사실상 초기 설계를 이끈 Boris(Claude Code의 창시자로 언급됨)가 남긴 트윗에서 이 결정의 이유를 확인할 수 있다. 초기 버전의 Claude Code는 로컬 벡터 DB를 이용한 시맨틱 검색을 실제로 사용했지만, 실험 결과 파일 시스템을 grep으로 탐색하는 “에이전틱 검색(Agentic Search)” 방식이 더 잘 작동한다는 판단이 내려졌다. 복잡한 인프라 없이도 단순하고 직접적이기 때문이다.
이 선택은 합리적이지만, 한계도 분명하다. Grep 기반 탐색은 매 세션마다 동일한 코드베이스를 처음부터 다시 읽어야 하며, 키워드로 표현되지 않는 의미론적 관계를 포착하기 어렵다. 이 한계가 Turbopuffer가 이 문제를 다시 들여다보게 된 출발점이다.
Cursor가 증명한 것: 시맨틱 검색은 실제로 효과가 있다
Turbopuffer의 첫 번째 고객 중 하나인 Cursor는 코드베이스를 Turbopuffer에 인덱싱하여 시맨틱 코드 검색을 적극적으로 활용하고 있다. 이 접근이 단순한 기술적 선택이 아닌 실질적인 성과를 내고 있다는 것은 Cursor가 공개한 블로그 포스트에서 확인할 수 있다.
01:36 - Cursor 블로그 포스트에서 인용한 시맨틱 검색 성능 향상 수치
강연자가 인용한 Cursor의 데이터에 따르면, Composer 모델 기준으로 시맨틱 검색 도입 시 답변 정확도가 약 24% 상대적으로 향상되었으며, 전체 모델 평균으로는 약 12.5~13%의 개선이 있었다. 이 벤치마크는 Composer 2 출시 이전에 수행된 것이므로, 최신 모델에서는 유사하거나 더 높은 수준의 성능 향상이 기대된다는 것이 강연자의 견해다.
더 직접적인 비즈니스 지표로는 온라인 A/B 테스트 결과가 있다. 시맨틱 코드 검색을 허용한 그룹에서 대형 코드베이스의 코드 보존율(code retention)이 2.6% 증가하고, 불만족 사용자 요청이 2.2% 감소했다. 강연자는 이 숫자가 작아 보일 수 있다는 점을 먼저 인정하면서도, 모든 쿼리가 시맨틱 검색의 혜택을 받는 것이 아니라는 점에서 이 수치의 의미를 재해석한다. 단순한 쿼리나 간단한 도구 호출은 시맨틱 검색이 필요 없으므로, 실제로 시맨틱 검색이 유효한 쿼리 집합에서의 효과는 이보다 훨씬 클 수 있다는 것이다.
01:57 - Cursor의 온라인 A/B 테스트 결과
임베딩은 캐시된 연산이다
강연자가 제시하는 시맨틱 검색의 핵심 가치는 성능 향상만이 아니다. 그가 사용하는 표현은 “임베딩은 캐시된 연산(Embeddings are cached compute)“이다.
03:02 - 에이전틱 grep 방식과 시맨틱 검색 방식의 토큰 흐름 비교
이 비교를 구체적으로 풀어보면 이렇다. Grep 기반의 에이전틱 검색은 파일 시스템을 탐색하고, 파일을 읽고, 다시 grep을 수행하는 과정을 매 세션마다 반복한다. 동일한 코드베이스에서 동일한 질문을 하더라도 이 연산은 다시 처음부터 수행된다. 강연자가 예시로 든 경우, 한 번의 탐색에서 약 6,000 토큰이 소모되는데, 이것이 여러 에이전트와 여러 세션에 걸쳐 누적되면 상당한 비용이 된다.
반면 시맨틱 검색 방식은 초기에 코드베이스를 청크(chunk)하고 임베딩하여 인덱싱하는 비용이 발생하지만, 이후 쿼리는 이 캐시된 의미 표현(semantic representation)에 대한 빠른 벡터 검색으로 처리된다. 현재처럼 여러 에이전트를 동시에 실행하는 환경에서는 이 차이가 장기적으로 의미 있는 절감으로 이어진다는 것이 강연자의 주장이다.
TurboGrep: Claude Code를 위한 시맨틱 검색 도구
이 배경 위에서 Turbopuffer가 만든 것이 TurboGrep이라는 CLI 도구다. 작동 방식은 다음과 같다. 먼저 tree-sitter 기반의 코드 분할 라이브러리를 사용해 코드베이스를 파싱하고 청크로 나눈다. 그 다음 Voyage AI의 Voyage Code 3 임베딩 모델을 사용해 각 청크를 임베딩하고, 이를 Turbopuffer에 업로드한다. 이후 Claude Code는 tpuf_search라는 도구 호출을 통해 벡터 검색을 수행할 수 있게 된다.
강연자는 Django 레포지토리를 대상으로 한 도구 호출 트레이스 예시를 영상에서 보여주는데, Claude Code가 tpuf_search_password_reset_token_generator와 같은 형태로 TurboGrep을 호출하고, 검색 결과를 바탕으로 전체 설명을 생성하는 흐름을 확인할 수 있다. v1 버전은 이미 오픈소스로 공개되어 있으며, v2 버전도 곧 오픈소스로 출시될 예정이라고 한다.
벤치마킹 방법론: ContextBench
“이게 더 잘 작동한다”고 말하는 것은 쉽다. 실제로 얼마나 잘 작동하는지 측정하는 것이 중요하다. 강연자는 Cursor가 내부적으로 사용하는 벤치마크와 유사한 개념의 공개 논문인 ContextBench를 기준으로 실험을 설계했다.
ContextBench의 철학은 독특하다. 코딩 에이전트가 최종적으로 문제를 풀었는지 여부만을 평가하는 것이 아니라, 문제를 풀어가는 과정에서 어떤 파일을 찾았는지, 어떤 라인을 읽었는지, 어떤 심볼(symbol)을 참조했는지를 측정한다. 이 벤치마크는 “어떻게 거기에 도달하느냐도 중요하다”는 테제를 갖고 있으며, 에이전트가 실제로 올바른 파일을 찾고 있는지를 인간이 레이블링한 데이터셋을 기반으로 평가한다. 즉, 특정 태스크를 완료하기 위해 에이전트가 반드시 참조했어야 하는 파일, 라인, 심볼의 집합이 정답으로 정의되어 있다.
강연자는 세 가지 실험 조건을 설정했다.
- 기본 Claude Code (아무 수정 없음)
- Claude Code + 최대 50라인 제한 Windowed Read (긴 파일 읽기로 인한 노이즈 제거 목적)
- Windowed Read + TPUF 시맨틱 검색 도구 추가
50라인 제한을 둔 이유는 명확하다. 에이전트가 1,000라인짜리 파일 전체를 읽어버리면 모든 조건에서 점수가 비슷해져 도구 간 차이를 측정하기 어렵기 때문이다. 실험은 50개 태스크를 대상으로 수행되었다.
벤치마킹 결과 1: Precision
Precision은 에이전트가 읽은 파일 중 실제로 필요한(golden) 파일의 비율이다. 예를 들어 에이전트가 10개의 파일을 읽었고 그 중 8개가 골든 파일이라면 Precision은 80%다.
06:42 - 세 조건의 파일 Precision 비교
결과를 직접적인 언어로 번역하면 이렇다. 기본 Claude Code는 파일 Precision이 약 65%였는데, 이는 세 번에 한 번꼴로 불필요한 파일을 읽고 있다는 뜻이다. Windowed Grep을 적용하면 다섯 번에 한 번꼴로 줄어들고, 여기에 시맨틱 검색까지 추가하면 여덟 번에 한 번꼴, 즉 파일 Precision이 약 87%까지 향상된다. 라인 Precision은 기본값 33%에서 출발하고, 심볼 Precision은 43%에서 출발한다. 이 두 지표 역시 도구를 추가할수록 개선되는 추세를 보인다.
강연자는 이 결과가 Claude Code의 기본 탐색 성향을 반영한다고 분석한다. Claude Code는 기본적으로 매우 탐색적(exploratory)이어서 최대한 많은 파일을 읽으려는 경향이 있고, 그것이 65%라는 Precision 수치로 나타난다는 것이다.
벤치마킹 결과 2: Recall과 그 복잡성
Recall은 태스크에 필요한 파일 중 에이전트가 실제로 찾아낸 비율이다. 10개의 골든 파일 중 5개를 찾았다면 Recall은 50%다.
흥미롭게도 파일 Recall에서는 기본 Claude Code가 가장 높은 수치를 보인다. 이 역시 탐색적 성향 때문으로, 많은 파일을 읽다 보니 우연히 필요한 파일도 더 많이 포함시키게 된다. 그러나 라인 Recall로 가면 이 이점이 급격히 사라진다. 많은 파일을 읽었지만, 그 파일들에 골든 컨텍스트 라인이 별로 없었다는 의미다. 다시 말해 많이 읽었지만 엉뚱한 것을 많이 읽은 셈이다.
07:51 - 파일 Recall 및 라인 Recall 비교 결과
한편 Windowed Grep과 Windowed Grep + 시맨틱 검색 조건에서는 Recall이 비슷한 수준을 보인다. 시맨틱 검색이 일부 태스크에서는 오히려 Recall을 낮추는 경우도 있었는데, 강연자는 이를 50개 태스크를 시맨틱 검색이 우세한 그룹과 Grep이 우세한 그룹으로 분리해 분석함으로써 설명한다. 특정 태스크에서는 시맨틱 검색이 압도적으로 좋고, 다른 태스크에서는 키워드 검색이 훨씬 낫다는 것이다.
08:37 - 시맨틱 검색 우세 / Grep 우세 그룹으로 분리한 세부 Recall 비교
시맨틱 검색이 이기는 경우, Grep이 이기는 경우
이 분석은 강연의 핵심 인사이트 중 하나다. 두 검색 방식은 서로 다른 종류의 문제에 강점을 보인다.
시맨틱 검색이 유리한 상황은 동일한 키워드를 공유하지 않지만 의미론적으로 연관된 파일들을 찾아야 할 때다. 강연자가 든 예시는 다양한 ORM(Object-Relational Mapping) 라이브러리에 걸쳐 있는 코드를 찾는 태스크였다. 각 라이브러리는 서로 다른 키워드를 사용하지만 “비슷한 동작을 하는 코드”라는 의미론적 공통점이 있고, 시맨틱 검색은 이 관계를 포착할 수 있다.
반면 Grep이 유리한 상황은 임포트(import) 경로를 추적하거나 명확한 식별자가 있는 코드를 찾을 때다. 첫 번째 또는 두 번째 도구 호출에서 키워드가 맞아떨어지면, Grep은 이후의 탐색을 매우 효율적으로 수행할 수 있다.
이 두 방식의 강점이 다르다는 사실은 단순한 관찰을 넘어 설계 원칙으로 이어진다. 코드 검색 도구는 어느 하나만을 선택하는 것이 아니라 두 가지를 상황에 맞게 조합하는 방향으로 발전해야 한다.
Q&A: 실무적 맥락에서의 추가 논의
강연 이후 청중과의 질의응답에서 몇 가지 실질적인 주제가 다뤄졌다.
코드 품질과 시맨틱 검색의 관계. 한 청중이 “엉망인 코드(shit code)“에서는 어떤 방식이 더 잘 작동하는지 물었다. 강연자는 시맨틱 검색은 코드에 주석이 잘 달려 있을수록 효과가 좋다고 답했다. 임베딩 모델이 청크의 의미를 파악하는 데 주석이 핵심적인 역할을 한다는 것이다. 단순히 함수 바디만 있는 코드보다 설명 주석이 붙어 있는 코드가 임베딩 품질이 훨씬 높고, 이것이 검색 성능으로 직결된다.
쿼리-문서 간 형식 불일치 문제. 또 다른 청중은 시맨틱 검색의 근본적인 한계인 쿼리와 인덱싱된 데이터 간의 형식 차이를 지적했다. 사람이 “이 기능이 어떻게 작동하나요?”라고 묻는 자연어 쿼리와, 원시 코드 청크 사이의 의미론적 거리가 크다는 것이다. 이를 해결하기 위한 부모-자식(parent-child) 구조(부모는 쿼리 친화적인 설명, 자식은 실제 코드)에 대해 질문했다. 강연자는 자신의 실험에서는 단순한 원시 코드만 사용했다고 솔직하게 밝히면서도, Cursor가 이 문제를 자체 임베딩 모델로 해결하고 있을 것이라고 추측했다. 한 청중은 Cursor가 실제로 코드 위에 가상의 주석(fake comments)을 생성한 뒤 코드와 함께 임베딩하는 방식을 사용한다고 언급했다.
벡터 DB vs. 로컬 Grep. 벡터 DB를 굳이 써야 하는 상황에 대한 질문에 강연자는 다음과 같이 정리했다. 로컬 파일 시스템을 grep으로 탐색하는 것은 비용이 없고 단순하기 때문에 많은 상황에서 충분히 좋다. 그러나 노션(Notion)과 같은 지식 베이스, 멀티모달 데이터(이미지, 오디오, 비디오 파일)는 grep이 구조적으로 적합하지 않다. 이런 데이터를 에이전트가 의미론적으로 탐색해야 할 때, 벡터 DB가 의미를 캐시해두는 방식이 실질적인 가치를 가진다는 것이다.
마무리: 더 작고 스마트한 컨텍스트 창을 향해
강연자는 마지막으로 자신이 생각하는 장기적인 방향을 제시했다. 무한정 파일 시스템을 grep해서 방대한 컨텍스트를 집어넣는 방식은 한계가 있다. 승자는 수십억 토큰의 컨텍스트를 수백만 개의 정확한 토큰으로 압축하는 경량 도구들을 제공하는 사람들이 될 것이라는 것이다.
이 주장의 핵심은 단순함과 다양성의 균형이다. 시맨틱 검색 하나가 모든 것을 해결하지도 않고, Grep만으로도 충분하지 않다. 서로 다른 방식으로 서로 다른 종류의 정보를 찾는 도구들이 협력할 때, 에이전트는 더 정확하고 효율적으로 작동할 수 있다. Turbopuffer의 TurboGrep은 그 한 가지 시도이며, 이 영역에서의 더 많은 실험과 공개적인 벤치마킹이 필요하다는 메시지로 강연은 마무리된다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Benchmarking semantic code retrieval on Claude Code — Kuba Rogut, Turbopuffer |
| 채널 | AI Engineer |
| 발표자 | Kuba Rogut (Turbopuffer) |
| 리포트 작성 | 2026-06-04 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.