모델을 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)
Data Architect 과정 2장인 의미를 위한 데이터 모델링의 모듈 6/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 제3정규형까지 설계하고, 한 발 물러서라 · 다음: 장 학습 가이드, 그다음 다음 장: Salesforce 데이터 아키텍처
이 모듈이 답하는 질문: 논리 데이터 모델은 어떻게 물리 Salesforce 데이터 모델이 될까요?
드디어 Salesforce 이야기를 합니다. 모든 상자를 개체로 바꾸고 싶은 충동을 참아 왔다면, 이제 그래도 됩니다. 하지만 우리가 들어온 순서를 보십시오. 비즈니스를 이해했고, 데이터를 기술했고, 각 사실을 제자리에 두었고, 어디서 그것을 일부러 구부릴지 정했습니다. 이제야 Salesforce가 그것을 어떻게 구현해야 하는지 묻습니다. 기억했으면 하는 흐름이 그것입니다. 개념 → 논리 → 물리. 개념 모델은 비즈니스를 기술합니다. 논리 모델은 데이터를 기술합니다. 물리 모델은 우리가 실제로 그것을 어떻게 만들지 기술합니다.
앉아, 기다려, 모델링
섹션 제목: “앉아, 기다려, 모델링 ”물리 단계는 작은 것에서 가장 잘 보이니, 반려동물이 먼저 갑니다.
누가 비즈니스이고 누가 사람인가? 브리더는 비즈니스이므로 레코드 유형이 Breeder인 계정이 됩니다. 주인도 계정, 또는 개인 계정이며, 레코드 유형은 Owner입니다. 같은 표준 개체의 두 종류가 다이어그램 맨 위에 나란히, 모듈 1부터 있던 바로 그 자리에 놓입니다.
표준 개체에 자리가 없는 것은 무엇인가? 반려동물, 품종, 재주, 반려동물 재주, 재주 평가는 사용자 정의 개체가 됩니다. 그리고 모듈 5에서 반려동물에 복사해 둔 종을 기억하십니까? 여기서 그것이 일을 맡습니다. 반려동물의 레코드 유형, 즉 Dog 또는 Cat이 됩니다. 개 개체와 고양이 개체 대신, 각자 페이지 레이아웃과 선택 목록 값을 가진 레코드 유형 두 개를 둔 개체 하나입니다.
어떤 관계가 마스터-세부 사항인가? 저는 하위 레코드의 상위가 절대 바뀌지 않을 때만 마스터-세부 사항을 씁니다. 반려동물 재주는 평생 자기 반려동물에 속하고, 각 재주 평가는 자기 반려동물 재주에 속하므로, 둘 다 마스터-세부 사항입니다. 그 효과는 바로 나타납니다. 마스터-세부 사항 덕분에 반려동물은 자기 반려동물 재주의 롤업 요약을 가질 수 있고, 그래서 모듈 5의 아는 재주 수가 저절로 보조를 맞춥니다. 하지만 반려동물은 집을 옮기기도 하므로, 주인은 조회입니다.
어떤 것이 조회인가? Salesforce는 상위 하나에 하위 10,000건을 넘지 않도록 권장합니다. 앉아 같은 인기 있는 재주, 흔한 품종, 큰 브리더는 그것을 쉽게 넘길 수 있으므로, 반려동물 재주는 조회로 자기 재주를 가리키고, 반려동물도 같은 방식으로 품종과 브리더를 가리킵니다. 그리고 가능하면 다형성 관계를 피하십시오. 필드 하나가 여러 개체 유형을 가리킬 수 있는 종류입니다. 첫날에는 편리하지만, 나중에 그것을 읽어야 하는 모든 것, 즉 보고서, 연동, 그리고 이제는 에이전트에게 더 어렵습니다.
무엇이 플랫폼 밖에 남는가? 반려동물이 자기 위치를 알려 주는 GPS 목걸이를 차고 있다면, 그 위치는 전혀 복사해 들일 필요가 없습니다. 목걸이의 추적 시스템에서 실시간으로 읽는 외부 개체가 될 수 있습니다.
그 다이어그램의 모든 결정은 앞에서 정한 무언가로 거슬러 올라가고, 바로 그것이 요점입니다. 이제 Steve Trucking에서 같은 단계를 밟아 봅시다.
논리 모델에서 시작하라
섹션 제목: “논리 모델에서 시작하라 ”Steve Trucking 논리 모델에는 이제 리테일 파트너, 물류 센터, 배송 목록, 배송, 배송 품목, 수령인, 경로, 정차지, 배송팀, 트럭, 배송팀 배정이 있습니다. 비즈니스 개념들이고, 이제 Salesforce에 매핑하기 시작할 수 있습니다.
리테일 파트너는 계정일 수도 있습니다. 배송은 현장에서 예정된 작업을 위해 Salesforce가 이미 가진 무언가에 대응할 수도 있고, 사용자 정의 개체가 될 수도 있습니다. 배송 목록에 맞는 표준은 없으니 아마 사용자 정의가 될 겁니다. 그리고 수령인은 정말 어려운 질문입니다. 개인 계정일까, 연락처일까, 아니면 그냥 배송에 담긴 정보일까? 그 질문은 다음 장에서 제대로 답합니다.
중요한 단어는 여전히 ~일 수도입니다. 비즈니스 개념이 Salesforce 개체처럼 들린다고 구현을 단정하지 마십시오. 그래서 논리 모델을 먼저 만들었습니다. Salesforce 설계를 시험해 볼 기준을 주니까요.
비즈니스 엔터티가 자동으로 사용자 정의 개체를 뜻하지는 않는다
섹션 제목: “비즈니스 엔터티가 자동으로 사용자 정의 개체를 뜻하지는 않는다 ”관리자들이 피했으면 하는 함정이 있습니다. “엔터티 열한 개를 찾았으니 사용자 정의 개체가 열한 개 필요하다.” 아닙니다. 논리 엔터티는 그 비즈니스 개념이 중요하다고 알려 줍니다. Salesforce가 그것을 어떻게 저장해야 하는지 지시하지는 않습니다. 개념은 표준 개체, 사용자 정의 개체, 개체 사이의 관계, 필드 하나나 몇 개, 구성에서 관리하는 값, 또는 아예 Salesforce 밖에 있는 데이터(Steve Trucking의 배송 사진이 좋은 후보입니다)가 될 수 있습니다. 그런 선택은 물리 모델에서 하며, 그래서 첫 통화에서 하지 않았던 것입니다.
속성은 물리 필드가 된다
섹션 제목: “속성은 물리 필드가 된다 ”속성에서도 같은 전환이 일어납니다. 논리 모델의 트럭에는 차량 번호, VIN, 제조사, 모델, 연식, 번호판, 상태가 있습니다. 이제 그것들이 물리적으로 어떻게 존재할지 정합니다. 어떤 개체가 소유하는지, 어떤 필드 유형을 쓰는지, 어떤 것이 필수인지, 어떤 것이 고유해야 하는지, 어떤 것이 외부 식별자인지, 어떤 것에 유효성 검사가 필요한지, 어떤 것이 저장되지 않고 파생되는지, 어떤 것이 민감한지. 논리 수준에서는 트럭이 무엇을 뜻하는지 물었습니다. 물리 수준에서는 Salesforce가 트럭을 어떻게 표현할지 묻습니다. 다른 질문입니다.
관계는 플랫폼 결정이 된다
섹션 제목: “관계는 플랫폼 결정이 된다 ”관계에 들인 시간이 여기서 보상받습니다. 각 관계가 일대일인지, 일대다인지, 다대다인지, 필수인지 선택인지, 이력이 중요한지 이미 압니다. 이제 Salesforce가 그것을 어떻게 구현할지 정합니다. 조회, 마스터-세부 사항, 또는 Salesforce 연결 개체(Salesforce Junction Object), 어쩌면 자기 속성을 가진 연결 개체. 우리가 발견했듯이 관계 자체가 비즈니스 의미를 가질 수 있기 때문입니다.
배송팀 배정을 다시 떠올려 보십시오. 이 장을 “배송팀과 트럭 사이에 Salesforce 연결 개체를 만듭시다”로 시작할 수도 있었습니다. 그랬다면 무엇을 건너뛰었을지 보십시오. 관계가 왜 존재하는지, 날짜와 경로가 필요한지, 상태가 있는지, 몇 주 뒤의 파손 클레임에 그 이력이 필요한지. 그런 비즈니스 질문이 배송팀 배정이 무엇인지 말해 줍니다. 그다음에야 Salesforce가 그것을 어떻게 만들지, 그리고 Salesforce에 이미 그 일을 하는 무언가가 있는지 정해야 합니다.
이제 물리 모델을 그려라
섹션 제목: “이제 물리 모델을 그려라 ”다이어그램이 다시 바뀝니다. 개념 모델은 비즈니스 개념과 단순한 선을 보여 주었습니다. 논리 모델은 속성, 키, 카디널리티, 관계에 숨은 엔터티를 더했습니다. 이제 물리 모델은 Salesforce처럼 보이기 시작합니다. 표준 개체, 사용자 정의 개체, 필드, 관계 유형, 그리고 플랫폼 밖에 있는 것.
그 세 다이어그램을 나란히 놓고 흐름을 볼 수 있기를 바랍니다. 서로 무관한 다이어그램 세 개가 아니라 세 수준에서 본 같은 비즈니스입니다.
제가 이것들을 어떻게 그리는지 한마디 하겠습니다. 배치가 메시지의 일부이기 때문입니다. 주 개체를 가운데에서 약간 아래에 둡니다. 상위 개체가 있으면 약간 위에 두어, 비즈니스가 생각하는 방식대로 위에서 아래로, 왼쪽에서 오른쪽으로 모델을 읽게 합니다. 참조 데이터는 옆으로 갑니다. 색도 의미가 있습니다. 저는 Salesforce를 늘 파란색으로 하고, 회사 자체 시스템에는 색을 하나 고르는데, 보통 초록색입니다. 초록은 친근하고 좋은 색이니까요. 빨간색은 쓰지 않고, 노란색은 조금 거칩니다. 모델이 그렇게 배치되면 저에게 노래를 부릅니다. 여러분이 보게 될 다이어그램 상당수는 사실 공간 관리입니다. 꽉 찬 차고에 차를 어떻게 다 세울까? 저는 마음이 붙잡을 수 있는 논리적인 그림을 그리고 싶습니다.
물리 모델은 플랫폼을 존중해야 한다
섹션 제목: “물리 모델은 플랫폼을 존중해야 한다 ”Salesforce는 범용 관계형 데이터베이스가 아닙니다. 관계, 소유권, 보안, 보고에 대해 나름의 생각이 있습니다. 한계, 쿼리 동작, 자동화가 있고, 대규모에서 모델이 어떻게 동작하는지에 영향을 주는 아키텍처가 있습니다. 그래서 화이트보드에서 완벽해 보이던 논리 모델도 물리 모델이 되면서 바뀌어야 할 수 있습니다. Salesforce가 방해하는 게 아닙니다. 플랫폼에는 형태가 있다는 뜻이고, 좋은 아키텍트는 그 형태를 이해합니다. 다음 장이 바로 그 이야기입니다.
때로는 모듈 5에서 내린 비정규화 결정 때문에 물리 모델이 깔끔한 논리 모델과 일부러 달라지기도 합니다. 이유를 설명할 수 있다면 괜찮습니다.
설정 화면에서 설계하지 마라
섹션 제목: “설정 화면에서 설계하지 마라 ”혹시 이런 습관이 있다면 버렸으면 합니다. 설정 → 개체 관리자 → 새 사용자 정의 개체에서 데이터 아키텍처를 시작해, 모델을 만들어 가며 알아내는 것입니다. Salesforce는 무언가를 만드는 것을 믿기 힘들 만큼 쉽게 해 줍니다. 그것이 강점이고, 약한 데이터 모델이 그토록 빨리 생기는 이유이기도 합니다. 몇 번 클릭하면 개체가, 몇 번 더 하면 필드와 관계가 생깁니다. 그러면 데이터가 들어오고, Flow가 만들어지고, 보고서가 생기고, 연동이 그것에 의존하게 되며, 5분 만에 만든 개체를 바꾸는 비용이 아주 커집니다. 1장의 가역성 테스트입니다. 그러니 새 사용자 정의 개체를 클릭하기 전에 모델을 그리십시오.
물리가 영구를 뜻하지는 않는다
섹션 제목: “물리가 영구를 뜻하지는 않는다 ”제가 세 모델을 분리해 두는 이유가 하나 더 있습니다. 기술은 바뀝니다. 오늘 Steve Trucking 데이터 일부는 Salesforce 코어에 있습니다. 내일은 일부가 Data 360, 웨어하우스, 또는 아직 고르지 않은 시스템에 있을 수 있고, AI 어시스턴트에는 자기만의 표현이 필요합니다. 물리 아키텍처는 바뀔 수 있지만, 비즈니스 개념은 놀랄 만큼 안정적입니다. 리테일 파트너, 배송, 수령인은 여전히 존재합니다. 그것이 논리 모델을 가치 있게 만듭니다. 오늘의 구현에 묶이지 않은, 오래가는 비즈니스 기술입니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”논리 모델을 물리 Salesforce 모델로 바꿀 때, 저는 이것을 결정합니다.
- 어떤 비즈니스 엔터티가 Salesforce 표준 기능에 대응하고, 어떤 것에 사용자 정의 개체나 다른 표현이 필요한지.
- 논리 속성이 어떻게 물리 필드가 되고, 관계가 플랫폼에서 어떻게 구현되는지.
- 의도적인 비정규화가 물리 설계의 어디에 들어가는지.
- 어떤 데이터가 Salesforce에 속하고, 어떤 데이터가 다른 곳에 속하는지.
- 어떤 플랫폼 특성 때문에 물리 모델이 논리 모델과 달라져야 하는지.
무엇보다 저는 각 결정을 거슬러 추적할 수 있기를 원합니다. 제 물리 모델의 무엇을 가리키며 **“그게 왜 거기 있죠?”**라고 물으면, 논리 모델과 개념 모델을 거쳐 비즈니스가 실제로 필요로 하는 무언가까지 데려다 드릴 수 있어야 합니다. 비즈니스 → 개념 → 논리 → 물리.
시험 너머: AI가 바꾸는 것. 이제 AI는 요구사항 문서를 한 번에 Salesforce 개체와 필드까지 가져갈 수 있습니다. 그래서 순서가 덜 중요해지는 게 아니라 더 중요해집니다. AI가 요구사항에서 구성으로 건너뛰었다면, 그 사이에 무슨 일이 있었는지 보여 달라고 하십시오. 무엇을 엔터티로 정했는지, 어떤 키를 골랐는지, 어떤 관계를 가정했는지, 어디서 비정규화했는지. 그것들은 아키텍처 결정이고, 아키텍트는 여전히 그것을 봐야 합니다.
이 장은 첫 통화에서 명사를 들으며 시작해, 비즈니스까지 거슬러 추적할 수 있는 물리 모델로 끝납니다. 이제 Salesforce 위에 짓기로 했으니 다음 질문은 더 깊어집니다. 우리는 실제로 어떤 데이터 플랫폼 위에 짓고 있는가?
더 알아보기
섹션 제목: “더 알아보기 ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27(영어, 확인일 2026-10-02): “상위 레코드 하나에 하위가 10,000건을 넘지 않도록 상위-하위 관계를 구성하라.” 데이터 스큐에 관한 지침이지 고정된 제한이 아닙니다. 7장에서 더 깊이 다룹니다.
- Roll-Up Summary Field (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-12): 롤업 요약은 마스터-세부 사항 관계를 통해 세부 레코드를 세거나 합산합니다.