세일즈포스 Guest User 권한과 제한사항 정리

프로젝트에서 공개 페이지나 외부 연동 엔드포인트를 만들다 보면 Salesforce Guest User를 다루게 된다.
그런데 Guest User는 일반 사용자와 권한 모델이 좀 다르기때문에 예상하지 못한 제약 때문에 막히는 경우도 많다.
이번 글은 프로젝트들를 진행하면서 자주 부딪혔던 Guest User 관련 특이사항을 정리해보았다.

1. 게스트 사용자란?

Guest User는 로그인 없이 공개된 Experience Cloud 사이트나 Salesforce Site에 접근하는 사용자를 의미한다.
사이트마다 전용 Guest User 프로필과 사용자 레코드가 하나씩 생성되고, 해당 사이트에 접속하는 익명 사용자는 모두 같은 Guest User 컨텍스트로 동작한다.

그래서 공개 페이지를 만들거나, 외부에서 세일즈포스로 직접 호출이 들어오는 공개 엔드포인트를 설계할 때는 결국 Guest User 권한 설계를 먼저 보게 된다.

예를 들어 세일즈포스에서 webhook을 받는 구조를 만들 때도, 실제로는 이 Guest User 컨텍스트를 어떻게 다룰지부터 고민하게 된다.

2. 객체 권한이 있다고 바로 레코드가 보이는 것은 아니다

Guest User를 처음 다룰 때 가장 헷갈리는 부분이 바로 이 지점이다.
프로필에 객체 권한을 부여했다고 해서, 바로 레코드를 조회할 수 있는 것은 아니다.
세일즈포스는 접근 권한을 한 단계로 판단하지 않는다.
보통 아래 세 가지를 각각 따로 확인해야 한다.

• 객체 권한
• 레코드 접근 권한
• 필드 권한

특히 Guest User는 Secure guest user record access가 강제되기 때문에, 레코드를 읽게 하려면 Guest User Sharing Rule로 별도 공유를 열어줘야 한다.
즉 Guest User 권한을 볼 때는 객체 권한만 확인하면 안 된다.
객체 권한 + 필드 권한 + 공유 규칙을 함께 확인해야 한다.

3. 레코드 공유는 Guest User Sharing Rule 중심으로 본다.

Guest User에게 레코드 접근 권한을 줄 때는 보통 Guest user access, based on criteria 방식의 Guest User Sharing Rule을 사용한다.
실무에서는 사실상 이 방식이 Guest User에게 레코드를 노출하는 대표적인 방법이라고 보면 된다.
다만 중요한 제약이 있다.
이 방식으로 열 수 있는 권한은 읽기 전용이다.
즉 레코드를 조회할 수 있게 만드는 것은 가능하지만, 일반 사용자처럼 수정 권한까지 열어주는 방식으로 설계할 수는 없다.
또 하나 주의할 점은 이 규칙도 criteria-based sharing rule 한도에 포함된다는 것이다.
객체별로 rule 수가 많아지기 시작하면, 단순히 기능 구현 문제가 아니라 운영 관점에서도 관리 포인트가 생긴다.

4. Guest User는 왜 읽기 중심으로만 설계해야 할까?

결론부터 말하면, Guest User는 일반 사용자처럼 넓은 권한을 가질 수 없기 때문이다.
공식 문서 기준으로 Guest User에게는 View All, Modify All, Edit, Delete 같은 객체 권한을 부여할 수 없다.
실제로는 Read와 Create 중심으로만 권한을 설계하게 된다.
레코드 공유 방식도 제한적이다.
Guest User는 다음과 같은 방식으로 접근 권한을 받을 수 없다.

• Manual Sharing
• Apex Managed Sharing
• Public Group 포함
• Queue 포함

여기서 Apex Managed Sharing은 Apex 코드로 특정 레코드를 특정 사용자나 그룹에 직접 공유하는 방식인데, Guest User에게 접근 권한을 여는 용도로는 사용할 수 없다.
결국 Guest User에게 레코드 접근을 열어주는 방식은 매우 제한적이다.

그래서 실무에서는 Guest User Sharing Rule을 통한 읽기 권한 부여를 기본으로 보고 설계하게 된다.
수정이 필요한 요구사항이 있다면, Guest User에게 직접 수정 권한을 주는 방식이 아니라 별도 서버 로직이나 제한적인 system context 처리를 따로 설계해야 한다.

5. 업데이트가 필요한 경우는 별도 설계가 필요하다

이런 이유 때문에, 업데이트가 필요한 요구사항은 게스트 사용자에게 직접 수정 권한을 주는 방식으로 풀기 어렵다.
결국 코드 단에서 별도로 처리하는 방식이 필요해진다.

실무에서는 without sharing을 사용하는 방식으로 우회하는 경우가 많고, 경우에 따라서는 Guest User가 직접 레코드를 수정하지 않고 플랫폼 이벤트만 발행한 뒤 후속 처리는 다른 실행 컨텍스트에서 수행하도록 분리하는 방식을 쓰기도 한다.

다만 without sharing은 정말 최소 범위로 가져가는 게 좋다.
공식 문서에서도 이런 방식은 아주 제한적으로 사용하라고 안내하고 있기 때문에, 공개 컨트롤러 전체를 넓게 without sharing으로 열어두기보다는 실제로 필요한 DML 처리 구간만 별도 서비스로 분리해서 최소 범위로 가져가는 쪽이 훨씬 안전하다.

솔직히 프로젝트를 하다 보면 이런 부분까지 하나하나 다 챙기기는 쉽지 않다...ㅎ
그래도 위험을 알고 설계하는 것과 모르고 설계하는 것은 꽤 다르다고 생각한다 그래서 최소한 이런 제약이 있다는 점은 항상 인지하려고 하는 편이다.

6. 레코드 생성 이후 UX도 같이 고려해야 한다

게스트 사용자가 레코드를 생성하는 경우에도 같이 봐야 할 포인트가 있다.
게스트 사용자가 생성한 레코드는 더 이상 Guest User 자신이 owner가 되지 않는다.
생성된 레코드는 org의 기본 owner로 지정된 내부 사용자에게 할당된다.
그래서 게스트 사용자가 레코드 생성 직후 상세 화면을 다시 열도록 설계하면, 경우에 따라 바로 접근 오류가 날 수 있다.

7. LWC/Aura에서 Apex 호출 시 주의할 점

LWC나 Aura에서 @AuraEnabled Apex를 호출하는 경우도 주의해야 한다.
Guest User는 해당 Apex 클래스에 대한 접근 권한이 프로필이나 설정에서 열려 있어야 호출할 수 있다.
실제로는 페이지 자체는 잘 열리는데, Apex 호출만 막히는 경우가 있다.
이럴 때는 공유 규칙 문제가 아니라 Apex Class Access 문제인 경우도 많다.
즉 화면 접근이 된다고 해서 서버 호출까지 자동으로 가능한 것은 아니다.
Guest User에서는 화면 접근 권한과 Apex 호출 권한을 분리해서 확인하는 습관이 필요하다.

8. guest user 컨텍스트에서 사용할 수 없는 기능도 있다

Guest User 컨텍스트에서는 사용할 수 없는 Apex 기능도 있다.
예를 들어 ConnectApi의 일부 메서드는 Guest User 컨텍스트에서 제약이 있을 수 있다.
그래서 특정 네임스페이스나 기능을 사용할 때는, 단순히 Apex에서 호출 가능하다는 것만 보고 판단하면 조금 위험하다.
Guest User 컨텍스트에서도 실제로 지원되는지를 먼저 확인하고 설계하는 편이 안전하다. 아무 문제가 없는데 코드에서 권한문제로 에러가 난다면 이 부분을 꼭! 찾아보도록 하자...

9. 운영 시에는 접근 범위를 점검하는 것이 좋다

운영 관점에서는 Setup > Guest User Sharing Rule Access Report를 통해 현재 guest user에게 열려 있는 object / record / field 범위를 점검할 수 있다.

초기 구축 시점에는 의도한 범위만 열었다고 생각했더라도, 이후 기능이 추가되거나 공유 규칙이 늘어나면서 공개 범위가 생각보다 커질 수 있다.
그래서 운영 단계에서도 guest user가 실제로 어디까지 접근 가능한지 주기적으로 점검하는것이 좋을거같다.

 10. 마무리 

프로젝트를 진행하면서 guest user 관련 이슈는 대부분 권한 문제에서 시작됐다.
단순히 권한 설정만 조정해서 해결되는 경우도 있었지만, 경우에 따라서는 구조를 추가하거나 설계 자체를 수정해야 하는 경우도 있었다.
그래서 guest user를 사용하는 기능은 제한사항을 충분히 이해한 상태에서 처음부터 설계하는 것이 중요하다고 생각한다.