기업 데이터의 종류

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)

A kitchen where each kind of food is kept its own way: bins and jars on the pantry shelves, fresh food on the counter, the fridge and freezer, a recipe book. — AI로 생성한 이미지

Data Architect 과정 4장인 기업 데이터 이해하기의 모듈 2/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: Salesforce는 여러 시스템 중 하나다 · 다음: Salesforce를 둘러싼 시스템

이 모듈이 답하는 질문: 기업은 어떤 종류의 데이터를 가지며, 왜 그것들은 서로 다른 곳에 속할까요?

고객 레코드 하나. 국가 목록. 주문 하나. 필드 정의. 5년치 매출 합계. 배송 사진 400만 장. 모두 데이터이지만, 아키텍처 관점에서는 같은 것이 아닙니다. 변하는 방식, 자라는 방식, 쓰이는 방식이 다르고 소유하는 사람도 다르며, 자동으로 같은 곳에 있어서는 안 됩니다. 그래서 누군가 “이 데이터가 Salesforce에 있어야 해요”라고 하면 제 다음 질문은 **어떤 종류의 데이터인가?**입니다. 그 답이 무엇을 할지 알려 주기 시작합니다.

개체가 아니라 종류에서 시작하라

Salesforce 사람으로서 우리는 요구사항을 거의 즉시 구조로 옮깁니다. 고객은 계정, 사진은 파일, 상태는 선택 목록. 결국엔 유용합니다. 기업 수준에서 저는 먼저 어떤 종류의 정보를 다루는지 알고 싶습니다. 분류하는 방법은 많고(DAMA 지식 체계가 표준 참고서입니다), 저는 여섯 가지가 유용하다고 봅니다. 마스터, 참조, 트랜잭션, 메타데이터, 분석, 비정형. 범주가 아키텍처는 아닙니다. 더 나은 질문을 하는 방법입니다.

마스터 데이터: 비즈니스가 아는 것들

마스터 데이터는 비즈니스가 그것을 중심으로 돌아가는 지속적인 것들을 기술합니다. 고객, 제품, 가격, 직원, 공급업체, 장소, 자산. Salesforce 영업 org라면 계정과 연락처, 제품과 가격 목록입니다. Steve Trucking에서 리테일 파트너는 마스터 데이터입니다. Keystone은 이벤트가 아니라 Steve Trucking과 지속적인 관계를 맺은 조직입니다. 물류 센터 아홉 곳도 마스터 데이터입니다.

마스터 데이터는 그것을 쓰는 트랜잭션보다 오래 삽니다. 리테일 파트너 하나에 배송이 수백만 건일 수 있습니다. 그래서 그것에 대한 첫 질문은 늘 **누가 소유하는가?**입니다. Salesforce가 아닐 수 있습니다. ERP가 제품을 소유할 수 있습니다. Salesforce가 잠재 고객을 소유하고, 그들이 고객이 되면 ERP가 권위를 가질 수 있습니다. MDM 플랫폼이 여러 시스템에서 모은 고객의 기업 정체성을 소유할 수 있습니다. 6장, 마스터 데이터와 정체성에서 깊이 다룹니다. 지금은 모양을 알아보십시오.

참조 데이터: 비즈니스가 공유하는 어휘

참조 데이터는 다른 데이터를 분류하는 데 쓰는 통제된 어휘입니다. 국가 코드, 통화, 제품 범주, 사유 코드, 상태. Steve Trucking의 배송 상태(예약됨, 적재됨, 배송 중, 도착 임박, 배송 완료, 설치 완료, 예외, 반품)는 참조 데이터입니다. 배송이 아니라 배송을 기술하는 데 쓰는 말입니다.

작고 무해해 보입니다. 흔히 값 여덟 개짜리 선택 목록입니다. 작다고 중요하지 않은 것과 헷갈리지 마십시오. Salesforce는 Delivered, ERP는 Complete, 리테일 파트너는 D를 보낸다면, 누군가는 각각이 무엇을 뜻하고 어떻게 대응하는지 정의해야 합니다. 연동의 가정은 참조 데이터에 숨어 있습니다.

트랜잭션 데이터: 일어난 일

트랜잭션 데이터는 활동을 기록합니다. 주문 접수, 결제, 배송 완료, 케이스 생성. 같은 영업 org라면 견적과 견적 품목, 주문과 주문 품목, 결제입니다. 각각이 고객과 제품을 가리킵니다. Steve Trucking의 연간 배송 100만 건은 트랜잭션이고, 그 상태 갱신도 그렇습니다. 배송당 약 여덟 번이니 1년에 상태 변경 800만 건이고, 비즈니스는 매년 30%씩 성장합니다.

마스터 데이터와는 전혀 다른 성장 곡선입니다. 위에는 리테일 파트너 셋, 아래에는 수백만 행. 여기서 스티브의 0의 개수가 중요해집니다. 리테일 파트너 → 배송 → 상태를 보며 상자마다 같은 무게를 줄 수는 없습니다. 트랜잭션 데이터라면 저는 곧바로 볼륨, 속도, 보존, 이력, 보관, 연동, 그리고 사람들이 실제로 그것을 어떻게 찾아야 하는지 생각합니다. 파트 2가 거기에 많은 시간을 씁니다.

메타데이터: 데이터에 관한 데이터

이 과정 내내 메타데이터로 일해 왔습니다. 개체의 정의, 필드의 유형, 그 설명, 그 관계. 기업 전체에도 있습니다. 웨어하우스 스키마, 연동 매핑, 데이터 카탈로그, API 계약, 그리고 필드마다 소유자, 민감도 수준, 정의, 계보, 보존 규칙. 값은 데이터이고, 그 값이 무엇을 뜻하는지에 대한 기술은 메타데이터입니다. 3장에서 말했듯 Flag2__c는 아무에게도 아무것도 알려 주지 않고, AI가 데이터의 의미를 알아내려고 메타데이터를 읽는 지금 그것이 더 중요합니다.

분석 데이터: 다른 데이터로 만든 데이터

“지난 5년간 리테일 파트너별 정시 배송률은?”은 트랜잭션이 아닙니다. 분석 질문이고, 수백만 건의 배송에서 새 데이터를 만들어 답합니다. 정시율, 파손율, 파트너별 매출, 설치 품질, 배송팀 추세. 그리고 다른 일입니다. “217번 트럭의 다음 정차지는?”이라고 묻는 배차 담당자는 5년치 이력을 훑을 필요가 없습니다. 5년간 지역별 정시 성과를 비교하는 경영진은 필요합니다. 그래서 분석 데이터는 보통 그 일을 위해 만든 웨어하우스, 레이크하우스, 분석 플랫폼에 있습니다. Salesforce가 무언가를 저장할 수 있다고 해서 운영 플랫폼이 그 위의 모든 분석을 돌릴 곳이 되는 건 아닙니다.

비정형 데이터: 행에 들어가지 않는 것

문서, PDF, 이미지, 오디오, 동영상, 이메일, 녹취록, 지식 문서. Steve Trucking에서는 배송 사진입니다. 배송당 약 네 장, 설치가 있으면 더, 1년에 400만~500만 장. 사진은 그냥 필드 하나가 아닙니다. 크고, 누군가의 집 안을 보여 줄 수 있고, 자기 보존 규칙이 있으며, 검색 방식도 다릅니다. 검색이 된다면요.

이 종류는 해마다 더 중요해집니다. 예전에는 정형 모델 밖에 있던 정보로 이제 AI가 쓸모 있는 일을 할 수 있기 때문입니다. 녹취록은 데이터입니다. PDF 매뉴얼은 데이터입니다. 설치 사진은 데이터입니다. 그것이 Salesforce 코어에 속한다는 뜻은 아닙니다. 랜드스케이프에 속한다는 뜻입니다.

Click to enlarge

여섯 가지 종류, 각각 네 가지 질문. 답은 종류마다 달라지고, 바로 그것이 핵심입니다.

종류는 질문의 절반일 뿐이다: 워크로드

어떤 종류의 데이터를 가졌는지 아는 것으로는 부족합니다. 그것으로 무엇을 하는지도 알고 싶습니다. 여기서는 세 가지 워크로드가 중요하고, 그것들을 혼동하면 나쁜 아키텍처가 됩니다.

운영: 비즈니스를 돌린다. 배차 담당자가 배송을 갱신하고, 배송팀이 정차지를 마감하고, 상담원이 케이스를 엽니다. 작은 읽기와 쓰기가 많습니다. 이것 찾기, 저것 갱신, 오늘의 정차지 보여 주기. 이것이 OLTP, 온라인 트랜잭션 처리이고, Salesforce는 이걸 아주 잘합니다. 관리자와 개발자가 사는 곳입니다.

분석: 비즈니스를 이해한다. 5년치 모든 배송을 파트너와 물류 센터별로 묶고, 연도별로 비교하고, 재무와 결합합니다. 이제 훑고 집계합니다. 이것이 OLAP, 온라인 분석 처리이고, 웨어하우스, 레이크하우스, 분석 플랫폼이 바로 이것을 위해 만들어졌습니다. 간단히 말하면 org는 비즈니스를 돌리고, 웨어하우스와 레이크는 그것을 분석한다. 고전적인 실수는 그 워크로드를 운영 플랫폼에 얹고 0이 늘어날 때 놀라는 것입니다. 누군가 막대한 이력을 반복해서 훑고 싶어 한다면 “그냥 보고서 하나 더”로 다루지 마십시오. 올바른 플랫폼인지 물으십시오. 파트 2의 규모를 위한 설계 *(coming soon)*에서 다시 다루고(코어를 웨어하우스로 만들지 마라), 파트 3의 관계형 너머 *(coming soon)*에서 분석 구조를 어떻게 만드는지 보여 줍니다.

스트리밍: 움직이는 데이터. 이벤트, 원격 측정, 상태 변경, 센서 값. Steve Trucking의 트럭은 하루에 GPS 데이터 약 20만 건을 보냅니다. 배차 담당자는 217번 트럭이 지금 어디 있는지 신경 씁니다. Salesforce가 모든 트럭의 분 단위 읽기를 전부 보관해야 할까요? 아닐 수도 있습니다. “지금 어디인가?”와 “지난 분기 경로 효율 추세는?”은 같은 출처에서 나오지만 전혀 다른 저장 결정으로 이어집니다.

얼마나 빨리 움직여야 하는가?

그다음 지연입니다. 수업에서 저는 이렇게 말합니다. 실시간은 누군가 돌아오기를 문 앞에서 기다리는 것입니다. 심부름을 보내고 그 자리에 서 있습니다. 돌아올 때까지 다른 일을 할 수 없으니까요. 그것이 동기입니다. 준실시간은 그 사람이 나가는 걸 보고 다른 일을 하다가, 곧 돌아오면 그때 처리하는 것입니다. 그것이 비동기입니다. 그리고 배치가 있습니다. 아무도 한 명씩 문을 나서지 않습니다. 데이터는 기다렸다가 일정에 따라 한 묶음으로 움직입니다. 매시간, 몇 시간마다, 또는 매일. 배치로 충분한 상황은 많고, 그렇지 않은 상황도 있습니다. 어느 쪽인지 아는 것이 일입니다. 이 셋은 단지 연동 용어가 아니라 아키텍처 선택입니다.

흔한 ERP 연동을 보십시오. 오전 11시에 ERP에서 새 제품이 만들어집니다. 영업이 정말 정오까지 그것을 팔아야 할까요? 저는 두 가지 답을 다 봤습니다. 어떤 고객사는 가능한 한 빨리 원합니다. 다른 고객사는 그 SKU를 아직 출하해 주지 않았다면 아직 팔 거라고 기대할 수 없다고 말합니다. 그래서 제품은 보통 하루 한 번, 때로는 더 빠릅니다. 고객은 최소 하루 한 번. 매시간도 봤고, 극단적인 경우 준실시간도 봤습니다. 주문은 다릅니다. 처리가 시작되어야 하니 준실시간입니다. 영업 담당자는 거래를 성사시키고 다음 일로 넘어가고, 주문은 몇 초에서 1~2분 안에 ERP에 도착합니다. “기업 데이터”에 맞는 단 하나의 지연은 없습니다. 비즈니스가 실제로 필요로 하는 것을 묻고, 인상적으로 들린다는 이유로 모든 것을 실시간으로 만들지 마십시오. 실시간에는 비용이 있습니다.

범주 뒤의 네 가지 질문

“이건 트랜잭션 데이터다!”라고 외치고 다닐 필요는 없습니다. 분류는 중요한 데이터 세트마다 네 가지 질문을 불러일으키려고 있는 것입니다.

누가 소유하는가? 어느 시스템이 권한 원천인가? 저는 이것을 셋으로 나눕니다. 어디서 생성되는가, 어디서 편집되는가, 어디서 참조되는가? 6장에서 깊이 다룹니다(만들어지고, 편집되고, 참조되는 곳, 그리고 얼마나 빨리?).
얼마나 빨리 변하는가? 1년에 한 번, 매일, 초당 수십에서 수백 번?
얼마나 커지는가? 10건, 1만 건, 1,000만 건, 100억 건?
생명주기는 무엇인가? 영원히 사는가, 보관되는가, 삭제되어야 하는가, 시간이 지나며 가치를 잃는가?

그 네 가지가 “Salesforce가 이걸 저장할 수 있나?”보다 훨씬 많은 것을 알려 줍니다. 그리고 이미 배운 것을 하나로 묶습니다. 소유권, 생명주기, 0의 개수, 데이터가 있는 곳.

하나의 비즈니스가 모든 종류를 만든다

Steve Trucking에서 리테일 파트너는 마스터 데이터, 상태 어휘는 참조 데이터, 각 배송은 트랜잭션, 그 필드의 정의는 메타데이터, 5년치 정시 성과표는 분석, 설치 사진은 비정형, GPS 피드는 스트리밍입니다. 모두 “Steve Trucking 데이터”입니다. 그렇다고 같은 데이터베이스에 속하지는 않습니다. 그것이 전환입니다.

시험 너머: AI가 바꾸는 것. 질문 하나에 답하려고 에이전트에게는 정형 고객 레코드, 최근 트랜잭션, PDF 매뉴얼, 서비스 녹취록, 실시간 원격 측정이 필요할 수 있습니다. 비정형과 스트리밍 데이터는 CRM 데이터베이스에 속하지 않더라도 아키텍처의 일급 구성 요소가 되며, 아키텍트는 여전히 각 출처를 누가 소유하는지, 얼마나 최신인지, 에이전트가 그것을 믿어야 하는지 알아야 합니다.

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

중요한 각 데이터 세트가 어떤 종류의 데이터이며, 누가 소유하는지.
그 워크로드가 운영, 분석, 스트리밍, 또는 그 혼합 중 무엇인지.
얼마나 빨리 변하며, 다른 시스템이 그 변화를 실제로 얼마나 빨리 봐야 하는지.
볼륨과 생명주기가 그것이 어디에 얼마나 오래 있을지를 어떻게 정하는지.
Salesforce가 그것을 소유할지, 사본을 둘지, 참조할지, 워크로드에 더 맞는 곳에 둘지.

누군가 요구사항을 건네면 어떤 개체, 어떤 필드, 어떤 API로 뛰어들지 마십시오. 먼저 어떤 종류의 데이터인지, 누가 소유하는지, 얼마나 빨리 변하는지, 얼마나 커지는지, 얼마나 오래 사는지, 그것으로 무엇을 하려는지 물으십시오. 계정, 배송 이벤트, 5년치 집계, 사진 한 장은 모두 같은 비즈니스에 중요하면서도 같은 아키텍처 문제가 아닐 수 있습니다.

더 알아보기

DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 제2판(2017, 영어): 데이터 범주와 데이터 관리의 표준 참고서.
Steve Trucking 브리프, 4절(볼륨).