[전문가 기고] 데이터 품질관리를 위한 새로운 접근 방법 - 비투엔컨설팅 강대웅 상무

데이터 모델을 중시하는 사람들에게는 딱히 새로울 것도 없는

데이터 품질관리를 위한 새로운 접근 방법

[ 강대웅 ] 삼성SDS 출신으로, 현재는 비투엔컨설팅의 전문위원이자 상무이사로 재직 중이다. 1994년부터 지금까지 데이터 관련 업무에만 종사하였다. davidkang@b2en.com

정보시스템 구축과 운영 관련 산업분야에서 데이터 품질관리 시스템 도입은 이제 당연시되는 분위기이다. 웬만한 사이즈의 차세대 정보시스템 구축 제안요청서들에는 데이터 품질관리 체계 수립과 솔루션 도입이 포함되어 있다. 마치 데이터 품질관리 시스템만 도입되면 데이터 품질이 절로 좋아진다거나 보장될 수 있다는 충성된 종교적 믿음이라도 있는 듯 하다. 데이터 품질이 무엇인가? 데이터가 데이터답게 존재해야 하는 것이 품질일 것이다. 데이터의 업무적 특성대로 발생되고 있다면 품질이 확보되었다고 할 수 있을 것이다. 결국 데이터 품질은 데이터 품질관리 시스템 도입보다 업무적 특성이 무엇인지 관리하는 것이 더욱 중요하다는 얘기이다. 본 기고에서는 정보시스템 구축과 운영에 있어 데이터의 업무적 특성을 데이터 모델에 체계적으로 관리하고 데이터 품질관리 시스템과 연계하여 품질을 확보할 수 있는 방법을 제시하고자 한다.

1. 들어가며

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

적지 않은 기업이나 공공기관의 데이터 품질관리 현실이 이러하다. 심지어는 이런 상태로 관리하면서도 데이터 품질 관련 인증을 받고자 하는 곳도 심심치 않게 있을 정도이다.

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

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

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

필자는 일년에 수 차례 데이터 모델링 관련 강의나 강연을 하고 있으며, 이 때 수강생들에게 가장 강조하는 점은 데이터 모델이 데이터베이스 테이블과 컬럼을 설명하는 문서라기 보다는 데이터가 지니는 업무적 특성을 정해진 표기법(eg. IE(Information Engineering))을 이용하여 도식한 것이라는 점이다. 물론, 물리적 데이터 모델은 데이터베이스를 설명하는 문서로 봐도 좋다. 그러므로, 잘 설계된 데이터 모델이란 업무적 특성이 잘 표현되어 있어서 데이터 모델을 통해 업무적 특성이 쉽게 읽혀져야 한다.

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

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

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

 

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

 

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

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

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

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

그런데, 데이터 모델2 및 위 업무규칙1, 2를 통해 협력업체 테이블에는 발송업체도 등록되어 있고 상품납품업체도 등록되어 있음을 유추할 수 있다. 데이터 모델에는 명확하게 표현되어 있지 않지만 협력업체 테이블의 협력업체유형코드 컬럼을 통해 발송업체 기능을 가진 업체인지 상품납품업체 기능을 가진 업체인지를 구분하고 있을 것이다. 만약, 발송 테이블의 발송협력업체번호에 발송업체가 아닌 상품납품업체의 업체번호가 기록되어 있다면 혹은 상품납품업체 테이블의 상품납품협력업체번호에 발주업체의 업체번호가 기록되어 있다면 이는 업무 규정에 위배되는 데이터이다. 그럼에도 불구하고 업무규칙1과 업무규칙2는 이와 같은 오류 데이터를 발견해내지 못한다. 그 이유는 업무규칙 1과 업무규칙 2 도출 근간인 데이터 모델2가 물리 데이터 모델 수준이고 물리 데이터 모델은 데이터의 업무적 특성을 충분히 표현하기에는 한계가 있기 때문이다.

 

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

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

• 업무규칙1: 발송 테이블의 발송협력업체번호는 Not Null이며 협력업체 테이블의 부분집합인 발송업체에 등록된 업체여야 한다. 부분집합을 식별하는 협력업체 컬럼은 협력업체유형코드이다.

• 업무규칙2: 상품납품업체 테이블의 상품납품협력업체번호는 Not Null이며 협력업체 테이블의 부분집합인 상품납품업체에 등록된 업체여야 한다. 부분집합을 식별하는 협력업체 컬럼은 협력업체유형코드이다.

• 업무규칙3: 협력업체 테이블의 해외발송대행여부 컬럼은 협력업체의 부분집합 중 발송업체의 경우에만 기록되며 반드시 Y, N 중 하나의 값으로 표현되어 있어야 한다.

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

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

3. 맺으면서

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

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

데이터 품질관리를 잘 하고 싶은 기업과 기관이여, 잘 설계된 데이터 모델을 먼저 확보해보세요. 데이터 고품질 유지를 위한 열쇠가 여기에 있습니다!