실행 백엔드

파일시스템을 건드리거나 명령을 실행하는 모든 툴은 실행 백엔드를 거칩니다. 그 일이 어디서 일어나는지를 백엔드가 결정합니다. 툴셋 자체는 바뀌지 않습니다 — read_file, shell, grep, git_commit 등은 내 노트북에서 돌든, 컨테이너 안에서 돌든, 네트워크 너머 호스트에서 돌든 똑같이 동작합니다.

바꾸기

/backend
/backend local
/backend docker {"image": "python:3.11-slim"}
/backend ssh {"host": "10.0.0.5", "user": "build", "key": "~/.ssh/id_ed25519"}

인자 없이 /backend만 치면 현재 백엔드를 출력합니다. 변경은 즉시 세션에 적용되며, 이미 진행 중이던 작업도 다음 툴 호출부터 바뀐 백엔드를 씁니다. 프로젝트는 <project>/.snowpea/settings.json의 backend 항목으로 기본값을 지정할 수 있습니다.

local

기본값입니다. 명령은 내 사용자 권한으로, 세션의 작업 디렉터리에서, 내 환경 그대로 실행됩니다. 아무것도 격리되지 않으므로 — 내 코드를 직접 다룰 때 쓸 백엔드이지, auto 모드 잡을 여기에 겨눠서는 안 됩니다.

docker

/backend docker {"image": "python:3.11-slim"}

키	기본값	의미
image	python:3.11-slim	컨테이너를 만들 이미지
workdir	세션의 workdir	컨테이너 내부의 같은 절대 경로에 바인드 마운트됨

컨테이너는 세션 이름을 따서 만들어지고, 첫 툴 호출 시점에 지연 생성되며, 세션이 닫히면 제거됩니다. 작업 디렉터리는 같은 절대 경로에 바인드 마운트되므로 모델이 추론하는 경로는 안팎이 동일합니다. 설치된 패키지, 네트워크, 환경 등 그 외 모든 것은 컨테이너의 것입니다.

auto 모드에 맞는 백엔드가 바로 이것입니다. 에이전트가 원하는 대로 설치하고 원하는 대로 망가뜨리게 두고, 컨테이너는 버리면 됩니다.

실행 중인 Docker 데몬이 필요합니다. 없으면 조용히 local로 폴백하지 않고 실패를 그대로 보고합니다.

ssh

/backend ssh {"host": "10.0.0.5", "port": 22, "user": "build", "key": "~/.ssh/id_ed25519"}

키	의미
host	호스트 이름 또는 주소
port	기본값 22
user	원격 사용자
key	개인 키 경로
password	key의 대안
cwd	원격 작업 디렉터리, 기본값은 원격 홈

명령은 SSH로, 파일 읽기·쓰기는 SFTP로 돕니다. 에이전트가 쓴 파일은 원격 호스트에만 존재합니다 — 로컬에는 아무것도 미러링되지 않으며, ssh 백엔드에서의 write_file은 내 디스크를 건드리지 않습니다. 키 인증을 강하게 권장합니다. 세션 설정에 들어간 비밀번호는 결국 설정 파일 속 비밀번호입니다.

지금 어디에 있는지 확인하기

정직한 테스트는 이렇게 물어보는 것입니다:

snowpea -c "run hostname and tell me what it printed"

local에서는 내 머신, docker에서는 컨테이너 id, ssh에서는 원격 호스트가 나옵니다. 에이전트가 파일시스템을 보는 시야 전체가 백엔드를 거쳐 오므로, 이 부분에서 에이전트가 틀릴 여지는 없습니다.

바뀌지 않는 것

백엔드가 다루는 것은 툴 실행이지 데몬이 아닙니다. 세션, 메모리, 승인 큐, 스케줄러, 게이트웨이는 세션이 어떤 백엔드를 쓰든 전부 내 머신의 데몬 안에 그대로 있습니다. 네트워크 툴 — web_search, web_extract, 브라우저 툴, 미디어 툴, MCP 서버 — 은 백엔드 호스트가 아니라 데몬에서 실행됩니다.

다음

헤드리스 — 이 모든 것을 스크립트에서 쓰기.