복잡한 AI 에이전트를 만들려면 정교한 벡터 검색, 커스텀 툴, 복잡한 파이프라인이 필요하다고 생각하기 쉽습니다. 하지만 Vercel이 최근 공개한 접근법은 놀랍도록 단순합니다. 가장 효과적인 에이전트 아키텍처는 이미 여러분의 터미널에 있다는 것이죠.
Vercel은 내부 에이전트의 커스텀 툴 대부분을 파일시스템 툴과 bash 툴로 교체했습니다. 그 결과 영업 통화 요약 에이전트의 비용이 Claude Opus 4.5 기준으로 통화당 약 1달러에서 0.25달러로 75% 절감됐고, 출력 품질도 개선됐습니다.
출처: How to build agents with filesystems and bash – Vercel Blog
왜 파일시스템인가
기존 접근법은 크게 두 가지였습니다. 모든 컨텍스트를 프롬프트에 쑤셔 넣거나, 벡터 검색을 사용하는 것이죠. 프롬프트에 모두 넣으면 토큰 제한에 걸리고, 벡터 검색은 의미적 유사성엔 좋지만 구조화된 데이터에서 특정 값을 정확히 찾아야 할 때는 부정확합니다.
파일시스템은 다른 트레이드오프를 제공합니다. 고객 기록, 티켓 이력, CRM 데이터 같은 것들은 자연스러운 계층 구조를 갖고 있어 디렉토리에 직접 매핑됩니다. grep -r "pricing objection" transcripts/ 같은 명령어로 정확한 매칭이 가능하고, 에이전트는 필요한 파일만 주문형으로 로드하기 때문에 컨텍스트가 최소화됩니다.
더 중요한 건, LLM이 이미 이 방식에 익숙하다는 점입니다. 모델은 학습 과정에서 수없이 많은 코드를 보며 디렉토리 탐색, grep, 복잡한 코드베이스의 상태 관리를 익혔습니다. 코드 탐색에 뛰어난 에이전트라면 어떤 데이터든 파일시스템으로 구조화하면 똑같이 뛰어날 수밖에 없습니다.
실제로 어떻게 작동하는가
에이전트의 핵심 구조는 놀랍도록 간단합니다. 세 가지 기본 툴만 있으면 됩니다.
1. read_file: 파일 내용 읽기
2. list_files: 디렉토리 목록 보기
3. edit_file: 파일 생성 및 수정
에이전트의 작동 루프는 이렇습니다. 사용자가 요청하면, LLM은 필요한 툴을 호출하라는 구조화된 응답을 반환합니다. 프로그램이 실제로 로컬에서 그 작업을 실행하고, 결과를 다시 LLM에게 보냅니다. LLM은 그 컨텍스트를 바탕으로 계속 작업하거나 응답하죠.
LLM은 절대 파일시스템을 직접 건드리지 않습니다. 단지 무엇을 해야 할지 요청할 뿐이고, 여러분의 코드가 샌드박스에서 실행합니다. 추론은 LLM이, 실행은 격리된 환경이 담당하는 구조입니다.
Vercel의 영업 통화 요약 에이전트도 같은 원리입니다. 에이전트는 이런 구조를 봅니다.
gong-calls/
demo-call-001-companyname.md # 현재 통화 기록
previous-calls/ # 이전 통화들
salesforce/
account.md # CRM 계정 정보
slack/
slack-channel.md # 슬랙 히스토리에이전트는 코드베이스를 다루듯 이 구조를 탐색합니다. ls로 뭐가 있는지 보고, grep으로 패턴을 찾고, cat으로 필요한 섹션을 읽습니다. 우리가 미리 정의한 파라미터가 아니라 원본 정보를 직접 다루기 때문에 예상하지 못한 엣지 케이스도 스스로 처리합니다.
단순함의 힘
이 접근법의 장점은 명확합니다.
네이티브 모델 능력 활용: grep, cat, find, awk 같은 도구들은 LLM이 학습 중에 수십억 번 본 것들입니다. 새로운 기술을 가르치는 게 아니라 이미 아는 걸 쓰는 거죠.
미래 지향적 아키텍처: 모델이 코딩 능력이 좋아질수록 여러분의 에이전트도 자동으로 좋아집니다. 학습 분포를 거스르는 게 아니라 활용하는 겁니다.
디버깅 가능: 에이전트가 실패하면 어떤 파일을 읽었고 어떤 명령어를 실행했는지 정확히 볼 수 있습니다. 블랙박스가 아니라 실행 경로가 보입니다.
유지보수할 코드 감소: 데이터 타입마다 검색 파이프라인을 만드는 대신, 디렉토리 구조에 파일을 쓰기만 하면 됩니다. 나머지는 에이전트가 알아서 처리합니다.
물론 프로덕션 툴은 여기에 더 나은 에러 핸들링, 스트리밍 응답, 스마트한 컨텍스트 관리, 승인 워크플로우 등을 추가합니다. 하지만 핵심 루프는 정확히 이것입니다. LLM이 결정하고, 코드가 실행하고, 결과가 다시 흐르는 구조. 그게 전부입니다.
실무 적용을 위한 힌트
만약 에이전트를 만들고 있다면, 커스텀 툴을 만들고 싶은 충동을 참고 먼저 물어보세요. “이걸 파일로 표현할 수 있을까?” 고객 지원 시스템이라면 /customers/cust_12345/tickets/처럼 계층을 만들고, 문서 분석 시스템이라면 /documents/uploaded/와 /documents/extracted/로 나누는 식입니다.
Vercel은 최근 이 패턴을 구동하는 bash-tool을 오픈소스로 공개했고, Mihail Eric의 200줄 구현 코드도 공개돼 있습니다. 에이전트의 미래는 놀랍도록 단순할지도 모릅니다. 최고의 아키텍처는 아키텍처가 거의 없는 것일 수도 있습니다. 그냥 파일시스템과 bash만 있으면 되니까요.
참고자료:
답글 남기기