데이터 스튜어드의 거버넌스 실무 가이드

잘 가꾼 정원과 방치된 정원은 한눈에 구분됩니다. 잘 가꾼 정원에는 화단마다 이름표가 붙어 있고 어떤 식물이 어디에 심겼는지 배치가 분명합니다. 반면 오래 손을 놓은 정원은 잡초가 화초를 덮고 구획의 경계가 흐릿해지며 언제 심었는지 모를 나무가 제멋대로 자라 있습니다.

데이터 거버넌스를 맡게 된 담당자가 마주하는 첫 장면도 이와 크게 다르지 않습니다. 새로 부임한 정원사가 이런 정원 앞에 서면 막막하기 마련입니다. 주인이 누구인지 알 수 없는 테이블, 부서마다 다르게 붙은 컬럼 이름, 몇 년 전에 만들어 놓고 아무도 열어 보지 않는 규정 문서가 뒤섞여 있습니다.
 

데이터 담당자를 흔히 데이터 스튜어드(Data Steward)라고 부릅니다. 스튜어드(steward)는 남의 살림이나 재산을 맡아 돌보는 청지기를 뜻하는 말입니다. 여기에 이 역할의 본질이 담겨 있습니다. 스튜어드는 데이터의 소유자가 아니라 데이터를 돌보는 사람입니다. 정원의 땅이 정원사 것이 아니듯, 데이터의 주인은 따로 있고 스튜어드는 그것이 잘 관리되도록 살피는 사람입니다. 이 글에서는 스튜어드가 데이터 거버넌스 체계를 처음 세우는 일과 그것을 오래 유지·운영하는 일을, 두 국면으로 나눠 짚어 보겠습니다.

데이터 스튜어드는 무엇을 맡는 사람인가

데이터 거버넌스에는 성격이 다른 세 역할이 함께 등장합니다. 데이터 오너(Data Owner), 데이터 스튜어드(Data Steward), 그리고 데이터 커스터디언(Data Custodian)입니다. 이름이 비슷해 보이지만 맡는 일은 뚜렷이 나뉩니다.

• 데이터 오너: 특정 데이터 영역에 대한 최종 책임과 의사결정 권한을 가진 사람입니다. 보통 해당 업무를 책임지는 현업 부서의 리더가 맡습니다. 이 데이터를 누구에게 공개할지, 어떤 정의를 표준으로 삼을지를 최종 승인합니다.
• 데이터 스튜어드: 오너가 정한 방향을 실제 관리 업무로 옮기는 실무 관리자입니다. 데이터의 정의를 정리하고 품질을 살피며 표준이 지켜지는지 점검합니다.
• 데이터 커스터디언: 데이터를 물리적으로 저장하고 운영하는 IT 담당자입니다. 데이터베이스를 관리하고 백업·접근 통제 같은 기술적 조치를 실행합니다.

쉽게 말해 소유와 책임 결정은 오너, 실무 관리는 스튜어드, 물리적 보관과 운영은 커스터디언이 나눠 맡습니다. 세 역할을 정원에 빗대면, 정원을 소유한 집주인이 오너, 날마다 돌보는 정원사가 스튜어드, 물과 도구를 대는 설비 담당이 커스터디언인 셈입니다.

여기서 스튜어드라는 자리의 특징이 드러납니다. 스튜어드는 강한 권한으로 일하는 자리가 아닙니다. 데이터를 마음대로 바꾸거나 폐기할 권한은 오너에게 있고 시스템을 손댈 권한은 커스터디언에게 있습니다. 스튜어드에게 남는 것은 책임과 조율입니다. "관리자라고 불리는데 정작 결정 권한은 없다"는 딜레마가 여기서 생깁니다.

그래서 스튜어드의 실제 역량은 명령에서 나오지 않습니다. 오너와 현업과 IT 사이를 오가며 합의를 이끌어 내는 조율에서 나옵니다. 이 점을 처음부터 이해하고 시작하는 것과 그렇지 않은 것은 이후 일의 방식을 크게 가릅니다.

거버넌스가 문서로만 남는 이유

데이터 거버넌스를 규정집이나 정책 문서와 같은 것으로 여기는 경우가 적지 않습니다. 데이터 관리 지침서를 두껍게 만들고 표준 명명 규칙을 정리한 문서를 배포하고 나면 거버넌스를 갖췄다고 여기는 식입니다. 그런데 그렇게 만든 문서 대부분은 공유 폴더 깊숙한 곳에 저장된 뒤 다시 열리지 않습니다.

데이터 거버넌스는 문서화가 필요한 과정임에는 틀림없습니다. 하지만 문서를 만드는 것 자체가 목적이 되면 데이터 거버넌스는 실패합니다. 설계도를 아무리 정교하게 그려도 그것에 맞춰서 씨를 뿌리고 물을 주지 않으면 아름다운 정원이 되지 않는 것과 같습니다. 규정이 실제 업무 흐름 속에서 작동하지 않으면 그 규정은 없는 것과 마찬가지입니다. 거버넌스의 성패는 문서의 두께로 갈리지 않습니다. 그 원칙이 날마다의 데이터 처리 과정에 얼마나 스며들어 있는지가 가릅니다.

이 관점은 오래전부터 정리되어 왔습니다. 데이터 관리 지식체계를 정리한 국제 표준 격의 문헌인 DAMA-DMBOK(Data Management Body of Knowledge)은 거버넌스를 일회성 구축이 아니라 지속적으로 수행하는 관리 기능으로 규정합니다. 조직의 거버넌스 수준을 단계별로 진단하는 여러 성숙도 모델(maturity model)도 문서가 있는지보다 프로세스가 실제로 반복 수행되고 측정되는지를 성숙의 기준으로 삼습니다. 다시 말해 거버넌스는 만들어 두는 것이 아닙니다. 돌아가게 하는 것입니다.

전사부터 덮으려 하지 않는다 — 범위 정하기

초기 구축에서 가장 먼저 짚을 것은 범위입니다. 의욕이 앞서면 조직의 모든 데이터를 한 번에 표준화하고 통제하겠다는 계획을 세우기 쉽습니다. 하지만 전사를 한꺼번에 덮으려는 시도, 이른바 빅뱅 방식은 착수 자체를 계속 미루게 만드는 함정이 됩니다. 완벽한 전사 표준을 먼저 세운 뒤 시작하려다 보면, 부서 간 이견을 조율하는 단계에서 몇 개월이 흘러가고 결국 아무것도 굴러가지 않습니다.

출발점은 좁게 잡아야 합니다. 데이터로 인해 겪는 고통이 가장 큰 도메인을 골라서 거기서부터 손을 대는 방식입니다. 예를 들어 고객 데이터가 그런 영역입니다. 여러 시스템에 흩어져 중복 관리되고, 정의가 부서마다 달라 통합 지표를 뽑을 때마다 숫자가 어긋나기 때문입니다.

A사가 고객 데이터라는 한 도메인을 파일럿으로 정했다고 해 보겠습니다. 이 도메인 안에서 정의를 맞추고 품질을 측정하며 표준을 적용해 눈에 보이는 개선을 만들어 냅니다. 이렇게 만든 작은 성공은 그 자체로 조직의 신뢰를 얻는 마중물이 됩니다. "거버넌스를 했더니 실제로 지표가 정확해지더라"는 경험이 한 번 쌓이면 다음 도메인으로 확장할 때 현업의 협조를 구하기가 한결 수월해집니다. 정원 전체를 한 번에 갈아엎는 대신 화단 하나를 먼저 정갈하게 만들어 보여 주는 셈입니다.

누가 무엇을 책임지는가 — 역할과 R&R 못박기

범위를 정했다면 그 안에서 누가 무엇을 책임지는지를 분명히 해야 합니다. 데이터에 주인이 없으면 품질도 있을 수 없습니다. 아무도 자기 일이라 여기지 않는 데이터는 아무도 돌보지 않기 때문입니다.

이를 위해 도메인별로 스튜어드를 지정하고 역할과 책임을 명문화합니다. 흔히 RACI라 부르는 방식으로 정리하면 도움이 됩니다. 각 업무마다 실무를 수행하는 사람(Responsible), 최종 책임을 지는 사람(Accountable), 자문에 응하는 사람(Consulted), 결과를 통보받는 사람(Informed)을 구분해 표로 못박아 두는 방식입니다. 데이터 거버넌스 협의체처럼 부서 간 이견을 조율하고 표준을 승인하는 의사결정 기구도 세워 두면, 갈등이 생겼을 때 논의가 흘러갈 통로가 마련됩니다.

다만 현실에서는 스튜어드를 전담으로 두기 어려운 조직이 훨씬 많습니다. 대개 현업 담당자가 본래 업무와 스튜어드 역할을 겸직합니다. 겸직 자체가 잘못은 아닙니다. 오히려 업무를 가장 잘 아는 사람이 데이터를 돌보는 편이 자연스러운 면도 있습니다. 문제는 겸직이 '이름만 스튜어드'로 흐를 때입니다. 최소한 그 사람에게 데이터 관리에 쓸 시간이 공식적으로 배정되고 그 활동이 평가에 반영되어야 겸직이 굴러갑니다.

전담 거버넌스 조직을 두는 것만이 정답도 아닙니다. 조직 규모가 크고 도메인이 다양하다면, 중앙 조직이 원칙만 세우고 각 현업이 자기 도메인의 스튜어드를 맡는 연합형 구조가 더 잘 맞습니다. 중요한 것은 형태가 아닙니다. 데이터마다 돌보는 사람이 분명히 정해져 있다는 사실 자체입니다.

공통의 언어 만들기 — 표준과 비즈니스 용어사전

다음 과제는 공통의 언어를 만드는 일입니다. 같은 단어를 부서마다 다른 뜻으로 쓰는 한, 데이터를 통합하는 순간 숫자가 어긋납니다.

'활성 고객'이라는 지표를 생각해 보겠습니다. 마케팅 부서에서는 최근 3개월 안에 한 번이라도 접속한 사람을 활성 고객으로 셉니다. 영업 부서에서는 최근 1년 안에 구매한 사람을 활성 고객으로 봅니다. 두 정의가 다른 채로 각자 지표를 뽑으면, 회의 자리에서 활성 고객 수가 서로 다르게 보고되고 그 자리는 숫자의 진위를 다투는 자리로 바뀝니다. 코드값도 마찬가지입니다. 어떤 시스템은 완료 상태를 Y로, 다른 시스템은 1로, 또 다른 시스템은 DONE으로 기록합니다. 이런 값들이 한 곳에 모이면 통합 자체가 불가능해집니다.

이 혼란을 걷어 내는 도구가 데이터 표준과 비즈니스 용어사전(business glossary)입니다.

• 데이터 표준: 도메인 정의, 코드값 체계, 명명 규칙을 통일합니다. 완료 상태는 어떤 값으로 기록할지, 컬럼 이름은 어떤 규칙으로 붙일지를 조직 공통으로 정합니다.
• 비즈니스 용어사전: '고객', '활성 고객', '매출' 같은 업무 용어의 합의된 정의를 한 곳에 모아 관리합니다. 여기에 정의된 뜻이 조직의 공식 언어가 됩니다.

조직 내에서 데이터에 대한 신뢰성은 결국 '같은 말을 같은 뜻으로 쓴다'는 것에서 출발하기 때문에, 표준과 모델링이야말로 데이터 거버넌스의 뿌리입니다. 데이터를 정돈하는 일의 절반은 이 공통 언어를 만드는 데 있다고 봐도 지나치지 않습니다.

그리고 표준과 용어사전을 세우는 일은 기술 작업이라기보다 합의를 이끌어 내는 조율 작업에 가깝습니다. 데이터 스튜어드의 핵심 과업이 부서 간의 합의와 조율인 이유입니다.

무엇을 가졌는지부터 확인한다

표준이라는 언어를 마련했으면 그 언어로 무엇을 정리할지부터 알아야 합니다. 내 정원에 어떤 식물이 어디에 심겼는지 모르면 가꿀 수 없습니다. 데이터도 마찬가지입니다. 조직이 어떤 데이터를 어디에 가지고 있는지 파악하지 못한 상태에서는 거버넌스가 공회전합니다.

그래서 필요한 것이 데이터 자산의 목록화입니다. 어떤 데이터가 어느 시스템에 있고 어떤 의미를 담고 있으며 누가 관리하는지를 정리해 데이터 카탈로그에 등록합니다. 이때 함께 관리하는 것이 메타데이터입니다. 메타데이터란 데이터를 설명하는 데이터로, 말하자면 상품에 붙은 라벨과 같습니다. 라벨을 보면 원산지와 성분과 유통기한을 알 수 있듯, 메타데이터를 보면 그 데이터의 출처와 정의와 갱신 주기를 알 수 있습니다.

아울러 데이터 리니지(lineage), 즉 데이터의 흐름을 파악하는 일이 중요합니다. 리니지는 어떤 데이터가 어디서 생성되어 어떤 가공을 거쳐 최종 지표에 이르는지를 추적한 지도입니다. 리니지가 정리되어 있으면 지표에 이상이 생겼을 때 어느 단계에서 문제가 생겼는지 거슬러 올라가 찾을 수 있습니다. 반대로 리니지가 없으면 문제의 원인을 찾는 데만 며칠이 걸립니다.

목록화 없이 시작한 거버넌스는 가진 것을 모른 채 관리하겠다는 말과 같습니다. 무엇을 가졌는지 아는 것, 그것이 돌봄의 첫걸음입니다.

품질은 규칙과 숫자로 관리한다

목록이 갖춰지면 품질 관리가 시작됩니다. 여기서 짚어야 할 원칙은, 품질은 형용사가 아니라 숫자로 말해야 한다는 것입니다. "우리 데이터 품질은 좋은 편입니다"라는 말은 아무런 의미가 없습니다.

품질을 관리하려면 먼저 무엇을 품질로 볼지 기준을 나눠야 합니다. 대표적인 품질 차원은 네 가지입니다.

• 정확성: 값이 실제 사실과 일치하는가
• 완전성: 있어야 할 값이 빠지지 않았는가 (결측 여부)
• 일관성: 같은 대상이 시스템 간에 모순 없이 기록되었는가
• 유효성: 값이 정해진 형식과 범위를 지키는가

각 차원마다 측정 규칙과 임계치를 정의합니다. 예를 들어 '고객 이메일 컬럼의 결측률은 2% 이하, 고객 식별자의 중복률은 0.1% 이하'와 같이 목표를 구체적인 숫자로 세웁니다. 그런 다음 정기적으로 품질 측정 작업을 돌려 실제 값이 임계치 안에 있는지 측정합니다. 이렇게 하면 "품질이 나빠졌다"는 막연한 느낌이 "지난달 결측률이 2%에서 5%로 올랐다"는 구체적 사실로 바뀝니다. 느낌에는 대응할 수 없어도 사실에는 대응할 수 있습니다.

다만 모든 데이터를 100% 완벽하게 만들 필요는 없습니다. 비용을 감당하기 어렵고, 애초에 대부분의 경우에 가능하지도 않습니다. 데이터 품질 수준의 목표는 100% 완벽한 게 아니라 용도에 맞는 수준에서 멈춰서야 합니다. 민감한 규제 항목에 관련된 데이터는 매우 높은 정확성이 필요하지만, 대략의 추세만 보는 내부 참고용 데이터에 그 정도의 엄격함을 적용하는 것은 낭비입니다. 어디에 얼마나 힘을 쏟을지 가늠하는 것도 스튜어드의 역량입니다.

거버넌스를 별도 업무가 아니라 일상에 녹인다

정원 조성은 여기까지입니다. 범위를 정하고 역할을 세웠으며, 공통 언어를 만들고 자산을 목록화한 뒤 품질 기준까지 세웠습니다. 이제부터는 조성한 정원을 돌보는 일, 곧 유지·운영의 국면입니다. 이 국면의 성패는 거버넌스를 별도의 업무로 두느냐, 그렇지 않느냐 하는 데서 갈립니다.

거버넌스가 본래 업무와 분리된 별도 활동으로 남으면 그 일은 바쁠 때마다 뒷전으로 밀립니다. 데이터를 만들고 난 후에 나중에 따로 시간을 내서 표준에 맞는지 점검하고 품질을 정제하는 방식은, 그 '나중'이 좀처럼 오지 않기 때문에 지속되지 못합니다.

과거에는 이렇게 사후에 데이터를 정제하는 방식이 일반적이었습니다. 데이터가 쌓인 다음 문제를 발견하고 뒤늦게 손보는 식입니다. 이제는 접근이 달라지고 있습니다. 데이터를 생성하고 변경하는 프로세스 자체에 스튜어드의 승인 절차와 표준 점검을 내장하는 방식입니다. 새 데이터 항목을 만들 때 표준 명명 규칙을 지키지 않으면 등록이 되지 않도록 하고, 중요한 데이터를 변경할 때는 결재 프로세스 안에 스튜어드의 검토가 들어가도록 설계합니다.

이러한 변화는 소프트웨어 개발에서 보안을 다루는 방식과 닮아 있습니다. 다 만든 프로그램을 나중에 점검해 취약점을 찾는 대신 개발 단계에서부터 보안을 내재화하는 시큐어코딩이 자리잡은 것처럼, 데이터 거버넌스도 사후 단속에서 사전 설계로 옮겨 가고 있습니다.

보이게 만든다 — 측정·리포팅·성숙도 진단

거버넌스를 일상에 녹인 뒤에는 그 성과를 보이게 만들어야 합니다. 거버넌스는 눈에 잘 띄지 않는 활동입니다. 데이터가 조용히 정돈되어 있을 때는 아무도 그 공을 알아채지 못하고, 문제가 터졌을 때만 존재가 드러납니다. 이런 일에는 경영진의 지원이 오래 이어지기 어렵습니다. 성과가 보이지 않으니 예산과 인력을 계속 대 줄 이유를 설득하기 어렵기 때문입니다.

그래서 거버넌스의 진척을 숫자로 보여 주는 장치가 필요합니다. 몇 가지 지표를 정해 정기적으로 리포팅하는 방식이 도움이 됩니다.

• 표준 준수율: 새로 만들어지는 데이터가 표준을 지키는 비율
• 품질 지표 추세: 핵심 데이터의 결측률·중복률이 시간에 따라 어떻게 변하는가
• 카탈로그 등록률: 관리 대상 데이터 중 카탈로그에 등록되어 관리되는 비율

지표 리포팅과 별도로, 조직의 거버넌스 수준이 어디쯤 있는지를 성숙도 모델로 진단해 두면 방향을 잡는 데 유용합니다. 성숙도 모델은 거버넌스 역량을 초기 단계부터 최적화 단계까지 여러 단계로 나눠, 지금 우리가 어느 지점에 있고 다음 단계로 가려면 무엇이 필요한지를 보여 줍니다. 앞서 언급한 DAMA-DMBOK을 비롯한 여러 프레임워크가 이러한 성숙도 모델의 기반을 제공합니다.

이런 측정은 결국 "정원이 나아지고 있다"는 증거를 모으는 일입니다. 지난 분기보다 품질 지표가 개선되고 카탈로그 등록률이 올랐다는 사실이 숫자로 보이면, 거버넌스를 보는 눈도 비용에서 투자로 바뀌기 시작합니다.

흔히 빠지는 함정 — 관료주의와 도구 만능주의

다만 이 일에는 빠지기 쉬운 함정이 두 가지 있습니다. 방향을 잘못 잡으면 애써 만든 거버넌스가 오히려 조직에 걸림돌이 됩니다.

첫 번째는 관료주의입니다. 통제에 힘이 실리다 보면 규정이 점점 늘어나고 데이터를 하나 만들거나 바꾸는 데 여러 단계의 승인이 필요해집니다. 어느 순간 거버넌스는 일을 돕는 장치가 아니라 일을 막는 장벽이 됩니다. 현업은 규정을 우회할 방법을 찾기 시작하고, 그렇게 만들어진 데이터가 거버넌스 체계 밖에서 자라납니다. 잡초를 뽑겠다고 하다가 꽃까지 뽑아 버리는 정원사와 같은 실수입니다.

두 번째는 도구 만능주의입니다. 값비싼 데이터 카탈로그 솔루션이나 품질 관리 도구를 도입하면 거버넌스가 저절로 갖춰진다는 기대입니다. 하지만 도구는 사람이 정한 규칙과 프로세스를 실어 나르는 그릇일 뿐입니다. 표준을 무엇으로 삼을지, 품질 기준을 어떻게 정할지, 누가 책임질지가 정해지지 않은 상태에서 도구만 들이면 비싼 도구가 비어있는 채로 돌아갑니다.

두 함정을 벗어나는 열쇠는 거버넌스의 목적을 정확히 세우는 데 있습니다. 거버넌스의 본분은 통제가 아닙니다. 규정의 목적은 사람들이 데이터를 믿고 쉽게 쓰도록 돕는 데 있지, 못 쓰게 막는 데 있지 않습니다. 이 기준으로 보면 어떤 규정이 도움이 되고 어떤 규정이 장벽인지를 구분할 수 있습니다. 도움이 되지 않는 통제는 과감히 덜어 내는 것도 스튜어드의 일입니다.

스튜어드가 오늘 당장 할 수 있는 것 — 실무 체크리스트

마지막으로 데이터 스튜어드가 지금 당장 점검할 수 있는 체크리스트를 준비했습니다. 조직 내 데이터 거버넌스의 수준을 두고 다음 질문에 답해 보면 현재 위치가 드러납니다.

점검 항목	질문
역할	우리 도메인에 지정된 스튜어드와 오너가 있는가
정의	핵심 용어(예: 활성 고객)의 합의된 정의가 문서로 있는가
표준	코드값과 명명 규칙이 통일되어 있는가
목록	어떤 데이터를 어디에 가졌는지 카탈로그로 파악되는가
품질	핵심 데이터의 품질을 형용사가 아니라 숫자로 보고 있는가
내재화	표준·품질 점검이 업무 워크플로 안에 들어가 있는가

여섯 항목 중 '그렇다'고 답할 수 있는 것과 그렇지 않은 것을 확인하보면 지금 우리 조직에서는 어디에 힘을 쏟아야 할지가 보입니다. 하나도 준비되지 않았다면 역할과 정의부터, 어느 정도 갖췄다면 내재화와 측정으로 무게 중심을 옮기면 됩니다. 여섯 개를 한 번에 채우려 들기보다 비어 있는 칸부터 손대는 것이 중요합니다.

완공일 없는 정원

데이터 거버넌스는 스튜어드 한 사람의 노력만으로 되는 일은 아닙니다. 데이터를 자산으로 다루는 조직 문화와 경영진의 의지가 뒷받침되지 않으면 아무리 정교한 규정과 도구도 오래 굴러가지 못합니다. 다만 잘 돌본 데이터가 쌓이면 그 위에서 하는 일들이 달라진다는 점만은 분명합니다. 정의가 맞춰지고 품질이 관리되며 맥락이 정돈된 데이터는 분석 지표의 가치를 높이고 AI 서비스의 정확성을 향상시킵니다.

데이터 거버넌스를 처음 세울 때는 전사를 한꺼번에 덮으려 들면 안됩니다. 작은 도메인부터 좁게 시작해 역할을 만들고 공통의 언어를 만들며 가진 데이터를 목록화하고 품질을 숫자로 관리합니다. 그 뒤에는 거버넌스의 성과를 지표로 보이게 만들어 관료주의와 도구 만능주의의 함정을 피하면서 상시 역량으로 한 단계씩 키워 갑니다.

이 모든 일을 관통하는 것은 처음의 그림, 곧 데이터라는 정원을 맡아 돌보는 청지기의 자세입니다. 거버넌스는 한 번 만들고 끝나는 프로젝트가 아닙니다. 완공일 없이 계속 돌봐야 하는 정원입니다. 거창한 전사 프로젝트를 기다리지 마시고 맡은 도메인 한 곳의 정의와 품질부터 점검해 보시길 권합니다. 정원은 오늘 뽑은 잡초 하나, 오늘 붙인 이름표 하나에서 달라지기 시작합니다.