용어 사전, 계보, 분류

🌐 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장인 데이터 품질과 거버넌스의 모듈 3/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 나쁜 데이터 막기 · 다음: 개인정보 보호법이 설계를 형성한다

이 모듈이 답하는 질문: 데이터가 무엇을 뜻하는지, 어디서 왔는지, 얼마나 민감한지 어떻게 기록할까요?

org를 물려받았습니다. 계정에 필드가 900개 있고, 그중 Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c, Account_Status__c가 있습니다. 누군가 실제로 고객인지 알려 주는 것은 어느 것일까요? 설명을 엽니다. 셋은 비어 있습니다. 하나는 “Customer Type”이라고 쓰여 있습니다. 고맙네요. 하나는 ERP에서 왔다고 하고, 또 하나는 6년 전 이미 떠난 사람이 만들었습니다. 이제 당신이 아키텍트가 아니라 연동, 보고 팀, 에이전트라고 상상해 보십시오. 조직에는 데이터가 많습니다. 그렇다고 데이터가 무엇을 뜻하는지 아는 것은 아닙니다.

여기서 메타데이터가 아키텍처가 됩니다. 서로 관련 있지만 같지는 않은 세 질문을 통해서입니다.

• 용어 사전: 이 데이터는 무엇을 뜻하는가?
• 계보: 어디서 왔는가?
• 분류: 어떻게 다뤄야 하는가?

두 종류의 메타데이터

메타데이터는 두 종류가 있고, 둘 다 필요합니다. 비즈니스 메타데이터는 데이터가 비즈니스에 무엇을 뜻하는지입니다. 정의, 오너, 사용 규칙, 민감도. 기술 메타데이터는 그것이 어떻게 만들어지고 이동하는지입니다. 개체와 필드, 유형과 길이, API 이름, 스키마, 한 시스템에서 다른 시스템으로의 매핑, 원천에서 대상까지의 계보. 필드의 API 이름과 유형은 개발자에게 그것을 어떻게 쓰는지 알려 주고, 정의와 오너는 나머지 모두에게 그것을 써도 되는지 알려 줍니다. 둘이 어긋나거나 하나가 빠진 곳에서 연동과 보고서가 잘못됩니다.

시험 포인트. 비즈니스 메타데이터(의미, 정의, 오너, 규칙, 민감도: 비즈니스 용어 사전과 분류)와 기술 메타데이터(개체, 필드, 유형, API 이름, 스키마, 매핑, 계보)를 구분하십시오.

의미에서 시작하라

3장이 규칙을 정했습니다. 모든 필드에 설명을 단다. Customer Status라는 필드에 “Customer Status”가 아니라, “파트너와 Steve Trucking의 현재 상거래 관계. 활성화 뒤 ERP가 설정. 잠재 고객 평가에는 쓰지 말 것.” 같은 것입니다. 이제 무엇을 뜻하는지, 어디서 오는지, 무엇에 쓰지 말아야 하는지 압니다. 그것이 비즈니스 용어 사전의 시작입니다. 중요한 데이터에 대한 공통 정의. 고객이란? 활성 고객이란? 배송 완료는 무슨 뜻인가? 무엇이 정시인가? 다섯 부서를 한 방에 모으기 전까지는 뻔해 보입니다. 재무에 정의가 하나, 영업에 또 하나, 운영에 세 번째, 웨어하우스에 네 번째가 있고, 누군가 다섯 번째로 대시보드를 만들었습니다. 문제는 아무도 같은 말을 못 해서가 아닙니다. 기업이 의미에 합의하지 않은 것입니다.

용어 사전은 스프레드시트나 문서 도구에 있을 수 있지만, 중요한 정의는 사람들이 데이터를 쓰는 곳 가까이 있어야 합니다. 플랫폼에서는 필드 설명, 도움말 텍스트, 분류 메타데이터입니다. 분석에서는 더 중요합니다. “매출”이 경영 대시보드에서 하나를, 분석가의 쿼리에서 다른 것을 뜻해서는 안 됩니다. 그것이 시맨틱 레이어의 용도이며, Data 360의 시맨틱 모델은 지표, 차원, 관계 같은 관리되는 정의를 물리 데이터 위에 둡니다(Create a Semantic Model in Data 360 (opens in a new tab)). 기술은 바뀌지만 요구사항은 바뀌지 않습니다. 중요한 데이터에는 합의된 의미가 필요합니다.

그리고 기술이 아니라 의미에서 시작하십시오. 개체, 필드, 유형, API 이름으로 시작하는 용어 사전은 구현을 문서화합니다. 비즈니스 용어로 시작하는 용어 사전은 기업을 문서화합니다.

비즈니스 용어	의미	표현되는 곳
리테일 파트너	계약에 따라 Steve Trucking이 배송해 주는 유통업체	Salesforce 계정, 재무 ERP 고객
배송	한 수령인에게, 한 주소로, 하루에 하는 배송 한 건	지금은 RouteDesk, 배송이 Salesforce로 옮겨 오면 작업 주문
수령인	배송을 받는 사람	배송에 담긴 수령인 정보
배송 완료	합의된 운영 정의에 따라 완료됨	배송 상태
정시 배송	합의된 배송 시간대 안에 완료됨	파생 지표

Click to enlarge

하나의 의미, 여러 기술적 표현.

그다음 어디서 왔는지 물어라

값이 무엇을 뜻하는지 알면, 저는 어디서 왔는지 알고 싶습니다. 그것이 계보입니다. Salesforce에 있는 파트너의 법적 이름. 영업 담당자가 입력했나, ERP가 보냈나, 연동이 변환했나, Data 360이 통합했나, 계산됐나, AI가 생성했나? 그것이 내가 그 값을 얼마나 믿고 무엇을 해도 되는지에 영향을 줍니다. 모듈 2의 임시 레코드를 기억하십시오. 두 계정이 모두 “Keystone”이라고 할 수 있습니다. 하나는 어제 영업 담당자가 만들었고, 다른 하나는 권위 있는 식별자와 함께 ERP에서 왔습니다. 같은 텍스트, 다른 계보, 다른 대우.

계보는 데이터 엔지니어가 그린 테이블 천 개짜리 다이어그램만이 아닙니다. 중요한 데이터에 대해 저는 실용적인 질문에 답하고 싶습니다. 어디서 시작했나, 어느 시스템이 권위 있나, 무엇이 변환했나, 어느 시스템이 사본을 받았나, 마지막으로 무엇이 바꿨나, 파생 값을 원천까지 추적할 수 있나? 4장의 랜드스케이프는 시스템들이 연결되어 있다고 말합니다. 계보는 그 길에서 데이터에 무슨 일이 일어났는지 말합니다.

일부 계보는 공짜로 옵니다. 계정의 ERP ID, 생성자와 최종 수정자, 연동 로그, 매핑 문서. Data 360은 데이터 개체에 레코드마다 데이터 원천과 원천 개체를 기록하는 계보 필드를 더합니다(Data Lineage Fields (opens in a new tab)). 하지만 시스템이 연동되어 있다고 계보가 나타나리라 가정하지 마십시오. 때로 가장 유용한 계보는 필드 하나입니다. 원천 시스템 = Keystone. 그리고 출처가 거버넌스에 중요하다면, 사람이 입력하는 게 아니라 연동이 설정하도록 기계적으로 믿을 만하게 만드십시오.

계보가 가장 필요한 것은 파생 데이터입니다. Steve Trucking이 트럭 위치, 배송 시간대, 경로 이력으로 배송 지연 위험을 계산하고, 배차가 그것으로 우선순위를 정한다고 합시다. “높음”은 어디서 왔을까요? 수령인에게 “배송이 늦어지고 있습니다”라고 말하는 에이전트를 더하면, 무엇이 그 말의 근거였고 얼마나 최신이었는지 알아야 합니다. 저장된 값에서 계산되고, 통합되고, 예측되고, 생성된 값으로 멀어질수록 계보가 더 중요해집니다.

분류는 다른 질문에 답한다

이제 어떻게 다뤄야 하는가? 수령인 이름, 배송 주소, 전화번호, 배송 메모, 배송 상태, 트럭 번호, 물류 센터, 리테일 파트너, 사진. 민감도가 같지 않습니다. “배송 중”은 전화번호가 아니고, 물류 센터 코드는 누군가의 집 안을 찍은 사진이 아닙니다. Salesforce는 표준이든 사용자 정의든 필드마다 이것을 기록하게 해 줍니다. Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization(Data Classification Metadata Fields (opens in a new tab)). 3장은 그것을 분류 체계 필드라고 부르고, 왜 중요한지도 말했습니다. 필드에 PII나 GDPR 표시를 하면 마스킹 도구부터 대규모 언어 모델에 표시된 값이 닿지 않게 막을 수 있는 Salesforce의 AI 트러스트 레이어까지, 여러 프로세스가 그 필드를 찾을 수 있습니다. 3장의 주의 하나: Salesforce는 이제 에이전트에 대해서는 그 LLM 마스킹을 끕니다. 에이전트에 필요한 맥락까지 지워 버릴 수 있기 때문입니다(중요한 것을 분류하라: 분류 체계 필드). 그러니 분류는 여전히 다른 통제들을 움직여야 합니다.

여기서 제 입장은 의도적입니다. 모든 필드가 아니라 민감한 필드를 분류하라. 누군가 “100% 분류 완료”를 보고하려고 필드 수천 개를 석 달 동안 분류하고 아무도 그것을 쓰지 않기를 원하지 않습니다. 수령인의 전화번호, 예. 집 주소, 예. 대문 비밀번호와 “마당에 개 있음”이 담길 수 있는 배송 메모, 예. 사람이나 집이 찍힐 수 있는 사진, 당연히. 내부 표시용 레이블? 거버넌스의 에너지를 쓸 곳이 아닙니다. 문서화되지 않은 필드가 괜찮다는 뜻은 아닙니다. 서로 다른 두 가지 일입니다. 문서화는 넓게, 분류는 신중하게. 그것이 분류를 의미 있게 유지합니다.

사람들이 쓸 수 있는 분류 체계

분류에는 어휘, 즉 분류 체계가 필요합니다. Salesforce의 기본값은 Public, Internal, Confidential, Restricted, MissionCritical이고, 조직마다 자기 레이블을 원할 수 있습니다. 저는 그것을 처방하지 않습니다. 이해할 수 있게 유지하십시오. 범주가 47개이고 개인정보 팀 밖에서는 31번과 32번을 아무도 구분하지 못한다면 도움이 되지 않습니다. 좋은 분류 체계는 레이블을 동작에 연결합니다. 필드가 민감한 개인정보라면 누가 볼 수 있나, 샌드박스에 갈 수 있나, 지역을 벗어날 수 있나, 분석에 나타날 수 있나, 얼마나 오래 보관하나, 에이전트가 써도 되나? 이제 분류가 일을 하고 있습니다.

시행 없는 분류는 장식이다

수령인의 전화번호를 민감하다고 표시하고 다른 것은 아무것도 바꾸지 않으면, 문서를 쓴 것입니다. 유용하지만, 거버넌스는 더 나아갑니다. 분류는 권한, 마스킹, 암호화, 보존, 동의, 데이터 이동, 샌드박스 사용, 감사, AI 접근을 이끌어야 합니다. 그중 일부는 아키텍트의 설계 결정이고, 일부 플랫폼은 이제 Data 360 거버넌스처럼 태그와 분류를 정책에 직접 적용합니다(Data Governance in Data 360 (opens in a new tab)). 그리고 필드를 Restricted로 표시한다고 누군가 그것을 읽는 걸 막지는 못합니다. 분류는 필드를 어떻게 다뤄야 하는지 말하고, 보안이 그렇게 되게 만듭니다. 순서는 이렇습니다. 데이터를 식별하고, 이해하고, 중요한 것을 분류한 다음, 그 분류가 요구하는 통제를 적용합니다.

Click to enlarge

데이터에 관한 세 가지 질문, 그리고 세 번째 질문은 무언가를 움직여야 합니다.

참조 데이터에도 메타데이터가 필요하다

국가 코드, 배송 상태, 물류 센터 코드, 파트너 식별자, 취소 사유. 두 시스템이 다르기 전까지는 단순해 보입니다. 하나는 CANCELLED, 다른 하나는 CANCELED, 세 번째는 CNCL, 네 번째는 9라고 합니다. 참조 데이터에는 정의, 오너, 원천, 값이 바뀌는 경우의 생명주기, 그리고 시스템마다 다르게 표현할 때의 매핑이 필요합니다. 작은 값이 아주 큰 프로세스를 이끌 수 있습니다. 6장에서 더 다룹니다.

셋을 함께

수령인 전화번호를 보십시오. 용어 사전: 특정 배송을 받는 사람에게 연락하는 데 쓰는 번호. 계보: 리테일 파트너의 배송 목록에서 옴. 분류: 개인정보. 이제 아키텍처 질문이 가능해집니다. 배송팀이 볼 수 있나, 얼마나 오래(브리프는 자기 정차지에 대해서만, 그날에만이라고 합니다), 샌드박스에 갈 수 있나, Snowflake에 필요한가, 에이전트가 써도 되나, 배송이 끝나면 어떻게 되나?

이제 배송 상태를 보십시오. 용어 사전: 배송의 현재 운영 상태. 계보: Steve Trucking의 배송 프로세스가 설정하고 각 파트너에게 그쪽 연동으로 돌려보냄. 분류: 운영, 민감하지 않음. 다른 데이터, 다른 대우. 그것이 요점입니다.

저는 메타데이터를 진짜 아키텍처가 끝난 뒤 만드는 문서로 다루지 않습니다. 필드가 무엇을 뜻하는지 말할 수 없다면 데이터 모델을 이해하지 못한 것입니다. 값이 어디서 왔는지 모른다면 연동을 이해하지 못한 것입니다. 민감한지 모른다면 보안을 이해하지 못한 것입니다. 메타데이터는 아키텍처를 기술하고, 때로는 이끕니다.

시험 너머: AI가 바꾸는 것. 분류는 에이전트가 무엇을 가져오거나 되풀이해도 되는지의 스위치가 되어 가고 있고, 계보는 에이전트의 답이나 행동까지 닿아야 합니다. 에이전트가 수령인에게 배송이 늦는다고 말한다면, 아키텍처는 무엇이 그 근거였는지, 어디서 왔는지, 에이전트가 그것을 써도 됐는지 말할 수 있어야 합니다. “Salesforce 어딘가”는 계보가 아니고, “고객 데이터”는 분류가 아닙니다.

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

• 시스템과 팀이 한 단어에 다른 의미를 주지 않도록, 어떤 비즈니스 용어에 관리되는 정의가 필요한지.
• 중요한 값이 원천, 권위, 변환을 보여 줄 만큼 계보를 어떻게 유지하는지.
• 어떤 필드가 민감도나 규정 준수의 의미를 가져 명시적 분류를 받는지.
• 조직이 어떤 분류 체계를 쓰며, 사람들이 그것을 일관되게 적용할 수 있는지.
• 분류가 쓰이지 않고 남는 대신 실제 통제를 어떻게 이끄는지.

데이터를 관리하기 전에 무엇을 가졌는지 아십시오. 무엇을 뜻하는지, 어디서 왔는지, 어떻게 다뤄야 하는지. 문서화는 넓게, 분류는 신중하게, 계보는 중요한 곳에. 그러지 않으면 데이터를 관리하는 게 아닙니다. 그냥 가지고 있을 뿐입니다.

더 알아보기

• Salesforce 도움말, Data Classification Metadata Fields (opens in a new tab)(영어), 확인일 2026-10-14.
• Salesforce 도움말, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab), Create a Semantic Model in Data 360 (opens in a new tab)(영어), 확인일 2026-10-14.