에이전틱 검색과 벡터 검색을 직접 평가한 코딩 에이전트 실험

URL: https://www.youtube.com/watch?v=pLdgH-jLw5A 날짜: 2026-10-16 채널: TechBridge 원문 제목: [한영자막] 코딩 에이전트의 Agentic Search와 Vector Search, 직접 평가해봤습니다 — Braintrust

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코딩 에이전트에서 Vector Search와 Agentic Search 중 어떤 방식이 더 정확하고 비용 효율적인지, 재현 가능한 평가(evals)로 판단해야 한다.==

• 감이나 몇 번의 프롬프트 실행만으로 기능 출시 여부를 결정하면 모델의 회귀와 비용 증가를 발견하기 어렵다.
• Microsoft TypeScript-Go 저장소의 실제 버그 수정 이력을 데이터셋으로 삼아 두 검색 방식을 같은 조건에서 비교했다.
• 두 방식은 같은 정확도를 보였지만, 해당 실험에서는 Vector Search가 Agentic Search보다 네 배 비쌌다.

평가는 단순한 점수표가 아니라 데이터셋, 작업 정의, 채점 체계, 실험을 연결해 AI 시스템에 관한 질문에 답하는 절차다. 검색 결과의 근접성만 제공하는 방식과 코드의 연결 관계를 직접 따라가는 방식의 차이를 추적하려면, 테스트 결과뿐 아니라 각 실행의 trace와 비용까지 함께 확인해야 한다.

1. AI 시스템을 감이 아닌 데이터로 평가하기

AI 기능의 출시 결정은 재현 가능한 근거와 실패 원인을 함께 보여주는 방식으로 바뀌어야 한다.

1.1. “잘 되는 것 같다”는 출시 기준이 될 수 없다

1. 감에 의존한 출시 결정의 문제

   1. 고객과의 대화에서 엔지니어링 팀이 준비됐다고 말했거나 PM이 몇 개의 프롬프트를 시험해 좋아 보였다는 이유로 기능을 출시했다는 사례가 있었다.
   2. 이런 결정은 실제 테스트 케이스의 통과율이나 실패 유형이 아니라 팀의 느낌(vibes)에 기반한다.
   3. AI 시스템은 복잡하고 비결정적이므로 소수의 성공 사례만으로 전체 성능을 추정할 수 없다.

2. 수치가 있는 출시 기준

   1. “200개의 테스트 케이스를 실행했고 94%가 통과했으므로 출시한다”처럼 데이터셋, 통과율, 판단 근거를 함께 제시해야 한다.
   2. 하나의 지표가 좋아졌다는 사실만으로 충분하지 않다. 정확도가 5% 올랐지만 말투(tone)가 5% 나빠졌다면 그 상충 관계를 명시해야 한다.
   3. 개선과 회귀를 동시에 기록해야 제품·엔지니어링 팀이 어떤 품질을 선택했는지 알 수 있다.

1.2. 평가가 답해야 하는 질문

1. 모델과 시나리오에 관한 질문

   1. 새 모델이 계속 출시되는 상황에서 우리 요구에 가장 적합한 LLM은 무엇인지 비교할 수 있다.
   2. 영어 입력·출력에서는 잘 작동하지만 일본어 입력·출력에서는 약한지, Python에서는 잘 작동하지만 TypeScript에서는 약한지처럼 다양한 실제 조건을 점검할 수 있다.
   3. AI가 회사의 목소리와 기준을 일관되게 반영하는지 확인할 수 있다.

2. 운영과 개선에 관한 질문

   1. 과도한 비용을 쓰지 않고 높은 성능을 얻을 수 있는지 측정할 수 있다.
   2. 사용자의 피드백을 학습해 반복적으로 개선하고 있는지 확인할 수 있다.
   3. 시스템이 깨지거나 이전보다 나빠졌을 때 언제, 어떤 조건에서 회귀가 일어났는지 탐지할 수 있다.

3. 실제 회귀 사례

   1. 2025년 4월 OpenAI가 모델을 업데이트했을 때 더 도움이 되는 모델을 의도했지만, 실제로는 지나치게 동의하는 성향(sycophantic)이 강해졌다.
   2. 사용자의 말에 쉽게 맞장구치면서 진실성(truthfulness)이 낮아지는 변화는 일상적인 수동 확인만으로 놓치기 쉽다.
   3. 동일한 평가셋을 모델 변경 전후에 돌리면 이런 성향 변화와 품질 회귀를 조기에 포착할 수 있다.

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

평가 하나는 데이터와 실행 방법, 품질 판단, 비교 실험이 결합된 단위다.

2.1. 데이터셋: 무엇을 시험할 것인가

1. 데이터셋의 기본 역할

   1. 데이터셋은 AI 시스템에 넣을 입력들의 모음이며, 시스템이 실제로 맞닥뜨릴 상황을 대표해야 한다.
   2. 정답에 가까운 대표 사례(golden cases), 경계 사례(edge cases), 이미 알려진 실패 모드(failure modes)를 함께 넣는다.
   3. 데이터셋이 빈약하면 점수가 높아도 실제 사용 환경의 품질을 보장할 수 없다.

2. 현실에서 얻는 데이터

   1. 운영 로그에서 실제 사용자 질문과 시스템 응답을 추출하면 평가셋이 실제 문제를 반영하게 된다.
   2. 도메인에 따라 정답이나 우수한 응답의 기준을 전문가에게 확인해야 한다.
   3. 특정 언어·프레임워크·고객군이 빠지면 그 조건에서의 실패를 측정할 수 없으므로 입력 분포를 넓혀야 한다.

2.2. 작업(task): 시스템이 어떻게 행동할 것인가

1. 작업 정의

   1. 작업은 입력을 받은 AI 시스템이 어떤 방식으로 출력해야 하는지 규정한다.
   2. 보통 시스템 프롬프트와 해당 작업을 실행할 모델을 포함한다.
   3. 같은 데이터셋이라도 프롬프트나 모델이 달라지면 다른 작업 구성이 된다.

2. 가설을 작업으로 바꾸기

   1. “검색 결과가 충분한 문맥을 제공하는가” 같은 질문을 모델·도구·프롬프트의 구체적인 구성으로 바꿔야 한다.
   2. 특정 도구를 사용하거나 사용하지 않도록 제약할 때는 프롬프트만이 아니라 실행 환경의 도구 권한도 함께 통제해야 한다.

2.3. 채점(scoring): 무엇을 좋은 출력으로 볼 것인가

1. 품질 기준 작성

   1. PM이나 엔지니어가 어떤 출력이 좋은지, 어떤 출력이 나쁜지를 판별할 기준을 작성한다.
   2. 기준은 가능하면 관찰 가능한 결과로 표현해야 하며, 사람마다 다른 인상을 점수로 바꾸는 데 주의해야 한다.

2. 채점 방식의 선택

   1. 결정론적 채점(deterministic scoring)은 테스트 통과 여부처럼 명확한 조건을 코드로 판정한다.
   2. LLM-as-a-judge는 다른 LLM이 미리 정의한 기준에 따라 응답을 평가한다.
   3. 사람 검토(human review)는 전문성이 필요한 도메인에서 정답과 우수성의 기준을 직접 확인한다.
   4. 어떤 채점 방식을 쓸지는 질문의 성격과 필요한 신뢰 수준에 맞춰 정한다.

2.4. 실험(experiment): 가설을 비교하기

1. 실험의 정의

   1. 특정 데이터셋, 특정 작업, 특정 채점 시스템의 조합 하나가 실험 하나가 된다.
   2. 시스템을 개선하려는 가설에 따라 데이터셋, 프롬프트·모델을 포함한 작업, 채점 기준 중 하나 이상을 바꾼다.
   3. 각각의 구성 변경은 별도의 실험으로 기록해야 이전 결과와 개선·회귀를 구분할 수 있다.

2. 결과 비교

   1. 실험 1과 실험 2를 비교해 전체 점수가 좋아졌는지 나빠졌는지 확인한다.
   2. 특정 행(row)을 열어 어떤 테스트 케이스가 바뀌었는지 확인하면 총점 뒤에 숨은 원인을 찾을 수 있다.
   3. 점수만 보는 대신 개별 trace를 조사해야 실패한 코드 경로, 반복 검색, 환각, 문맥 누락을 설명할 수 있다.

3. Braintrust에서 평가와 운영 관찰을 연결하는 방법

평가 결과를 실제 서비스의 로그와 이어 붙이면 출시 후 발견한 문제를 다시 평가셋과 개선 실험으로 돌릴 수 있다.

3.1. 실험·trace를 탐색하는 도구

1. 실험 결과 비교 UI

   1. Braintrust UI에서는 실험 간 성능을 비교하고 개별 행을 열어 특정 테스트 케이스의 변화를 볼 수 있다.
   2. 장시간의 다중 턴 대화처럼 수동으로 훑기 어려운 실행도 trace 단위로 확인할 수 있다.

2. 자연어 질의

   1. 실험과 trace 전체에 자연어로 “내 실험을 요약해 달라”고 요청할 수 있다.
   2. “이 실험의 문제를 강조해 달라”고 요청해 반복되는 실패·환각·드리프트를 찾을 수 있다.
   3. 여러 실험 중 성능이 가장 좋았던 구성을 묻고 trace에서 패턴을 확인할 수 있다.
   4. UI뿐 아니라 CLI와 MCP 서버도 제공되므로 개발 흐름에 맞는 접근 방식을 선택할 수 있다.

3.2. 프로덕션 observability

1. 로그 수집과 대시보드

   1. Braintrust SDK로 애플리케이션 코드를 감싸면 운영 로그를 Braintrust로 보낼 수 있다.
   2. 일반적인 observability처럼 프로덕션 로그를 모니터링하고 대시보드를 만들 수 있다.
   3. 운영에서 실제로 발생한 실패를 다시 데이터셋으로 만들면 평가가 고정된 테스트로 끝나지 않는다.

2. 애플리케이션에서 평가까지의 반복 흐름

   1. 문서 페이지에 사용자가 문서에 관해 질문하는 AI 챗봇을 새로 배포한다.
   2. 고객이 사용하기 시작하면 실제 질문·응답 로그가 쌓인다.
   3. 로그의 일부, 예를 들어 10~20개 행을 샘플링해 평가 데이터셋을 만든다.
   4. 데이터셋에 작업과 채점 시스템을 붙여 여러 평가를 실행한다.
   5. 데이터셋, 프롬프트, 채점 기준을 각각 조정하며 어떤 구성이 가장 나은지 비교한다.
   6. 평가 결과에서 배운 점을 코드나 AI 시스템 설정에 반영하고 애플리케이션에 다시 배포한다.
   7. 변경 사항이 새 프로덕션 로그로 들어오면 같은 흐름을 반복해 지속적으로 품질을 개선한다.

4. 평가는 여러 직군이 함께 만드는 팀 작업이다

실제 평가에는 코드 변경뿐 아니라 데이터 확보, 라벨링, 성공 기준 수립, 도메인 판단, 결과 분석이 모두 필요하다.

4.1. 역할별 책임

1. AI 엔지니어

   1. 시스템 코드와 프롬프트를 변경하고 평가 실행 환경을 구성한다.
   2. 실제 운영 데이터를 플랫폼으로 가져오고 실행 trace가 끊기지 않도록 계측한다.

2. 제품 관리자(PM)

   1. 조직에서 평가를 주도하는 경우가 많으며, 무엇을 성공으로 볼지에 대한 가설을 세운다.
   2. 프롬프트와 작업 정의를 조정하고 제품 목표와 평가 지표를 연결한다.

3. 도메인 전문가(subject-matter expert)

   1. 보험·의료·법률처럼 전문성이 필요한 영역에서 데이터에 라벨을 붙이고 정답 또는 우수성의 기준을 제공한다.
   2. 일반적인 언어 품질만으로 판단할 수 없는 위험과 예외를 평가셋에 반영한다.

4. 데이터 분석가

   1. 실험 결과와 운영 데이터를 분석해 어떤 구성에서 성능이 달라졌는지 설명한다.
   2. 단순 평균뿐 아니라 실패 유형, 비용, 특정 입력군의 편차를 찾아 다음 가설로 연결한다.

4.2. 협업이 필요한 이유

1. 데이터에서 의사결정까지의 연결
   1. 엔지니어가 시스템을 실행할 수 있게 만들어도 어떤 데이터가 중요한지는 제품·도메인 판단이 필요하다.
   2. PM이 성공 기준을 세워도 결과의 통계적 의미와 비용 구조는 엔지니어와 분석가가 확인해야 한다.
   3. 평가를 팀 스포츠로 보면 기능 출시, 회귀 감지, 개선 실험이 한 사람의 감이나 단일 직군의 책임으로 축소되지 않는다.

5. Agentic Search와 Vector Search의 개념

두 검색 방식은 코드베이스에서 관련 로직을 찾는 방법과 문맥을 구성하는 방식이 다르다.

5.1. Vector Search: 의미적 근접성을 찾기

1. 임베딩과 벡터 공간

   1. 코드나 텍스트를 임베딩(embedding)으로 변환하면 각 조각의 의미가 숫자 벡터로 표현된다.
   2. 의미가 비슷한 조각은 벡터 공간에서 서로 가깝고, 의미가 다른 조각은 멀리 떨어진다.
   3. 늑대(wolf), 개(dog), 고양이(cat)는 모두 동물이므로 서로 가까운 위치에 놓인다.
   4. 바나나(banana)와 사과(apple)는 과일이므로 서로 가깝지만 동물 그룹과는 멀리 놓인다.

2. 벡터 데이터베이스를 이용한 검색

   1. 실제 구현에서는 임베딩을 Qdrant나 Pinecone 같은 벡터 데이터베이스에 저장한다.
   2. “내 코드베이스에서 데이터베이스 로직은 어디에 있는가?” 같은 질의를 임베딩으로 바꾼다.
   3. 데이터베이스는 질의의 단어·의미와 가장 가까운 코드 조각을 반환한다.
   4. 반환되는 조각은 database나 logic과 의미적으로 가까울 수 있지만, 함수의 호출 관계나 파일 전체 맥락을 함께 보장하지는 않는다.

5.2. Agentic Search: 사람이 코드베이스를 탐색하듯 찾기

1. 도구를 이용한 능동적 탐색

   1. LLM에 grep, find, ls, cat, bash 같은 도구를 제공하고 코드베이스를 직접 탐색하게 한다.
   2. 에이전트는 함수 이름을 찾고 파일을 연 뒤 전체 내용을 읽는다.
   3. 함수가 다른 파일의 함수를 호출하면 호출 경로를 따라가 그 파일을 다시 열고 읽는다.
   4. 필요한 로직을 찾을 때까지 검색·읽기·추론의 순환을 이어간다.

2. 두 방식의 정보 구조 차이

   1. Vector Search는 질의와 의미적으로 가까운 코드 조각을 빠르게 제시한다.
   2. Agentic Search는 함수 정의, 호출하는 코드, import, 도구 호출 등 여러 조각 사이의 관계를 순서대로 복원한다.
   3. 따라서 전자는 올바른 코드에 가까이 가는 근접성(proximity)에 강하고, 후자는 조각을 연결하는 연결 조직(connective tissue)을 확보하는 데 강하다.

6. TypeScript-Go 저장소로 두 검색 방식을 평가한 실험

실제 버그가 있었던 과거 커밋과 수정된 PR을 이용해 코드 위치를 찾아 버그를 해결하는 능력을 비교했다.

6.1. 데이터셋 만들기

1. 버그가 있는 커밋 선택

   1. Microsoft의 오픈소스 TypeScript-Go 저장소에서 병합된 PR을 모두 살폈다.
   2. 제목에 “fix”가 포함된 PR을 골라 수정된 코드와 그 부모 커밋을 비교했다.
   3. 부모 커밋을 체크아웃해 버그가 아직 남아 있는 상태를 재현했다.

2. 버그 작업 생성

   1. 수정 전후의 diff를 Claude에 제공했다.
   2. Claude가 diff를 바탕으로 버그를 설명하는 작업, 즉 Linear 티켓과 비슷한 bug task를 생성하게 했다.
   3. 생성된 작업을 LLM에 입력하고, LLM이 RAG 기반 Vector Search 또는 Agentic Search로 버그 로직의 위치를 찾아 해결하게 했다.
   4. 최종 데이터셋은 약 20개의 서로 다른 PR에서 구성했다.

6.2. 두 검색 구현을 같은 실행 환경에 넣기

1. Agentic Search 구성

   1. Claude Code는 기본적으로 Agentic Search를 사용하므로 각 버그 작업을 Claude Code에 그대로 실행시켰다.
   2. 코드베이스를 직접 살피며 함수와 파일의 관계를 추적할 수 있는 기본 능력을 활용했다.

2. Vector Search 구성

   1. 두 실험의 실행 조건을 맞추기 위해 Vector Search도 같은 Claude Code harness 안에서 실행했다.
   2. Claude Code가 기본 설정인 Agentic Search로 되돌아가지 않도록 프롬프트에 Agentic Search를 사용하지 말라고 명시했다.
   3. 프롬프트만으로는 모델이 금지된 도구를 호출할 수 있으므로, Agentic Search에 사용되는 도구를 disallowed tools 플래그로 차단했다.
   4. 이중 제약으로 Vector Search와 Agentic Search가 같은 harness를 사용하면서도 서로 다른 검색 방식만 실행하도록 했다.

6.3. subprocess trace를 복구한 계측 문제

1. 고아 trace 문제

   1. Claude Code 실행을 subprocess로 돌리자 하위 실행이 부모 trace와 연결되지 않고 고아(orphaned) 상태가 됐다.
   2. 단순히 “Claude agent를 실행했다”는 상위 단계만 보이고, subprocess 안에서 어떤 LLM 호출과 터미널 명령이 일어났는지는 보이지 않았다.
   3. 내부 실행이 보이지 않으면 검색 횟수, 함수 추적 과정, 실패 원인을 비교할 수 없다.

2. parent span ID 전달

   1. 부모 span ID를 환경 변수로 subprocess에 전달해 하위 실행이 부모 trace에 속하도록 수정했다.
   2. 수정 전에는 왼쪽 패널에 run cloud agent 같은 상위 실행만 표시됐다.
   3. 수정 후에는 subprocess 안의 모든 턴, 모든 LLM 호출, grep, bash, ls, find 같은 터미널 명령까지 한 trace에서 확인할 수 있었다.
   4. 투명한 trace는 나중에 디버깅하고 두 검색 방식의 행동 차이를 설명하기 위한 핵심 조건이었다.

6.4. 이진 채점 기준

1. 테스트 통과를 정답으로 삼기

   1. TypeScript-Go 저장소의 테스트 스위트를 실행해 결과를 채점했다.
   2. 테스트 스위트를 통과하면 100%를 부여했다.
   3. 테스트에 실패하면 0%를 부여했다.

2. 기준의 장점과 한계

   1. 테스트 통과 여부는 사람이 응답을 읽고 판단하는 대신 결정론적으로 비교할 수 있다.
   2. 반면 테스트가 포착하지 못하는 설명 품질, 수정의 유지보수성, 탐색 효율 같은 요소는 이 점수에 포함되지 않는다.
   3. 이 실험의 질문이 버그를 찾아 실제 저장소 테스트를 통과시킬 수 있는지였기 때문에 이진 기준을 사용했다.

7. 실험 결과와 trace에서 얻은 학습

약 20개 작업에서 두 방식의 테스트 정확도는 같았지만, 검색 행동과 비용 구조는 달랐다.

7.1. 정확도는 같고 비용은 네 배 달랐다

1. 전체 결과

   1. Vector Search와 Agentic Search는 동일한 수준의 정확도를 기록했다.
   2. 해당 설정에서 Vector Search의 실행 비용은 Agentic Search의 네 배였다.
   3. 정확도만 보고 두 방식이 동등하다고 결론 내리면 운영 비용과 탐색 효율의 차이를 놓치게 된다.

2. 비용이 커진 경로

   1. Vector Search는 코드 조각을 반환한 뒤에도 문맥이 부족하면 다시 검색했다.
   2. 다시 코드 조각을 받고 또 검색하는 반복이 이어지며 검색 횟수가 늘었다.
   3. 검색을 수행할 때마다 LLM 호출과 실행 비용이 누적돼 최종 비용이 Agentic Search보다 커졌다.

7.2. Vector Search가 놓친 문맥

1. 코드 조각의 불완전성

   1. Vector Search가 반환한 청크에는 import가 빠지는 경우가 있었다.
   2. 도구 호출이나 해당 함수를 호출하는 상위 코드가 빠지는 경우도 있었다.
   3. 청크가 질의어와 의미적으로 가깝더라도 에이전트가 버그를 고치기에는 필요한 주변 문맥이 부족할 수 있다.

2. 26번 검색으로도 연결하지 못한 사례

   1. 한 작업에서 Vector 에이전트는 26번 검색을 수행했다.
   2. 그래도 한 파일에 걸친 세 함수가 어떻게 상호작용하는지 연결하지 못했다.
   3. 개별 함수 조각에 가까이 접근하는 것과 호출 관계를 이해하는 것은 별개의 능력임이 드러났다.

7.3. Agentic Search가 복원한 연결 관계

1. 사람과 유사한 탐색 순서

   1. Agentic Search는 함수 이름을 찾았다.
   2. 함수 전체를 읽고 로직의 결함을 발견했다.
   3. 이어서 해당 함수의 호출 로직을 따라 다른 파일로 이동했다.
   4. 필요한 정의와 호출 맥락을 결합해 버그를 해결했다.

2. 근접성과 연결 조직의 비유

   1. Vector Search는 올바른 코드 근처로 데려가는 근접성을 제공했다.
   2. Agentic Search는 서로 떨어진 코드 조각을 실제 동작 흐름으로 묶는 연결 조직을 제공했다.
   3. 복잡한 버그는 한 조각의 유사성보다 import·호출·상태 변화의 연결을 이해해야 하므로, 검색 결과를 어떻게 조립하는지가 중요하다.

8. 평가 설계의 한계와 개선 방향

이번 수치는 유용한 출발점이지만 모든 저장소와 모든 구현에 일반화할 수 있는 최종 결론은 아니다.

8.1. 반복 실행이 부족했다

1. 비결정성 문제

   1. LLM은 같은 작업에서도 실행마다 다른 검색 경로와 답을 낼 수 있다.
   2. 작업당 한 번만 실행하면 우연히 성공하거나 실패한 결과가 전체 점수에 크게 반영될 수 있다.
   3. 작업별로 여러 trial을 실행해야 평균 성능과 분산을 파악하고 점수를 더 신뢰할 수 있다.

2. 개선 방법

   1. 동일한 데이터셋·작업·채점 기준으로 여러 번 실행한다.
   2. 평균 정확도와 비용뿐 아니라 실행 간 편차를 함께 기록한다.
   3. 특정 검색 전략이 운 좋게 한 번 성공한 것인지 안정적으로 재현되는 것인지 구분한다.

8.2. Vector Search 구현과 데이터셋을 확장해야 했다

1. 구현 품질의 한계

   1. 사용한 Vector Search 구현은 상대적으로 약한 구현이었다.
   2. 더 강한 청크 전략, 재랭킹, 호출 관계 보강, 충분한 문맥 확장을 적용하면 결과가 달라질 수 있다.
   3. 따라서 네 배 비용 차이는 모든 Vector Search 구현의 본질적인 특성이라고 볼 수 없다.

2. 데이터셋 규모와 범위

   1. 약 20개 행만 사용했으므로 통계적 확신이 제한적이다.
   2. 서로 다른 규모와 구조의 저장소를 추가하고 더 다양한 버그 유형을 포함해야 한다.
   3. 한 저장소의 TypeScript-Go 사례뿐 아니라 여러 언어·프레임워크·코드베이스에서 평가해야 일반화 가능성을 확인할 수 있다.

8.3. 한계가 있어도 평가를 시작해야 한다

1. 평가의 목적

   1. 첫 평가가 완벽한 최종 평가일 필요는 없다.
   2. 초기 실험은 어떤 질문을 데이터셋·작업·채점 기준으로 바꾸는지 보여주고, 다음 실험의 개선 지점을 드러낸다.
   3. 감에 의존하는 상태보다 한계가 명시된 작은 평가를 시작하는 편이 의사결정에 더 많은 정보를 제공한다.

2. 다음 실험으로 이어가기

   1. 반복 trial과 더 큰 데이터셋을 추가한다.
   2. Vector Search의 구현을 보강하고 검색 횟수·토큰·실행 시간·비용을 세부적으로 비교한다.
   3. 정확도와 비용 외에도 문맥 완전성, 수정 품질, 지원 언어·프레임워크별 성능을 별도 지표로 평가한다.

주요 발언 모음

“평가는 AI 시스템에 관한 질문에 답하는 방법이다.”

“200개의 서로 다른 테스트 케이스를 실행했고 94%가 통과했기 때문에 이 기능을 출시한다고 말할 수 있어야 한다.”

“정확도가 5% 올라갔지만 말투는 5% 나빠졌다는 식의 미묘한 변화도 말할 수 있어야 한다.”

“평가는 팀 스포츠다.”

“Vector Search는 올바른 코드에 대한 근접성을 많이 제공했지만, Agentic Search는 코드 조각의 실제 로직을 연결하는 조직을 더 많이 제공했다.”

“이 평가에는 구멍이 많다. 하지만 목표는 최고의 평가를 만드는 것이 아니라 평가를 만드는 개념을 보여주는 것이다.”

핵심 데이터 & 수치

• 약 20개 PR: Microsoft TypeScript-Go 저장소에서 제목에 fix가 포함된 병합 PR의 부모 커밋을 이용해 버그 상태 작업을 구성했다.
• 10~20개 행: 운영 로그에서 일부를 샘플링해 새 평가 데이터셋을 만드는 예시 규모다.
• 100% 대 0%: TypeScript-Go 테스트 스위트를 통과하면 100%, 실패하면 0%를 부여하는 이진 채점 기준이다.
• 26회 검색: 한 Vector Search 실행이 세 함수의 상호작용을 이해하지 못한 채 수행한 검색 횟수다.
• 4배 비용: 실험 구성에서 Vector Search가 Agentic Search보다 지불한 실행 비용이다.
• 정확도 동일: 약 20개 작업에서 두 검색 방식의 테스트 정확도는 같은 수준이었다.
• 2025년 4월: OpenAI 모델 업데이트가 더 도움이 되도록 의도됐으나 지나치게 동의적이고 덜 진실한 반응을 만든 회귀 사례가 발생한 시점이다.

결론 및 시사점

1. AI 기능은 몇 번의 프롬프트 성공이나 “준비됐다”는 말이 아니라 대표성 있는 데이터셋, 명확한 작업, 검증 가능한 채점 기준, 반복 실험으로 출시 여부를 판단해야 한다.
2. Vector Search는 의미적으로 가까운 코드 조각을 찾는 데 유용하지만, import·호출 관계·상위 문맥을 자동으로 묶어준다는 보장이 없다.
3. Agentic Search는 함수와 파일을 순차적으로 탐색하며 코드의 연결 관계를 복원할 수 있지만, 도구 호출과 trace를 계측해 실제 탐색 과정과 비용을 확인해야 한다.
4. 같은 정확도라도 검색 횟수와 LLM 호출 누적에 따라 운영 비용이 크게 달라질 수 있으므로 정확도·비용·실행시간·문맥 완전성을 함께 평가해야 한다.
5. subprocess를 실행할 때 parent span ID를 전달하면 내부 LLM 호출과 터미널 명령까지 추적할 수 있어 실패 원인과 비용 차이를 설명할 수 있다.
6. AI 엔지니어, PM, 도메인 전문가, 데이터 분석가가 데이터·성공 기준·구현·분석을 나눠 맡아야 평가가 실제 제품 의사결정으로 이어진다.
7. 작업당 여러 trial, 더 강한 Vector Search 구현, 여러 저장소와 언어를 포함한 대규모 데이터셋으로 실험을 확장해야 현재 결과의 일반화 가능성을 검증할 수 있다.
8. 완벽한 평가를 기다리기보다 작은 평가를 시작하고, 그 결과에서 드러난 데이터셋·프롬프트·채점·계측의 한계를 다음 실험에 반영하는 반복 구조를 만드는 것이 핵심이다.