표준 데이터 모델

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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle. — AI로 생성한 이미지

Data Architect 과정 3장인 Salesforce 데이터 아키텍처의 모듈 2/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: Salesforce 데이터 플랫폼: 데이터베이스 그 이상 · 다음: 직접 만들기: 사용자 정의 개체

이 모듈이 답하는 질문: Salesforce는 당신을 위해 무엇을 이미 모델링해 두었고, 그것은 어떻게 짜여 있을까요?

모듈 1에서 모선을 보라고 했습니다. 무언가를 발명하기 전에 Salesforce 자신은 그것을 어떻게 하는지 보라는 것이죠. 이 모듈에서 실제로 들여다봅니다. Salesforce는 이미 비즈니스의 많은 부분을 표준 개체로 모델링해 두었고, 제가 들어가 보는 대부분의 org에서 그중 두 모델이 일의 대부분을 합니다. Sales 모델과 Service 모델입니다. 무언가가 사용자 정의 개체가 될 자격이 있는지 정하려면, 먼저 이미 무엇이 있는지 알아야 합니다. 그것이 다음 두 모듈입니다.

무엇이 개체를 표준으로 만드는가

표준 개체는 기본으로 제공됩니다. Salesforce가 만들었고, 정해진 용도가 있고, 자기 필드와 관계를 갖고 옵니다. 필드를 추가하고, 그것을 중심으로 자동화를 만들고, 레이아웃을 바꿀 수는 있지만, 다시 설계할 수는 없습니다. 표준 필드와 관계는 Salesforce의 것입니다.

이름을 보십시오. Account, Contact, Case. 접두사도 없고 접미사도 없습니다. Salesforce가 그 공간을 자기 몫으로 남겨 둔 것입니다. 우리가 만드는 것은 모두 __c로 끝나므로, Salesforce는 당신 org의 어떤 것과도 충돌하지 않고 언제든 새 표준 개체를 추가할 수 있습니다. 실제로 릴리스마다 추가합니다.

어느 시점에 누군가 제품 개체를 만들었는데 잘되지 않아 뒤에 남겨 둬야 했습니다. 그래서 API 이름이 Product2입니다. 누군가 Salesforce를 안다고 말할 때 제 첫 번째 리트머스 시험입니다.

Sales 모델

왼쪽, 리드(Lead)에서 시작합니다. 고객이 될 수도 있는 누군가입니다. 리드는 아직 모델의 일부라고 하기 어렵습니다. 대기 구역입니다. 리드를 전환하면 Salesforce가 진짜 레코드를 만듭니다. 계정, 연락처, 그리고 거래가 있다면 기회. 그래서 저는 리드를 옆으로 떨어뜨려 그립니다.

계정은 회사입니다. 그 연락처는 거기서 일하는 사람들입니다. 기회는 그 계정과의 거래입니다. 여기까지는 예상 밖의 것이 없습니다.

이제 흥미로워집니다. 거래에는 무엇이 들어 있을까요? 각 줄이 기회 제품(Opportunity Product)이고, 기회 제품은 제품을 곧장 가리키지 않습니다. 가격 목록 항목(Price Book Entry)을 가리킵니다. 이 제품을, 이 가격에, 이 가격 목록에서. 가격 목록 항목은 제품과 가격 목록(Price Book) 사이에 있으므로, 같은 제품이 표준 가격 목록에서는 한 가격을, 파트너 가격 목록에서는 다른 가격을 가질 수 있습니다.

관계 두 개가 차례로 사물이 된 것입니다. 2장에서 배송과 제품 사이의 배송 품목, 개(Dog)와 재주(Trick) 사이의 개 재주(Dog Trick)를 기억하십니까? Salesforce도 여기서 정확히 같은 일을 두 번 했습니다. 기회와 가격 목록 항목 사이의 기회 제품, 그리고 제품과 가격 목록 사이의 가격 목록 항목. 이것을 읽을 수 있으면 표준 데이터 모델의 대부분을 읽을 수 있습니다.

Click to enlarge

그 사슬을 가까이서, 그것을 묶어 주는 필드와 함께 보면 이렇습니다.

Click to enlarge

사람들이 걸려 넘어지는 규칙이 하나 있습니다. 표준 가격 목록이 있고, 다른 어떤 가격 목록의 가격 목록 항목이든 그 제품의 표준 가격을 그대로 쓸 수 있습니다. 기회의 제품을 로드하기 전에 그 기회가 어떤 가격 목록을 쓰는지 아십시오.

Service 모델

이제 집의 다른 쪽입니다. 같은 계정, 같은 연락처. 무언가 잘못되면 고객은 케이스를 엽니다.

케이스는 대개 고객이 가진 무언가에 관한 것이고, Salesforce에는 그것을 위한 개체가 있습니다. 자산입니다. 모듈 5에서 저는 이것을 사람들이 간과하는 표준 개체라고 부를 겁니다. 고객이 우리에게서 샀든 아니든, 고객이 가진 것입니다.

그리고 고객은 무엇을 받을 자격이 있을까요? 그것이 자격(Entitlement)입니다. 계정이 받을 수 있는 지원으로, 흔히 자산, 제품, 서비스 계약에 묶여 있습니다. 케이스에 자격을 붙이면, 이제 케이스는 자신이 어떤 수준의 지원을 받아야 하는지 압니다.

Click to enlarge

케이스에서 자기 자신으로 되돌아가는 선을 보십시오. 모든 케이스에는 상위 케이스(Parent Case) 필드가 있고, 그것은 다른 케이스를 가리킵니다. 그것이 자기 조회(self-lookup), 즉 개체에서 자기 자신으로 가는 관계입니다. 처음 보면 많은 사람이 헷갈려 하니, 제가 그것을 쓰는 두 가지 이유를 말씀드리겠습니다.

첫째: 작은 문제들로 쪼개지는 큰 문제. 고객이 설치 전체가 멈췄다고 보고합니다. 우리는 네트워크, 하드웨어, 구성에 대한 하위 케이스를 열고, 각각 따로 처리하며, 모두 위로 해결됩니다. 하위 케이스가 다 끝나기 전에는 상위 케이스도 끝나지 않습니다.

둘째: 이력. 지난달에 한 케이스가 종료되었는데, 이제 같은 문제가 다시 생겼습니다. 새 케이스가 원래 케이스를 가리키므로, 그것을 여는 사람은 누구든 이 일이 전에도 있었다는 것과 그때 무엇을 했는지 볼 수 있습니다.

자기 조회는 모듈 7에서 관계를 다룰 때 다시 봅니다.

두 다이어그램에서 계정과 연락처가 같은 자리에 있다는 것을 눈여겨보십시오. 같은 레코드입니다. 영업 담당자와 서비스 상담원은 집의 다른 쪽에서 같은 고객을 보고 있습니다. 그것이 표준에 머물러야 하는 가장 강력한 논거 중 하나입니다. 이 모델들은 만나도록 만들어졌습니다.

파일과 첨부 파일

레코드에 있는 모든 것이 필드는 아닙니다. 계약서, 사진, PDF, 스프레드시트는 파일이고, 레거시인 예전 첨부 파일 모델이 아니라 Salesforce Files에 속합니다. 문서가 이미 SharePoint Online, OneDrive, Google Drive, Box에 있다면 Files Connect로 사용자가 복사하지 않고도 Salesforce에서 그것에 닿을 수 있습니다.

파일은 레코드와 다르게 셉니다. Salesforce는 스토리지를 둘로 나눕니다. 파일 스토리지는 첨부 파일, Files, Salesforce CRM Content, Chatter 파일 등을 담고, 데이터 스토리지는 레코드를 담습니다. 모든 레코드에 사진이나 스캔이 붙으면 파일 스토리지는 빠르게 늘어납니다. 그래서 현장 앱의 사진처럼 대량의 이미지는 Salesforce 밖에 두고 Salesforce에는 링크만 남기는 것이 맞는 경우가 많습니다. 모듈 4에서 다시 다룹니다.

열 두 개든 이백 개든

데이터 스토리지도 데이터베이스와 다르게 셉니다. 보통의 데이터베이스에서 열 두 개에 행 100만 개인 테이블은 작고, 열 백 개에 행 100만 개인 테이블은 코끼리입니다. Salesforce는 둘을 똑같이 잽니다. 대부분의 레코드는 필드가 몇 개든 약 2KB로 셉니다. 예외도 있습니다. 캠페인은 더 크게 세고, 이메일 메시지는 실제 크기로 세고, 개인 계정은 계정이자 연락처이므로 약 4KB로 셉니다.

팁을 하나 드리겠습니다. 새 org에 들어갈 때마다 제가 가장 먼저 가는 곳 중 하나가 설정 → 저장 공간 사용량(Storage Usage)입니다. 첫 통화에서 고객에게 스크린샷을 부탁하기도 합니다. 그 화면은 거짓말을 하지 않습니다. 어떤 개체가 늘고 있는지, 어떤 개체가 이미 코끼리인지 알려 줍니다.

개인 계정: 고객이 사람일 때

계정과 연락처 모델은 회사와 거기서 일하는 사람들에게는 훌륭하게 작동합니다. 하지만 고객이 회사가 아니라면요? 사람이라면요?

그것이 개인 계정입니다. 개인을 위해 계정과 연락처를 하나의 레코드로 합친 것입니다. 연락처 필드가 함께 오고, 사용자 정의 연락처 필드는 자기만의 접미사 __pc를 달고 나타납니다. 그 아래에서는 둘 다이므로, 하나하나가 계정 스토리지와 연락처 스토리지 양쪽에 계산됩니다.

켜기 전에 경고 하나. 개인 계정은 한 번 활성화하면 비활성화할 수 없습니다. 1장의 가역성 테스트가 가장 순수한 형태로 나타난 것입니다. 언제 그만한 가치가 있는지에 대한 제 입장은 모듈 5에서 말씀드립니다.

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

무언가 새로운 것을 설계하기 전에, Salesforce가 비즈니스의 어느 부분을 이미 모델링해 두었는지.
어떤 개념이 Sales 모델에 들어가는지, Service 모델에 들어가는지, 둘 다인지. 둘이 계정과 연락처를 공유한다는 것을 알고서.
문서와 이미지가 어디에 있을지: Salesforce Files, 연결된 파일 시스템, 또는 링크만 남기고 플랫폼 밖.
Salesforce가 세는 방식, 즉 열이 아니라 레코드로 셀 때 데이터가 스토리지에서 얼마나 들지.
끌 수 없는 것을 켜기 전에, 고객이 회사인지 사람인지.

그런데 Salesforce에 필요한 것이 없다면요? 직접 만듭니다. 그것이 다음입니다.

더 알아보기

OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform(영어, 확인일 2026-10-12): “기회와 연결된 Product2 제품 목록의 구성원”이며, 가격 목록 항목이 필수다.
PricebookEntry (opens in a new tab), Object Reference(영어, 확인일 2026-10-12): “Pricebook2와 Product2 사이의 연결”이며, 항목은 표준 가격을 사용할 수 있다.
Case (opens in a new tab), Object Reference(영어, 확인일 2026-10-12): ParentId, “계층에서 상위 케이스의 ID. 레이블은 Parent Case”이며, 케이스에 대한 조회다.
Entitlement (opens in a new tab), Object Reference(영어, 확인일 2026-10-12): “계정이나 연락처가 받을 수 있는 고객 지원”이며, 자산, 제품, 서비스 계약에 기반할 수 있다.
Data and Storage Resources (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-12): 파일 스토리지와 데이터 스토리지에 무엇이 포함되는지.
Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-12): “대부분의 Salesforce 레코드는 약 2KB의 데이터 스토리지를 차지한다.” 개인 계정은 약 4KB.
Enable Person Accounts (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-10-12): “개인 계정은 활성화한 뒤에는 비활성화할 수 없다.”
Files Connect FAQ (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25).