차세대 프로젝트 경험 기반 재구성 사례
차세대 프로젝트에서 품질대상을 선별해 규칙 세팅과 진단을 수행하며 전반적인 데이터 품질의 개념과 경험을 기반으로 구성한 사례로 품질 진단 방식에 대해서 공유합니다.
제가 경험한 프로젝트는 전환과 초기 적재 대상을 기준으로 품질 진단을 했으며, 일반적으로 일시적 용도의 임시 테이블, 단순 로그 테이블, 외부 연계용 테이블, 솔루션에서 관리하는 테이블은 품질 진단 대상에서 제외합니다.
데이터 품질 진단대상은 프로젝트마다 기준이 다를 수 있다는 점은 참고하시길 바랍니다.
1. 데이터 품질 진단의 시작
품질 진단은 “무엇을 볼 것인가”를 결정하는 과정입니다.
대상의 기준은 품질 진단에서 신뢰성과 객관성을 결정하는 출발점이라 볼 수 있습니다. 품질대상의 기준이 정의되면, “어디에 어떤 규칙이 필요한지”가 명확해집니다.
2. 데이터 품질 진단 과정
데이터 품질 진단을 하기 위해서 품질 진단 대상 선정이 필요합니다.
대상이 선정되면, 해당 테이블에 존재하는 컬럼마다 품질 진단 규칙 대상인지 확인 후 규칙을 설정합니다. 모든 품질 진단 항목의 규칙 설정이 완료되면, 진단을 실행합니다.
일반적으로 데이터 품질 진단은 전환 이후의 TO-BE 데이터 검증을 위해 수행되지만, 모든 품질 활동이 전환 프로젝트에 한정되는 것은 아닙니다.
실제 운영(SM) 과정에서도 이상 데이터 탐지, 품질 지표 모니터링, 규칙 개선 등을 위해 지속적으로 품질 진단이 이루어질 수 있습니다.
따라서 본 글에서 다룬 사례는 AS-IS 데이터를 TO-BE 구조로 전환한 이후, 초기 적재 데이터의 품질을 검증하는 단계에 초점을 맞추고 있습니다.
다만, 데이터 품질 프로세스 전체는 프로젝트의 목적·데이터 특성·운영 방식에 따라 달라질 수 있다는 점을 함께 참고해 주시기 바랍니다.
진단 수행 완료 후 품질 진단결과서를 통해서 응용 팀에게 오류 데이터 개선활동 요청합니다.
개선 방안은 품질 담당자와 전환 담당자의 역할에 따라 분리됩니다.
진단 규칙 변경 사항은 품질 담당자가 규칙 수정 및 진단 재실행을 통해 직접 조치하며,
매핑 룰 변경이 필요한 경우에는 응용 팀 요청을 통해 전환 팀이 수정·재전환을 수행한 뒤
품질 담당자가 재진단으로 개선 여부를 최종 확인합니다.
[그림 1] 데이터품질 진단과정
3. 품질 진단 대상 선정의 핵심 기준
품질 진단 대상 기준은 5가지로 나눌 수 있습니다.
첫째, ‘데이터 활용도 기준’으로 실제 업무 시스템에서 자주 조회•갱신•분석되는 데이터를 말합니다. 둘째, ‘데이터 중요도 기준’ 의사결정•성과 지표에 직접 사용되는 데이터로 매출 집계, 고객 등급 정보를 사례로 들 수 있습니다.
‘전환 •적재 기준’ 데이터 전환 대상 및 초기 적재 대상 데이터, ‘업무 프로세스 연계성 기준’ 다른 업무와 참조 관계를 많이 맺는 데이터, ‘품질 리스크 기준’ 오류 발생 시 업무에 큰 장애를 일으킬 수 있는 데이터 중에서 기준을 정할 수 있습니다.
품질 진단 대상 기준을 정함으로써, 업무상 핵심 데이터를 빠짐없이 진단 및 검증하며 제한된 자원 안에서 효율적으로 품질 관리 범위를 설정할 수 있습니다.
아래 ERD(Entity Relationship Diagram)를 통해 품질 진단 대상의 기준을 선정 후 품질 진단규칙 컬럼과 진단 방식에 대해서 파악해 보고자 합니다.
실무에서 가장 빈번히 활용되는 회원·주문·상품 테이블을 진단 대상으로 설정하고, 해당 테이블 내 핵심 품질 진단 컬럼을 대상으로 분석하겠습니다.
[그림 2] ERD(Entity Relationship Diagram) 사례
다음 “4. 진단 항목 컬럼 품질 규칙 세팅 기준”에서 [표 1]을 참고해 품질지표로 무엇이 있는지 테이블의 컬럼을 보면 품질 진단 대상으로 쉽게 식별할 수 있습니다.
회원·주문·상품 테이블에 포함된 컬럼에 따르면, 번호, 아이디, 코드, 일자, 여부, 금액으로 끝나는 컬럼이 품질 진단 대상임을 알 수 있습니다.
4. 진단 항목 컬럼 품질 규칙 세팅 기준
완결성, 유효성, 정합성으로 품질지표를 세분화해서 나눌 수 있습니다.
경험한 차세대 프로젝트에서 규칙을 세팅할 때는 완결성 지표를 제외하고, 유효성(날짜·번호· 여부·코드)과 정합성(논리 관계 일관성·시간 순서 일관성· 참조 관계)를 중심으로 작업을 진행했습니다. 이번 글에서는 이러한 경험을 바탕으로 구성한 예시를 활용해 품질 지표별 진단 과정을 살펴보고자 합니다.
[표 1] 품질지표
[표 1] 을 토대로 진단 대상 컬럼에 대한 규칙 설정 시 필요한 정보와 어떻게 품질 진단을 하는지 파악해 보겠습니다.
대표적으로 회원 테이블과 주문 배송 테이블에 포함된 컬럼을 가지고 품질 진단해 보겠습니다.
- 회원
– 번호(회원번호, 휴대전화번호), 아이디(회원아이디)
– 코드(회원상태코드, 성별코드), 여부(탈퇴여부)
- 주문배송
– 번호(배송번호), 코드(배송상태코드)
– 일자(배송시작일자/배송종료일자), 시간순서일관성(배송시작일자/배송종료일자)
아래 내용은 실제 프로젝트 사례가 아닌, 제 경험을 토대로 구성한 예시이며, 품질 진단 과정을 이해하기 위한 설명용입니다. 따라서 프로젝트 환경에 따라 방식은 달라질 수 있습니다.
첫 번째, “번호” 컬럼입니다. 번호컬럼은 해당 도메인에 대한 명확한 체계가 존재하면, 정규식이나 패턴분석을 통해 품질 진단을 할 수 있습니다.
예를 들어 휴대전화번호의 체계는 10자리 또는 11자리로 다음과 같이 ‘0[0-9]{2}-[0-9]{3,4}-[0-9]{4}’ 정규식으로 표현할 수 있습니다.
[그림 3] 휴대폰번호 오류검사 쿼리(정규식)
프로젝트에서 사용한 품질 진단 솔루션에서 정규식이 아닌 패턴으로 진단이 가능하므로
N: 숫자, X:문자로 설정되어 있었습니다.
따라서 위 정규식이 아닌 패턴으로 “휴대전화번호” 품질 진단이 가능합니다.
[그림 4] 휴대전화번호 오류검사 쿼리(패턴)
휴대전화번호처럼 자릿수가 10~11자리로 고정된 단순 도메인은
정규식 대신 패턴 분석만으로도 충분하고, 오히려 검사 속도와 안정성 측면에서 더 유리하다는 장점이 있습니다.
품질 진단의 주목적은 단순한 진단 수행이 아니라, 진단 결과를 토대로 데이터 구조와 운영 방식을 개선하는 데 있습니다.
번호에 따른 오류 데이터 발생 시 번호 체계에 맞게 특수문자 제거와 같이 매핑 규칙 변경을 통해 처리하며, 해당 번호에 따른 도메인 설정 오류는 품질 진단 규칙 재정의가 필요합니다. 번호 도메인이 잘못 정의되어 해당 컬럼이 실제 업무 체계와 맞지 않거나 예외 형식이 혼재되어 기존 규칙만으로는 정확한 검증이 어렵습니다.
따라서 신규 도메인을 정의하고 이를 반영하여 품질 진단 규칙을 재설정합니다.
두 번째, “아이디” 컬럼입니다. 아이디컬럼은 번호컬럼과 동일하게 아이디 도메인에 대한 명확한 체계가 존재하면 품질 진단을 할 수 있습니다.
예를 들어 회원아이디 도메인이 ‘E + 숫자 4자리’ 형태(E0001)’로 설계되었다면,
이를 검증하기 위한 정규식은 ‘E[0-9]{4}’ 로 정의할 수 있습니다.
[그림 5] 회원아이디 오류검사 쿼리
세 번째, “코드” 컬럼 입니다.
코드컬럼은 공통코드(단일코드) 또는 목록코드인지 판단 후, 해당 코드에 등록된 코드값에 있는 값인지 점검하기 위한 목적이라 볼 수 있겠습니다.
품질 진단을 하기 위해서 공통코드 경우, 공통코드 테이블명, 코드값 컬럼, 코드 컬럼이 있어야 하고, 목록코드인 경우 목록 코드명, 코드값명컬럼, 코드값 테이블 즉, 목록 테이블의 정보가 필수적입니다.
‘성별코드’가 목록코드일 경우, 해당 코드에 대한 코드값 정보는 아래와 같이 가정했을 때 품질 진단을 해보겠습니다.
– 목록테이블명: 성별코드(TB_GENDER_C)
– 컬럼명: 성별코드(GENDER_CD)
– 코드값명컬럼: 성별코드명(GENDER_CD_NM)
[그림 6] 성별코드 오류검사 쿼리
코드컬럼 품질 조치 방안은 누락된 코드값 존재 시 추가하거나 잘못된 코드값 존재할 경우 수정, 데이터 보정으로 개선할 수 있습니다.
네 번째, “여부” 컬럼입니다. 여부컬럼은 Y,N 값을 제외한 값은 오류 데이터로 진단했습니다. 프로젝트에 따라 Y/N이 아닌 0/1, y/n 등이 여부컬럼의 기준값이 될 수 있습니다.
[그림 7] 탈퇴여부 오류검사 쿼리
다섯 번째, “일자” 컬럼입니다. 일자에 대한 데이터 형식에 따라 도메인 표현식은 달라질 수 있습니다. 주문 배송의 배송 시작 일자가 VARCHAR2(8): YYYYMMDD 날짜 유형인 경우, 아래와 같이 품질 진단을 했습니다. 같은 날짜 유형이면, SQL 참고해서 컬럼만 변경 후 동일하게 진단할 수 있겠습니다.
[그림 8] 배송시작일자 오류검사 쿼리
‘여부’와 ‘일자’ 컬럼의 개선방안은 일반적으로 데이터 확인 및 불필요한 공백 제거 후 자릿수에 맞게 날짜 형식으로 보정, 0/1 -> Y/N으로 매핑룰 수정이 있습니다. 예외로 Y/N 이외 값도 여부의 정상 데이터로 프로젝트에서 기준인 경우, 코드컬럼으로 판단되어 위 ‘성별코드’의 품질 진단 방식으로 수행 및 개선방안을 활용하시면 좋을 것 같습니다.
여섯 번째, “시간 순서 일관성”입니다.
한 테이블에 ~시작 일자,~종료 일자 쌍으로 구성된 경우 시작일이 종료일보다 나중인 경우가 존재하는지 진단하는 품질지표입니다.
다음은 주문 배송 테이블에서 배송 시작 일자와 배송 종료 일자에 대해 시간 순서 일관성 진단을 해보겠습니다.
[그림 9] 시간순서일관성 오류검사 쿼리
시간 순서 일관성의 경우, 오류 데이터 존재할 시 데이터 확인 후 보정하거나 업무적 허용 가능성 있다고 판정되면 진단규칙 제외로 조치할 수 있습니다.
일곱 번째, “참조 관계”입니다.
참조 관계는 자식 테이블에서 참조하는 컬럼에 부모 테이블에서 참조되는 컬럼에 없는 경우가 있는지 판단하는 것이 목적입니다.
참조 관계 품질 진단을 하기 위해서, 부모 테이블명, 참조되는 부모 테이블의 컬럼명, 자식 테이블명, 참조하는 자식 테이블의 컬럼명의 정보가 필요합니다.
다음은 주문과 주문 상품 엔터티 간 참조 컬럼인 주문번호에 대해서 품질진단 쿼리입니다.
[그림 10] 주문-주문상품 간 주문번호 참조 무결성 오류검사 쿼리
자식 테이블에 있지만, 부모 테이블에 없는 주문번호일 경우 해당 데이터 누락인지 확인 및 해당 관계 규칙에 있어서 예외로 진단 항목에서 제외될 수도 있습니다.
5. 마무리하며..
데이터 품질 설계의 첫 단추는 “관리 대상을 어디까지 둘지 명확히 정의하는 것”입니다. “품질은 점검이 아니라 설계다”를 주제로 잡은 이유도 여기에 있습니다.
실제로 품질활동의 대부분 진단을 실행하기 전 단계에서 이미 방향이 결정됩니다.
어떤 데이터를 진단 대상으로 정의하고, 품질지표에 따라 진단 항목을 설계하며, 이를 검증하기 위한 규칙을 세팅하는 과정이 전체 품질 진단의 구조와 품질 수준을 사실상 좌우합니다.
제 개인적 견해로는, 이러한 점에서 점검보다 설계 단계가 데이터 품질을 결정하는 핵심 요소라고 생각합니다.
다만 실제 프로젝트를 수행하면서 몇 가지 한계도 경험할 수 있었습니다. 프로젝트마다 특성이 달라 데이터 품질의 기준이 동일할 수 없지만, 전반적인 품질 진단 업무를 수행하면서 정확한 기준이 없어 모호하게 다가오는 부분이 있었습니다.
따라서 품질 진단에 있어서 공통적으로 맞출 수 있는 기준을 모색해 정할 필요가 있다고 생각합니다.
또한, DQ 솔루션의 기능적 제약으로 인해 여전히 수작업에 의존해야 하는 영역이 많았고, 이 과정에서 관리 대상 누락이 발생할 수 있다는 한계를 체감했습니다.
특히 명확한 규칙 정의와 자동화 체계가 구축되지 않은 상태에서는 진단, 검증, 리포팅 전반이 사람의 판단과 작업에 의존할 수밖에 없었고, 그 결과 실수로 인한 누락이나 기준 적용의 불일치가 반복적으로 발생했습니다. 이러한 경험을 통해 수작업 중심 품질 운영의 구조적 한계를 인식하게 되었고, 이를 개선하기 위해서는 명확한 규칙 세팅을 자동화할 수 있는 진단 쿼리 고도화를 해보고자 합니다.
참고문헌
행정안전부, https://data.go.kr/ (공공데이터포털), 공공데이터 품질관리 매뉴얼 ver 2.1
과학기술정보통신부, https://www.msit.go.kr/ , 데이터 품질인증 가이드라인