Cursor Projects, 몇 달 동안 컨텍스트 유지 — 파일에 담기지 않은 것은 다음 에이전트에 전달되지 않는다 (2026)

출시 발표 글은 범위에 대해 구체적으로 설명합니다. Cursor는 Projects가 "기능 개발, 마이그레이션 또는 전체 앱 개발과 같이 더 큰 규모의 작업을 수행할 수 있게 해줍니다. 수개월 간의 작업에 걸쳐 컨텍스트를 유지하고, 수천 개의 서브 에이전트에 작업을 위임하며, 프롬프트 없이도 반복적인 작업을 수행합니다"라고 설명합니다.

코디네이터는 의도적으로 코더가 아닙니다. "프로젝트의 코디네이터 에이전트는 스스로 코드를 작성하지 않습니다. 작업을 계획하고, 이를 구현할 에이전트에게 위임하며, 완료된 작업을 검토할 수 있도록 사용자에게 가져옵니다." 또한 사용자가 없는 곳에서 실행됩니다. "Project는 클라우드의 자체 컴퓨터에서 실행되므로 노트북을 닫아도 중단되지 않습니다." 그리고 Slack 채널, 일정 또는 풀 리퀘스트 세트를 모니터링하여 스스로 작업을 시작할 수 있습니다.

컨텍스트와 관련하여 가장 중요한 섹션은 Cursor가 발표문 자체에서 "공유 컨텍스트(Shared context)"라고 제목을 붙인 부분입니다:

"각 Project는 에이전트가 사용하는 모든 클라우드 및 로컬 머신에 동기화되는 파일 세트를 유지합니다. 에이전트는 코드베이스에 대해 학습한 내용과 사용자가 선호하는 작업 방식과 함께 연구 결과 및 아티팩트(artifacts)를 추가합니다."

그리고 그 메커니즘을 드러내는 예시는 다음과 같습니다. "예를 들어, 한 에이전트가 서비스 테스트 방법을 알아내면 향후 모든 에이전트가 해당 지침을 사용할 수 있습니다. 공유 컨텍스트는 Project와 함께 성장하여 시간이 지남에 따라 코디네이터를 더 효과적으로 만듭니다."

이 예시를 자세히 읽어보세요. 혜택은 실재하며, 조건부입니다. 향후 모든 에이전트가 해당 지침을 사용할 수 있는 이유는 에이전트가 이를 파일에 기록했기 때문입니다. 지식이 전달된 것은 에이전트들이 연결되어 있어서가 아닙니다. 기록되었기 때문에 전달된 것입니다.

Cursor의 서브 에이전트 문서에서는 나머지 절반을 명시적으로 밝히고 있습니다:

"서브 에이전트는 깨끗한 컨텍스트로 시작합니다. 서브 에이전트는 이전 대화 기록에 액세스할 수 없으므로, 부모 에이전트가 프롬프트에 관련 정보를 포함합니다."

이 두 문장이 모델의 전부입니다. 서브 에이전트는 프롬프트와 체크아웃을 받습니다. 히스토리는 받지 못합니다. 부모 에이전트가 무엇을 포함할지 결정하며, Project의 동기화된 파일 세트가 부모 에이전트 이후에도 살아남는 유일한 것입니다.

단일 에이전트가 담을 수 있는 양은 변하지 않습니다. Cursor가 서브 에이전트를 격리하는 이유는 비용 때문입니다. "각 서브 에이전트는 자체 컨텍스트 창을 가집니다. 긴 연구나 탐색 작업이 메인 대화의 공간을 차지하지 않습니다." 코드베이스 탐색, 셸 명령, 브라우저 제어를 위한 세 가지 내장 서브 에이전트가 존재하는 이유는 이러한 작업이 노이즈를 많이 발생시키기 때문이며, Cursor가 밝힌 이유는 "중간 출력은 서브 에이전트에 남아 있고, 부모 에이전트는 최종 요약만 보기 때문"입니다.

따라서 설계상 다음 단계에 도달하는 것은 요약본입니다. 에이전트가 3시간 전에 이미 내린 결정을 자신 있게 다시 도출하는 것을 본 적이 있다면, 바로 이 설계의 결과를 경험한 것입니다. 이전 글인 코딩 에이전트가 실제로 읽는 것에서는 단일 에이전트 측면에서 동일한 경계를 다루었으며, Projects는 이를 워커 수만큼 곱해줍니다.

또한 공유 파일 세트가 완전한 기록이 되는 것도 아닙니다. Cursor는 이 부분에서도 신중합니다. 8월 19일 릴리스에서는 Projects 출시와는 별개로 자체 머신에서 실행되는 서브 에이전트가 도입되었습니다. "이제 서브 에이전트는 자체 가상 머신에서 실행될 수 있습니다. 각 서브 에이전트는 자체 클라우드 환경에서 깨끗한 컨텍스트를 가진 프로젝트의 격리된 복사본을 받습니다." 그리고 서브 에이전트 문서는 기본값에 대해 경고합니다. "서브 에이전트는 기본적으로 부모 에이전트의 체크아웃을 공유합니다. 여러 서브 에이전트가 동시에 파일을 편집하면 서로의 변경 사항을 덮어쓸 수 있습니다."

바뀌는 것은 프로젝트의 영구적인 부분이 어디에 존재하느냐입니다. Projects 이전에는 장기적인 작업이 열어둔 채팅창과 직접 관리하는 지침 파일 세트에 존재했습니다. Projects 이후에는 채팅이 전달자로서 사라지고(수백 개의 채팅이 각각 깨끗하게 시작됨), 파일 세트가 유일한 채널로 격상됩니다. 이것이 더 나은 아키텍처입니다. 또한 프로젝트 메모리의 품질은 이제 누군가가 기꺼이 기록해 둔 내용의 품질과 정확히 일치함을 의미합니다.

이것은 Cursor만의 관찰이 아닙니다. 이 카테고리가 도달한 결론입니다. Kiro의 Crew 문서는 "격리된 컨텍스트로 병렬 실행되는" 서브 에이전트를 설명합니다. Factory는 커스텀 드로이드(droid)를 "자체 시스템 프롬프트, 모델 및 도구 정책을 가지고 드로이드가 신선한 컨텍스트 창에서 집중적인 작업을 위임하는" 서브 에이전트로 정의합니다. Zencoder의 서브 에이전트 파이프라인은 "병렬 실행 및 깨끗한 컨텍스트 격리를 위해 서로 다른 모델, 컨텍스트 및 기술을 가진 격리된 하위 프로세스를 생성"합니다. Warp는 이식성에 대해 반대 접근 방식을 취하며 "Rules, Skills, MCP 서버 및 Codebase Context가 앱, CLI, 클라우드에서 동일하게 적용된다"고 말합니다. 다른 방향에서 내린 동일한 결론입니다. 즉, 영구적인 레이어는 대화형 레이어가 아니라 선언된 레이어라는 것입니다. 이것은 그들 중 누구도 비판하는 것이 아닙니다. 신선한 컨텍스트가 상속된 컨텍스트보다 낫다고 독립적으로 결정한 4개의 팀이 있으며, 4개 팀 모두 유지되어야 하는 부분을 채우는 역할을 사용자에게 남겨둔 것입니다.

"코디네이터가 기억하니까 내가 직접 기록할 필요는 없다." 코디네이터는 파일 세트를 유지합니다. 구전 역사를 유지하는 것이 아닙니다. 서브 에이전트가 학습하고 요약해 버린 모든 것은 파일에 저장되지 않는 한 해당 서브 에이전트의 실행이 끝날 때 사라집니다.

"수천 개의 서브 에이전트는 내 코드베이스에 대한 수천 개의 관점을 의미한다." 그것은 수천 번의 깨끗한 시작을 의미합니다. 폭은 병렬성에서 오고, 연속성은 기록된 레이어에서 옵니다. 긴 컨텍스트가 메모리가 아닌 이유에 대한 글은 모델 수준에서 동일한 구분을 제시합니다.

"이것은 Claude Code의 서브 에이전트와 동일한 문제입니다." 비슷하지만 동일한 대상은 아니며 구분할 가치가 있습니다. Claude Code의 서브 에이전트가 메모리를 공유하지 않는 문제는 단일 세션이 확장되었다가 다시 돌아오는 것에 관한 것입니다. Cursor Project는 사용자가 보지 못하는 머신들에서 수개월 동안 실행되는 "기능, 마이그레이션 또는 전체 앱"과 같은 작업 범위에 맞춰져 있습니다. 영향 범위가 다르며 해결책도 다릅니다. 마찬가지로, Cursor의 클라우드 에이전트가 컨텍스트를 잊어버리는 문제는 단일 원격 실행을 다루는 반면, 이것은 모든 실행보다 오래 살아남는 레이어에 관한 것입니다.

"Project는 우리 팀의 지식이 머물러야 할 곳이다." 일부는 그렇습니다. 하지만 Project는 해당 Project 범위로 제한됩니다. 팀이 2주 동안 논의한 컨벤션(다른 데이터베이스를 거부한 이유, 마이그레이션을 담당하는 서비스, 릴리스의 '완료' 정의 등)은 기능별 사실이 아닙니다. 이러한 지식은 이를 표면화한 Project보다 오래 지속되며, 다음 Project와 옆에 있는 동료가 사용하는 도구에서도 읽을 수 있어야 합니다.

목표는 아키텍처와 싸우는 것이 아닙니다. 프로젝트별 파일 세트에 프로젝트 간의 추론을 담아달라고 요구하는 것을 멈추는 것입니다.

1단계: 작업의 아티팩트와 프로젝트의 결정 사항 분리하기

Project가 축적하는 것들을 살펴보고 한 가지 질문으로 각 항목을 분류해 보세요. "이 기능이 출시된 후에도 이것이 여전히 유효한가?" "테스트를 위해 결제 서비스를 실행하는 방법"은 이 작업의 아티팩트이므로 Cursor가 지정한 위치에 정확히 들어맞습니다. "소유자 없이는 종속성을 추가하지 않는다"는 결정 사항이며, 다음 Project에서도, 에디터에서도, 3개월 후의 코드 리뷰에서도 똑같이 유효할 것입니다.

아티팩트는 Project에 들어갑니다. 결정 사항은 Project가 읽어오는 레이어에 들어갑니다.

2단계: 규칙뿐만 아니라 이유도 함께 기록하기

"여기에 리포지토리 패턴을 사용하라"는 문구를 읽은 코디네이터는 이를 따르겠지만 이유는 알지 못할 것입니다. 반면 "레거시 어댑터가 부하 상황에서 연결을 누수하여 프로덕션에서 문제가 발생했기 때문에 여기에 리포지토리 패턴을 사용한다"는 문구를 읽은 코디네이터는 해당 규칙이 언제 적용되지 않는지 판단할 수 있습니다. 이것이 지침 파일과 결정 기록(decision record)의 차이이며, 매번 새로 작성하는 대신 Project 간에 기록을 전달할 가치가 있는 이유입니다.

3단계: 모든 환경에서 접근할 수 있는 단일 주소 제공하기

Cursor는 "에이전트가 사용하는 모든 클라우드 및 로컬 머신에" Project 파일을 동기화하여 Project 내부의 이식성 문제를 해결합니다. 하지만 Project 간의 이식성이나 팀의 다른 도구 간의 이식성은 해결하지 못합니다. 결정 기록을 접근 가능한 곳에 두고 Project 파일 세트가 이를 가리키도록 설정하면, 동일한 단락을 네 군데에서 관리할 필요가 없어집니다. 프로젝트 문서를 AI 메모리로 전환하기에 대한 글에서 이 분류 과정을 더 자세히 다룹니다.

공유 결정 레이어는 바로 MemoryLake가 존재하는 이유입니다. 코디네이터, 로컬 에이전트, 그리고 이 모든 것을 한 번도 본 적 없는 다음 Project가 읽을 수 있는 단일 추론 저장소입니다.

1단계: API 키 생성하기

로그인하고 워크스페이스 설정을 연 다음 API 키를 생성합니다. 이 키는 에이전트와 에디터가 동일한 레이어를 읽는 데 사용하는 인증 정보이므로, 한 번 생성하여 작업하는 모든 환경에서 사용할 수 있도록 유지하세요.

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

이미 두 번 이상 설명한 결정 사항부터 시작하세요. 아키텍처 결정과 그 이유, 리뷰 주기를 거치며 살아남은 컨벤션, 코드만 봐서는 명확하지 않은 제약 조건 등이 이에 해당합니다. 코디네이터가 문서를 로드하지 않고도 즉시 조치를 취할 수 있도록 각 항목을 짧게 유지하세요.

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

실제로 사용하는 도구(에디터, 터미널 에이전트, 클라우드 실행 환경)를 연결하여 동일한 추론이 각 도구에 도달하도록 하세요. 서브 에이전트는 여전히 깨끗한 상태로 시작하지만, 프로젝트의 결정 사항이 이미 앞에 놓여 있는 상태로 시작하게 됩니다.

첫 번째 차이점은 Project가 끝날 때 나타납니다. 닫힌 Project에서 서서히 낡아가는 파일 세트 대신, 추론은 이미 다음 Project가 읽을 수 있는 곳에 존재하고 아티팩트는 원래 있어야 할 곳에 남게 됩니다.

두 번째는 코디네이터가 작업을 위임할 때 나타납니다. Cursor의 모델은 부모 에이전트가 프롬프트에 무엇을 넣을지 결정하도록 합니다. 영구적인 사실들이 부모 에이전트가 인용할 수 있는 레이어에 존재하면, 그 결정은 더 쉬워지고 일관성이 생깁니다. 또한 지난 5월에 해결한 질문에 대해 서브 에이전트들이 세 가지 다른 답을 내놓는 현상을 방지할 수 있습니다.

세 번째는 최악의 상황에서 나타납니다. 버그 보고 채널에 대해 프롬프트 없이 실행되는 Project는 결국 사용자가 취하지 않았을 행동을 취하게 될 것입니다. 그 이후에 던져야 할 유용한 질문은 '에이전트가 무엇을 바탕으로 작업했는가'이며, 요약본에서 재구성하는 대신 고정된 결정 사항이 기록되고 버전 관리될 때 이 질문에 답할 수 있습니다. AI가 기억하는 내용 감사하기는 이를 가능하게 하는 실천 방법입니다.

이전 히스토리가 없는 독자를 위해 작성하세요. 모든 서브 에이전트가 바로 그 독자입니다. "논의된 바와 같이"로 시작하는 항목은 잘못 해석될 가능성이 높습니다.

항상 참인 것과 현재만 참인 것을 분리하세요. 스프린트 상태는 Project에 속합니다. 고정된 결정 사항은 그 아래 레이어에 속합니다. 이 둘을 섞으면 스프린트가 끝나는 순간 레이어가 쇠퇴하기 시작합니다.

거절된 옵션을 기록하세요. 에이전트가 무언가를 다시 제안하는 것을 막는 가장 비용 효율적인 방법은 거절 사유와 그 이유를 한 번 기록해 두는 것입니다.

에이전트가 코드베이스에 대해 작성한 내용을 다시 읽어보세요. Cursor는 에이전트가 "코드베이스에 대해 학습한 내용과 사용자가 선호하는 작업 방식"을 추가한다고 말합니다. 이는 정말 유용한 메커니즘이지만 동시에 추론이기도 합니다. 처음 몇 개의 항목은 초안으로 취급하고 수정하세요. 새로운 팀원의 온보딩 노트를 수정하는 것과 마찬가지입니다.

인수인계 과정에서 손실이 발생한다고 가정하고 비용을 낮추세요. 에이전트 간의 채널을 넓힐 수는 없습니다. 채널을 통해 이동하는 것이 대화 기록이 아니라 결론이 되도록 할 수는 있습니다.

Cursor Projects는 훌륭한 엔지니어링 결과물이며, 그 컨텍스트 모델은 정직합니다. 서브 에이전트는 깨끗하게 시작하고, 부모 에이전트는 필요한 것을 제공하며, Project의 동기화된 파일이 살아남는 전부입니다. 그 결과는 설명하기는 간단하지만 놓치기 쉽습니다. 모든 워커가 아무것도 없는 상태에서 시작하는 아키텍처에서, 기록된 레이어는 있으면 좋은 것이 아닙니다. 그것은 오늘 일어나는 일과 다음 달에 일어날 일 사이의 유일한 대역폭입니다.

Projects는 베타 버전이며 모든 사용자에게 배포 중입니다. 코디네이터에게 수개월 간의 작업을 맡기려 한다면, 가장 레버리지가 높은 1시간은 프롬프트를 작성하는 시간이 아닙니다. 에이전트가 기억해 주기를 기대했던 결정 사항들을 기록하는 시간입니다.