고품질 데이터 추구에서 얻은 교훈: 회고적 글

Source: Dev.to

표지 사진 by Claudio Schwarz on Unsplash

Source: …

Introduction

본격적으로 들어가기 전에 데이터 품질이 무엇을 의미하는지 논의해 보겠습니다. IBM은 이를 다음과 같이 잘 정의하고 있습니다:

데이터 품질은 데이터 세트가 정확성, 완전성, 유효성, 일관성, 고유성, 적시성 및 목적 적합성 기준을 얼마나 잘 충족하는지를 측정하며, 이는 조직 내 모든 데이터 거버넌스 이니셔티브에 있어 핵심적인 요소입니다.

데이터 품질은 데이터가 완벽해야 한다는 것뿐만 아니라, 의도된 사용에 적합해야 한다는 점도 중요합니다—즉, 데이터 품질은 상황에 따라 달라집니다. 데이터가 수집되고 활용되는 도메인은 다른 검증 항목만큼이나 중요합니다. 많은 경우에, 이는 정확성, 유효성, 일관성, 적시성 및 고유성을 위한 검증 기준을 정의하는 기반이 됩니다. 또한, 데이터 품질은 팀 내 신뢰를 구축하거나 무너뜨릴 수 있습니다.

이 글은 고품질 데이터를 유지하기 위한 로드맵을 설정한 제 경험을 되돌아보는 내용입니다. 과거에 데이터 품질 강제 적용 및 구현에 대해 질문받을 때마다 저는 항상 “툴을 사용하거나 해당 기술을 활용하면 된다”라고 답했습니다. 실제로는 그 답변이 얼마나 제한적인지에 대한 냉혹한 현실을 마주하게 되었습니다.

좀 더 구체적인 상황을 살펴보면, 숙련된 데이터 분석가와 과학자 그룹에게 특정 제품에 대해 일정 기간(월, 주, 일 등) 동안 동일한 메트릭을 계산하도록 요청했을 때, 모두 다른 숫자를 도출했습니다. 이러한 불일치는 신뢰를 무너뜨리며, 모든 데이터 프로세스의 결과는 신뢰성에 기반합니다. 사람마다 메트릭 값이 다르면, “수집된 데이터가 좋은가? 처리 과정에서 오류가 발생하고 있는가?”라는 질문이 떠오르게 됩니다.

이때 저는 데이터 품질이 단순히 도구에만 의존하는 것이 아니라는 것을 깨달았습니다. 데이터 제품을 효과적으로 제공하기 위해 반드시 갖추어야 할 핵심 요소가 있습니다. 저는 이를 프로세스, 사람, 기술이라는 세 가지 주요 요소로 구분하고, 이들이 조화롭게 함께 작동하도록 했습니다. 다음 섹션에서는 각 요소에 대해 자세히 설명합니다.

People

데이터가 한 사람 이상에 의해 읽히고 해석될 경우, people 요소를 반드시 고려해야 합니다. 이는 하위 단계의 활동처럼 보일 수 있지만, 자동화된 워크플로, 정기적인 워크플로, 혹은 즉석에서 수행되는 워크플로든 가능한 한 빨리 다루는 것이 필수적입니다.

이를 실용적으로 만들기 위해서는, 데이터의 품질이 요청을 이해하는 것에서 시작됩니다. 모든 이해관계자 간에 분석 전달 과정에서 지식이 자유롭게 흐를 수 있어야 합니다. 예를 들어, 고위 임원이 “제품 A의 3일 차 유지율이 어떻게 되나요?”라고 물었을 때, 바로 멋진 SQL이나 Python 스크립트를 작성하기보다는 다음과 같은 명확화 질문을 해야 합니다:

• 클래식 유지율을 의미하나요, 아니면 롤링 유지율을 의미하나요?
• 전 세계 제품에 대해 지역별 유지율을 원하시나요? 이는 지역별 패턴을 보여줄 수 있습니다.
• 유지율을 UTC 24시간 주기로 측정해야 하나요? 등등.

이러한 질문은 정확히 무엇을 계산해야 하는지에 대한 명확성을 제공하거나, 가정할 여지를 마련해 줍니다. 전반적으로 결과 데이터와 그 해석의 품질은 사람들이 효과적으로 소통하는지에 달려 있습니다. 분석가와 엔지니어가 협업하는 팀에서는 명확한 정의를 문서화하고 쉽게 접근할 수 있도록 하여 신뢰할 수 있는 하위 데이터가 생성되도록 해야 합니다.

기술

툴 목록은 계속 늘어나고 있습니다. Great Expectations, Amazon Deequ, SODA와 같은 도구와 DBT의 검증 규칙, AWS Glue Data Quality와 같은 플랫폼 내장 솔루션 등으로 데이터 품질 검사는 기술적으로 해결된 문제입니다. 이제 남는 질문은 비용, 팀 역량, 기존 기술 스택과의 최적 적합성 등, 즉 도구 평가 과정에서 나타나는 기준에 관한 것입니다.

이러한 도구들은 데이터가 포함해야 할 내용에 대한 유효한 정의를 만드는 데 훌륭한 역할을 합니다. 일반적으로 제공하는 기능은 다음과 같이 일관된 방식으로 이루어집니다:

• 데이터 품질 기대치(expectations) 생성
• 검사 결과 저장
• 이해관계자에게 결과 보고

또한, 데이터 처리 및 분석 작업을 소프트웨어 개발 관행과 유사하게 다루는 것이 이제는 일반적인 관행이 되었습니다. 유지 보수 가능하고 가독성이 높으며 모듈화된 코드를 작성하는 것은 협업과 장기적인 지속 가능성을 촉진하기 위한 필수 조건이며, 사치가 아닙니다. 이를 위해 Git과 같은 버전 관리 시스템을 사용하는 것은 절대 타협할 수 없는 요소입니다.

프로세스

우리는 사람들이 조화롭게 협력하는 것이 기대치를 맞추는 데 중요한 역할을 한다는 것을 보았습니다. 저는 프로세스를 사람과 기술을 둘러싼 래퍼라고 생각합니다. 좋은 프로세스는 사람과 도구 간의 원활한 상호작용을 촉진하여 정의된 목표를 달성하게 합니다.

예를 들어, 데이터 엔지니어와 분석가 그룹이 Write‑Audit‑Publish (WAP) 패턴을 사용하여 워크플로를 정의하고, 감사 레이어에서 데이터 품질 및 검증 테스트를 수행할 수 있습니다. 그 결과, 모든 정의된 테스트를 통과하지 않은 데이터 제품은 절대 공개되지 않습니다. 대규모 데이터셋은 또한 빠른 실패(fail‑fast) 메커니즘을 활용한 사전 검사를 포함할 수 있습니다.

효과적인 프로세스를 구축하는 것은 항상 간단하지 않습니다:

• 단계가 너무 많으면 목표 달성이 번거로워집니다.
• 단계가 너무 적으면 일관되고 지속 가능한 결과를 위한 안전한 경계와 가이드라인을 정의하는 데 필요한 견고함이 부족할 수 있습니다.

좋은 프로세스는 균형을 이루며, 그 균형을 맞추기 위해 여러 차례 반복이 필요할 수 있습니다.

결론

데이터 품질을 도구만으로 달성할 수 있다고 주장하고 싶지만, 올바른 프로세스가 없으면 도구는 무용지물이 되고, 올바른 사람과 구조를 유지하려는 약속이 없으면 프로세스는 쉽게 회피됩니다. 이것이 진정 중요한 점입니다.

기술, 프로세스, 사람 모두가 조화롭게 작동하지 않으면 어떤 조직이나 프로젝트에서도 취약한 데이터 품질 프레임워크가 형성됩니다. 또한 논의된 아이디어는 데이터 품질이라기보다 데이터 거버넌스의 한 측면으로 보일 수 있습니다. 데이터 계약 개념에서도 이러한 원칙들과 강력히 일치합니다.

전반적으로, 데이터 거버넌스, 데이터 계약, 데이터 품질 프레임워크 등 조직에서 무엇이라 부르든 그 복잡한 적용은 이러한 요소들과 그 이상에 의존하게 됩니다.