모든 스레드가 기록하는 메모리를 중심으로 재구축되는 Claude Projects — 기존 프로젝트 업그레이드는 나중으로 미룬 Anthropic (2026)

하루 간격으로 올라온 두 개의 포스트는 모두 작업이 어디에 머무르는지에 대한 이야기입니다.

프로젝트 관련 포스트의 날짜는 2026년 9월 17일입니다. 이 포스트는 이중 구조를 설명합니다. "프로젝트에는 작업을 수행하는 스레드와 이를 지시하는 코디네이터가 있습니다." 각 스레드는 가벼운 작업이 아닙니다. Anthropic은 구체적으로 명시합니다. "내부적으로 각 스레드는 자체 브랜치와 리포지토리 복사본에서 작동하는 Claude Code 클라우드 세션입니다."

각 스레드가 자체 복사본을 가지기 때문에, 코드 충돌에 대한 해결 경로가 문서화되어 있습니다. "코디네이터가 작업을 체계적으로 유지하지만, 여러 스레드가 동일한 코드를 작업하는 경우 그 중복은 다른 PR과 마찬가지로 머지 충돌(merge conflict)로 해결됩니다." 스레드는 더 세분화될 수도 있습니다. "각 스레드는 필요한 경우 subagents, 루프 및 워크플로우를 사용하여 위임된 작업을 여러 조각으로 더 나눌 수 있으므로 대규모 작업을 더 빠르게 완료할 수 있습니다." 이러한 세분화가 컨텍스트를 어디에 남겨두는지는 별개의 문제이며, 이는 what subagents do and don't share에서 다루었습니다.

다음은 컨텍스트 섹션입니다. Anthropic은 프로젝트를 "장기 실행 또는 에이전트 워크플로우, 즉 단일 답변보다 오래 걸리고 여러 부분으로 구성된 작업"을 위해 구축된 것으로 규정하며, 메모리가 누적된다고 설명합니다. "시간이 지남에 따라 Claude는 프로젝트 세부 정보에 대해 더 많이 학습하고 이를 작업에 적용합니다." 제시된 예시는 코드가 아닌 결정 사항들입니다. "Claude는 배포가 금요일로 이동했는지, 내보내기가 취소된 이유가 무엇인지, 또는 결제 서비스를 수정하기 전에 누구에게 확인해야 하는지 기억할 수 있습니다." 이와 함께 "이제 프로젝트에는 사용자가 추가한 파일과 Claude가 생성한 아티팩트를 수집하는 라이브러리가 포함됩니다."

출시 일정에 대한 문구는 거의 아무도 인용하지 않은 부분입니다. Anthropic의 표현에 따르면, 액세스는 "Claude Code에서 클라우드 세션을 사용하고 웹이나 데스크톱에 기존 프로젝트가 없는 일부 Claude Pro 및 Max 구독자"를 대상으로 시작되었습니다. 이미 프로젝트를 사용하고 계셨다면 이 조항은 여러분에게 해당됩니다. 그리고 이어지는 문장은 다음에 일어날 일을 말해줍니다. "Pro 및 Max 요금제의 기존 프로젝트는 현재와 동일하게 계속 작동합니다. 출시가 chat 및 Cowork으로 확장됨에 따라 업그레이드할 예정입니다."

2026년 9월 16일 자 두 번째 포스트는 하루 전에 발생한 구조적으로 동일한 이벤트입니다. "오늘부터 Claude Cowork과 chat이 하나의 Claude로 통합됩니다." Anthropic이 밝힌 통합 이유는 누구나 공감할 수 있는 가장 명확한 언어로 문제를 지적합니다. "우리는 더 큰 작업을 위한 별도의 공간으로 Cowork을, 시각적 작업을 위해 Design을 구축했습니다. 사람들은 두 가지를 모두 사용하면서, 작업이 어디에 속하는지 결정하는 것이 가장 답답하다고 말했습니다. 한 곳에서 시작한 작업이 다른 곳으로 이어지지 않았기 때문입니다."

이는 벤더가 출시 포스트에서 자체 컨테이너 간에 컨텍스트가 전달되지 않았음을 스스로 인정한 것입니다. 해결책 또한 명확하게 제시되어 있습니다. 이제 이러한 기능들을 "이미 가지고 있는 컨텍스트, 스킬, 커넥터와 함께 모든 대화에서 사용"할 수 있으며, 이미 Cowork을 사용 중인 사람들의 경우 "채팅, 프로젝트, 아티팩트, 커넥터, 스킬 등 모든 것이 그대로 유지됩니다."

기록하는 주체가 바뀝니다. 지금까지 프로젝트에 컨텍스트가 쌓인 것은 주로 사용자가 무언가를 입력했기 때문이었습니다. 재설계된 프로젝트에서는 모든 스레드가 작업을 수행하면서 공유 메모리에 내용을 추가합니다. 기록하는 주체가 한 명에서 여럿으로 늘어났으며, 그 주체는 사람이 아닌 세션입니다. 작업을 배분하는 코디네이터는 에이전트 팀과 동일한 형태를 띠고 있으며, 그 컨텍스트가 어디에 도달하는지는 what agent teams share에서 다룬 질문입니다.

읽기가 일어나는 위치가 바뀝니다. Anthropic은 두 가지 수준에서의 검토를 설명합니다. "메인 프로젝트 채팅에서 진행 상황을 모니터링하고 가이드하거나, 각 개별 스레드로 들어가 세부 사항을 검토하고 제어할 수 있습니다." 따라서 살펴볼 수 있는 공간이 존재합니다. 습관을 들여야 할 것은 그것을 들여다보는 것입니다. 공유 메모리는 이제 한 번 설정하고 끝나는 설정 패널이 아니라, 계속해서 작동하는 작업 아티팩트입니다.

비용 프로필이 바뀝니다. "프로젝트는 한 번에 여러 스레드를 실행할 수 있으며, 각 스레드는 완전한 Claude Code 세션입니다. 이 때문에 프로젝트가 사용량 제한에 더 빨리 도달할 수 있습니다." Anthropic은 이에 대한 제어 기능도 함께 제공합니다. "프로젝트별 사용량을 확인하고 코디네이터 채팅 및 작업자 스레드에서 사용하는 모델과 노력 수준(effort levels)을 선택할 수 있습니다."

스레드가 실행되는 위치는 아직 바뀌지 않습니다. "현재 스레드는 클라우드에서 실행됩니다. 로컬 도구 및 코드와 함께 네트워크 뒤의 로컬 머신에서 실행하는 기능은 곧 제공될 예정입니다."

기존 프로젝트는 당장 바뀌지 않습니다. 현재와 동일하게 계속 작동하며, 나중에 업그레이드됩니다. 이는 일종의 공백을 의미합니다. 지금 사용 중인 프로젝트는 아직 경험해보지 못한 전환의 한쪽에 놓여 있습니다.

프로젝트가 영구적인 기록이 되지는 않습니다. 프로젝트는 작업이 진행되는 동안 그 작업이 머무르는 공간입니다. 결정 뒤에 숨겨진 추론은 결정 자체보다 더 가치 있으며, 컨테이너보다 더 오래 지속됩니다. 이는 우리가 why a long context window isn't memory에서 구분한 차이점입니다.

"공유 메모리가 있으니 이제 기록을 멈춰도 된다." 포스트에서는 공유 메모리가 "복잡한 프롬프트 엔지니어링의 필요성"을 줄여준다고 말합니다. 이는 프롬프트에 대한 주장이지, 여러분의 기록에 대한 주장이 아닙니다. Anthropic이 예로 든 것들(일정이 변경된 배포, 취소된 내보내기, 확인해야 할 담당자)은 다음 분기에도 여러분의 언어로 작성된 어딘가에서 읽을 수 있어야 하는 중요한 정보들입니다.

"병렬 스레드는 단지 더 빠른 세션일 뿐이다." 각 스레드는 자체 브랜치와 리포지토리 복사본을 가진 완전한 클라우드 세션입니다. 이는 브라우저 탭과는 완전히 다른 작업 단위이며, 사용량 제한에 대한 Anthropic의 경고가 이를 증명합니다.

"코드와 메모리가 모두 병합된다." Anthropic은 명시적으로 하나의 해결 메커니즘을 설명하며, 이는 코드를 위한 것입니다. 중복은 "다른 PR과 마찬가지로 머지 충돌로 해결됩니다." 반면 공유 메모리에 대해서는 동일한 페이지에서 다른 관계를 설명합니다. 모든 스레드가 메모리에 "기여하고 이를 활용합니다." 이 둘은 서로 다른 설계이며, 하나가 둘 다 해결해 줄 것이라 가정하기보다 서로 다른 설계로 이해하는 것이 좋습니다. 다른 벤더도 이와 유사한 분리를 시도했으며, 우리는 이를 what reaches the next agent in Cursor Projects에서 살펴보았습니다.

"내 프로젝트가 자연스럽게 새로운 프로젝트로 바뀔 것이다." 출시가 chat 및 Cowork으로 확장됨에 따라 Anthropic의 일정에 맞춰 업그레이드될 것입니다. 그전까지는 현재 방식대로 계속 작동합니다. Anthropic은 Cowork 포스트에서 기업 고객을 위한 일정도 명시했습니다. "엔터프라이즈 관리자는 조직에 변경 사항이 적용되기 최소 30일 전에 안내를 받게 됩니다."

"이것은 세션을 브랜칭하는 것과 같다." 그렇지 않습니다. 브랜치는 다른 경로를 시도할 수 있도록 하나의 세션을 복사하는 것이지만, 프로젝트는 하나의 목표를 향해 여러 세션을 실행합니다. 브랜치 케이스는 forking a remote Claude Code session에서 별도로 다루었습니다.

목표는 공유 메모리를 피하는 것이 아닙니다. 재설계가 진행 중인 컨테이너 내부에 여러분의 컨텍스트 중 어느 부분을 보관해도 안전한지 파악하는 것입니다.

1단계: 스레드가 시작되기 전에 결정 사항 기록하기

목표를 설정하고 프로젝트가 작업을 분산하기 전에, 스레드가 임의로 추측했을 때 큰 비용이 발생할 수 있는 서너 가지 사항을 미리 작성해 두세요. 이미 배제한 제약 조건, 팀이 합의한 규칙, 특정 담당자의 확인 없이 건드려서는 안 되는 서비스 등이 이에 해당합니다. Anthropic이 제시한 프로젝트 메모리의 예시들이 바로 이러한 사실들이며, 이는 그것들이 매우 중요하다는 것을 보여줍니다. 해당 정보를 저장하는 제품을 열지 않고도 다시 읽을 수 있는 곳에 기록해 두세요.

2단계: 요약뿐만 아니라 스레드도 직접 읽기

Anthropic이 설명한 두 가지 수준을 모두 활용하세요. 프로젝트 채팅은 작업이 어디에 있는지 알려주고, 개별 스레드는 어떤 근거로 어떤 결론을 내렸는지 알려줍니다. 스레드의 결론이 팀이 따르게 될 결정 사항이 된다면, 여러분만의 문장으로 복사해 두세요. 스레드 내부에만 존재하는 결론은 나중에 다시 도출해야 하는 결론이 될 뿐입니다.

3단계: 업그레이드 이후에도 유지되는 복사본 보관하기

기존 프로젝트는 현재 정상 작동하며 나중에 업그레이드될 예정입니다. 전환 이후에 다시 설명하기 번거로운 내용들은 이미 프로젝트 외부에 존재해야 합니다. 이는 도구를 전환할 때도 살아남을 수 있게 해주는 원칙이며, carrying context between Claude Code sessions에서 다룬 내용이기도 합니다.

분리된 정보 중 영구적으로 보관해야 할 부분은 프로젝트, 스레드 또는 특정 벤더의 컨테이너가 아닌 다른 곳에 머물러야 합니다. MemoryLake는 특정 제품의 구조와 독립되어 있으며 연결된 모든 어시스턴트에서 읽을 수 있는, 결정 사항들을 의도적으로 기록해 두는 저장소입니다. 여러분의 언어로 직접 항목을 작성할 수 있습니다. Anthropic의 시스템이나 다른 벤더의 저장소에서 데이터를 읽거나, 쓰거나, 삭제하지 않으므로 프로젝트, 스레드 및 라이브러리는 전적으로 자체 제어 하에 유지됩니다.

1단계: API 키 생성하기

대시보드에서 키를 생성합니다. 이 키를 통해 코디네이터 채팅, 터미널 세션, 그리고 완전히 다른 어시스턴트가 각각 자체 복사본을 유지하지 않고도 동일한 사실 집합에 접근할 수 있습니다.

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

Anthropic의 예시가 가리키는 네 가지 카테고리(변경된 일정, 거부된 결정 사항, 특정 서비스의 소유권, 준수해야 할 규칙)로 시작해 보세요. 각 항목 옆에 이유를 추가하세요. 그 이유가 있어야 향후 스레드가 이미 거부된 사항을 다시 제안하는 것을 방지할 수 있습니다.

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

대화 기록에서 사실을 재구성하는 대신 작업 시작 시 해당 사실이 로드되도록 도구를 메모리 레이어에 연결하세요. 그런 다음 유일하게 검증 가능한 테스트를 실행해 보세요. 다른 어시스턴트에게 이전 결정 사항 중 하나를 말해달라고 요청해 보세요. 답변을 얻는다면, 여러분의 추론은 더 이상 단일 제품의 형태에 종속되지 않는 것입니다.

첫 번째 변화는 "이 작업이 어느 영역에 속하는가"라는 질문에 두 번 답할 필요가 없어진다는 점입니다. Anthropic은 자사 제품에서 이 질문을 제거했으며, 이전에는 이 질문 때문에 사용자들이 컨텍스트를 잃어버리곤 했다고 명시적으로 밝혔습니다. 동일한 논리가 한 단계 위에도 적용됩니다. 어떤 사실이 여러 도구에 걸쳐 중요하다면, 우연히 열게 된 특정 도구 내부에만 머물러서는 안 됩니다.

두 번째는 프로젝트 메모리가 맹신하는 대상이 아니라 검토해야 하는 대상이 된다는 점입니다. 많은 스레드가 여기에 기록을 남깁니다. 스레드의 결론을 읽는 것은 이제 문제가 발생했을 때 수행하는 감사가 아니라, 일상적인 작업의 일부가 됩니다.

세 번째는 결정 사항과 기록의 차이가 실무적으로 명확해진다는 점입니다. 프로젝트는 진행 중인 작업을 하나로 묶는 데 매우 유용합니다. 하지만 특정 선택을 한 이유에 대한 기록은 수명이 다른 별개의 아티팩트이며, 이번 재설계는 두 가지를 동일한 장소에 저장하고 있었다는 사실을 인지할 좋은 기회입니다.

네 번째는 업그레이드가 더 이상 불안하지 않다는 점입니다. 기존 프로젝트는 현재 정상 작동하며 나중에 변경됩니다. 중요한 모든 정보의 복사본이 외부에 존재한다면, 이러한 전환은 반나절을 허비해야 하는 일이 아니라 단순한 알림에 불과할 것입니다.

처음에는 목표를 좁게 설정하세요. "비서실장에게 브리핑하듯 프로젝트에서 Claude에게 브리핑하면 새로운 스레드나 기존 스레드로 작업을 라우팅합니다"라는 Anthropic의 프레임워크는 브리핑이 구체적이어서 라우팅 경로가 명확할 때 가장 잘 작동합니다.

프로젝트별 사용량을 조기에 확인하세요. 여러 개의 완전한 클라우드 세션을 동시에 실행하는 것은 기존과 다른 소비 패턴을 보이며, Anthropic은 코디네이터와 작업자 스레드에 대한 제어 기능을 각각 별도로 제공합니다.

라이브러리를 아카이브가 아닌 인박스(수신함)로 취급하세요. 라이브러리는 사용자가 추가한 파일과 Claude가 생성한 아티팩트를 수집합니다. 작업 중에 무언가를 찾는 데는 유용하지만, 도출된 결론을 정리해 둔 기록과는 다릅니다.

규칙뿐만 아니라 이유도 함께 기록하세요. "확인 없이 결제 서비스를 건드리지 마세요"라는 규칙은 시간이 지나면 잊히기 쉽습니다. "확인 없이 결제 서비스를 건드리지 마세요. 정산 작업이 정해진 시간에 실행되며, 지난 6월에 스키마 변경으로 인해 오류가 발생한 적이 있습니다"라는 기록은 인수인계 과정에서도 살아남습니다.

컨테이너 외부에 복사본 하나를 보관하세요. Anthropic은 이틀 동안 두 개의 컨테이너를 이동했습니다. 이는 제품이 개선되고 있다는 증거이기도 하지만, 영구적인 사실들을 컨테이너가 아닌 다른 곳에 보관해야 하는 이유이기도 합니다.

Claude projects의 재설계는 프로젝트의 본질에 대한 진정한 변화입니다. 단순히 채팅이 첨부된 폴더가 아니라, 코디네이터, 병렬 클라우드 세션, 라이브러리, 그리고 모든 스레드가 기여하는 메모리를 갖춘 대화입니다. Anthropic은 코드 중복이 머지 충돌로 해결된다는 점, 스레드가 실제 비용이 발생하는 완전한 세션이라는 점, 현재 스레드가 클라우드에서 실행된다는 점 등 놓치기 쉬운 부분을 포함하여 전체적인 구조를 문서화했습니다.

기억해야 할 두 문장은 여러분이 이미 가지고 있는 것에 대한 내용입니다. 기존 프로젝트는 "현재와 동일하게 계속 작동"하며, Anthropic은 "출시가 chat 및 Cowork으로 확장됨에 따라 업그레이드할 예정"입니다. 이 중 문제될 것은 전혀 없습니다. 단지 여러분의 컨텍스트가 머무는 공간의 형태가 예정대로 변경되는 것뿐입니다.

그 전날, Anthropic은 컨테이너가 왜 중요한지 설명했습니다. 사람들은 작업이 어디에 속하는지 계속 결정해야 했고, "한 곳에서 시작한 작업이 다른 곳으로 이어지지 않았기 때문"입니다. 이는 이번 달에 발표된 문제 제기 중 가장 명확한 설명입니다. 실질적인 대응책은 더 나은 컨테이너를 선택하는 것이 아닙니다. 컨테이너보다 오래 지속되는 사실들을 여러분이 통제할 수 있는 곳에 보관하고, 컨테이너는 계속해서 개선되도록 내버려 두는 것입니다.