"bash만 있으면 된다"를 직접 테스트해봤습니다

Ankur Goyal(Braintrust)을 초대해, AI 에이전트에서 "bash만 있으면 충분하다"는 가설을 직접 검증한 경험을 공유합니다.

AI 커뮤니티에서는 파일시스템과 bash가 AI 에이전트에 가장 적합한 추상화라는 확신이 점점 커지고 있습니다. 논리 자체는 합리적입니다. LLM은 코드, 터미널, 파일 탐색에 관한 방대한 데이터로 학습되었으니, 에이전트에게 셸을 주고 알아서 작업하게 하면 된다는 것이죠.

코딩이 아닌 에이전트에도 이 접근법이 유효할 수 있습니다. Vercel이 최근 발표한 파일시스템과 bash로 에이전트 구축하기 게시물에서는 영업 통화, 고객 지원 티켓 등 구조화된 데이터를 파일시스템에 매핑하는 방식을 보여줬습니다. 에이전트가 grep으로 관련 섹션을 찾아 필요한 정보를 추출하고, 필요에 따라 컨텍스트를 구성하는 방식입니다.

하지만 검증할 가치가 있는 반론도 있습니다. 컨텍스트를 탐색하고 가져오는 데는 파일시스템이 적절한 추상화일 수 있지만, 구조화된 데이터를 쿼리하는 경우에도 그럴까요? 이를 확인하기 위해 평가 하네스를 구축했습니다.

평가 설계

에이전트에게 GitHub 이슈와 풀 리퀘스트 데이터셋을 쿼리하는 과제를 부여했습니다. 이러한 반정형 데이터는 고객 지원 티켓이나 영업 통화 기록 같은 실제 사용 사례와 유사합니다.

질문 난이도는 다음과 같이 다양하게 구성했습니다:

• 단순 쿼리: "'security'를 언급한 미해결 이슈는 몇 개인가?"

• 복잡한 쿼리: "누군가 버그를 신고한 후, 다른 사람이 이를 수정했다고 주장하는 풀 리퀘스트를 제출한 이슈를 찾아라"

세 가지 에이전트 방식이 경쟁했습니다:

1. SQL 에이전트: 동일한 데이터가 들어 있는 SQLite 데이터베이스에 직접 쿼리 실행

2. Bash 에이전트: just-bash를 사용해 파일시스템의 JSON 파일을 탐색하고 쿼리

3. 파일시스템 에이전트: 전체 셸 접근 없이 기본 파일 도구(검색, 읽기)만 사용

모든 에이전트에 동일한 질문을 주고 정확도를 기준으로 평가했습니다.

초기 결과

SQL이 압도적이었습니다. 정확도 100%를 달성한 반면, bash는 53%에 그쳤습니다. Bash는 토큰도 7배 더 소모하고, 비용은 6.5배, 소요 시간은 9배 더 걸렸습니다. 기본 파일시스템 도구(검색, 읽기)조차 63% 정확도를 기록하며 bash보다 나은 성능을 보였습니다.

SQL 실험, bash 실험, 파일시스템 실험 결과를 직접 확인할 수 있습니다.

흥미로운 점은 bash 에이전트가 매우 정교한 셸 명령어를 생성했다는 것입니다. find, grep, jq, awk, xargs를 일반적인 에이전트 워크플로에서는 좀처럼 볼 수 없는 방식으로 체이닝했습니다. 모델이 셸 스크립팅에 대한 깊은 지식을 갖고 있는 건 분명하지만, 그 지식이 실제 작업 성능 향상으로 이어지지는 않았습니다.

결과 디버깅

평가 과정에서 주의 깊게 살펴봐야 할 실질적인 문제들이 드러났습니다.

성능 병목. 밀리초 단위로 실행돼야 할 명령어가 10초 만에 타임아웃되었습니다. 68,000개 파일에 대한 stat() 호출이 원인이었습니다. 이 문제를 해결하기 위해 just-bash 도구가 최적화되었습니다.

스키마 컨텍스트 부재. Bash 에이전트는 쿼리 대상인 JSON 파일의 구조를 알지 못했습니다. 시스템 프롬프트에 스키마 정보와 예시 명령어를 추가하면 개선되긴 했지만, 격차를 좁히기에는 충분하지 않았습니다.

평가 채점 문제. 실패 케이스를 수작업으로 확인한 결과, "기대 정답"이 실제로 틀렸거나 에이전트가 찾은 추가 유효 결과를 채점기가 오답으로 처리한 질문이 여러 개 발견되었습니다. 모호하거나 데이터셋과 불일치하는 5개 질문이 수정되었습니다.

• "가장 많은 고유 이슈 리포터를 보유한 저장소는?"이라는 질문은 조직 수준과 저장소 수준 그룹핑 사이에서 모호했음

• 여러 질문의 기대 정답이 실제 데이터셋과 일치하지 않았음

• Bash 에이전트가 참조 정답에 포함된 것보다 더 많은 유효 결과를 찾아낸 경우도 있었음

Vercel 팀이 수정 사항을 담은 PR을 제출했습니다.

just-bash와 평가 자체를 모두 수정한 후, 성능 격차가 상당히 좁아졌습니다.

하이브리드 접근법

그 다음에는 다른 아이디어를 시도했습니다. 하나의 추상화를 선택하는 대신, 에이전트에게 둘 다 주는 것입니다:

• bash로 파일을 탐색하고 조작할 수 있게 하고

• 적절한 경우 SQLite 데이터베이스도 사용할 수 있게 함

하이브리드 에이전트는 흥미로운 행동 패턴을 보였습니다. SQL 쿼리를 실행한 뒤, 파일시스템을 grep으로 탐색해 결과를 교차 검증했습니다. 이 이중 확인 덕분에 하이브리드 방식은 일관되게 100% 정확도를 기록한 반면, 순수 SQL은 간혹 오류를 냈습니다.

하이브리드 실험 결과를 직접 확인할 수 있습니다.

대신 비용이라는 트레이드오프가 있습니다. 하이브리드 방식은 도구 선택에 대한 추론과 결과 검증 과정 때문에 순수 SQL 대비 약 2배의 토큰을 사용합니다.

주요 교훈

just-bash, 평가 데이터셋, 데이터 로딩 문제를 모두 수정한 결과, bash-sqlite 하이브리드가 가장 안정적인 접근법으로 부상했습니다. 진정한 "승자"는 단일 실행에서의 원시 정확도가 아니라, 자기 검증을 통한 일관된 정확도였습니다.

200건 이상의 메시지와 수백 개의 트레이스를 거치며 다음과 같은 성과를 얻었습니다:

• just-bash의 성능 병목 해결

• 평가에서 모호하거나 잘못된 기대 정답 5개 수정

• off-by-one 오류를 유발하는 데이터 로딩 버그 발견

• 에이전트가 정교한 검증 전략을 스스로 개발하는 과정 관찰

Bash 에이전트가 스스로 작업 결과를 검증하려는 성향은 정확도뿐 아니라, 순수 SQL 방식에서는 눈에 띄지 않았을 문제를 수면 위로 끌어올리는 데도 효과적이었습니다.

에이전트 설계에 주는 시사점

명확한 스키마가 있는 구조화된 데이터에는 여전히 SQL이 가장 직접적인 경로입니다. 빠르고, 잘 정립되어 있으며, 토큰 소모도 적습니다.

탐색과 검증에는 bash가 SQL이 따라올 수 없는 유연성을 제공합니다. 에이전트가 파일을 직접 살펴보고, 결과를 샘플 확인하며, 파일시스템 접근을 통해 엣지 케이스를 잡아낼 수 있습니다.

하지만 더 큰 교훈은 평가 자체에 있습니다. Braintrust와 Vercel 팀이 매 단계마다 상세한 트레이스를 공유하며 주고받은 피드백이야말로 도구와 벤치마크를 실질적으로 개선한 원동력이었습니다. 이런 가시성이 없었다면, 잘못된 데이터에 기반해 어떤 추상화가 "이겼는지" 논쟁만 계속하고 있었을 것입니다.

직접 벤치마크를 실행해 보세요

평가 하네스는 오픈소스로 공개되어 있습니다.

아래 항목을 자유롭게 교체할 수 있습니다:

• 데이터셋 (고객 티켓, 영업 통화, 로그 등 현재 작업 중인 데이터)

• 에이전트 구현체

• 실제 사용 사례에 맞는 질문

이 글은 Ankur Goyal과 Braintrust 팀이 작성했습니다. Braintrust는 AI 애플리케이션을 위한 평가 인프라를 만들고 있으며, 이번 평가 하네스는 오픈소스로 공개되어 Vercel의 just-bash와 통합됩니다.