Claude 프로젝트 보관 전 권한 회수: Archive 뒤에도 멤버가 남는 이유
TL;DR
- Claude Projects에서 Archive는 목록 정리입니다. 공유 멤버·권한 수준·프로젝트 지식은 보관 뒤에도 유지되며, 보관을 풀면 이전 상태로 돌아옵니다.
- 접근을 끝낼 사람은 프로젝트 Share > 대상 역할 > Remove access에서 별도로 제거합니다. 조직 전체 접근과 Enterprise 그룹 경로가 있다면 그것도 확인합니다.
- 사람의 승인 아래 비민감 시험 프로젝트의 설정과 접근을 양쪽에서 확인합니다. 원본 삭제, 실제 민감 자료 열람, 대화 링크 회수는 이번 완료 범위에서 분리합니다.
핵심 3줄 요약
핵심 1
보관은 공유 권한 회수가 아닙니다. 프로젝트가 목록에서 덜 보이더라도 멤버는 남습니다.
핵심 2
개별 초대와 General access의 조직 전체 범위는 별개입니다. 그룹으로 받은 권한도 따로 점검합니다.
핵심 3
Remove access 뒤 대상 계정 차단과 유지할 동료의 정상 접근을 각각 확인하고 검토 기록을 남깁니다.
이 글에서 다룰 내용
공유 프로젝트 보관의 의미, 보관 전에 확인할 접근 경로, Share에서 한 사람을 제거하는 단계, Archive의 위치, 비민감 계정으로 양면 검증하는 기준을 다룹니다. 조직 전체 관리자 정책이나 인사 계정 삭제 절차는 다루지 않습니다.
보관은 왜 권한을 끊지 못하나요?
Claude Projects의 Archive는 완료된 프로젝트를 목록에서 정리하고 나중에 다시 참고하도록 남겨두는 기능입니다. Anthropic 도움말은 공유 프로젝트를 보관해도 멤버, 권한 수준, 프로젝트 지식이 유지된다고 명시합니다. 보관을 해제하면 기존 상태가 돌아옵니다.
권한 회수는 Share의 멤버 목록을 바꿔야 합니다. 보관 버튼을 눌러 프로젝트가 메인 목록에서 멀어져도 기존 수신자의 접근이 끝나지는 않습니다. 이미 보관한 프로젝트의 접근도 공유 설정에서 제거할 수 있습니다.
프로젝트 지식과 대화도 구분합니다. 프로젝트 멤버는 공유한 지식과 지침을 볼 수 있지만, 작성자의 개별 대화는 기본적으로 자동 공유되지 않습니다. 반대로 별도로 발급한 대화 공유 링크는 프로젝트 보관 점검과 별개의 접근 경로입니다.
언제 이 절차가 필요할까요?
Team 또는 Enterprise의 공유 프로젝트에서 프로젝트 작업이 끝났지만 자료를 지우지 않고 보관하려는 때에 씁니다. 예전 담당자의 접근은 끝내고 승인된 내부 검토자는 유지해야 한다면, 보관보다 먼저 현재 공유 상태를 재고해야 합니다.
비민감한 시험 프로젝트와 승인받은 시험 계정을 준비합니다. 업무 원본에 바로 적용하지 않습니다. 대상자, 남길 동료, 변경 승인자, 보관 책임자, 검증 기록의 보관 위치를 먼저 정합니다.
테스트 화면과 사람 승인 기록은 운영자가 만드는 내부 절차입니다. Claude가 자동으로 만드는 감사 로그가 아닙니다.
관리자가 조직의 프로젝트 공유를 꺼도 이미 공유된 프로젝트의 기존 구성원이 자동으로 모두 제거되는 것은 아닙니다. 공식 도움말은 새 초대가 막힌 상태에서도 기존 접근을 바꾸거나 제거할 수 있다고 설명합니다. 관리자 토글만으로 개별 멤버 회수를 대체하지 않습니다.
보관 전 Share에서 권한 회수하는 순서
1. 보관 대상과 현재 접근 경로를 고정합니다
정확한 프로젝트를 열어 이름 오른쪽 Share를 확인합니다. 프로젝트 이름만 보고 다른 프로젝트의 멤버를 지우지 않도록 프로젝트 식별자와 소유자를 내부 기록에 적습니다. 외부로 실이메일이나 원문 자료를 복사하지 않습니다.
General access가 Only people invited인지 Everyone at [your organization]인지 기록합니다. 후자라면 개인 목록에서 한 사람을 지워도 그 사람이 조직 구성원으로서 프로젝트를 볼 수 있을 가능성이 남습니다. 조직 전체 공개 범위와 직접 초대를 두 개의 접근 경로로 봅니다.
Enterprise의 그룹 공유가 설정된 경우 그룹명과 직접 초대를 따로 적습니다. 공식 문서는 그룹 공유를 Enterprise 베타 기능이라고 설명하며 그룹 구성원에게는 그룹을 통한 접근이 생길 수 있다고 합니다. 그룹으로 들어온 사람을 개인 목록에 없다는 이유로 차단됐다고 단정하지 않습니다.
2. 변경 승인자가 제거할 계정을 확정합니다
대상자의 전체 주소와 현재 역할, 유지할 동료의 역할을 대조합니다. Can view는 프로젝트 내용·지식·지침을 볼 수 있고 프로젝트 안에서 대화할 수 있지만 내용을 편집하지 못합니다. Can edit는 지식·지침 및 멤버 설정도 변경할 수 있습니다.
편집자를 모두 지우거나 Can edit를 읽기 전용으로 오해하지 않습니다. 프로젝트 인계가 필요한 승인된 동료의 권한은 유지할지 먼저 결정합니다. 대상 계정을 확정하지 못하면 권한 변경을 중단하고
확인 필요
로 남깁니다.
3. Share에서 승인된 대상만 Remove access합니다
프로젝트의 Can edit 권한을 가진 멤버가 Share 메뉴를 열어 대상 이름 오른쪽 역할을 누르고 Remove access를 선택합니다. Anthropic은 제거된 사용자가 해당 프로젝트와 그 콘텐츠에 더 이상 접근할 수 없다고 안내합니다.
이 단계는 한 사람에게 직접 부여된 프로젝트 접근을 회수하는 조작입니다. 조직 전체 General access, 다른 그룹 부여, 별도 대화 공유 링크가 있다면 그 경로까지 닫혔다는 증거가 아닙니다. 불필요한 범위 변경은 각각 다른 승인 대상으로 분리합니다.
4. 설정과 두 계정의 접근을 따로 확인합니다
Share를 다시 열어 대상이 사라지고 유지할 동료의 권한이 남았는지 읽습니다. 조직 전체에 노출해서는 안 되는 시험 프로젝트라면, 별도 승인을 받아 General access를 Only people invited로 바꿨는지도 다시 확인합니다.
가능하다면 승인된 제거 대상 시험 계정으로 직접 로그인해 비민감 시험 프로젝트가 열리지 않는지 봅니다. 승인된 내부 동료 계정은 여전히 열 수 있어야 합니다. 로그아웃 상태의 실패만으로 회수를 판정하지 않습니다.
그룹 경로가 남거나 시험 계정을 쓸 수 없다면
설정 확인
과
접근 차단 확인 필요
를 분리해 기록합니다.
5. 검증 뒤 프로젝트를 Archive합니다
권한과 접근 시험을 확인한 다음에만 승인받은 시험 프로젝트를 보관합니다. 공식 도움말의 보관 경로는 프로젝트 오른쪽 위의 점 세 개 메뉴를 열어 보관을 확인하는 방식입니다. 보관된 프로젝트는 Projects의 archived projects 탭에서도 찾을 수 있습니다.
보관 전후의 멤버 목록과 접근 시험을 비교합니다. Archive를 눌러도 멤버 권한이 바뀌지 않는다는 점을 검증 기록에 명시합니다. 이미 보관했다면 원본을 지우거나 새 프로젝트를 만들지 말고 기존 프로젝트의 공유 설정에서 회수 대상을 확인합니다.
복사해서 쓰는 접근 검토 프롬프트
아래 요청문은 사람이 직접 읽고 익명화한 시험 관찰값을 내부 메모로 정리할 때만 씁니다. Claude에게 실계정 권한을 조회하거나 Remove access 버튼을 대신 누르라는 뜻이 아닙니다.
목표: 비민감 시험 프로젝트의 보관 전 권한 회수 검토 메모 만들기
허용 입력: 승인된 익명 프로젝트 식별자, Share에서 사람이 확인한 General access 값, 직접 초대·그룹 여부, 두 시험 계정의 관찰값과 승인자
제외 입력: 실이메일, 실제 고객자료, 비밀값, 미승인 계정, 권한 변경 실행, 원본 삭제, 대화 링크 회수, 외부 전송
출력 형식: 프로젝트 식별자 | 보관 전 범위 | 회수 대상 역할 | 다른 접근 경로 | 대상 차단 시험 | 유지 멤버 시험 | 근거 위치 | 확인 필요 | 승인자 빈칸
완료 기준: 사람이 설정 재조회와 두 계정의 비민감 접근 시험을 분리 기록하고 보관 여부를 결정한 검토 메모 한 장
추정 금지: 직접 보지 않은 설정값이나 실행하지 않은 계정 시험을 성공으로 꾸미지 말고 확인 필요로 표시
승인 지점: 변경 책임자의 개별 권한 회수 승인 후 사람이 확인하며, 보관과 실제 운영 프로젝트 적용은 별도 승인
메모의 표 항목은 저자가 만든 내부 검토 양식입니다. Claude의 자동 접근 감사나 권한 변경 기능이 아닙니다. 민감한 자료나 실제 수신자의 주소를 요청문에 넣지 않습니다.
실전 인사이트
권한이 남아 있는지의 질문을 보관 버튼보다 앞에 둡니다. 프로젝트에 남은 Can edit 한 명, 조직 전체 공개, Enterprise 그룹 권한은 서로 다른 경로입니다. 하나를 줄였다고 다른 경로가 자동으로 사라지지 않습니다.
보관 후에도 프로젝트 내용을 참고할 수 있다는 공식 설명은 곧 모든 복사본을 회수할 수 있다는 뜻이 아닙니다. 이미 외부로 복사된 내용, 별도의 대화 링크, 조직의 계정 정책은 이번 프로젝트 멤버 회수 시험으로 검증할 수 없습니다. 검증표에 확인 범위와 미확인 범위를 같이 적어 둡니다.
주의할 점
General access를 Everyone at [your organization]에서 Only people invited로 바꾸는 것은 다른 구성원의 접근에도 영향을 줄 수 있습니다. 승인된 개별 회수 작업과 동일한 승인으로 처리하지 않습니다. 조직 전체 범위를 바꾸기 전에 필요한 내부 협업자의 접근을 확인합니다.
그룹이 프로젝트를 공유하고 있다면 직접 초대만 제거해도 그룹을 통한 접근이 남을 수 있습니다. 그룹 구성이나 관리 설정의 변경은 별도 책임자가 검토합니다. 별도로 공유된 대화도 프로젝트의 기본 비공개 상태와 혼동하지 않습니다.
보관은 삭제나 자동 권한 폐기, 영구 백업을 보장하지 않습니다. 이번 단계의 결과는 승인받은 비민감 시험 프로젝트의 설정과 계정별 접근 검토 메모입니다. 운영 원본 삭제, 인사 계정 비활성화, 조직 정책 변경, 외부 링크 회수는 각각 별도 승인과 검증이 필요합니다.
자주 묻는 질문
프로젝트를 Archive하면 멤버가 자동으로 제거되나요?
아닙니다. Anthropic은 멤버, 권한 수준, 프로젝트 지식이 보관 뒤에도 보존된다고 명시합니다. 접근 종료는 Share에서 따로 처리합니다.
이미 보관했다면 반드시 보관 해제한 다음 권한을 회수해야 하나요?
공식 공유 도움말은 보관 전이나 후에 공유 설정에서 접근을 제거할 수 있다고 설명합니다. 현재 계정의 메뉴에서 기존 프로젝트를 찾고 Share의 멤버 상태를 확인합니다. 보관 해제를 필수 단계라고 단정하지 않습니다.
멤버를 지웠는데도 그 계정이 프로젝트를 열 수 있나요?
General access가 조직 전체이거나 Enterprise 그룹 공유처럼 다른 권한 경로가 남았는지 확인합니다. 제거 대상의 로그인 시험과 남길 동료의 정상 접근 시험을 따로 기록합니다.
프로젝트 멤버를 제거하면 공유했던 대화 링크도 닫히나요?
프로젝트 멤버와 별도 대화 공유는 서로 다른 범위입니다. 기본적으로 프로젝트 대화는 자동 공유되지 않지만 별도로 공유한 링크가 있다면 해당 대화의 상태를 따로 확인합니다. 이번 프로젝트 보관 시험 결과만으로 링크 회수를 완료라고 적지 않습니다.
출처
- Anthropic Claude Help Center — Manage project visibility and sharing: 프로젝트 멤버 제거 경로, General access, 그룹 경로, 보관 후 권한 유지.
- Anthropic Claude Help Center — How can I create and manage projects?: Archive 동작과 점 세 개 메뉴, 보관된 프로젝트 접근.
마무리
Claude 공유 프로젝트에서 보관은 정리, Remove access는 권한 회수입니다. 보관 전에 직접 초대·조직 범위·그룹 접근을 분리해 보고, 승인된 시험 계정으로 대상 차단과 정상 협업을 확인합니다. 미확인 경로가 남았다면 완료라고 적지 말고 내부 검토 메모에
확인 필요
로 남깁니다.
