나쁜 데이터 막기

🌐 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 과정 5장인 데이터 품질과 거버넌스의 모듈 2/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 거버넌스는 org 안에 설계된다 · 다음: 데이터를 알라

이 모듈이 답하는 질문: 데이터를 어떻게 좋게 만들고, 계속 좋게 유지할까요?

나쁜 데이터를 다루는 방법은 두 가지입니다. 들어오기 전에 막거나, 나중에 정리하거나. 둘 다 조금씩 하게 됩니다. 하지만 고를 수 있다면 저는 문제를 영원히 정리하는 조직을 만들기보다 문제를 예방하겠습니다. 중복, 잘못된 식별자, 빠진 정보, 비표준 값, 다른 시스템이 소유한 필드를 바꾸는 사용자, 좋은 데이터를 나쁜 데이터로 덮어쓰는 연동. 모두 누군가의 정리 프로젝트가 됩니다. 그래서 설계 질문은 **애초에 어떤 나쁜 데이터를 합리적으로 막을 수 있는가?**입니다. 그리고 “합리적으로”가 중요합니다. 답은 시스템을 쓸 수 없을 때까지 모든 필드를 잠그는 것이 아니니까요.

충분히 좋음은 비즈니스가 정의한다

나쁜 데이터를 막기 전에 좋은 데이터를 정의하십시오. 정의는 하나가 아닙니다. 좋다는 것은 프로세스를 돌릴 만큼 완전하고, 결정을 내릴 만큼 정확하고, 워크로드에 맞을 만큼 최신이고, 다른 시스템과 합칠 만큼 일관되고, 어느 고객인지 알 만큼 고유하고, 자동화에 쓸 만큼 표준적이고, 어디서 왔는지 알 만큼 추적 가능하다는 뜻일 수 있습니다. 데이터에 따라 다릅니다. Steve Trucking이 리테일 파트너에게 청구한다면 파트너의 법적 정체성은 맞아야 합니다. 영업 담당자가 회의 뒤 메모를 적는다면 문장마다 승인하는 위원회는 아무도 필요 없습니다. 충분히 좋음은 비즈니스가 정의하고, 아키텍트는 그것을 측정 가능하고 시행 가능하게 만듭니다.

비용이 큰 오류를 막아라

모든 잘못된 필드가 같은 주의를 받을 가치가 있지는 않습니다. 저는 하류에 결과를 남기는 오류에 가장 신경 씁니다. 중복 고객은 판매 이력 둘, 서비스 이력 둘, 연락처 묶음 둘, 외부 ID 둘, 같은 회사를 동기화하는 연동 둘, 웨어하우스와 Data 360의 버전 둘, 그리고 결국 어느 고객이 진짜인지 정하는 에이전트를 뜻합니다. 설명란의 오타보다 훨씬 비쌉니다. 그러니 “모든 필드를 어떻게 검증하지?”로 시작하지 마십시오. **어떤 나쁜 데이터가 가장 큰 비즈니스 또는 아키텍처 문제를 만드는가?**로 시작하고, 가장 강한 통제를 거기에 두십시오.

열 것인가, 잠글 것인가?

계정 생성이 고전적인 예입니다. 모든 영업 담당자가 계정을 만들 수 있어야 할까요? 제 답은 데이터를 둘러싼 거버넌스에 달려 있다입니다. 대부분의 중소 org에서는 열린 생성이 괜찮습니다. 영업 담당자가 잠재 고객을 만나 계정을 만들고 일을 시작합니다. 그게 CRM의 용도입니다. 중복 규칙, 필수 정보, 스튜어드십이 품질을 관리합니다. 거버넌스가 책임감 있게 들린다는 이유로 무거운 승인 프로세스를 더하지 않습니다.

이제 랜드스케이프를 바꿔 보십시오. 법적 고객이 ERP에서 마스터로 관리되고, ERP 식별자와 함께 Salesforce로 들어오며, ERP가 권위 있습니다. 이제 열린 생성은 같은 관리 대상 엔터티를 만드는 길이 둘이라는 뜻입니다. ERP와 영업 담당자가 같은 회사를 각각 만들면, 어느 쪽이 이기고, 연동은 어느 식별자를 쓰고, 어느 레코드가 이력을 가질까요? 열린 생성은 사용성 질문이기를 멈추고 마스터 데이터 질문이 됩니다. 계정이 ERP에서 마스터로 관리되거나 ERP와 동기화된다면 생성을 잠그십시오.

하지만 완전히 잠그는 것도 실패합니다. 영업 담당자가 ERP에 없는 잠재 고객을 만나 기회를 열고 싶은데, 거버넌스 모델이 “계정은 안 돼요”라고 합니다. 그래서 재무를 사흘 기다리거나, 기회를 엉뚱한 계정에 붙이거나, 잠재 고객을 메모 필드나 스프레드시트에 둡니다. 데이터 모델은 지켰고 비즈니스는 망쳤습니다.

중간 길: 임시 레코드 유형

제가 좋아하는 중간 길이 있습니다. 영업이 특정 레코드 유형, 즉 잠재 고객용 또는 임시 유형으로 계정을 만들게 하고, 관리되는 유형으로의 전환을 통제하라. 영업은 회사를 기록하고 판매를 시작합니다. 레코드는 분명히 말합니다. 아직 권위 있는 시스템에서 확정되지 않았다고. 그다음 통제된 프로세스가 그것을 전환합니다. 재무가 승인하거나, 연동이 ERP에 제출하고, ERP가 기존 고객과 매칭하거나 새 고객을 만들어 권위 있는 식별자를 돌려보냅니다. 이제 레코드는 임시 → 관리됨이라는 경계를 넘고, 이는 두 시스템이 각자 마스터 레코드라고 믿는 것을 만드는 것과 매우 다릅니다.

레코드 유형이 제가 가르치는 메커니즘입니다. 무엇을 쓰든 상태를 데이터에서 보이게 하십시오. 레코드가 어디서 왔는지, 경계를 넘었는지, 지금 누가 바꿀 수 있는지, 그리고 그것을 권위 있는 시스템에 묶는 식별자. 전환 뒤에만 존재하는 ERP 고객 ID가 그중 가장 분명한 신호입니다.

흐름마다 레코드 유형 하나

흐름 전체를 그림 한 장에 올려 보면 이것이 왜 통하는지 보입니다. 고객과 제품은 ERP에서 들어옵니다. 기회와 그 품목은 나가서 ERP의 주문이 됩니다. 그럼 계정은요? 일부는 들어오고, 일부는 나갑니다. 그래서 제가 여러 구현에서 본 흔한 패턴은 계정에 방향마다 하나씩, 레코드 유형을 두 개 두는 것입니다. Sales 계정은 Salesforce에서 태어납니다. 영업 담당자가 만들고, 편집하고, 판매하고, 고객이 되면 ERP로 내보내집니다. ERP 계정(저는 Customer, 또는 그냥 SAP라고 불렀습니다)은 ERP에서 태어나 연동을 통해 들어옵니다. 연동 말고는 아무도 그 레코드 유형을 만들지 않고, 그 마스터 데이터 필드(법적 이름, 주소, 지불 조건)는 사용자에게 읽기 전용입니다. 레코드 유형이 레코드가 어느 쪽으로 흐르는지 알려 주니, 마스터 관리의 방향이 레코드에 바로 드러납니다.

Click to enlarge

흐름마다 레코드 유형 하나: Sales 계정은 나가고, ERP 계정은 들어옵니다.

그래도 어려운 경우가 사라지지는 않습니다. 영업 담당자가 Steve’s Plumbing 리드를 전환하는데, Steve’s Plumbing은 이미 ERP 계정으로 있고, 어째서인지 중복 검사가 그것을 잡지 못했습니다. 이제 병합하고, 하위 레코드의 상위 레코드를 재지정하고, 어느 레코드가 살아남을지 정해야 합니다(6장 모듈 3).

그리고 레코드 유형 자체에 매달리지 마십시오. 저는 보통 강한 이유가 없으면 레코드 유형을 피합니다. 여기서 쓴 것은 Dynamic Forms 이전에는 레코드 유형이 페이지 레이아웃을 골랐고, 한 레이아웃이 ERP 필드를 읽기 전용으로 보여 줬기 때문입니다. Dynamic Forms에서는 가시성 규칙이 필드 값에 따라 필드를 보이고 숨길 수 있고, 필드를 특정 페이지에서 읽기 전용으로 만들 수 있으며, Salesforce 스스로도 Dynamic Forms가 필요한 페이지 레이아웃과 레코드 유형의 수를 줄여 준다고 말합니다(Break Up Your Record Details with Dynamic Forms (opens in a new tab), Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). 하지만 페이지에서 읽기 전용은 그 페이지에서만 읽기 전용입니다. API, 데이터 로드, 연동은 여전히 그 필드에 쓸 수 있습니다. 진짜 시행은 필드 수준 보안이나 유효성 규칙입니다. UI 검증은 데이터 검증이 아닙니다(3장 모듈 9). 두 종류의 계정에 서로 다른 선택 목록 값이나 비즈니스 프로세스가 필요할 때는 레코드 유형이 여전히 제 몫을 합니다. 정말 중요한 것은 어떤 필드가 레코드가 어디서 왔는지 분명히 말해 주는 것입니다. ERP 키 자체, 마스터 데이터 플래그, 또는 원천 선택 목록. 그다음 그 필드로 편집 가능 여부를 정하십시오.

Click to enlarge

임시에서 관리됨으로: 영업은 바로 판매를 시작하고, 기준 프로세스만이 레코드를 관리되는 상태로 만듭니다.

관리되는 레코드를 보호하라

고객이 ERP에서 돌아오면 ERP ID, 법적 이름, 세금 식별자, 청구 정보는 관리되는 속성입니다. 영업 담당자가 그것을 바꿔야 할까요? ERP가 소유한다면 아닙니다. 모듈 1의 정책이 시행 지점을 필요로 하는 것입니다. ERP ID는 읽기 전용, 법적 정체성은 통제되고, 영업 담당자는 여전히 영역, 관계 메모, Salesforce 자체 분류를 편집합니다. 목표는 손댈 수 없는 계정이 아닙니다. Salesforce가 소유한 데이터와 Salesforce가 참조하는 데이터 사이의 분명한 선입니다. (4장의 erp_ 접두사가 그 선을 스키마에서 보이게 합니다.)

결국 얻는 것은 사실상 하이브리드인 골든 레코드입니다. ERP의 마스터 데이터 필드가 들어옵니다. 법적 이름, 청구 주소와 배송 주소, 지불 조건. 그다음 Salesforce가 절대 돌아가지 않는 자체 필드를 더합니다. 영업 등급, 마지막 주문일, 마케팅이 쓰는 거의 모든 것. 같은 계정, 두 종류의 필드, 그리고 종류마다 원천은 하나입니다.

가장 어려운 것은 양방향 연동입니다. 영업 담당자가 ERP의 법적 이름을 Steve’s Plumbing에서 Steve’s Plumbing LLC로 바꿔야 한다고 합시다. 바로 그 5분 사이에 ERP의 누군가가 그것을 Steve’s Plumbing L.L.C.로 바꿉니다. 누구의 변경이 이길까요? 사고방식은 이렇습니다. 필드가 ERP에서 마스터로 관리된다면 필드를 바꾸는 게 아니라 바꿔 달라고 요청하는 것입니다. 요청이 충돌하면 어떻게 될지 정하십시오. ERP가 이기거나, 그사이 값이 바뀌었으면 요청을 거부하거나, 사람이 해결할 때까지 기다립니다. 그리고 관련 필드를 하나의 변경으로 함께 보낼지, 하나씩 보낼지도 정하십시오. 6장에서 충돌을 더 깊이 다룹니다(루프와 충돌).

문 앞에서 중복을 막아라

중복은 불어납니다. 만들어지기 전에 잡으면 작은 문제입니다. 2년 뒤 기회, 케이스, 연락처, 청구서, 연동, 분석이 양쪽에 매달린 채 발견하면 큰 문제입니다. 3장 모듈 7에서 메커니즘(일치 규칙, 중복 규칙, 고유 외부 ID)을 다뤘으니 다시 가르치지 않겠습니다. 거버넌스 질문은 **어디서 중복을 막아야 하고, 어디서 용인했다가 나중에 해결할 것인가?**입니다. 가벼운 마케팅 리드는 모호함과 함께 살 수 있습니다. 재무 트랜잭션이 있는 ERP 관리 고객은 그럴 수 없습니다.

기계가 읽는 것을 표준화하라

자유 텍스트는 사람에게는 훌륭하고, 시스템이 해석해야 할 때는 끔찍합니다. 경로 배정을 이끄는 필드에 Arizona, AZ, Ariz., Phoenix area, Southwest를 넣으면 품질 문제가 생깁니다. 값이 자동화, 연동, 보고, 보안, 배정, 에이전트의 행동을 이끈다면 얼마나 표준적이어야 하는지 깊이 생각하십시오. 모든 텍스트 필드가 선택 목록이 되지는 않지만, 사람이 읽는 정보와 기계가 그것으로 결정하는 정보를 구분하십시오. 후자는 더 강한 통제를 받을 가치가 있습니다.

필수 필드가 가짜 데이터를 만들게 두지 마라

어떤 필드가 중요하다고 정하고 필수로 만듭니다. 사용자는 답을 모르고, 시스템은 넘어가지 못하게 하니 N/A, Unknown, 999999, test@test.com을 입력합니다. 필드는 채워졌고 데이터는 쓰레기입니다. 무언가를 필수로 만들기 전에 사용자가 그 시점에 정말 그것을 아는지 물으십시오. 모른다면 프로세스 후반에 필수로 하거나, 다른 시스템이 공급하게 하거나, 임시 상태를 쓰거나, 모른다는 것이 정당한 답일 때는 명시적인 알 수 없음을 제공하십시오. 유효성 규칙은 정책을 시행할 수 있습니다. 모르는 것을 알게 할 수는 없습니다.

모든 데이터 경계에는 품질 결정이 필요하다

나쁜 데이터의 원천은 사람만이 아닙니다. 연동은 더 빨리 만듭니다. 리테일 파트너의 배송 목록이 몇백 줄로 도착합니다. 몇 줄은 우편번호가 잘못되었고, 두어 줄은 알 수 없는 물류 센터를 가리키고, 두 줄은 같은 주문 참조를 반복합니다. 어떻게 할까요? 파일 전체를 거부? 좋은 줄은 받고 나쁜 줄은 돌려보내기? 전부 적재하고 나중에 정리? 예외를 격리? 누구에게 알리고, 파트너는 무엇이 실패했는지 어떻게 알까요? 보편적인 답은 없지만, 답은 있어야 합니다. 4장은 모든 화살표에 메커니즘이 필요하다고 했습니다. 하나 더하십시오. 모든 데이터 경계에는 품질 결정이 필요하다. 무엇을 받고, 거부하고, 격리할지, 그리고 예외를 누가 책임질지.

Click to enlarge

모든 데이터 경계에는 품질 결정이 필요합니다.

과거 데이터는 다르다

RouteDesk에는 Steve Trucking의 8년치 이력이 있고, 품질은 물류 센터마다 다릅니다. 옮기기 전에 8년치 전부를 오늘의 기준으로 정리해야 할까요? 자동으로는 아마 아닙니다. 무엇에 쓰입니까? 일상 운영, 참조, 클레임, 보고, 추세 분석? 전부 Salesforce에 있어야 하나요, 일부는 다른 곳에 있어도 되나요? 마이그레이션 장에서 깊이 다룹니다. 거버넌스 요점은 이것입니다. 이력이 자동으로 활성 데이터와 같은 기준을 필요로 하지는 않습니다. 그것으로 결정을 내린다면 품질이 중요합니다. 참조용으로 보관한다면 다른 기준으로 충분할 수 있습니다. 과거를 정리하는 데 큰돈을 쓰기 전에 목적을 아십시오.

누군가 행동할 것을 측정하라

거버넌스는 결코 끝나지 않으니, 품질이 미끄러지는 때를 봐야 합니다. 중복률 상승, 격리된 레코드 증가, 연동 거부 증가, 자리표시자 값의 확산, 우회 요청 증가, 더 이상 맞지 않는 보고서. 하지만 지표 150개를 만들고 143개를 무시하지는 마십시오. Steve Trucking이라면 유효한 파트너 참조가 없는 배송, 쓸 수 있는 주소가 없는 배송, 반복된 주문 참조, 거부된 파트너 메시지, 임시 상태에 머문 계정일 수 있습니다. 초록 원으로 가득한 대시보드가 데이터가 좋다는 뜻은 아닙니다. 누군가 행동할 준비가 된 것을 측정하십시오.

시험 너머: AI가 바꾸는 것. 나쁜 데이터는 점점 나쁜 행동이 됩니다. 사람은 전화를 걸기 전에 번호가 이상해 보인다는 걸 알아챌 수 있지만, 에이전트는 받은 값을 그냥 씁니다. 중복 고객, 오래된 상태, 가짜 필수 값, 잘못된 식별자는 곧장 잘못된 메시지나 잘못된 갱신이 됩니다. 그래서 예방의 가치가 올라갑니다. 스튜어드십의 필요가 사라지지는 않습니다.

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

• 어떤 품질 실패가 예방 통제를 정당화할 만큼 해로운지.
• 관리되는 레코드를 자유롭게 만들지, 권위 있는 시스템만 만들게 할지, 임시에서 관리됨으로 가는 경로를 거치게 할지.
• Salesforce가 어떤 속성을 소유하고, 어떤 속성은 참조만 하는지.
• 검사를 통과하지 못한 유입 데이터를 어떻게 할지(받기, 거부, 격리), 그리고 예외를 누가 책임질지.
• 스튜어드가 미끄러짐을 볼 수 있도록 어떤 품질 신호를 측정할지.

나쁜 레코드를 전부 막을 수는 없습니다. 일은 완벽한 데이터가 아니라 피할 수 있는 나쁜 데이터가 비싼 데이터가 되지 않게 하는 것입니다. 2년치 이력이 쌓이기 전에 중복을 막으십시오. 연동 열 개가 잘못된 식별자에 의존하기 전에 식별자를 보호하십시오. 영업이 잠재 고객을 만들게 하되, 관리되는 고객이 될 때까지는 그런 척하지 마십시오. 그리고 나쁜 것이 통과했을 때 누군가 그것을 보고, 맡고, 고칠 수 있게 하십시오.

더 알아보기

• Salesforce 도움말, Things to Know About Duplicate Rules (opens in a new tab)(영어), 확인일 2026-10-14.
• Salesforce 도움말, Break Up Your Record Details with Dynamic Forms (opens in a new tab), Required and Read-Only Fields in Dynamic Forms (opens in a new tab)(영어), 확인일 2026-10-14.