김기창의 데이터 모델링 강의(22회)

무조건 많은 데이터보다 정확한 데이터를 위해

[필자 소개]

김기창은 데이터 분야에서 15년 이상 일하고 있으며, 현재는 위즈덤마인드 (www.wisdom-mind.co.kr)의 대표 컨설턴트로서 데이터 모델링(Data Modeling)과 DA(Data Architecture) 컨설팅을 하고 있다. 특별히 풍부한 실전을 바탕으로 데이터 모델링을 직접 수행하며, 실무에 적절한 DA 컨설팅을 하는 것이 강점이다. 저서로는 [데이터베이스 활용을 위한 SQL Server 2000], [관계형 데이터 모델링 프리미엄 가이드], [관계형 데이터 모델링 노트]가 있으며, 역서로는 [데이터 모델링 리소스 북]이 있다. 2007년에는 [전사적 데이터 아키텍처 프레임웍에 대한 개념 모델 개발] 논문을 발표했다. 모델러가 기업에게 제공할 최고의 가치는 좋은 모델을 제공하는 것이라고 생각하고 있다. 소명을 갖고 많은 기업에서 진짜 모델이 운영되는 것을 꿈꾸고 있으며, 그런 모델을 설계하는 진짜 모델러가 많아질 수 있도록 노력하고 있다.

이번 강의의 주제는 데이터 품질입니다. 데이터 품질 영역은 데이터 표준 영역과 비슷하게 시스템의 영향을 많이 받은 영역입니다. 대개 데이터품질관리시스템(DQMS)이라는 시스템을 사용해야 데이터 품질 활동을 할 수 있어서 데이터 품질이라고 하면 DQMS 시스템을 의미하게 됩니다.
하지만 이번 강의에서 설명할 데이터 품질은 DA 전체 영역에 대한 품질을 의미합니다. DQMS 시스템에서 관리하고 있는 데이터 품질보다 범위가 넓습니다. 또한 실무를 하면서 제가 경험했던 요소에 대해서 다룰 예정입니다.


최근에 데이터 품질 관련 프로젝트가 다양하게 많은 거 같습니다. 저는 데이터 품질 관리 프로젝트 경험이 없습니다. 대부분의 프로젝트가 모델링이었고, 앞서 언급했던 DQMS가 회사에 없었기 때문에 데이터 품질 관리 프로젝트 자체는 경험할 기회가 없었습니다. 데이터 품질 활동이야 많이 했지만요.
이런 이유 때문에 이번 강의 내용이 실무 프로젝트에서 일반적으로 수행하는 데이터 품질 관리와는 다를 수 있다는 점을 언급하고 싶습니다. 데이터 품질 관리 프로젝트에 대한 소개보다는 데이터 품질을 좋게 하기 위해서 어떤 일을 해야 하는지가 주제입니다.


이번 강의에서는 데이터 품질에 대한 내용을 개괄적으로 설명할 것입니다. 튜닝 주제와 마찬가지로 상세하게 설명하면 책 한 권의 내용이 될 것입니다. 간단하게 요약해서 설명하겠습니다.

데이터 품질 개요

제가 생각하고 있는 데이터 품질 관리를 본격적으로 설명하기 전에 데이터 품질의 몇 가지 용어에 대해 설명하겠습니다.
데이터 아키텍처 영역에 포함된 데이터 품질(data quality)이라고 하면, 테이블에 저장된 데이터를 분석해서 품질이 떨어지는 데이터는 개선하여 높은 품질을 유지하도록 하는 활동을 의미합니다.


고품질의 데이터를 유지하기 위한 활동에는 우선 대상을 정의하는 게 포함됩니다. 무엇을 검토할지에 대한 것입니다. 대상이 정해졌으면 어떤 규칙을 적용해서 품질을 높일지를 정하게 됩니다. 여기에는 절차까지 포함됩니다.
데이터 품질 관리 대상을 선정하고 측정을 합니다. 이때는 프로파일링이라는 기법을 사용합니다. 데이터 프로파일링(data profiling)은 데이터 속에서 비즈니스 규칙(business rule) 및 분석 알고리즘 툴을 사용해 데이터의 비일관성을 발견하는 방법입니다. 잘못된 데이터를 발견하고 개선시킬 수 있는 중요한 활동으로 DQMS(data quality management system) 없이는 하기 힘듭니다.


데이터 프로파일링을 통해 추출된 이상 데이터는 분석해서 개선(cleansing) 활동으로 이어집니다. 개선이 안 되는 경우도 있지만 언제가는 개선해야 하는 대상입니다. 지속적으로 모니터링을 해야 하는 것이죠.

데이터 품질 관리 유형

데이터 품질 관리에 대한 일반적인 내용을 간략하게 설명드렸고요. [그림 1]은 제가 생각하는 데이터 품질 관리 프레임워크입니다.





[그림 1] 데이터 품질 관리 프레임워크


표준 무결성이라고 하는 표준 데이터 유형에는 단어와 용어, 코드에 대한 무결성이 주를 이룹니다. 데이터 표준 관리 항목에 대해 표준 준수 여부를 체크하게 됩니다. 메타 데이터에 대한 품질 체크라고 볼 수 있습니다.
모델 무결성을 의미하는 데이터 구조 유형에는 엔터티, 관계, 속성이 있으며, 각각에 대해 결점이 없도록 하는 것이 엔터티 무결성, 참조 무결성, 도메인 무결성입니다. 정규화와 엔터티 통합 등의 엔터티 설계와 엔터티 간의 관계 등 모델 구조와 관련된 품질을 측정하여 개선하는 것을 의미합니다.


데이터 무결성을 의미하는 데이터 값 유형에는 주 식별자와 관계, 속성 등에 사용된 데이터 값 자체에 대한 무결성이 포함됩니다. 데이터 값에 대한 엔터티 무결성, 참조 무결성, 도메인 무결성, 업무 무결성이 이에 해당합니다.
[그림 1]과 같이 데이터 품질에 대해 검증해야 하는 영역은 크게 세 가지로 구분하고요. 각 영역에 대한 품질 기준을 수립해 품질 개선 작업을 수행하게 되는 것입니다. [그림 1] 프레임워크의 세 가지 유형을 간략하게 설명하겠습니다.

모델 무결성

세 가지의 품질 관리 유형 중에서 데이터 구조와 연관된 유형이 모델 무결성입니다. 데이터 모델에 결점이 없도록 관리하는 것을 의미합니다.
엔터티에는 주 식별자가 존재해야 한다(엔터티 무결성)는 것과 같은 기초적인 것에서부터 엔터티의 주 식별자는 슈퍼 식별자가 되면 안 된다는 등의 모델링 이론을 상세하게 반영한 요소들이 있을 것입니다.


이는 모델이 제대로 설계됐는지 확인할 수 있는 요소인데요. 체크해야 할 요소들이 모델 무결성의 대상이 되는 것입니다. 모델 무결성은 모델 검증과도 연관되고 모델링 자체를 의미하기도 해서 범위가 너무 넓습니다.
따라서 데이터 모델에 대한 검증 요소에 대해서는 이번 강의에서는 생략하고 기회가 있을 때 별도의 강의에서 설명하겠습니다. 제가 쓴 책(데이터 모델링 노트)에서도 모델을 검증하는 방법이 다소 있으니 참고하시기 바랍니다.

표준 무결성

데이터 품질 관련 활동에서 생소할 수 있는 영역이 표준 무결성입니다. 이는 데이터 모델의 근간이 되는 표준 데이터(단어, 도메인 등)에 대해 품질을 검증하는 것입니다. 표준 데이터를 관리하는 시스템이 있다면 그 시스템에 대한 품질 검증일 수도 있습니다.
사례를 간략하게 설명드리면요. 우선 단어는 표준어와 금지어로 구성돼 있는데요. 이중 금지어를 용어에 사용하고 있는지를 검증해야 합니다. 메타를 관리하는 시스템이 있음에도 이런 현상이 발생하는 경우가 있습니다. 복합어와 연관돼 단순하지 않을 수 있고요. 금지어가 나중에 추가될 수 있어 절차도 필요하고 주기적 점검도 필요합니다.


복합어도 검증해야 하는 대상입니다. 복합어가 존재하는데, 복합어를 단어로 분리한 형태로 영문 명을 사용하는 경우도 많습니다. ‘고객어의 조합인 ‘고객+번호’로 사용해 영문을 ‘CU_NO’로 사용하는 경우입니다. 같은 의미인데 컬럼 명이 달라지는 것이니 심각한 표준화 위반입니다. 데이터 타입까지 달라질 수 있어 더욱 그렇죠.


이음동의어와 동음이의어도 검증 대상인데요. 영문 명이 같은 단어가 있다면 이음동의어인 것입니다. 개인적으로는 허용하지 않는 것을 원칙으로 합니다. 이를 허용하지 않는다면, 영문 명이 같은 단어가 존재하면 안 되겠죠.
한글 명은 같은데 영문 명이 다르다면 동음이의어입니다. 동음이의어는 피할 수 없을 때가 있는데요. 이를 허용한다면 모든 동음이의어에 대해 컬럼 명이 제대로 사용됐는지, 다른 의미의 컬럼 명이 사용된 게 아닌지 검증해야 합니다. 예를 들어 수신일자 속성이 ‘Receive Date’의 의미인데, ‘Deposit Date’로 사용된 게 아닌지 일일이 검증해야 합니다.


분류어도 품질을 검증해야 할 중요한 요소입니다. 계좌번호 속성이 도메인 속성이 되면, 분류어도 됩니다. 만약 입금한 계좌번호를 의미하는 속성이 필요할 때는 ‘입금+계좌번호’로 사용해야 합니다. 그래야 ‘계좌번호’라는 도메인 속성을 사용해서 입금계좌번호 속성의 도메인이 계좌번호 속성의 도메인과 완전하게 일치하게 됩니다.


만약 ‘입금+계좌+번호’로 사용한다면, 입금계좌번호 속성에 ‘번호’라는 도메인을 사용한 것이니 도메인이 일치하지 않습니다. 입금계좌번호 속성이 Number(10)이 되고 계좌번호 속성이 Varchar(12)가 될 수 있는 것입니다. 이를 방지하기 위해서는 분류어인 도메인 속성을 제대로 사용했는지 시스템으로 검증해야 합니다.


자주 나오는 사례 몇 가지만 설명드렸습니다. 표준 원칙이 오류 없이 제대로 도출이 됐는지, 표준 원칙을 시스템이 제대로 반영하고 있는지, 표준 콘텐츠에 대한 품질이 좋은지 등을 검증하는 영역이 표준 무결성입니다.
표준과 관련된 품질 검증은 DQMS 시스템에서 데이터 전체를 대상으로 검증하지 않습니다. 콘텐츠가 쌓이면 그때그때 비정기적으로 수행하는 것이 좋습니다. 대량의 데이터가 아니기 때문이기도 하고, 기준 데이터이기 때문에 한 번 정돈되면 대개 문제가 없습니다.


표준 콘텐트는 데이터 모델의 기초 데이터로 사용되는 일종의 메타 데이터입니다. 속성에 지 저장된 실제 업무 데이터를 검증하는 게 중요하고 대부분의 표준 검증은 이에 해당합니다. 하지만 메타 데이터인 표준 콘텐츠도 제대로 생성되고, 결점이 없이 관리가 되고 있는지를 검증하는 것은 의미가 있습니다. 이를 간과하면 실제 데이터의 품질이 떨어지게 됩니다.

데이터 값 무결성 - 엔터티 무결성

데이터 값에 대한 품질 검증은 일반적으로 많이 알려진 방법입니다. 대개 데이터 품질이라고 했을 때 데이터 값을 의미하기 때문에 실무에서 사실상 이 부분에 대한 품질 점검을 수행합니다.


저는 데이터 값에 대한 무결성을 엔터티 무결성, 참조 무결성, 도메인 무결성, 업무 무결성으로 구분합니다. 실무에서는 이 중에서도 도메인 무결성만을 의미하는 경향이 있습니다. 품질 검증이라고 하면 속성에 저장된 값을 일일이 조사해서 잘못된 데이터를 찾고 바로잡는 일을 수행하게 됩니다. 속성에 사용된 데이터 값 자체에 대한 정합성과 무결성을 검증하는 것입니다.


그럼 엔터티 무결성부터 몇 가지 사례를 소개하겠습니다. 엔터티 무결성은 인스턴스 자체가 결점이 없다는 것을 의미합니다. 일반적으로 알고 있는 엔터티 무결성에는 주 식별자가 존재해야 한다는 것이 있습니다. 주 식별자는 인스턴스를 유일하게 만들어 결점이 없도록 하는, 인스턴스의 최소 요건을 만족시켜 주는 요소입니다.


주 식별자와 유사한 요소가 후보 식별자입니다. 후보 식별자에 속하는 속성은 모든 인스턴스에서 값이 유일해야 하죠. 따라서 후보 식별자에 대해 중복이 발생하는지를 검증하는 것이 엔터티 무결성에 속하는 사례입니다.
문제는 엔터티에 후보 식별자가 있는지를 알아내는 것과, 그 후보 식별자를 관리하는 것입니다. 어떤 식으로든 관리를 해야 대상 속성에 대한 값 유일성을 지속적으로 검증할 수 있습니다.


슈퍼 식별자에 대해서도 검증이 필요합니다. 원래 주 식별자가 ‘A+B’인데, ‘A+B+C’로 PK를 생성한 것이 이에 해당합니다. 이렇게 해도 인스턴스는 유일하므로 데이터는 생성이 되는데요. 필요 없는 속성이 추가된 것이니 유일성이 깨질 수 있습니다. 이때 ‘A+B’로 검증해서 2개 이상이 나오는 인스턴스에 대한 검토가 필요합니다.
슈퍼 식별자도 역시 찾아내는 것이 어렵습니다. 경험이 많은 모델러라도 슈퍼 식별자를 찾아내는 것은 쉽지 않을 것입니다. 제가 데이터 값으로 분류한 영역은 도메인 무결성을 제외하면 대체로 식별하는 것부터 어려운 작업이 됩니다.


정규화에 대한 검증도 엔터티 무결성에 포함됩니다. 묶음 속성으로 1정규화를 위반한 엔터티는 묶음 속성 중에서 주 식별자 성격을 찾아 그 값을 검증해야 합니다. 쌍을 맞춰서 값이 제대로 생성됐는지도 검증해야 하고요. 시스템으로 구현하기 어려운 검증 중에 하나일 텐데 중요한 엔터티가 1정규형을 위반했다면 반드시 검증해야 합니다.


주 식별자 일부에만 종속된 속성 값도 검증해야 합니다. 주 식별자 일부에만 종속된 속성을 별도의 엔터티로 분리하는 게 2정규화죠. 따라서 시스템에서 주 식별자 일부에만 종속된 속성의 값이 2개 이상인지를 검증해야 합니다. 3정규형 위반일 경우도 마찬가지입니다.
선분 이력 방식을 사용하는 엔터티일 경우, 시작일자와 종료일자가 직선이 되는지를 검증하게 됩니다. 만약 선분이 되지 않는다면 데이터의 품질이 떨어진 것이니 선분이 되도록 데이터를 수정해야 하고, 다시 생성되지 않도록 소스를 고쳐야 합니다.


또한 보관 주기가 있는 엔터티가 있습니다. 이를 메타 시스템에 등록해서 관리하면, 실제 엔터티에 입력된 일자와 보관 주기를 비교해서 만료된 인스턴스에 대해서는 보관 처리를 하게 되는데, 이것도 엔터티 무결성의 종류입니다.

데이터 값 무결성 - 참조 무결성

참조 무결성(referencial Integrity, RI)은 관계를 의미합니다. 따라서 이번 절에 소개되는 내용은 관계에 대한 것입니다. 참조 무결성 영역에서 가장 중요하고 기본적은 검증은 관계선으로 표현된 관계에 대해서 참조 무결성 관계인지를 DQMS에서 검증하는 것입니다.
이 부분은 현재 가장 많이 수행하는 품질 관리 활동 중 하나입니다. 사실 관계선이 표현돼 있다면 DB에서 참조 무결성 제약을 생성해야 하고요. 이렇게 RI 제약이 생성돼 있다면 DQMS 시스템에서 참조 무결성을 별도로 관리할 이유가 없습니다. 참조 무결성 제약이 DQMS 시스템이 하는 역할을 하니까요.


DB에 참조 무결성 제약이 없을 경우에만 DQMS에서 참조 무결성을 검증하게 됩니다. 많은 시스템이 DB에 참조 무결성 제약이 없기 때문에 이 부분이 가장 많이 수행되는 활동 중 하나입니다
코드에 대한 참조 무결성 검증도 많이 하게 됩니다. 공통 코드 엔터티와 코드를 참조한 엔터티의 코드값 RI를 검증하는 것입니다. 공통 코드 엔터티를 어떻게 설계하느냐에 따라 관계선이 있을 수 있는데요. 이때는 참조 무결성 제약의 존재 여부에 따라 DQMS에서 검증하게 됩니다.


배타 관계도 품질을 검증해야 하는 대표적인 관계입니다. 구분자 속성에 해당하는 배타 속성 값이 상위 엔터티에 존재하는지를 따져야 하는 것이죠. 배타 관계는 참조 무결성 제약을 생성할 수 없으니 DQMS 시스템에서 검증해야 하는 것 중 하나입니다. 관계의 중요성까지 생각하면 더욱 검증해야 하는 대상입니다.
특수한 관계비도 품질을 검증해야 하는 대상입니다. 만약 관계가 일대일 관계이면서, 일반 속성으로 상속된다면 관계비가 실제로 일대일인지 시스템으로 검증해야 합니다. 주 식별자로 상속된 일대일 관계는 검증할 필요가 없습니다. 이니까요. 필수 관계 또한 검증해야 합니다. 하위 엔터티에 해당 인스턴스가 반드시 있어야 하니까요.


추출 관계 또한 품질을 검증해야 합니다. 2차 이상의 관계인 추출 관계는 추출 관계에 의한 조인 값과 상위 엔터티와의 여러 차례의 조인을 통해 얻어지는 값이 일치해야 합니다. 이를 시스템에서 검증하게 됩니다.
이상으로 몇 가지 언급한 참조 무결성 검증 또한 우선 모델을 분석해야 합니다. 관계선으로 표현돼야 검증 대상임을 알 수 있는 것이죠. 모델링이 중요한 이유입니다. ERD 모델이 없다면 검증하기 매우 어렵고 체계적인 관리는 할 수 없습니다.

데이터 값 무결성 - 도메인 무결성

도메인 무결성은 속성에 저장된 값 자체를 검증하는 것입니다. 실무에서 수행하는 대부분의 데이터 품질 개선 활동이 이에 해당합니다. 예를 들어 가입일자 속성 값에 일자가 아닌 데이터가 존재하는지를 검증하는 것입니다.
속성의 도메인이 일자일 경우, ‘2045년 2월 30일’과 같은 데이터가 입력되지 않았는지, 월(VC)을 의미하는데 ‘13’ 값이 입력되지 않았는지, 여부의 경우 약속한 두 가지(Y, N)만 입력돼 있는지를 검증하는 것입니다. 이제까지 언급한 품질 무결성 중에 가장 쉽고 단순한 검증입니다.


유의미한 값이 반드시 입력돼야 하는데, ‘__‘, ‘00’ 등의 무의미한 값이 입력됐는지, 정해진 기본 값, 예를 들면 ‘999’이 사용돼야 하는데, ‘~~~’ 등의 다른 기본 값이 사용됐는지 등도 이에 해당합니다. 우편번호, 주민등록번호와 같이 패턴이 존재할 경우, 값이 패턴과 일치하는지도 검증 대상입니다.
도메인 무결성은 속성의 값만을 검증하는 단순한 검증입니다. 이미 많이 알고 있는 부분이기 때문에 넘어가겠습니다.

데이터 값 무결성 - 업무 무결성

업무 무결성은 아마도 매우 복잡한 품질 검증 방법일 거 같습니다. 시스템에서 구현하는 데 따른 어려움보다는 도출하는 데 어려움이 있을 것입니다. 업무를 따져서 도출해야 하기 때문에 업무를 모르면 도출할 수 없습니다.
사례 중에 시간 순서에 대한 무결성이 있습니다. 업무적으로 생성되는 시간적 순서가 명확하다면 이를 업무 무결성으로 도출해서 품질을 검증하는 것입니다. 예를 들어 주문일자 값보다 앞선 배송일자 값이 있다거나, 계약시작일자 값보다 앞선 계약종료일자 값이 있는지를 검증하는 것입니다.


데이터 간의 연관성도 업무 무결성에 해당합니다. 계좌 엔터티의 사고여부 속성은, 계좌사고내역 엔터티에 데이터가 존재할 때만 ‘Y’로 관리한다거나, 사고여부 속성 값이 ‘Y’일 때만 사고일자 속성 값에 데이터가 존재해야 한다는지 등이 데이터 간 연관성에 해당합니다.
업무적인 조건도 품질 검증 대상입니다. ‘주문이 3만 원 이상이면 배송료는 무료이다’, ‘초회 보험료가 납입된 일자가 보험시작일이다’ 등은 업무 조건에 의해서 상호 값이 결정됩니다. 이를 시스템에서 검증하는 것이 업무 무결성입니다.

마무리: 데이터 활용의 조건은 ‘품질’

데이터 품질 관리에 대한 내용은 책으로 한 권이 나올 정도로 방대합니다. 이번 강의에서는 개념만을 간략하게 설명했습니다. 빠지면 안 될 것 같아 소개만 하는 정도였지만 매우 중요한 영역이 데이터 품질입니다. 이 부분이 더욱 중요한 이유는 데이터 모델과 직접 연관되기 때문입니다.
현재는 빅데이터 산업의 영향으로 데이터의 양에만 치우친 모습입니다. 해당 분야의 전문가들은 알겠지만 품질이 떨어지는 데이터는 아무리 많아도 효용 가치가 떨어집니다. 활용하기 위해서는 품질을 좋게 만들어야 하는 행위를 별도로 해야 합니다. 잘 안 되는 게 문제지만, 그나마도 이렇게 품질관리 활동을 하면 다행입니다. 품질을 무시하고 존재하는 데이터를 그대로 활용만 하기도 합니다.


데이터의 품질에는 관심이 없고 데이터의 용량에만 관심이 많은 세태가 안타깝습니다. 기초와 기반이 무너졌을 때는 복구하기 더 힘들어집니다. 양보다 질이 선행돼야 하고, 잘못된 데이터가 생기지 않도록 하는 일이 선행돼야 합니다.
여러 가지 사정으로 품질이 많이 떨어진 상태라면 이번 강의에서 설명한 다양한 방법을 활용해 데이터 품질을 높여야 합니다. 이게 선행되지 않고서는 결과는 의미 없습니다. 그저 얼만큼 많은 데이터를 사용해서 나온 결과인지만을 강조하기 위함입니다.


데이터의 품질을 높이기 위해서는 근본적으로는 데이터 모델의 품질이 향상돼야 합니다. 데이터를 저장하는 곳이 제대로여야 데이터가 제대로 저장되는 건 너무 당연한 것입니다. 내용물에 맞도록 박스를 만들어야죠. 아무 내용물이 들어갈 큰 박스 몇 개를 만드는 건 적절하지 않습니다.
데이터의 품질을 근본적으로 향상시키는 데이터 모델과 잘못된 데이터를 적극적으로 찾아 수정하는 데이터 품질 활동이 중요하다는 점을 다시 한 번 강조하면서 이번 강의를 마무리하겠습니다.


2017년 중순부터 연재한 ‘김기창의 데이터 모델링 강의’의 마지막 강의인 다음 강의의 주제는 모델러입니다. 연재의 첫 강의를 준비하면서 마지막은 역시 모델러에 대한 내용으로 마무리해야겠다고 생각했습니다. 어떻게 하면 모델러가 될 수 있는지, 어떤 준비를 해야 하는지 등에 대한 개인적인 생각입니다. 실무를 통해 많은 모델러를 만났고, 강의나 교육도 적지 않게 한 경험담일 수도 있습니다. (다음 회에 계속)