---
title: "\"Bash면 다 된다\"를 실제로 벤치마크해봤더니 — SQL 압승, 하이브리드가 최적"
published: 2026-01-22T23:58:11.000Z
canonical: https://jeff.news/article/1115
---
# "Bash면 다 된다"를 실제로 벤치마크해봤더니 — SQL 압승, 하이브리드가 최적

Vercel과 Braintrust가 AI 에이전트에게 SQL/Bash/파일시스템 도구를 주고 성능을 비교. 초기 SQL 압승(100% vs 53%)이었지만, 디버깅 후 하이브리드(SQL+Bash) 접근이 자기 검증을 통해 가장 신뢰할 수 있는 결과를 보여줌.

## "Bash면 다 된다"를 실제로 테스트해봄

- Vercel 블로그에 Braintrust의 Ankur Goyal이 기고한 글. AI 에이전트에게 "파일시스템 + bash만 주면 된다"는 가설을 실제 벤치마크로 검증함

- 배경: LLM이 코드, 터미널, 파일 탐색에 대해 광범위하게 학습했으니, 셸만 주면 알아서 작업할 수 있다는 주장이 커뮤니티에서 힘을 얻고 있었음. Vercel도 세일즈 콜, 지원 티켓 같은 비코딩 데이터를 파일시스템에 매핑해서 에이전트에게 grep하게 하는 접근법을 보여준 바 있음

## 벤치마크 설계

- GitHub 이슈와 PR 데이터셋을 대상으로 간단한 쿼리("보안 관련 이슈 몇 개?")부터 복잡한 쿼리("버그 신고 후 수정 PR이 달린 이슈 찾기")까지 테스트

- 세 가지 에이전트를 경쟁시킴: **SQL 에이전트**(SQLite 직접 쿼리), **Bash 에이전트**(JSON 파일을 셸 명령으로 탐색), **파일시스템 에이전트**(search/read 도구만 사용)

## 초기 결과: SQL 압승

- SQL이 **정확도 100%**, Bash는 **53%**에 그침. 토큰 사용량 7배, 비용 6.5배, 소요 시간 9배 더 많았음. 기본 파일시스템 도구(63%)가 오히려 풀 Bash 접근보다 나았음

- 흥미로운 점: Bash 에이전트가 find, grep, jq, awk, xargs를 체이닝하는 상당히 정교한 셸 명령을 생성했는데, 그 "지식"이 실제 성능으로 연결되지 않았음

## 디버깅하니까 이야기가 달라짐

- 성능 병목: 68,000개 파일에 stat() 호출이 10초 타임아웃. just-bash 도구에 최적화 적용
- 스키마 컨텍스트 부재: Bash 에이전트가 JSON 파일 구조를 몰랐음. 시스템 프롬프트에 스키마 추가하니 개선됐지만 격차를 좁히진 못함
- **평가 데이터 자체의 오류**: 정답이 틀리거나 모호한 문제가 5개 발견됨. Bash 에이전트가 실제로는 더 많은 정답을 찾았는데 스코어러가 오답 처리한 경우도 있었음

## 하이브리드가 답

- SQL과 Bash를 둘 다 주니 에이전트가 흥미로운 행동을 보임: SQL로 쿼리하고 → 파일시스템에서 grep으로 교차 검증. 이 자기 검증 덕에 **일관된 100% 정확도** 달성

- 트레이드오프는 비용. 하이브리드가 순수 SQL 대비 약 2배 토큰을 씀. 하지만 순수 SQL이 가끔 틀리는 것까지 감안하면 신뢰성에서는 하이브리드가 우위

> [!TIP]
> 핵심 교훈: 구조화된 데이터에는 SQL이 직접적이고 빠름. 탐색과 검증에는 Bash가 SQL이 못 하는 유연성을 제공. 하지만 진짜 교훈은 eval 자체를 계속 디버깅해야 한다는 것 — 도구가 아니라 평가 기준이 틀릴 수 있음

- eval 하네스는 오픈소스로 공개됨. 자기 데이터셋(고객 티켓, 세일즈 콜, 로그 등)으로 교체해서 돌려볼 수 있음

## 핵심 포인트

- SQL 정확도 100%, Bash 53%, 파일시스템 63%
- Bash가 정교한 셸 명령을 생성하지만 성능으로 연결 안 됨
- eval 데이터 자체에 오류 5건 발견
- 하이브리드가 SQL 쿼리 후 grep으로 교차 검증하는 행동 발현
- eval 하네스 오픈소스 공개

## 인사이트

에이전트 도구 선택보다 평가 프레임워크의 품질이 더 중요할 수 있다는 메타 교훈이 가장 인상적. 도구 논쟁보다 eval 디버깅에 시간을 쓰라는 실질적 조언.