모든 구조는 약속이다
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 과정 3장, 파트 1: 데이터 아키텍트 되기. 이전: 의미를 위한 데이터 모델링.
모든 수업에서 하는 질문이 있습니다. 누군가 “Salesforce로 일합니다”라고 말한다면, 제품 개체의 API 이름은 무엇일까요?
Product2입니다. 제 첫 번째 리트머스 시험입니다. 어느 시점에 Salesforce는 제품 개체를 만들었다가, 그것이 잘 작동하지 않는다는 걸 깨닫고 뒤에 남겨 둬야 했습니다. 그냥 없앨 수는 없었기에 Product2를 추가했습니다. Salesforce조차 자기의 옛 구조와 함께 삽니다.
Salesforce는 성장할 여지도 스스로에게 남겼습니다. 표준 개체에는 접두사도 접미사도 없고, org를 커스터마이징하는 우리는 결코 그 공간을 차지할 수 없습니다. 그래서 Salesforce는 우리가 만드는 무엇과도 충돌하지 않고 계속 개체를 추가할 수 있습니다.
여기에 교훈이 있습니다. 개체를 만드는 데는 10분이 걸립니다. 그것과 함께 사는 데는 몇 년이 걸립니다. 추가하는 모든 개체와 모든 필드는 약속입니다. 스토리지를 차지합니다. 한계를 떠안습니다. 설계했든 안 했든 공유 모델을 갖게 됩니다. 그것을 건드리는 모든 사람에게 라이선스가 필요합니다. 그리고 이제 AI도 그것을 읽으므로, 이름을 어떻게 붙이고 어떻게 설명하느냐가 에이전트가 당신의 데이터를 어떻게 이해하는지를 정합니다. 추가하기는 쉽습니다. 빼기는 어렵습니다.
이 장은 Salesforce의 구성 요소를 결정으로 바꿉니다.
AI로 생성한 이미지입니다.
구조 한눈에 보기
섹션 제목: “구조 한눈에 보기 ”Salesforce는 데이터를 담을 곳을 여섯 가지 줍니다. 저는 이것들을 슬라이드 한 장에 올립니다. 첫 번째 일은 이것들이 모두 존재한다는 걸 아는 것이니까요.
| 구조 | 용도 | 함정 |
|---|---|---|
| 표준 개체 | Salesforce 자체 모델: 계정, 연락처, 기회, 케이스, 자산 등 | 의도된 용도로 쓰지 않으면 맞서 싸운다 |
| 사용자 정의 개체 | 당신의 비즈니스 데이터 | 만들기는 쉽고, 퇴역시키기는 어렵다 |
| 외부 개체 | 다른 시스템에 있는 데이터를 Salesforce에서 보여 줌 | 건드릴 때마다 콜아웃이다 |
| 빅 개체 | 보관해야 하지만 거의 열지 않는 막대한 볼륨 | 표준 UI나 보고가 없고, 인덱스로 조회한다 |
| 파일 | 문서, 사진 및 기타 콘텐츠 | 파일 스토리지가 빠르게 늘어난다 |
| 첨부 파일 | 파일을 저장하던 예전 방식 | 레거시: 파일을 쓸 것 |
하지만 하나를 고르는 것은 일부일 뿐입니다. 구조보다 먼저, 데이터가 애초에 어디에 있어야 하는가라는 질문이 옵니다. 코어 내에 둘지, 이미 있는 곳에서 참조할지, 보관할지.
이 장의 길
섹션 제목: “이 장의 길 ”이 장은 커서 열 부분으로 나뉩니다. 각 부분은 독립적으로 읽을 수 있습니다. 2장에서는 모델이 어떠해야 하는지 정했고, 여기서는 그것이 Salesforce에서 어떻게 살아야 하는지 정합니다.
- Salesforce 데이터 플랫폼: 데이터베이스 그 이상. Salesforce를 다르게 만드는 것, 그리고 플랫폼에 형태가 있는 이유.
- 모선을 보라: 표준 데이터 모델. Salesforce가 이미 만들어 둔 Sales 모델과 Service 모델, 파일, 스토리지, 개인 계정.
- 직접 만들기: 사용자 정의 개체. 새 사용자 정의 개체 화면이 정하는 것, 만들지 않았는데 있는 필드, 그리고 표준, 사용자 정의, 관리 패키지 등 어떤 API 이름이든 읽는 법.
- 이 데이터는 어디에 있는가? 코어 내, 참조, 보관: 어떤 개체든 만들기 전에 정한다.
- 올바른 개체를 골라라. 깔끔한 적합 테스트, 표준 개체가 지고 오는 짐, 개인 계정, 그리고 사람들이 무엇을 쓸 수 있는지 정하는 라이선스.
- 필드도 아키텍처다. 필드 유형별로, 사람들을 놀라게 하는 동작들, 그리고 모든 필드에 설명이 필요한 이유.
- 관계에는 결과가 따른다. 조회냐 마스터-세부 사항이냐, 세 단계 깊이와 두 상위 너비, 논리적 연결 개체와 Salesforce 연결 개체(Salesforce Junction Object), 그리고 발목을 잡는 한계.
- 소유권과 생명주기. 누가 레코드를 소유하는지, 소유권이 접근이 되는 공유 테이블, 그리고 레코드의 생애 동안 무슨 일이 일어나는지.
- 데이터를 일관되게 유지하기. 일관성 사다리: 모든 층에는 비용이 있고, 새 규칙을 만족시키려고 과거를 “고치지” 않는다.
- Salesforce 물리 모델을 설계하라. 논리 모델에서 Salesforce까지 한 단계씩 쌓아 올리며, 추론과 함께 보는 Steve Trucking의 한 단면.
다 읽었다면 장 학습 가이드로 스스로 점검하십시오. 시험 대비 체크리스트, 시험 너머의 습관, 알아야 할 용어, 그리고 몇 가지 질문이 있습니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- Salesforce가 이미 무엇을 모델링해 두었는지, 무언가를 발명하기 전에: 모선을 보라.
- 각 종류의 데이터가 어디에 있을지, 코어 내, 참조, 보관 중에서, 구조를 고르기 전에.
- 어떤 구조가 그것을 담을지, 각각이 무엇을 포기하는지 알고.
- 개체들이 어떻게 관계를 맺고 누가 레코드를 소유하는지, 그리고 그것이 접근과 규모에 무엇을 뜻하는지.
- 모델이 어떤 라이선스에 의존하는지, 개체를 설계한 뒤가 아니라 전에 확인해서.
- 데이터가 어떻게 일관되게 유지되는지, 그리고 각 일관성 층의 비용.
시험 너머: AI 지원 구축은 몇 분 만에 개체와 필드를 만들 수 있습니다. 추가가 거의 공짜가 되면 “모든 구조는 약속이다”는 덜 중요해지는 게 아니라 더 중요해집니다. 각 모듈은 그 결정에 대해 AI가 바꾸는 것으로 끝납니다.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce 도움말(영어)
- Standard User Licenses (opens in a new tab), Salesforce 도움말(영어)
다음: 기업 데이터 이해하기