명사를 들어라
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 과정 2장인 의미를 위한 데이터 모델링의 모듈 1/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 장 개요 · 다음: 관계를 그려라
이 모듈이 답하는 질문: 비즈니스 대화에서 데이터 모델의 시작을 어떻게 찾을까요?
고객과의 첫 통화에서 제가 하는 일 중 하나는 명사를 듣는 것입니다.
첫 설계 회의를 말하는 게 아닙니다. 아직 비즈니스와 그들이 이루려는 것을 이해하려 애쓰는 첫 대화를 말하는 겁니다.
그들은 말합니다. 저는 듣습니다.
그리고 이런 단어를 듣습니다.
리테일 파트너. 수령인. 물류 센터. 배송 목록. 배송. 경로. 배송팀. 트럭.
이 명사들이 곧바로 제 주의를 끕니다. 그 대화 어딘가에 제 데이터 모델의 시작이 있기 때문입니다.
문제를 완전히 이해했다고 생각할 때까지 기다리지 않습니다. 아직 듣는 동안 데이터를 보기 시작합니다. 명사를 듣고, 그것들이 어떻게 연결되는지 스케치하기 시작하고, 그 스케치가 다음 대화의 틀을 잡도록 돕습니다. 때로는 고객과의 첫 회의가 끝날 무렵 이미 저만의 데이터 모델을 그려 두고 있습니다.
저에게는 그것이 명사에서 시작합니다.
잠시 Salesforce를 잊어라
섹션 제목: “잠시 Salesforce를 잊어라 ”여기서 저항해 주셨으면 하는 본능이 있습니다. Salesforce 관리자로 오래 일했다면 특히 강한 본능입니다.
고객이 고객이라고 말하면, 당신은 생각합니다.
계정.
사람이라고 말하면, 당신은 생각합니다.
연락처.
물류 센터라고 말하면, 벌써 사용자 정의 개체가 필요한지 고민하고 있습니다.
아직 그러지 마십시오.
이 시점에서 저는 고객이 결국 계정이 될지, 개인 계정이 될지, 사용자 정의 개체가 될지, 다른 무언가가 될지 신경 쓰지 않습니다. 먼저 비즈니스를 이해하고 싶습니다.
그것이 비즈니스를 모델링하는 것과 Salesforce를 구성하는 것의 차이입니다. Salesforce 개체에서 시작하면 이미 생각을 하나의 구현에 가둔 것입니다. 결국 예상했던 곳에 도착할 수도 있지만, 저는 계정과 연락처가 처음 알았던 두 개체여서가 아니라 비즈니스가 이끌었기 때문에 그곳에 도착하고 싶습니다.
그러니 몇 분만 Salesforce를 잊으십시오. 실제로 비즈니스를 운영하는 사람들이 자기 세계를 어떻게 묘사하는지 들으십시오.
앉아, 기다려, 모델링
섹션 제목: “앉아, 기다려, 모델링 ”비즈니스의 말을 듣기 전에, 누구나 이미 이해하는 것부터 들어 봅시다. 저는 이 내용을 실제 수업에서 가르칠 때 개로 시작합니다.
여기 개 한 마리가 있습니다. 마커스가 벨라를 키웁니다. 벨라는 메이플 리지 켄넬에서 태어났습니다. 래브라도이고, 앉아, 기다려, 손을 할 줄 압니다.
명사를 들어 보십시오. 마커스, 벨라, 메이플 리지 켄넬, 래브라도, 앉아. 하지만 이것들은 이름, 즉 구체적인 대상입니다. 제가 원하는 것은 각 이름이 속한 종류입니다. 벨라는 개(Dog)입니다. 마커스는 주인(Owner)입니다. 메이플 리지 켄넬은 브리더(Breeder)입니다. 래브라도는 품종(Breed)입니다. 앉아는 재주(Trick)입니다. 명사 다섯 개, 후보 상자 다섯 개.
그다음 모든 명사에 던지는 질문입니다. 이것은 일을 하는 사람인가, 데이터인가? 마커스는 사람입니다. 하지만 벨라를 키우는 것은 일이 아니라 벨라에 관한 사실이고, 머지않아 누군가 “이 개의 주인은 누구죠?”라고 묻습니다. 그러니 주인은 모델에 들어갑니다. 벨라에게 손을 가르친 훈련사는 일을 하는 사람이고, 상자가 필요 없을 수도 있습니다. 비즈니스가 누가 어떤 재주를 가르쳤는지 묻기 시작하지 않는 한 말입니다.
그리고 후보라는 말에 주목하십시오. 품종은 정말 독립된 상자일까요, 아니면 개에 적힌 단어일 뿐일까요? 그 질문을 붙들고 계십시오. 모듈 4에서 정규화할 때 답하겠습니다.
작은 예로 본 기법의 전부입니다. 이제 실제 비즈니스의 말을 들어 봅시다.
명사는 후보 엔터티를 준다
섹션 제목: “명사는 후보 엔터티를 준다 ”이 과정 내내 쓸 가족 경영 회사 Steve Trucking의 이야기를 들어 봅시다. 대형 유통업체의 물류 센터에서 냉장고, 세탁기, TV 같은 대형 상품을 사람들의 집까지 배송하고, 그중 일부는 설치까지 합니다.
첫 대화에서 이런 말을 듣습니다.
- 리테일 파트너
- 수령인
- 물류 센터
- 배송 목록
- 배송
- 경로
- 배송팀
- 트럭
이미 쓸모가 있습니다. 화이트보드에 상자를 그리기 시작할 수 있습니다.
그러니 명사를 사각형 안에 넣으십시오. 이 시점에서는 그게 전부입니다. 상자. 선도, 색도, Salesforce를 말해 주는 어떤 것도 없습니다. 과정 후반에는 모양과 색이 의미를 갖기 시작합니다. 지금은 사각형이 그저 비즈니스가 이야기하는 대상일 뿐입니다.
그다음 방향을 잡기 시작하십시오. 상자를 하나씩 놓으면서 두 가지를 생각해야 합니다. 서로 어떻게 연결되는지, 그리고 어떤 종류의 데이터인지. 일부는 고객 데이터입니다. 우리가 함께 일하는 기업과 사람들입니다. 일부는 주문과 주문 품목 같은 트랜잭션 데이터입니다. 계속해서 반복해 일어나는 일들입니다. 그리고 일부는 기업이 제공하는 제품이나 서비스 같은 참조 데이터입니다. 일이 의존하는 것들입니다.
Steve Trucking에서 리테일 파트너와 수령인은 고객 데이터입니다. 배송 목록, 배송, 경로는 트랜잭션입니다. 물류 센터, 배송팀, 트럭은 일이 의존하는 것들입니다.
하지만 여기에 중요한 단어가 있습니다. 후보입니다.
명사는 단서입니다. 자동으로 엔터티가 되는 것도 아니고, 자동으로 Salesforce 개체가 되는 것은 더더욱 아닙니다.
디스커버리 세션에서 저는 모든 명사를 적습니다. 그들이 말하는 명사마다 스스로에게 하나를 묻습니다. 이것은 일을 하는 사람인가, 데이터인가? 사업 개발 매니저는 일을 하는 사람입니다. 그건 사용자, 역할, 어쩌면 권한 집합입니다. 주문, 청구서, 품목은 데이터입니다. 둘 다 중요하지만 설계에서 전혀 다른 곳에 들어가며, 일찍 구분해 두면 조직도의 직함마다 상자를 그리는 일을 피할 수 있습니다.
그런데 그 명사 중 일부는 사람일 것입니다. Steve Trucking에서는 냉장고를 기다리는 수령인, 배송 목록을 보내는 리테일 파트너 쪽 사람들, 그리고 배송팀, 즉 트럭에 탄 기사와 보조원입니다. 이것들은 역할이고, 역할은 데이터처럼 보이지 않을 수 있습니다. 하지만 사람이 데이터에 대해 행동하거나 데이터와 관련되면, 그들 자신도 데이터에 표현되어야 합니다. 누가 이걸 배송했나? 누가 서명했나? 누가 배송 목록을 보냈나? 그래서 많은 역할이, 때로는 전부가 모델에도 들어가게 됩니다.
Steve Trucking이 말하는 방식을 들어 보면 한 가지를 알아차릴 겁니다. 그들은 그냥 “고객”이라고 말하지 않습니다. 두 종류의 고객이 있습니다. 리테일 파트너는 Steve Trucking이 그를 위해 배송하는 대형 유통업체입니다. 배송 목록을 보내고 배송 건당 비용을 냅니다. 수령인은 냉장고를 받는 사람입니다. 수령인은 매장에서 그것을 샀고 Steve Trucking이라는 이름을 들어 본 적도 없을 수 있습니다.
고객이라는 상자 하나를 그렸다면, 전혀 다른 두 가지를 섞어 버렸을 것입니다.
어쩌면 물류 센터는 자기 레코드, 이력, 관계, 속성을 가질 만큼 중요할 수도 있습니다.
어쩌면 다른 명사는 결국 다른 무언가의 속성일 뿐으로 드러날 수도 있습니다.
그것을 알아내려는 것입니다. 아직 개체를 만드는 게 아닙니다. 비즈니스에 대한 이해를 쌓는 중입니다.
이제 관계를 들어라
섹션 제목: “이제 관계를 들어라 ”명사는 출발점을 줍니다. 그다음 저는 비즈니스가 그것들을 어떻게 연결하는지 듣습니다.
리테일 파트너는 물류 센터들을 운영한다.
리테일 파트너는 물류 센터와 배송일마다 배송 목록을 보낸다.
배송 목록에는 배송들이 나열된다.
배송은 수령인에게 간다.
경로는 약 열 곳의 정차지를 도는 하루치 운행이다.
두 명으로 된 배송팀이 트럭을 운행한다.
이제 무언가가 일어나고 있습니다. 더 이상 명사 목록을 보고 있지 않습니다. 모델이 보이기 시작합니다.
질문이 나타나기 시작하는 곳도 여기입니다.
리테일 파트너가 물류 센터를 둘 이상 가질 수 있나?
배송은 정차지와 같은 것인가?
정차지 하나에서 수령인 두 명에게 배송할 수 있나?
배송팀은 늘 같은 두 사람인가?
지난달 어느 배송팀이 어느 트럭을 몰았는지가 중요한가, 아니면 오늘 어느 트럭을 모는지만 중요한가?
우리가 무엇을 하고 있는지 보십시오. 아직 Salesforce 질문을 하고 있지 않습니다. 비즈니스 질문을 하고 있습니다. 그리고 그 답이 결국 Salesforce 설계를 이끌 것입니다.
첫 모델은 완벽하지 않아도 된다
섹션 제목: “첫 모델은 완벽하지 않아도 된다 ”처음 그린 상자들이 그대로 살아남으리라 기대하지 않습니다. 사실 그대로 살아남는다면 의심스러울 겁니다.
첫 모델의 목적은 맞는 것이 아닙니다. 우리가 어디서 틀렸는지 발견할 만큼 구체적인 무언가를 주는 것입니다.
배송, 경로, 배송팀, 트럭을 보드에 올리면 사람들이 반응할 수 있습니다.
“사실 배송이 늘 상품 하나는 아니에요. 세탁기, 건조기, 그리고 헌 제품 수거일 수도 있어요.”
좋습니다. 더 말씀해 주세요.
“배송팀을 배송에 배정하지 않아요. 경로에 배정해요.”
좋습니다. 경로에는 무엇이 있나요?
“그리고 설치가 있으면 체크리스트와 사진이 끝나기 전에는 배송팀이 정차지를 마감할 수 없어요.”
이제 중요한 것을 배우고 있습니다.
다이어그램 하나가 모호한 대화를 반론할 수 있는 무언가로 바꿨습니다. 그것이 제가 일찍 모델링하기를 좋아하는 이유 중 하나입니다. 아름다운 다이어그램으로 회의실을 감동시키려는 게 아닙니다. 더 빨리 배우려는 것입니다.
모델은 대화의 일부입니다.
이것이 개념 모델이다
섹션 제목: “이것이 개념 모델이다 ”우리가 만들기 시작한 것에는 공식 이름이 있습니다. 개념 데이터 모델입니다.
이 수준에서 제가 관심 있는 것은 비즈니스가 중요하게 여기는 것들과 그것들이 어떻게 연결되는지입니다. 표준 개체냐 사용자 정의 개체냐, 필드 API 이름, 조회냐 마스터-세부 사항이냐, 필수 필드, 인덱스, 자동화, Apex, Flow는 아직 걱정하지 않습니다. 그것들도 중요하고, 거기까지 갈 것입니다. 하지만 무엇을 모델링하는지 이해하기 전에 그것들을 정하면, 엉뚱한 문제부터 푸는 셈입니다.
개념 모델은 회의실에서 Salesforce를 모르는 사람들에게도 이해되어야 합니다. 유용한 시험입니다. 운영 매니저가 제 다이어그램을 읽기 전에 Delivery__c가 무슨 뜻인지 설명해야 한다면, 너무 일찍 구현으로 넘어간 것입니다.
저는 그들이 모델을 보고 이렇게 말하기를 원합니다.
“네, 우리 비즈니스는 그렇게 돌아가요.”
아니면, 더 좋은 것은:
“아니요, 그렇게 돌아가지 않아요.”
이제 고칠 것이 생겼으니까요.
아무도 말하지 않을 때도 같은 기법이 통한다
섹션 제목: “아무도 말하지 않을 때도 같은 기법이 통한다 ”이것은 고객 디스커버리에서만 쓰는 방법이 아닙니다. “고객”이 문서일 때도 통합니다.
요구사항 문서를 읽을 때도 저는 거의 같은 일을 합니다. 중요한 비즈니스 개념은 무엇인가? 어떤 관계가 기술되어 있나? 무엇이 반복해서 나오나? 무엇이 자기 생명주기를 갖고, 따로 식별되어야 하고, 이력이 필요한가? 무엇이 생성되고, 변경되고, 배정되고, 이전되고, 일정이 잡히고, 퇴역하나?
첫 회의에서 듣는 것과 같은 것들입니다. 종이 위에서 그 단서들은 요구사항 문단을 추론할 수 있는 모델로, 그리고 다음 대화를 위한 더 나은 질문으로 바꿉니다.
모델은 문제를 푼 뒤에 만들어 내는 산출물이 아닙니다. 문제를 푸는 데 쓰는 도구 중 하나입니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”이 첫 단계가 끝날 무렵, 저는 이것을 결정하려 합니다.
- 어떤 명사가 의미 있는 후보 엔터티인지.
- 어떤 서로 다른 단어가 같은 비즈니스 개념을 나타내고, 어떤 한 단어가 두 가지를 숨기고 있는지(“고객”처럼).
- 어떤 개념이 자기 레코드와 생명주기를 필요로 하는지.
- 주요 개념들이 서로 어떻게 연결되는지.
- 자신 있게 모델링하기 전에 비즈니스가 답해야 할 질문은 무엇인지.
아직 Salesforce 구현을 결정하는 것은 아닙니다. 먼저 비즈니스를 그릴 수 있을 만큼 이해해야 합니다. 그리고 명사들이 보드에 올라가면, 다음으로 이해하고 싶은 것은 그 사이의 선입니다.
시험 너머: AI가 바꾸는 것. AI 도구에 요구사항 문서를 주면 몇 초 만에 명사를 찾고, 엔터티를 제안하고, 관계를 스케치합니다. 디스커버리를 가속하는 데 쓰되, 이해를 외주로 맡기지는 마십시오. Steve Trucking에서 “고객”이 두 가지 다른 것을 뜻한다는 걸 AI는 비즈니스가 말해 주지 않는 한 알 수 없습니다. AI의 첫 모델을 비즈니스를 운영하는 사람들 앞에 놓고 물으십시오. “여러분의 비즈니스가 정말 이렇게 돌아가나요?”