볼륨이 공유 모델을 만날 때

🌐 19개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기 이 섹션은 영어판이 바뀌었으며 아직 다시 번역되지 않았습니다. (35)

Data Architect 과정 7장인 규모를 위한 설계의 모듈 3/4. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 핫스팟: 소유권, 부모, 조회 스큐 · 다음: 오늘 아카이브하지 않는다면…

이 모듈이 답하는 질문: 공유를 존중하는 모델이 대용량에서도 어떻게 빠르게 유지될까요?

지난 모듈은 핫스팟을 찾았습니다. 이제 보안을 더합니다. 합리적으로 보이는 데이터 아키텍처가 비싸지는 곳입니다. 작업 주문 900만 건은 볼륨 문제입니다. 각각이 정확히 맞는 내부 사용자와 정확히 맞는 리테일 파트너에게만 보이는 작업 주문 900만 건은 대규모 공유 문제입니다. 레코드는 그냥 저장되는 것이 아닙니다. Salesforce는 **누가 이것을 볼 수 있는가?**에도 답해야 합니다. 대규모에서 그 답은 데이터 아키텍처의 일부입니다.

공유도 데이터입니다

아키텍트가 볼륨을 셀 때는 비즈니스 레코드를 셉니다. 하지만 Salesforce는 접근을 떠받치는 것도 유지합니다. 소유자, 역할, 그룹, 공유 규칙, 명시적 공유, 멤버십. 작은 규모에서는 그런 작업이 있다는 것을 잊어도 됩니다. 큰 규모에서는 안 됩니다. 그래서 저는 절대 “공유는 나중에 보안 팀이 정리할 거예요”라고 말하지 않습니다. 제가 고르는 관계, 소유자, 부모, 외부 사용자 모델, 그 하나하나가 공유에 영향을 줍니다. 데이터 아키텍트와 공유 아키텍트는 다른 사람일 수 있지만, 그들의 아키텍처는 연결되어 있습니다.

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing (새 탭에서 열림); Sharing a Record Using Apex (새 탭에서 열림)). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros. ⟲

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood (새 탭에서 열림), Winter ‘27, archived copy (새 탭에서 열림)). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables. ⟲

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare (새 탭에서 열림)). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects. ⟲

클릭하여 확대

Step 1 of 3: the records. Nine million work orders. ⟲

클릭하여 확대

Step 2 of 3: the share table, three rules to groups. ⟲

클릭하여 확대

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records. ⟲

That’s why the levers that keep sharing fast are mostly levers on the number of rows: ⟲

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source). ⟲
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs). ⟲
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3). ⟲
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below). ⟲

Test knowledge. Know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows. ⟲

접근 요구사항에서 시작하십시오

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect. ⟲

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together. ⟲

역할 계층은 조직도가 아닙니다

팀들은 역할 계층을 조직도를 그대로 본떠 설계합니다. 그러다 회사가 조직을 개편하고, 누군가 역할 하나를 옮기면, Salesforce는 접근에 미치는 결과를 계산해야 합니다. 작은 규모에서는 아무도 눈치채지 못합니다. 레코드 수백만 개에서는 조직 개편이 큰 데이터 작업입니다. 그래서 대량 레코드 소유자에 대한 지침이 역할 없음, 또는 계층 맨 위의 별도의 안정적인 역할입니다(Ownership Data Skew (새 탭에서 열림)). 이 원칙은 일반화됩니다. 대규모에서는 안정성이 설계 기능입니다. 공유 구조에 매달린 레코드가 많을수록 그것을 더 조심스럽게 바꿔야 합니다.

그룹도 마찬가지입니다. 공개 그룹은 공유 규칙을 공급하고, 사용자는 그룹에 속하고, 그룹은 그룹을 포함합니다. 유용한 도구지만, 엄청난 수의 사용자와 레코드가 늘 바뀌는 그룹 멤버십에 의존한다면 재계산을 이해해야 합니다. 그래서 대량 레코드 소유자는 공유 규칙의 원본으로 쓰이는 공개 그룹 밖에 둡니다(같은 출처). 교훈은 “공개 그룹은 나쁘다”가 아닙니다. 이것입니다. 가장 큰 레코드 쏠림을 가장 변덕스러운 접근 구조에 깊이 생각하지 않고 연결하지 마십시오.

공유 재계산은 진짜 일입니다

Steve Trucking이 운영 모델을 바꿉니다. 사용자 수백 명이 이동하고, 소유권이 바뀌고, 역할과 그룹이 바뀌고, 큰 공유 규칙 하나가 바뀝니다. 구성 작업처럼 들립니다. 하지만 플랫폼은 큰 레코드 집단의 접근 권한을 다시 계산해야 할 수 있으니, 저는 이것을 데이터 작업으로 다룹니다. 사용자, 레코드, 소유권 및 멤버십 변경이 얼마나 되나요? 재계산은 얼마나 되나요? 실제 볼륨으로 테스트할 수 있나요? 언제 돌려야 하고, 그동안 사용자에게는 무엇이 보이나요? 큰 보안 재정렬은 큰 데이터 마이그레이션과 같은 규율을 받을 자격이 있습니다.

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance (새 탭에서 열림)). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale (새 탭에서 열림), Winter ‘27). ⟲

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time. ⟲

클릭하여 확대

At scale, access realignment is a data operation. ⟲

“연기”가 가볍게 해도 된다는 뜻은 아닙니다. 공유를 연기해야 할 만큼 큰 변경이라면 계획이 필요합니다. 현실적인 볼륨으로 테스트하고, 비즈니스가 동의한 유지 보수 창, 검증, 끝나지 않을 때의 대비책, 그동안 사용자가 겪을 일에 대한 이해까지. Salesforce의 지침은 먼저 풀 샌드박스(full copy sandbox)에서 모델링하라는 것입니다(같은 출처). 테스트 레코드 5,000개로 훌륭하게 작동하는 보안 모델은 5,000만 개에 대해 아무것도 증명하지 못하기 때문입니다. 실제로 설계하는 0의 개수로 테스트하십시오.

세분화된 잠금은 도움이 되지만, 만병통치약은 아닙니다

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking (새 탭에서 열림)); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters. ⟲

Steve Trucking: 대규모 파트너 격리

체크포인트 1에서 파트너 격리가 요구사항이기 때문에 모든 작업 주문은 자기 리테일 파트너를 영구적으로 가집니다. 규모의 숫자는 그것을 덜 중요하게 만드는 것이 아니라 더 중요하게 만듭니다. Redrock이 사업의 40%라면 5년간 Redrock 작업 주문은 약 360만 건입니다. 관계는 맞습니다. Redrock은 정말로 하나의 파트너입니다. 그러니 접근 설계는 모델을 왜곡하는 대신 실제 비즈니스 관계를 따라가야 합니다(파트너 사용자는 자기 파트너의 작업 주문을, DC 관리자는 자기 DC의 작업 주문만). 지난 모듈의 DC별 하위 계정 구조가 여기서 두 번 돕습니다. 자식을 분산하고, DC 단위 접근에 매달릴 실체를 줍니다.

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times. ⟲

내부 접근은 또 다릅니다

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them. ⟲

때로는 보안이 모델을 바꿔야 합니다. 두 종류의 정보가 완전히 다른 소유자, 수명 주기, 대상, 공유 요구를 가진다면, 레코드 하나에 필드 수준 통제를 겹겹이 쌓을 수도 있고, 데이터를 분리해 자기 경계를 가진 객체로 만들 수도 있습니다. 필드 수준 보안 구성을 피하려고 분리하지는 않지만, 보안은 물리 모델을 바꿀 정당한 이유입니다.

공유에도 0의 개수가 있습니다

레코드가 각각 1,000만 개인 두 설계가 있습니다. 하나는 소유권이 단순하고, 계층이 안정적이고, 공유 규칙이 적고, 멤버십 변동이 거의 없습니다. 다른 하나는 소유권이 매우 분산되어 있고, 역할이 자주 바뀌고, 큰 중첩 그룹과 많은 공유 규칙이 있고, 조직 개편이 끊이지 않습니다. 레코드 수는 같고, 규모 문제는 완전히 다릅니다. 그래서 대용량 객체마다 저는 접근 모델의 숫자도 원합니다. 소유자는 몇 명이고 얼마나 몰려 있는지, 기본 접근, 어떤 계층 관계와 규칙과 그룹이 중요한지, 외부 사용자는 몇 명인지, 그리고 누군가 역할을 바꾸거나, 파트너가 추가되거나, 지역이 개편되면 어떻게 되는지. 그리고 질문 하나. 이 설계가 일으킬 수 있는 가장 큰 재계산은 무엇인가? 그것이 제가 테스트하고 싶은 시나리오입니다.

클릭하여 확대

Count the access model, not just the records. ⟲

최적화하느라 보안을 버리지 마십시오

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy. ⟲

시험 너머: AI가 바꾸는 것. 에이전트는 어떤 사람보다 빨리 조회하고 집계하기 때문에, 지나치게 넓은 접근 모델이 더 위험해집니다. “Brightwave의 데이터를 Redrock에게 보여 주지 마”라고 말하는 프롬프트에 기대지 마십시오. 경계는 아키텍처에 속합니다. 에이전트가 무엇을 공개하기로 선택하는지에 대한 지시가 아니라, 인가가 에이전트가 무엇에 닿을 수 있는지를 제한해야 합니다. 인가 모델을 데이터 모델과 함께 확장하십시오.

아키텍트가 여기서 결정하는 것

• 대용량 객체마다 어떤 관계, 소유자, 역할, 그룹, 공유 규칙이 접근을 좌우하는지.
• 대량 레코드 소유자와 다른 핫스팟이 변덕스러운 계층 및 그룹 구조로부터 격리되어 있는지.
• 큰 접근 재정렬을 어떻게 테스트하고, 일정을 잡고, 한 번만 재계산하고, 운영 볼륨에서 검증하는지.
• 다른 보안 요구가 레코드 하나의 접근을 복잡하게 만드는 대신 데이터를 분리할 근거가 되는지.
• 파트너, 직원, 애플리케이션, 에이전트의 접근이 정체성 지름길이 아니라 비즈니스 관계에 어떻게 묶여 있는지.

레코드 1,000개를 위한 안전한 설계를 그리기는 쉽고, 모두가 모든 것을 보는 빠른 설계를 그리기도 쉽습니다. 아키텍트의 일은 둘 다 살아남는 시스템입니다. 맞는 사람이 맞는 데이터를 보고, 0을 더해도 여전히 작동하는 시스템. 대규모에서 공유는 데이터 아키텍처의 일부입니다.

더 알아보기

• Object Reference for the Salesforce Platform, WorkOrderShare (새 탭에서 열림) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (새 탭에서 열림) (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (새 탭에서 열림), Group Membership Locking (새 탭에서 열림) and Deferred Sharing Maintenance (새 탭에서 열림), checked 2026-11-01. ⟲
• 더 깊이: Sharing and Visibility Architect 과정, 대규모 공유 (coming soon).
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲
• Salesforce, Record-Level Access: Under the Hood (새 탭에서 열림) (Winter ‘27, archived copy (새 탭에서 열림)), checked 2026-10-20. ⟲
• Apex Developer Guide, Understanding Sharing (새 탭에서 열림) and Sharing a Record Using Apex (새 탭에서 열림), checked 2026-11-01. ⟲