데이터 품질의 비밀

 

 

p.24~25

'데이터 다운타임 - data downtime'은 데이터가 수집되지 않아 누락되거나 부정확하게 측정되는 등의 데이터 손실로 인해 소프트웨어 또는 서비스의 가동이 중지되는 상황을 의미한다. 이는 혁신적인 테크 기업이나 데이터가 중심인 기업에서도 발생할 수 있는 이슈로 데이터를 다루는 기업들이 직면할 수 있는 큰 문제 중 하나다. 대시보드에 잘못된 데이터를 표시하여 잘못된 의사결정을 내릴 수 있기 때문이다. 다시 말해 데이터 다운타임은 신뢰할 수 없는 데이터가 너무 많을 때 일어난다.

 

데이터 다운타임은 기업에 대한 고객의 신뢰도에 부정적인 영향을 끼칠 뿐 아니라 기업이 연간 수백만 달러 이상의 비용을 지출하는 데 직접적인 영향을 미치기도 한다. 기업용 데이터베이스 업체인 줌인포에 따르면, 2019년에만 약 20%의 기업이 데이터 품질 문제로 고객이 빠져 나가는 경험을 했다고 한다.

 

물론, 데이터 다운타임 자체만으로 기업의 수익성이 크게 나빠지는 것은 아니다. 하지만 관련 조사에 따르면, 데이터 조직이 데이터 품질 문제를 처리하기 위해 전체 업무 시간의 40% 이상을 소모한다고 한다. 만약 품질 이슈가 없었다면 더 흥미로운 프로젝트를 수행하거나 실질적인 비즈니스 혁신을 만들어 가는 데 더 많은 시간을 할애할 수 있었을 것이다.

 

p.28~29

지난 몇 년 사이, 다수 기업이 데브옵스의 개념을 '데이터옵스 DataOps' 라는 이름으로 데이터에 적용해 왔다. 데이터옵스는 데이터 관리의 자동화를 통해 데이터의 안정성과 성능을 개선하고, 데이터 사일로를 줄이며 데이터 분석 속도를 높이고 오류를 감소시키는 프로세스를 말한다.

 

인튜이트Intuit, 에어비앤비, 우버, 넷플릭스 등은 2019년부터 데이터옵스 모범 사례를 적용하여 비즈니스 전반에서 모든 사용자가 신뢰할 수 있고 가용성이 높은 데이터를 확보하겠다고 발표했다. 기업 내에서 확보한 데이터는 전략기획이나 재무, 그로스 마케팅과 같은 분야에서 데이터 분석에 기반한 의사결정이 가능하도록 도움을 줄 뿐만 아니라 애플리케이션이나 디지털 서비스를 다양하게 지원한다. 반면 어떤 기업들은 부정확하거나 누락된 데이터 혹은 잘못된 데이터 때문에 비용 및 시간 측면에서 손해를 입고 나서야 고객들의 신뢰를 잃기도 한다.

 

- 인튜이트 사례 (링크)

- 에어비앤비 사례 (링크)

- 우버 사례 (링크)

- 넷플릭스 사례 (링크)

 

p.31

요컨대, 데이터 파이프라인에서는 많은 일이 진행되고 있는데, 소스 데이터는 다양한 애플리케이션 프로그래밍 인터페이스(이하 API) 및 파이프라인에서 진행되는 여러 과정의 통합을 통해 추출 수집 변환 불러오기 저장 처리되어 또 다른 단계로 전달된다. 개발 영역에서 코드가 병합될 때마다 애플리케이션 다운타임이 발생할 수 있듯이, 위 프로세스의 각 시점에서도 데이터 다운타임이 발생할 가능성이 생기게 된다. 또한 데이터 웨어하우스 간에 데이터가 마이그레이션되거나 데이터가 수동으로 입력 및 변경되는 대대적인 이벤트가 아닐지라도 데이터에 문제가 발생할 수 있다.

 

p.32

그렇다면 분산된 데이터 아키텍처란 무엇일까? 중앙의 플랫폼 조직에서는 데이터를 관리하고, 비즈니스 전반의 데이터 분석 기능이나 데이터 과학자들은 분산시키는 구조를 말한다. 갈수록 많은 팀이 데이터 분석가를 활용하는 모델을 채택하고 있다. 그리고 해당 유형의 아키텍처에 의존하는 팀도 늘어나는 추세다(분산 도메인 지향 데이터 아키텍처인 데이터 메시 data mesh(참고 링크)와는 다른 개념임).

 

p.35~36

"데이터 웨어하우스를 사용할 것인가, 데이터 레이크를 사용할 것인가?" 데이터 엔지니어에게 이렇게 묻는 것만으로도 그 자체로 의미 있는 질문이 될 것이다. 구조화된 데이터 저장소인 데이터 웨어하우스와 보다 자유도가 높은 데이터 레이크 모두 고품질 데이터가 필요하다. 점점 더 많은 데이터 조직이 증가하는 비즈니스 요구 사항을 소화하기 위해 데이터 웨어하우스와 데이터 레이크를 둘 다 사용하고 있다. 이것이 데이터 레이크하우스가 부각되는 이유다.

 

데이터 레이크하우스(Data Lakehouse)라는 개념은 클라우드 플랫폼 분야에서 아마존의 '레드시프트 스펙트럼 Redshift Spectrum'이나 '데이터브릭스'의 '레이크하우스 Lakehouse'와 같은 기능이 추가되면서 처음 등장했다. 당시 데이터 레이크에도 SQL 질의 및 스키마와 같은 데이터 웨어하우스의 기능이 추가되는 추세였다. 사실상 오늘날에는 웨어하우스와 레이크의 기능적 차이가 줄어들고 있으며, 두 형태의 장점을 결합한 데이터 레이크하우스가 확산되고 있다.

 

레이크하우스로 마이그레이션한다는 것은 데이터 파이프라인이 점점 더 복잡해지고 있음을 시사한다. 이 과정에서 누군가는 데이터 웨어하우스와 데이터 레이크의 기능을 모두 활용하기 위해 단일 벤더의 솔루션을 사용할 것이다. 반면 다수의 스토리지에 데이터를 마이그레이션하고 레이어를 각각 처리하는 사용자도 있을 것이다. 다만 이런 경우 충분한 테스트를 거쳤더라도 데이터 다운타임이 발생할 여지가 커진다.

 

p.39

만약 데이터 엔지니어에게 조직 내 데이터를 가장 크게 구분해 달라고 요청한다면, '운영 데이터'와 '분석 데이터'라는 용어를 듣게 될 것이다. 운영 환경과 분석 환경의 차이는 데이터를 분리하는 여러 방법 중 하나다. 이는 중요한 문제로서, 데이터 품질 문화를 조성하는 데 관심이 있다면 반드시 이해해야 한다. 

 

여기서는 운영 데이터에 대해서도 간단히 설명하겠지만, 이 책의 목적에 맞게 분석 데이터 품질에 계속 집중할 것이다. 운영 데이터의 품질과 신뢰성 관리는 종종 데브옵스, 사이트 신뢰성 엔지니어링 및 기타 소프트웨어 분야, 분석 데이터로 정보가 제공되는 소프트웨어 프로덕트를 구축하는 것과 밀접하게 관련된 소프트웨어 원칙에 포함된다.

 

운영 데이터 

- 운영상 생성된 데이터, 즉 조직에서 일상적인 운영을 통해 생성된 데이터(링크)다. 특정 시점의 인벤토리 스냅샷, 고객 인상 및 거래 기록은 모두 운영 데이터의 예다.

 

분석 데이터

- 분석적으로 사용되는 데이터, 즉 데이터 기반 의사결정에 활용되는 데이터를 말한다. 마케팅 전환율, 클릭율, 글로벌 지역별 광고 노출 등이 분석 데이터의 예다.

 

간단히 말해, 운영 데이터는 시스템 및 프로세스의 신속한 업데이트를 위해 실제 비즈니스 프로세스의 데이터를 기록하는 반면 분석 데이터는 좀 더 강력하고 효율적인 분석을 하는 데 사용된다. 더 쉽게 이야기하면, 운영 데이터로 비즈니스를 운영하고 분석 데이터로 비즈니스를 관리한다. 분석 데이터가 운영 데이터와 다른 방식으로 비즈니스 인텔리전스를 주도한다는 점을 고려할 때, 이 데이터가 조직의 성공에 더 중요하거나 '중심적'이라고 생각할 수 있다. 그러나 분석 데이터는 변환 집계된 운영 데이터에 의존하기 때문에 항상 그런 것만은 아니다.

 

p.40