거버넌스는 org 안에 설계된다

🌐 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장인 데이터 품질과 거버넌스의 모듈 1/6. 각 모듈은 독립적으로 읽을 수 있습니다. 다음: 나쁜 데이터 막기

이 모듈이 답하는 질문: 아키텍트에게 데이터 거버넌스는 무엇을 뜻하며, 누가 무엇을 할까요?

사람들은 데이터 거버넌스라는 말을 들으면 회의를 떠올립니다. 위원회, 정책, 표준, 누가 데이터로 무엇을 해야 하는지 설명하는 문서. 그 모든 것이 거버넌스 프로그램의 일부일 수 있습니다. 아키텍트로서 저는 다른 질문에 관심이 있습니다. 정책은 어디서 시행되는가?

정책이 어떤 필드는 재무만 바꿀 수 있다고 한다면, 무엇이 그것을 시행합니까? ERP가 법적 고객 레코드를 소유한다고 한다면, Salesforce의 누군가가 그것을 바꾸는 걸 무엇이 막습니까? 배송팀은 수령인의 주소를 자기 정차지에 대해서만, 그날에만 본다고 한다면, 실제로 무엇이 그것을 사실로 만듭니까? 7년간 보관하라고 한다면, 7년 뒤 무엇이 그것을 보관하거나 지웁니까? 시행 지점이 없는 정책은 대개 희망 사항입니다. 거버넌스는 그런 결정이 시스템 안에 구축될 때 아키텍처가 됩니다.

거버넌스는 결코 끝나지 않는다

이것부터 짚고 가겠습니다. 거버넌스는 끝나지 않습니다. 저는 그것이 밀물과 썰물처럼 오가는 것을 봐 왔습니다. 회사가 데이터 품질에 진지하게 주의를 기울이면 상황이 나아집니다. 관심이 다른 데로 옮겨 가면 품질이 미끄러집니다. 새 연동이 가동되고, 사업부가 프로세스를 바꾸고, 누군가 파일을 가져오고, 회사가 다른 회사를 인수하고, 에이전트가 레코드를 쓰기 시작하면 문제가 다시 바뀝니다. 목표는 모든 레코드가 영원히 완벽한 신화 같은 상태가 아닙니다. 데이터를 비즈니스에 충분할 만큼 믿을 만하게 유지하고 최악의 나쁜 데이터를 막는 것입니다. 계속되는 일입니다.

Salesforce가 거의 혼자 있을 때 거버넌스는 한곳에서 데이터를 정리하는 것을 뜻합니다. 4장의 랜드스케이프의 한 노드일 때는 더 어렵고, 더 필요합니다. 이제 고객은 Salesforce, ERP, 웨어하우스, 파트너 시스템, Data 360에 있습니다. 누가 소유하나? 누가 바꿀 수 있나? 어느 사본이 권위 있나, 어떤 속성이 이동해도 되나, 얼마나 오래 보관하나, 틀렸을 때 누가 책임지나? 구성 질문이 아닙니다. 구성이 되는 거버넌스 질문입니다.

레코드 소유자는 데이터 오너가 아니다

소유자라는 말부터 시작하십시오. Salesforce가 그것을 헷갈리게 만드니까요. 계정을 열면 소유자가 보입니다. 이를테면 영업 담당자. 그 담당자가 고객 데이터를 소유할까요? 꼭 그렇지는 않습니다. Salesforce에서 소유자가 있는 개체의 레코드는 사용자나 대기열이 소유합니다. 소유자는 전체 접근 권한을 받고, 역할 계층과 공유 규칙을 통해 배정과 공유를 이끕니다(Sharing and Record Access Features (opens in a new tab)). 그것이 레코드 소유권, 플랫폼 메커니즘입니다.

데이터 오너는 다른 것입니다. 데이터를 비즈니스 자산으로서 책임지는 사람이나 조직입니다. 재무가 법적 고객 정보를, 운영이 배송 상태를, 인사가 직원 데이터를 책임질 수 있습니다. Salesforce는 그것을 기록할 곳도 줍니다. 필드마다 있는 Data Owner 분류 필드입니다(Data Classification Metadata Fields (opens in a new tab)).

Steve Trucking에서 리테일 파트너의 계정은 그 파트너를 관리하는 영업 임원이 소유할 수 있습니다. 하지만 파트너의 법적 정체성은 재무가 관리하고 재무 ERP에서 마스터로 관리됩니다. 영업, 서비스, 운영, 파트너 포털 모두 그 계정이 필요합니다. 그렇다고 재무가 확정한 파트너의 법적 정체성을 영업 임원이 바꿔야 한다는 뜻은 아닙니다. 저는 팀들이 소유자 필드를 보고 데이터 소유권을 해결했다고 여기는 걸 봐 왔습니다. 해결하지 않았습니다. 레코드 배정은 비즈니스 책임이 아닙니다.

오너, 스튜어드, 관리 담당자

거버넌스 역할 셋, 서로 다른 일 셋.

데이터 오너는 정책을 정합니다. 데이터가 무엇을 뜻하는지, 누가 만들고 바꿀 수 있는지, 얼마나 정확해야 하는지, 얼마나 오래 보관하는지, 누가 볼 수 있는지, 어느 시스템이 권위 있는지, 틀렸을 때 어떻게 되는지에 답합니다. 아키텍트가 그 답을 지어내서는 안 됩니다. 제 가장 확고한 입장 중 하나입니다. 오너는 정책을 정하고, 아키텍트는 그것을 시행한다. 고객이 활성화되면 법적 이름은 ERP 프로세스를 통해서만 바뀔 수 있다고 재무가 말한다면, 그것은 거버넌스 결정입니다. 그것을 기계적으로 사실로 만드는 것이 제 일입니다.

데이터 스튜어드는 그것이 계속 작동하게 합니다. 스튜어드는 데이터의 일상적인 건강 가까이에 있습니다. 품질 신호를 지켜보고, 중복을 조사하고, 예외를 해결하고, 수정을 조율하고, 정의를 유지하고, 계속 나쁜 데이터를 만들어 내는 프로세스를 찾아냅니다. 스튜어드에게는 일이 두 가지 더 있습니다. 두 팀이 필드의 뜻, 소유자, 볼 수 있는 사람을 두고 의견이 갈리면, 스튜어드가 그 분쟁을 오너에게 가져가고 결정이 실행될 때까지 챙깁니다. 그리고 스튜어드는 데이터 리터러시를 키웁니다. 데이터를 입력하고 쓰는 사람들이 그것이 무엇을 뜻하고 규칙이 왜 있는지 이해하도록 돕는 것입니다. 스튜어드에게는 조직도의 이름 이상이 필요합니다. 시간, 가시성, 프로세스, 그리고 문제를 고치게 할 권한. 그렇지 않으면 “데이터 스튜어드”는 누군가의 여덟 번째 업무가 되어 분기에 한 번 들여다보는 일이 됩니다.

관리 담당자는 시스템을 운영합니다. 관리자, 플랫폼 팀, 보안 팀. 데이터를 저장하고 처리하는 기술을 운영하는 누구든. 오너가 이 역할들만 볼 수 있다고 말하면, 관리 담당자가 그것을 사실로 만드는 통제를 운영합니다. 이름보다 각 책임을 분명히 하는 것이 중요하고, 작은 조직에서는 한 사람이 두 역할을 겸할 수도 있습니다.

프로그램은 어떻게 운영되는가

거버넌스 프로그램은 대개 세 가지 형태로 나타납니다. 중앙 집중형: 한 팀이 모든 도메인의 정책과 표준을 씁니다. 일관되지만, 실제로 일하는 사람들과 멀리 떨어진 병목이 될 수 있습니다. 연합형(분산형): 재무, 영업, 운영 같은 각 도메인이 몇 가지 공유 규칙 안에서 자기 데이터를 관리합니다. 일과 가깝지만, 도메인 사이에서 정의가 서로 멀어집니다. 하이브리드: 작은 중앙 팀이 표준과 공유 정의를 소유하고, 도메인 오너와 스튜어드가 자기 데이터를 운영합니다. 제가 본 대부분의 기업은 결국 하이브리드 어딘가에 자리 잡습니다. 아키텍트에게 이 형태는 실용적인 질문 하나에 답해 줍니다. 제가 정책을 시행하기 전에 누가 그것을 승인하고, 공유 정의는 어디에 있는가?

시험 포인트. 거버넌스 프로그램을 운영하는 세 가지 방식, 중앙 집중형, 연합형(분산형), 하이브리드를 알고, 각각이 누가 정책을 정하고 공유 정의가 어디에 있는지에 어떤 의미인지 알아 두십시오.

RACI가 제 몫을 하게 하라

RACI(누가 실행하고, 누가 책임지고, 누가 자문하고, 누가 통보받는가)는 도움이 되지만, 거버넌스가 “하나 있어야 한다”고 해서 만든 거대한 스프레드시트는 아닙니다. 저는 그것이 아키텍처 질문에 답하기를 원하고, 4장의 질문 셋(범주 뒤의 네 가지 질문)에서 시작합니다. 데이터는 어디서 만들어지고, 어디서 편집되고, 어디서 참조되는가? 흔히 서로 다른 시스템입니다. 제품을 보십시오. ERP가 만들고, Salesforce가 참조하고, 포털이 보여 주고, 웨어하우스가 분석합니다. 이제 비즈니스가 “활성 제품”의 뜻을 바꿉니다. 변경은 어디서 시작되고, 누가 승인하고, 어떻게 퍼지고, 어느 사본이 읽기 전용인가? 답할 수 없다면 아직 거버넌스가 없는 것입니다. 사본이 있을 뿐입니다. 좋은 RACI는 바로 그 모호함을 드러냅니다.

거버넌스는 기계적이 되어야 한다

비즈니스가 법적 고객명은 재무만 바꿀 수 있다고 합니다. 저는 아키텍처의 답이 “교육에서 다루겠습니다”이기를 원하지 않습니다. 교육은 도움이 되지만 시행이 아닙니다. 필드 수준 접근일 수도, 유효성 규칙일 수도, 연동만 쓰는 필드일 수도, 직접 편집 대신 통제된 프로세스일 수도 있습니다. 메커니즘은 요구사항에 달려 있지만, 반드시 하나는 있어야 합니다.

거버넌스 정책	결정하는 오너	가능한 시행 지점
ERP가 법적 고객 정체성을 소유한다	재무	연동 전용 필드, 권한, 유효성 검사
필요한 사람만 개인정보를 본다	개인정보, 보안	공유, 권한, 필드 접근
고객 식별자는 고유하다	비즈니스 오너	고유 외부 ID, 중복 규칙
관리되는 레코드는 수작업으로 만들지 않는다	데이터 오너	권한, 자동화, 연동
민감한 데이터에는 정해진 보존 기간이 있다	개인정보, 법무	보존 또는 삭제 프로세스
중요한 변경은 증명할 수 있어야 한다	규정 준수	필드 기록, 감사 추적
데이터의 출처는 식별 가능하게 남는다	데이터 오너	출처 필드, 계보 메타데이터

가능한 시행 지점이라고 일부러 말합니다. 기능 고르기 표가 아닙니다. 생각의 순서입니다. 정책은 무엇인가, 누가 소유하는가, 그리고 아키텍처의 무엇이 그것을 사실로 만드는가?

Click to enlarge

오너는 정책을 정하고, 아키텍트는 그것을 시행합니다.

좋은 행동에 기대지 마라

“ERP 고객 ID는 절대 바꾸지 마세요.” 모두가 압니다. 누군가 바꾸기 전까지는요. 실수로, 데이터 적재로, 자동화로, 연동으로, 에이전트로. 그것을 바꾸는 것이 기업 데이터를 망가뜨린다면, “제발 그러지 마세요”는 통제가 아닙니다. 통제를 만드십시오. 신뢰하되 검증하라. 사람, 연동, 자동화, AI 모두 실수하니, 아키텍처는 언젠가 무언가가 정책이 금지한 일을 시도하리라고 가정해야 합니다. 그러면 어떻게 되는가?

거버넌스는 시스템 경계를 넘는다

랜드스케이프로 돌아가십시오. ERP가 고객을 소유하고, Salesforce, 웨어하우스, 고객 데이터 플랫폼이 사본을 갖고, 파트너가 그 일부를 받습니다. 정책은 어느 시스템에 적용될까요? 전부입니다. Salesforce는 법적 이름 변경을 올바르게 막는데 연동이 하류 시스템에서 그것을 덮어쓰게 둘 수 있습니다. Salesforce는 웨어하우스가 아직 가진 개인정보를 지울 수 있습니다. Salesforce에서 민감하다고 분류된 필드가 다른 곳에서는 분류되지 않은 텍스트 필드에 들어갈 수 있습니다. 데이터가 org의 가장자리에서 멈추지 않으니 거버넌스도 거기서 멈출 수 없습니다. 그래서 4장이 먼저 왔습니다. 랜드스케이프가 거버넌스가 얼마나 멀리 닿아야 하는지 알려 줍니다.

모든 것이 아니라 충분히 관리하라

반대의 실패도 똑같이 실재합니다. 거버넌스가 중요하다는 걸 알고 나서 모든 것을 잠급니다. 아무도 만들 수 없고, 모든 변경에 승인이 필요합니다. 데이터는 관리되고, 아무도 일을 할 수 없습니다. 거버넌스는 데이터에 알맞은 통제를 뜻합니다. 어떤 것은 엄격하게, 어떤 것은 가볍게. 어떤 레코드는 자유롭게 만들 수 있고, 어떤 것은 승인이 필요합니다. 어떤 필드는 거의 누구나 편집할 수 있고, 어떤 것은 연동만. 다음 모듈이 바로 그것을 실무적으로 다룹니다.

그리고 거버넌스는 결코 끝나지 않으니, 시행에는 피드백이 필요합니다. 중복이 늘고 있나? 필수 필드가 쓰레기로 채워지고 있나? 연동이 실패하고, 사용자가 우회로를 찾고, 예외가 늘고, 스튜어드가 하루 종일 문제 하나에 매달리고 있나? 그 신호들이 설계가 작동하는지, 그리고 때로는 통제나 정책이 바뀌어야 한다는 걸 알려 줍니다.

시험 너머: AI가 바꾸는 것. 거버넌스에 새로운 소비자, 에이전트가 생겼습니다. 무엇을 무엇에 써도 되는지는 여전히 데이터 오너가 정하고, 그것을 시행 가능하게 만드는 것은 여전히 아키텍트입니다. 바뀌는 것은 속도와 규모입니다. 에이전트는 관리되는 데이터를 사람보다 훨씬 빠르게 읽고, 결합하고, 그것에 따라 행동하므로, 문서에만 있는 정책은 더욱 아무것도 지키지 못합니다.

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

• 중요한 각 데이터 영역을 누가 책임지며, 그것이 레코드 소유권과 어떻게 다른지.
• 누가 데이터의 스튜어드이고 누가 관리 담당자로서 운영하는지.
• 중요한 데이터가 랜드스케이프 전반에서 어디서 만들어지고, 편집되고, 참조되고, 마스터로 관리되는지.
• 어떤 시행 지점이 각 중요한 정책을 기계적으로 사실로 만드는지.
• 거버넌스가 작동하는지, 아니면 미끄러지기 시작하는지를 아키텍처가 어떻게 보여 주는지.

거버넌스 요구사항을 들으면 저는 그것을 번역합니다. “ERP가 이걸 소유한다.” “이 사람들만 이걸 볼 수 있다.” “누가 이걸 바꿨는지 증명해야 한다.” “이걸 7년간 보관하라.” 매번, 시행 지점을 보여 주십시오. 아키텍트는 정책을 정하지 않습니다. 그것을 시행하는 시스템을 설계합니다. 거버넌스가 문서이기를 멈추고 아키텍처가 되는 곳이 거기입니다.

더 알아보기

• Salesforce 도움말, Sharing and Record Access Features (opens in a new tab)(영어), 확인일 2026-10-14.
• Salesforce 도움말, Data Classification Metadata Fields (opens in a new tab)(영어), 확인일 2026-10-14.