코딩 에이전트에 벡터 검색을 붙이기 전에 fix 커밋 다섯 개로 비교 평가부터 만듭니다, Braintrust 실험에서는 정답률은 같고 비용만 4배였습니다 | DAKER 커뮤니티

코딩 에이전트에 벡터 검색을 붙이면 버그를 더 잘 찾습니까? Braintrust의 개발자 애드버킷 Jess Wang이 직접 돌려 본 평가에서는 답이 예상과 달랐습니다. 같은 Claude Code 하네스로 버그 위치 찾기 과제를 풀게 했더니, 파일을 열고 함수 호출을 따라가는 에이전트형 검색과 임베딩 기반 벡터 검색의 정답률은 같았습니다. 차이는 비용에서 났습니다. 벡터 검색 쪽이 약 4배 비쌌습니다. AI Engineer 채널이 10월 5일 공개한 약 18분짜리 발표 Agentic Search vs Vector Search for Coding Agents: We Ran the Eval — Braintrust는 이 결과보다 그 결과를 얻은 방법이 더 쓸모 있는 영상입니다. 해커톤에서 코딩 에이전트나 RAG를 쓰는 참가자가 오늘 가져갈 행동은 하나입니다. 내 저장소에서 이미 고친 fix 커밋 몇 개를 골라, 검색 방식을 바꾸기 전에 비교할 수 있는 작은 평가 세트부터 만드는 것입니다.

나무 책상 위에 빨간 실로 이어진 인쇄 문서 다섯 장과 돋보기, 흩어진 종이 뭉치를 찍은 실사풍 생성 이미지와 제목 문구 정답률은 같고 비용은 4배, 검색 방식도 평가로 고릅니다, Braintrust 공식 로고
설명용 생성 이미지입니다.

Braintrust 발표가 실제로 보여 준 실험

발표는 AI Engineer World's Fair 2026에서 녹화됐습니다. Jess Wang은 평가가 무엇인지 설명한 뒤, 회사 CEO가 보내 준 Cursor의 시맨틱 검색 관련 게시물을 계기로 실험을 설계했다고 말합니다. 질문은 단순했습니다. 코딩 에이전트가 버그가 있는 코드를 찾을 때, 사람처럼 파일을 하나씩 읽어 가는 방식과 의미가 비슷한 코드 조각을 벡터 데이터베이스에서 꺼내 오는 방식 중 어느 쪽이 나은가입니다.

두 방식의 차이도 발표에서 짧게 정리합니다. 벡터 검색은 코드나 텍스트를 임베딩으로 바꿔 Qdrant나 Pinecone 같은 벡터 데이터베이스에 저장해 두고, 질문과 의미가 가까운 조각을 돌려줍니다. 에이전트형 검색은 LLM에게 grep, find, ls, cat 같은 명령을 주고, 함수 이름을 찾고 파일을 열고 호출을 따라 다른 파일로 넘어가게 합니다. Jess Wang은 후자를 사람이 코드베이스를 읽는 방식에 가깝다고 설명합니다.

평가 세트는 Microsoft의 오픈소스 저장소 microsoft/typescript-go에서 만들었습니다. 제목에 fix가 들어간 머지된 PR을 모은 뒤, 각 PR의 부모 커밋, 곧 버그가 아직 남아 있는 시점으로 되돌렸습니다. 그리고 버그 코드와 수정 코드의 차이를 바탕으로 Claude가 이슈 형식의 버그 과제를 쓰게 했습니다. 에이전트는 이 과제만 보고 버그가 있는 위치를 찾아야 합니다. 발표자는 약 20개의 PR로 평가를 돌렸다고 밝힙니다.

채점은 저장소가 이미 갖고 있는 테스트 스위트에 맡겼습니다. 테스트를 통과하면 100%, 실패하면 0%인 이진 채점입니다. 정답 코드를 사람이 하나하나 비교하지 않아도 되므로, 작은 팀도 따라 할 수 있는 구조입니다.

벡터 검색만 쓰게 만드는 데 필요했던 두 가지 장치

에이전트형 검색 쪽은 준비가 쉬웠습니다. 발표자 설명대로 Claude Code는 기본적으로 에이전트형 검색을 쓰기 때문에, 과제를 그대로 맡기면 됐습니다. 어려운 쪽은 벡터 검색이었습니다. 실험 조건을 맞추려고 같은 Claude Code 하네스 안에서 벡터 검색을 돌려야 했는데, 그대로 두면 Claude Code가 습관처럼 grep으로 돌아갔기 때문입니다.

그래서 두 가지를 함께 썼습니다. 먼저 프롬프트에 에이전트형 검색을 쓰지 말라고 명시했습니다. 하지만 Jess Wang은 프롬프트만으로는 절대 충분하지 않다고 말합니다. 그래서 Claude Code의 허용하지 않을 도구 목록 플래그로 에이전트형 검색에 쓰이는 도구 호출 자체를 막았습니다.

지시문으로 금지하는 것과 도구 목록에서 빼는 것은 다른 일입니다. 비교 실험이라면 도구 단계에서 막아야 조건이 섞이지 않습니다.

Claude Code 공식 CLI 문서에 따르면 --disallowedTools에 도구 이름만 쓰면 그 도구가 Claude의 컨텍스트에서 아예 빠지고, Bash(rm *)처럼 범위를 붙인 규칙은 도구는 남겨 두되 적힌 형태와 일치하는 호출만 거부합니다. 같은 문서의 도구 목록 설명을 보면 macOS, Linux, WSL에서는 Grep 도구가 기본으로 들어 있지 않습니다. 이 환경에서 검색을 막으려면 Grep이라는 이름만 막는 것으로는 부족하고, Bash로 실행되는 grep이나 find 같은 명령까지 범위 규칙으로 막아야 한다는 뜻입니다. 범위 규칙은 적힌 형태와 일치할 때만 작동하므로, 실험이 끝난 뒤 트레이스에서 실제로 막혔는지 확인하는 과정이 꼭 필요합니다.

두 번째 장치는 관측입니다. Claude Code 실행을 하위 프로세스로 돌렸더니 트레이스가 부모와 끊긴 고아 상태가 됐습니다. 상위 트레이스에는 에이전트를 실행했다는 한 줄만 남고, 그 안에서 무슨 명령을 몇 번 불렀는지는 보이지 않았습니다. 해결책은 부모 스팬 ID를 환경 변수로 하위 프로세스에 넘기는 것이었습니다. 이렇게 고친 뒤에는 하위 프로세스 안의 모든 LLM 호출과 grep, bash, ls, find 같은 터미널 명령이 한 트레이스 안에 이어져 보였습니다. 발표자는 이 투명성이 이후 디버깅에 중요했다고 강조합니다.

결과: 정답률은 같고 비용은 약 4배

결과는 한 문장으로 요약됩니다. 벡터 검색과 에이전트형 검색은 같은 정확도를 냈지만, 벡터 검색의 비용이 약 4배 높았습니다. 발표자는 트레이스를 직접 읽으며 원인을 세 가지로 정리합니다.

첫째, 벡터 검색이 돌려준 코드 조각에는 import, 도구 호출, 그 함수를 부르는 위쪽 코드 같은 주변 맥락이 자주 빠져 있었습니다. 조각만으로는 버그를 어떻게 고쳐야 할지 판단할 근거가 부족했습니다. 한 사례에서는 벡터 검색 에이전트가 26번 검색하고도 한 파일 안의 함수 세 개가 서로 어떻게 맞물리는지 끝내 연결하지 못했습니다.

둘째, 에이전트형 검색은 함수 이름으로 grep하고, 함수 전체를 읽고, 논리의 결함을 찾고, 호출하는 쪽을 따라 다른 파일로 넘어갔습니다. Jess Wang은 이 차이를 이렇게 표현합니다.

벡터 검색은 정답 코드 근처까지는 데려다주었지만, 코드 조각 사이의 논리를 잇는 연결 조직은 에이전트형 검색 쪽에 있었습니다.

셋째, 비용 차이는 검색 횟수에서 나왔습니다. 벡터 검색 에이전트는 조각을 받고, 부족하면 다시 검색하고, 또 조각을 받는 과정을 반복했습니다. 그때마다 LLM 호출이 쌓였고, 그 누적이 약 4배의 비용 차이가 됐습니다. 정답률만 보는 평가였다면 두 방식이 같다고 결론 내렸겠지만, 비용을 함께 기록했기 때문에 차이가 드러났습니다.

이 결과를 그대로 일반화하면 안 되는 이유

발표자 스스로 실험의 한계를 분명히 밝힙니다. 과제마다 한 번씩만 돌렸고, LLM은 결정적이지 않으므로 여러 번 반복해야 점수를 더 믿을 수 있습니다. 벡터 검색 구현도 상대적으로 약했다고 인정합니다. 데이터도 약 20개 행에 저장소 하나뿐이었습니다. 발표의 목적은 최고의 평가를 만드는 것이 아니라 평가를 처음부터 끝까지 만드는 흐름을 보여 주는 것이라고 말합니다.

반대 방향의 근거도 있습니다. Cursor는 2025년 11월 6일 공식 블로그 글 Improving agent with semantic search에서 자체 임베딩 모델 기반 시맨틱 검색이 에이전트 성능을 크게 높였다고 발표했습니다. 정답이 정해진 코드베이스 질문으로 구성한 자체 평가 세트 Cursor Context Bench에서 질문 답변 정확도가 평균 12.5% 높아졌고, 모델에 따라 6.5%에서 23.5%까지 차이가 났다고 합니다. 온라인 A/B 테스트에서는 시맨틱 검색이 있을 때 에이전트가 쓴 코드의 유지율이 0.3% 올랐고, 파일이 1,000개 이상인 큰 코드베이스에서는 2.6%까지 올랐다고 밝힙니다. 동시에 Cursor는 에이전트가 grep도 많이 쓰며, 두 방식을 함께 쓸 때 가장 좋은 결과가 나온다고 결론 내립니다.

구분Braintrust 발표 (2026년 10월 공개)Cursor 블로그 (2025년 11월)
비교한 조건벡터 검색만 vs 에이전트형 검색만grep 등 기존 검색 vs 기존 검색 + 시맨틱 검색
평가 데이터typescript-go의 fix PR 약 20개자체 평가 세트 Cursor Context Bench와 온라인 A/B 테스트
채점저장소 테스트 통과 여부정답이 정해진 질문의 정확도, 코드 유지율 등
발표된 결과정확도 동일, 벡터 검색 비용 약 4배정확도 평균 12.5% 향상, 큰 코드베이스에서 효과 확대

두 결과는 서로를 부정하지 않습니다. Braintrust는 벡터 검색만 남기고 에이전트형 검색을 막았고, Cursor는 기존 검색에 시맨틱 검색을 더했습니다. 임베딩 모델의 품질, 코드베이스의 크기, 과제의 종류도 다릅니다. 그래서 이 두 자료에서 얻을 결론은 어느 쪽이 정답이냐가 아니라, 내 저장소와 내 과제로 직접 재 봐야 한다는 것입니다.

평가를 이루는 네 가지와 Braintrust 문서의 정리

Jess Wang은 평가를 네 부분으로 나눕니다. 시스템에 넣을 데이터 세트, 시스템 프롬프트와 모델처럼 입력을 받아 출력을 내는 방식을 정한 과제, 출력이 좋은지 나쁜지 판정하는 채점기, 그리고 이 셋의 조합 하나하나를 뜻하는 실험입니다. 데이터나 프롬프트나 채점 기준 중 하나를 바꿀 때마다 새 실험이 생기고, 실험끼리 비교하면 어떤 행이 좋아지고 나빠졌는지 볼 수 있습니다.

Braintrust 공식 문서 Evaluate systematically도 같은 구조를 세 요소로 정리합니다. 평가할 예시인 데이터, 평가할 동작인 과제, 결과를 판정하는 평가기입니다. 문서는 같은 입력에도 출력이 달라질 수 있고, 한 지표를 높인 변경이 다른 지표를 조용히 떨어뜨릴 수 있다는 점을 AI 시스템이 기존 소프트웨어와 다른 이유로 듭니다. 발표에서도 정확도는 5% 올랐지만 어조 점수는 5% 떨어졌다는 식으로 말할 수 있어야 한다는 예를 듭니다.

몇 개의 프롬프트를 넣어 보니 괜찮았다는 판단은 감으로 출시하는 것입니다. 몇 개의 사례 중 몇 개를 통과했는지로 말할 수 있어야 합니다.

발표자는 평가를 팀 스포츠라고도 부릅니다. AI 엔지니어가 코드를 고치고 데이터를 플랫폼에 넣는 동안, 기획자는 성공이 무엇인지에 대한 가설을 세우고, 해당 분야 전문가는 정답 기준을 라벨링하고, 데이터 분석가는 결과를 읽습니다. 해커톤 팀에 그대로 옮기면 역할 분담표가 됩니다.

해커톤 참가자의 작업 방식은 무엇이 달라지는가

대회에서 코딩 에이전트나 RAG 파이프라인을 쓰는 팀은 검색 방식을 바꾸는 결정을 자주 감으로 내립니다. 벡터 데이터베이스를 붙이면 더 정확해질 것 같고, 청크 크기를 줄이면 더 좋아질 것 같다는 식입니다. 이 발표가 바꾸는 지점은 그 결정을 내리기 전에 비교할 기준을 먼저 만든다는 것입니다.

둘째로, 정답률과 함께 비용과 검색 횟수를 같이 기록하게 됩니다. API 크레딧이 정해진 대회에서는 정확도가 같을 때 4배 비싼 방식을 고르는 것이 곧 실험 횟수를 4분의 1로 줄이는 일이 됩니다. 셋째로, 에이전트를 스크립트에서 하위 프로세스로 돌린다면 트레이스가 끊기지 않았는지부터 확인하게 됩니다. 실패한 실행에서 에이전트가 무엇을 몇 번 검색했는지 보이지 않으면, 결과가 나빠진 이유도 설명할 수 없습니다.

오늘 할 한 가지: fix 커밋 다섯 개로 검색 방식 비교 세트 만들기

발표처럼 20개까지 모을 필요는 없습니다. 오늘은 다섯 개로 시작해도 충분합니다. 핵심은 테스트로 채점할 수 있는 과제를 고르는 것입니다.

  1. 팀 저장소나 자주 쓰는 오픈소스 저장소에서 버그를 고친 커밋 가운데 테스트가 함께 추가되거나 수정된 커밋 다섯 개를 고릅니다. 커밋 메시지에 fix가 들어간 것부터 보면 빠릅니다.
  2. 각 커밋의 부모 커밋을 체크아웃해 버그가 남아 있는 상태를 만듭니다. 수정 내용을 바탕으로 증상만 적은 버그 설명을 씁니다. 파일 이름이나 줄 번호처럼 정답 위치를 알려 주는 단서는 넣지 않습니다.
  3. 같은 에이전트로 두 번 실행합니다. 한 번은 기본 설정 그대로, 한 번은 비교하고 싶은 검색 도구만 남기고 나머지 검색 도구를 막은 설정으로 돌립니다. Claude Code라면 프롬프트 지시와 함께 --disallowedTools 규칙을 쓰고, Bash로 실행되는 검색 명령까지 막혔는지 트레이스에서 확인합니다.
  4. 채점은 고친 커밋에 들어 있던 테스트를 통과했는지로 합니다. 통과 여부와 함께 실행 비용, LLM 호출 수, 검색 호출 수를 한 줄씩 표로 남깁니다.
  5. 가능하면 같은 과제를 두세 번 반복합니다. 한 번의 결과로 결론을 내리지 않는다는 발표자의 조언을 그대로 따르는 것입니다.

이 표가 생기면 다음 결정이 쉬워집니다. 청크 크기를 바꾸든, 임베딩 모델을 바꾸든, 시맨틱 검색을 grep과 함께 쓰든, 같은 다섯 과제로 다시 돌려 이전 실험과 비교하면 됩니다. 대회 발표 자료에서도 검색 방식을 왜 골랐는지 숫자로 설명할 수 있습니다.

출처

여러분 팀은 검색 방식이나 청크 크기를 바꿀 때 무엇을 기준으로 결정하고 있습니까? 이미 써 본 비교 방법이나, fix 커밋으로 평가 세트를 만들 때 막혔던 부분이 있다면 댓글로 나눠 주십시오.