AI 에이전트가 노트북을 벗어나 휴대폰에서도 돌아가기 시작하면서, 실행 환경 자체가 사용자의 기기에서 서비스 제공사의 클라우드로 옮겨가고 있다. 클로드 코드(Claude Code), 인스틴트(Instinct), 포크(Poke) 같은 제품이 각자 가상머신(VM)을 띄워 그 안에서 에이전트를 구동한다는 뜻이다. 한 개발자가 ws-term 환경을 뜯어보며 정리한 관찰 기록을 보면, 겉으로는 비슷해 보이는 두 서비스가 내부적으로는 상당히 다른 설계 철학을 따르고 있음이 드러난다. 실무자 입장에서 이 차이는 단순한 호기심거리가 아니라, 데이터가 어디에 남고 실행 권한이 누구에게 있는지를 가르는 문제다.
클로드 코드: 운영자를 테넌트 안에 봉인하다
클로드 코드의 실행 상자는 자체 커널을 가진 KVM 게스트, 즉 파이어크래커(Firecracker) 마이크로VM이다. 부팅되면 러스트로 작성된 init이 곧장 뜨고, 여기서 process_api라는 프로세스가 PID 1을 차지한다. 이 프로세스는 호스트의 제어 에이전트가 사용자 VM 내부에 상주하는 형태로, 디스크를 마운트한 뒤 vsock 2024번 포트를 열어 외부 호스트가 세션을 조종할 수 있게 한다. 다시 말해 운영 주체가 사용자의 공간 안쪽에 들어와 있는 셈인데, 그래서 이를 격리하는 데 상당한 공을 들였다. PID 1은 덤프가 금지돼 있고, CAP_SYS_PTRACE 권한이 있어도 /proc/1/mem 접근이 거부되며, 사용자 셸에는 CAP_SYS_RESOURCE 권한이 빠져 있다.
디스크는 사용자 몫(쓰기 가능·영속)과 서비스 몫(읽기 전용·공유)으로 깔끔하게 갈린다. 실제 도구 호출을 실행하는 하니스는 324MB짜리 Bun 컴파일 바이너리로 읽기 전용 디스크에 놓여 있다. 정작 모델 추론은 이 상자 밖에서 이뤄진다. 추론 요청은 HTTPS/2 위의 서버-전송 이벤트(SSE)로 /v1/messages에 나가는데, 443 포트만 허용하고 중간자 검사를 거치는 이그레스 게이트웨이(인증서 CN이 'Egress Gateway ... production')를 통과하며, api.anthropic.com은 /etc/hosts에 고정돼 있다. 인바운드 연결은 아예 없다(주소가 RFC-5737 테스트 대역인 192.0.2.2). 인증은 호스트가 발급한 OAuth 토큰으로, 루트만 읽을 수 있게 디스크에 캐시되고 부팅마다 교체된다.
생명주기는 전적으로 호스트가 주도한다. 내부에서 측정한 값으로 init까지 약 430밀리초, 하니스 프로세스까지 약 6.4초가 걸린다. 메시지가 들어오면 호스트가 vsock으로 VM을 깨워 --session-mode resume으로 세션을 이어가고, 유휴 상태가 길어지면 호스트 판단으로 회수한다. 회수될 때 프로세스는 죽지만 vda 디스크는 그대로 떨어져 나갔다가 다음 콜드 부팅에서 다시 붙는다. 연산 자원은 파괴됐는데도 대화가 끊김 없이 이어지는 느낌을 주는 이유가 여기에 있다.
인스틴트: 상자는 버리고 기억만 남긴다
인스틴트는 최근 출범한 스타트업으로, 챗봇이 아니라 진짜 비서 같은 느낌을 주는 기억 처리 방식이 특징이다. 흥미로운 점은 자체 VM 함대를 운영하지 않는다는 것이다. e2b.local이라는 흔적이 말해주듯, 인스틴트는 E2B가 파는 샌드박스(sandbox-as-a-service)를 빌려 쓴다. 일회용 우분투 상자를 에이전트에게 넘겨 컴퓨터 한 대를 쥐여주는 방식이다. PCI 버스가 없고(pci=off), MMIO 위의 virtio, 빈 DMI, tap0 네트워킹 같은 파이어크래커 특유의 서명이 그대로 보인다. 결국 두 서비스 모두 같은 마이크로VM 위에 앉아 있고, 차이는 누가 함대를 굴리며 그 안에 무엇을 부팅하느냐에 있다. 클로드 코드가 벗겨낸 커스텀 init을 띄운다면, E2B는 systemd와 XFCE 데스크톱까지 갖춘 완전한 우분투를 약 1.26초 만에 그래픽 데스크톱까지 콜드 부팅한다. 여기에도 게스트 내부 운영자가 있지만, 봉인된 PID 1이 아니라 평범한 systemd 서비스로 도는 E2B의 envd일 뿐이다. 인스틴트는 2 vCPU·1.9GB짜리 소박한 데스크톱 템플릿을 쓴다.
상자가 일회용이라면 에이전트의 기억은 어디에 사는가. 답은 /memory 디렉터리이고, 이것이 이 플랫폼의 핵심 아이디어다. 기억은 [[위키 링크]]로 엮인 마크다운 파일들의 깃(git) 저장소이며, 탐색은 grep으로 한다. timeline 폴더는 시간이 지나면서 원본에서 시간별·일별·주별로 거칠어지는데, 인간의 기억이 흐려지는 방식을 닮았다. 에이전트는 별도의 기억 API를 호출하는 대신 스스로 마크다운을 쓰고 자기 이름으로 커밋하는 깃 작성자 역할을 한다. 이 저장소는 파일 묶음이 아니라 하나의 깃 번들로 S3에 사용자별 ID를 키로 저장된다. 접근 인증에는 장기 키 대신 수명이 짧은 STS 자격증명을 쓰기 때문에, 샌드박스가 유출되더라도 토큰이 만료되면 스스로 무력화된다. 영속적인 자산은 S3의 깃 저장소이고 기계는 버려지는 소모품이라는 구도다.
실행 표면과 지속되는 '브라우저 신분'
인스틴트 상자에는 추론 호출이 전혀 없다. 클로드 코드가 운영자를 게스트 안에 봉인한다면, 인스틴트는 두뇌를 게스트에 아예 넣지 않는다. 샌드박스는 순수한 실행 표면일 뿐이어서, agent-exec-server가 백엔드가 건네는 배시 명령을 그대로 돌리고, 지메일·클라우드 브라우저·결제 같은 모든 도구 호출은 GraphQL 요청으로 api.instinct.com에 나가 서버 쪽에서 실행된다. --base-url이 컴파일에 박혀 있지 않고 런타임 인자인 점도 이 구조와 맞아떨어진다. 도구는 MCP가 아니라 CLI로 제공되며, tools --help는 지메일·노션·슬랙·스트라이프 결제·자격증명 볼트 등 약 50개 네임스페이스를 나열한다.
설계 의도를 가장 잘 드러내는 것은 클라우드 브라우저다. 인스틴트가 사용자를 대신해 음식을 주문하거나 항공권을 예약할 때, 이 샌드박스에서 브라우저를 여는 것이 아니라 별도의 클라우드 브라우저 풀에서 하나를 임대한다. 각 브라우저는 사용자의 저장된 프로필(쿠키·로그인)을 지닌 채 같은 api.instinct.com 브리지를 통해 조종된다. 리스 동작만 봐도 구조가 읽힌다. 프로필마다 새 로그인을 저장할 수 있는 쓰기 리스는 정확히 하나뿐이고, 동시에 최대 다섯 개까지 돌 수 있으며, 리스를 반납할 때는 쿠키를 먼저 저장해 다음 리스가 그것을 불러오도록 한다. 이 지속성이 핵심이다. 사용자의 브라우저 신분은 S3 볼트, 관측 인덱스와 나란히 서버 쪽에 놓인 세 번째 영속 자산으로, 일회용 상자가 한 작업 동안만 빌렸다가 되돌려주는 대상이다. 덕분에 비밀번호 같은 자격 정보가 상자에 직접 닿지 않고도 로그인이 이뤄진다.
두 접근을 나란히 놓으면 실무적 함의가 분명해진다. 클로드 코드는 게스트 격리에 엔지니어링을 집중해 코드 실행 샌드박스로서의 신뢰성을 확보하려 하고, 인스틴트는 실행 환경을 철저히 소모품으로 취급하면서 기억·자격증명·브라우저 세션이라는 지속 자산을 서버 쪽으로 밀어낸다. 어느 쪽이든 사용자 데이터의 무게중심이 로컬 기기에서 서비스 인프라로 옮겨갔다는 사실은 공통이며, 이는 감사·권한 관리·유출 대응을 설계할 때 반드시 고려해야 할 지점이다. 다만 여기 정리된 내용은 외부에서 환경을 관찰해 추정한 기록인 만큼 각 서비스의 공식 문서로 검증할 여지가 남아 있고, 새 제품이 나올 때마다 이런 구조는 계속 갱신될 것이다.