문서요약 - 데이터 품질 문제의 원인 by Maydanchik

제목: 데이터 품질 문제의 원인(Causes of Data Quality Problems)

저자: Arkady Maydanchik

문서유형: 책 “Data Quality Assessment”의 제 1장, 2007년

 

 

데이터의 품질에 부정적인 영향을 미치는 13가지 프로세스에 대하여 기술한 자료

 

---

 

데이터 품질에 영향을 주는 13개 프로세스

아래 그림은 데이터 문제를 초래하는 13개 프로세스를 보여줌(3개 상위 카테고리로 묶임)

 

 

• 좌측 그룹은 수동으로 또는 다양한 인터페이스와 데이터 통합 기법을 통해 데이터를 외부로부터 데이터베이스(DB)로 가져오는 프로세스들. 유입되는 데이터의 일부가 애초부터 부정확한 채 단순히 한 곳에서 다른 곳으로 이주되었거나, 또는 데이터 추출, 변형, 로딩 프로세스 동안 에러가 생겼을 수도 있다.
• 하단 그룹은 DB 내에서 데이터를 조작하는 프로세스들. 일부는 일상 업무이며, 다른 일부는 주기적 시스템 업그레이드, 대규모 데이터 업데이트, DB 재설계, 다양한 임시적/즉흥적(ad hoc) 활동에 의해 일어난다. 대개 이런 작업을 위한 시간/자원이 부족하고, 데이터 품질에 미칠 영향을 이해하는데 필요한 메타데이터가 부족한 것이 현실임. 따라서 이 내적 데이터 프로세싱이 여러 데이터 문제로 이어지는 것이 놀라운 일이 아님
• 우측 그룹은 어떤 물리적 변경 없이도 정확한 데이터를 시간 경과에 따라 부정확하게 만드는 프로세스들. 데이터 값은 변경되지 않지만 그 정확성은 곤두박질침(대개 데이터에 의해 표현되는 현실 세계 오브젝트가 변화하는데 데이터 수집 프로세스가 이 변화를 포착하지 못할 때 발생). 오래된 데이터가 점차 부정확하고 쓸모 없게 됨

 

1. 초기 데이터 전환(Initial data conversion)

• DB가 빈 상태로 그 생명 주기를 시작하는 경우는 드물며 기존의 어떤 데이터 소스로부터의 데이터 전환이 그 시작점인 경우가 많음
• 데이터 전환은 시스템 구현의 가장 어려운 부분이며, 새롭게 채워진 신규 DB의 에러율이 기존 소스 시스템의 에러율 보다 높을 수도 있다. 즉, 데이터 전환이 데이터 문제의 주요 소스이며, 회사는 좋지 못한 데이터 전환의 결과를 수 년 또는 수십 년 안고 가게 됨
• 데이터 전환을 위험하게 만드는 이슈:
  1) 시스템은 3개 층(데이터베이스, 비즈니스 규칙, 사용자 인터페이스)으로 구성되며, 따라서 사용자의 눈에 보이는 것이 실제 DB에 저장된 것은 아니다. 데이터 전환 동안 데이터 구조(즉, 구 DB와 신 DB 간 데이터 매핑)에 관심이 집중되지만, 소스 시스템과 타겟 시스템의 비즈니스 규칙 층이 다르므로 전환된 데이터가 기술적으로는 정확해도 실무적인 용도로는 부정확할 수 있다.
  2) 소스 DB에 대한 신뢰할만한 메타데이터가 결여됨. 불완전하고, 부정확하고, 쓸모 없어져버린 메타데이터 상에 구축된 명세에 따라 데이터 전환이 이루어짐
• 위에서 전환 프로세스에 의해 도입되는 데이터 문제를 서술했지만 소스 데이터 자체도 절대 완전하지 않음. 즉, 기존의 잘못된 데이터가 전환 동안 바이러스처럼 변형되거나 번져나가는 경향이 있다.

 

2. 시스템 통합(System consolidations)

• IT 분야에서 흔하게 일어나는 DB 통합은 구 시스템이 단계적으로 폐지되거나 합쳐질 때 수행됨. 또한 회사의 인수/합병 시 항상 뒤따라오는 작업
• 기업 합병 후 DB 통합은 특히 골칫거리인데, 대개 계획에 없었던 일이고, 불합리하게 짧은 기간 내에 완수되어야만 하고, IT 부서 간 문화적 충돌이 한창일 때 행해지며, 프로젝트 중도에 핵심 인물이 떠나면 전문 지식의 손실이 필연적으로 따르기 때문이다.
• 데이터 통합은 ‘초기 데이터 전환’이 처한 것과 동일한 어려움에 직면하지만 그 정도가 훨씬 더 심하다(통합의 개념이 완전 새로운 차원의 복잡성을 더함). 구조를 변경할 여지가 별로 없거나 아예 없는 기존의 DB(이미 데이터가 채워져 있음)로 병합되어야 하는데, 새 데이터가 여기에 들어맞지 않을 수 있음. 또한 통합된 시스템에서의 데이터가 종종 겹침에 따라 중복(duplicates)과 데이터 충돌 발생
• 데이터 통합은 데이터 문제의 주 원인 중 하나이며 따라서 조심스럽게 다루어져야 한다.

 

3. 수동 데이터 입력(Manual data entry)

• 높은 자동화에도 불구하고 여전히 많은 데이터가 다양한 폼(forms)과 인터페이스를 통해 사람에 의해 DB로 입력됨. 데이터 부정확성의 가장 흔한 소스가 수동으로 데이터를 입력하는 사람이 실수를 범하는 것(예, 키를 잘못 누름, 리스트에서 잘못된 엔트리 선택, 올바른 데이터 값을 틀린 박스에 입력 등)
• 복잡하고 불편한 데이터 입력 폼(또는 윈도우와 웹 기반 인터페이스)이 데이터 입력을 더 복잡하게 만들어 에러 수를 크게 증가시킬 수 있음
• 결측값(missing values)을 어떻게 다루는지도 흔한 데이터 입력 문제. 사용자가 다양한 타입의 결측값에 동일한 공백값(blank value)을 할당하거나, 공백이 허용되지 않으면 종종 의미 없는 대체 값을 입력하기도 함
• 데이터 입력 폼에 있는 디폴트 값이 손을 타지 않은 채 그대로 남겨지거나, 리스트 박스의 첫 번째 엔트리가 다른 엔트리보다 더 자주 선정됨
• 좋은 데이터 입력 폼과 지침(설명)이 데이터 입력 문제를 다소 완화시킴. 하지만 현실에서 데이터 입력이 만만한 작업이 아니라 수동 데이터 입력이 항상 데이터 문제의 중요 원인으로 남을 것이라는 점을 받아들여야 함

 

4. 배치 피드(Batch feeds)

• 배치 피드는 시스템 간 정기적인 대량 데이터 교환 인터페이스이다. 그 수가 계속 증가 중인 업계의 DB들이 배치 피드의 복잡한 거미줄을 통해 의사소통 함
• 각각의 배치가 대량의 데이터를 담고 있는데, 이 데이터에서의 어떤 문제가 향후 피드에 의해 더 확대되며 큰 혼란을 야기할 수 있음. 각 개별 피드가 지나치게 많은 에러를 초래하지 않을지는 몰라도 문제가 한 배치로부터 다른 배치로 가며 점차 축적되는 경향이 있다. 또한 지속적으로 증가하는 백로그를 바로잡을 기회가 별로 없다.
• 잘 테스트된 배치 피드가 문제가 되는 이유는 배치 피드를 발원하는 소스 시스템이 빈번한 구조적 변경/업데이트/업그레이드를 겪기 때문이다. 이런 변경에 모든 다운스트림 시스템이 영향을 받으므로 각 다운스트림 배치 피드가 재평가되어야 함. 하지만 다수의 독립적인 다운스트림 DB로 공급되는 데이터 피드에 어떤 변경이 무슨 영향을 주는지를 테스팅하는 것이 현실적으로 어려움. 그 결과 회귀 테스팅과 품질 보증의 결여가 소스 시스템이 변경될 때마다 배치 피드 관련 다양한 데이터 문제로 이어지게 됨

 

5. 실시간 인터페이스(Real-time interfaces)

• 점점 더 많은 데이터가 실시간(또는 준 실시간) 인터페이스를 통해 시스템 간에 교환됨. 즉, 데이터가 어떤 한 DB에 들어오자마자 다른 다운스트림 DB로 트랜잭션을 보내는데 필수적인 절차를 트리거 한다.
• 데이터가 즉각적으로 모든 관련 DB로 전달되므로 데이터가 맞지 않을(out-of-sync) 가능성이 적다. 하지만 너무 빠르게 전파되다 보니 데이터가 정확한지 검증할 시간이 없음(기껏해야 개별 애트리뷰트의 유효성이 체크됨)
• 또한 데이터 문제가 식별될 수 있다 하더라도 이에 대응할 상대편이 없음(트랜잭션은 반드시 수락되거나 또는 거부되어야 하며, 데이터가 거부되면 영원히 잃게 될 수도 있음)
• 빠른 전달의 대가로 종종 데이터 품질이 희생되는 점을 인지해야 함. 구 배치 피드가 새 실시간 인터페이스에 의해 교체될 때 데이터 품질 저하의 잠재 비용을 평가하고 이것을 빠른 데이터 전파의 장점과 비교해 가늠해야 한다.

 

 

6. 데이터 프로세싱(Data processing)

• 데이터 프로세싱(사용자가 트리거한 정기 트랜잭션부터 연말 대량 계산 및 조정까지 많은 모양과 형식을 가짐)은 모든 운영 시스템의 중심에 위치. 이론상으로는 시계처럼 돌아가는 반복 프로세스이지만 프로그램과 기저 데이터 둘 다 변하고 진화하므로 실제는 전혀 고정적이지 않음
• 정기적인 데이터 프로세싱을 책임지는 프로그램의 소소한 변경과 수정이 일상적인데, 이런 작은 변경은 별로 영향을 미치지 않는다는 잘못된 인식으로 종종 제대로 테스트가 안됨. 하지만 코드의 작은 버그도 백만 개 레코드에 적용되면 백만 개 에러를 순식간에 생성하는 점에 유의해야 함
• 정기 프로세싱을 책임진 프로그램이 새로운 수집 절차로 인해 야기된 데이터의 변화에 뒤처짐. 변화된 새 데이터가 DB로 들어갈 때는 괜찮아 보였어도 정기 프로세싱에서 잘못된 결과가 생성되게 만들 정도로 다를 수 있음
• 프로세싱이 실수로 잘못된 시간에 수행되면 데이터가 있어야 할 상태에 있지 않아서 올바른 프로그램도 틀린 결과를 만들어냄
• 이론상으로는 DB에 무슨 일이 진행 중인지 그리고 어떻게 여러 프로세스가 서로 연관되어있는지에 대한 완전한 그림을 문서화해서 문제를 해결하는 것이 가능(즉, 코드, 프로세스, 데이터 구조, 데이터 수집 절차에서의 변경이 데이터 품질에 어떤 영향을 주는지 분석해 예상 못한 데이터 에러를 제거함). 하지만 현실적으로는 이것이 불가능하며, 그런 이유로 DB 내 정기 데이터 프로세싱이 항상 데이터 문제의 원인이 됨

 

7. 데이터 클린징(Data cleansing)

• 데이터 클린징이 높은 데이터 품질을 얻고자 하는 본연의 목표에도 불구하고 문제를 수정하기 보다는 더 많은 데이터 문제를 만들어 내기도 함
• 데이터 클린징이 위험한 이유는 데이터 품질 문제가 대개 복잡하고 서로 연결되어 있기 때문. 한 문제를 수정하면 동일한(또는 다른 관련) 데이터 요소에서 많은 문제가 생길 수 있음. 예, 고용 이력은 직위 이력, 급여율 이력, 기타 많은 고용 데이터 애트리뷰트와 밀접히 연결되어 있으며, 이 데이터 카테고리들 중 하나에 수정을 가함으로써 다른 모든 카테고리들과 데이터가 비일관적이 될 수도 있음
• 자동화된 데이터 클린징 알고리즘도 결국 컴퓨터 프로그램이므로 필연적으로 버그를 가지게 됨. 이런 알고리즘에 있는 버그는 종종 수천 개의 레코드에 영향을 미치기 때문에 매우 위험
• 데이터 품질 명세가 종종 실제 데이터 요구사항을 반영하지 못함. 그 결과 데이터가 어떤 이론적 모델에 부합할지는 몰라도 실제 용도로는 부정확
  예) 수 차례 인수 이력이 있는 회사의 HR 시스템 고용 이력 데이터를 클린징하는데 있어 많은 직원의 고용 일자가 누락되었거나 부정확한 것이 발견됨(퇴직 연금 계산에 이 데이터가 꼭 필요). 클린징 작업자는 여러 레가시 데이터 소스에 접근해 해당 문제를 수정하는 알고리즘을 개발함. 하지만 많은 직원이 현 회사에 의해 직접 고용되지 않고 과거 다양한 인수를 통해 합류했으며, 연금 계산에 인수 이전의 과거 고용 기간은 포함 안됨. 즉, 시스템이 직원의 ‘최초 고용 일자’ 필드에 입력되길 원한 것은 ‘인수 일자’인데 주어진 데이터 품질 명세가 이를 반영하지 않았고, 결국 틀린 클린징을 하게 됨
• 요약하면 데이터 클린징은 신중하게 사용되지 않으면 도움 보다는 오히려 해가 되는 양날의 칼이다.

 

8. 데이터 퍼징(Data purging)

• 더 많은 데이터를 위한 자리를 만들기 위해 구 데이터가 정기적으로 시스템에서 제거됨. 보유 한계에 도달하였고 오래된 데이터가 더 이상 필수적이지 않은 경우 데이터 퍼징이 정상적인 작업이지만 데이터 품질에 높은 위험을 가져온다.
• 데이터가 제거될 때 실수로 관련 데이터도 제거되는 위험이 항상 존재. 퍼징 프로그램이 단순히 실패하거나, 또는 시스템 업그레이드/데이터 전환 등으로 인해 지난 퍼징 이후로 데이터 구조가 변경되었을 수도 있음(이로 인해 퍼징이 잘못된 데이터에 영향을 미치게 됨). 의도한 것보다 많은 데이터가 제거되거나 또는 의도 보다 적게 제거됨(DB에 불완전 레코드를 남기므로 이것도 마찬가지로 문제임)
• DB에 틀린 데이터가 있을 때는 상황이 더 복잡해짐. 틀린 데이터가 우연히 퍼징 기준에 들어 맞아 남아있어야 함에도 제거되거나 또는 제거되어야 하는데 남아 있게 됨
  예) HR 시스템이 회사를 떠난 지 5년이 넘은 모든 종업원의 데이터를 제거하도록 설정되면서 잘못 입력된 퇴직 일자를 가진 일부 직원의 레코드도 제거해 버림

 

9. 포착 안된 변화(Changes not captured)

• 단순히 기술하고 있는 오브젝트가 변해버려서 데이터가 쓸모 없게(부정확하게) 되기도 함
• 데이터가 점차 현실과 동떨어지게 되는 이런 상황이 사람 사는 세계에서 아주 흔하며, 이는 필연적으로 점진적 데이터 쇠퇴(그리고 데이터 품질 저하)로 이어진다.
• 데이터는 실 세계 오브젝트를 사실대로 표현할 때만 정확함. 하지만 이는 완벽한 데이터 수집 프로세스를 가정한 것이며 실상은 오브젝트의 변화를 컴퓨터가 눈치 못 채고 지나갈 때가 많다. 사람들은 이사하고, 결혼하고, 심지어 자신의 데이터가 저장된 모든 시스템에 이런 이벤트를 기록하기 전에 죽는다. 그래서 같은 사람에 대한 데이터가 시스템마다 전혀 다를 수 있으며, 이는 통합 시 어려움을 준다.

 

10. 시스템 업그레이드(System upgrades)

• 대부분의 상업 시스템이 몇 년마다 업그레이드됨. 인하우스 개발 소프트웨어는 한 해에도 여러 번 업그레이드 되기도 함. 업그레이드가 시스템 전환과 통합만큼 파괴적이고 고통스럽지는 않을지 몰라도 여전히 데이터 문제를 만든다.
• 현실의 데이터는 데이터 모델과 데이터 사전에 기술된 것과 꽤 다름. 데이터 필드가 잘못된 목적에 사용되거나, 일부 데이터가 분실되었거나, 일부는 이전 버전에서 허용되는 폼에 맞추어져 있다. 과거 세대의 산물로써 무해하게 자리만 차지하고는 있어도 절대 건드리면 안 되는 데이터도 있음. 업그레이드는 이런 모든 문제를 드러나게 만든다.
• 업그레이드가 데이터의 실제 모습이 아닌 기대 모습을 겨냥해 설계되고 테스트 되는 경우가 많은데, 일단 업그레이드가 구현되면 걷잡을 수 없게 됨. 과거에는 잘 돌아가던 시스템이 그리고 테스팅 환경에서도 잘 되던 새 버전이 왜 갑자기 전혀 동작하지 않는지 골머리를 않는 일이 심심치 않게 발생함
• 시스템 업그레이드는 대개 앞에서 언급한 데이터 쇠퇴 프로세스를 통해 데이터 품질에 영향을 미친다. 하지만 시스템 업그레이드가 실질적인 재구조화와 기존 데이터의 대규모 업데이트를 요구하기도 함. 믿을만한 메타데이터가 없는 상황에서의 이런 변경은 많은 수의 데이터 에러로 이어진다.

 

11. 새로운 데이터 용도(New data uses)

• 데이터 품질이 “사용 목적에 부합하는 정도(fitness to the purpose of use)”로 정의됨
• 데이터가 어떤 한 목적에는 적합해도 다른 목적에는 그렇지 못할 수도 있다. 즉, 기저 데이터(underlying data)가 동일하다 할지라도 새로운 데이터 용도가 데이터 품질 인식 수준에 변화를 가져올 수 있다.
• 새로운 용도가 데이터 정확성에 특히 중요도를 둘 수도 있음. 예, 고객 주소의 15% 에러율이 텔레마케팅 목적으로 사용될 때는 괜찮았어도 빌링에서는 용납되기 힘들다.
• 정확성 외에도 데이터 품질의 다른 측면(예, 값의 granularity, 데이터 보유 정책)이 데이터의 용도에 따라 달라질 수 있음. 예, 3년간 보관되는 직원 임금 데이터가 급여 관리 용도에는 적합하지만 임금 추세를 분석하는 용도로는 사용될 수 없음

 

12. 전문 지식의 상실(Loss of expertise)

• DB의 많은 데이터가 긴 역사를 가짐. 오래된 레가시 시스템으로부터 왔을 수도 있고, 과거에 여러 차례 변경되었을 수도 있으며, 데이터 필드와 값 코드의 사용이 시간에 따라 변화하고, 동일 필드의 동일 값이 여러 다른 레코드에서 완전히 다른 것을 의미할 수도 있다. 이런 사실에 대한 전문가들의 지식이 데이터를 올바르게 사용하도록 허용하며, 이런 지식 없이 데이터를 글자 그대로 사용하면 종종 슬픈 결말을 맞게 됨
• 현장의 데이터 사용자들은 대개 나쁜 데이터와 좋은 데이터를 구별할 수 있고 이를 효율적으로 사용할 수 있다. 이들은 어디를 봐야 할지 그리고 무엇을 체크해야 할지 안다. 이 전문가들 없이는 데이터 품질에 대한 부정확한 가정이 세워지고 나쁜 데이터 품질이 드러나게 된다.
• 유감스럽게도 많은 데이터 지식이 메타데이터 문서보다는 사람 머리 속에 존재. 사람이 이전하고, 퇴직하고, 잊어버리기 때문에 데이터가 더 이상 제대로 사용되지 못하게 됨

 

13. 프로세스 자동화(Process automation)

• IT 진보로 점점 더 많은 작업이 자동화됨. 사람은 사용하기에 앞서 저절로 데이터를 검증하지만, 컴퓨터 프로그램은 데이터를 글자 그대로 받아들이며 정확한지에 대한 제대로 된 판단을 못함. 자동화 프로세스에서 일부 검증 화면이 구현되었을 수도 있지만 모든 데이터 특이성을 식별하는데 실패하거나 또는 성능을 위해 비활성화됨. 그 결과 자동화가 데이터 쇠퇴를 야기한다.
• 기술 진보는 또한 더 광범위한 사용자 그룹에게 더 많은 데이터가 노출되게 함. 예, 지난 15년 간 음성 응답 시스템과 인트라넷을 통해 HR 데이터를 직원이 접근하도록 공개하는 것이 가능해짐. 직원이 부가 혜택이나 교육 프로그램에 대한 자신의 자격을 체크하고 기타 정보를 질의할 수 있게 되었지만, 잘못된 HR 데이터가 노출되면 직원들의 불만이 쏟아지기도 함. 즉, 데이터 자체는 변하지 않았지만 인식되는 품질 수준은 저하됨