Steve Trucking, 내가 설계한다면
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)
Data Architect 과정 6장인 마스터 데이터와 정체성의 모듈 6/6이자 파트 1의 끝. 이전: 권한 원천이 공유될 때 · 다음: 파트 2는 규모를 위한 설계 *(coming soon)*로 시작합니다
이 체크포인트가 답하는 질문: 실제 시나리오에서 파트 1을 하나로 엮을 수 있나요?
먼저 과제를 해 보십시오. 이것은 체크포인트 1 과제에 대한 제 풀이입니다. 아직 자기 설계를 그리지 않았다면, 계속 읽기 전에 그것부터 하십시오. 가치는 답을 읽는 데가 아니라 여러분의 추론을 제 추론과 비교하는 데 있습니다.
이것은 “내가 설계한다면”입니다. 유일한 답이 아니라 실현 가능한 해법 하나이고, 트레이드오프에 이름을 붙이고 제 입장을 밝힙니다. 대용량 데이터, 쿼리 설계, 통합 패턴, 마이그레이션, 트랜잭션은 아직 다루지 않았고, 그건 의도된 것입니다. 아키텍처는 더 많이 배울수록 발전합니다. 하지만 파트 1만으로도 뼈대를 세우기에는 충분합니다.
숫자에서 시작하라
섹션 제목: “숫자에서 시작하라 ”개요에서: 영업일 하루 약 3,300건, 연간 100만 건의 배송, 매년 30% 성장. 배송당 약 1.6개 품목(연간 160만 개), 배송당 약 8회의 상태 변경(연간 800만 건), 연간 사진 400만–500만 장, 하루 약 20만 건의 GPS 측정값, 연간 약 18만 건의 케이스. 세 가지 방식으로 배송 목록을 보내는 리테일 파트너 셋, 물류 센터 아홉 곳, 2인 배송팀이 타는 트럭 330대. 그리고 Steve Trucking은 이미 Service Cloud, Field Service, 파트너 포털이 있는 Salesforce org 하나를 운영합니다. 상자 하나 그리기 전에 0의 개수를 세십시오. 아래에서 여러 가지를 그 숫자가 정합니다.
배송의 핵심: 모선을 보라
섹션 제목: “배송의 핵심: 모선을 보라 ”배송이 중심이고, Field Service는 이미 배차를 합니다. 그래서 3장의 슬라이스처럼 Field Service의 표준 모델에서 시작합니다.
| 비즈니스 개념 | Salesforce object | 이유 |
|---|---|---|
| 리테일 파트너 | Account(Retail Partner 레코드 유형) | Steve Trucking이 계약하는 기업. 계약, 케이스, 포털 접근을 가짐 |
| 파트너 직원(물류 센터 관리자, 매장 직원) | Contact | 포털 사용자는 연락처여야 함 |
| 배송 하나: 수령인 한 명, 주소 하나, 파트너 주문 하나, 하루 | Work Order | Field Service의 작업 단위. 일정 관리, 모바일 앱, 서비스 보고서가 여기에 매달림 |
| 각 품목이나 서비스: 냉장고, 설치, 수거 | Work Order Line Item | 작업을 나누고, 체크리스트와 청구를 이끎 |
| 정차 종류: 배송만, 설치 포함, 수거 포함 | Work Type | 소요 시간, 기술, 설치 체크리스트를 정함 |
| 예약된 방문과 그 시간대 | Service Appointment | Field Service가 일정을 잡고 배송팀 앱이 보여 주는 것 |
| 배송팀과 트럭, 물류 센터 배차 구역 | Service Resource, Service Crew, Service Territory | Field Service는 배송팀을 하나의 리소스로 일정을 잡음 |
| 수령인 문의, 파트너 클레임 | Case | 서비스 콘솔, 엔타이틀먼트, 이메일-케이스 |
| 화요일 Phoenix 물류 센터용 파트너 목록 | Manifest__c(사용자 정의) | 수신, 대조, 재처리의 단위를 나타내는 표준 개체가 없음 |
나머지는 모두 표준으로 둡니다. 사용자 정의 개체를 더 만들지 않는 것은 의도된 것입니다. 1장의 질문이 아키텍트가 언제 사용자 정의 개체를 하나 더 만드는 데 저항해야 하느냐였고, 여기서 답은 “거의 항상”입니다. 예를 들어 파트너의 주문 줄은 새 개체가 아닙니다. 파트너의 참조로 식별되는 작업 주문입니다.
3장의 피날레(Salesforce 물리 모델을 설계하라)에서 자라난 그림입니다. 같은 개체가 같은 자리에 있고, 배송팀, 배차 구역, 케이스, 그리고 체크포인트 1이 오프코어에 두는 것이 더해졌습니다.
파트너의 주문을 배송에 맞추는 키
섹션 제목: “파트너의 주문을 배송에 맞추는 키 ”배송 목록의 각 줄은 작업 주문 하나가 되고, 해당 배송 목록에 연결됩니다. 키는 제가 가장 답을 듣고 싶은 질문입니다. 파트너가 보낸 이 줄이 바로 그 배송이라는 걸 어떻게 알까요? 제 답은 리테일 파트너와 파트너 자신의 주문·배송 참조로 만든 작업 주문의 외부 ID(예: KEYSTONE-PHX-8843119-1)이며, 고유로 표시합니다. 원천마다 필드 하나, 일대일. 그것은 우리의 식별자가 아니라 파트너의 식별자입니다. 2장의 “한 대상에 여러 식별자”이자 모듈 1의 “파트너가 자기 주문 참조를 소유한다”입니다.
왜 중요할까요? 배송 목록은 하루나 이틀 전에 도착하고 당일에 수정됩니다. 그 키가 있으면 다시 보내거나 수정된 배송 목록은 모두 중복을 만드는 대신 upsert됩니다. 수정이 작업 주문을 갱신하고, 필드 하나가 그것을 기록하고, 이미 경로가 배정된 배송의 변경은 코디네이터에게 알림을 보냅니다. 파트너의 변경은 적용되지만, 배차가 확인할 때까지 표시가 붙습니다. 4장의 그림에서 바뀌는 것도 바로 이것입니다. 지금은 모든 배송 목록이 RouteDesk에 들어오고, 코디네이터가 경로를 Salesforce에 다시 입력하고 완료된 정차지를 거꾸로 다시 입력합니다. 이 설계에서는 배송 목록이 파트너의 키로 upsert되어 Salesforce로 곧장 들어옵니다. RouteDesk는 은퇴하고, 재입력은 끝납니다. 세 가지 수신 형식은 통합 장에서 설계합니다. 데이터의 결정은 키입니다.
수령인: 개인 계정, 연락처, 아니면 둘 다 아닌가?
섹션 제목: “수령인: 개인 계정, 연락처, 아니면 둘 다 아닌가? ”이것이 파트 1에서 가장 흥미로운 데이터 결정이므로, 선택지를 먼저 보이고 제 선택을 말하겠습니다.
선택지 A: 개인 계정. 각 수령인이 개인 계정이 되고, 모든 배송에 연결됩니다. 장점: 표준이고, Service Cloud, 메시징, 콘솔과 자연스럽게 작동하며, 반복 수령인을 알아봅니다. 단점: 연간 약 100만 명의 새 수령인이 각각 기업 계정의 약 두 배 스토리지를 쓰는 개인 계정이 되어(Estimated Record Size by Object Type (opens in a new tab)), 2년 안에 org에서 가장 큰 개체 중 하나가 됩니다. 그리고 수령인은 Steve Trucking의 고객이 아닙니다. 각 리테일 파트너의 고객이고, Steve Trucking은 한 파트너의 고객을 다른 파트너의 고객과 결코 섞어서는 안 됩니다(S2).
선택지 B: 리테일 파트너 계정 아래의 연락처. 단점: 계정 서너 개 아래 연락처 100만 개는 거대한 규모의 상위-하위 스큐로, 상위 레코드당 하위 레코드 약 10,000개라는 Salesforce 지침을 훨씬 넘습니다(Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). 보여 주고, 기각하는 선택지입니다.
선택지 C: 수령인은 배송에 산다. 수령인의 이름, 전화, 이메일, 주소, 배송 메모는 배송 목록에서 가져와 작업 주문의 필드로 둡니다(주소 필드는 이미 거기에 표준으로 있습니다). 장점: 새로운 대형 개체가 없고, 데이터는 배송이 필요로 하는 만큼만 정확히 존재하며, 삭제는 파트너의 일정에 따라 배송 단위로 이루어지고, 각 배송이 한 파트너에 속하므로 파트너 격리가 저절로 됩니다. 단점: 반복 수령인을 같은 사람으로 알아보지 못합니다.
그것이 맞춰야 할 균형입니다. 여러 배송을 같은 장소의 같은 사람으로 알아봐야 할 필요가 과연 생길까요? 그 사람에게 로그인을 줘야 할까요? 그것이 자기 레코드가 필요한 수령인과, 그저 배송에 관한 데이터인 수령인 정보 사이의 선입니다. 그리고 중간 길이 있습니다. 리테일 파트너 자신의 고객 ID를 배송의 필드, 즉 **리테일 파트너 고객 ID(Retail Partner Customer ID)**로 담는 것입니다. 수령인 레코드를 만들지는 않지만, 파트너가 같은 고객에게 보내는 배송들을 하나로 묶어 주며, 그것이 더 통합된 고객 경험의 시작입니다. 그리고 그 고객이 실제로 사는 리테일 파트너의 시스템으로 곧장 이어집니다. 그것은 파트너의 식별자이므로 파트너와 함께일 때만 의미가 있습니다. 한 파트너의 고객 4417은 다른 파트너의 고객 4417과 아무 관계가 없습니다.
제 전문가적 의견으로는 선택지 C가 옳습니다. 알아보지 못하는 부분은 받아들일 만하고, 오히려 바람직합니다. Steve Trucking은 배송 이상으로 이 사람들과 관계가 없습니다. 다시 모듈 1입니다. 수령인은 파트너의 고객이고, 그들이 누구인지에 대한 권한 원천은 파트너입니다. 그리고 5장이기도 합니다. 한곳에 들어와 배송 하나에 묶인 개인정보는 보호하고, 보존하고, 삭제하기가 훨씬 쉽습니다. 그리고 2장의 정규형에도 맞습니다. 수령인의 정보는 배송과 일대일이므로 배송에 속합니다. 별도의 수령인 하위 개체는 반복되는 값 몇 개를 아끼는 대신 개체 하나, 관계 하나, 그리고 그 부담을 더할 것이고, 그보다 더 많이 아끼는 유일한 길은 리테일 파트너를 넘어 같은 사람을 하나로 다루는 것인데, 우리는 그렇게 하지 않습니다. 그래서 배송이 수령인을 담고, 리테일 파트너 고객 ID가 파트너 자신의 시스템으로 돌아가는 길이 됩니다.
파트너를 넘어 수령인을 통합할 것인가?
섹션 제목: “파트너를 넘어 수령인을 통합할 것인가? ”John Smith, 123 Main Street가 Redrock의 배송 목록과 Brightwave의 배송 목록에 나옵니다. 아마 같은 사람일 겁니다. Steve Trucking이 그들을 통합해야 할까요? 아니요, 의도적으로 하지 않습니다. 리테일 파트너를 넘어 수령인을 통합하면 S2를 어기게 됩니다. 파트너는 다른 파트너의 수령인을 결코 보아서는 안 되고, 통합 정체성이 바로 정보가 새는 다리입니다. 이 장의 입장을 적용한 것입니다. 섞이는 비용이 큰 곳에서는 의도적으로 과소 매칭하라. 그리고 여기서 섞이는 비용은 매우 큽니다.
나중에 리테일 파트너가 자기 배송 안에서 반복 수령인을 알아보고 싶어 한다면, 그것은 그 파트너로 범위를 한정한 ID 확인 도구, 예를 들어 Data 360의 ID 확인이 할 일입니다. 개인 계정이 아니라 레지스트리 방식의 지도이고, 결코 파트너를 넘나들지 않습니다. 누가 누구인지의 지도는 소유권도, 접근도 부여하지 않습니다.
org에 남는 것과 남지 않는 것
섹션 제목: “org에 남는 것과 남지 않는 것 ”3장은 데이터가 어디에 있어야 하는지 물었습니다. 여기서는 0의 개수가 답합니다.
- 현재 상태는 서비스 약속과 작업 주문에 있습니다. 상태 변경의 이력은 연간 약 800만 건이고 늘어나는데, 핵심 org에 있을 필요가 없습니다. 각 변경을 이벤트로 게시하고 웨어하우스, 즉 Snowflake에 보관합니다. org는 현재 상태를 유지하고, 이력은 서비스, 운영, 분석을 위해 여전히 존재하지만 운영 데이터베이스 안에 있지 않을 뿐입니다.
- 사진(연간 400만–500만 장, 일부는 사람이나 집 내부가 찍힘)은 그 물량에 맞게 만든 스토리지에 오프코어로 두고, 배송팀 앱에서 바로 업로드합니다. org는 필요한 것만 유지합니다. 사진마다 작은 인덱스 레코드 하나, 또는 개수와 “필수 설치 사진 완료” 플래그만. 제가 선호하는 건 더 가벼운 쪽입니다. org를 날씬하게 유지하고, 사진 저장소가 인덱스와 보존을 소유하게 하십시오.
- GPS 측정값(하루 20만 건)은 FleetLink에 남고 Snowflake로 갑니다. org에는 추적 페이지와 배차 담당자의 지도를 위한 최신 위치만 있으면 됩니다.
- RouteDesk의 8년치 이력(약 500만 건의 배송)은 웨어하우스나 아카이브로 가서 클레임 처리 시 접근할 수 있게 합니다. 그중 무엇이라도 org로 들어온다면, 그것은 파트 2의 마이그레이션 결정입니다.
체크포인트 1: 내가 설계한다면. 4장의 랜드스케이프(Steve Trucking의 랜드스케이프)와 같은 자리이고, 재입력과 스프레드시트가 사라졌다.
누가 무엇을 보고, 누구에게 라이선스가 필요한가
섹션 제목: “누가 무엇을 보고, 누구에게 라이선스가 필요한가 ”- 리테일 파트너는 자기 배송만 봅니다(S2). 모든 작업 주문은 자기 리테일 파트너를 지니고, 포털 사용자는 자기 파트너의 배송을, 물류 센터 관리자는 자기 물류 센터의 배송만 봅니다.
- 파트너 사용자에게는 공유 규칙과 역할을 지원하는 포털 라이선스가 필요합니다: Customer Community Plus 또는 Partner Community. 3장의 경기장 좌석입니다. 가장 싼 좌석으로는 이 설계에 필요한 공유를 얻지 못합니다. 두 라이선스 모두 외부 사용자에게 역할이 필요하고, Salesforce는 역할이 많을수록 org가 느려진다고 경고합니다(Experience Cloud User Licenses (opens in a new tab)). 파트너마다, 물류 센터마다 역할 하나는 괜찮지만, 매장마다 역할 하나는 아닙니다.
시험 포인트. 어떤 외부 라이선스가 표준 공유를 지니는지 알아 두십시오. Customer Community Plus와 Partner Community(외부 사용자에게 역할 필요)이며, 공유 세트를 쓰는 Customer Community는 아닙니다.
- 수령인에게는 라이선스가 필요 없습니다. 추적 페이지는 로그인이 아니라 만료되는 토큰이 담긴 링크로 배송 하나를 보여 줍니다(S3).
- 스큐를 주의하십시오. 연간 수십만 개의 작업 주문이 파트너 계정 서너 개를 가리키면 계정 데이터 스큐입니다. 한 가지 방법은 각 파트너 아래 물류 센터마다 하위 계정을 두어 하위 레코드를 아홉 갈래 이상으로 나누는 것이고, 클레임 기간이 지난 완료된 배송을 아카이브하면 상위 레코드당 활성 하위 레코드가 적게 유지됩니다. 파트 2에서 다룹니다.
내가 하지 않을 것
섹션 제목: “내가 하지 않을 것 ”수령인이 개인이라는 이유로 모든 수령인에게 개인 계정을 만들지 않겠습니다. 계정 세 개에 연락처 100만 개를 매달지 않겠습니다. Field Service의 작업 주문 옆에 사용자 정의 Delivery 개체를 만들지 않겠습니다. 파트너를 넘어 수령인을 통합하지 않겠습니다. 수백만 장의 사진이나 GPS 측정값을 핵심 스토리지에 넣지 않겠습니다. 그리고 실제로 마스터 관리 결정을 내리지 않았다면 통합된 수령인을 골든 레코드라고 부르지 않겠습니다.
아직 열려 있는 것
섹션 제목: “아직 열려 있는 것 ”파트 1은 뼈대를 세웠고, 파트 2가 그것을 시험합니다. 3년 차의 LDV 잣대(작업 주문, 서비스 약속, 품목은 모두 2–3년 안에 대용량 영역에 들어섭니다), 파트너 범위의 목록 보기를 위한 쿼리 설계, 세 가지 수신 통합과 세 가지 상태 피드, RouteDesk 마이그레이션, 당일의 트랜잭션, 그리고 포털 뒤의 보안 설계. Steve Trucking도 바뀔 것입니다. 이 설계를 간직하십시오. 다시 보게 될 겁니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 어떤 표준 개체가 핵심을 맡는지(여기서는 Field Service의 개체들), 그리고 어떤 사용자 정의 개체가 정말 정당한지(여기서는 하나).
- 각 파트너의 주문 줄을 배송에 맞추는 키, 그리고 그것이 왜 파트너에게 속하는지.
- Steve Trucking이 실제로 그들과 맺은 관계에 근거해, 수령인이 무엇인지.
- 정체성을 통합할지, 그리고 섞이는 비용이 너무 커서 감수할 수 없는 곳이 어디인지.
- 무엇이 org에 남고, 무엇이 오프코어에 있으며, 설계가 어떤 라이선스에 의존하는지.
더 알아보기
섹션 제목: “더 알아보기 ”- Steve Trucking 개요와 과제(D1, D3, DC1).
- Salesforce 도움말, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab), Experience Cloud User Licenses (opens in a new tab)(영어), 확인일 2026-10-14.
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab)(영어), 3장에서 인용.