<데이터 품질의 비밀> 저자 3인 인터뷰
<데이터 품질의 비밀(Data Qualtiy Fundamentals)> 원저자들의 책 출간 기념 인터뷰를 요약했어요. 책을 기반으로 데이터 품질의 정의부터 데이터 신뢰성, 옵저버빌리티 등 관련 내용을 응축한 질문과 답변이 담겨 있어서 이 글을 읽으면 미리 <데이터 품질의 비밀: 데이터 신뢰를 쌓는 데이터옵스의 핵심과 엔드 투 엔드 단계별 가이드>을 맛볼 수 있어요. 더 심화된 내용 또는 다양한 사례를 책으로 읽기 전에 이 글을 워밍업으로 읽으면 좋아요.
Q. <데이터 품질의 비밀>에서 데이터 품질 관리는 소스 데이터가 깨끗하고 정확한지 확인하는 작업 그 이상이라고 설명하셨죠. 그러면 데이터 품질의 정의는 무엇일까요?
라이어 개비쉬(Lior Gavish)_이전에도 기업들에게는 데이터가 중요했어요. 데이터 분석을 하면서 오류가 보이니 데이터 품질을 개선하기 위해 노력도 했고요. 그러나 본격적으로 데이터 품질을 최우선시하게 된 시기는 2020년대 들어서면서부터입니다. 데이터가 단순히 비즈니스 과정의 산출물이 아니라 제품이 되어서, 신뢰도가 중요해졌기 때문에요.
그 결과, 기업은 점점 더 데이터를 코드처럼 여기게 되었고, 소프트웨어 엔지니어링 팀들의 오랜 표준인 프레임워크와 패러다임을 데이터 조직과 아키텍처에 적용하기에 이르렀습니다.
Q. <데이터 품질의 비밀>에서 데이터 품질 관리는 소스 데이터가 깨끗하고 정확한지 확인하는 작업 그 이상이라고 설명하셨죠. 그러면 데이터 품질의 정의는 무엇일까요?
라이어 개비쉬(Lior Gavish)_이전에도 기업들에게는 데이터가 중요했어요. 데이터 분석을 하면서 오류가 보이니 데이터 품질을 개선하기 위해 노력도 했고요. 그러나 본격적으로 데이터 품질을 최우선시하게 된 시기는 2020년대 들어서면서부터입니다. 데이터가 단순히 비즈니스 과정의 산출물이 아니라 제품이 되어서, 신뢰도가 중요해졌기 때문에요.
그 결과, 기업은 점점 더 데이터를 코드처럼 여기게 되었고, 소프트웨어 엔지니어링 팀들의 오랜 표준인 프레임워크와 패러다임을 데이터 조직과 아키텍처에 적용하기에 이르렀습니다.
*출처: <데이터 품질의 비밀>, 한빛미디어, 2023
그중에서도 데브옵스(DevOps)는 사이트 안정성 엔지니어링(SRE), 지속적 통합/지속적 배포(CI/CD), 마이크로서비스 기반 아키텍처와 같은 업계 최고의 모범 사례를 도입했어요.
데브옵스의 목표는 자동화를 통해 보다 안정적이고 성능이 뛰어난 소프트웨어를 출시하는 거잖아요. 그래서 이를 데이터에 적용해서 ‘데이터옵스(DataOps)’ 개념을 만들었어요. 데이터옵스는 자동화를 통해 데이터의 안정성과 성능을 개선하고, 데이터 사일로를 줄이며, 더 빠르고 내결함성이 있는 분석을 촉진하는 프로세스입니다.
이제 데이터 품질은 분석 프로그램을 강화하는 첫 단계로서 데이터의 신뢰성, 완전성 및 정확성을 측정하는 기능으로 구체화되기 시작했습니다. 측정하지 않는 것은 관리할 수 없다는 원칙이 적용되는 것이지요. 이에 따라 데이터 품질은 데이터가 비즈니스 요구 사항에 맞는지 여부를 가늠하는 기준으로도 역할하고 있습니다. 결국 데이터옵스는 대규모 데이터 품질 관리와 관련된 차세대 주요 키워드가 될 것이라고 생각합니다.
Q. 데이터 품질은 데이터 과학 및 분석이 주목을 받기 시작했을 때부터 IT 팀의 우선 순위였을 텐데요. 아직도 문제가 많아요. 데이터 품질을 관리하는 게 왜 이렇게 어려울까요?
바 모세스(Barr Moses)_말씀하신 ‘문제’라 함은, 보통 데이터 다운타임(가동 중지), 데이터 누락, 오류 또는 부정확성을 의미합니다. ‘아직도 문제가 많다’기보다는 추세에 따라 문제가 더 자주 발생한다고 봐요. 특히 최근에는 다음 4가지 이유로 많이 발생합니다.
1) 데이터 신선도 제고(refresh) 필요성 증가
데이터 신선도는 중요한 데이터가 마지막으로 업데이트된 시기를 확인할 수 있는 강력한 지표입니다. 예를 들어 정시에 정기적으로 업데이트되어야 하는 보고서가 있는데, 어느 순간 확인해보니 오래된 데이터가 그대로 기록된 경우가 있습니다. 그랬을 때 무언가 잘못되었다는 사실을 알 수 있습니다. 요즘처럼 유입되는 데이터의 양이 증가하고, 진입점도 여러 개면 데이터의 신선도를 제고할 필요성도 함께 늘어납니다.
2) 클라우드로의 마이그레이션 증가
데이터 기반 분석, 교차 기능 데이터 조직과 아마존 레드시프트(Amazon Redshift), 스노우플레이크(Snowflake) 및 구글 빅쿼리(Google BigQuery)와 같은 클라우드 등 데이터 웨어하우스 솔루션이 급부상했어요. 데이터를 잘 쓰는 기업들에게 이런 솔루션들은 더 큰 인기를 끌게 됐습니다. 기본적으로 클라우드를 사용하면 데이터를 더 쉽게 관리할 수 있고, 다양한 사용자가 접근할 수 있으며, 데이터 처리를 더 빠르게 할 수 있기 때문이에요.
3) 데이터 수집 소스 증가
또한 기업들은 분석 모델 및 기계학습 모델을 만들기 위해 수십에서 수백 개의 내외부 데이터 소스(source)를 사용해요. 이중 하나라도 예기치 못하게 변경되면 회사가 적절한 의사 결정을 내리는 데 지장을 줄 수 있습니다.
4) 데이터 파이프라인 복잡성 증가
데이터 파이프라인도 복잡해졌어요. 몇 년 사이 아주 고급스러운, 새로운 툴들이 많이 등장했죠. 각 기업 경영진들이 다양한 데이터 자산을 열람하고, 그들을 서로 연결시켜서 새로운 인사이트를 뽑아내기를 원했기 때문입니다. 그들은 파이프라인에서 처리 단계를 늘렸고 데이터 사이의 위계질서를 정하기도 했어요. 데이터를 읽어보려는 노력이었으나 한편으로는 데이터를 변형하는 등 품질을 낮추는 원인이 되었어요. 결국 의도치 않게 데이터 자산의 정확도를 낮추게 됐고요.
*출처: <WHAT IS DATA PIPELINE? EXPLAINED BY OUR DEVS>, 유튜브 채널 ‘TECH IN 5 MINUTES’
Q. 데이터 품질 관리의 효과를 측정할 방법이 있을까요?
몰리 보르웨르크(Molly Vorwerck)_데브옵스와 비슷하게, 데이터 문제를 식별하는 데 걸리는 시간과 해결하는 데 걸리는 시간을 측정하고 있습니다.
탐지 시간(TTD)은 데이터 엔지니어링 팀이 데이터 품질에 생긴 문제를 식별하는 데 걸리는 시간입니다. 데이터가 최신이 아니거나 실행에 실패한 모델, 전체 파이프라인에 적용된 스키마가 변경된 경우 등이 문제에 속합니다. 데이터 팀은 TTD를 수일에서 수주, 때로는 수개월을 측정합니다. 탐지하는 방법은 다운스트림 데이터 사용자가 데이터의 품질이 별로라는 사실을 기업에 제보할 때까지 기다리는 것이기 때문에요.
다음은 해결 시간(TTR)인데요. 데이터 엔지니어링 팀은 알림을 받은 후 데이터 사고를 얼마나 빨리 해결했는지를 확인하는 지표입니다. 시간, 분 또는 일 단위로 측정되는 TTR로는 문제의 심각도를 이해하고 해결에 걸리는 시간을 예측할 수 있습니다.
이를 돈으로 환산(지출/절감한 금액)하면 데이터 품질 문제가 미치는 재정적인 영향을 이해관계자에게 쉽게 전할 수 있습니다. 산출식은 다음과 같습니다.
(TTD + TTR) * 다운타임 시간당 비용 = 데이터 다운타임 비용
Q. 기업에서 데이터 분석을 향한 요구가 늘어나고 또 복잡해졌습니다. 그리고 데이터 팀은 이를 만족하기 위해 데이터를 점점 더 분산하고 있고요. 이런 상황에서 데이터 품질을 잘 유지하면서 데이터 민주화도 이루기 위해 제시하는 모범 사례 또는 새로운 트렌드는 무엇입니까?
몰리 보르웨르크_데이터가 비즈니스 운영의 중심이 되면서 회사의 거의 모든 팀이 데이터 관리 및 분석에 참여합니다. 데이터를 기반으로 인사이트를 수집하고 의사결정을 잘 내리기 위해섭니다. 따라서 프로세스도 간소화했죠.
결과적으로 데이터 팀들은 분산 모델을 택했습니다. 2010년대 중반 소프트웨어 엔지니어링 업계에서 일어난 마이크로서비스 아키텍처로의 변화가 이를 반영합니다.
예를 들어, 200명 규모의 회사에서 3명의 데이터 엔지니어와 10명의 데이터 분석가로 구성된 팀을 만들었다고 칩시다. 분석가 팀은 비즈니스 요구사항을 더 세부적으로 반영하기 위해 다른 팀 소속으로 분산됐습니다. 이들은 운영 팀이나 데이터 팀에 보고하면서도 특정 데이터세트를 보유하며 직능을 수행하고 있습니다.
그러나 여러 도메인에서 데이터를 생성하고 활용하기 때문에, 데이터세트를 중복해서 기록하는 경우도 생기고요. 시간이 지날수록 데이터가 누락되고 부실해지기 마련입니다.
해당 문제를 해결하기 위해 데이터 팀은 비즈니스 중앙 집중식 거버넌스 모델을 도입해야 한다고 봅니다. 조직 전반에 걸쳐 데이터 품질을 관리하기 위해 보편적인 표준을 적용하는 방법이기 때문이에요. 실제로도 트렌드가 그렇게 흘러가고 있고요.
Q. 책에 ‘데이터 옵저버빌리티(Data observability)’라는 용어가 등장합니다. 이는 무엇을 뜻하며 기존의 데이터 품질 관리와 어떻게 다른가요?
출처: <데이터 품질의 비밀>, 한빛미디어, 2023
바 모세스_기존의 데이터 팀은 파이프라인의 회복탄력성을 확인하기 위해 데이터 테스트에만 의존했습니다. 그러나 2021년부터 기업이 수집하는 데이터의 양이 어마무시해졌고 파이프라인은 예전보다 더 복잡해졌습니다. 따라서 데이터 테스트 접근법만으로는 충분치 않게 됐습니다. 그래서 데이터 옵저버빌리티 개념이 등장했어요.
데이터 옵저버빌리티는 데이터 시스템의 라이프사이클 각 단계에서 데이터의 상태를 이해하는 조직의 능력을 의미합니다. 감사(audit), 데이터 침해 및 침탈 조사, 기타 데이터 재해에 쉽고 빠르게 대응할 수 있는 능력이에요.
Q. 데이터 옵저버빌리티를 잘 수행하려면 무엇을 해야할까요?
라이어 개비쉬_데이터 전문가가 데이터 품질과 신뢰성을 더 잘 추적하기 위해서는 아래 5가지 요소(또는 데이터 기능)를 측정할 수 있어야 합니다.
1) 신선도(Freshness): 최근 데이터입니까? 마지막으로 생성된 것이 언제였습니까? 어떤 업스트림 데이터가 들어갔거나 빠졌습니까?
2) 분포(Distribution): 데이터가 허용 범위 내에 있습니까? 형식이 올바르게 지정되어 있습니까?
3) 볼륨(Volume): 모든 데이터가 전부 잘 들어가 있나요?
4) 스키마(Schema): 우리의 스키마는 무엇이며 어떻게 변경됐나요? 누가, 어떤 이유로 이러한 변경을 하였습니까?
5) 계보(Lineage): 주어진 데이터 자산의 업스트림 소스는 무엇이며 어떤 다운스트림 자산이 영향을 받습니까? 이 데이터를 생성한 사람은 누구이며 데이터로 의사결정을 하는 사람은 누구인가요?
데이터 옵저버빌리티를 잘 수행하려면 앞서 언급한 5개 요소를 중앙 집중식으로 안정되게 모니터링할 수 있어야 합니다. 임시 쿼리나 단순 SQL 래퍼와 달리, 해당 모니터링은 ‘테이블 Y의 필드 X 값이 오늘 Z보다 낮음’ 정도에 그쳐서는 안 됩니다. 사전 예방을 궁극적인 목표로 삼아야 합니다.
또 데이터 옵저버빌리티 솔루션은 다운스트림 종속성을 추적할 수 있는 계보를 제공하기도 합니다. 또 데이터 저장소에서 데이터를 추출할 필요 없이 자동으로 모니터링하는 기능도 제공해요. 그래서 요구사항을 충족하면서도 보안을 강화하고 데이터 볼륨을 확장할 수 있게 만듭니다.
저자 3인이 평소 데이터 품질에 관해 하고 싶은 말이 많았던 만큼 인터뷰에서도 유익한 정보가 많이 쏟아졌는데요. 더 자세한 내용을 보시려면 <데이터 품질의 비밀: 데이터 신뢰를 쌓는 데이터옵스의 핵심과 엔드 투 엔드 단계별 가이드>를 읽어보시면 좋겠습니다. 지금 서점에서 만나보세요!
