Cursor Cloud Agent가 빌드(Builds)를 사용해도 컨텍스트를 잊어버리는 이유 (2026)

빌드는 모델이 아닌 머신을 준비합니다

빌드에 실제로 무엇이 포함되어 있는지 읽어보세요. 문서는 개발 환경을 "노트북의 설정과 유사함: 클론된 리포지토리, 설치된 의존성, 시크릿, 시작 명령 및 네트워크 액세스"로 설명하며, 이는 에이전트 주도 설정, 저장된 스냅샷 또는 Dockerfile을 통해 .cursor/environment.json으로 구성됩니다. 빌드는 에이전트가 "리포지토리와 의존성이 준비된 상태에서 시작"할 수 있도록 해당 환경을 미리 준비하며, 에이전트는 항상 가장 최근에 성공한 빌드에서 시작합니다. 의존성 업데이트로 인해 환경이 깨지면 실패한 빌드는 절대 활성화되지 않습니다.

이 목록의 모든 항목은 인프라입니다. 그 중 지식에 해당하는 것은 단 하나도 없습니다. 설치 명령은 빌드 생성 중에 한 번 실행되고 시작 명령은 세션마다 재실행되는데, 이는 서비스와 컨테이너에 정확히 맞는 설계이지만, 에이전트가 이번 스프린트에서 결제 모듈에 파괴적 변경(breaking change)을 적용하면 안 된다는 사실을 알고 있는지 여부와는 완전히 무관합니다.

Cursor는 환경이 얼마나 중요한지 직접적으로 언급합니다. "에이전트는 자신이 실행되는 환경만큼만 유능하다", 그리고 "환경 설정은 클라우드 에이전트의 효과를 개선하는 가장 중요한 단계이다"라고 말이죠. 이는 사실이며, 빌드는 이를 저렴하게 만들어 줍니다. 다만 이는 사람들이 세 번째 클라우드 실행에서 동일한 실수를 반복한 후 던지는 질문과는 다른 질문에 답하고 있을 뿐입니다.

트리거가 브리핑의 전부입니다

로컬 세션에서는 대화가 이루어집니다. 하지만 클라우드 에이전트는 그렇지 않은 경우가 많습니다. 문서화된 진입점에는 Cursor Desktop, cursor.com/agents의 Cursor Web, iOS 앱 또는 Android PWA, @cursor 명령을 통한 Slack, GitHub 또는 Bitbucket 풀 리퀘스트나 이슈에서 @cursor를 언급하는 댓글, Linear, 그리고 API가 포함됩니다.

이들 대부분의 공통점을 살펴보세요. 에이전트는 누군가가 작성한 단 하나의 메시지에 의해 실행되며, 종종 편집기 앞에 앉아 있지 않은 상태이거나 코드를 작성하지 않은 팀원에 의해 실행되기도 합니다. 그 메시지가 브리핑의 전부입니다. 에이전트가 리포지토리 콘텐츠 외에 알게 될 모든 것은 그 한 문장과 스스로 읽는 파일들에서 나옵니다. 그리고 Linear 티켓에서 휴대폰으로 작성된 한 문장은 로컬 세션에서 에이전트와 20분 동안 대화해 온 것에 비하면 매우 빈약한 브리핑입니다.

이것이 바로 실패가 로컬에서의 망각과는 다르게 느껴지는 이유이기도 합니다. 로컬에서는 에이전트가 흐름을 놓치는 것을 감지하고 다시 설명할 수 있습니다. 반면 클라우드 실행에서는 이를 감지할 사람이 방에 없기 때문에, 오해가 그대로 풀 리퀘스트로 이어지게 됩니다.

규칙은 유일한 지식 채널이며, 그 중 한 가지 형태는 경고 없이 실패합니다

트리거가 빈약하기 때문에, 모든 지속적인 지식은 리포지토리에 존재해야 합니다. Cursor의 규칙 문서에서도 이를 명시적으로 밝히고 있습니다. "대형 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다." 규칙은 문서화된 네 가지 형태, 즉 버전 관리 하의 .cursor/rules에 있는 .mdc 파일 형태의 프로젝트 규칙, Cursor 환경에 글로벌하게 적용되는 사용자 규칙, Team 및 Enterprise 플랜의 대시보드에서 관리되는 팀 규칙, 그리고 하위 파일 지원 및 더 구체적인 파일이 우선순위를 갖는 프로젝트 루트의 AGENTS.md로 제공됩니다.

동일한 문서에서 인용한 함정이 여기 있습니다. ".cursor/rules에 있는 일반 .md 파일은 description, globs, alwaysApply를 지정하는 프런트매터(frontmatter)가 없기 때문에 규칙 시스템에 의해 무시됩니다."

경고도 없고, 에러도 없으며, 로그에 기록도 남지 않습니다. 규칙처럼 보이고, 규칙 디렉토리에 있으며, 작동하는 것처럼 읽히는 파일이 말이죠. 이는 규칙이 일반 마크다운이었던 다른 도구에서 마이그레이션해 온 팀들에게 가장 큰 타격을 주며, 가장 감당하기 힘든 곳인 클라우드 실행에서 보이지 않게 작동합니다. 세션을 지켜보며 컨벤션 파일이 로드되지 않았음을 알아챌 사람이 아무도 없기 때문입니다. 규칙이 로드되는 시점을 결정하는 네 가지 적용 모드(alwaysApply: true, 지능적 적용을 위한 description, 특정 파일을 위한 globs, 또는 명시적인 @-mention이 필요한 수동 적용)와 함께 살펴볼 가치가 있습니다. 수동 적용으로 설정된 규칙은 클라우드 에이전트 실행 시 자동으로 로드되지 않습니다.

클라우드 작업에는 두 가지 제약 조건이 더 중요합니다. 문서는 규칙을 500행 미만으로 유지하고 큰 규칙은 조립 가능한 조각으로 분할할 것을 권장합니다. 이는 항상 로드되는 채널이 의도적으로 좁게 설계되었음을 의미합니다. 또한 globs로 범위가 지정된 규칙은 일치하는 파일이 사용될 때만 컨텍스트에 들어옵니다. 이는 적절하지만, 에이전트가 어떤 파일을 건드릴지 결정하기 전까지는 영역별 지식이 보이지 않는다는 것을 의미합니다.

문서에는 유지되는 항목들이 나열되어 있지만, 메모리는 그 목록에 없습니다

이 부분은 신중하게 다루고 싶습니다. Cursor의 클라우드 에이전트 문서는 환경, 스냅샷, 빌드, .cursor/hooks.json의 훅, "에이전트가 전체 작업 공간을 검사하고 조율된 변경을 수행할 수 있는" 멀티 리포지토리 작업 공간, 선택 가능한 컨텍스트 창 크기와 함께 "클라우드 에이전트가 엄선된 모델을 사용함"을 나타내는 모델 선택, 그리고 에이전트가 사용한 환경 및 빌드와 버전 기록을 보여주는 대시보드를 다룹니다.

하지만 서로 다른 에이전트 실행 간에 컨텍스트, 상태 또는 메모리가 유지되는 것에 대해서는 설명하지 않습니다. 규칙 문서 역시 메모리 기능에 대한 언급이 없으며, 이 글을 쓰는 시점에 cursor.com/docs/agent/memories는 404 페이지를 반환합니다. 따라서 정확한 주장은 "Cursor에 메모리가 없다"가 아니라, 실행 간에 지식을 전달하기 위해 문서화된 메커니즘은 규칙 파일뿐이며, 문서의 그 어디에서도 에이전트의 두 번째 실행이 첫 번째 실행으로부터 리포지토리에 있는 것 외에 다른 것을 상속받는다고 보장하지 않는다는 것입니다.

문서화된 내용을 바탕으로 계획을 세우세요. 만약 여러분의 팀이 클라우드 에이전트가 지난주를 기억할 것이라는 문서화되지 않은 가정에 의존하고 있다면, 그 가정은 문서상 아무런 지원을 받지 못하며, 그 증상은 실행 간의 불일치로 나타날 것입니다. 이는 Cursor가 이전 세션을 잊어버리는 이유에서 설명한 로컬 문제의 클라우드 버전입니다.

더 긴 규칙 파일 작성하기. 자연스러운 조치이지만, 500행 제한 권장 사항과 충돌합니다. 특정 크기를 넘어서면 항상 로드되는 파일은 모델의 주의를 끌기 위해 실제 작업과 경쟁하는 텍스트의 장벽이 됩니다. 그리고 그 안의 모든 내용은 관련 여부와 관계없이 매 실행마다 비용으로 지불됩니다.

트리거 댓글에 컨텍스트 넣기. 단 한 번의 실행에는 효과가 있습니다. 하지만 이는 티켓을 등록하는 사람이 모든 프로젝트 제약 조건을 알고 있어야 하고 이를 매번 다시 언급해야 함을 의미하므로, 에이전트에게 작업을 위임하는 목적에 어긋나며 다음 티켓까지 유지되지도 않습니다.

환경에 추가하기. 사람들은 지식을 설정으로 인코딩하려고 시도합니다. 예를 들어 설치 스크립트가 출력하는 README 파일이나 시작 명령이 에코하는 파일 등이 있습니다. 환경은 의존성과 서비스를 위한 것입니다. 이를 통해 전달되는 지식은 취약하며 코드 리뷰에서 보이지 않습니다.

대신 모든 것을 로컬에서 실행하기. 가장 안전하지만 가장 비용이 많이 드는 답변입니다. 팀원이 자신의 머신 없이도 Slack이나 PR 댓글에서 작업을 트리거할 수 있다는 클라우드 에이전트의 존재 이유를 포기하게 됩니다.

규칙이 로드되었다고 가정하기. 매우 흔한 일이며, 일반 .md 함정으로 인해 상황은 더 악화됩니다. 팀들은 파일이 컨텍스트에 전혀 포함되지 않았음에도 모델을 디버깅합니다. 모델을 탓하기 전에 규칙이 실제로 적용되었는지 확인하세요. 이는 Cursor가 프로젝트 규칙을 잊어버리는 이유에서 설명한 실패 패턴입니다.

더 많은 에이전트 생성하기. 병렬 클라우드 에이전트는 문제를 해결하는 대신 배가시킵니다. 각각의 에이전트는 자신만의 빈약한 브리핑에서 시작하며, 다른 에이전트가 어떤 결론을 내렸는지 알지 못합니다. 이는 멀티 에이전트 메모리에서 다루는 형태입니다.

구조적인 문제는 클라우드 에이전트가 단 두 개의 입력(트리거와 리포지토리)만 가지며, 그 중 하나는 한 문장에 불과하다는 점입니다. 규칙 파일은 매 실행마다 컨텍스트에 있어야 하는 소수의 항목만 처리할 수 있습니다. 규칙 파일이 담을 수 없는 것은 늘어나는 프로젝트 지식입니다. 즉, 결정 사항, 기각된 접근 방식, 이상해 보이는 코드를 올바른 선택으로 만든 제약 조건 등입니다. 이러한 자료는 항상 로드되는 파일에 담기에는 너무 방대하고, 종료된 로컬 세션에 남겨두기에는 너무나 가치 있습니다.

MemoryLake는 에이전트가 항상 들고 다녀야 하는 파일 대신, 필요할 때 쿼리할 수 있는 지식의 보금자리를 제공합니다. 모든 연결된 에이전트가 읽을 수 있는 메모리 레이어를 제공하므로, PR 댓글로 트리거된 실행에서도 팀이 이미 결정한 사항을 찾아볼 수 있습니다. 설정은 세 단계로 이루어집니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 모든 에이전트가 하나의 자격 증명을 공유하므로 중요합니다. 클라우드 실행은 여러 플랫폼에서 트리거되므로 플랫폼별로 구성을 다르게 하고 싶지 않기 때문입니다.

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

규칙 파일에 담을 수 없는 지식을 로드하세요. 아키텍처 결정 사항과 그 배경 논리, 시도했다가 포기한 접근 방식과 그 이유(빈약한 브리핑을 받은 새로운 에이전트가 그렇지 않으면 이를 다시 자신 있게 제안할 것이므로 가장 가치 있는 카테고리입니다), 컨텍스트 없이는 임의적으로 보이는 제약 조건, 아무도 적어둘 생각을 하지 않아 사람들의 머릿속에만 존재하는 컨벤션 등이 이에 해당합니다. 에이전트가 조치를 취할 수 있는 결과를 반환할 수 있도록 각 항목은 짧고 하나의 아이디어만 담도록 유지하세요.

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

에이전트를 연결합니다. MemoryLake는 MCP 및 API를 통해 접근할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 도구들은 API를 통해 동일한 메모리를 읽습니다. 규칙은 매 실행마다 컨텍스트에 있어야 하는 소수의 항목이라는 좁은 역할을 계속 수행합니다. 그 외의 모든 것은 검색 가능해지므로, 빈약한 트리거가 빈약한 브리핑을 의미하지 않게 됩니다. MCP 측을 처음 구성하는 경우, MCP로 크로스 AI 메모리 설정하기에서 단계를 안내합니다.

솔직한 한계도 있습니다. MemoryLake는 클라우드 실행을 감시하지 않으며, 누군가 기록하지 않는 한 에이전트가 학습한 내용을 캡처하지 않습니다. 또한 강제 적용 레이어가 아닙니다. 모델이 무엇을 결정하든 반드시 지켜져야 하는 규칙이 있다면, 이는 훅이나 CI 검사에 속해야 하며, 이것이 바로 .cursor/hooks.json이 존재하는 이유입니다. 그리고 규칙 파일을 대체하지도 않습니다. 두 가지는 서로 다른 역할을 수행하며, 어느 한쪽에 두 가지 역할을 모두 요구하는 것은 실수입니다.

빈약한 트리거가 빈약한 결과물로 이어지지 않습니다. 티켓을 등록하는 사람이 더 이상 모든 제약 조건을 기억하는 사람일 필요가 없습니다. 이것이 클라우드 에이전트의 진정한 약속이며, 에이전트 없이도 제약 조건에 접근할 수 있을 때만 유효합니다.

클라우드와 로컬 실행이 수렴합니다. 현재는 긴 대화 끝에 편집기에서 실행했는지, 아니면 Slack 메시지에서 실행했는지에 따라 동일한 요청이 다른 결과물을 만들어내는 경우가 많습니다. 두 환경 모두 동일한 메모리를 읽을 때 플랫폼은 더 이상 중요하지 않게 되며, 이는 컨텍스트가 한 머신에만 머무르는 현상이 사라짐을 의미합니다.

규칙 파일이 짧아지고, 따라서 더 좋아집니다. 항상 로드되는 채널에서 참조 지식을 제거하는 것은 단순히 깔끔함만을 위한 것이 아닙니다. 이를 통해 500행 권장 사항을 준수할 수 있으며, 매번 진정으로 적용되어야 하는 규칙들과 경쟁하는 노이즈를 줄일 수 있습니다.

반복되는 수정 사항이 더 이상 반복되지 않습니다. 클라우드 에이전트를 사용하면서 가장 힘 빠지는 경험은 세 번째 실행에서 첫 번째 실행 때 수정했던 실수를 다시 저지르는 것을 보는 것입니다. 이는 수정 사항이 세션에만 머물렀고, 세션은 종료되었기 때문에 발생합니다. 한 번 기록해 두면 이후의 모든 실행에서 사용할 수 있습니다.

리뷰가 짧아집니다. 에이전트가 작성한 풀 리퀘스트에 대한 대부분의 리뷰 댓글은 코드 품질에 대한 것이 아니라 에이전트에게 없었던 컨텍스트에 대한 것입니다. 컨텍스트를 제공하면 리뷰의 상당 부분이 사라집니다.

지금 바로 `.cursor/rules`에서 일반 `.md` 파일을 감사하세요. 프런트매터에 description, globs, alwaysApply를 지정하지 않은 파일은 아무런 경고 없이 무시됩니다. 이는 특히 다른 도구에서 마이그레이션된 리포지토리에서 높은 적중률을 보이는 5분짜리 점검입니다. 이는 Windsurf에서 Cursor로 마이그레이션하기에서 설명한 것과 동일한 전환 함정입니다.

각 규칙이 어떤 모드를 사용하는지 파악하세요. 항상 로드되어야 하는 소수의 규칙에는 alwaysApply: true를, 영역별 규칙에는 globs를, 지능적 적용에는 description을 사용하세요. @-mention이 필요한 수동 규칙은 무인 클라우드 실행에서 자동으로 로드되지 않으므로 로컬 전용으로 취급하세요.

에이전트가 리포지토리 외에는 아무것도 모른다고 가정하고 트리거를 작성하세요. 실제로 모르기 때문입니다. 목표와 수락 기준을 명시하고, 배경 지식은 검색 가능한 레이어가 제공하도록 하세요.

실행이 잘못되었을 때는 환경 대시보드를 사용하세요. 문서는 에이전트가 사용한 환경과 빌드, 그리고 버전 기록을 보여준다고 설명합니다. 실행이 이전과 다르게 동작했다면 모델이 변경되었다고 가정하기 전에 다른 빌드에 있었는지 확인하세요.

반드시 지켜야 하는 제약 조건은 줄글이 아닌 훅(hooks)에 넣으세요. 클라우드 에이전트는 .cursor/hooks.json에서 명령 기반 훅을 실행합니다. 모든 변경 사항에 대해 참이어야 하는 모든 것은 제안이 아닌 강제 적용을 위해 훅에 속해야 합니다.

시크릿은 메모리에 넣지 마세요. 환경 시크릿은 환경 구성에 속합니다. 메모리 레이어는 자격 증명이 아닌 지식을 보관하는 곳입니다.

빌드는 진정한 개선 사항이며 가격 정책도 반박하기 어렵습니다. 무료이며, 8월 17일부터 기본적으로 활성화되고, 에이전트는 콜드 머신 대신 항상 마지막으로 성공한 빌드에서 시작합니다. 지금 남아 있는 격차에 대해 이야기할 가치가 있는 이유는 빌드가 핑곗거리를 없애주기 때문입니다. 클라우드 에이전트가 부팅하는 데 4분이 걸렸을 때는 느린 속도가 문제처럼 느껴졌습니다. 하지만 몇 초 만에 시작하여 지난달에 거부했던 디자인을 즉시 제안하는 것을 보면 속도가 결코 문제가 아니었음이 명백해집니다.

해결책은 더 긴 규칙 파일이 아닙니다. 클라우드 에이전트가 두 개의 입력을 가지며, 그 중 하나는 단 한 문장이고, 팀이 알고 있는 다른 모든 것은 나머지 하나에서 검색할 수 있어야 한다는 점을 인식하는 것입니다. Cursor가 이제 머신을 예열하는 것처럼, 지식을 예열하세요.