올바른 개체를 골라라
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장인 Salesforce 데이터 아키텍처의 모듈 5/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 이 데이터는 어디에 있는가? · 다음: 필드도 아키텍처다
이 모듈이 답하는 질문: 이 비즈니스 개념은 어떤 종류의 Salesforce 개체가 되어야 하며, 라이선스는 무엇을 허용할까요?
Salesforce에서 가장 하기 쉬운 일 중 하나가 사용자 정의 개체를 만드는 것입니다. 바로 그래서 저는 우리가 그것을 너무 많이 만든다고 생각합니다.
요구사항 회의에서 누군가 “유통 대리점을 추적해야 해요”라고 말합니다. 새 사용자 정의 개체: 대리점. 끝. 다만 저는 아키텍트가 먼저 다른 질문을 하기를 바랍니다. 대리점이란 무엇인가? 회사입니다. Salesforce에는 이미 회사를 표현하는 꽤 좋은 방법이 있습니다. 계정이라고 부릅니다. 답이 늘 계정이라는 뜻은 아닙니다. 하지만 회사가 왜 계정이 아닌지 설명해야 한다면, “비즈니스가 그들을 대리점이라고 불러서”보다 나은 이유를 원합니다.
여기서 2장의 논리 모델이 플랫폼을 만나고, 제 출발점은 단순합니다. 비즈니스 개념이 표준 개체의 의도된 용도에 깔끔하게 맞는다면, 거기서 시작하라.
의미에서 시작하라
섹션 제목: “의미에서 시작하라 ”무언가가 개체가 될 자격이 있더라도, 자동으로 사용자 정의 개체가 될 자격이 있는 것은 아닙니다. 그것이 실제로 무엇을 나타내는지 물으십시오. 어떤 형태든 사업체나 조직? 계정에서 시작하십시오. 그 조직과 일하는 사람? 연락처. 고객이 소유하거나 산 것? 자산. 팔려고 하는 것? 이제 기회가 대화에 들어옵니다.
그래서 우리는 모듈 2에서 먼저 모선을 봤습니다. 그 모델들이 모든 비즈니스에 맞지는 않지만, 우리 것을 만드는 게 더 깔끔해 보인다는 이유로 무시해서는 안 됩니다. 새 사용자 정의 개체를 만들기 전에, Salesforce는 이 개념을 어떻게 모델링하는지, 그 모델을 중심으로 무엇이 만들어져 있는지, 그것을 대체하면 무엇을 포기하게 되는지 물으십시오.
깔끔한 적합 테스트
섹션 제목: “깔끔한 적합 테스트 ”제 테스트는 질문 하나입니다. 이 비즈니스 개념이 표준 개체의 의도된 용도에 깔끔하게 맞는가? 맞는다면 제 기울기는 표준 개체 쪽입니다.
대리점은 우리와 관계가 있는 회사이니 계정에 깔끔하게 맞습니다. 사용자들이 어떤 회사는 대리점, 어떤 회사는 공급업체, 어떤 회사는 리테일 파트너, 어떤 회사는 고객이라고 불러도 상관없습니다. 그것들은 비즈니스 역할이고, 물리 개체 네 개가 필요하지 않습니다. 비즈니스에서 이름이 다르다고 자동으로 데이터 구조가 달라지는 것은 아닙니다. 유형, 레코드 유형, 관계가 그 차이를 담을 수 있습니다.
테스트는 반대 방향으로도 작동합니다. 1장에서 질문 하나를 남겨 두었습니다. 고객사에 배송지가 여러 곳 있습니다. 각 배송지는 계정이어야 할까요, 사용자 정의 개체여야 할까요?
계정은 많은 것을 줍니다. 주소 필드가 있고, 이미 계정 주소를 기대하는 모든 것, 즉 보고서, 지도, 연동이 따라옵니다. 하지만 부담도 따라옵니다. 많은 필드, 공유, 계층, 소유권, 계정에 매달린 모든 것. 그리고 그 대부분은 별도 주소와 상관이 없습니다. 대체 주소 하나 때문에 쓰지도 않을 무거운 것들을 잔뜩 짊어지게 됩니다.
계정의 하위 개체인 사용자 정의 개체는 가벼울 수 있습니다. 주소 필드만 있고, 우리가 배송하는 장소이며, 제가 독립적으로 통제할 수 있는 자기 생명주기를 가집니다.
그러니 균형의 문제입니다. 떠안는 무게 대 얻는 가치. 필요한 것이 자기 생명주기를 가진 주소뿐이라면, 저는 거기서 사용자 정의로 갑니다.
케이스의 하위 이슈도 마찬가지입니다. 하위 이슈 하나하나가 정말 케이스라면, 즉 상담원이 처리하고 자기 상태와 서비스 수준을 가진다면, 모듈 2의 상위 케이스(Parent Case)로 중첩하십시오. 하지만 아무도 케이스로 처리하지 않는 체크리스트 항목일 뿐이라면, 완전한 케이스는 결코 쓰지 않을 것을 잔뜩 지고 다니고, 단순한 사용자 정의 하위 개체가 더 가벼울 수 있습니다. 사용자 정의가 더 깔끔해서가 아닙니다. 의미가 다르거나, 무게가 맞지 않기 때문입니다.
표준 개체는 짐을 지고 온다
섹션 제목: “표준 개체는 짐을 지고 온다 ”표준 개체를 고를 때는 필드 이상을 고르는 것입니다. Salesforce 제품들이 이미 이해하는 것을 고르는 것입니다. 보고, 자동화, 내장된 관계, 제품 기능, AppExchange 패키지, 그리고 Salesforce가 다음에 만들 무엇이든. 엄청난 가치가 있을 수 있습니다.
표준 개체에는 나름의 의견도 따라옵니다. 기존 동작, 관계, 보안 고려 사항, 때로는 라이선스 요건, 그리고 필요 없는 기능. 그래서 “언제나 표준 개체를 써라”는 제 규칙이 아닙니다. 저에게는 “언제나” 규칙이 없습니다. 기울기가 있을 뿐입니다. 의미가 깔끔하게 맞고 그 주변의 플랫폼 동작이 설계와 싸우지 않고 도울 때 표준 개체를 써라. 5년 동안 기회를 영업 기회가 아닌 무언가처럼 동작하게 만드는 데 쓴다면, 표준에 머물러서 얻은 게 없습니다. 반대 방향으로 잘못된 타협을 했을 뿐입니다.
자산은 좋은 예다
섹션 제목: “자산은 좋은 예다 ”자산은 사람들이 간과하는 표준 개체 중 하나입니다. 가장 간단히 말하면 고객이 가진 것입니다. 우리에게서 샀을 수도, 아닐 수도 있습니다. 고객 현장에 있는 경쟁사 제품도 저는 신경 씁니다. 그것을 정비하고 있거나, 교체하려 하거나, 설치 기반을 이해해야 하니까요. 자산을 먼저 보지 않고 Customer_Product__c를 만든다면 아키텍처 질문 하나를 건너뛴 것입니다. 자산이 자동으로 이기는 건 아니지만, 평가받을 자격은 있습니다.
개인 계정: 언제 사람이 계정인가?
섹션 제목: “개인 계정: 언제 사람이 계정인가? ”모듈 2에서 개인 계정을 만났습니다. 개인 고객을 위해 계정과 연락처를 한 레코드에 담은 것입니다. 이제 결정입니다.
제 입장은 이렇습니다. B2C라면 개인 계정 없이 하기 어렵다. 계정과 연락처에 기본으로 따라오는 것이 너무 많아서 비용과 부담을 감수할 가치가 있습니다. 그리고 비용이 있습니다. 비즈니스 계정의 약 두 배 스토리지, 끌 수 없는 스위치, 그리고 일부 외부 라이선스는 그것을 쓸 수 없습니다. Partner Community는 개인 계정과 함께 쓸 수 없습니다(Experience Cloud User Licenses (opens in a new tab)). 그러니 질문은 “데이터베이스에 사람이 있나?”가 아닙니다. 모든 org에는 사람이 있습니다. **“이 비즈니스에서 사람이 정말 계정인가?”**입니다. 연락처가 사람이라고 개인 계정이 되는 것은 아닙니다. 비즈니스 관계가 그것을 정합니다.
이제 모든 걸 복잡하게 만들겠다: 라이선스
섹션 제목: “이제 모든 걸 복잡하게 만들겠다: 라이선스 ”지금까지: 개념을 찾고, 가장 깔끔한 표준을 찾고, 의미가 맞지 않으면 사용자 정의로 간다. 이제 아키텍트의 후속 질문입니다. 누가 그것을 써야 하는가? 아름다운 모델을 설계해 놓고 나서, 데이터가 필요한 사람의 절반이 고른 개체에 대한 라이선스가 없다는 걸 발견할 수 있습니다. 라이선스는 데이터 모델의 일부입니다.
내부 라이선스 세 가지
섹션 제목: “내부 라이선스 세 가지 ”먼저 회사 내부 사람들부터 시작하겠습니다. 회사 안에는 모든 아키텍트가 훤히 알았으면 하는 라이선스 유형이 세 가지 있습니다. 각 사용자가 무엇을 보고 할 수 있는지, 그래서 데이터 모델이 무엇을 기대할 수 있는지를 그것이 정하기 때문입니다.
Sales Cloud(현재 Agentforce Sales). 이 사용자들은 완전한 Salesforce 사용자 라이선스를 가집니다. 표준 CRM 개체, 그리고 모든 표준 또는 사용자 정의 앱. 계정과 연락처 위에 리드, 기회, 예측이 있고, 케이스까지 있습니다. 영업 담당자가 통화 전에 고객의 미결 케이스를 볼 수 있습니다. 캠페인을 만들고 운영하려면 하나가 더 필요합니다. Marketing User 기능 라이선스입니다.
Service Cloud(현재 Agentforce Service). 같은 Salesforce 사용자 라이선스를 서비스용으로 설정한 것입니다. 케이스가 중심이고, Service Console에서 처리합니다. Service Cloud User 기능 라이선스가 서비스용 Salesforce 콘솔을 열어 줍니다. 자격 관리와 마일스톤을 통한 **서비스 수준 계약(SLA)**이 있는 곳이고, 대부분의 에디션에서 추가 구매하는 Knowledge가 들어오는 곳입니다.
Platform(Salesforce Platform). CRM이 아니라 사용자 정의 앱이 필요한 사람들을 위한 것입니다. 계정, 연락처, 보고서, 대시보드, 문서, 그리고 org의 모든 사용자 정의 앱을 받습니다. 받지 못하는 것은 예측, 리드, 캠페인, 기회입니다. 더 저렴하고, 바로 그래서 대형 사용자 정의 앱이 그렇게 많이 그 위에서 돌아가며, 바로 그래서 데이터 모델의 발목을 잡을 수 있습니다.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| 사용자 라이선스 | Salesforce | Salesforce | Salesforce Platform |
| 용도 | 판매 | 고객 지원 | 사용자 정의 앱 |
| 계정, 연락처 | 예 | 예 | 예 |
| 리드, 기회, 예측 | 예 | 예 | 아니요 |
| 케이스 | 예, 고객의 케이스를 보기 위해 | 중심, Service Console에서 | 아니요 |
| 서비스 수준 계약 | 아니요 | 예, 자격과 마일스톤 | 아니요 |
| 사용자 정의 개체와 앱 | 예 | 예 | 예 |
아키텍트처럼 표를 읽으십시오. 큰 사용자 집단이 Platform에 있다면, 그들의 업무를 기회에 두는 설계는 시작도 전에 깨져 있습니다. 경영진에게 SLA 수치가 필요하다면, 그들이 가진 라이선스가 그것을 볼 수 있는지를 정합니다. 이 세 유형이 동작을 좌우합니다.
라이선스가 개체를 정할 때
섹션 제목: “라이선스가 개체를 정할 때 ”제가 가장 자주 부딪힌 희생양은 기회입니다. 표에서 봤듯이 Platform 사용자는 그것을 받지 못하고(Standard User Licenses (opens in a new tab)), Customer Community 사용자도 그것으로 일할 수 없습니다. 그래서 요구사항이 기회처럼 보이고, 누군가 “기회를 씁시다”라고 하면, 저는 누가 접근해야 하는지 묻습니다. 큰 인원이 Platform이나 Customer Community 라이선스라면, 라이선스는 더 이상 조달 세부 사항이 아닙니다. 아키텍처 제약이고, 보통 설계를 사용자 정의 개체 쪽으로 밉니다.
위쪽으로도 작용합니다. 수업에서 묻습니다. CEO가 멋진 대시보드를 원합니다. Sales 라이선스일까요, Service일까요? Sales 사용자는 영업 개체와 케이스까지 볼 수 있으니, 영업 대시보드와 미결 케이스 수라면 Sales로 충분합니다. 하지만 경영진이 SLA KPI(케이스가 서비스 수준을 위반하기까지 얼마나 남았는지)를 원하는 순간, 그 데이터는 자격(entitlement)과 마일스톤에 있고, 자격 관리에는 예전 Service Cloud인 Agentforce Service가 필요합니다(Supported Editions for Service Features (opens in a new tab)). 이제 경영진의 라이선스를 업그레이드하게 됩니다. 비즈니스 요구사항을 듣고, 그것이 필요로 하는 데이터 아래에 어떤 라이선스가 있는지 아십시오.
경기장
섹션 제목: “경기장 ”저는 라이선스를 경기장 좌석으로 생각합니다. 모두가 같은 경기를 봅니다. 가운데 비싼 좌석을 사면 양 팀을 가까이서 볼 수 있습니다. 구석 외야석 꼭대기에 있으면 좌석에 쿠션도 없고 쌍안경으로 봅니다.
그것이 외부 라이선스입니다. 회사 밖의 사람들, 즉 Experience Cloud 사이트에 로그인하는 고객과 파트너를 위한 것입니다. 알아 두었으면 하는 것이 세 가지입니다.
Customer Community: 외야석. 케이스와 지식이 필요한 대규모 외부 사용자를 위해 만들어졌습니다. 자기 지원 케이스를 확인하는 고객 같은 경우입니다. 좌석은 대략 절반 가격이고 엄청난 수의 사용자에게 줄 수 있습니다. 그 위에서는 무엇을 잃을까요? 보고서, 대시보드, 그리고 상위 등급이 받는 역할 기반 공유인 공유 테이블입니다. 개인 계정과는 함께 쓸 수 있습니다.
Customer Community Plus: 대략 중간쯤. Salesforce는 그것을 보고서, 대시보드, 표준 공유가 필요한 외부 사용자를 위한 라이선스로 설명합니다. 다른 사람들의 접근을 관리하거나, 자기 수치를 봐야 하는 고객 같은 경우입니다.
Partner Community: 더 가까이, 영업 데이터에 접근하는 기업 간(B2B) 용도입니다. 파트너는 리드와 기회로 일합니다. 딜을 등록하고, 우리와 함께 캠페인을 운영합니다. 영업 개체에 닿는 외부 좌석이 이것입니다. 함정이 하나 있습니다. 개인 계정과 함께 쓸 수 없습니다(Experience Cloud User Licenses (opens in a new tab)).
실수는 모두가 비싼 표를 가진 것처럼 설계했다가, 구현 단계에서 대부분의 사용자가 그들의 데이터를 둔 구역에 들어갈 수 없다는 걸 발견하는 것입니다. 그러면 선택지가 셋입니다. 다른 좌석을 사거나, 경험을 옮기거나, 모델을 다시 설계하거나. 셋 다 아키텍처입니다.
비용을 내는 방식이 설계를 바꾼다
섹션 제목: “비용을 내는 방식이 설계를 바꾼다 ”사람들이 잊는 질문이 하나 더 있습니다. 이 사용자들은 어떻게 로그인할까? 외부 라이선스에는 두 가지 형태가 있습니다. 회원 기반: 사용자당 비용을 내며, 매일 로그인하는 파트너 500명에게 맞습니다. 로그인 기반: 월별 로그인 횟수를 사며, 1년에 몇 번 로그인하는 고객 500만 명에게 맞습니다. 같은 날 여러 번 로그인해도 로그인 한 번으로 셉니다(Experience Cloud User Licenses (opens in a new tab)).
그래서 누군가 “고객 포털을 만들고 있어요”라고 하면 제 다음 질문은 어떤 템플릿이냐가 아닙니다. 고객은 누구이고, 몇 명이고, 얼마나 자주 오고, 어떤 데이터가 필요하고, 그것으로 무엇을 해도 되는가?
라이선스가 모델을 형성할 때
섹션 제목: “라이선스가 모델을 형성할 때 ”때로 라이선스는 개체를 고르는 데서 그치지 않고 모델 전체를 휘게 합니다. 일부 플랫폼 라이선스는 사용자를 사용자 정의 개체 최대 10개로 된 사용자 정의 앱 하나로 제한합니다(예를 들어 Lightning Platform – One App, Standard User Licenses (opens in a new tab)).
초기의 한 프로젝트에서, 대형 전문 서비스·건설 회사를 위해 전 직원용 LinkedIn 같은 것을 만들어야 했습니다. 모두의 직무, 기술, 자격증, 언어, 프로젝트를 담아서, 특정 국가에서 자격증을 가진 교량 기술자를 찾을 수 있도록요. 제한이 없었다면 사용자-직무, 사용자-기술, 사용자-자격증, 사용자-언어, 사용자-프로젝트 개체에 자격증과 프로젝트 참조 목록까지 만들었을 겁니다. 개체 10개짜리 라이선스에서, 그것도 다 쓰지 말라는 말을 들은 상태로는 불가능했습니다. 그래서 노래 제목 맞히기가 되었습니다. 몇 개의 개체로 이걸 만들 수 있을까? 답은 두 개였습니다. 목록 종류(직무, 기술, 자격증, 언어, 프로젝트)마다 레코드 유형을 둔 참조 개체 하나, 그리고 그것을 가리키며 대응하는 레코드 유형을 가진 사용자 속성 개체 하나.
최적의 모델은 아니었습니다. 보고하기 괴로웠고, 저는 더 깔끔한 쪽을 원했습니다. 하지만 라이선스가 허용한 것이 그것이었습니다. 저는 이런 것을 맥가이버 칼 개체라고 부릅니다. 이 패턴을 뒷주머니에 넣어 두었다가, 한계가 여지를 남기지 않을 때 비상용 유리를 깨고 레코드 유형으로 분리하십시오. 다만 무엇과 맞바꾸는지 아십시오. 레코드 유형마다 권한이 달라야 하면 결국 개체를 나눠야 할 수도 있습니다.
사람만 사용자인 시대는 지났다
섹션 제목: “사람만 사용자인 시대는 지났다 ”중요해진 라이선스 질문이 하나 더 있습니다. 사람이 아닌 것들은요? 연동에도 정체성이 있습니다. 에이전트에도 정체성이 있습니다. Salesforce에는 이제 시스템 간 연동을 위한 Salesforce Integration 라이선스가 있습니다. API 전용이고 사람용이 아니며, Enterprise, Unlimited, Performance Edition org마다 다섯 개가 포함됩니다(Standard User Licenses (opens in a new tab)). 그러니 어떤 사용자에게 접근이 필요한지만 묻지 마십시오. 어떤 정체성에게 필요한지 물으십시오. 사람, 고객, 파트너, 연동, 에이전트. 그리고 각각이 무엇을 보고 무엇을 해야 하는지.
시험 너머: AI가 바꾸는 것. 에이전트가 데이터의 또 다른 소비자이자 생산자가 되면서, 개체 선택과 라이선스는 사람이 보는 화면만의 문제가 아닙니다. 에이전트가 어떤 정체성으로 실행되는지, 그 정체성이 무엇에 닿을 수 있는지, 그리고 모델이 에이전트에게 필요한 데이터를 그것이 쓸 수 없는 개체나 권한 뒤에 두고 있지는 않은지 아십시오.
Steve Trucking: 쉬운 것 하나와 어려운 것 하나
섹션 제목: “Steve Trucking: 쉬운 것 하나와 어려운 것 하나 ”Steve Trucking은 리테일 파트너와 일합니다. 리테일 파트너란 무엇일까요? 사업체입니다. 쉽습니다. 계정. 누군가 “파트너”라는 단어를 썼다고 Retail_Partner__c를 만들지 않습니다.
이제 냉장고를 받는 사람, 수령인입니다. 연락처? 개인 계정? 다른 무엇? 1년에 새 수령인이 100만 명이고, 그들은 우리 고객이 아니라 리테일 파트너들의 고객입니다. 관계, 접근, 규모를 이해하기 전에 개체로 뛰어들고 싶지 않은 바로 그런 질문입니다. 파트 1 체크포인트에서 정하겠습니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 비즈니스 개념이 표준 개체의 의도된 용도에 깔끔하게 맞는지, 아니면 의미나 무게가 다른지.
- 비즈니스 레이블이 다른 것이 다른 엔터티인지, 같은 엔터티의 다른 역할일 뿐인지.
- 데이터가 필요한 모든 사람, 외부 사용자, 연동, 에이전트가 계획한 라이선스로 고른 개체에 닿을 수 있는지.
- 인원과 로그인 패턴(회원 기반 또는 로그인 기반)이 라이선스와 모델을 어떻게 형성하는지.
- 라이선스 한계가 최적에 못 미치는 모델을 정당화하는 때, 그리고 그 맞바꿈이 보고와 권한에서 무엇을 치르게 하는지.
요점은 표준 개체는 좋고 사용자 정의 개체는 나쁘다는 것이 아닙니다. 선택에는 결과가 따르고, 때로는 명사가 아니라 그것을 써야 하는 사람들, 그리고 기계들이 그 선택을 정한다는 것입니다.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce 도움말, Standard User Licenses (opens in a new tab)(영어), 확인일 2026-10-02, 재확인일 2026-10-12: Platform 사용자에게는 예측, 리드, 캠페인, 기회 권한이 없다. 사용자 정의 개체 최대 10개짜리 사용자 정의 앱 하나. Enterprise Edition org마다 Salesforce Integration 라이선스 다섯 개.
- Salesforce 도움말, Experience Cloud User Licenses (opens in a new tab)(영어), 확인일 2026-10-02, 재확인일 2026-10-12: Partner Community는 개인 계정과 함께 쓸 수 없다. Customer Community Plus는 보고서, 대시보드, 표준 공유용. 같은 날 여러 번 로그인해도 한 번으로 센다.
- Salesforce 도움말, Supported Editions for Service Features (opens in a new tab)(영어), 확인일 2026-10-02, 재확인일 2026-10-12: 서비스 수준 계약(자격 관리)은 Agentforce Service에 포함. Knowledge는 대부분의 에디션에서 추가 비용.
- Salesforce 도움말, Available Feature Licenses (opens in a new tab)(영어), 확인일 2026-10-12: Service Cloud User는 “Access the Salesforce Console for Service”(서비스용 Salesforce 콘솔 접근). Marketing User는 캠페인 생성과 관리용.