증상은 새 세션이나 다른 Agent가 프로젝트 규칙을 다르게 해석하는 것입니다. 가장 빠른 해결책은 프로젝트 메모리를 보이는지로 판단하지 말고, 세션 간 재현·규칙 변경·권한 분리·분기 격리·복구 테스트를 통과시켜 Claude Code Projects 공유 메모리 검수를 끝내는 것입니다.
이 글은 반복 설명을 줄이려는 개인 사용자, 여러 Agent와 같은 개발 문맥을 써야 하는 소규모 팀, 클라우드 작업 공간과 권한을 관리하는 운영자를 위한 글입니다. 단순한 사용법이 아니라 공유 메모리가 실제 작업에서 안전하게 재현되는지 증명하는 방법에 초점을 둡니다.
검수 대상과 책임 범위
먼저 메모리라는 말을 하나로 묶지 않아야 합니다. Claude Code에는 프로젝트 지식, 프로젝트 지시문, 개인 메모리, 세션 기록, Git에 저장된 문서가 서로 다른 역할을 합니다. 공식 메모리 동작 문서는 CLAUDE.md와 메모리 파일이 작업 문맥에 영향을 줄 수 있음을 설명하지만, 현재 세션에서 읽혔다는 사실이 모든 Agent와 모든 사용자가 안전하게 재사용할 수 있다는 뜻은 아닙니다.
| 구분 | 주로 담는 내용 | 검수할 범위 | 담당자 |
|---|---|---|---|
| 프로젝트 지식 | 구조, 용어, 공통 규칙 | 새 세션과 다른 Agent에서 같은 의미로 읽히는지 | 프로젝트 담당자 |
| 프로젝트 지시문 | 명령 실행법, 테스트 규칙, 금지 사항 | 실제 행동이 규칙과 일치하는지 | 저장소 관리자 |
| 개인 메모리 | 개인 선호, 작업 습관 | 팀 공유 영역으로 유출되지 않는지 | 각 사용자 |
| 세션 기록 | 진행 중인 대화와 임시 판단 | 중단 뒤 복구 가능한 상태인지 | 작업자 |
| Git 문서와 상태 | 결정 사항, 코드, 분기, 커밋 | 메모리와 실제 저장소가 충돌하지 않는지 | 팀 관리자 |
Claude Code Projects의 지식 공유 범위는 계정에서 보이는 기능과 현재 공식 안내를 기준으로 확인해야 합니다. Projects의 생성과 관리 안내와 Projects 기능 설명을 함께 확인하되, 문서에 없는 지속성이나 복구를 추정해서는 안 됩니다.
Claude Code 프로젝트 메모리와 개인 메모리는 어떻게 구분해야 하나요?
프로젝트 메모리는 여러 작업자가 알아야 하는 규칙과 구조를 담는 영역입니다. 개인 메모리는 특정 사용자의 선호나 임시 작업 방식에 가깝습니다. 예를 들어 테스트 명령과 디렉터리 규칙은 프로젝트 영역에 둘 수 있지만, 개인의 출력 형식 선호나 실험 중인 메모는 공유 문서에 넣지 않는 편이 안전합니다.
다음 표를 문서 작성 전에 먼저 채우면 책임이 섞이는 문제를 줄일 수 있습니다.
| 항목 | 저장 위치 예시 | 허용할 내용 | 넣지 말아야 할 내용 |
|---|---|---|---|
| 프로젝트 규칙 | CLAUDE.md 또는 프로젝트 문서 |
빌드, 테스트, 디렉터리 원칙 | 개인 취향 |
| 작업 상태 | Git 이슈, 작업 문서, 커밋 | 담당자, 결정 이유, 다음 단계 | 대화만으로 남긴 약속 |
| 비밀 정보 | 비밀 저장소와 환경 설정 | 필요한 작업에서만 읽는 참조 | 토큰, 비밀번호, 내부 주소 |
| 임시 판단 | 세션 기록 또는 별도 초안 | 아직 확정되지 않은 선택지 | 확정 규칙처럼 보이는 문장 |
개인 사용자 검수 흐름
개인 사용자는 같은 프로젝트에서 새 세션을 열고 동일한 질문을 반복하는 방식부터 시작하면 됩니다. 단순히 “기억하고 있나요?”라고 묻지 말고, 기억이 실제 행동을 바꾸는지 확인해야 합니다.
- 기준 브랜치와 작업 디렉터리를 기록합니다.
- 프로젝트 구조, 테스트 명령, 코딩 규칙을 담은 문서를 준비합니다.
- 첫 세션에서 규칙을 읽게 한 뒤, 모델이 참조한 파일과 실행한 명령을 기록합니다.
- 세션을 종료하고 같은 프로젝트에서 새 세션을 엽니다.
- 새 세션에 같은 기능 수정과 테스트 실행을 요청합니다.
- 출력된 계획, 접근한 경로, 실행한 명령을 첫 세션과 비교합니다.
- 규칙 한 줄을 의도적으로 바꾸고 새 세션에서 이전 규칙을 계속 따르는지 확인합니다.
이 과정에서 “알고 있다”는 답변은 증거가 아닙니다. 파일을 읽었는지, 바뀐 규칙에 따라 행동했는지, 잘못된 이전 정보를 버렸는지를 기록해야 합니다. CLI 사용 문서는 세션 제어와 명령 사용법을 확인할 때 기준으로 삼을 수 있습니다.
Claude Code Projects의 공유 메모리는 세션을 넘어서 재사용되나요?
재사용 여부는 프로젝트 지식이 현재 세션에 실제로 로드되고, 새 세션에서 같은 규칙이 행동으로 나타나는지로 판단해야 합니다. 프로젝트 이름이나 이전 대화가 보인다는 이유만으로 지속성을 확정하면 안 됩니다. 규칙 변경 테스트에서 이전 내용이 계속 사용된다면 메모리 오류, 문서 중복, 세션 문맥 문제를 분리해서 조사해야 합니다.
개인 사용자의 선택 조건
- 규칙이 새 세션에서도 재현되고 민감 정보가 없다면 프로젝트 메모리를 계속 사용합니다.
- 규칙은 보이지만 행동이 달라지면
CLAUDE.md, 경로, 중복 지시문을 먼저 점검합니다. - 임시 결정이 장기 규칙처럼 남으면 Git 문서나 작업 기록으로 이동합니다.
- 개인 선호와 팀 규칙이 섞여 있으면 개인 메모리와 프로젝트 문서를 분리합니다.
소규모 팀의 공유 작업
여러 Agent가 같은 프로젝트 문맥을 사용하려면 지식, 작업 상태, 임시 결정을 따로 기록해야 합니다. 모든 내용을 하나의 CLAUDE.md에 넣으면 파일은 커지지만 책임과 변경 이력이 흐려집니다.
팀 검수에서는 구성원 또는 Agent별로 같은 읽기 전용 작업을 먼저 시킵니다. 프로젝트 구조 설명, 테스트 명령 확인, 특정 파일의 변경 금지 조건을 각각 요청하고 결과를 비교합니다. 결과가 다르면 공유 범위, 현재 디렉터리, 권한 또는 규칙 충돌을 조사합니다.
여러 Agent가 같은 프로젝트 문맥을 공유하려면 어떻게 해야 하나요?
공유해야 하는 사실은 버전이 있는 문서에 두고, 진행 중인 작업은 작업 기록에 둡니다. 한 Agent가 임시로 판단한 내용을 전체 프로젝트 메모리에 바로 넣지 않아야 합니다. Agent마다 작업 브랜치와 산출물 경로를 지정하고, 통합 시점에 사람이 변경 내용을 검토해야 합니다.
Git 브랜치만으로 완전한 격리가 되지는 않습니다. 동일한 외부 서비스, 공통 환경 변수, 공유 폴더와 네트워크 권한이 남아 있을 수 있기 때문입니다. 따라서 브랜치, 작업 공간, 산출물 디렉터리, 외부 상태를 함께 확인해야 합니다.
팀 단위 합격 조건
- 같은 기준 문서를 읽고 같은 테스트 명령을 선택합니다.
- 임시 결정과 확정 규칙에 서로 다른 저장 위치를 사용합니다.
- Agent별 브랜치와 작업 공간을 기록합니다.
- 생성 파일의 경로를 분리하고 덮어쓰기 여부를 확인합니다.
- 병합 전에는 Git 상태와 변경 목록을 사람이 확인합니다.
플랫폼 관리자의 클라우드 검수
클라우드 다중 Agent 작업 공간은 메모리 기능만의 문제가 아닙니다. 신원, 파일, 브랜치, 네트워크 권한, 세션 복구를 각각 검수해야 합니다. 접근 관리 문서는 계정과 권한 모델을 확인할 때 참고할 수 있고, 사내 네트워크를 거치는 경우 프록시 설정 안내도 함께 확인해야 합니다.
주의: 토큰, 개인 경로, 내부 주소, 고객 정보는 공유 메모리의 테스트 문자열로도 넣지 않는 편이 좋습니다. 실제 비밀 정보가 한 번 기록되면 삭제 뒤에도 세션 기록이나 백업에 남았는지 별도로 확인해야 합니다.
플랫폼 관리자는 다음 순서로 작업 공간을 끊어 확인합니다.
- 작업 공간에 접속한 사용자의 신원과 역할을 기록합니다.
- 읽기, 쓰기, 실행, 네트워크 접근을 각각 시험합니다.
- 메모리와 문서에서 토큰, 비밀키, 내부 주소, 개인 선호를 검색합니다.
- 세션 중단 후 같은 작업 공간을 다시 열어 파일과 브랜치 상태를 비교합니다.
- 컨테이너 재생성이나 작업 공간 전환 뒤 복구되는 항목을 기록합니다.
- 복구되지 않는 상태는 Git 커밋, 작업 기록, 외부 저장소처럼 명시적인 위치에 보관합니다.
클라우드 Claude Code 세션이 끊긴 뒤 프로젝트 상태를 어떻게 복구하나요?
먼저 세션 기록, 현재 작업 디렉터리, Git 상태를 따로 확인해야 합니다. 세션이 이어지는 것과 파일 변경이 보존되는 것은 다른 문제입니다. 파일은 남았지만 브랜치가 바뀌었을 수 있고, 대화는 복구됐지만 외부 서비스의 임시 상태는 사라졌을 수 있습니다.
Projects에서 검색 기반 지식 연결을 사용하는 경우에는 Projects 검색 보강 안내의 적용 범위도 확인해야 합니다. 검색 결과가 나왔다는 사실만으로 모든 문서가 항상 같은 우선순위로 사용된다고 판단해서는 안 됩니다.
기억이 작동하지 않을 때의 분류
문제의 원인을 곧바로 “메모리 기능이 고장 났다”고 결론 내리면 안 됩니다. 아래 순서로 좁히면 재현 시간이 짧아집니다.
- 파일 미로드: 해당 메모리나
CLAUDE.md가 실제로 읽혔는지 확인합니다. - 경로 불일치: 현재 작업 디렉터리가 규칙 파일이 적용되는 위치인지 확인합니다.
- 규칙 충돌: 프로젝트 규칙, 개인 설정, 세션 지시가 서로 반대인지 비교합니다.
- 문맥 압축: 긴 작업에서 초기 지시가 현재 문맥에 남아 있는지 확인합니다. 장시간 작업은 문맥 관리와 긴 작업 안내를 참고합니다.
- 브랜치 미동기화: 다른 브랜치에 규칙 변경이나 문서 커밋이 남아 있는지 확인합니다.
- 권한 거부: 파일, 실행 명령, 네트워크에 대한 접근이 차단됐는지 확인합니다.
장애 기록에는 세션 식별자, 작업 디렉터리, 메모리 파일 버전, Git 브랜치와 상태, Agent의 권한을 남깁니다. 이 정보가 없으면 같은 요청을 다시 보내도 원인을 비교하기 어렵습니다.
팀 배포와 반복 검수
공유 메모리를 팀 표준으로 배포하기 전에는 소유자와 변경 절차를 정해야 합니다. 프로젝트 문서마다 관리자를 지정하고, 변경 이유와 승인자를 기록합니다. 민감 정보 검색 규칙도 문서화하며, 새 버전의 Claude Code나 작업 공간 구성이 바뀔 때 고정된 시험 과제를 다시 실행합니다.
사람별 최소 점검표
개인 사용자
- 새 세션에서 프로젝트 규칙을 재현합니다.
- 규칙 변경 뒤 이전 정보가 사라지는지 확인합니다.
- 테스트 명령과 실제 실행 결과를 기록합니다.
- 개인 메모와 프로젝트 규칙을 분리합니다.
소규모 팀
- 여러 Agent가 같은 기준 문서를 읽는지 비교합니다.
- 작업 상태와 임시 결정을 분리합니다.
- 브랜치와 산출물 경로의 충돌을 시험합니다.
- 병합 전에 Git 상태를 검토합니다.
플랫폼 관리자
- 신원, 파일, 브랜치, 네트워크 권한을 따로 승인합니다.
- 비밀 정보와 개인 정보를 공유 영역에서 검사합니다.
- 세션 중단, 작업 공간 전환, 재생성 뒤 복구 범위를 기록합니다.
- 실패 시 되돌릴 수 있는 커밋과 외부 상태를 준비합니다.
조건별 도입 판단
- 새 세션 재현과 규칙 변경 시험을 모두 통과하면 프로젝트 메모리를 일상 작업에 사용합니다.
- 공유 지식은 재현되지만 작업 상태가 자주 사라지면 메모리에 의존하지 말고 Git 문서와 작업 기록을 추가합니다.
- 권한이나 비밀 정보 검수가 끝나지 않으면 다중 Agent 작업을 공개하지 않고 격리된 시험 공간으로 되돌립니다.
- 장시간 실행과 중단 복구가 핵심이면 세션 기록만 믿지 말고 커밋, 작업 목록, 산출물 저장소를 외부화합니다.
- 물리 장치나 고정된 네트워크 연결이 필요하면 클라우드 작업 공간보다 전용 장비를 검토합니다.
현재 환경이 로컬 장비나 일반 클라우드 서버라면 세 가지 문제가 자주 남습니다. 작업 공간을 직접 유지해야 하고, 여러 Agent의 파일 충돌과 권한을 별도로 설계해야 하며, 중단 뒤 동일한 개발 환경을 복원하는 데 운영 시간이 듭니다. 반면 Kvmzen의 클라우드 맥 대여는 필요한 기간에 macOS 기반 작업 공간을 마련해 테스트와 임시 다중 Agent 운영을 시작하기 쉽습니다. 장기간 고정 부하, 특수한 물리 포트, 지속적인 전용 장비가 필요한 경우에는 구매가 더 적합하지만, 짧은 검수 기간이나 팀의 원격 개발 환경 시험이라면 클라우드 맥 대여 안내를 기준으로 현재 비용과 관리 부담을 비교해 보시기 바랍니다.
마지막으로 이 점검표를 프로젝트 배포 절차에 복사해 두고, 메모리·신원·작업 공간을 한 번에 승인하지 마십시오. 공유 메모리가 통과해도 Agent별 권한 경계가 부족할 수 있으므로, 다음 단계에서는 원격 맥 지원 안내와 함께 권한 분리 결과를 다시 확인하는 편이 안전합니다.