Agentic Search vs Vector Search for Coding Agents: We Ran the Eval — Braintrust

한 줄 핵심

이 영상은 AI 시스템을 감으로 배포하지 않고, 평가(evals)와 관측성으로 실제 성능을 검증하며 코딩 에이전트의 검색 방식까지 비교하는 실전 방법을 보여준다.

시간별 요약

1. 0:00
   소개 Evals가 왜 중요한지와, 실제 업무에서 수행한 복잡한 평가 사례를 통해 핵심 개념을 설명하는 흐름으로 진행된다.
2. 0:42
   evals란 무엇인가 AI 기능을 배포할 때는 단순한 감상이 아니라, 측정 가능한 기준으로 성능을 판단할 수 있어야 한다는 문제의식이 제시된다.
3. 1:02
   감으로 배포하지 않기 충분한 테스트 없이 ‘좋아 보인다’는 이유로 배포하는 방식은 위험하며, 다수의 테스트 케이스와 정량적 근거가 필요하다.
4. 1:27
   evals가 답하는 것 evals는 어떤 LLM이 적합한지, 실제 다양한 상황에서 잘 작동하는지, 비용 대비 성능이 어떤지, 문제가 언제 발생하는지를 답하게 해준다.
5. 2:22
   sycophancy 롤백 OpenAI의 모델 변경처럼 의도와 다르게 더 아첨하는 방향으로 바뀌는 사례는, 복잡하고 비결정적인 AI 시스템에서 evals가 필수임을 보여준다.
6. 3:02
   eval의 네 가지 요소 데이터셋, 태스크, 스코어링 시스템, 실험이 eval을 구성하며, 이 네 요소의 조합이 각각의 실험을 만든다.
7. 4:32
   실험 비교 서로 다른 실험 결과를 나란히 비교해 개선이나 회귀를 확인하고, 개별 테스트 케이스 단위로 무엇이 달라졌는지 추적할 수 있다.
8. 4:52
   자연어로 트레이스 질의하기 트레이스와 실험 전체에 대해 자연어로 요약·문제점 탐색·성능 비교를 할 수 있어, 긴 대화나 미묘한 드리프트를 찾는 데 유용하다.
9. 5:47
   관측성 SDK로 코드를 감싸 프로덕션 로그를 수집하고, 대시보드와 전통적 관측성 방식으로 운영 상태를 확인할 수 있다.
10. 6:02
    eval 플라이휠 프로덕션 로그를 샘플링해 데이터셋을 만들고, eval을 돌려 개선점을 찾은 뒤 코드 변경과 배포로 이어가는 순환 구조가 설명된다.
11. 7:47
    eval은 팀 스포츠 eval은 엔지니어 혼자 만드는 것이 아니라, PM, 도메인 전문가, 데이터 분석가가 함께 가설 수립, 라벨링, 검증을 맡아야 제대로 작동한다.
12. 8:42
    실험: agentic search 대 vector search 코딩 에이전트에서 agentic search와 vector search 중 무엇이 더 효과적인지 비교하기 위한 실제 eval 사례가 소개된다.
13. 9:32
    vector search의 작동 방식 코드나 텍스트를 embedding으로 바꾸고 벡터DB에 저장한 뒤, 질의와 의미적으로 가까운 청크를 찾아 반환하는 방식이다.
14. 10:42
    agentic search의 작동 방식 LLM이 grep, find, ls, cat, bash 같은 도구를 사용해 사람처럼 코드베이스를 탐색하고, 함수 호출을 따라가며 필요한 논리를 찾는다.
15. 11:22
    데이터셋 만들기 Microsoft의 TypeScript go 리포지토리에서 bug가 있던 시점의 커밋과 수정 PR을 찾아, diff 기반으로 bug task를 생성해 데이터셋을 구성한다.
16. 12:17
    Claude Code에서 둘 다 실행하기 비교 공정성을 위해 둘 다 Claude Code 하네스에서 실행했고, vector search는 프롬프트 제한과 disallowed tools로 agentic 행동을 막아 구현했다.
17. 13:17
    고아 트레이스 수정 서브프로세스로 실행되며 트레이스가 끊기는 문제를 parent span ID를 환경변수로 전달해 해결했고, 이후 하위 호출과 터미널 명령까지 가시화할 수 있었다.
18. 14:37
    테스트 스위트로 채점하기 Microsoft TypeScript go 테스트 스위트를 통과하면 100점, 실패하면 0점으로 두는 단순한 이진 채점 방식이 사용되었다.
19. 14:57
    결과: 정확도는 같고 비용은 4배 정확도는 둘이 같았지만, vector search는 agentic search보다 4배 더 많은 비용이 들었고, 트레이스를 통해 그 이유를 추가 분석했다.
20. 15:22
    vector search가 부족했던 이유 vector search는 관련 청크는 잘 찾지만 import, 호출 코드, 주변 문맥을 놓치기 쉬워서, 실제 버그 해결에 필요한 연결 정보를 충분히 제공하지 못했다.
21. 16:27
    비용이 더 높았던 이유 vector search는 청크를 찾고 다시 검색하는 반복을 많이 만들어 LLM 호출이 누적되었고, 그 결과 실행 비용이 크게 증가했다.
22. 16:47
    주의점과 베스트 프랙티스 단일 평가와 적은 샘플만으로 결론을 내리기보다, 여러 번의 실행, 더 강한 구현, 더 큰 데이터셋으로 신뢰도를 높여야 한다.

실무 인사이트

• AI 기능은 배포 전 ‘잘 되는 것 같음’이 아니라, 대표 사례·엣지 케이스·실패 모드를 포함한 eval로 검증해야 운영 리스크를 줄일 수 있다.
• 코딩 에이전트의 검색 방식은 정확도보다 비용과 문맥 보존 능력에서 차이가 크게 날 수 있으므로, 단순 검색 적중률만 보지 말고 실제 작업 완수 비용까지 함께 봐야 한다.
• eval은 한 번 만들고 끝나는 산출물이 아니라, 프로덕션 로그→샘플링→재평가→개선 배포로 이어지는 반복 루프로 운영해야 효과가 크다.