소유권과 생명주기

🌐 28개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정 3장인 Salesforce 데이터 아키텍처의 모듈 8/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 관계에는 결과가 따른다 · 다음: 데이터를 일관되게 유지하기

이 모듈이 답하는 질문: 누가 레코드를 소유하며, 레코드의 생애 동안 무슨 일이 일어날까요?

데이터 모델을 볼 때 저는 개체가 무엇이고 어떻게 연결되는지만 알고 싶은 게 아닙니다. 시간이 지나며 레코드에 무슨 일이 일어나는지 알고 싶습니다. 누가 만드는가? 누가 소유하는가? 누가 재배정할 수 있는가? 비즈니스 관계가 바뀌면, 더 이상 활성이 아니면 어떻게 되는가? 삭제되어야 하는 때가 있는가, 얼마나 오래 보관하는가? 어느 것도 ERD, 즉 엔터티 관계 다이어그램(2장 데이터 모델의 상자와 선)에 나타나지 않습니다. 전부 데이터 아키텍처입니다. 그리고 Salesforce에서 소유권은 데이터 모델과 보안 모델이 부딪히는 곳입니다.

소유권은 필드에 적힌 이름 그 이상이다

관리자들은 레코드에서 소유자를 보고 레이블로 읽습니다. 바트가 이 계정의 소유자, 리사가 저 케이스의 소유자. 그런 뜻일 수 있습니다. 하지만 Salesforce에서 소유권은 플랫폼 메커니즘이기도 합니다. 소유자가 있는 개체에서는 소유자가 역할 계층, 공유 규칙, 대기열, 재배정을 통해 누가 레코드를 볼 수 있는지 결정합니다. 그래서 “이 레코드의 소유자는 누구인가?”라고 물을 때 저는 페이지에 누구 이름이 나오는지 묻는 게 아닙니다. 어떤 보안과 생명주기 동작을 거기에 붙이고 있는지 묻는 것입니다. 소유자는 사용자일 수도 있고, 일부 개체(그중에는 사용자 정의 개체, 케이스, 리드가 있습니다)에서는 대기열일 수도 있으며, 어느 쪽이든 소유자는 레코드에 대한 모든 권한을 얻습니다(Understanding Sharing (opens in a new tab)).

그래서 저는 비즈니스 책임과 레코드 소유권을 구분합니다. 같은 사람일 때도 있고, 아닐 때도 있습니다. 비즈니스가 배차 담당자가 배송을 책임진다고 해도, 그것이 자동으로 배차 담당자를 소유자로 만들지는 않습니다. 책임은 별도 필드에 두고, 소유권은 보안과 규모를 지원하도록 설정할 수 있습니다. 둘 다 “소유자”라는 말을 쓴다고 섞이게 두지 마십시오.

공유 테이블: 소유권이 접근이 되는 곳

공유 테이블이 무엇인지조차 모르는 사람들이 있습니다. 데이터 아키텍트라면 누구나 알아야 합니다.

레코드 공유의 대부분은 관련된 공유 개체에 보관됩니다. Salesforce판 접근 제어 목록입니다(Understanding Sharing (opens in a new tab)). 계정에는 AccountShare, 연락처에는 ContactShare가 있고, 사용자 정의 개체도 자기 것을 얻습니다. Truck__c에는 Truck__Share가 있습니다(Sharing a Record Using Apex (opens in a new tab)). 그 안의 각 행은 네 가지를 말합니다.

• 어떤 레코드: 상위 ID.
• 누구: 사용자, 또는 그룹(공개 그룹, 역할의 그룹, 영역).
• 얼마나: 읽기, 편집, 또는 모두(모든 권한).
• 왜: 행 원인(row cause). 소유자는 Owner, 공유 규칙은 Rule, 수동 공유는 Manual, Team, 계정과 그 하위 사이에 Salesforce가 추가하는 암시적 원인들, 그리고 Apex 공유를 위해 개발자가 정의하는 이유들.

수업에서 저는 Workbench를 열고 레코드를 공유하면서 공유 테이블을 조회합니다. 그러면 행이 나타났다 사라지는 걸 보게 됩니다. 누군가 “이 사람이 왜 저걸 볼 수 있죠?”라고 물을 때, 답은 대개 이유와 함께 한 행에 들어 있습니다.

하지만 모든 것이 거기 있지는 않습니다. 조직 전체 기본값은 행이 아닙니다. 역할 계층도 거기에 저장되지 않습니다. 소유자보다 위에 있는 사람들의 접근은 필요할 때 계산됩니다. 그리고 모두 보기, 모두 수정, 모든 데이터 보기, 모든 데이터 수정은 공유 테이블을 완전히 건너뜁니다(Sharing a Record Using Apex (opens in a new tab)). 수업에서 제가 말하듯이, 모두 보기를 체크하면 공유 테이블을 우회한 것입니다.

Salesforce는 레코드가 어떻게 관련되어 있는지에 따라 일부 레코드를 대신 공유하기도 합니다. 이것이 암시적 공유이고, 계정과 그 하위 사이에서 동작합니다. 연락처, 케이스, 기회를 볼 수 있다면 그것이 속한 계정도 읽을 수 있습니다. 그리고 계정 소유자는 계정의 연락처, 케이스, 기회에 접근할 수 있으며, 그 수준은 소유자의 역할이 정합니다(Implicit Sharing (opens in a new tab)). 최근 릴리스에서 Salesforce는 그 하위 접근의 일부를 행으로 저장하지 않고 필요할 때 계산하므로, 공유 테이블을 조회해도 나오지 않는다고 놀라지 마십시오. 여기서는 힌트만 드립니다. 자세한 내용은 관계와 기본 제공 공유에 있습니다.

외부 사용자가 많을 때를 위한 예외가 하나 더 있습니다. 수천에서 수백만 고객을 위해 만든 Customer Community 라이선스인 대량 커뮤니티 사용자(high-volume community users)는 역할이 없고, 공개 그룹에 들어갈 수 없으며, 공유 규칙이나 수동 공유로 레코드를 받을 수 없습니다(About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). 그들에게는 공유 테이블이 답이 아닙니다. 그들은 레코드의 계정이나 연락처를 사용자 자신의 것과 일치시키는 **공유 세트(sharing sets)**를 통해 레코드에 닿습니다. 그 라이선스가 확장되는 이유 중 하나입니다. Sharing and Visibility 과정은 외부 사용자와의 공유에서 다룹니다.

그리고 모듈 7을 기억하십시오. 세부 사항 개체에는 공유 개체가 아예 없습니다. 그 접근은 마스터의 공유 개체와 마스터-세부 사항 필드의 공유 설정에서 옵니다.

데이터 아키텍트가 왜 신경 써야 할까요? 소유권이 이 테이블에 기록되기 때문입니다. 소유자가 바뀔 때마다, 새 공유 규칙이 생길 때마다, 사용자가 역할이나 그룹을 옮길 때마다 Salesforce는 행을 추가하고 제거합니다. 레코드 몇천 건이면 아무도 모릅니다. 1,000만 건이고 사용자 한 명이 대부분을 소유한다면, 잠시 뒤 만날 재계산이 그것입니다.

시험 포인트. 사용자 정의 개체의 공유 개체 이름은 Truck__Share처럼 Object__Share입니다. 세부 사항 개체에는 공유 개체가 없습니다. 그 접근은 마스터에서 옵니다. 그리고 레코드의 소유자가 바뀌면 수동 공유는 제거되고, 개발자가 정의한 이유를 가진 Apex 공유는 남습니다.

여기서 데이터 모델이 보안 모델에 바통을 넘기고, 나머지는 Sharing and Visibility Architect 과정에서 가르칩니다. 스티브의 레코드 공유 22가지 방법, 조직 전체 기본값, 소유권, 대기열, 역할 계층, 암시적 공유는 관계와 기본 제공 공유, Apex 공유 이유는 프로그래밍 방식 공유와 보안 코드입니다. 이 과정에서는 12장이 사람, 애플리케이션, 에이전트를 위해 그것을 하나로 모읍니다.

때로는 소유권을 물려받는다

지난 모듈에서 마스터-세부 사항의 하위에는 자기 소유자가 없고 상위를 따른다는 것을 봤습니다. 그게 정확히 맞는 경우가 많습니다. 비즈니스가 배송의 품목마다 다른 소유자를 필요로 할까요? 아닙니다. 배송이 생명주기를 소유하고 품목은 그것에 속합니다. 그래서 관계 설계와 소유권 설계는 함께 일어납니다. 마스터-세부 사항을 골랐을 때 이미 소유권 결정의 일부를 내린 것입니다.

시스템이 만든 레코드는 누가 소유하는가?

이제 흥미로워집니다. 사람이 계정을 만들면 그 사람이 소유자가 될 수 있습니다. 하지만 ERP가 밤사이 트랜잭션 10만 건을 보냅니다. 그건 누가 소유할까요? 연동 사용자? 대기열? 데이터에서 계산한 지역 소유자? 5년 동안 아무도 떠올린 적 없는 시스템 계정? 그리고 이제 에이전트도 레코드를 만듭니다.

제 입장은 이렇습니다. 소유권이 공유에 중요한지에 달려 있다. 연동 사용자나 에이전트 사용자도 유효한 사용자이고, 레코드를 소유할 수 있습니다. 그 개체에서 소유권이 (역할 계층이나 공유 규칙을 통해) 접근을 결정한다면, 레코드를 올바른 소유자에게 배정하십시오. 실제 사용자, 대기열, 또는 전용 소유자 사용자. 그렇지 않다면 시스템 사용자를 소유자로 두는 것이 더 나은 선택일 수 있습니다. 그러면 감사 추적이 레코드를 만든 주체로 곧장 이어지니까요.

어느 쪽이든 의도적으로 정하십시오. 모든 것을 소유한 연동 계정은 조용히 당신의 보안 아키텍처 일부가 되어 있고, 그것이 언젠가 비활성화되면 무슨 일이 생기는지 누군가는 알아야 합니다.

소유권은 규모 문제가 될 수 있다

분포도 중요합니다. 레코드 1,000만 건이 소유자 수천 명에게 퍼져 있는 것이 한 모양이라면, 레코드 1,000만 건을 사용자 한 명이 소유하는 것은 전혀 다른 모양입니다. Salesforce는 사용자 한 명이 한 개체의 레코드를 10,000건 넘게 소유하는 것을 소유권 데이터 스큐라고 부릅니다(Ownership Data Skew (opens in a new tab)). 보통 누군가 모든 것을 사용자 한 명이나 대기열 하나에 몰아 둘 때 생깁니다. 배정되지 않은 모든 리드를 자리표시자 사용자에게, 모든 연동 레코드를 연동 사용자에게. 그 사용자가 역할 계층에서 이동하거나, 공유 규칙이 의존하는 그룹에 들어가거나 나올 때까지는 무해합니다. 그러면 Salesforce가 엄청난 수의 공유 항목을 조정해야 하고, 오래 걸리는 재계산이 생깁니다.

권장 사항은 실용적입니다. 가능하면 소유권을 더 많은 사용자에게 분산하십시오. 한 사용자가 많이 소유해야 한다면 그 사용자를 역할 계층 밖에 두고, 역할이 필요하다면 맨 위의 전용 역할에 두고 옮기지 마십시오. 그리고 공유 규칙이 쓰는 공개 그룹에 넣지 마십시오(Ownership Data Skew (opens in a new tab)). 지난 모듈의 하위가 너무 많은 상위, 즉 상위-하위 스큐에도 같은 생각이 적용됩니다.

그러니 분포는 물리 모델의 일부입니다. 레코드가 몇 건인지만 묻지 말고, 어떻게 분포되어 있는지 물으십시오. 0의 개수의 또 다른 버전입니다. 0이 몇 개인가뿐 아니라 0이 어디에 몰려 있는가. 파트 2에서 스큐를 깊이 다루고, 여기서는 그것이 오는 걸 알아보기를 바랍니다. Sharing and Visibility 과정은 대규모 공유에서 다시 다룹니다.

“기본 소유자”가 아키텍처가 된다

늘 보는 패턴이 있습니다. 누가 무언가를 소유해야 할지 아무도 모르니, 누군가 “전부 연동 사용자에게 배정해요”라거나 “System이라는 범용 사용자를 만들어요”라고 말합니다. 그게 맞을 수도 있습니다. 하지만 우연히 그렇게 하지는 마십시오. 임시 기본값은 영구가 되는 습성이 있습니다. 2년 뒤 모든 레코드가 integration@company.com 소유이고, 아무도 이유를 기억하지 못하며, 바꾸는 것이 하나의 프로젝트가 됩니다. 그것이 1장의 가역성 테스트입니다. 레코드 100만 건을 소유자 한 명에게 주기 전에, 나중에 그것을 바꾸려면 무엇이 필요한지 물으십시오.

재배정은 생명주기 이벤트다

소유자는 바뀝니다. 영업 담당자가 떠나고, 영역이 옮겨 가고, 팀이 재편되고, 지역이 재조정됩니다. 소유자에 무엇이 의존합니까? 공유, 자동화, 보고서, 대기열, 에스컬레이션, 연동? 소유자를 바꾸면 누가 레코드를 볼 수 있는지가 바뀐다면, 재배정은 관리상의 정리가 아닙니다. 보안 이벤트이고, 레코드 100만 건이라면 운영 이벤트이기도 합니다. 그때 공유 테이블을 지켜보십시오. 소유자가 바뀌면 수동 공유는 제거되고, 개발자가 정의한 이유를 가진 Apex 공유는 그 변경에서 살아남습니다(Understanding Sharing (opens in a new tab)). 수업에서 저는 누군가와 레코드를 공유하고, 소유자를 바꾸고, 그러면 그 사람은 접근을 잃습니다. 교실은 늘 놀랍니다.

그리고 소유권은 접근과 같지 않다는 걸 기억하십시오. 레코드를 봐야 하는 사람이 소유자만은 아니며, Salesforce에는 접근을 부여하는 방법이 많습니다. 역할 계층, 공유 규칙, 팀, 영역, 수동 공유와 프로그래밍 공유. Sharing and Visibility 과정이 스티브의 레코드 공유 22가지 방법을 시작으로 그것들을 깊이 다룹니다. 아키텍트의 요점은 더 단순합니다. 모든 접근 문제를 소유권으로 풀지 마십시오. 누군가 레코드를 보게 하려고 소유자를 이리저리 옮기고 있다면, 아마 엉뚱한 문제를 풀고 있는 것입니다.

생성은 시작일 뿐이다

많은 데이터 모델링이 생성에서 멈춥니다. 필드, 개체, 관계, 끝. 하지만 레코드는 10년을 살 수도 있습니다. 갱신되고, 소유자가 바뀌고, 상태와 관계가 바뀌고, 비활성이 되고, 이력이 되고, 보관이 필요해지고, 언젠가는 삭제될 수도 있습니다. 아키텍처는 레코드가 어떻게 태어나는지만이 아닙니다. 태어나서 사라질 때까지 무슨 일이 일어나는지입니다.

Click to enlarge

오래됐다는 이유만으로 삭제하지 마라

리테일 파트너가 일감을 보내지 않게 됩니다. 계정을 삭제할까요? 자동으로는 아닙니다. 그 배송, 클레임, 청구 이력은 여전히 중요합니다. 트럭이 퇴역합니다. 배송 이력과 파손 클레임과 함께 삭제할까요? 그것은 더 이상 활성이 아닐 수 있지만, 그 데이터는 여전히 살아 있습니다. 그래서 저는 비활성과 사라짐을 구분합니다. 퇴역한 트럭은 모델에 남을 수 있고, 퇴사한 직원은 여전히 감사 이력에 나타날 수 있습니다. 아키텍처는 운영 관계가 끝난 뒤에도 중요한 사실을 지켜야 합니다.

보존은 비즈니스 요구사항이다

반대편도 있습니다. 모든 것을 영원히 보관하는 것도 아키텍처가 아닙니다. 스토리지는 늘고, 보고서는 느려지고, 검색은 시끄러워지고, 개인정보 보호법은 일부 데이터를 지워야 한다고 말할 수 있습니다. 그래서 저는 **이것을 얼마나 오래 보관하는가?**에 대한 명시적인 답을 원합니다. “Salesforce가 보관해요”는 보존 정책이 아닙니다.

그리고 대개 이것은 트랜잭션 데이터에 대한 질문입니다. 참조 데이터, 즉 제품, 서비스 유형, 물류 센터는 거대해지지 않고 다른 레코드가 그것을 가리키므로 보통 남습니다. 고객 데이터는 그 중간입니다. 고객의 수명을 끝내는 날이 올 수 있습니다. 특히 개인정보를 갖고 있고 보관할 이유가 끝났을 때입니다. 하지만 양은 트랜잭션에 있습니다. 배송, 주문, 케이스, 약속이 매일, 끝없이 만들어집니다. 그것이 수억 행으로 자라는 것이고, 보존이 명시적이어야 하는 곳이 거기입니다. 운영 데이터는 org에 2년, 재무 기록은 어딘가에 7년, 일부 사진은 90일. 이것들은 비즈니스 규칙이고, 아무도 묻지 않았다면 아키텍트가 물어야 합니다.

수업에서 몇 년째 하는 말입니다. 오늘 보관하지 않는다면, 언젠가 보관하긴 할 건가요? “나중에 처리하죠”는 레코드 3억 건에서 비상 프로젝트가 되는 경향이 있습니다. 파트 2에는 같은 질문 위에 세운, 보관과 영구 삭제에 대한 모듈이 통째로 있습니다.

Steve Trucking: 배송은 누가 소유하는가?

배송은 리테일 파트너의 배송 목록에서 연동이 하루에 약 3,300번 만듭니다. 누가 소유할까요? 리테일 파트너는 아닙니다. 그건 비즈니스 관계입니다. 수령인도 아닙니다. 배송팀이 실행하지만, 배송팀이 트럭을 바꿀 때마다 레코드의 소유자가 바뀌어야 할까요? 배차 담당자? 물류 센터? 대기열? 그것을 만든 연동 사용자?

이제 이 모듈을 적용하십시오. 그것을 결정하는 질문부터 시작합니다. 소유권이 누군가의 배송 접근을 결정하는가? Steve Trucking에서는 그렇지 않습니다. 배차 담당자는 자기 물류 센터의 배송을, 배송팀은 자기 경로의 배송을, 각 리테일러는 파트너 포털에서 자기 배송을 봅니다. 그중 어느 것도 레코드 소유자가 누구인지에 달려 있지 않습니다. 접근은 물류 센터, 경로, 파트너에서 옵니다.

그래서 제 답은 이렇습니다. 연동 사용자가 배송을 소유한다. 시스템 사용자가 의도적으로 레코드를 소유하는 좋은 예입니다.

• 감사 추적이 정직합니다. 모든 배송의 소유자가 그것이 어디서 왔는지 말해 줍니다. 배송 목록 연동입니다.
• 접근은 소유권이 아니라 공유에서 옵니다. 물류 센터 필드에 건 기준 기반 공유 규칙이 각 물류 센터 팀에 그 배송을 주고, 파트너는 포털을 통해 자기 배송에 닿습니다.
• 스큐는 설계로 없앱니다. 하루 3,300건이면 연동 사용자는 사흘 만에 배송 10,000건을 넘기니, 첫날부터 소유권 스큐입니다. 그에 맞게 계획한다면 괜찮습니다. 연동 사용자는 역할이 없으므로 계층에서 그 위의 무엇도 재계산할 필요가 없고, 공유 규칙이 쓰는 공개 그룹에도 들어가지 않습니다.
• 아무도 배송을 재배정하지 않습니다. 배송팀이 트럭을 바꾸고 배차 담당자가 교대해도 소유자는 절대 움직이지 않으니, 재배정 폭풍도 없고 잃을 수동 공유도 없습니다.

그리고 그 사용자가 언젠가 비활성화되거나 교체되면 어떻게 되는지 기록해 두십시오. 이제 그 사용자가 레코드 수백만 건을 소유하니까요. 그것이 다음 팀이 찾아야 할 결정입니다.

시험 너머: AI가 바꾸는 것. 에이전트는 기계의 속도로 레코드를 만들고 바꿉니다. 에이전트가 자기 사용자로 레코드 10만 건을 만들면 “소유자는 나중에 고치죠”는 스큐, 공유 재계산, 정리 프로젝트가 됩니다. 에이전트가 운영에 들어가기 전에 같은 질문으로 소유권 규칙을 정하십시오. 여기서 소유권이 공유에 중요한가?

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

• 소유권이 비즈니스 책임을 나타내는지, 보안 메커니즘인지, 둘 다인지, 그리고 소유자 필드가 아니라면 책임은 어디에 두는지.
• 레코드에 자기 소유자가 필요한지, 상위에서 물려받아야 하는지.
• 연동과 에이전트가 만든 레코드를 누가 소유하는지, 소유권이 공유를 결정하는지에 따라.
• 소유권이 어떻게 분포되는지, 그리고 한 사용자가 많이 소유해야 할 때 소유권 스큐를 어떻게 피하는지.
• 레코드가 언제 비활성이 되고, 언제 보관되고, 얼마나 오래 보존되며, 언제 삭제가 옳은지.

물리 모델을 볼 때 데이터가 어디에 저장되는지만 묻지 마십시오. 오늘 누가 소유하고, 내일 누가 소유할 수 있으며, 더 이상 필요 없을 때 어떻게 되는가를 물으십시오. 다음: 올바른 개체, 필드, 관계, 소유자를 갖추어도 데이터는 여전히 믿을 만하게 유지되어야 합니다.

더 알아보기

• Apex 개발자 가이드, Understanding Sharing (opens in a new tab)(영어), 확인일 2026-10-13: 소유자(사용자, 또는 사용자 정의 개체, 케이스, 리드의 경우 대기열)는 모든 권한을 얻는다. 공유의 대부분은 관련 공유 개체에 있다. 역할 계층은 실행 시점에 계산된다. 소유자가 바뀌면 수동 공유는 제거되고 Apex 관리 공유는 유지된다. 행 원인 값.
• Apex 개발자 가이드, Sharing a Record Using Apex (opens in a new tab)(영어), 확인일 2026-10-13: AccountShare, MyCustomObject__Share. 세부 사항 개체에는 공유 개체가 없다. 공유 개체가 추적하지 않는 것(조직 전체 기본값, 역할 계층, 모두 보기와 모두 수정).
• Salesforce 도움말, Implicit Sharing (opens in a new tab)(영어), 확인일 2026-10-13: 계정과 그 연락처, 케이스, 기회 사이의 접근.
• Salesforce 도움말, About High-Volume Community or Site Users (opens in a new tab), Sharing Rule Considerations (opens in a new tab)(영어), 확인일 2026-10-13: 역할 없음, 공유 규칙이나 수동 공유 없음. 대신 공유 세트.
• Sharing and Visibility Architect 과정: 스티브의 레코드 공유 22가지 방법, 조직 전체 기본값, 소유권, 대기열, 역할 계층, 관계와 기본 제공 공유, 프로그래밍 방식 공유와 보안 코드, 외부 사용자와의 공유, 대규모 공유.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab), Parent-Child Data Skew (opens in a new tab)(영어), 확인일 2026-10-02.