[한영자막] 코딩 에이전트의 Agentic Search와 Vector Search, 직접 평가해봤습니다 — Braintrust

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Braintrust의 코딩 에이전트 비교 실험에서는 Agentic Search와 Vector Search의 정확도가 같았지만, Vector Search의 비용이 약 4배 높았으며 이 결과는 소규모 데이터와 구현상의 한계를 전제로 해석해야 한다.

📌 핵심 요점

1. Evals는 AI 시스템에 관한 질문에 데이터로 답하는 방법이다. 몇 가지 프롬프트를 사용해 본 인상보다 정확도, 비용, 품질 저하를 측정한 결과로 출시와 변경을 판단해야 한다.
2. 평가는 데이터셋, 태스크, 채점 체계, 실험으로 구성된다. 운영 로그를 평가 데이터로 만들고, 실험 결과를 반영해 배포한 뒤 다시 관찰하는 개선 순환이 중요하다.
3. Vector Search는 임베딩의 의미적 유사성으로 코드 조각을 찾는다. Agentic Search는 LLM이 grep, 파일 읽기 등의 도구로 함수와 호출 관계를 따라가며 코드를 탐색한다.
4. 발표자는 Microsoft의 TypeScript Go 저장소에서 약 20개의 버그 수정 PR을 골라 비교했다. 두 방식 모두 Claude Code 실행 환경을 사용하고, Vector Search 조건에서는 프롬프트와 도구 제한으로 Agentic Search 사용을 막았다.
5. 실험에서 두 방식의 정확도는 같았지만 Vector Search의 비용은 약 4배였다. 발표자는 코드 조각에 빠진 맥락을 보완하려는 반복 검색과 LLM 호출을 원인으로 해석했으며, 반복 시행·구현 개선·데이터 확대가 필요하다고 인정했다.

🧩 배경과 문제 정의

Braintrust의 개발자 관계 엔지니어 Jess는 AI 기능의 출시를 막연한 인상으로 결정하는 관행을 문제로 제시한다. AI 시스템은 변경에 따라 정확도, 말투, 비용 등이 서로 다르게 움직일 수 있으므로, 평가를 통해 개선과 퇴행을 구체적으로 확인해야 한다는 설명이다.

이후 코딩 에이전트의 검색 방식에 관한 논의를 실제 평가 과제로 옮긴다. 임베딩으로 관련 코드 조각을 찾는 Vector Search와 도구를 사용해 코드를 순차적으로 탐색하는 Agentic Search를 같은 실행 환경에서 비교하고, 정확도와 비용 차이를 실행 추적으로 해석한다. 발표는 평가 방법을 설명하는 사례이며, 제한된 실험의 결론을 모든 코딩 작업에 일반화하지 않도록 한계도 함께 제시한다.

🕒 시간순 섹션별 상세정리

1. 인상에 따른 출시를 데이터에 따른 판단으로 바꾸기

• Jess는 소수의 프롬프트를 시험해 보고 괜찮아 보인다는 이유로 출시하는 사례를 지적한다. 테스트 통과율이나 정확도와 말투 사이의 변화처럼 구체적인 근거가 필요하다고 보여준다. [01:14]
• Evals는 모델 선택, 언어·프로그래밍 언어별 성능, 비용 효율, 브랜드 일관성, 사용자 피드백과 품질 저하에 관한 질문에 답하는 방법이다. [02:10]
• 발표자는 2025년 4월 OpenAI 업데이트가 지나친 동조로 이어졌다는 사례를 들어, 복잡하고 비결정적인 AI 시스템에 평가 체계가 필요하다고 강조한다. [02:47]

2. 평가를 구성하는 네 가지 요소

• 데이터셋에는 기준 사례, 경계 사례, 실패 유형을 담고, 태스크에는 입력을 받아 출력을 만드는 방식과 시스템 프롬프트·사용 모델 등을 정의한다. [03:28]
• 채점 체계는 출력의 좋고 나쁨을 판단한다. 결정적 채점, LLM을 심판으로 사용하는 방식, 사람의 검토 등이 예로 드러난다. [03:56]
• 데이터셋·태스크·채점 체계의 특정 조합이 하나의 실험이며, 가설에 따라 요소를 바꾸면서 여러 실험을 만든다. [04:20]

3. 실험 비교와 운영 관찰 기능

• Braintrust에서는 실험 간 개선과 퇴행을 비교하고, 개별 행으로 들어가 어떤 테스트 사례가 달라졌는지 확인할 수 있다고 보여준다. [04:39]
• 자연어로 실행 추적과 실험을 조회해 문제를 요약하거나 패턴을 찾을 수 있다. 긴 다중 턴 대화의 환각과 이탈을 살피는 용도를 설명하고 CLI와 MCP 서버도 언급한다. [05:32]
• SDK로 코드를 감싸 운영 로그를 수집하고, 로그 모니터링과 대시보드 등 관찰 기능을 사용할 수 있다고 보여준다. [05:52]

4. 운영 로그에서 평가와 재배포로 이어지는 순환

• 문서용 AI 챗봇을 예로 들어, 실제 사용자 요청에서 쌓인 운영 로그 중 10~20개 정도를 추출해 초기 데이터셋을 만드는 흐름을 보여준다. [06:41]
• 태스크와 채점 체계를 정하고 데이터·프롬프트·점수를 조정하며 실험한다. 결과에서 배운 내용을 시스템 변경과 배포에 반영하면 다시 운영 로그가 쌓이며 개선 순환이 반복된다. [07:26]

5. 평가는 여러 역할이 함께 만드는 작업

• AI 엔지니어는 코드 변경과 데이터 유입을 담당하고, 제품 관리자는 성공의 기준에 관한 가설을 세우거나 프롬프트를 조정하는 역할을 맡는다고 보여준다. [08:04]
• 보험·의료·법률 같은 전문 영역에서는 전문가가 데이터 라벨링과 정답 기준을 돕고, 데이터 분석가는 결과를 분석한다. [08:27]

6. 검색 방식 비교의 계기와 작동 원리

• 발표자는 Cursor의 코딩 에이전트 검색 관련 게시물을 평가해 달라는 요청과 온라인 논의를 계기로 비교 실험을 진행했다고 드러낸다. [09:14]
• Vector Search는 코드나 텍스트를 의미를 나타내는 임베딩으로 바꾸고 벡터 데이터베이스에 저장한 뒤, 질문과 의미적으로 가까운 코드 조각을 반환한다. [10:32]
• Agentic Search는 LLM에 grep, find, ls, cat 등의 도구를 제공한다. 함수명을 찾고 파일을 읽고 호출 관계를 따라가며 필요한 로직을 탐색한다. [11:08]

7. 버그 수정 PR로 평가 데이터셋 만들기

• Microsoft의 TypeScript Go 저장소에서 제목에 fix가 들어간 병합 PR을 찾고, 수정 전 부모 커밋을 체크아웃해 버그가 남아 있는 상태를 준비한다. [11:36]
• Claude로 수정 전후 diff에서 버그 과제를 생성하고, LLM이 검색 방식별로 버그 로직을 찾도록 했다. 데이터는 약 20개 PR로 구성했다. [12:07]

8. 실행 환경 통제와 하위 프로세스 추적 연결

• Agentic Search에는 Claude Code의 기본 탐색 방식을 사용했다. Vector Search도 같은 실행 환경에서 수행하되, 프롬프트 지시와 disallowed tools 설정으로 기본 탐색 도구 사용을 제한했다. [13:03]
• Claude Code를 하위 프로세스로 실행하면서 추적이 분리되는 문제가 생겼고, 부모 span ID를 환경 변수로 전달하는 방식으로 연결했다. [13:26]
• 연결 이후에는 하위 프로세스의 각 턴, LLM 호출, 터미널 명령까지 확인할 수 있어 실행 과정을 디버깅할 수 있었다. [14:25]

9. 같은 정확도와 약 4배 비용 차이를 추적으로 해석하기

• TypeScript Go 테스트 스위트를 통과하면 100%, 실패하면 0%를 주는 이진 채점을 사용했다. 결과적으로 두 방식의 정확도는 같았지만 Vector Search의 비용은 약 4배였다. [15:00]
• 발표자는 벡터 검색의 코드 조각에 import나 호출 코드 등의 맥락이 빠질 수 있다고 보여준다. 한 사례에서는 26번 검색하고도 세 함수의 상호작용을 연결하지 못했다. [15:37]
• Agentic Search는 전체 함수와 파일 사이의 호출 로직을 따라갔다. 발표자는 Vector Search에서 맥락을 보완하려는 검색이 반복되면서 LLM 호출과 비용이 누적됐다고 해석한다. [16:33]

10. 실험의 한계와 발표의 목적

• 발표자는 LLM의 비결정성을 고려한 과제별 반복 시행이 필요하며, 자신의 Vector Search 구현도 개선 여지가 있다고 인정한다. [17:04]
• 약 20개 사례를 넘어 데이터와 저장소를 확대해야 한다고 보여준다. 최고의 평가 결과를 제시하기보다 평가를 처음부터 끝까지 만드는 과정을 보여주는 것이 목적이라고 드러낸다. [17:28]
• Evals의 의미와 중요성, 실제 적용 방법을 전달했기를 바란다는 말로 발표를 마친다. [17:43]

🧾 결론

• 이 사례에서 Agentic Search의 장점은 관련 코드를 찾는 데 더해 함수와 파일 사이의 논리적 연결을 따라갈 수 있었다는 점이다.
• 같은 정확도라도 검색 횟수와 LLM 호출이 다르면 실행 비용은 크게 달라진다. 최종 점수와 실행 과정을 함께 살펴야 한다.
• 발표의 목적은 검색 방식의 보편적인 우열을 확정하는 것이 아니라, 실제 문제를 평가 실험으로 구성하고 결과를 해석하는 전체 과정을 보여주는 데 있다.

📈 투자·시사 포인트

• AI 개발 도구를 도입하거나 비교할 때 정확도와 함께 작업당 비용을 확인필요가 있다. 이 실험에서는 정확도가 같아도 비용 차이가 크게 나타났다.
• 코드 검색 도구는 관련 코드의 검색 성능뿐 아니라, 에이전트가 수정에 필요한 주변 맥락과 호출 관계를 확보하도록 돕는지도 평가해야 한다.
• Braintrust가 소개한 실험 비교와 운영 관찰 기능은 실패 원인과 비용 증가 경로를 분석하는 데 쓰인다. 다만 발표에는 매출, 시장 규모, 기업 가치 등 직접적인 투자 판단 자료가 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• 약 20개 사례와 단일 저장소를 사용한 결과다. 다른 언어, 저장소 규모, 버그 유형에서도 같은 정확도와 비용 관계가 나타나는지는 확인되지 않았다.
• 발표자는 Vector Search 구현이 상대적으로 약했다고 밝혔다. 구현을 개선한 뒤에도 비용이 약 4배인지 재검증해야 한다.
• 과제별 반복 시행이 보완점으로 제시됐다. 정확도의 절대 수치, 결과의 변동 폭, 비용 집계 범위와 세부 설정은 제공된 자막만으로 확인할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 사용 사례의 운영 로그에서 대표 사례, 경계 사례, 실패 사례를 골라 평가 데이터셋을 구성한다.
• 같은 데이터와 실행 환경에서 검색 방식을 비교하고, 각 조건에서 사용할 수 있는 도구를 명확하게 제한한다.
• 정확도와 함께 작업당 비용, 검색 횟수, LLM 호출을 기록하고 과제별로 여러 번 실행한다.
• 하위 프로세스에 부모 span ID를 전달해 전체 실행 추적을 연결하고, 맥락 누락과 반복 검색이 발생한 사례를 확인한다.

❓ 열린 질문

• Vector Search가 함수 전체와 호출 관계 등 더 충분한 맥락을 제공하도록 개선되면 비용 차이는 얼마나 줄어들까?
• 여러 저장소와 버그 유형으로 평가를 확대해도 Agentic Search의 비용상 이점이 유지될까?
• 버그 위치 탐색의 성공과 최종 테스트 통과를 따로 측정하면 두 방식의 차이를 어떻게 설명할 수 있을까?