이 데이터는 어디에 있는가?

🌐 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 데이터 아키텍처의 모듈 4/10. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 직접 만들기: 사용자 정의 개체 · 다음: 올바른 개체를 골라라

이 모듈이 답하는 질문: 개체를 만들기 전에, 이 데이터는 실제로 어디에 있어야 할까요? Salesforce의 코어 내에 둘지, 이미 있는 곳에서 참조할지, 보관할지.

질문 하나 드리겠습니다. 새 요구사항이 책상에 떨어집니다. 가장 먼저 무엇을 하십니까?

우리 대부분과 같다면 설정을 열고 사용자 정의 개체를 만듭니다. 이해합니다. 10분이면 탭, 페이지 레이아웃, 목록 보기가 생깁니다. 그리고 제가 모든 수업에서 하는 말이 있습니다. 그 새 개체를 만드는 순간, 의도했든 아니든 당신은 이미 아키텍트처럼 생각하고 있습니다. 만드는 모든 개체는 약속이기 때문입니다. 스토리지를 차지합니다. 한계를 떠안습니다. 설계했든 안 했든 공유 모델을 갖게 됩니다. 그것을 건드리는 모든 사람에게 라이선스가 필요합니다. 그리고 사람과 연동이 그것에 의존하게 되면, 그것을 없애기란 행운을 빌어야 할 일입니다.

그러니 첫 아키텍처 결정은 어떤 개체냐가 아닙니다. *이 데이터는 어디에 있어야 하는가?*입니다. 그걸 제대로 정하면 개체 유형은 거의 저절로 정해집니다.

코어 내와 오프코어

먼저, 제가 자주 쓸 단어 하나가 있습니다. 코어입니다. 코어는 당신의 org가 돌아가는 Salesforce 플랫폼입니다. 모듈 1에서 본 메타데이터 기반의 멀티테넌트 플랫폼이고, 모듈 2의 Sales와 Service 개체가 있는 곳이며, 모듈 3에서 만드는 모든 사용자 정의 개체가 있는 곳입니다. 데이터가 코어 내에 있다고 말할 때, 저는 그 데이터가 당신의 org, 그 개체 안에 저장되어 있다는 뜻으로 말합니다.

모든 데이터가 거기에 있는 것은 아닙니다. Data 360은 자기 데이터를 org의 개체 밖, 자체 저장소에 둡니다(코어 인접(near-core)입니다. 관리는 코어 내에서 하고, 데이터는 코어 밖에서 호스팅됩니다. 자세한 내용은 4장에서). 그리고 회사가 운영하는 것 중 Salesforce가 전혀 아닌 모든 것이 있습니다. ERP, 웨어하우스, 주문 시스템, 파트너의 플랫폼. 그 모든 것이 오프코어입니다. Salesforce는 그것에 닿고, 보여 주고, 쓸 수 있지만, 당신의 org가 그것을 저장하지는 않습니다.

코어 내에는 실제로 레코드를 담는 개체가 두 종류 있습니다. 표준과 사용자 정의(__c)의 sObject, 그리고 빅 개체(__b)입니다. 오프코어에서는 외부 개체(__x)와 그 밖의 연동 도구로 데이터에 닿습니다. 모듈 3의 접미사들을 기억해 두십시오. 이름만 보고도 데이터가 어디에 있는지 알려 줍니다.

저는 이것을 사무실처럼 생각합니다. 어떤 것은 매일 쓰는 책상 위에 둡니다. 어떤 것은 다른 사람의 서류함에서 찾아보기만 하면 됩니다. 그리고 어떤 것은 뒷마당 창고의 상자에 넣습니다. 그래서 답이 세 가지입니다.

1. 코어 내: 당신의 책상 위에 있다

데이터가 매일 Salesforce에서 생성되고, 변경되고, 쓰입니다. 계정, 케이스, 기회, 작업 주문. sObject에 두는 것은 사무실 앞쪽에 두는 것과 같습니다. 표준 개체와 사용자 정의 개체가 바로 이것을 위한 것이고, 모든 것을 얻습니다. 페이지 레이아웃, 공유, 자동화, 보고, 검색, 그리고 이제는 데이터 모델 위에 세워진 AI 기능까지.

하지만 책상이 공짜는 아닙니다. 코어 내 데이터는 스토리지 비용이 들고, Salesforce가 세는 방식대로, 즉 열 단위가 아니라 레코드 단위로 계산됩니다. 문서는 그와 별도로 파일 스토리지에 계산됩니다. 둘 다 모듈 2에서 다뤘습니다. 대량의 사진과 스캔은 오프코어에 두고 Salesforce에는 링크만 남기는 편이 맞는 경우가 많습니다.

2. 참조: 다른 사람의 서류함에 있다

데이터가 다른 시스템(ERP, 데이터 웨어하우스, 주문 플랫폼)에 속하고, 그 시스템이 진실의 원천으로 남습니다. 사용자는 Salesforce에서 그것을 봐야 하고, 어쩌면 레코드와 연결해야 하지만, Salesforce가 자기 사본을 가질 필요는 없습니다. 이것을 가상 데이터라고 부르는 것도 듣게 될 겁니다. 저장되는 일 없이 Salesforce에 가상으로 나타나기 때문입니다.

그것이 Salesforce Connect를 통한 외부 개체입니다. 저는 오리처럼 생기고 오리처럼 걷지만 오리는 아니라고 말하곤 합니다. sObject처럼 나타납니다. 페이지 레이아웃과 관련 목록에 넣을 수 있고, 외부 조회와 간접 조회로 자기 레코드와 연결할 수 있습니다. 하지만 데이터는 코어 내에 저장되지 않습니다. 건드릴 때마다 콜아웃이 일어납니다. 레코드를 열고, 관련 목록을 불러오고, 보고서를 실행하면 Salesforce가 다른 시스템에 가서 묻습니다. 그만큼 지연이 생기고, 당신의 페이지는 그 뒤의 시스템만큼만 가용합니다.

사람들이 라이선스 비용에 반발하니, 제가 수업에서 하는 대로 계산해 보십시오. Connect는 엔드포인트 단위로 라이선스가 매겨지고, 엔드포인트 하나로 여러 개체를 가져올 수 있습니다. 이제 대안을 만들고 유지하는 비용을 물어보십시오. 사용자 정의 컴포넌트, 그 뒤의 콜아웃 코드, 고장 나면 대기하는 개발자. 라이선스가 더 싼 경우가 많고, 관리자가 코드 한 줄 없이 구성할 수 있습니다. 약점은 사용자가 하루 종일 편집하거나 보고서를 많이 돌리는 데이터입니다.

문서도 참조할 수 있습니다. 계약서가 이미 SharePoint Online, OneDrive, Google Drive, Box에 있다면, Files Connect로 사용자가 복사하지 않고 Salesforce에서 접근할 수 있습니다.

데이터를 참조하는 방법이 Salesforce Connect만은 아닙니다. 때로는 사용자 정의 로직입니다. 다른 시스템을 실시간으로 호출해 그 데이터를 페이지에 보여 주고, 사본은 남기지 않는 코드입니다. 완전한 통제권을 얻는 대신, 콜아웃과 오류와 유지보수에 대한 책임도 전부 집니다. 그리고 Data 360도 복사 없이 연합할 수 있습니다. 그 선택은 자기 장이 있습니다(가상화, 연합, 제로 카피). 여기서 요점은 결정 자체입니다. 복사하지 말고 참조하라.

3. 보관: 뒷마당 창고로 간다

이력, 감사 추적, 오래된 트랜잭션. 때로는 수년 동안 보관해야 하지만 거의 아무도 열지 않습니다. 그리고 팀들이 미루는 게 이것입니다. 수업에서 레코드 5,000만 건짜리 개체가 있다며 왜 보관해야 하느냐고 물으면, 저는 되묻습니다. 오늘 보관하지 않는다면, 언젠가 보관하긴 할 건가요? 오늘 5,000만 건이면 1억, 1억 5,000만, 2억 건으로 가고 있습니다.

창고는 두 개입니다. 하나는 코어 내의 빅 개체입니다. 데이터를 차고에 두는 것이라고 생각하십시오. 엄청난 수의 레코드를 저장할 수 있지만, 페이지 레이아웃에 넣을 수 없고, 표준 UI나 보고가 없으며, 빅 개체의 인덱스로 정확히 일치하거나 범위로 조회합니다(Big Objects Best Practices (opens in a new tab)). 보안은 개체와 필드 권한뿐이고 레코드 공유는 없으며, 자동화도 돌지 않습니다. 저는 Salesforce Connect는 수십 번 썼지만 빅 개체는 한두 번밖에 안 썼습니다. 작동하지만 다루기 불편하고, 데이터를 꺼내려고 우회책을 꽤 많이 써 왔습니다. 그래서 제 조언은 제안하기 전에 프로토타입을 만들어 보라는 것이고, 고르기 전에 사람들이 데이터를 어떻게 찾을지 계획하라는 것입니다.

다른 창고는 오프코어입니다. 다른 곳에 있는 웨어하우스나 데이터베이스입니다(규모를 위한 설계). 그쪽이 더 나은 창고인 경우가 많고, 눈에서 사라질 필요도 없습니다. 오프코어에 보관한 데이터도 Tableau 같은 도구로 보고서에 나타날 수 있고, 누군가 과거를 돌아봐야 할 때 Salesforce Connect나 다른 가상화 방법으로 Salesforce에서 여전히 닿을 수 있습니다.

처음부터 이걸 제대로 한 프로젝트 이야기를 해 드리겠습니다. 한 리테일 고객이 매장을 1,200곳 넘게 가지고 있었습니다. 그들은 “매장당 하루 예약이 100건밖에 안 돼요. 별거 아니에요”라고 했습니다. 그래서 계산해 봤습니다. 하루 100건, 주 6일(1년에 약 305일), 매장 1,200곳이면 1년에 예약이 3,600만 건이 넘습니다. 그러다 방문마다 예약이 두 건, 하나는 앞쪽 카운터, 하나는 매장 뒤쪽용으로 생긴다고 했습니다. 1년에 7,300만 건이 넘는 레코드입니다. 그러고는 5년치 이력을 원했습니다. 성장을 빼고도 3억 6,000만 건이 넘는 레코드입니다. 아직 오픈도 안 했는데, 저는 기차가 대용량 데이터 역으로 곧장 달려가는 게 보였습니다. 그래서 예약을 하나도 모으기 전에 보관을 만들었습니다. 오래된 예약은 빅 개체로 옮기고, 검색 화면은 현재 예약과 그 바로 아래에 보관된 예약을 보여 줬습니다. 몇 년이 지난 지금도 잘 돌아갑니다.

Click to enlarge

적용하기: Steve Trucking

Steve Trucking은 우리의 진행 시나리오입니다. 대형 유통업체의 물류 센터에서 가전과 전자제품을 받아 고객의 집에 배송하고 설치하는 가족 경영 라스트마일 배송 회사입니다. 데이터 네 종류, 답 세 가지:

데이터	있는 곳	이유
오늘의 배송, 배송팀, 약속	코어 내	배차 담당자와 배송팀이 하루 종일 그 안에서 일한다
유통업체의 주문 상세	참조(또는 코어 내의 얇은 사본)	유통업체의 시스템이 진실의 원천이다
3년 전 배송 이력	보관	클레임과 추세를 위해 보관하며, 거의 아무도 열지 않는다
배송 사진	오프코어, 링크	하루 수천 장. Salesforce 밖에 저장하고 배송에 링크를 둔다

같은 내용을 데이터 모델로 보면 이렇습니다. 배송(Delivery)은 코어 내에 있고, 사람들이 하루 종일 그 안에서 일합니다. 3년이 지나면 빅 개체인 배송 이력(Delivery History)으로 옮겨 갑니다. 여전히 코어 내지만 창고로 나간 것입니다. 파트너의 주문은 외부 개체 __x로 나타납니다. Salesforce가 배송을 그것과 연결하지만, 데이터는 유통업체의 시스템에 남습니다. 그리고 사진은 완전히 오프코어에 있고, 배송에서 링크로 연결됩니다. 모델 하나, 거처 셋.

Click to enlarge

실제 org에는 세 가지가 모두 있습니다. 곤란해지는 org는 개체를 만드는 것이 기본 버튼이었기 때문에 모든 것을 코어 내에 둔 곳입니다.

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

• 각 종류의 데이터가 있을 곳, 어떤 개체를 설계하기 전에: 코어 내, 참조, 보관.
• 진실의 원천. 다른 시스템이 데이터를 소유한다면 Salesforce가 조용히 두 번째 마스터가 되어서는 안 된다.
• 오프코어에 있는 모든 것의 접근 경로. 참조 데이터에는 가용한 원천과 받아들일 만한 지연이, 보관 데이터에는 사람들이 그것을 찾을 방법이 필요하다.
• 스토리지 증가. 저장 공간 경고가 올 때가 아니라 지금 계산하라(하루 레코드 수 × 성장 × 보존 기간).

시험 너머: AI는 “코어 내”의 판돈을 올린다. AI 기능과 에이전트는 플랫폼이 이해하는 데이터, 즉 이름과 설명이 잘 붙은 표준·사용자 정의 개체의 데이터에서 가장 잘 작동합니다. 그것이 더 많은 것을 코어 내에 두라는 끌림이 됩니다. 잘못된 데이터라면 그 끌림에 저항하십시오. ERP 데이터의 오래된 사본에 근거한 에이전트는 자신 있게 틀린 답을 줍니다. 살아 있는 원천을 참조하거나, 작고 잘 설명된 일부만 코어 내에 두는 것이 더 나은 수인 경우가 많습니다. AI가 데이터를 어디서 읽는지가 이제 데이터를 어디에 둘지 정하는 일의 일부입니다.

더 알아보기

• Big Objects Best Practices (opens in a new tab), Salesforce Developers(영어, 확인일 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25)
• 이 과정에서: 가상화, 연합, 제로 카피, 규모를 위한 설계