Cursor Automations가 실행 간에 유지하는 메모리를 보호하는 방법 (2026년 가이드)

Cursor 문서에 기술된 내용부터 시작해 보겠습니다. "Memories를 사용하면 에이전트가 동일한 자동화에 대해 실행 간에 영구적인 노트를 읽고 쓸 수 있습니다. 이를 사용하여 시간이 지남에 따라 기억하고 개선되는 에이전트를 구축하십시오. 각 메모리는 에이전트의 작업 파일 시스템 외부에 존재하는 명명된 항목(기본적으로 MEMORIES.md)으로 저장됩니다."

이 단락의 세 가지 세부 사항이 다른 모든 것을 결정합니다. 노트는 사용자가 아닌 에이전트가 작성합니다. 노트는 "실행 간에" 유지되므로 오늘 작성된 노트가 향후 모든 실행에 영향을 미칩니다. 그리고 노트는 "동일한 자동화"에 속하므로 각 자동화는 메모리를 공유하는 대신 자체 메모리를 가집니다.

기본값과 제어 기능은 다음과 같습니다. "Memories는 기본적으로 활성화되어 있지만 비활성화할 수 있습니다. Memories는 도구 구성 UI에서 보고 편집할 수 있습니다." 삭제는 양방향으로 작동합니다. "에이전트는 자동화 실행 중에 오래된 메모리 파일을 삭제할 수 있습니다. 도구 구성 UI에서 메모리 파일을 삭제할 수도 있습니다." 이 마지막 기능은 2026년 6월 업데이트에서 추가되었으며, "UI에서 메모리 파일을 삭제하거나 실행 시 오래된 메모리를 삭제하도록 자동화에 지시"할 수 있는 기능이 추가되었습니다.

그리고 경고 전문은 다음과 같습니다. "Memories는 실행 간에 유지되므로 자동화가 신뢰할 수 없는 입력을 처리하는 경우 주의해서 사용해야 합니다. 입력으로 인해 향후 자동화 실행에 의도치 않게 영향을 미치는 오해의 소지가 있거나 악의적인 메모리가 생성될 수 있습니다."

이제 자동화가 일반적으로 읽는 내용을 살펴보겠습니다. Cursor의 트리거 목록에는 Slack의 "채널의 새 메시지", 풀 리퀘스트의 "댓글 추가됨", GitHub 이슈의 "이슈 댓글", POST할 수 있는 웹훅 엔드포인트, Linear 이벤트 등이 포함됩니다. 이 각각은 귀하가 아닌 다른 사람이 작성한 텍스트를 전달합니다. Slack 채널에서 버그 보고서를 분류하는 자동화는 의도적으로 매 실행마다 신뢰할 수 없는 입력을 읽고 있으며, 기본적으로 이를 기반으로 스스로에게 노트를 작성하고 있습니다.

이것이 에디터의 메모리와의 차이점입니다. 에디터에서 타이핑하는 사람은 바로 귀하입니다. 자동화에서는 입력을 트리거한 사람이 누구든 그 사람으로부터 입력이 들어오며, 그가 남긴 노트는 아무도 보지 않는 사이에 다음 실행에서 읽힙니다.

혼동을 줄 수 있으므로 이름에 대해 짚고 넘어가겠습니다. Cursor 메모리를 검색할 때 많은 경우 Cursor 버전 1.0에서 도입된 IDE 기능인 "Cursor가 대화의 사실을 기억하고 향후 참조할 수 있는" 기능을 의미하며, 메모리는 "개별 수준에서 프로젝트별로 저장"됩니다. Cursor의 현재 문서 인덱스에서는 Memories를 Automations 도구로 설명하고 있으며, 규칙 문서는 규칙을 에디터의 영구 레이어로 설명합니다. "대규모 언어 모델은 완료(completions) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 영구적이고 재사용 가능한 context를 제공합니다." 이 가이드는 Automations 메모리 도구를 다룹니다.

모든 자동화에 대해 메모리를 켜두기. 이것이 기본값이며, 매일 아침 자체 리포지토리의 커밋을 요약하는 자동화의 경우에는 아마 괜찮을 것입니다. 하지만 공개 채널을 읽는 자동화의 경우, 낯선 사람의 메시지가 자동화가 보관하는 노트에 영향을 미칠 수 있음을 의미합니다.

모든 곳에서 메모리 끄기. 안전하지만, 이 기능의 진정한 가치를 버리는 것입니다. 어떤 불안정한 테스트(flaky tests)를 무시해야 하는지 또는 어떤 리뷰어가 어떤 디렉토리를 소유하고 있는지 학습하는 자동화는 첫 번째 실행보다 열 번째 실행에서 진정으로 더 나은 성능을 발휘합니다.

에이전트가 스스로 정리할 것이라 믿기. Cursor 문서에는 에이전트가 "자동화 실행 중에 오래된 메모리 파일을 삭제할 수 있다"고 나와 있습니다. 이는 유용한 정리 작업입니다. 하지만 동일한 입력값을 읽고 무엇이 오래되었는지 결정하는 것 역시 동일한 에이전트입니다.

메모리 파일을 절대 열어보지 않기. 노트는 도구 구성 UI에서 보고 편집할 수 있습니다. 많은 팀이 자동화를 설정하고 일주일 동안 작동하는 것을 지켜본 후, 그 이후로 자동화가 스스로에게 무슨 말을 해왔는지 전혀 들여다보지 않습니다.

메모리가 여러 자동화 간에 공유된다고 가정하기. 메모리는 "동일한 자동화"로 범위가 제한됩니다. 분류 자동화가 학습한 내용은 리뷰 자동화에는 보이지 않으며, 이는 합리적인 격리이지만 흔히들 놀라는 부분입니다.

목표는 학습 효과는 유지하면서 무엇을 학습했는지에 대한 추측을 배제하는 것입니다.

Step 1: 읽는 입력을 기준으로 각 자동화 분류하기

자동화 목록을 작성하고, 각 자동화에 대해 모든 트리거와 읽는 모든 소스를 기록하십시오. 그런 다음 두 그룹으로 분류합니다.

신뢰할 수 있는 입력: 자체 리포지토리에 대한 일정, 팀의 푸시 및 머지, 자체 시스템의 웹훅. 에이전트가 읽는 텍스트는 귀하가 제어하는 사람과 시스템에 의해 작성되었습니다.

신뢰할 수 없는 입력: 공개 Slack 채널, 댓글을 달 수 있는 모든 사람의 풀 리퀘스트 및 이슈 댓글, 제3자에게 노출된 웹훅, 고객의 티켓. 연결된 도구에 대한 Cursor 자체 가이드도 동일한 방향을 가리킵니다. "자동화에 필요한 권한을 가진 신뢰할 수 있는 서버만 연결하십시오."

신뢰할 수 없는 그룹의 경우, 자동화가 실제로 실행 간에 무언가를 기억해야 하는지 결정하십시오. 많은 자동화는 그럴 필요가 없으며, 각 항목을 개별적으로 분류합니다. 이러한 자동화의 경우 메모리를 비활성화하십시오. 메모리를 통해 진정으로 개선되는 자동화의 경우, 메모리를 켜두고 Step 2로 이동하십시오.

Step 2: 자동화에 기록할 수 있는 내용을 정확히 지시하기

자동화의 프롬프트는 메모리에 대한 규칙을 설정하는 곳입니다. Cursor의 설정 흐름은 이를 중심에 둡니다. "자동화에 대한 지침이 포함된 프롬프트를 작성하십시오."

해당 프롬프트에 짧고 명시적인 메모리 정책을 추가하십시오. 어떤 종류의 사실을 기록할 가치가 있는지 명시하십시오. 예를 들어, 어떤 테스트가 불안정한 것으로 알려져 있는지, 어떤 디렉토리가 어떤 소유자에게 매핑되는지, 어떤 알림 패턴이 노이즈로 판명되었는지 등입니다. 입력 내부에 포함되어 들어오는 지시사항, 권한에 대한 주장, 자동화 자체의 동작을 변경하라는 요청 등 절대 기록해서는 안 되는 사항을 명시하십시오. 그리고 불확실한 것은 규칙이 아닌 관찰 결과로 기록해야 한다고 명시하십시오.

이것이 신뢰할 수 없는 입력을 안전하게 만드는 것은 아니며, Cursor의 주의 사항은 여전히 적용됩니다. 다만 오해의 소지가 있는 입력이 변질될 수 있는 범위를 좁히고, 파일을 읽을 때 정책을 벗어난 내용이 눈에 띄기 때문에 잘못된 노트를 더 쉽게 발견할 수 있게 해줍니다.

자동화의 작업에 민감한 내용을 읽는 것이 포함되어 있다면, 메모리 정책을 생각보다 더 엄격하게 유지하십시오. 실행 간에 유지되는 메모리는 단 한 번의 잘못된 입력이 오랫동안 영향을 미칠 수 있는 공간입니다.

Step 3: 정기적으로 MEMORIES.md를 검토하고, 승인된 사본을 다른 곳에 보관하기

캘린더에 반복 알림을 설정하여(바쁜 자동화는 매주, 한가한 자동화는 매월) 도구 구성 UI에서 각 자동화의 메모리를 열고 읽어보십시오.

풀 리퀘스트를 리뷰하듯이 읽어보십시오. 각 노트가 사실인가요? 여전히 유효한가요? 신뢰할 수 있는 입력에서 나온 것인가요? 잘못된 내용은 편집하고, 오래된 내용은 삭제하며, 입력이 에디터에게 쓰라고 지시해서 작성된 것처럼 보이는 내용이 있는지 확인하십시오.

그런 다음 승인한 노트의 사본을 자동화 외부의 어딘가에 보관하십시오. 실행이 오작동할 때 오늘의 메모리를 마지막으로 확인한 버전과 비교하고 싶을 것이며, 자동화 자체의 파일은 변경되었을 수 있는 유일한 요소입니다. 다른 도구의 반복 실행 에이전트에도 동일한 개념이 적용됩니다. Warp 클라우드 에이전트가 이전 실행을 기억하도록 만드는 방법의 배경이 되는 패턴은 방치된 기록이 아니라 검토된 기록입니다.

Step 3에서 승인된 사본은 유용한 결과물입니다. 즉, 누군가가 확인하고 동의한 짧은 교훈 목록입니다. MemoryLake는 자동화가 다음 실행 시 다시 쓸 수 있는 파일과 분리하여 이를 보관할 수 있는 공간입니다.

항목은 본인의 언어로 직접 작성합니다. 자동화의 MEMORIES.md, Cursor 설정 또는 다른 벤더의 저장소에서 아무것도 읽거나 쓰거나 삭제하지 않습니다.

Step 1: API 키 생성하기

로그인하고 대시보드에서 키를 생성합니다. 이 키는 자동화, 에디터 세션 또는 완전히 다른 도구이든 관계없이 에이전트가 작성한 항목을 읽을 수 있도록 해줍니다.

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

Step 3에서 승인한 교훈을 항목당 하나씩, 확인한 이유와 날짜와 함께 추가하십시오. 날짜가 중요합니다. 불안정한 테스트에 대한 교훈은 누군가 그 테스트를 수정하기 전까지만 유효하기 때문입니다.

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

에이전트가 워크스페이스를 가리키도록 설정하십시오. 그러면 검토된 교훈을 하나의 자동화 파일에 가두어 두는 대신, 이를 필요로 하는 모든 자동화 및 세션에서 사용할 수 있게 됩니다.

첫 번째 차이점은 메모리가 기본값이 아니라 자동화별로 결정하는 사항이 된다는 것입니다. 자체 시스템만 읽는 자동화는 계속 학습합니다. 낯선 사람의 텍스트를 읽는 자동화는 기억하기를 중단하거나 서면 정책에 따라 기억하게 됩니다.

두 번째는 편향(drift)이 눈에 보이게 된다는 점입니다. 아무도 읽지 않는 메모리 파일은 몇 주 동안 잘못된 믿음을 축적할 수 있습니다. 누군가 정기적으로 검토하는 파일은 그 믿음이 여러 실행에 영향을 미치기 전에 수정됩니다.

세 번째는 교훈이 하나의 자동화에 갇히지 않는다는 것입니다. 메모리는 자동화별로 범위가 지정되기 때문에, 하나가 학습한 유용한 사실은 다른 자동화에는 보이지 않습니다. 승인된 교훈을 공유된 장소에 보관하는 것이 해결책이며, 이는 Cursor 클라우드 에이전트가 context를 잊어버리는 이유 및 Cursor Projects가 context 파일을 공유하는 방법에서 설명한 것과 동일한 공백을 메워줍니다.

네 번째는 반복 실행 에이전트가 추론 가능한 시스템처럼 작동하기 시작한다는 점입니다. 다른 도구의 예약된 작업도 동일한 형태를 가집니다. 처음부터 다시 시작되는 ChatGPT 예약 작업 및 Cowork 예약 작업 및 메모리를 참조하십시오. 공통된 핵심은 백그라운드 에이전트의 메모리는 누군가가 마지막으로 확인한 만큼만 유효하다는 점입니다.

메모리를 활성화하기 전에 트리거를 분류하십시오. 공개 채널, 열린 댓글 스레드 및 제3자 웹훅은 신뢰할 수 없는 입력입니다.

작업에 필요하지 않은 경우 메모리를 비활성화하십시오. 많은 분류 작업은 항목별로 작동하며 기억하는 것에서 얻는 이득이 거의 없습니다.

프롬프트에 메모리 정책을 작성하십시오. 무엇을 기록할지, 절대 기록하지 말아야 할지, 불확실성을 어떻게 기록할지 명시하십시오.

정기적으로 메모리 파일을 검토하십시오. Cursor는 이를 보고 편집할 수 있게 해줍니다. 가치는 실제로 읽는 것에서 나옵니다.

승인된 사본을 자동화 외부에 보관하십시오. 동작이 변경되면 현재 파일과 마지막으로 신뢰했던 버전을 비교하십시오.

각 자동화는 독립적으로 기억한다는 점을 명심하십시오. 메모리는 자동화별로 적용됩니다. 공유된 교훈은 공유된 공간이 필요하며, 이는 Cursor가 이전 세션을 잊어버리는 문제 및 반복 실행 에이전트가 이전 실행을 잊어버리는 문제의 더 광범위한 문제를 해결하는 방법이기도 합니다.

Cursor는 매 실행마다 아무것도 없는 상태에서 시작하는 백그라운드 에이전트라는 실제 문제를 해결하기 위해 Automations 메모리 도구를 구축했습니다. 메모리가 켜져 있으면 자동화는 "시간이 지남에 따라 기억하고 개선"할 수 있으며, 이러한 이유로 기본적으로 켜져 있습니다.

Cursor는 또한 위험성을 명확하게 기록했습니다. 입력이 "향후 자동화 실행에 의도치 않게 영향을 미치는 오해의 소지가 있거나 악의적인 메모리로 이어질 수 있기" 때문에, 자동화가 신뢰할 수 없는 입력을 처리하는 경우 메모리를 "주의해서 사용해야 합니다." Slack 채널, 풀 리퀘스트 댓글 또는 외부 웹훅을 읽는 자동화의 경우, 이는 예외적인 상황이 아니라 일반적인 상황입니다.

각 자동화를 읽는 내용에 따라 분류하고, 필요하지 않은 곳에서는 메모리를 끄고, 기록할 수 있는 내용에 대한 정책을 작성하고, 정기적으로 파일을 검토하십시오. 승인한 교훈을 자동화가 다시 쓸 수 없는 곳에 보관하면, 그 메모리는 단지 맞기를 바라는 대상이 아니라 신뢰할 수 있는 자산이 됩니다.