강대웅 비투엔컨설팅 전문위원겸 상무이사

▲ 강대웅 비투엔컨설팅 전문위원겸 상무이사

[컴퓨터월드] 정보시스템 구축과 운영 관련 산업분야에서 데이터 품질관리 시스템 도입은 이제 당연시되는 분위기다. 일정 규모 이상의 차세대 정보시스템 구축 제안요청서에는 데이터 품질관리 체계 수립과 솔루션 도입이 포함돼 있다. 그러나 데이터 품질관리 시스템만 도입되면 데이터 품질이 절로 좋아진다거나 보장될 수 있다는 잘못된 생각은 버려야 한다.

데이터 품질이 무엇인가? 데이터가 데이터답게 존재해야 하는 것을 의미한다. 데이터의 업무적 특성대로 발생되고 있다면 품질이 확보되었다고 할 수 있을 것이다. 데이터 품질은 데이터 품질관리 시스템 도입보다 업무적 특성이 무엇인지 관리하는 것이 더욱 중요하다는 얘기이다. 여기에서는 정보시스템 구축과 운영에 있어 데이터의 업무적 특성을 데이터 모델에 체계적으로 관리하고 데이터 품질관리 시스템과 연계해 품질을 확보할 수 있는 방법을 제시하고자 한다.

 

수천 개의 테이블에 수만 개의 컬럼으로 구성된 DB의 데이터 품질관리를 위해 운영되고 있는 업무규칙(BR, Business Rule) 수가 수백 개에 지나지 않는다면 데이터 품질지표를 신뢰할 수 있겠는가? 대부분의 테이블과 컬럼들이 고유의 업무적 특성을 지니고 있는데 다 어디 가고 고작 수백 개 정도만 업무규칙화된 것일까?

적지 않은 기업이나 공공기관의 데이터 품질관리 현실이 이러하다. 특히 이런 상태로 데이터를 관리하면서 데이터 품질 관련 인증을 받고자 하는 기업이나 공공기관이 있다는 사실에 그저 놀랄 뿐이다.

수백 개의 업무규칙 그 자체가 문제라는 것은 아니다. 수백 개의 업무규칙 만으로도 충분한 경우도 있다. 그러나, 수천 개의 테이블, 수만 개의 컬럼에 대해 수백 개의 업무규칙은 지나치게 적은 면이 있다.

업무규칙이 지나치게 적게 관리되는 요인으로는 데이터 품질관리 체계 구축 사업이 데이터 품질관리 프로세스와 절차를 수립하거나 관련 솔루션 도입 중심으로 고착화되어 있기 때문이다. 또한 데이터 품질관리가 일회성 사업으로 그쳐 데이터 품질을 측정하는 업무규칙을 발굴하고 확장하는데 소홀한 것도 업무규칙이 적게 관리되는 요인이라 할 수 있다.

 

데이터 품질관리의 핵심은 데이터 모델

필자는 일년에 수 차례 데이터 모델링 관련 강의나 강연을 하고 있다. 강의 도중 데이터 모델이 데이터베이스 테이블과 컬럼을 설명하는 문서라기 보다는 데이터가 지니는 업무적 특성을 정해진 표기법(eg. IE(Information Engineering))을 이용해 도식화한 것이라는 점을 특히 강조한다.

물론, 물리적 데이터 모델은 데이터베이스를 설명하는 문서로 봐도 좋다. 그러므로, 잘 설계된 데이터 모델이란 업무적 특성이 잘 표현되어 있어 데이터 모델을 통해 업무적 특성이 쉽게 읽혀져야 한다.

그러나, 국내에서 진행되는 수많은 정보시스템 구축 프로젝트 및 운영 환경에서 접하는 데이터 모델은 그저 데이터베이스 테이블과 컬럼을 보기 좋게 나열한 것에 불과한 경우가 너무 많아 안타까울 뿐이다. 심지어 데이터 모델을 정보시스템 구축 프로젝트의 산출물 정도로만 취급해 정보시스템 오픈 후 운영 중에는 더 이상 관리하지 않는 곳도 많다.

결론을 어느 위치에 쓸까 고민하다 순간 귀차니즘이 살짝 발동하여 이 지점에 써보기로 한다. 데이터 품질관리의 핵심은 잘 정의된 풍부한 업무규칙을 개발하고 운영하는 것인데 이러한 업무규칙의 상당 부분을 별다른 노력 없이 데이터 모델로부터 충분히 도출할 수 있다는 것이 결론이 되겠다. 물론, 데이터 모델이 그저 데이터베이스 테이블이나 컬럼을 나열하는 식으로만 관리되는 기업이나 기관에서는 비현실적인 얘기이다.

다소 기술적인 이야기로 치우칠 수 있겠으나 아래 세 가지의 데이터 모델을 비교해보고자 한다. 모두 동일한 업무를 다른 방식으로 설계한 것이다.

▲ 데이터 모델 1

데이터 모델 1은 데이터베이스의 테이블과 컬럼을 평면적으로 나열한 것을 도식한 것이다. 이러한 데이터 모델에서 데이터 품질관리를 위한 업무규칙을 찾기는 쉽지 않기 때문에 별도로 업무규칙 도출을 위한 조사 작업을 실시해야 한다.

▲ 데이터 모델 2

데이터 모델 2는 데이터베이스의 테이블과 컬럼에 대한 물리 데이터 모델 수준을 보여준다. 엔티티(entity)는 데이터베이스 테이블을 대신하며 속성은 컬럼을 대신하고 있으며 외래 키(FK, Foreign Key)에 해당하는 컬럼을 릴레이션십으로 표현한 것이다.

이 데이터 모델에는 데이터의 업무적 특성이 표현되어 있으므로 데이터 품질 진단을 위한 업무규칙들을 도출할 수 있을 것이다.

 - 업무규칙 1: 발송 테이블의 발송협력업체번호는 Not Null이며 협력업체 테이블에 등록된 업체여야 한다.
 - 업무규칙 2: 상품납품업체 테이블의 상품납품협력업체번호는 Not Null이며 협력업체 테이블에 등록된 업체여야 한다.

그런데, 데이터 모델 2 및 위 업무규칙 1, 2를 통해 협력업체 테이블에는 발송업체도 등록되어 있고 상품납품업체도 등록되어 있음을 유추할 수 있다. 데이터 모델에는 명확하게 표현되어 있지 않지만 협력업체 테이블의 협력업체유형코드 컬럼을 통해 발송업체 기능을 가진 업체인지 상품납품업체 기능을 가진 업체인지를 구분하고 있을 것이다.

만약, 발송 테이블의 발송협력업체번호에 발송업체가 아닌 상품납품업체의 업체번호가 기록되어 있거나 혹은 상품납품업체 테이블의 상품납품협력업체번호에 발주업체의 업체번호가 기록되어 있다면 이는 업무 규정에 위배되는 데이터이다.

그럼에도 불구하고 업무규칙 1과 업무규칙 2는 이와 같은 오류 데이터를 발견해내지 못한다. 그 이유는 업무규칙 1과 업무규칙 2 도출 근간인 데이터 모델 2가 물리 데이터 모델 수준이고 물리 데이터 모델은 데이터의 업무적 특성을 충분히 표현하기에는 한계가 있기 때문이다.

▲ 데이터 모델 3

데이터 모델 3은 논리 데이터 모델이다. 필자는 이를 개념 데이터 모델이라고 이야기하고 싶으나 실제 정보시스템 구축 프로젝트에서는 논리 데이터 모델로 통용되고 있다. 이것이 개념이냐 논리이냐에 대해서는 주제에서 벗어나므로 더 이상 논하지는 않겠다.

데이터 모델 3을 통해 다음과 같은 데이터 품질관리를 위한 업무규칙을 도출할 수 있다.

 - 업무규칙1: 발송 테이블의 발송협력업체번호는 Not Null이며 협력업체 테이블의 부분집합인 발송업체에 등록된 업체여야 한다. 부분집합을 식별하는 협력업체 컬럼은 협력업체유형코드이다.
 - 업무규칙 2: 상품납품업체 테이블의 상품납품협력업체번호는 Not Null이며 협력업체 테이블의 부분집합인 상품납품업체에 등록된 업체여야 한다. 부분집합을 식별하는 협력업체 컬럼은 협력업체유형코드이다.
 - 업무규칙 3: 협력업체 테이블의 해외발송대행여부 컬럼은 협력업체의 부분집합 중 발송업체의 경우에만 기록되며 반드시 Y, N 중 하나의 값으로 표현되어 있어야 한다.

데이터 모델 3은 논리 데이터 모델이므로 물리적으로는 데이터 모델 1 또는 데이터 모델 2와 같은 구조로 구현되었음을 전제하고 업무규칙 1, 2, 3을 도출한 것이다. 업무규칙 3은 컬럼의 Not Null 정보 및 도메인 정보까지 포함해 기술한 것임을 전제로 한다.

수천 개에 달하는 테이블 및 수만 개의 컬럼들을 데이터 모델 3과 같이 업무적 특성이 잘 표현되도록 정확하게 설계한다면 데이터 품질관리를 위한 업무규칙을 매우 풍부하게, 매우 쉽게 도출할 수 있을 것이다.

 

맺으면서

이상과 같이, 데이터 모델 특히 논리 데이터 모델을 업무적 특성을 고려해 상세하게 설계하는 것이 데이터 품질관리의 핵심이다. 컴퓨터 공학 전공서적으로 유명한 Conceptual Database Design – An Entity Relationship Approach(Batini, Ceri, Navathe 공저)에서는 데이터 모델이 지녀야 할 질적 특성(Quality Features)을 제시하고 있는데, 데이터 모델은 업무적 특성을 정해진 표기법을 이용해 최대한 자세하게 표현하고 있어야 하고 이를 통해 데이터 모델의 가독성(Readability)과 자명성(Self-Explanation) 등을 확보할 수 있다고 기술하고 있다.

많은 정보시스템 구축과 운영 사업에서 데이터 모델은 데이터베이스를 구축하기 위한 목적으로 설계된다. 필자 및 필자가 속한 회사에서도 이런 목적으로 데이터 모델을 설계하는 일을 하고 있다. 그러나, 데이터 모델을 단지 데이터베이스의 테이블과 컬럼을 설명하기 위한 산출물로만 여기지 말고 데이터가 지니는 업무적 특성을 상세하게 표현하고 있는 기업이나 기관의 데이터 지도로써 활용될 수 있도록 해야 할 것이다.

저작권자 © 아이티데일리 무단전재 및 재배포 금지