커서(Cursor)가 셀프 호스티드 머신(Self-Hosted Machines)을 출시했다. 클라우드 코딩 에이전트의 도구 실행 단계를 기업이 직접 관리하는 머신에서 돌릴 수 있게 하는 기능이다. 옮겨가는 것은 실행 환경뿐이며, 에이전트의 루프와 추론, 계획 수립은 그대로 커서 클라우드에 남고 작업의 시작과 스케줄링도 커서가 계속 맡는다.
연결 방식은 반대로 설계됐다. 기업 측 머신에 커서 CLI를 설치하고 agent worker start를 실행하면, 이 머신이 커서 클라우드로 향하는 장기 아웃바운드 HTTPS 연결을 맺는다. 커서는 플랫폼이 기업 네트워크 내부로 먼저 연결을 시도하는 일은 없다고 공식적으로 밝히고 있다. 보안팀 입장에서는 나가는 통신만 존재하는 경로인 셈이라, 이를 위해 방화벽에 별도 구멍을 낼 필요가 없다.
실행 환경을 사내로 옮기는 이유
커서는 세 가지 시나리오를 꼽았다. 첫째, 에이전트가 작업 중 사내 소스 저장소와 내부 서비스, 데이터베이스에 직접 접근해야 하는 경우로, 호스팅형 가상머신으로는 닿지 않는다. 둘째, 특정 하드웨어가 필요한 경우로 학습에는 GPU가, iOS 앱 빌드에는 맥이 필요하다. 셋째, 운영체제나 빌드 파이프라인 자체가 너무 무거워 표준 클라우드 이미지에 들어가지 않는 경우다.
이 세 가지 제약에 걸리는 곳은 하나같이 대기업이다. 중소 규모 팀은 호스팅형 샌드박스를 쓰는 데 별다른 장애가 없지만, 금융과 의료, 대형 제조업체는 컴플라이언스 규정상 코드를 제3자 인프라에 두지 않도록 못 박아 놓은 경우가 많아 그동안 이런 고객사는 에이전트 도입 자체를 포기할 수밖에 없었다.
두 가지 형태와 나열된 파트너사들
설정은 두 단계로 나뉜다. '마이 머신(My Machines)'은 노트북이나 가상머신 한 대를 개인 계정에 연결하는 방식이고, '풀(Pools)'은 팀·기업용 명명된 대기열로 요청량에 따라 용량이 자동으로 늘고 줄어든다. 후자는 수십에서 수백 명이 빌드 머신 묶음을 함께 쓰는 상황을 겨냥한 것이다.
샌드박스 쪽에는 AWS 람다, 클라우드플레어, 코더(Coder), 데이토나(Daytona), E2B, 모달(Modal), 네임스페이스(Namespace), 버셀(Vercel) 등 여러 업체가 이름을 올렸다. 이 조합은 이번 발표의 성격을 잘 보여준다. 커서는 격리 런타임을 직접 만들 생각이 없고, 그 영역은 이미 하고 있는 업체들에 맡긴 채 에이전트 스케줄링과 모델이라는 두 축만 쥐고 가겠다는 것이다. 그중 네임스페이스가 제공하는 기능은 특이한데, 클라우드 에이전트 세션마다 실제 맥 한 대를 띄워줄 수 있다.
리눅스와 맥 워커 모두 브라우저 제어 기능도 함께 열었다. 머신에 크롬이나 크로미움 관련 종속성만 설치돼 있으면 에이전트가 스스로 페이지를 열어 변경 사항을 확인할 수 있다.
현실을 보여주는 숫자 하나
커서는 글에서 사내에서 머지된 풀 리퀘스트 가운데 60% 이상이 클라우드 에이전트가 만든 것이라고 밝혔다. 이 수치는 기업 도입을 다룬 글에 실려 있으며, 의도는 분명하다. 먼저 자사가 실제로 쓰고 있다는 것을 증명한 뒤 고객에게 머신을 내놓으라고 요청하려는 것이다.
제품 라인을 보면 커서는 지난 1년간 줄곧 스케줄링 계층으로 파고들었다. 먼저 에이전트를 클라우드로 옮기고, 이어 구동 속도를 해결했으며, 이번에는 실행 위치 문제를 다뤘다. 코딩 도구 간 경쟁의 축은 자동완성 품질에서 런타임이 어디에 있느냐로 옮겨갔고, '매니지드 경험'과 '코드가 외부로 나가지 않는다'는 두 조건을 동시에 만족시키는 쪽이 대형 고객의 예산을 가져가게 된다.
참고 출처: 커서 공식 블로그, CocoLoop, 각 샌드박스 제공업체 공개 자료. 내부 머지 60%라는 수치와 연결 방식, 파트너사 목록은 커서 공식 발표를 기준으로 한다.