보면 안 되는 레코드를 사용자가 볼 수 있을 때 — 원인 찾는 법

이 사람이 왜 저 레코드를 볼 수 있지?는 Salesforce에서 가장 흔한 접근 권한 질문이자, 눈으로 답하기 가장 어려운 질문입니다. 플랫폼이 가시성을 한곳에서 결정하지 않기 때문입니다. 여러 메커니즘의 합집합을 부여하죠. 이 가이드는 접근을 열어 준 그 하나를 찾아내기 위한 반복 가능한 점검 순서를 제시합니다.

먼저, 사고의 틀

Salesforce 공유는 가산적이며 가장 관대한 쪽이 이깁니다. 접근을 허용하는 규칙 하나와 차단하는 규칙 하나를 찾는 게 아닙니다. 단 하나의 부여라도 찾으면 됩니다. 하나만 있어도 충분하기 때문입니다. (전체 계층 구조에 대해서는 Salesforce에서 누가 레코드를 볼 수 있는가를 참고하세요.)

단 하나의 메커니즘이라도 접근을 부여하면 사용자는 접근 권한을 갖습니다. 여러분의 일은 그것이 어느 것인지 찾는 것입니다.

1단계 — 공유 버튼 읽기

레코드에서 **공유(Sharing)**를 클릭하세요(조직 전체 기본값이 완전히 공개가 아닌 객체에서 사용 가능). 목록에는 접근 권한이 있는 사용자와 이유(Reason) 열 — Owner, Role Hierarchy, Sharing Rule, Manual Share, Team 등 — 이 표시됩니다. 대부분의 경우 여기서 곧바로 범인의 이름이 드러납니다.

사용자가 목록에 아예 없는데도 레코드를 본다면 프로필 수준의 우회를 의심하세요 — 2단계로 가세요.

2단계 — 권한 수준 우회를 배제하기

다음 권한들은 공유 모델을 완전히 무시합니다.

View All Data / Modify All Data(시스템 권한, 예를 들어 System Administrator 프로필에 있음).
해당 특정 객체에 대한 객체 수준 View All / Modify All.

사용자가 프로필이나 권한 집합을 통해 이 중 하나라도 갖고 있다면 공유를 변경해도 레코드를 숨길 수 없습니다. 그 권한을 제거해야 합니다. 사용자의 프로필 그리고 할당된 모든 권한 집합을 확인하세요.

3단계 — 위에서 아래로 공유 계층 훑기

정말로 공유 부여가 원인이라면, 어느 계층인지 식별하세요.

조직 전체 기본값이 너무 개방적임

객체의 OWD가 Public Read Only나 Public Read/Write라면, 객체 접근 권한이 있는 모든 사람이 모든 레코드를 봅니다. 해결책은 구조적입니다 — 조직 전체 기본값을 조이고 의도적으로 접근 권한을 다시 부여하세요.

역할 계층이 접근 권한을 위로 끌어올림

사용자가 역할 계층상 레코드 소유자보다 위에 있고 “Grant Access Using Hierarchies”가 켜져 있으면, 소유자의 접근 권한을 자동으로 상속받습니다. 가장 흔히 놀라는 경우입니다.

지나치게 넓은 공유 규칙

Region = EMEA → 역할 X와 공유와 같은 기준 기반 규칙은, 특히 데이터나 역할이 변경된 후 의도한 것보다 훨씬 많은 사람을 포함할 수 있습니다. 사용자의 역할, 공용 그룹, 또는 지역을 대상으로 하는 규칙을 검토하세요.

수동 또는 암시적 공유

수동 공유: 누군가 레코드의 공유 버튼을 사용했습니다.
암시적 공유: 상위 Account에 대한 접근이 하위 Case와 Contact에 제한적인 읽기 접근을 부여합니다. 사람들이 끊임없이 잊는 항목이며, 항상 읽기 전용입니다.
Apex 관리 공유: 사용자 정의 코드가 공유를 생성했습니다. 공유 버튼에는 표시되지만 출처는 코드에 있습니다.

팀과 지역

Account/Opportunity/Case 팀 멤버십이나 Enterprise Territory Management 하의 일치하는 **지역(territory)**은 각각 독립적으로 접근 권한을 부여합니다.

4단계 — 재계산 지연이 아닌지 확인하기

접근 권한이 일관되지 않아 보인다면, 최근 소유권, 역할, 규칙 변경 후 공유 재계산이 끝나가는 모습을 보고 있는 것일 수 있습니다. 버그라고 선언하기 전에 완료되도록 두세요.

진단 체크리스트

공유 버튼 → 해당 사용자의 이유(Reason) 읽기.
프로필 + 권한 집합 → View All / Modify All이 있나?
이 객체의 OWD가 너무 개방적인가?
사용자가 역할 계층상 소유자보다 위에 있나?
그들을 포함하는 공유 규칙(특히 기준 기반)이 있나?
수동, 암시적, 또는 Apex 공유가 있나?
팀 멤버이거나 일치하는 지역이 있나?
최근 변경 → 재계산을 기다리기.

첫 번째 “예”가 답입니다 — 그리고 같은 접근 권한을 부여하는 경로가 둘 이상일 수도 있습니다. 반대 문제 — 봐야 하는 레코드를 볼 수 없는 사용자 — 에 대해서는 접근 권한 누락 진단 체크리스트를 참고하세요.

오후 내내가 아니라 몇 초 만에 끝내기

프로필, 권한 집합, 그리고 여섯 가지 공유 메커니즘에 걸쳐 사용자-레코드 쌍마다 여덟 개 계층을 훑는 일은, 바로 실제 노출을 숨기는 수작업 노동입니다. AgentForceAccess가 대신 해 줍니다. 사용자가 왜 레코드를 볼 수 있는지 평이한 한국어로 물어보면, 모든 계층을 추적하고 정확한 부여 근거를 짚어 줍니다 — 그래서 바로 해결책으로 직행할 수 있습니다.

자주 묻는 질문

가장 빠른 첫 확인 방법은 무엇인가요?

레코드를 열고 공유 버튼을 클릭한 다음 해당 사용자의 "이유(Reason)" 열을 읽으세요. 대부분의 표준 객체에서는 Owner, Role Hierarchy, Sharing Rule, Manual 등 접근 권한을 부여한 메커니즘의 이름이 표시됩니다. 또한 그 사용자가 단순히 "View All Data"나 객체 수준 "View All"을 갖고 있지는 않은지도 확인하세요.

공유 버튼에 "Role Hierarchy"라고 표시됩니다 — 이제 어떻게 하나요?

역할 계층상 그 사용자보다 아래에 있는 누군가가 레코드를 소유하고 있거나(또는 공유받았고), 해당 객체에 대해 "Grant Access Using Hierarchies"가 활성화되어 있다는 뜻입니다. 그 접근을 제거하려면 계층 구조나 소유권을 바꾸거나, 사용자 정의 객체의 경우 계층 접근을 비활성화해야 합니다 — 어느 것도 가볍게 할 일은 아닙니다.

공유가 아니라 프로필 권한이 원인일 수도 있나요?

네. "View All Data"/"Modify All Data"와 객체 수준 "View All"/"Modify All"은 공유 모델을 완전히 우회합니다. 사용자가 이 중 하나라도 갖고 있다면 어떤 공유 변경으로도 레코드를 숨길 수 없으며, 대신 그 권한을 제거해야 합니다.

접근 권한이 간헐적으로 나타났다 사라지는 이유는 무엇인가요?

공유 재계산 때문입니다. 소유권 변경, 역할 이동, 규칙 편집 후 Salesforce는 공유 항목을 비동기적으로 다시 처리합니다. 그 시간 동안에는 접근 권한이 일관되지 않게 보일 수 있습니다. 구성 버그라고 결론 내리기 전에 재계산이 끝나도록 두세요.