이제 내가 관리하는 머신에서 실행되는 Cursor Cloud Agents — 에이전트의 컨텍스트가 실제로 위치하는 곳 (2026)

분할을 정의하는 단 한 문장

발표 내용 중:

"Self-Hosted Machines를 사용하면 실행 환경만 이동하는 반면, 에이전트 루프, 추론 및 계획은 Cursor 클라우드에 유지됩니다. 도구 출력은 추론을 위해 Cursor로 다시 전송되며 코드 조각이 포함될 수 있고, 에이전트 트랜스크립트는 Cursor에 의해 처리 및 저장될 수 있습니다."

한 문장에 세 가지 주장이 담겨 있습니다. 실행 환경이 이동합니다. 도구 출력이 다시 전송되며 코드 조각이 포함될 수 있습니다. 트랜스크립트가 처리 및 저장될 수 있습니다.

공식 문서에서도 다른 관점에서 동일한 내용을 설명하고 있으며, 무엇이 전송되는지 명시하고 있으므로 두 가지 모두 읽어볼 가치가 있습니다:

"전체 체크아웃, 빌드 캐시 및 머신 로컬 자격 증명은 사용자의 머신에 유지됩니다. 실행 중에 워커는 파일 내용, 터미널 출력, diff, 스크린샷, 로컬 MCP 결과 및 라우팅 메타데이터와 같이 에이전트가 필요로 하는 콘텐츠를 Cursor로 전송합니다."

파일 내용(File contents)이 이 목록에 포함되어 있습니다. 이는 Cursor가 무언가를 숨기려 해서가 아니라(그들은 이를 명확히 기록해 두었습니다), 추론을 위해 모델이 판단해야 할 바이트 데이터가 필요하기 때문입니다. 모델이 다른 곳에서 실행되는 아키텍처에서는 이를 피할 수 없습니다.

두 영역의 서로 다른 보존 규칙

Cursor의 클라우드 에이전트 보안 페이지는 에이전트 데이터를 여러 유형으로 분류하고 각각에 고유한 보존 규칙을 부여합니다. 여기서는 그중 두 가지가 중요합니다.

런타임 워크스페이스(runtime workspace)는 "실제 실행을 위한 체크아웃된 리포지토리, 빌드 아티팩트 및 도구 실행 컨텍스트"를 보유합니다. 보존 규칙은 다음과 같습니다. "실행이 유휴 상태가 되면 자동으로 재활용되며, 후속 프롬프트를 보낼 때 타이머가 초기화됩니다."

대화 상태(conversation state)는 "프롬프트, 모델 응답, 도구 호출, diff 컨텍스트 및 데모 아티팩트"를 보유합니다. 이는 "에이전트별 키로 암호화되어 Cursor 백엔드"에 저장되며, 보존 규칙은 "실행을 다시 확인하고 재개할 수 있도록 기본적으로 무기한 보관되며, 요청 시 삭제 가능"합니다.

따라서 에이전트가 생각한 내용에 대한 지속적인 기록은 이동하지 않는 영역에 속합니다. Self-Hosted Machines는 일시적인 영역만 재배치합니다.

후속 질문 시 기억 여부를 결정하는 기본값

실제 숫자가 언급된 부분은 다음과 같습니다. 풀(pool) 구성에서:

"워커가 요청에 매칭되면 Cursor는 모든 에이전트 도구 호출을 머신으로 직접 전달합니다. 연결에는 기본적으로 1시간으로 설정된 유휴 시간 초과(idle timeout)가 있습니다."

그리고 해당 타이머가 만료되면:

"워커가 시간 초과되면 Cursor는 이를 해제된 것으로 표시합니다. 머신은 재설정되어 풀에 다시 진입할 수 있습니다. 사용자가 머신과의 연결이 끊어진 채팅을 다시 시작하면, 채팅은 풀의 새로운 머신에 다시 연결됩니다. 풀이 최대 절전 모드(hibernation)를 사용하지 않는 한, 기존 머신의 워크스페이스 상태는 인계되지 않습니다."

마지막 절을 두 번 읽어보십시오. 대화는 백엔드에 무기한 보관되므로 유지됩니다. 하지만 워크스페이스는 유지되지 않습니다. 문서는 그 비용에 대해 직설적으로 설명합니다. "머신이 해제된 후 도착한 후속 요청은 풀에서 다시 할당받습니다. 에이전트는 새로운 머신에 도달하게 되며, 이미 가지고 있던 워크스페이스를 재구성하는 데 처음 몇 분을 소비할 수 있습니다."

문서에 제시된 해결책은 최대 절전 모드(hibernation)입니다. 머신이 유휴 상태가 될 때 스냅샷을 찍고, 재연결 창(reconnect window) 내에 후속 요청이 도착하면 이를 복원하여 "창이 만료되기 전에 동일한 ID를 가진 워커"를 시작하는 것입니다. 스냅샷이 사라지면 소유권을 해제하고 "대체 머신이 이를 소유할 수 있습니다."

풀은 리포지토리에 종속되지 않습니다

컨텍스트에 영향을 미치는 또 다른 설계 세부 사항은 다음과 같습니다. "풀은 개별 리포지토리에 종속되지 않습니다. 요청은 풀만 식별하면 되며, 사용 가능한 모든 워커가 이를 처리할 수 있습니다. 이를 통해 하나의 풀이 여러 리포지토리를 지원할 수 있습니다."

효율적입니다. 하지만 이는 다음 요청을 처리하는 머신이 기본적으로 프로젝트의 이력을 가지고 있는 머신이 아닐 수도 있음을 의미합니다.

실행 환경을 이동시키며, 이것이 핵심입니다. Cursor에 따르면, 팀들은 일반적으로 "에이전트 도구 실행이 소스 제어, 내부 서비스 및 코드 리포지토리에 직접 액세스할 수 있는 자체 네트워크 내부에서 발생해야 할 때", 에이전트에 "GPU 또는 iOS 개발용 Mac과 같은 맞춤형 하드웨어"가 필요할 때, 또는 빌드 파이프라인을 "Cloud Agent 빌드로 패키징하기 어려울 때" 이를 사용합니다. 이는 실제 제약 사항이며, 이 기능은 이를 진정으로 해결합니다.

추론 레이어는 이동하지 않으며, 이는 의도된 설계입니다. Cursor는 "에이전트 루프, 추론 및 계획"을 실행합니다. 사용자의 워커는 "파일 편집 및 터미널 명령을 수행합니다. 또한 컴퓨터 사용 도구 및 로컬 MCP 서버를 실행합니다."

이는 Cursor만의 독특한 특징이 아닙니다. Anthropic의 Managed Agents를 위한 self-hosted 샌드박스에서도 거의 유사한 언어로 문서화된 동일한 형태가 나타납니다. self-hosting은 "오케스트레이션은 Anthropic 측에 유지하되 도구 실행은 사용자가 제어하는 인프라로 이동"시킵니다. 특히 메모리 레이어에 대해서는 다음과 같이 설명합니다. "에이전트의 기술과 세션에 연결된 모든 메모리 저장소의 콘텐츠는 Anthropic에 의해 저장되고 세션 동안 샌드박스로 복사되며, 에이전트가 메모리 파일에 가한 변경 사항은 다시 저장소로 동기화됩니다." Anthropic은 심지어 "AWS의 Claude Platform의 self-hosted 환경에서는 세션에 메모리 저장소를 연결할 수 없다"는 명확한 한계를 문서화해 두었습니다. 두 벤더 모두 동일한 아키텍처적 결론을 내렸습니다. 즉, self-hosting은 메모리나 추론 레이어가 아닌 샌드박스를 재배치하는 것입니다. 이러한 호스팅된 저장소의 메커니즘은 그 자체로 이해할 가치가 있으며, 이에 대해서는 Claude의 에이전트 메모리 저장소에서 다루고 있습니다.

이것이 자체적으로 개인정보 보호 태세를 악화시키지는 않습니다. Cloud Agents는 "Privacy Mode로 실행"되며, 이 모드가 켜져 있으면 "Cursor는 Cloud Agents가 액세스한 코드나 실행 시 생성된 프롬프트 및 응답을 학습에 절대 사용하지 않습니다." 요청 시 에이전트의 대화 트랜스크립트와 아티팩트를 제거하는 Delete Agent API가 있으며, Enterprise 팀은 "보존 정책을 통해 대화 보존 기간을 제한할 수도 있습니다." Runtime Secrets는 "트랜스크립트, 도구 출력 및 커밋에서 제거되어 모델에 절대 도달하지 않습니다." 이는 의미 있는 통제 수단이며 문서화되어 있습니다.

"이제 아무것도 네트워크를 벗어나지 않는다." 가장 흔한 해석이자 Cursor의 자체 문장이 바로잡는 부분입니다. 도구 출력은 추론을 위해 다시 전송되며 코드 조각이 포함될 수 있습니다. 그대로 유지되는 것은 체크아웃, 빌드 캐시 및 머신 로컬 자격 증명입니다. 이는 "아무것도 벗어나지 않는다"는 주장과는 진정으로 다르고 더 좁은 범위의 주장입니다.

"머신이 우리 소유이므로 에이전트가 더 많이 기억할 것이다." 풀(pool) 구성의 경우 정반대입니다. 머신을 소유한다고 해서 에이전트의 메모리가 확장되는 것은 아닙니다. 오히려 사용자가 직접 관리해야 하는 해제 타이머가 도입됩니다. 최대 절전 모드가 없으면 유휴 상태로 해제된 머신은 다음 후속 요청이 새로운 하드웨어에서 시작됨을 의미합니다.

"최대 절전 모드가 켜져 있다." 이는 자동으로 켜지는 스위치가 아니라 직접 구현해야 하는 패턴입니다. 유휴 해제 시간 초과를 단축하고, 유휴 상태일 때 스냅샷을 찍고, 할당되었지만 오프라인 상태인 큐 항목을 모니터링하고, 창이 만료되기 전에 복원해야 합니다. 이는 직접 작성하고 운영해야 하는 컨트롤러입니다.

"트랜스크립트도 이제 우리 쪽에 저장된다." 그렇지 않습니다. 대화 상태는 Cursor 백엔드에 위치하며 기본적으로 무기한 보관됩니다. 요청 시 삭제 가능하고 정책에 의해 제한될 수 있지만, Self-Hosted Machines에 의해 재배치되지는 않습니다.

"하나의 풀, 하나의 프로젝트." 풀은 모든 리포지토리를 지원합니다. 특정 리포지토리를 위해 웜 워크스페이스(warm workspace)를 유지하기 위해 머신 어피니티(machine affinity)에 의존하고 있었다면, 이는 풀이 보장하는 바가 아닙니다.

1단계: 설정에서 각 상태 유형이 어디에 위치하는지 기록하기

15분 정도 시간을 내어 자체 배포를 위한 4줄짜리 표를 만들어 보십시오. Cursor 문서에서 3줄을 제공하며, 4번째 줄은 여러분의 몫입니다.

체크아웃, 빌드 캐시, 머신 로컬 자격 증명 — 사용자의 머신, 워커가 재설정될 때 사라짐. 런타임 워크스페이스 — 사용자의 머신, 유휴 상태 후 재활용됨. 대화 트랜스크립트 — Cursor 백엔드, 기본적으로 무기한 보관. 지속성 프로젝트 지식 — 이 부분은 대부분의 팀이 채우지 못하는 줄입니다. 왜냐하면 그 답이 "해당 내용이 우연히 포함된 트랜스크립트 내부"이기 때문입니다.

이 네 번째 줄이 모든 문제의 핵심입니다. 그 위의 모든 것은 의도적으로 일시적이거나 벤더에 의해 보관됩니다.

2단계: 타이머를 의도적으로 설정하고 해제 상태 확인하기

두 개의 조절 노브가 있으며, 이들의 상호작용이 문제를 일으킵니다. 1시간 기본값을 그대로 상속받기보다는 의도를 가지고 워커 연결의 유휴 시간 초과를 구성하고, 풀이 최대 절전 모드를 사용할지 여부를 명시적으로 결정하십시오.

그런 다음 실제로 관심 있는 케이스를 테스트해 보십시오. 에이전트를 시작하고, 실제 워크스페이스 상태를 빌드하게 한 다음, 유휴 시간 초과가 지날 때까지 기다렸다가 후속 요청을 보내십시오. 에이전트가 바로 재개하는지, 아니면 처음 몇 분 동안 재구성하는 데 시간을 보내는지 관찰하십시오. 이를 한 번만 수행해 보면 풀이 어떻게 작동하는지 알 수 있으며, 이는 문서에서 추론하는 것보다 훨씬 가치 있습니다.

이 작업을 수행하는 동안 컨트롤러가 오프라인 경로를 처리하는지 확인하십시오. Cursor는 오프라인 머신에 대한 후속 요청을 claimedWorkerId 및 wakeTimeoutMs가 포함된 '할당되었지만 오프라인 상태'인 큐 항목으로 알리고 일치하는 이벤트를 방출합니다. 인프라에서 이를 감시하는 것이 없다면 최대 절전 모드가 실제로 구성된 것이 아닙니다.

3단계: 유지되어야 하는 지식을 모든 머신과 트랜스크립트 외부에 배치하기

1단계와 2단계를 통해 정확한 맵과 예측 가능한 타이머를 확보할 수 있습니다. 하지만 근본적인 질문에는 답하지 못합니다. 새로운 워커가 후속 요청을 할당받았을 때, 에이전트는 사용자의 규칙을 어떻게 알 수 있을까요?

현재의 답은 "트랜스크립트에 포함되어 있다면 거기서 가져온다"입니다. 이로 인해 지속성 지식은 대화 이력의 부산물이 됩니다. 즉, 벤더가 보유하고, 기본적으로 무기한 보관되며, 주제별이 아닌 세션별로 구성됩니다. 이는 모든 실행에서 참이어야 하는 사실들을 정리하기에는 형편없는 파일링 시스템이며, 동일한 논리가 모든 상태 비저장(stateless) 실행 레이어에 적용됩니다. 이것이 바로 MCP 작업을 위한 메모리가 동일한 결론에 도달하는 이유입니다.

별도의 메모리 레이어를 사용하면 질문에서 머신을 완전히 배제할 수 있습니다. 어떤 풀의 어떤 리포지토리에서 어떤 워커가 요청을 할당받든, 에이전트는 동일한 저장소를 읽습니다. 최대 절전 모드는 후속 요청과 유능한 답변 사이를 가로막는 장애물이 아니라, 워크스페이스 웜 상태 유지를 위한 비용 최적화 수단이라는 본연의 역할을 하게 됩니다. MemoryLake는 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인하고 대시보드에서 API 키를 생성합니다. 이 자격 증명은 워커, 풀 또는 머신 이미지가 아닌 사용자에게 바인딩됩니다. 이는 다음 프롬프트에 응답하는 머신이 컨트롤러에 의해 90초 전에 시작된 머신일 때 매우 중요한 특성입니다.

2단계: 첫 번째 메모리 업로드

새로운 워커가 체크아웃에서 재구성할 방법이 없는 정보들을 입력하십시오. 아키텍처 결정과 그 배경 이유, 배포 규칙, 에이전트가 액세스할 수 있는 내부 서비스, 이미 세 개의 서로 다른 세션에 입력했던 수정 사항 등이 이에 해당합니다.

일시적인 것은 일시적으로 남겨두십시오. 빌드 캐시와 체크아웃은 재활용되어야 하며, 이는 손실이 아닙니다.

3단계: AI 및 에이전트 연결

에이전트가 저장소를 가리키도록 설정하십시오. 그러면 풀링된 요청이 이미 프로젝트 지식을 보유한 상태로 도착하므로, 워크스페이스를 재구성하는 데 재설명 대신 몇 분의 빌드 시간만 소요됩니다.

첫 번째 변화는 풀 튜닝이 지식 결정이 아닌 경제적 결정이 된다는 점입니다. 현재로서는 비용을 절감하기 위해 유휴 시간 초과를 단축하면 에이전트가 알고 있는 내용도 단축됩니다. 이 두 가지가 동일한 레버여서는 안 됩니다.

두 번째는 교차 리포지토리 풀을 설계된 대로 안전하게 사용할 수 있게 된다는 점입니다. 여러 리포지토리를 지원하는 하나의 풀이 효율적인 이유는 워커가 서로 대체 가능하기 때문입니다. 그리고 대체 가능한 워커는 지식이 워커 내부에 위치할 때만 문제가 됩니다.

세 번째는 지속성 지식이 더 이상 보존 정책의 파생물이 되지 않는다는 점입니다. 대화 보존 기간을 제한하는 것은 훌륭한 거버넌스이지만, 이로 인해 에이전트가 코드베이스에 대해 이해하고 있는 내용이 암묵적으로 감소해서는 안 됩니다. 이 두 가지를 분리하는 것은 제품별이 아닌 도구 간에 하나의 메모리 공유하기의 원칙과 동일합니다.

• 요약이 아닌 실제 경계를 인용하십시오. 실행 환경만 이동하며, 에이전트 루프, 추론 및 계획은 Cursor 클라우드에 유지되고, 도구 출력은 추론을 위해 다시 전송됩니다.
• 유휴 시간 초과를 의도적으로 설정하십시오. 연결 기본값은 1시간입니다. 이것이 팀의 후속 요청 전송 방식과 일치하는지 결정하십시오.
• 최대 절전 모드를 직접 운영하는 인프라로 취급하십시오. 유휴 상태일 때 스냅샷을 찍고, 할당되었지만 오프라인 상태인 항목을 모니터링하며, 창 내에 동일한 워커 ID로 복원하십시오.
• 머신 어피니티에 의존하지 마십시오. 풀은 리포지토리에 종속되지 않으며, 사용 가능한 모든 워커가 요청을 처리할 수 있습니다.
• 기존의 보존 통제 수단을 사용하십시오. 특정 트랜스크립트를 위한 Delete Agent API, 기간 제한을 위한 Enterprise 보존 정책, 트랜스크립트 및 커밋에서 값을 완전히 배제하기 위한 Runtime Secrets를 활용하십시오.
• 조직 전체에서 Privacy Mode를 표준으로 유지하십시오. 레거시 Privacy Mode는 Cloud Agents에서 지원되지 않으며, 문서는 모든 실행이 보장을 상속받을 수 있도록 표준 모드를 강제할 것을 권장합니다.
• 새로운 워커가 무엇을 알고 있는지 감사하십시오. 만약 답이 어떤 트랜스크립트가 연결되어 있는지에 따라 달라진다면, 그 지식은 아직 지속성을 갖추지 못한 것입니다.
• 변경 사항이 있으면 다시 확인하십시오. 이 기능은 2026년 9월 2일에 샌드박스 제공업체 통합 및 Linux 컴퓨터 사용 기능과 함께 출시되었습니다. 빠르게 변화하는 기술 영역은 계속 움직입니다.

Self-Hosted Machines는 실제 제약 조건에 대한 실질적인 해결책이며, Cursor는 관련 보도들보다 그 경계를 더 신중하게 문서화했습니다. 실행 환경은 사용자의 네트워크 내부로 이동합니다. 하지만 에이전트 루프, 추론 및 트랜스크립트는 이동하지 않습니다.

실제적인 결과는 헤드라인보다 더 좁은 범위이면서도 더 유용합니다. 풀링된 배포에서 인프라 시간 초과는 이제 에이전트가 정보를 알고 있는 상태에서 후속 요청을 시작할지, 아니면 처음부터 다시 시작할지를 결정하는 데 도움을 줍니다. 이 타이머를 의도적으로 설정하고, 워크스페이스 웜 상태 유지가 중요하다면 최대 절전 모드를 구현하며, 모든 릴리스에서 살아남아야 하는 지식은 어떤 워커도 소유하지 않는 레이어에 보관하십시오.