데이터 거버넌스의 첫걸음, 데이터 표준화

 

Intro

이번에 투입된 프로젝트는 데이터 거버넌스를 구축하는 프로젝트였다. '데이터 거버넌스'는 사실 포괄적으로 사용되는 용어이기 때문에, 고객사에서 '거버넌스'를 어떻게 바라보는가에 따라서 수행 영역이 달라지는 것 같다.

 

일반적으로 이론화된 데이터 거버넌스를 구성하는 요소는 다음과 같다.

데이터 거버넌스란?
전사적인 데이터 관리 방향을 제시하고 통제하는 활동 전반을 말한다.
   1. 원칙 및 프로세스
      - 비전 및 원칙, 업무에 대한 문서화를 말함
      - e.g. 데이터 관리 체계 정의서, 데이터 모델 관리 지침서, 데이터 표준 지침서, 데이터 품질 지침서  등
   2. 조직
      - 담당자 및 R&R 정의
   3. 관리 도구
      - 메타데이터, 데이터 표준 승인 관리, 데이터 품질, 데이터 모델 관리 도구 등

 

 

이번 프로젝트에서 가장 큰 요구사항은 '데이터 품질'에 대한 관리 요구였다. 지금까지는 기존에 구축한 시스템을 운영하는 것만으로도 충분히 비즈니스를 영위할 수 있었지만, 갈수록 데이터 활용에 대한 요구와 가치가 커지면서 기존 데이터 관리 체계에 한계를 느끼고 있는 기업이 많아지고 있다. 데이터 거버넌스 체계가 잘 구축되지 않은 경우 '이런 데이터 어디에 있지?', '데이터 분석 결과가 왜 이러지?'와 같은 질문에 답하는 데 큰 시간을 소모하게 된다. 그런데 대부분 이러한 시간 낭비의 원인은 (1) 데이터 자산에 대한 가시성이 확보되지 않았거나, (2) 데이터 품질 관리가 미흡했기 때문이다. 이번 프로젝트도 결국은 어떤 데이터가 어디에 어떻게 있는지 확인하고, 앞으로 이 데이터들의 품질을 올려 활용도를 높이겠다는 목적에서 시작되었다.

 

Why 데이터 표준화

데이터 표준화와 데이터 품질은 어떤 관계가 있을까? 데이터 표준화는 데이터에 일관성 있게 이름을 붙히고, 그 이름에 걸맞는 값들로 데이터가 구성되도록 개선하는 작업이다. 데이터 표준화는 품질 개선 활동을 원활하게 하고 전사 수준에서 일관성 있게 데이터 관리를 하기 위해 필요하다.

 

Why 1. 명명 규칙이 필요하니까

동일한 데이터라면 같은 이름을 붙여둬야 한다. 일례로, '고객생년월일' 데이터가 저장되어 있는 컬럼 이름이 '주민번호앞자리', '회원생일', '본인기념일' 등으로 컬럼마다 다르게 되어 있다면 어떨까? 해당 데이터에 대해 수집해 처리나 분석을 하기까지 데이터를 식별하는 데만 많은 시간을 허비하게 될 수 있다.

 

Why 2. 데이터 값에도 규칙이 필요하니까

동일한 이름의 컬럼들의 데이터타입이 상이한 경우를 많이 보았을 것이다. 앞선 예시에서 들었던 '고객생년월일' 데이터가 DATETIME일 때도, VARCHAR 일 때도, CHAR일 때도 있다면? '생년월일' 데이터라면 허용해야 할 값의 range가 명확한데(1800년대에 태어난 고객이나 13월에 태어난 고객은 없을 것이다), 이에 대한 검증 규칙을 타입별로 세워야 할 것이다. 활용 시 여러 전처리가 필요할 수 있고, 데이터 정확성을 신뢰하기 어려워진다. 왜냐하면 품질 개선이 필요하더라도 케이스별로 처리해야하니, 자동화가 어려워 실질적으로 품질 점검이나 개선 활동이 불가능해진다.

 

But, 현실은 규칙이 지배하지 않지

하지만 현실은 시스템별로 명명 규칙도 다르고, 데이터 값에 대한 명확한 기준이 없는 경우가 많다. 데이터 표준 없이 시스템이 구축되더라도 해당 서비스는 잘 돌아간다. 하지만 시스템 경계를 넘어서 통시적으로 데이터를 활용하려면 결국 데이터 표준화를 거쳐야 한다.

 

그렇게 데이터 표준화를 첫단추로 프로젝트가 시작되었다.

 

How 데이터 표준화 절차

데이터 표준화는 결국 어떤 데이터들이 관리되고 있는지 긁어 모아와서, 그 데이터들에 알맞은 이름을 붙혀주는 작업이다. 

 

이번 프로젝트는 단기간에 방대한 양을 표준화 해야 했기 때문에, 프로파일링 등 업무밀도가 높은 작업은 일부 생략했음을 참고하기 바란다.

How 1. 딕셔너리 정보 수집 

DBMS 딕셔너리에서  Table (Name, Num_rows, Created, Comments 등), Column (DataType, Length), Constraints (Nullable, PK, FK) 에 대한 정보들을 수집한다. 이번에는 Sybase SAP, HANA, IQ를 대상으로 딕셔너리 정보를 조회해야 했는데 확보된 쿼리가 없어서 공식문서를 뒤적여 가며 짰다.

 

How 2. 테이블명, 속성명 한글화

보통은 DBMS 코멘트 정보나 기존 한글화 자료를 사용한다. 이번 프로젝트는 고객사에서 기존에 활용하던 데이터 모델이 있어 그 정보도 수집해 활용했다. 수집된 자료들을 모아서 이미 한글명칭이 확보된 것들을 정리하고, 누락된 것은 따로 정리해 운영 담당자에 배포하여 한글화를 요청했다.

 

How 3. 한글 명칭 파싱 및 표준화 

수집된 한글 명칭을 단어 단위로 쪼개어(파싱) 분석했다. 파싱을 할 때에는 생상성 Skill 블로그의 "형태소 분석기"와 "데이터 표준점검 도구"를 활용했다. 파싱을 거치면서 다음과 같은 사항을 처리했다.

• 오탈자나 특수문자 제거
• 잔존하는 영문 수정
• 의미가 같은 단어 통합 (e.g. 수정, 업데이트, 변경 ➡️ 수정)
  • 표준어로 통합
  • 사용 빈도 높은 단어로 통합
• 약어 수정/통합 (e.g. 행자부, 행안부, MOI ➡️ 행정안전부)

 

How 4. 컬럼 도메인 식별 및 분류어 부착

표준 단어로 이루어진 속성명(한글 컬럼명)을 얻게 되면, 속성명이 분류어(도메인명)로 종결되는지 확인 후 분류어가 없는 경우 부착했다. (e.g. 월별_종업원_퇴직금 ➡️ 월별_종업원_퇴직금_금액 )

속성명 분류어란?
해당 속성(컬럼)의 데이터 타입과 길이, 형식 등 도메인을 알 수 있도록 어미에 붙이는 명칭. (e.g. 일시, 일자, 금액, 수, 명)

 

속성명에 분류어를 부착하는 작업은 매우 중요하다. 분류어를 부착한다는 것은 그 컬럼의 도메인을 식별한다는 의미이며, 도메인이 식별되어야 데이터 품질 점검이 가능해지기 때문이다.

 

What 데이터 표준화 결과물

데이터 표준화 절차를 거치며 만들어지게 되는 최종 결과물 중 대표적인 것들을 소개한다.

What 1. 표준 단어사전

한글 명칭 파싱과 수정을 거치면서 테이블명/컬럼명으로 사용된 단어들을 목록화하여 표준 단어사전을 구축했다. 조직에서 어떤 단어를 사용할 것이고, 어떤 단어는 사용하지 않을 것인지를 사전으로 만든 것이다. 표준 단어사전에 기본적으로 들어가는 아이템은 다음과 같다.

• 단어 (e.g. 고객)
• 영문 약어 (e.g. CUST)
• 영문 정의 (e.g. Customer)
• 국문 정의 (e.g.  OO 서비스에 회원으로 등록된 개인을 말한다. 비회원의 경우 '가망고객' 단어를 사용한다.)
• 동의어 (a.k.a. 금칙어. e.g. 회원, 손님, 클라이언트)
• 분류어 여부 (e.g. "N")

 

What 2. 표준 도메인사전 및 용어사전

표준 단어사전에서 분류어로 구분된 단어들에 대하여 표준 도메인사전에 등재한다. 이때, 이 분류어가 사용할 수 있는 데이터 타입과 길이 등을 기재한다. 때문에 이 단계에서 해당 분류어를 사용하고 있는 컬럼들을 식별해 데이터타입과 길이 범위를 확인해보는 작업이 필요하다.

 

그리고 마지막으로, 표준 단어와 표준 도메인의 조합으로 만들어진 속성명 리스트가 표준 용어사전 이 된다. 표준 용어는 간단히 말해서 약속된 표준 단어로 이루어졌으며, 사용하기로 정한 도메인 중 가장 적합한 도메인을 택해 만든 속성명이라고 할 수 있다. 

 

What 3. 표준 관리 지침

표준 사전들을 구축하고 나면, 이 사전을 적용할 시스템 범위는 어떻게 되는지, 추가/수정에 대한 작성 담당자는 누구인지, 최종 결정권자는 누구인지 등을 정하는 데이터 표준 관리 지침서도 필요하다. 그래야 애써 정한 데이터 표준이 잘 적용되고 개선 발전될 수 있다. 지침은 고객사 요구사항과 표준화 과정을 거치면서 가지게 된 방향 등이 적용되었다.

 

이렇게 표준화를 마치고 나면 다음과 같은 작업 기반이 마련된 것이라 할 수 있다.

• 데이터 모델 생성
• 데이터 품질 점검 활동
• 신규 시스템 구축 시 표준 적용

 

Lesson Learned 

아직 프로젝트가 한창 진행 중이고, 앞으로 데이터 품질 점검 활동이 예정되어 있어 품질 점검까지 해보고 나면 표준화 작업에 대해서 아쉬운 점이 더 보일 수 있을 것 같다. 그래도 중간점검 차 표준화를 하면서 느끼게 된 점들을 정리해 본다.

Lesson 1. Divide and Conquer가 유효했나

프로젝트에 착수할 때부터 압도적인 양과 제한적인 기간 때문에 우리 팀이 세웠던 전략 중 하나는 Divde and Conquer였다. 전체 표준화 대상 시스템 중 절반을 1차로, 나머지 시스템 절반을 2차로 나누어 표준화를 2회 진행하였다. 그런데 이 전략은 효율성에서 좋지 못한 성과를 냈던 것 같다. 특히 표준 단어/용어/도메인 사전 구축에 있어 1차 대상 시스템만 놓고 보고 정의한 부분을 1-2차 시스템 전체를 놓고 보니 수정해야 할 부분이 많았다.

 

시스템 단위로 작업 일정을 나누기보다는 한글화 수집이 빠르게 된 부분은 단어 사전 구축 시에 모두 input으로 활용했으면 좋았을 것 같다.

 

Lesson 2. 고객의 참여가 중요하다

데이터를 바라보는 관점은 조직과 업무에 따라서 달라진다. 개발자의 관점, 운영자의 관점, 기획자의 관점, 분석가의 관점, 업무 담당자의 관점은 다를 수밖에 없다. 이러한 입장의 차이와 시스템 히스토리를 가장 잘 알고 있는 것은 결국 고객이다. 전사 관계자 간의 관점에 대해서 청취하고 조율하는 데 고객이 적극적으로 나서 준 덕분에, 프로젝트 내내 즉각적인 논의가 이루어질 수 있었고, 빠른 의사결정을 내릴 수 있었다.

 

Lesson 3. Legacy에 대한 존중이 필요하다

나의 개인적인 미스에 대한 이야기다. 이번에 이론으로만 접했던 데이터 표준화 업무를 처음으로 수행하다보니 너무 이상적인 지점을 지향하고 원론에 얽매인 의사결정을 내릴 때가 있었던 것 같다. 특히 물리 약어명을 새로 정의할 때 기존 약어명이 콩글리시 기반이라면 좀 더 범용적인 명칭으로 재정의하였는데, 워낙 오래도록 쓰여온 명칭이라 변경하면 오히려 명확하게 의사소통이 어려워질 것 같다는 의견이 있어 작업을 되돌려 놓기도 했다. 레거시는 결국 완성되기까지 유구한 역사를 가지고 있음을 주지하자.

 

Lesson 4. DBMS 기본을 놓치지 말자

단적으로는 데이터타입까지도 꼼꼼히 새로 공부해두어야겠다는 생각이 들었다. 이번에 도메인 표준을 정하면서 DBMS별 데이터타입은 어떻게 다른지에 대해 확인해야 했다. 그리고 현재 INTERGER, FLOAT, DOUBLE 타입이 사용되고 있는 컬럼들을 향후에는 NUMERIC으로 표준화하기로 했는데, 이때 적절한 Length와 Presicion을 확인하는 등 생각보다 기초적인 지식이 많이 요구되었다. 좀 더 현명한 의사결정을 내리고 고객에게 전달하기 위해서는 미리 준비되어 있어야 한다는 생각이 많이 들었다.