Claude Enterprise 그룹 공유 설정: 새 공유를 막고 기존 프로젝트 접근을 회수하는 법
TL;DR
Claude Enterprise의 그룹 공개 범위는 현재 Enterprise용 beta 기능입니다.
Share projects with this group
에서
Group members
와
Everyone
을 모두 해제하면 새 그룹 공유가 막힙니다. 이미 공유된 프로젝트 접근은 그대로 남습니다.
기존 그룹 접근은
Remove this group's access to all [number] projects
로 따로 회수해야 합니다. 첫 적용은 비민감 테스트 프로젝트에서 진행합니다. 그룹으로 받은 접근과 직접 초대·다른 그룹으로 받은 접근도 나눠 확인합니다.
핵심 3줄 요약
Discover this group
,
Share projects with this group
,
See group members
는 서로 다른 공개 범위를 제어합니다.이 글에서 다룰 내용
이 글은 기존 Enterprise 그룹을 대상으로 새 프로젝트 공유를 막는 흐름을 다룹니다. 이미 그 그룹에 공유된 프로젝트 접근도 함께 회수합니다. 그룹 삭제, SCIM 구성원 변경, 조직 전체
Public projects
정책 변경은 이번 작업에 포함하지 않습니다.
완료 기준은 버튼을 눌렀다는 기록이 아닙니다. 새 그룹 공유가 차단되고 기존 그룹 grant가 사라졌으며, 별도로 승인된 직접 협업은 의도대로 남았는지 확인한 내부 검토 기록입니다.
Claude Enterprise 그룹 공개 범위 설정이란
그룹 공개 범위는
Organization settings > Groups
에서 관리합니다. 그룹을 찾을 사람, 프로젝트를 공유할 사람, 구성원 명단을 볼 사람을 각각 정하는 설정입니다. 공식 문서는 이 기능을 Enterprise 조직의 beta로 설명합니다.
설정은 세 가지로 나뉩니다.
-
Discover this group: 그룹 이름을 찾을 수 있는 범위입니다. 그룹 구성원, 지출 한도, 역할 할당까지 보여 주는 설정은 아닙니다. -
Share projects with this group: 해당 그룹에 프로젝트를 공유할 수 있는 범위입니다. -
See group members: 그룹 구성원의 이름과 이메일 주소를 볼 수 있는 범위입니다.
각 항목에서
Group members
,
Everyone
, 또는 둘 다 해제를 선택할 수 있습니다. 새 공유를 완전히 막으려면
Share projects with this group
의 두 선택지를 모두 해제해야 합니다.
이 흐름이 맞는 상황
프로젝트가 끝났거나 팀이 재편되어 특정 그룹에 더는 새 프로젝트를 공유하면 안 될 때 알맞습니다. 과거에 그 그룹으로 공유한 프로젝트 접근까지 정리해야 한다면 기존 공유 회수 단계를 함께 수행합니다.
반대로 한 사람의 직접 초대만 없애려는 경우에는 프로젝트의
Share
메뉴에서 해당 구성원의
Remove access
를 검토하는 편이 맞습니다. 조직 전체의 공개 프로젝트를 끄는 작업도 별도 관리자 정책이므로 이 글의 그룹 공개 범위와 섞지 않습니다.
변경 전에 기록할 것
변경 전 기록은 제품이 자동으로 만드는 백업이 아니라 운영자가 남기는 내부 점검표입니다. 다음 항목을 먼저 적습니다.
- 대상 조직과 그룹 이름·표시 이름
- 현재
Discover this group,Share projects with this group,See group members값 - 화면에 표시된 기존 공유 프로젝트 수
- 비민감 private 테스트 프로젝트와 대표 그룹 구성원
- 계속 접근해야 하는 승인된 직접 협업자와 다른 접근 경로
- 변경 승인자, 실행자, 재공유가 필요할 때의 판단 담당자
Owners·Primary Owners 또는
Identity & Access
가
Can manage
인 custom role이 그룹을 관리할 수 있습니다. 권한이 없는 계정으로 우회하지 말고 승인된 관리자 계정을 사용합니다.
새 공유를 막고 기존 접근을 회수하는 6단계
1. 비민감 테스트 범위와 현재 grant를 기록합니다
실제 운영 그룹에 바로 적용하지 않습니다. 승인된 테스트 그룹과 private 프로젝트부터 고릅니다. 그룹 공유·직접 초대·다른 그룹 접근은 구분해 적습니다.
그룹 grant로만 접근하는 대표 사용자 한 명과 직접 초대로 계속 협업해야 하는 사용자 한 명을 정합니다. 이렇게 해야 회수 후의 차단 결과와 유지해야 할 협업을 한 화면에서 구별할 수 있습니다.
2. 정확한 그룹의 Visibility settings를 엽니다
Claude에서
Organization settings > Groups
로 이동해 대상 그룹의 편집 화면을 엽니다. 이름이 비슷한 그룹을 바꾸지 않도록 조직, 그룹 이름, 표시 이름을 변경 기록과 대조합니다.
이 작업은 그룹 공개 범위만 다룹니다. 그룹 삭제, 역할 변경, 구성원 추가·제거, SCIM sync는 건드리지 않습니다.
3. 새 그룹 공유를 차단합니다
Visibility settings
의
Share projects with this group
에서
Group members
와
Everyone
을 모두 해제합니다. 공식 문서에 따르면 둘 다 선택하지 않으면 이 설정은 꺼집니다.
Discover this group
과
See group members
는 별도 설정입니다. 이번 승인 범위가 새 프로젝트 공유 차단뿐이라면 두 값을 임의로 바꾸지 않습니다.
4. 기존 그룹 공유 회수를 별도로 승인받습니다
새 공유를 껐어도 기존 프로젝트 접근은 자동으로 없어지지 않습니다. 화면의
Remove this group's access to all [number] projects
가 보여 주는 프로젝트 수를 변경 기록과 대조합니다.
기존 그룹 grant를 모두 회수한다는 승인 후 이 작업을 실행하고 저장합니다. 이 조치는 기존 공유만 회수하며 미래의 새 공유를 막지 않으므로 3단계와 함께 적용해야 합니다.
5. 반영 시간을 기다리고 grant 경로를 다시 봅니다
새 공개 범위는 앱에 나타나기까지 몇 분 걸릴 수 있습니다. 공식 문서는 공유 프로젝트가 1,000개를 넘는 그룹의 회수 작업은 몇 분 이상 걸릴 수 있다고 안내합니다.
완료 표시가 보이기 전에 차단 여부를 단정하지 않습니다. 테스트 프로젝트의
Share
화면에서 그룹 grant, 직접 사용자 초대, 다른 그룹 grant를 각각 확인합니다.
6. 차단과 정상 협업을 양쪽에서 검증합니다
대표 그룹 구성원으로 새 프로젝트의 공유 대상에서 해당 그룹을 선택할 수 없는지 확인합니다. 이어서 과거에 그룹으로만 접근했던 테스트 프로젝트가 더는 열리지 않는지 확인합니다.
직접 초대로 승인된 협업자는 계속 프로젝트에 접근할 수 있어야 합니다. 관리자는 그룹을 계속 볼 수 있는데, 공식 문서상 공개 범위 설정이 관리자 그룹 접근에는 영향을 주지 않기 때문입니다. 관리자가 그룹을 볼 수 있다는 사실을 프로젝트 접근 회수 실패로 해석하지 않습니다.
그대로 복사해 쓸 변경 계획 프롬프트
아래 프롬프트는 관리자에게 변경 계획과 검증표를 먼저 만들도록 요청하는 용도입니다. 실제 설정 저장과 접근 회수는 사람이 승인한 뒤 수행합니다.
목표: Claude Enterprise 테스트 그룹에서 새 프로젝트 그룹 공유를 막고, 승인된 기존 그룹 공유를 회수한 뒤 정상 협업을 확인한다.
허용 입력: 대상 조직과 그룹 이름, 현재 Visibility settings, 화면에 표시된 공유 프로젝트 수, 비민감 private 테스트 프로젝트, 대표 사용자와 승인된 직접 협업자.
제외 입력·금지 작업: 고객·인사·계약 비밀, 운영 그룹 즉시 변경, 그룹 삭제, SCIM sync·구성원·custom role 변경, Public projects 정책 변경, 승인 전 Remove 실행.
출력 형식: 1) 변경 전 값 2) 새 공유 차단 계획 3) 기존 그룹 grant 회수 계획 4) 차단 사용자 검증 5) 정상 협업 검증 6) 확인 필요 항목 7) 승인 지점.
완료 기준: Share projects with this group의 Group members와 Everyone이 모두 해제되고, 기존 그룹 grant가 회수되며, 그룹 grant 사용자 차단과 직접 승인 사용자 접근 유지가 각각 확인된 내부 검토표.
추정 금지: 표시된 프로젝트 수 밖의 범위, 직접 초대·다른 그룹 접근의 자동 회수, 즉시 반영, 자동 롤백, 그룹 공개 범위가 관리자 접근까지 없앤다는 해석.
승인 지점: 설정 저장 전과 Remove this group's access to all [number] projects 실행 전에 변경 승인자가 각각 확인한다.
실전 활용 팁
가장 중요한 기록은 사용자가 접근할 수 있느냐보다 어떤 grant 경로로 접근하는가입니다. 같은 사용자가 그룹과 직접 초대를 모두 가지고 있으면 그룹 grant를 회수해도 프로젝트는 계속 열릴 수 있습니다.
따라서 결과를
그룹 grant 회수
,
직접 grant 유지
,
다른 그룹 grant 확인 필요
로 나눠 적습니다. 차단 실패처럼 보이는 현상을 설정 오류와 별도 접근 경로로 빠르게 구분할 수 있습니다.
주의할 점
- 그룹 공개 범위는 Enterprise beta입니다. Team의 일반 프로젝트 공유나 조직 전체
Public projects토글과 같은 기능으로 보지 않습니다. -
Share projects with this group을 끄는 일은 새 공유만 막습니다. 기존 그룹 접근은 별도 회수해야 합니다. -
Remove this group's access to all [number] projects는 기존 그룹 공유만 회수합니다. 미래 공유를 막으려면 공개 범위도 함께 꺼야 합니다. - 그룹과 구성원은 parent organization에서 공유될 수 있지만 공개 범위 설정은 organization별입니다. 한 child organization의 변경이 다른 조직에 자동 적용된다고 가정하지 않습니다.
- 그룹 공개 범위는 관리자에게 그룹이 보이는 권한을 없애지 않습니다. 프로젝트 접근 여부는 대표 일반 사용자로 따로 검증합니다.
- 그룹 삭제, 직접 초대 제거, 다른 그룹 권한 회수, SCIM 변경, 외부 공유 정책 변경은 이번 첫 완료 경계 밖에 둡니다.
자주 묻는 질문
Share projects with this group을 끄면 기존 프로젝트도 바로 안 보이나요?
아닙니다. 공식 문서는 이 설정을 끄면 새 공유가 차단되지만 이미 공유된 프로젝트는 자동으로 회수되지 않는다고 설명합니다. 기존 그룹 grant는
Remove this group's access to all [number] projects
로 별도 회수해야 합니다.
Group members만 선택하면 새 공유가 완전히 차단되나요?
아닙니다.
Group members
를 선택하면 그룹 구성원에게 공유 동작을 허용합니다. 새 그룹 공유를 완전히 막으려면
Group members
와
Everyone
을 모두 해제합니다.
관리자가 그룹을 계속 볼 수 있으면 회수에 실패한 것인가요?
그렇지 않습니다. 공개 범위 설정은 Owners·Primary Owners와
Identity & Access
권한이 있는 관리자에게 그룹이 보이는 접근에는 영향을 주지 않습니다. 그룹 관리 화면의 가시성과 일반 사용자의 프로젝트 접근을 분리해 확인해야 합니다.
회수 뒤에도 한 사용자가 프로젝트를 열 수 있는 이유는 무엇인가요?
그 사용자가 직접 초대됐거나 다른 그룹으로도 접근할 수 있습니다. 프로젝트의
Share
화면에서 그룹, 직접 사용자, 다른 그룹을 각각 확인하고 승인되지 않은 경로만 별도로 회수합니다.
출처
마무리
Claude Enterprise에서 새 그룹 공유 차단과 기존 프로젝트 접근 회수는 같은 버튼이 아닙니다.
Share projects with this group
을 끈 뒤 기존 공유 회수를 별도로 승인하고 실행해야 합니다.
마지막 판정은 관리자 화면이 아니라 실제 grant 경로에서 내립니다. 그룹 grant 사용자는 차단되고 승인된 직접 협업자는 계속 일할 수 있는지 확인하면 보안과 협업을 함께 지킬 수 있습니다.
