계층과 양방향 데이터

🌐 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 과정 6장인 마스터 데이터와 정체성의 모듈 5/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 지도는 결정이 아니다 · 다음: 체크포인트 1: Steve Trucking

이 모듈이 답하는 질문: 둘 이상의 시스템이 유지하는 데이터는 어떻게 관리할까요?

쉬운 아키텍처는 이렇습니다. ERP가 고객을 소유하고, Salesforce는 사본을 받고, 끝. 실제 기업은 그렇게 깔끔하지 않습니다. ERP는 법적 고객을, Salesforce는 영업 관계를 소유하고, 한 사업부는 SAP에, 인수한 사업부는 다른 ERP에 있고, 잠재 고객은 Salesforce에만 있습니다. 그러다 누군가 Salesforce 사용자가 ERP가 관리하는 필드를 갱신하게 해 달라고 하면, 화살표가 양쪽을 가리키기 시작합니다. 제가 이걸 가르칠 때 말하듯이, “가장 어려운 건 양방향 연동입니다.” 데이터를 양쪽으로 보내는 것이 기술적으로 어려워서가 아니라, 두 시스템이 모두 변경에 참여하는 순간 권한 원천에 대해 극도로 정확해야 하기 때문입니다.

양방향 데이터가 마스터가 둘이라는 뜻은 아니다

ERP가 청구 주소를 소유하고, 그것이 Salesforce에 복사됩니다. 영업 담당자가 고객에게서 주소가 바뀌었다는 걸 듣고, 비즈니스는 Salesforce를 떠나지 않고 갱신하게 하고 싶어 합니다. 합리적입니다. 이제 데이터는 ERP → Salesforce, Salesforce → ERP로 흐릅니다. 그럼 Salesforce가 청구 주소를 공동 소유하게 된 걸까요? 아닙니다. 통합의 방향이 권한 원천을 정하지 않습니다. 영업 담당자는 Salesforce의 사본을 바꾸는 게 아닙니다. 아키텍처적으로는 권위 있는 값의 변경을 요청하는 것입니다. ERP의 필드를 바꾸는 게 아니라, 바꿔 달라고 요청하는 것입니다. Salesforce는 인터페이스이고, ERP는 여전히 마스터입니다.

그것이 설계를 바꿉니다. Salesforce가 필드를 소유한다면 저장하고 끝입니다. ERP가 소유한다면 “저장”은 이런 뜻입니다. Salesforce가 제안된 주소를 보내고, ERP가 검증하고 수락하고, 마스터를 갱신하고, 권위 있는 값을 돌려보냅니다. 그때 비로소 관리되는 값이 바뀝니다. 요청 → 검증 → 수락 → 게시이지, “두 시스템을 갱신하고 동기화가 유지되길 바란다”가 아닙니다.

Click to enlarge

양방향 통합이 양방향 권한 원천을 만들지는 않는다.

마스터가 거절할 때

ERP가 변경을 거절합니다. 고객이 비활성이거나, 주소가 ERP 규칙을 어기거나, 사용자에게 법적 주소를 바꿀 권한이 없거나, ERP가 다운되었거나, 그사이 누군가 고객을 바꿨을 수 있습니다. Salesforce가 이미 새 주소를 보여 줬다면 이제 진실이 둘이고, 어느 쪽이 이기는지는 모듈 1이 이미 말했습니다. ERP입니다. 그래서 아키텍처에는 요청됨, 아직 수락되지 않음 상태가 필요합니다. 별도의 제안 값, “변경 대기” 플래그, 또는 확인을 받을 때까지 보여 주지 않기. 메커니즘은 사용 사례에 달려 있습니다. 규칙은 그렇지 않습니다. 거절된 요청이 경쟁하는 진실이 되게 두지 마십시오.

루프와 충돌

고전적인 예가 있습니다. ERP가 Salesforce를 갱신하고, Salesforce의 통합이 변경을 보고 ERP로 보내고, ERP가 갱신을 보고 다시 돌려보냅니다. 아주 비싼 루프를 만든 것입니다. 좋은 양방향 설계는 변경이 어디서 시작됐는지, 마스터가 수락했는지, 이것이 새로운 비즈니스 변경인지 이미 처리된 변경의 메아리일 뿐인지 압니다. 원천 식별자, 타임스탬프, 통합 메타데이터, 멱등 처리. 통합 장에서 깊이 다룹니다. 마스터 데이터의 원칙은 간단합니다. 변경을 일으키는 것인지, 반영하는 것인지 알아야 합니다.

그다음은 충돌입니다. 5장에서 하나를 만났습니다. 영업 담당자가 Steve’s Plumbing LLC를 요청하는 사이 ERP의 누군가는 Steve’s Plumbing L.L.C.를 입력합니다(관리되는 레코드를 보호하라). 여기 또 하나가 있습니다. Salesforce가 125 Main Street를 제안하고, 거의 같은 순간 ERP 사용자가 130으로 바꿉니다. 어느 쪽이 이길까요? 보편적인 기술적 답은 없습니다. ERP가 필드를 소유하니 항상 이길 수도 있고, Salesforce 요청이 검토 대기열로 갈 수도 있고, 나중에 수락된 변경이 이길 수도 있고, ERP가 시작 값이 바뀐 갱신은 모두 거절할 수도 있습니다. 그것은 동시성 문제지만, 그 밑에는 권한 원천의 결정이 있습니다. 누가 권위 있는 변경을 할 수 있는지 아무도 정하지 않았다면 어떤 통합 패턴도 구해 주지 못합니다.

그리고 필드 하나는 단순한 경우입니다. 주소는 도로명, 도시, 우편번호로 이루어집니다. ERP가 방금 도시를 바꿨는데 Salesforce가 새 도로명을 보냅니다. 도로명만 통과시킬까요? 아니면 주소를 하나의 트랜잭션으로 다뤄서, 필드들이 모두 함께 가거나 아무것도 가지 않게 하고, 변경 전체를 거절할까요? 어떤 필드들이 한 묶음으로 움직이는지는 첫 충돌이 일어난 뒤가 아니라 그 전에 정하십시오.

양방향 통합을 볼 때마다 저는 묻습니다. 양쪽이 같은 데이터를 바꾸면 어떻게 되나요? 답이 “아마 그런 일은 없을 거예요”라면 아직 끝나지 않은 것입니다. 어느 쪽이 이기나요? 거절하나요, 대기열에 넣나요, 버전을 비교하나요, 검토하나요? 그 필드가 애초에 양쪽에서 편집 가능해야 하나요? 때로는 최고의 양방향 설계가 특정 속성에 대해 한 방향을 없애는 것입니다. Salesforce는 요청할 수 있고, 수락된 값은 ERP만 게시합니다. 데이터는 여전히 양쪽으로 움직이지만, 그 필드의 마스터는 한 시스템뿐입니다. 그 차이가 전부입니다.

계층도 마스터 데이터다

관계도 마스터 데이터일 수 있습니다. 북미와 유럽 지역을 둔 글로벌 모회사, 그 아래 각 국가 자회사들. 계층 자체가 의미를 지닙니다. 누가 모회사인가? 어느 자회사가 어느 법인 아래에 있나? 어떤 계정이 글로벌 고객으로 롤업되나? 그것이 보고, 영업 지역, 가격, 계약, 신용 익스포저, 서비스, 데이터 접근, 분석을 좌우합니다. 계층은 그 안의 레코드만큼 중요할 수 있고, 같은 거버넌스가 필요합니다. (시험은 계층 관리를 명시하는데, 잊기 쉽습니다.)

Salesforce에서 계정 계층은 상위 계정 필드로 만듭니다. Lightning 계층 보기는 최대 2,000개 계정을, 그리고 사용자가 볼 수 있는 것만 보여 줍니다. 계층에서 개인 계정은 지원되지 않으며, 계정 사이트가 회사의 지점을 구별합니다(Considerations for Using Account Hierarchy (opens in a new tab)). 하지만 상위 계정 필드는 아키텍처 질문에 답하지 않습니다. 계층은 누가 소유하나?

시험 포인트. 계정 계층의 기본을 알아 두십시오. 상위 계정으로 만들고, Lightning 보기는 최대 2,000개 계정을, 그중 사용자가 볼 수 있는 것만 보여 주며, 개인 계정은 지원되지 않고, 계정 사이트가 회사의 지점을 구별합니다.

하나의 계층, 여러 마스터

제 경험으로는 계층은 마스터가 나뉘어 있습니다. 북미 법인들은 SAP에서, 유럽 법인들은 다른 ERP에서 오고, 새 잠재 고객은 Salesforce에서 만들어지고, 인수한 자회사는 아직 이전되지 않았습니다. 계층은 누가 소유할까요? 가지에 따라 다릅니다. 각 ERP가 자기 가지를 관리하고, Salesforce는 잠재 고객 관계를 전환될 때까지 관리합니다. 모두가 경계가 어디인지 아는 한, 정당한 아키텍처입니다. 가지별로 정하십시오.

Click to enlarge

계층의 권한 원천은 가지별로 정할 수 있다.

그러니 상위 계정 필드가 권한 원천을 가리게 두지 마십시오. 사용자가 Salesforce에서 자회사의 상위 계정을 바꿉니다. 기술적으로는 사소합니다. 아키텍처적으로는, 방금 회사의 법적 구조를 바꾼 걸까요? ERP가 그 가지의 마스터라면 아마 아닐 테니, Salesforce는 그걸 막거나 변경 요청으로 바꿔야 합니다. 아니면 Salesforce가 정당하게 상업적 계층을 유지하고 ERP가 법적 계층을 유지하는 것일 수도 있습니다. 그렇다면 아마 그 둘은 애초에 같은 관계여서는 안 됩니다.

한 회사에는 여러 유효한 계층이 있을 수 있습니다. 법적, 청구, 영업, 서비스, 지리적 계층. 글로벌 모회사가 계약에 서명하고, 지역들은 각자 서비스를 받고, 청구는 공유 재무 법인을 거치고, 영업은 지역별로 관리합니다. 진짜 계층은 어느 것일까요? 전부입니다. 각자 다른 질문에 답합니다. 실수는 하나여야 한다고 가정하는 것입니다. 각 관계의 종류마다 분명한 권한 원천이 있어야 합니다. 모듈 1의 속성 원칙을 관계에 적용한 것입니다.

그리고 모든 부모-자식 관계가 마스터 데이터는 아닙니다. 오늘의 배송을 한 경로로 묶는 것도 관계지만, 트랜잭션이자 운영 이벤트입니다. 고객 계층은 지속적인 비즈니스 관계를 설명합니다. 모델에서는 둘 다 부모-자식으로 보이지만 수명 주기가 같지 않습니다. 그 관계가 무엇을 뜻하는지, 그 의미가 얼마나 오래가는지 물으십시오.

고객 하나, ERP 둘

이걸 가르칠 때 저는 교실에 묻습니다. Salesforce는 하나인데 ERP는 둘 이상인 고객사와 일해 본 사람? 매번 손이 올라갑니다. 이유를 물어보면, ERP는 지역별로(북미용 하나, 유럽용 하나), 기능별로(배관 회사가 전기 회사를 인수하고, 각자 자기 ERP를 유지), 아니면 그냥 역사적으로 나뉘어 있습니다. 사업을 인수했는데 아직 아무도 이전하지 않은 것이죠.

Steve’s Plumbing을 고객으로 들어 보겠습니다. 북미에서 사업을 하니 북미 ERP에 고객 레코드가 있습니다. 그러다 뮌헨에 사무소를 열고, 유럽 ERP가 자체 고객 번호로 자기 고객 레코드를 만듭니다. 같은 회사, 레코드 둘, ID 둘. 이것을 Salesforce org 하나에서 어떻게 나타낼까요? 저는 세 가지 방법을 보았습니다.

계정 계층. Steve’s Plumbing이 상위이고, Steve’s Plumbing North America와 Steve’s Plumbing Europe이 하위 계정이며, 각 하위 계정이 한 ERP의 레코드를 나타냅니다. 함정은 이것입니다. 하위 계정들은 더 이상 정말로 Steve’s Plumbing이 아닙니다. 한 지역에서 사업하는 Steve’s Plumbing이고, 방금 보았듯이 계층은 의미를 지닙니다.

동등 계정. 계정 두 개가 나란히 있고, 각각 어느 ERP에 속하는지 말해 주는 필드(회사 코드, 지역)가 있습니다. 숨겨진 것은 없습니다. 비용은 보고에서 드러납니다. 전 세계의 Steve’s Plumbing을 보려면 이 두 계정이 같은 회사라고 말해 주는 무언가가 필요합니다.

계정 하나와 ERP마다 하위 레코드. Steve’s Plumbing은 하나이고, 하위 개체에 ERP마다 그 ERP의 고객 ID를 담은 레코드가 있습니다. ERP가 둘이든 열이든 상관없습니다. 영업 담당자들은 고객 하나를 보고 주문 하나를 넣습니다. 뒤에서는 Flow가 각 품목이 어느 ERP로 갈지 정합니다. 전기 작업은 전기 ERP로, 배관은 배관 ERP로. 하지만 이제 이름과 주소 같은 공유 값에 대해 어느 ERP가 기본인지, 그리고 고객이 한 ERP에는 있고 다른 ERP에는 없을 때 무슨 일이 일어나는지 정해야 합니다.

Click to enlarge

고객 하나, ERP 둘: Salesforce에서 나타내는 세 가지 방법.

ERP들을 어떻게 동기화하는지 물어라

그럼 어느 것일까요? 먼저, 영업 담당자들이 ERP 구조를 얼마나 봐야 할까요? 한쪽 ERP나 다른 쪽 ERP에 로그인하기 때문에 북미와 유럽이 별개의 사업이라는 걸 늘 알아 왔다면, 그들에게서 그걸 숨기지 마십시오. 그 구조를 동등 계정으로 Salesforce에 가져오십시오. 비즈니스가 영업 앞에 Steve’s Plumbing 하나를 두고 싶어 한다면, ERP마다 하위 레코드를 둔 계정 하나를 보고 있는 것입니다.

그다음이 정말로 결정을 내리는 질문이고, 그것은 Salesforce에서 정해지지 않습니다. 저는 고객사에 묻습니다. ERP들 사이에서 그 두 레코드를 어떻게 동기화하십니까? 잔액처럼 각 ERP에 로컬인 것을 말하는 게 아닙니다. 그건 트랜잭션 데이터입니다. 제 말은 마스터 데이터, 즉 법적 이름과 주소입니다. 두 ERP를 동기화하는 팀이 있다면 계정 하나로 합칠 수 있습니다. 자기 ERP에서도 동기화하지 못한다면, 어떻게 우리가 Salesforce에서 동기화해 주길 기대하겠습니까? 그렇다면 동등 계정이나 계층입니다.

ERP가 무엇인지 기억하십시오. 도입에 몇 년이 걸리는 거대한 시스템이고, 마스터 데이터를 관리하는 자기만의 방식을 갖고 옵니다. Salesforce가 그것을 움직이지는 않습니다. 우리는 ERP를 통제하지 못합니다. 우리가 통제할 수 있는 것은 Salesforce에서 그것을 어떻게 나타내느냐입니다.

가운데의 MDM

어떤 고객사는 우리가 오기 전에 이미 이 문제를 풀었습니다. 오랜 업력의 대기업, 여러 ERP. Salesforce보다 훨씬 전에 이 문제에 부딪혔고, ERP들 사이를 중개하도록 전용 MDM 제품을 가운데에 두었습니다. 모듈 2의 공존 또는 중앙 집중형 MDM입니다. 이제 Salesforce는 모든 ERP에 직접 연결하지 않습니다. 한곳, 즉 MDM 허브를 가리키고, 고객에 대한 단일한 표현을 받습니다. 하지만 자주 만날 거라고 기대하지는 마십시오. 그 자체로 큰 구현이고, 제가 일한 그 많은 세월 동안 함께 일해 본 건 두세 번뿐입니다. 그리고 허브가 있어도 각 주문이 어느 ERP로 가는지 알 수 있도록 그 하위 개체가 여전히 필요할 수 있습니다.

Click to enlarge

가운데의 MDM: Salesforce는 한곳을 가리킨다.

Steve Trucking: 누구의 계층인가?

리테일 파트너에게는 자기만의 구조가 있습니다. 본사, 지역 사업부, 물류 센터, 매장. Steve Trucking이 그 계층을 소유할까요? 아닙니다. 자기 조직의 권한 원천은 파트너입니다. 하지만 Steve Trucking은 계약, 계정 관리, 서비스, 보고를 위해 같은 지점들에 대한 자체 상업적 뷰가 필요할 수 있습니다. 예를 들어 파트너 아래 물류 센터마다 하위 계정을 두는 것입니다. 정당한 계층 둘, 권한 원천 둘. 이름을 붙이고, 하나의 트리가 모든 관계를 나타내는 척하지 마십시오.

경계를 보이게 하라

권한 원천이 나뉠 때마다 저는 경계가 보이기를 원합니다. 필드 이름, 레코드 메타데이터, 원천 시스템 식별자, 권한, 통합 동작, 문서. 제가 원하지 않는 건 개발자가 통합 다섯 개를 읽고 나서야 “이 상위 계정 값들은 SAP에서 온다, 잠재 고객은 빼고, 유럽도 빼고”를 발견하는 것입니다. 그건 유지 관리할 수 있는 권한 원천 모델이 아닙니다. 계층의 마스터가 나뉘어 있다면 그 분할을 문서화하십시오. 전환 시점에 권한 원천이 바뀐다면 그 변화를 문서화하십시오. Salesforce가 변경을 요청할 수는 있지만 할 수는 없다면, 그걸 사용 경험에서 분명히 보이게 하십시오.

Salesforce에서는 그것이 필드 하나에서 시작합니다. 이것이 마스터 데이터라고 분명히 말하는 필드가 있어야 합니다. ERP의 키, 또는 “마스터 데이터임” 플래그. 필드 편집 가능 여부는 레코드 유형이 아니라 그 필드로 정하십시오. Dynamic Forms가 있으면 ERP의 필드를 읽기 전용으로 보여 주기 위해 더 이상 레코드 유형이 필요하지 않습니다(5장, 흐름마다 레코드 유형 하나). 마스터 밖에서 레코드를 만드는 것은 허용할 수 있지만, 편집은 지켜보십시오.

시험 너머: AI가 바꾸는 것. 고객이 에이전트에게 “청구 주소를 125 Main Street로 바꿔 주세요”라고 말합니다. 필드는 Salesforce에 바로 있습니다. 에이전트가 그걸 갱신해야 할까요? ERP가 소유한다면 아닙니다. 에이전트에게는 필드 접근만이 아니라 쓰기 권한 원천이 필요합니다. 그 액션은 승인된 경로를 담아야 합니다. 변경 요청을 제출하고 “변경 요청을 처리하도록 제출했습니다”라고 말해야지, “청구 주소를 갱신했습니다”라고 거짓으로 보고해서는 안 됩니다.

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

• Salesforce에서의 편집이 권위 있는 데이터를 바꾸는지, 아니면 그것을 소유한 시스템에 변경을 요청하는지.
• 양방향 흐름이 일으킨 변경과 메아리를 어떻게 구별하고, 거절, 충돌, 지연, 장애를 어떻게 처리하는지.
• 각 계층을 누가 소유하는지, 필요하면 가지별로.
• 여러 ERP에 있는 고객 하나를 무엇으로 나타낼지: 계층, 동등 계정, 또는 ERP마다 하위 레코드를 둔 계정 하나. 고객사가 ERP들을 얼마나 잘 동기화하는지가 기준이다.
• 경쟁하는 계층들이 실은 서로 다른 정당한 관계인지: 법적, 청구, 영업, 서비스.
• 권한 원천의 경계와 승인된 쓰기 경로를 사용자, 통합, 개발자, 에이전트에게 어떻게 보이게 하는지.

공유된 권한 원천이 문제가 아닙니다. 모호한 권한 원천이 문제입니다. 여러 ERP가 서로 다른 가지의 마스터가 될 수 있고, Salesforce는 일부 속성의 마스터가 되면서 다른 속성은 변경을 요청할 수 있고, 여러 계층이 한 기업을 설명할 수 있습니다. 중요한 속성과 관계마다 누가 소유하는지, 누가 바꿀 수 있는지, 권위 있는 변경이 어디서 이루어지는지, 시스템들이 서로 다를 때 무슨 일이 일어나는지 말할 수 있는 한, 그 모든 게 잘 작동합니다. 말할 수 없다면, 다이어그램에 양방향 화살표를 하나 더 그려도 해결되지 않습니다.

더 알아보기

• Salesforce 도움말, Considerations for Using Account Hierarchy (opens in a new tab)(영어), 확인일 2026-10-14.