Vercel fx 분석: 실행 파일 하나로 배포하는 코딩 에이전트

어제 OpenSandbox 코드 분석에서는 에이전트가 명령을 실행할 공간을 살펴봤다. 로컬 Docker에서 Kubernetes로 옮겨도 같은 API를 쓰게 만들고, 짧게 사용하는 샌드박스를 할당하고 회수하는 시스템이었다. 그런 환경에 코딩 에이전트를 수백 개 넣으려면 다음 문제가 생긴다. 에이전트 하나를 띄우기 위해 언어 런타임과 패키지를 매번 설치해야 한다면, 샌드박스를 빨리 준비한 효과가 줄어든다.

Vercel Labs가 공개한 fx는 이 지점에서 출발한 코딩 에이전트 하네스다. Zig로 작성했고, macOS와 Linux용 네이티브 실행 파일로 배포한다. Node.js나 Python을 먼저 설치하지 않아도 된다. 터미널에서 직접 대화할 수 있지만, fx ask --json으로 한 번 실행하고 끝내거나 fx acp로 다른 프로그램에 연결할 수도 있다. WebAssembly 빌드는 브라우저 안에서도 같은 에이전트 루프를 돌린다.

공개 당시 앞에 나온 숫자는 6.3MB와 10마이크로초였다. 둘 다 설명 없이 보면 사람의 사용 경험과 연결하기 어렵다. 모델이 답하는 데는 여전히 초에서 분이 걸리고, 파일 몇 MB를 아끼는 일도 노트북 한 대에서는 중요하지 않다. fx의 크기와 시작 시간은 한 사람이 한 번 실행할 때보다, 시스템이 에이전트를 계속 만들고 버릴 때 의미가 생긴다.

실행 파일 크기가 줄이는 설치 작업

2026년 8월 23일 기준 최신 안정 버전 v0.0.5의 배포 파일을 직접 받아 확인했다. 압축을 푼 실행 파일은 플랫폼마다 크기가 달랐다.

따라서 6.3MB는 모든 환경에 적용되는 규격이 아니라 Apple Silicon 빌드의 대표값에 가깝다. 그래도 배포 방식의 차이는 분명하다. 네이티브 fx를 실행하는 데 node_modules, 가상환경, 언어별 패키지 관리자나 별도 런타임이 필요하지 않다. 파일을 내려받고 실행 권한을 주면 설치가 끝난다.

사람이 개발 머신에 에이전트 하나를 설치할 때는 이 차이가 작다. CI 이미지, 일회용 VM, 평가용 컨테이너를 계속 만들 때는 누적된다. 기본 이미지마다 런타임을 준비할 필요가 없고, 서로 다른 버전의 의존성 트리를 관리하지 않아도 된다. 새 버전을 배포하거나 되돌릴 때도 실행 파일과 체크섬을 교체하면 된다.

작은 크기는 저장 공간보다 에이전트를 작업 환경에 넣는 절차를 줄였다는 데 의미가 있다.

10마이크로초가 측정한 것

출시 소개의 10마이크로초가 재는 범위는 모델 응답이나 대화형 화면 전체보다 훨씬 좁다. 저장소의 벤치마크를 보면 측정 범위를 더 정확히 알 수 있다. FX_BENCH=1은 인자를 해석하고 CLI 명령을 고른 다음 TTY를 초기화하기 전에 종료한다.

현재 공식 CI는 Linux에서 여섯 경로를 각각 100회 실행한다.

프로세스 실행에 드는 운영체제 비용도 빼지 않는다. PR에서 하나라도 예산을 넘으면 검사에 실패한다. 출시 문구의 10마이크로초보다 이 2ms 계약이 현재 성능을 이해하는 데 더 유용하다. 무엇을 재는지 공개돼 있고, 설정과 파일 읽기가 포함된 경로까지 관리하기 때문이다.

이 수치가 모델을 빠르게 만들지는 않는다. 대신 작업 하나마다 프로세스를 새로 만들 수 있게 한다. 테스트 1천 개에 독립 에이전트를 붙이거나, 요청마다 깨끗한 세션을 시작하거나, 실패한 작업을 프로세스째 폐기하는 시스템에서 하네스 시작 시간이 병목이 되지 않는다.

터미널, 자동화, 편집기가 같은 코어를 쓴다

fx를 부르는 방법은 크게 세 가지다.

사람 ─────────────── fx                 대화형 터미널
스크립트·CI ──────── fx ask --json      한 번 실행하고 종료
편집기·애플리케이션 ─ fx acp             ACP 서버
                              │
                              ▼
                       같은 에이전트 루프
                 모델 ↔ 도구 ↔ 권한 ↔ 세션

대화형 화면은 무거운 IDE형 TUI보다 유닉스 셸에 가깝게 만들었다. 터미널의 스크롤 기록을 그대로 쓰고, 필요한 순간에만 선택 화면이나 권한 확인 UI를 띄운다.

자동화에서는 fx ask가 더 중요하다. 프롬프트 하나를 받고 결과를 출력한 뒤 종료하며, --json을 붙이면 다른 프로그램이 결과를 읽을 수 있다. 에이전트를 긴 세션이 아니라 명령 하나처럼 조합할 수 있는 형태다.

fx acp는 같은 코어를 Agent Client Protocol 서버로 실행한다. 편집기나 다른 에이전트 호스트가 표준 입출력으로 세션을 만들고 프롬프트와 권한 요청을 주고받는다. 사용자 인터페이스를 fx에 묶지 않고 실행기만 가져다 쓸 수 있다.

#35에서 하네스를 “모델 빼고 전부”라고 정리했는데, fx는 그 전부를 독립 프로세스로 잘라냈다. 모델과 화면이 바뀌어도 도구 호출, 컨텍스트 조립, 권한, 세션, 복구를 같은 실행기에 남기려는 구성이다.

작은 실행 파일 안에 남긴 기능

fx가 작은 이유를 기능이 거의 없기 때문이라고 보기는 어렵다. 네이티브 버전에는 파일 목록·검색·읽기·편집·이동·삭제, 셸 명령, 웹 검색과 페이지 읽기, 이미지 처리, 메모리, Skills, MCP, 서브에이전트가 들어 있다. AGENTS.md도 경로에 따라 읽고, 대화를 압축하며, 세션을 저장하고 재개한다. 명령 실행 기록을 테이프로 남겨 다시 재생하는 기능도 있다.

모델 연결도 실행기와 분리했다. Vercel AI Gateway 외에 현재 v0.0.5는 Codex와 Grok 구독 로그인을 지원하고, 호환되는 로컬 loopback 엔드포인트에도 연결할 수 있다. 모델 가중치와 추론 엔진은 fx 밖에 남는다. fx는 선택한 모델에 공통 메시지와 도구 명세를 보내고, 돌아오는 도구 호출을 로컬에서 처리한다.

여기서 6.43MB의 다른 해석이 나온다. 무거운 계산은 모델 서버가 맡고, 프로젝트 코드는 작업 공간에 있으며, 격리는 바깥 실행 환경이 맡는다. fx는 그 사이에서 반복되는 에이전트 루프와 상태만 소유한다. 큰 기능을 빽빽하게 담은 구현과 함께, 직접 맡는 책임을 좁힌 설계가 작은 바이너리를 만들었다.

WebAssembly는 운영체제 기능을 호스트에 맡긴다

fx는 같은 Zig 코드에서 fx-core.wasm과 fx-term.wasm을 만든다. 전자는 애플리케이션이 자체 화면을 만들 때 쓰는 headless 코어이고, 후자는 xterm.js 같은 브라우저 터미널에 붙인다. 현재 브라우저 데모의 fx-term.wasm은 5,209,918바이트로, 확인한 macOS arm64 네이티브 실행 파일보다 약 1.22MB 작았다.

WASM이 더 작은 이유는 네이티브 기능 일부를 뺐기 때문이다. 네트워크 요청은 JavaScript의 fetch()에 맡기고, 설정과 세션 저장도 호스트가 어댑터로 제공한다. 명령 실행이 필요하면 브라우저 애플리케이션이 제한된 workspace.exec()를 구현해야 한다.

공식 SDK 문서가 밝힌 제한은 넓다. WASM에는 네이티브 프로세스, OS 샌드박스, 임의 WASI 파일 접근, 네이티브 MCP, Skills, 서브에이전트, 웹 검색, 자동 업데이트가 없다. Chrome과 Edge 137 이상, Safari 27 이상에 들어간 JSPI도 필요하다. Node.js 24에서는 실험 플래그를 켜야 한다.

WASM은 네이티브 fx의 기능 중 일부만 가져간다. 에이전트 루프는 유지하고 운영체제 권한은 호스트가 결정하는 내장용 코어다. 브라우저마다 다른 저장소와 인증, 명령 실행 방식을 fx 안에 다시 구현하지 않은 선택이 크기 차이로 나타난다.

권한 확인은 샌드박스가 아니다

fx에는 파일 변경과 명령 실행을 검사하는 권한 계층이 있다. 규칙으로 허용·거부할 수 있고, 해결되지 않은 요청은 사람이나 자동 검토에 넘긴다. yolo 모드는 이 검사를 우회한다.

하지만 최신 v0.0.5에는 중요한 변경이 있다. 릴리스 노트는 승인된 명령을 일반 호스트 서브프로세스로 실행하고, 기존 샌드박스 설정과 명령을 폐기했다고 명시한다. 권한 확인은 “이 명령을 실행해도 되는가”를 결정하지만, 실행된 프로세스가 운영체제에서 어디까지 접근할 수 있는지는 막아주지 않는다.

이 구분은 fx의 용도를 더 명확하게 만든다. 신뢰할 수 없는 코드에 fx를 바로 실행할 것이 아니라, Docker·VM·OpenSandbox 같은 격리 환경 안에 넣어야 한다. fx는 샌드박스를 제공하기보다 샌드박스 안에 넣기 쉬운 에이전트에 가깝다. 전날 살펴본 OpenSandbox가 실행 환경을 만들고, fx가 그 안에서 모델과 도구를 연결하는 식으로 두 역할이 맞물린다.

어떤 경우에 차이가 생기나

개발자 한 명이 프로젝트 하나에서 대화형 에이전트를 오래 사용한다면 작은 바이너리와 2ms 시작 시간이 주는 차이는 제한적이다. 모델의 정확도, 첫 토큰 시간, 컨텍스트 관리, 코드 리뷰 품질이 훨씬 큰 차이를 만든다. fx도 실제 작업에 들어가면 같은 네트워크와 모델 지연을 기다린다.

반대로 다음과 같은 환경에서는 설계 의도가 바로 드러난다.

• 평가 문제마다 깨끗한 에이전트 프로세스를 새로 시작한다.
• CI 작업이나 서버 요청이 fx ask --json을 호출한다.
• 컨테이너와 VM 이미지에 언어 런타임 없이 에이전트를 넣는다.
• 편집기와 제품이 ACP를 통해 같은 실행기를 공유한다.
• 브라우저 애플리케이션이 저장소·인증·명령 권한을 직접 통제한다.
• 여러 모델을 같은 도구와 세션 조건으로 비교한다.

이 경우 에이전트는 개발자가 켜 놓는 앱보다 시스템이 호출하는 작업 프로세스에 가깝다. 설치 단계가 짧고, 시작 비용이 일정하며, 텍스트와 JSON 인터페이스가 있다는 사실이 모델의 응답 속도보다 중요해진다.

정리

fx의 6.3MB와 10마이크로초만 놓고 보면 작은 CLI를 만들었다는 이야기로 끝난다. 배포와 호출 방식을 함께 보면 숫자의 쓰임이 보인다. fx는 코딩 에이전트를 사용자별로 설치하고 오래 유지하는 애플리케이션에서, 작업 환경에 복사해 필요할 때 실행하는 프로세스로 옮기려 한다.

이를 위해 네이티브 버전은 에이전트 루프와 도구, 권한, 세션을 단일 실행 파일에 담았다. ACP에서는 사용자 인터페이스를 분리하고, WASM에서는 네트워크와 저장소, 명령 실행을 호스트에 넘겼다. 모델 추론과 보안 격리도 fx 바깥의 책임으로 남겼다. 작은 크기는 단순한 최적화 수치가 아니라, fx가 직접 맡을 범위를 어디까지 줄였는지를 보여준다.

프로젝트는 아직 v0.0.5이고 README도 실험 상태라고 경고한다. 공개 후 며칠 사이에 공급자 로그인과 권한, 명령 실행 방식이 크게 바뀌었다. 지금 당장 기존 코딩 에이전트를 교체할 안정된 도구라기보다, 평가·샌드박스·편집기·제품 안에서 에이전트를 어떤 단위로 실행할지 살펴볼 공개 구현으로 보는 편이 맞다.

참고: vercel-labs/fx 저장소, v0.0.5 릴리스, 도구 문서, 프로젝트 지침, ACP, WebAssembly SDK, 브라우저 호스트 연동, 데이터와 로컬 추론, 벤치마크 정의. 코드와 문서는 2026-08-23 조회했다. 네이티브 크기는 GitHub v0.0.5의 네 플랫폼별 압축 파일을 내려받아 실행 파일의 바이트 수를 확인한 값이다. WASM 크기는 같은 날 fx.sh/try가 제공한 fx-term.wasm의 Content-Length를 확인했다. 출시 수치는 제작자 발표이며, 10마이크로초를 독립 재현한 결과는 아니다.