Cowork 예약 작업이 사용자의 memory를 사용할지 여부를 제어하는 방법 (2026)

각 실행은 자체 세션입니다

예약 작업 페이지에는 다음과 같이 명확하게 명시되어 있습니다. "각 예약 작업은 자체 Cowork 세션으로 실행됩니다. 다른 작업과 마찬가지로 결과가 준비되면 검토할 수 있습니다."

이 문장 자체만 보면 다른 모든 무인 에이전트 설계와 다를 바 없어 보입니다. 하지만 다음 문장을 읽으면 달라집니다. "예약 작업은 원격으로 실행되므로 컴퓨터가 절전 모드이거나 Claude Desktop 앱이 닫혀 있는 경우에도 설정된 주기에 따라 실행됩니다."

원격으로 — 즉, 클라우드에서 실행된다는 의미입니다.

클라우드 세션은 채팅과 memory를 공유합니다

이 부분이 Cowork를 다르게 만드는 핵심입니다. Cowork의 시작 가이드 페이지에는 이를 다음과 같은 기능으로 나열하고 있습니다. "채팅과 공유되는 memory: 클라우드 세션에서 Claude는 이미 채팅에서 기억하고 있는 내용부터 시작하며, Cowork 작업에서 발생하는 내용도 다시 채팅으로 전달됩니다."

양방향입니다. 클라우드 세션은 Claude가 이미 기억하고 있는 내용에서 시작하고, 작업에서 일어나는 일은 다시 채팅으로 흘러갑니다.

작업이 저장하는 것은 학습한 내용이 아니라 프롬프트입니다

"memory가 있다"는 말은 두 가지를 의미할 수 있으므로 메커니즘을 정확히 짚고 넘어갈 필요가 있습니다. 예약 작업 자체는 지침을 저장합니다. "예약 작업을 생성하면 Claude는 프롬프트를 작업 지침으로 저장하고 선택한 주기에 따라 실행합니다."

이것이 작업 정의입니다. Memory는 클라우드 세션이 읽어오는 별도의 레이어입니다. 작업은 이전 실행의 자체적인 비공개 이력을 누적하지 않습니다. 단지 사용자의 memory에 액세스할 수 있는 세션에서 저장된 프롬프트를 다시 실행할 뿐입니다. 두 가지 모두 사실이며 동일한 것이 아닙니다. 이것이 바로 what persistent memory actually is의 핵심에 있는 차이점입니다.

일치하지 않는 두 개의 참고 사항

이제 해결되지 않은 부분입니다. 어느 한쪽만 선택하기보다는 게시된 두 문장을 모두 읽어볼 가치가 있습니다.

예약 작업 페이지에는 다음과 같이 나와 있습니다. "참고: 예약 작업은 내장된 예약 옵션을 사용하며 커넥터 및 Claude 계정에 저장된 파일과 함께 작동합니다. 컴퓨터의 폴더에 연결할 수 없습니다."

동일한 페이지의 수동 설정 지침에는 필드로 "Claude가 작업해야 하는 폴더 [선택 사항]"이 나열되어 있으며, 그 뒤에 다음과 같이 이어집니다. "참고: 예약 작업에 로컬 파일이나 앱이 필요한 경우 로컬에서만 실행됩니다."

한편, 시작 가이드 페이지에서는 세 번째 방식을 설명합니다. Cowork는 "세션을 클라우드에서 원격으로 실행하며(베타)," 로컬 기능은 세션을 로컬에서 실행하는 대신 데스크톱 앱을 통해 접근합니다. "이러한 기능은 컴퓨터의 리소스에 접근하므로 세션이 클라우드에서 실행되더라도 앱이 필요합니다."

현재 세 개의 페이지에서 폴더 바인딩 작업이 실행되는 위치에 대해 세 가지 다른 프레임을 제시하고 있습니다. Anthropic을 대신해 이를 조율하지는 않겠습니다. 추측하는 것이 사실대로 말하는 것보다 나쁘기 때문입니다. 여기서 기억해야 할 점은 다음과 같습니다. 예약 작업이 로컬 파일에 접근하는 경우, memory 동작에 대해 어떠한 가정도 하지 마십시오. 직접 검증해야 합니다.

예약 작업이 빈 상태로 시작한다고 가정하기. 가장 흔한 가정이지만, Cowork의 클라우드 실행에서는 잘못된 생각입니다. 이로 인해 사람들은 전체 context를 작업 프롬프트에 채워 넣게 되고, 프로젝트 세부 사항이 바뀔 때마다 프롬프트를 수동으로 수정해야 하는 번거로움이 발생합니다.

따라서 모든 것을 알고 있다고 가정하기. 반대의 오류입니다. 클라우드 세션에서 memory는 채팅과 공유될 뿐, 해당 작업의 이전 실행 기록이 아닙니다. 세 번째 실행에서 두 번째 실행의 결론을 알아야 하는 경우, memory는 이를 전달하기에 약한 채널이며 작업의 출력을 활용하는 것이 더 낫습니다.

더 많은 context를 제공하기 위해 예약을 로컬 폴더로 지정하기. 이해할 수 있는 직관이지만, 이는 작업이 실행되는 위치를 바꿀 가능성이 가장 높은 조치입니다. 바로 세 페이지가 서로 동의하지 않는 부분입니다. Context를 얻기 위해 로컬 파일 액세스를 추가하면 의존하고 있던 memory를 잃게 될 수 있습니다.

다른 도구의 예약 실행과 비교하여 일반화하기. ChatGPT의 예약 작업과 Warp의 클라우드 에이전트는 모두 설계상 새로 시작하므로, Cowork도 동일하게 작동할 것이라고 가정하기 쉽습니다. 하지만 클라우드 실행의 경우 그렇지 않습니다. 만약 여러분의 멘탈 모델이 ChatGPT's scheduled tasks starting over every run이나 Warp's cloud agents에서 비롯된 것이라면, Cowork에 맞게 업데이트해야 합니다.

Projects와 memory가 동일하다고 가정하기. Cowork 프로젝트는 "관련 작업을 자체 파일, context, 지침 및 memory가 있는 별도의 워크스페이스로 그룹화"하며, 이는 워크스페이스별 구성이지 채팅과 공유되는 계정 수준의 memory가 아닙니다. 둘 다 존재하며 범위가 다릅니다. 이 경계는 Claude's memory across chat and Cowork에서 다룹니다.

단계 1: 컴퓨터가 필요한지 여부에 따라 예약 작업 분류하기

예약 작업을 살펴보고 다음 두 가지 버킷 중 하나에 넣으십시오.

클라우드 전용 작업. Slack 또는 이메일의 일일 브리핑, 연결된 도구의 주간 보고서, 반복적인 리서치, 상태 요약 등입니다. 이들은 커넥터와 Claude 계정에 저장된 파일을 사용합니다. 설정된 주기에 따라 원격으로 실행되며, 문서에 따르면 클라우드 세션으로 실행되므로 채팅과 공유되는 memory가 적용됩니다.

로컬 컴퓨터의 리소스가 필요한 작업. 로컬 폴더의 파일 정리, 로컬 앱을 읽는 작업 등입니다. 이들은 폴더 필드와 "로컬에서만 실행됩니다"라는 참고 사항이 적용되는 작업이며, memory 동작을 가정해서는 안 되는 영역입니다.

두 번째 버킷의 경우, 작업에 실제로 로컬 액세스가 필요한지 자문해 보십시오. 놀랍게도 많은 "파일 정리" 예약 작업이 로컬 대신 Claude 계정에 저장된 파일을 대상으로 작동할 수 있으며, 이를 통해 작업을 첫 번째 버킷으로 깔끔하게 이동하고 모호성을 제거할 수 있습니다.

단계 2: 각 버킷에서 하나의 작업에 대해 memory 동작 검증하기

추측하지 마십시오. 한 번만 테스트해 보면 여러분의 설정에 대해 확실히 알 수 있습니다.

임시 예약 작업을 생성하고, 프롬프트에 Claude가 사용자의 memory를 통해서만 알 수 있는 특정 사실(예: 채팅에서 설정한 선호도, 해당 프롬프트에 한 번도 입력한 적 없는 프로젝트 세부 정보)을 말하도록 요청합니다. 예약 옵션에서 지원하는 수동 실행을 통해 실행하고 출력을 확인합니다.

그런 다음 동일한 작업의 폴더 바인딩 버전으로 이를 반복합니다. 만약 답변이 다르다면, 여러분의 계정에서 경계가 어디에 있는지 발견한 것입니다. 이는 서로 다르게 설명하는 세 페이지를 보고 추측하는 것보다 훨씬 더 신뢰할 수 있습니다.

결과를 어딘가에 기록해 두십시오. 이는 Cowork가 웹 및 모바일에서 베타 버전을 벗어나면서 변경될 수 있는 종류의 동작이므로, 영구적인 사실이 아니라 유효 기간이 있는 결과로 취급하십시오.

단계 3: 작업에 필요한 요소를 실행 위치에 의존하지 않는 레이어에 배치하기

이것이 구조적인 해결책입니다. 위의 모든 내용은 두 가지 동작 중 어떤 것을 얻게 되는지 확인하는 것에 관한 것이었습니다. 세 번째 옵션이 있습니다. 작업이 그 답변에 의존하지 않도록 만드는 것입니다.

예약된 실행에 필요한 지식이 작업이 명시적으로 읽는 외부 memory 레이어에 존재한다면, 해당 실행이 공유 memory가 있는 클라우드 세션이든 그렇지 않은 로컬 세션이든 상관없습니다. Context는 두 경우 모두 동일한 방식으로 전달됩니다. 계속해서 재검증해야 하는 문제를 환경 전반에서 안정적인 구조로 대체한 것입니다.

이것은 프롬프트 수정 문제에 대한 해답이기도 합니다. 작업 프롬프트는 저장된 문자열입니다. 프로젝트가 변경될 때마다 누군가 예약을 열고 수정해야 합니다. "현재 프로젝트 컨벤션을 사용하라"고 지시하고 저장소에서 이를 읽어오도록 하는 프롬프트는 컨벤션이 변경되어도 수정할 필요가 없습니다. MemoryLake는 세 단계로 설정할 수 있습니다.

단계 1: API 키 생성하기

로그인하고 대시보드에서 API 키를 생성합니다. 특정 플랫폼에 종속되지 않는다는 점이 여기서 중요합니다. 클라우드 및 로컬 실행 모두 동일한 저장소를 읽으므로, 클라우드 대 로컬의 문제가 작업이 알고 있는 내용을 결정하지 않게 됩니다.

단계 2: 첫 번째 memory 업로드하기

예약 작업에 지속적으로 필요한 정보들을 입력하십시오. 주간 보고서 형식의 컨벤션, 리서치 요약에서 관련성 있는 것으로 간주되는 항목 목록, 브리핑에서 모니터링해야 할 계정 및 용어, 그렇지 않았다면 모든 작업 프롬프트에 붙여넣었을 고정된 선호도 등입니다.

실행 간 결론도 여기에 해당합니다. 화요일 실행이 월요일 실행에서 결정된 사항을 알아야 한다면, 공유 memory가 이를 전달해주기를 바라는 대신 저장소에 기록하십시오.

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

Cowork가 저장소를 가리키도록 설정합니다. 그러면 무인 실행도 두 플랫폼 모두에서 대화형 세션과 동일한 지식에서 시작됩니다. 한 번 변경한 내용이 수정해야 할 프롬프트를 일일이 기억해 고치는 대신 모든 예약 작업에 전파됩니다.

첫 번째 변화는 예약 작업이 더 이상 취약한 문자열에 불과하지 않게 된다는 점입니다. 현재 작업 프롬프트는 작성 당시의 사실을 담은 스냅샷에 불과합니다. 프로젝트가 변경되면 이를 언급하는 모든 예약 작업이 소리 없이 낡은 정보가 되어버립니다.

두 번째는 자동화가 무엇을 알고 있는지 파악하기 위해 베타 버전의 경계를 추적할 필요가 없어진다는 점입니다. 클라우드의 Cowork 세션은 웹 및 모바일에서 베타 버전이며, 내장 브라우저는 점진적으로 배포 중이고, Dispatch는 일부 요금제에 대해 제한된 베타 버전입니다. 빠르게 발전하는 제품에서는 이 모든 것이 정상이지만, 누군가 실제로 의존하는 주간 보고서의 안정적인 기반이 되기에는 부족합니다.

세 번째는 실행 간의 연속성이 명시적으로 확보된다는 점입니다. 채팅과의 공유 memory는 훌륭한 기능이지만, "지난주 실행에서 무엇을 결론지었는가"를 파악하기에는 적절하지 않은 메커니즘입니다. 결론을 저장소에 기록하고 다음 실행 시 이를 다시 읽어오는 방식은 실행이 클라우드에서 발생하든 그렇지 않든 작동하는 방식입니다. 이는 memory for MCP tasks의 배경에 있는 논리와 동일합니다.

• 컴퓨터가 필요한지 여부에 따라 예약 작업을 분류하십시오. 이는 얻게 되는 동작을 바꿀 가능성이 가장 높은 단일 변수입니다.
• 로컬 폴더보다 Claude 계정에 저장된 파일을 선호하십시오 작업이 허용하는 한. 클라우드 전용 작업이 가장 명확하게 문서화된 동작을 보입니다.
• 버킷당 한 번씩 memory 동작을 테스트하고 발견한 내용을 기록해 두십시오. 수동 실행을 통해 저렴하게 테스트할 수 있으며, 이 결과는 유효 기간이 있습니다.
• 작업 프롬프트는 짧게 유지하고 작업 자체에 집중하십시오. 형식, 주기, 출력 형태는 프롬프트에 속하지만, 프로젝트 지식은 그렇지 않습니다.
• 공유 memory를 실행 로그로 사용하지 마십시오. 실행 N에 실행 N-1의 결론이 필요한 경우, 의도적으로 어딘가에 기록하십시오.
• Projects는 별도의 범위라는 점을 기억하십시오. 프로젝트 워크스페이스는 자체 파일, context, 지침 및 memory를 가집니다. 이는 채팅과 공유되는 계정 수준의 memory가 아닙니다.
• Cowork가 변경된 후에는 다시 확인하십시오. 클라우드 세션은 웹 및 모바일에서 베타 버전이며, 베타 버전의 동작은 변경될 수 있습니다.
• 예약 작업이 접근할 수 있는 대상을 검토하십시오. 예약 작업은 연결된 도구, 스킬, 설치된 플러그인을 포함하여 일반 Cowork 작업과 동일한 기능을 가집니다. 작업이 주기적으로 무인 실행되는 경우 이를 감사할 가치가 있습니다.

Cowork의 예약 작업은 업계 기본값보다 더 나은 혜택을 제공합니다. 클라우드 실행은 아무것도 없는 상태에서 시작하는 대신 Claude가 이미 기억하고 있는 내용에서 시작하고 다시 피드백을 제공합니다. 이는 정말 유용하며 알아둘 가치가 있습니다.

또한 이는 현재 폴더 바인딩 작업에 대한 문서에서 명확히 해결되지 않은 조건부 사항이기도 합니다. 따라서 예약 작업을 분류하고, 각 버킷에서 하나씩 테스트해 본 다음, 실제로 의존하는 모든 작업에 대해 실행이 어떤 머신에서 이루어지든 답변이 달라지지 않는 곳에 지식을 보관하십시오.