Salesforce 물리 모델을 설계하라

🌐 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 데이터 아키텍처의 모듈 10/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 데이터를 일관되게 유지하기 · 다음: 장 학습 가이드, 그다음 다음 장, 기업 데이터 이해하기

이 모듈이 답하는 질문: 논리 모델을 어떻게 Salesforce 아키텍처로 바꿀까요?

이 장은 플랫폼에는 형태가 있다는 하나의 긴 논증이었습니다. 표준 개체와 사용자 정의 개체, 데이터가 있을 수 있는 곳, 필드 유형, 관계, 소유권, 라이선스, 일관성 규칙, 스토리지와 규모. 각각이 2장의 논리 모델을 구현하는 방식을 바꿀 수 있습니다. 이제 Steve Trucking의 한 단면에서 그것을 모아 봅시다.

회사 전체가 아니라 한 단면입니다. 아키텍트들이 흔히 하는 실수는 다이어그램 하나로 기업 전체를 풀려는 것입니다. 저는 추론할 수 있는 무언가를 원합니다. 리테일 파트너가 배송 목록을 보내고, Steve Trucking이 거기 있는 것을 배송하고, 각 배송에 대해 필요한 것을 보관한다. 그다음 물리적 결정을 하나씩 내립니다. 전체 설계는 파트 1 체크포인트입니다.

이미 아는 것에서 시작하라

2장에서 개념 작업을 했습니다. 리테일 파트너, 수령인, 배송 목록, 배송, 배송 품목, 정차지 유형, 배송팀, 트럭, 물류 센터, 사진. 관계에 이름을 붙이고 그 의미를 물었습니다. 되풀이하지 않겠습니다. 이제 질문은 그 개념들이 Salesforce에서 어떻게 사는가입니다. 브리프의 사실 하나가 곧바로 중요합니다. Steve Trucking은 이미 약속, 배송팀, 모바일 앱을 위해 Field Service를 쓰고 있습니다.

리테일 파트너: 계정을 새로 발명하지 마라

리테일 파트너는 Steve Trucking이 일해 주는 회사입니다. Salesforce에는 이미 회사를 위해 설계된 개체가 있습니다. 계정. 깔끔한 적합입니다. 그러니 비즈니스가 “파트너”라고 말한다고 Retail_Partner__c를 만들지 않습니다. 다른 조직과 구분하는 Retail Partner 레코드 유형을 가진 계정이고, 그것과 함께 계약, 케이스, 물류 센터장을 위한 연락처, 그 연락처들의 포털 접근이 따라옵니다. 쉬운 결정입니다. 모두가 그렇지는 않습니다.

파트너의 주문 번호는 우리의 정체성이 아니다

각 리테일 파트너는 자기 참조 번호를 보냅니다. 한 파트너의 주문은 8843119처럼, 다른 파트너의 주문은 A-984732처럼 생겼습니다. 그 번호들은 중요하지만, 누구의 것일까요? 파트너의 것입니다. Salesforce에는 자체 레코드 ID가 있고, 파트너에게는 우리와 이야기할 때 쓰는 참조 번호가 있습니다. 둘 다 존재할 수 있습니다. 2장의 “하나의 대상, 여러 식별자”입니다.

그래서 파트너의 참조 번호는 연동이 갱신을 매칭하는 데 쓰는 외부 ID가 됩니다. 그리고 두 파트너가 같은 번호를 쓸 수 있으므로 정체성은 참조 번호 혼자가 아니라 파트너와 참조 번호의 조합입니다. 먼저 도착했다는 이유로 파트너 번호를 배송의 보편적 정체성으로 삼지 말고, 레코드를 찾을 때마다 연동이 텍스트 필드를 검색하게 만들지도 마십시오.

배송: 모선을 보라

여기서 Delivery__c를 만들고 싶어집니다. 비즈니스가 “배송”이라고 했으니 배송 개체가 필요하다고요. 바로 그것을 먼저 하지 말았으면 합니다. 모듈 2에서 그랬듯 모선을 보십시오. 생명주기, 품목, 일정, 현장의 배송팀이 있는, 특정 장소에서 수행되는 작업을 위해 Salesforce에는 이미 무엇이 있을까요? Field Service의 작업 주문(Work Order)입니다. Salesforce는 그것을 고객을 위해 수행할 필드 서비스 작업이라고 설명합니다(WorkOrder (opens in a new tab)). 예정된 방문과 그 시간대는 서비스 약속(Service Appointment)이고, 그것이 배차가 일정을 잡고 배송팀 앱이 보여 주는 것입니다.

그래서 배송 → 작업 주문입니다. 단어가 일치해서가 아닙니다. 일치하지 않습니다. 동작이 우리가 이미 비용을 내고 있고 쓰려는 플랫폼 기능과 일치하기 때문입니다. 표준 개체가 비즈니스 어휘를 공유할 필요는 없습니다. 개념을 올바르게 표현해야 합니다.

Click to enlarge

4단계 중 1단계: 모선. 각 카드는 비즈니스 개념이고, 그 아래에 Salesforce 개체가 있습니다.

하지만 표준 개체는 짐을 지고 온다

나머지 절반입니다. 작업 주문은 공짜가 아닙니다. Field Service 라이선스, 자기 관계, 보안 동작, 필수 필드, 자동화, 생명주기를 가져오고, 플랫폼의 다른 부분들이 그것이 특정 방식으로 동작하기를 기대합니다. 우리가 그것을 고르는 것은 적합이 깔끔하고 동시에 그 주변에 만들어진 것을 쓰기 때문입니다. Steve Trucking이 Field Service를 전혀 원하지 않고 모델이 매 단계 프로세스와 싸운다면 다시 생각하겠습니다. 아키텍처는 레이블이 아니라 적합입니다.

배송 품목: 모델을 따르라

배송이 작업 주문이 되면, 무엇이든 발명하기 전에 그 모델의 나머지를 보십시오. 작업 주문 품목(Work Order Line Item)은 작업 주문의 하위 작업입니다(WorkOrderLineItem (opens in a new tab)). 냉장고, 설치, 헌 제품 수거. 그래서 배송 품목 → 작업 주문 품목입니다. 첫 결정이 두 번째 결정을 형성했다는 점에 주목하십시오. 엔터티마다 따로 개체를 고르는 게 아닙니다. 모델을 채택하고, 그 주변에 사용자 정의 구조를 만들기 전에 나머지를 이해하십시오.

이것은 어떤 정차지인가?

Steve Trucking에서 정차지는 배송만, 배송과 설치, 배송과 헌 제품 수거 중 하나이고, 유형마다 소요 시간, 배송팀 기술, 설치 체크리스트가 있습니다. 2장에서 그것이 레이블이 아니라 엔터티라고 정했습니다. Field Service에는 이미 그것이 있습니다. 작업 유형(Work Type), 작업 주문과 그 품목에 적용할 수 있는 작업 종류의 템플릿입니다(WorkType (opens in a new tab)). 그래서 정차지 유형 → 작업 유형입니다. 다시 말하지만 작업 유형이라는 이름의 무언가가 있어서가 아니라, 개념과 동작이 맞아떨어지기 때문입니다.

Click to enlarge

4단계 중 2단계: 모델을 따르라. 품목과 작업 유형은 작업 주문과 함께 옵니다.

배송 목록: 이제 사용자 정의 개체가 필요하다

“피닉스 물류 센터의 화요일분 파트너 목록”을 위한 표준 개체가 있을까요? 딱히 없고, 표준에 머물렀다고 말하려고 무관한 개체에 억지로 넣지 않겠습니다. 배송 목록 → Manifest__c. 그것은 수신의 단위입니다. 어디서 왔는지(파일, API 배치), 언제 왔는지, 상태와 합계, 그리고 파트너가 당일에 다시 보낼 때 무엇을 비교하는지. 배송 목록의 각 줄은 그것에 다시 연결된 작업 주문이 됩니다.

사용자 정의는 실패가 아닙니다. 개념에 깔끔한 표준 자리가 없을 때 플랫폼이 주는 것입니다. 실수는 사용자 정의 개체를 만드는 것이 아니라, 플랫폼에 이미 그 개념이 있는지 확인하지 않고 만드는 것입니다.

Click to enlarge

4단계 중 3단계: 맞는 표준 개체가 없는 곳의 단 하나뿐인 사용자 정의 개체.

사진: Salesforce가 저장할 수 있다고 저장해야 하는 건 아니다

“배송 사진이 Salesforce에 있어야 해요.” “Salesforce에”는 무슨 뜻일까요? 사용자가 Salesforce에서 사진을 봐야 한다는 건 맞습니다. 그게 이미지 파일이 코어 스토리지에 있어야 한다는 뜻일까요? 꼭 그렇지는 않습니다. 0을 세어 보십시오. 배송당 사진 약 네 장, 설치가 있으면 더 많고, 배송이 1년에 100만 건이면 1년에 사진 400만~500만 장이며, 배송은 매년 30%씩 늘어납니다.

그래서 제 출발점은 이렇습니다. 사용자가 사진에 접근해야 한다고 코어 org를 거대한 사진 저장소로 만들지 마라. 파일은 그 볼륨을 위해 만들어진 코어 밖 스토리지에 두고, Salesforce는 그것을 찾고 보여 주는 데 필요한 것만 보관합니다. 참조, 개수, 또는 사진당 작은 인덱스 레코드, 그리고 필요한 설치 사진이 다 찍혔다는 플래그. 데이터에 대한 접근과 데이터가 물리적으로 있는 곳은 서로 다른 질문입니다. 모듈 4가 다시 돌아온 것입니다.

필드: 의미를 드러내라

작업 주문에는 필드가 필요합니다. 파트너의 참조 번호, 배송 시간대, 실제 배송 시각, 상태, “대문 비밀번호”나 “마당에 개 있음” 같은 메모. 필드 카탈로그로 만들지는 않겠습니다. 모듈 6에서 했습니다. 각 필드에 질문을 던지십시오. 무엇을 뜻하는지, 누가 소유하는지, 바뀌는지, 식별자인지, 통제된 어휘인지, 저장인지 파생인지, 민감한지. 파트너의 참조 번호는 외부 ID이므로 그 고유성은 단순한 체크박스가 아니라 연동 계약의 일부입니다. 실제 배송 시각은 시점이니 날짜/시간입니다. 상태는 동작을 이끄니 자유 텍스트가 아니라 통제된 목록입니다. 그리고 누군가의 집에 대한 배송 메모는 개인정보이니 분류됩니다. 모든 필드가 의미로 거슬러 올라갑니다.

관계: 상자만 잇지 마라

계정과 작업 주문, 작업 주문과 그 품목, 배송 목록과 작업 주문, 정차지를 기술하는 작업 유형. 그다음 선마다 모듈 7의 질문입니다. 하위가 혼자 존재할 수 있는가, 누가 소유하는가, 접근을 물려받는가, 옮겨 갈 수 있는가, 삭제하면 어떻게 되는가, 하위가 얼마나 쌓일 수 있는가? 모든 작업 주문이 리테일 파트너 계정 몇 개 아래에 있다면 상위마다 하위가 수십만 건입니다. 파트 2에서 답할 스큐 질문입니다. 그리고 표준 Field Service 관계에 대해서는 우리가 설계했을 모습과 같으리라 가정하지 말고 Salesforce가 이미 어떻게 만들었는지 확인하십시오. 표준 모델을 채택하면 Salesforce가 그 안에서 내린 결정들도 채택하는 것입니다. 그 위에 짓기 전에 이해하십시오.

소유권과 수령인: 기본값이 정하게 두지 마라

기본값이 기꺼이 우리 대신 내려 줄 두 결정입니다.

배송은 누가 소유하는가? 모듈 8에서 이미 답했고, 그 답은 작업 주문에 그대로 이어집니다. 여기서 소유권은 누구의 접근도 결정하지 않으므로, 연동 사용자가 자기가 만든 작업 주문을 소유합니다. 배차 담당자는 자기 물류 센터의 것을, 배송팀은 자기 경로의 것을, 각 리테일 파트너는 포털을 통해 자기 것을 봅니다. 모두 소유권이 아니라 공유를 통해서입니다. 연동 사용자에게는 역할이 없고, 우리 공유 규칙이 쓰는 공개 그룹에도 들어가지 않습니다. 하루 3,300건이면 사흘 만에 10,000건을 넘기 때문입니다. 그리고 그 사용자가 언젠가 교체되면 어떻게 되는지 적어 둡니다.

수령인은 무엇인가? 연락처? 개인 계정? 배송에만 보관되는 무언가? Steve Trucking이 이 사람들과 관계가 있기는 한지(그들은 리테일 파트너의 고객입니다), 한 파트너가 다른 파트너의 수령인을 볼 수 있는지, 그들의 개인정보를 얼마나 오래 보관해도 되는지, 그리고 규모에 달려 있습니다. 1년에 새 수령인이 약 100만 명입니다. 아직 그 모두를 알지는 못하고, 그래도 괜찮습니다. 때로는 올바른 답이 아직 충분히 모른다입니다. 질문을 적어 두고 정보를 구하러 가십시오. 불확실성을 사용자 정의 개체에 묻어 두지 마십시오. 4~6장이 기업 데이터와 마스터 데이터의 그림을 준 뒤, 파트 1 체크포인트에서 답하겠습니다.

일관성: 올바른 층에서 모델을 보호하라

모듈 9의 사다리가 적용됩니다. 파트너의 참조 번호는 고유한 외부 ID이니 다시 보낸 배송 목록이 중복을 만들지 않고 upsert합니다. 상태는 제한된 목록입니다. 실제 배송 시각은 상태가 배송 완료일 때만 필수입니다. 설치 정차지는 체크리스트와 사진 없이 마감할 수 없습니다. 거대한 Flow 하나가 아닙니다. 규칙마다 자기 칸에.

각 조각이 사는 곳

모듈 4의 질문으로 이 단면을 한 번 더 훑어봅시다. 각 데이터 조각은 어디에 사는가? 제 수업 자료에서는 슬라이드 한 장, 논리 대 물리입니다. 2장의 논리 엔터티와, 각각이 물리적으로 놓이는 곳. 코어 내에서 sObject(사용자 정의라면 __c)나 빅 개체(__b)로, 또는 오프코어에서 외부 개체(__x)로, 혹은 Salesforce에 아예 들어오지 않는 데이터로.

• 코어 내, 매일 작업하는 것: 계정, 작업 주문과 그 품목, 서비스 약속, 작업 유형, Manifest__c.
• 코어 내, 보관: 3년이 지난 배송은 빅 개체인 배송 이력(Delivery History)으로 옮겨 갑니다. 클레임에 대비해 여전히 그곳, 뒷마당 창고에 있습니다.
• 참조: 리테일 파트너 자체의 주문 상세는 파트너의 시스템에 남습니다. 우리는 파트너의 참조 번호를 외부 ID로 보관하고, 누군가 필요할 때 나머지는 외부 개체나 연동을 통해 가져옵니다.
• 오프코어: 사진. 수백만 장의 이미지를 위해 만들어진 스토리지에 두고, 작업 주문에서 링크합니다.

그것이 물리 모델입니다. 어떤 개체인가만이 아니라, 어떤 집인가.

이제 단면 전체를 보라

• 리테일 파트너 → Retail Partner 레코드 유형의 계정. 물류 센터장은 연락처.
• 배송 → 서비스 약속으로 일정을 잡는 Field Service 작업 주문.
• 배송 품목 → 작업 주문 품목.
• 정차지 유형 → 작업 유형.
• 배송 목록 → 사용자 정의 Manifest__c.
• 파트너 참조 번호 → 작업 주문의 외부 ID, 파트너별로 고유.
• 사진 → 코어 밖에 저장. Salesforce는 참조와 완료 플래그를 보관.
• 배송 이력 → 3년 뒤 빅 개체로 보관.
• 소유권 → 연동 사용자. 접근은 공유를 통해(모듈 8).
• 수령인 → 파트 1 체크포인트를 위해 열어 둠.

Click to enlarge

4단계 중 4단계: 코어 내, 보관, 오프코어를 아우르는 단면 전체. 모든 선은 조회입니다. Salesforce는 Field Service를 조회로 만들었고, 우리는 그 결정도 함께 채택합니다.

다이어그램은 아키텍처가 아니다

그 다이어그램을 건네 드릴 수는 있지만, 그것만으로는 부족합니다. 아키텍처는 그 뒤의 추론입니다. 왜 계정인가? 깔끔하게 맞는 회사다. 왜 Delivery__c가 아니라 작업 주문인가? 배송은 현장 작업처럼 동작하고, Field Service가 이미 있다. 왜 사용자 정의 배송 목록인가? 깔끔한 표준 자리가 없다. 왜 사진은 그냥 파일이 아닌가? 볼륨과 스토리지 경제성. 왜 외부 ID인가? 다른 시스템에 경계를 넘는 안정적인 정체성이 필요하다. 왜 연동 사용자가 작업 주문을 소유하는가? 여기서는 소유권이 접근을 결정하지 않고, 그래야 감사 추적이 정직하게 유지된다. 왜 수령인은 아직 열려 있는가? 아직 충분한 질문에 답하지 않았다. 선은 결과물이고, 결정들이 그것을 만들었습니다.

그러니 3장을 떠나며 가져갔으면 하는 습관이 이것입니다. 물리 모델의 무엇이든 가리키며 **왜?**라고 물으십시오. 왜 이 개체, 이 유형, 이 관계, 이 소유자, 이 장소, 이 규칙인가? 구성에서 물리 모델로, 논리 모델로, 비즈니스 요구사항으로 답을 거슬러 추적할 수 있어야 합니다. 그럴 수 없다면 누군가 설정 화면에서 설계한 것입니다.

그리고 아직 다 따져 보지 않은 숫자들을 눈치챘을 겁니다. 파트너별 배송, 품목, 사진, 보존, 보관. 좋습니다. 설계를 확정하기 전에 0의 개수를 물으십시오. 레코드 5만 건에서 아름답게 작동하는 모델이 5억 건에서는 전혀 다르게 동작할 수 있습니다. 그것이 파트 2입니다.

시험 너머: AI가 바꾸는 것. AI에 Steve Trucking 브리프를 주면 몇 초 만에 스키마를 만들어 냅니다. 계정, 작업 주문, 사용자 정의 개체, 필드, 배포 메타데이터까지. 환상적인 가속기이지만, 그것이 검토는 아닙니다. 아키텍트의 일은 매핑과 그 결과를 확인하는 쪽으로 옮겨 갑니다. 적합, 라이선스, 소유권, 생명주기, 규모, 정체성, 보안, 그리고 플랫폼 밖에 둘 것. AI는 로켓 부스터일 뿐, 당신이 올바른 방향을 향하고 있는지는 말해 주지 않습니다.

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

• 각 비즈니스 개념이 Salesforce에 어떻게 대응하는지: 표준 개체, 사용자 정의 개체, 또는 코어 밖의 무엇.
• 어떤 식별자, 필드, 관계가 비즈니스 의미를 조용히 바꾸지 않고 구현하는지.
• 채택한 표준 모델과 함께 어떤 플랫폼 동작과 라이선스가 따라오는지.
• 설계가 완성되기 전에 소유권, 생명주기, 일관성, 스토리지, 규모에 대해 어떤 결정을 내려야 하는지.
• 어떤 질문을 임의의 구현 선택 뒤에 숨기지 않고 명시적으로 열어 둘지.

이 장을 시작하며 모델이 Salesforce에서 어떻게 살아야 하는지 물었습니다. 그것이 Salesforce 데이터 아키텍처입니다. 개체를 만드는 것도, 설정을 외우는 것도, 더 예쁜 상자를 그리는 것도 아니라, 비즈니스 모델을 플랫폼의 형태에 의도적으로 맞추는 것입니다. 모든 구조는 약속입니다. 설명할 수 있는 약속을 하십시오.

더 알아보기

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab), WorkType (opens in a new tab)(영어), 확인일 2026-10-02.
• Steve Trucking 브리프.