Agentforce가 관리자 계정에서는 작동하지만 일반 사용자에게는 멈추는 원인 분석 | 권한 및 공유 설정 트러블슈팅

서론

Agentforce를 자신의 관리자 계정으로 테스트했을 때는 정상적으로 작동했는데, 일반 사용자가 로그인하게 하니 갑자기 '정보를 찾을 수 없습니다'라는 메시지가 반환된 경험이 있으신가요?

저 역시 처음 이 문제에 부딪혔을 때, Agentforce 자체의 결함이라고 생각하며 설정 화면만 거의 반나절 동안 들여다봤습니다. 결론적으로 말하면, 원인은 Agentforce 자체가 아니라 Salesforce의 권한 및 공유 설정 쪽에 있는 경우가 대부분입니다.

Agentforce 권한 오류의 상당수는 사실 평소와 같은 'Salesforce 공유 설정 트러블슈팅'과 동일한 절차로 문제를 분리할 수 있습니다.

이 글에서는 에이전트 사용자 권한에 대한 개념부터 실제로 무엇을 순서대로 확인해야 하는지, 제가 실무에서 찾아낸 절차를 정리했습니다.

Agentforce가 '작동하는 사람에 따라 결과가 달라지는' 메커니즘

먼저 알아야 할 것은 회사 내부용 Agentforce(Employee Agent)는 로그인한 사용자 본인의 권한으로 작동한다는 점입니다.

요컨대, Agentforce는 마법사가 아니라, 로그인 중인 사용자를 대신하여 사내 데이터베이스를 검색해 주는 '매우 눈치 빠른 대리인' 같은 것입니다. 대리인이기 때문에, 본인이 볼 수 없는 정보는 대리인에게도 보여줄 수 없습니다.

Salesforce 공식 도움말에서도 회사 직원을 위한 Agentforce 에이전트(Employee Agent)는 '로그인한 사용자의 실행 컨텍스트에서 작동하며, 해당 사용자의 프로필, 권한 집합(Permission Set), 공유 규칙/역할(Sharing Rule/Role)에 의해 에이전트의 동작과 응답이 결정된다'고 설명하고 있습니다. 관리자는 보통 매우 강력한 권한을 가지고 있어 무엇이든 가져올 수 있지만, 일반 사용자는 자신이 본래 접근할 수 있는 범위의 레코드만 볼 수 있습니다. 바로 여기에 불일치의 정체가 있습니다.

참고로, 에이전트의 액션이 Flow를 호출하는 경우라면, Flow 자체의 실행 컨텍스트(사용자 컨텍스트인지 시스템 컨텍스트인지)도 영향을 미칩니다. 이 점은 나중에 '막히는 포인트'에서 다루겠습니다.

즉, 관리자에서는 작동하고 일반 사용자에게는 멈추는 것은 대부분 버그가 아니라 '해당 사용자가 본래 접근할 수 없는 데이터를 읽으려고 시도했기 때문'이라는 이해로 괜찮습니다!

권한 및 공유 설정을 분리하는 실전 단계

원인을 짐작했으니, 실제로 무엇을 순서대로 확인해야 하는지 살펴보겠습니다. Salesforce 공식의 레코드 액세스 트러블슈팅 절차를 Agentforce의 맥락에 맞춰 재배열했습니다.

• 오브젝트 권한을 확인합니다: 설정의 '사용자'에서 대상 사용자를 열고, '개요 보기'를 클릭합니다. '오브젝트 권한' 탭에서 Agentforce가 읽어 들일 오브젝트(거래처, 케이스 등)에 참조 권한이 있는지 확인해야 합니다. 이곳이 부족하다면, 권한 세트에서 필요한 권한을 추가합니다. 권한이 정확하다면, 다음은 '레코드 액세스' 문제입니다. (※여기에 스크린샷 추가 예정)
• 조직의 공유 설정(OWD)을 확인합니다: 설정의 빠른 검색에서 '공유 설정'을 열고, 대상 오브젝트의 '기본 내부 액세스'를 확인합니다. 이곳이 '비공개' 또는 '공개/참조 전용'으로 되어 있다면, 레코드 소유자와 그 상위 역할의 사용자만 참조할 수 있습니다. (※여기에 스크린샷 추가 예정)
• 해당 레코드의 공유 계층을 봅니다: 실제로 Agentforce가 가져오려고 시도한 레코드의 상세 화면을 열고, 액션 메뉴에서 공유 상태를 확인합니다. 누가・어떤 메커니즘으로 그 레코드에 접근할 수 있는지 목록화되어 있으므로, 일반 사용자가 여기에 포함되어 있지 않다면, 여기가 원인입니다. (※여기에 스크린샷 추가 예정)
• 역할 계층과 소유자의 관계를 확인합니다: 해당 사용자가 레코드 소유자와 같은 역할을 하는지, 또는 계층상 더 상위의 역할에 있는지 확인합니다.
• 공개 그룹의 소속을 확인합니다: 공유 규칙의 대부분은 공개 그룹 단위로 설정되어 있으므로, 대상 사용자가 예상하는 그룹에 속해 있는지 확인합니다.
• 공유 규칙을 확인 및 추가합니다: 조직의 공유 설정 예외를 특정 공개 그룹이나 역할에 대해 자동으로 만드는 메커니즘입니다. 기존 규칙의 대상 조건이 벗어나지 않았는지, 혹은 새롭게 규칙을 추가할 필요가 없는지 확인합니다.
• 그래도 해결되지 않을 경우: 큐(Queue), 거래처・기회/케이스의 영업팀(Sales Team), Territory(상권), Apex를 통한 프로그램 공유, 제한 규칙 등 다른 메커니즘이 연관되어 있을 수 있습니다. 절차 6까지로 해결되지 않으면, 이 부분을 의심해 보세요.

솔직히, 공유 계층 화면을 처음 열었을 때는 정보량이 많아서 '와, 이거 어려울 것...' 하고 긴장했는데, 실제로 만져보니 '이 사용자는 이 공개 그룹을 통해 접근하고 있다'고 제대로 알려주기 때문에, 익숙해지면 원인 특정의 가장 빠른 지름길이 됩니다.

즉, ① 오브젝트 권한 → ② 조직의 공유 설정 → ③ 역할 계층・공유 규칙 → ④ 기타 메커니즘 순서로 위에서 기계적으로 하나씩 제거해 나가면 OK라는 이해로 괜찮습니다!

주의! 걸리기 쉬운 포인트

실무에서 빠지기 쉬운 포인트를 3가지 소개합니다.

첫 번째는 에이전트 액션이 Flow를 호출하고 있는 경우입니다. Flow 자체에도 '사용자 컨텍스트(User Context)'와 '시스템 컨텍스트(System Context)'라는 실행 방법의 구분이 있으며, 시스템 컨텍스트로 작동하는 Flow를 사용하면 Agentforce 측의 사용자 권한 검사를 건너뛰고 모든 데이터에 접근할 수 있게 될 때가 있습니다. 실무에서 사용할 때는 Flow의 실행 컨텍스트는 특히 놓치기 쉬우므로 주의하는 것이 좋을 것 같습니다. 의도치 않게 정보가 너무 넓게 보이는 것은 아닌지, Flow 측의 실행 컨텍스트도 함께 확인해 주세요.

두 번째는 외부용 Agentforce(Service Agent)와 혼동하지 않는 것입니다. Service Agent는 기본적으로 전용 '에이전트 사용자'의 권한으로 작동하기 때문에, 본 기사에서 다룬 '로그인 사용자 본인의 권한으로 작동한다'는 전제가 그대로 적용되지 않습니다. 이번 분리 절차는 어디까지나 사내용 Employee Agent를 상정하고 있습니다.

세 번째는 비용 문제입니다. Agentforce Employee Agent는 Enterprise・Performance・Unlimited・Developer 에디션에서 애드온으로 제공되는 기능으로 안내되어, 기본 라이선스에 표준으로 포함되어 있지 않을 수 있습니다. 이 기사에서는 2026년 9월 시점을 기준으로 확인된 정보를 바탕으로 하고 있으므로, 실제 계약 내용 및 최신 요금 체계는 반드시 공식 정보로 확인해 주시기 바랍니다!

참고로, 사내용 Agentforce(Employee Agent)의 한국어 UI상의 정식 명칭은 이번 조사 시점에서는 공식 문서에서 확인할 수 없었습니다. 영어 표기 그대로 안내하고 있으므로, 실제 화면에서는 표기가 다를 수 있다는 점을 양해 부탁드립니다.

요약

이번 내용을 되돌아봅니다.

요약

이번 내용을 되돌아봅니다.

• Agentforce(직원 에이전트)는 관리자가 아닌 로그인한 본인의 권한으로 작동합니다.
• 관리자에게만 작동하고 일반 사용자에게는 멈추는 경우, 대부분은 버그가 아니라 권한 및 공유 설정의 문제입니다.
• 문제 해결 순서는 '① 개체 권한 → ② 조직의 공유 설정 → ③ 역할 계층/공유 규칙 → ④ 기타 메커니즘' 순서가 가장 빠릅니다.
• Flow를 호출하는 액션은 Flow 측의 실행 컨텍스트도 함께 확인해야 합니다.

권한 관련 주제는 깊이가 있는 분야이지만, 문제 해결할 순서를 알고 있다면 생각보다 어렵지 않습니다. 함께 조금씩 익숙해져 봅시다!

Discussion