Launch HN: Terminal Use (YC W26) – 파일 시스템 기반 에이전트를 위한 Vercel

안녕하세요 Hacker News 여러분! 저희는 Terminal Use (https://www.terminaluse.com/)의 Filip, Stavros, 그리고 Vivek입니다. 저희는 샌드박스 환경 (sandboxed environment)에서 작동하며 작업을 수행하기 위해 파일 시스템 (filesystem)이 필요한 에이전트 (agents)를 더 쉽게 배포할 수 있도록 Terminal Use를 구축했습니다. 여기에는 코딩 에이전트 (coding agents), 리서치 에이전트 (research agents), 문서 처리 에이전트 (document processing agents), 그리고 파일을 읽고 쓰는 내부 도구들이 포함됩니다.

데모 영상은 여기 있습니다: https://www.youtube.com/watch?v=ttMl96l9xPA.

에이전트를 호스팅할 때 저희가 겪었던 가장 큰 고충은 여러 구성 요소를 하나로 엮어야 한다는 점이었습니다. 에이전트를 패키징하고, 샌드박스에서 실행하며, 사용자에게 메시지를 스트리밍하고, 턴 (turns) 간에 상태를 유지 (persisting state)하며, 에이전트 워크스페이스 (workspace)와 에이전트 간에 파일을 주고받는 과정을 관리해야 했습니다.

저희는 Replicate의 Cog와 비슷하지만 에이전트를 위한 무언가를 원했습니다. 즉, 리포지토리 (repo)로부터 에이전트 코드를 패키징하고 깔끔한 API/SDK 뒤에서 서비스할 수 있는 간단한 방법 말입니다. 저희는 에이전트와 통신하기 위한 프로토콜 (protocol)을 제공하고 싶었지만, 에이전트의 로직 (logic)이나 하네스 (harness) 자체를 제약하고 싶지는 않았습니다.

Terminal Use에서는 config.yaml과 Dockerfile을 사용하여 리포지토리로부터 에이전트를 패키징한 다음, 저희의 CLI로 배포합니다. 작업 (task, 대화)의 라이프사이클 (lifecycle)을 추적하는 세 가지 엔드포인트 (on_create, on_event, on_cancel)의 로직을 정의합니다. config.yaml에는 리소스 (resources), 빌드 컨텍스트 (build context) 등에 대한 세부 정보가 포함됩니다.

기본적으로 저희는 Claude Agent SDK 및 Codex SDK 에이전트를 지원합니다. 여기서 지원한다는 의미는 SDK 메시지 타입을 저희의 타입으로 변환하는 어댑터 (adapter)를 갖추고 있다는 뜻입니다. 만약 귀하만의 커스텀 하네스 (custom harness)를 사용하고 싶다면, 저희의 타입(Vercel AI SDK v6 호환)으로 메시지를 변환하여 보낼 수 있습니다. 프론트엔드의 경우, Vercel의 AI SDK와 함께 에이전트를 사용할 수 있게 해주는 Vercel AI SDK 프로바이더 (provider)를 제공하며, 스트리밍과 영속성 (persistence)을 직접 관리할 필요가 없도록 메시지 모듈 (messages module)을 갖추고 있습니다.

저희가 가장 차별화된다고 생각하는 부분은 스토리지 (storage)입니다.

저희는 파일 시스템 (filesystem)을 태스크 (task)의 생명 주기 (lifecycle)와 분리된 일급 기본 요소 (first-class primitives)로 취급합니다. 즉, 여러 턴 (turns)에 걸쳐 워크스페이스 (workspace)를 유지하거나, 서로 다른 에이전트 (agents) 간에 공유하거나, 샌드박스 (sandbox)가 활성화되어 있는지와 상관없이 파일을 업로드/다운로드할 수 있음을 의미합니다. 또한, 저희의 파일 시스템 SDK (filesystem SDK)는 서명된 URL (presigned urls)을 제공하여 사용자가 파일을 직접 업로드하고 다운로드할 수 있도록 지원하므로, 백엔드 (backend)를 통해 파일 전송을 프록시 (proxy)할 필요가 없습니다.

에이전트 로직 (agent logic)과 파일 시스템 스토리지 (filesystem storage)가 분리되어 있기 때문에, 샌드박스 내의 파일에 대해 걱정하지 않고도 에이전트를 쉽게 반복 개선 (iterate)할 수 있습니다. 버그가 발생하여 배포하더라도, 모든 태스크를 새로운 배포 버전으로 자동 마이그레이션 (auto-migrate)할 수 있습니다. 만약 파괴적 변경 (breaking change)이 발생한다면, 기존 태스크는 기존 버전에 머물도록 지정하고 새로운 태스크만 새 버전을 사용하도록 설정할 수 있습니다.

또한, 구성 가능한 마운트 경로 (mount paths) 및 읽기/쓰기 모드 (read/write modes)를 갖춘 멀티 파일 시스템 마운트 (multi-filesystem mounts) 지원을 추가하고 있습니다. 이를 통해 마운트 레이아웃 (mount layout)은 태스크별로 유지하면서도, 스토리지는 내구성을 갖추고 재사용할 수 있게 됩니다.

배포 (deployment) 측면에서는 현대적인 개발자 플랫폼 (developer platforms)의 영향을 받았습니다. 간단한 CLI 배포, 프리뷰/프로덕션 환경 (preview/production environments), Git 기반의 환경 타겟팅 (git-based environment targeting), 로그 (logs), 그리고 롤백 (rollback) 기능을 제공합니다. 에이전트를 구축, 배포 및 관리하는 데 필요한 모든 설정은 config.yaml 파일에 저장되므로, CI/CD 파이프라인에서 에이전트를 구축하고 배포하기가 용이합니다.

마지막으로, 저희는 여러분의 CLI 코딩 에이전트 (CLI coding agents)를 위해 플랫폼을 명시적으로 설계하여, 에이전트를 구축, 테스트 및 반복 개선할 수 있도록 돕습니다. 저희의 CLI를 사용하면 코딩 에이전트가 배포된 에이전트에게 메시지를 보내거나, 파일 시스템 콘텐츠를 다운로드하여 에이전트의 출력 결과를 이해하는 데 도움을 줄 수 있습니다. 저희가 에이전트를 테스트하는 일반적인 방법은 테스트하고 싶은 사용자 시나리오를 담은 마크다운 (markdown) 파일을 만든 다음, Claude Code가 사용자를 흉내 내어 배포된 에이전트와 대화하도록 하는 것입니다.

아직 갖추지 못한 점: 범용 샌드박스 (sandbox) 제공업체들과의 완전한 기능적 동등성 (parity)입니다. 예를 들어, 프리뷰 URL (preview URLs) 및 더 낮은 수준의 sandbox.exec(...) 스타일의 API는 아직 로드맵 상에 있습니다.

아래 댓글을 통해 여러분의 생각, 통찰, 질문 및 우려 사항을 들을 수 있기를 기대합니다!