[데이터 엔지니어링] 수명주기 5단계: 분석, 머신러닝 및 역ETL을 위한 데이터서빙

조 라이스, 맷 하우슬리 저자  <견고한 데이터엔지니어링>의 CHAPTER 9.1~9.4를 참고, 요약정리하여 작성한 글입니다.

---

책의 9장에서는 드디어 데이터 엔지니어링 수명 주기의 마지막 단계인 다운스트림 사용 사례에 대한 데이터 서빙(제공)을 다루고 있습니다. 데이터 엔지니어로서 접하게 될 아래 3가지 주요 사용 사례의 데이터를 서빙하는 다양한 방법을 설명합니다.

• 분석 및 BI용 데이터를 제공한다.
• ML 애플리케이션의 데이터를 제공한다.
• 역 ETL을 통해 데이터를 제공한다.

이번 글에서는 데이터 서빙에 관한 기초 고려 사항, 분석을 위해 데이터를 제공하는 방법, ML 분야 관련 사항에 대해 정리해보도록 하겠습니다.

 

9.1 데이터 서빙의 일반적인 고려 사항

9.1.1 신뢰

신뢰는 데이터 제공에 있어 가장 우선시해야 하고 중요한 고려 사항입니다. 최종 사용자는 수신한 데이터를 신뢰할 수 있어야 합니다. 데이터 엔지니어는 데이터 제품에 항상 고품질의 신뢰할 수 있는 데이터가 포함되어 있는지 확인해야 합니다.

데이터 품질을 실현하고 이해관계자의 신뢰를 구축할 수 있도록, 데이터 유효성 검사 및 데이터 관찰 가능성 프로세스를 활용하고 이해관계자와 함께 유효성을 시각적으로 검사하고 확인합니다. 데이터 검증은 재무 정보, 고객과의 상호작용 및 매출을 정확하게 나타내기 위해 데이터를 분석하는 것을 말합니다. 데이터 관찰 가능성은 데이터와 데이터 프로세스에 대한 지속적인 뷰를 제공합니다. 이러한 프로세스는 데이터 엔지니어링 수명 주기 전체에 걸쳐 적용되어야 하며, 최종 단계에 도달한 시점에서 좋은 결과를 얻을 수 있습니다.

이외에도, 최종 사용자 및 업스트림 이해관계자와 서비스 수준 협약(SLA) 및 서비스 수준 목표(SLO)에 대한 신뢰를 쌓아야 합니다. 단순히 SLA에 동의하는 것보다는, 지속적인 소통이 좋은 SLA의 핵심 특징임을 알아야 합니다.

9.1.2 사용 사례는 무엇이며 사용자는 누구인가?

'데이터의 생산적인 활용이란 무엇일까?'라는 질문에 답하려면 데이터의 사용 사례는 무엇이며 사용자는 누구인지를 고려해야 합니다.

데이터 사용 사례는 보고서와 대시보드를 보는 데 그치지 않고, 행동으로 이어질 때 최상의 효과를 발휘합니다. 사용 사례를 모색할 때는 항상 '이 데이터는 어떤 행동(작업)을 트리거하며 누가 수행할 것인가?'라고 질문하고, 이어서 '이 작업을 자동화할 수 있을까?'와 같은 적절한 후속 질문을 던져보는 것이 좋습니다.

새로운 데이터 프로젝트를 시작할 때는 역방향으로, 즉 사용자와 사용 사례의 관점에서 데이터 엔지니어링에 접근해야 합니다. 고객의 기대와 목표를 이해하면 뛰어난 데이터 제품을 더 쉽게 만들 수 있습니다.

9.1.3 데이터 제품

데이터 제품에 대한 좋은 정의는 '데이터를 사용해 최종 목표를 달성하도록 촉진하는 제품'이다. -D.J.Patil

 

데이터 제품을 제작할 때는 '실행해야 할 작업'을 생각하는 것이 유용합니다. 사용자는 '실행해야 할 작업'을 위해 제품을 '고용'합니다. 다시 말해 사용자가 무엇을 원하는지, 즉 제품을 '고용'하는 동기를 알아야 합니다. 아무도 사용하지 않으려는 데이터 제품을 구축하는 재앙이 발생하면 안 되겠죠.

좋은 데이터 제품에는 긍정적인 피드백 루프가 있습니다. 데이터 제품을 더 많이 사용할수록 더 유용한 데이터가 생성되고, 이 데이터는 데이터 제품을 개선하는 데 쓰입니다.

데이터 제품을 구축할 때는 아래 사항들을 고려하면 좋습니다.

• 사용자가 데이터 제품을 사용할 때 무엇을 달성하고자 하는가?
• 데이터 제품은 내부 사용자 또는 외부 사용자 중 어느 쪽에 제공되는가?(2장 참고)
• 구축 중인 데이터 제품의 성과와 ROI는 어떻게 되는가?

9.1.4 셀프서비스 여부

오늘날 셀프서비스 BI와 데이터 과학은 여전히 동경의 대상입니다. 셀프서비스 데이터는 일반적으로 최종 사용자를 이해하면서 실제로 구현하기가 어렵기 때문에, 대부분 실패하는 경우가 많습니다. 따라서 분석가 또는 데이터 과학자는 임시 보고서를 제공하고 대시보드를 유지 관리해야 합니다.

성공적인 셀프서비스 데이터 프로젝트는 적절한 사용자를 확보하는 것으로 요약됩니다. 셀프서비스 사용자와 그들이 원하는 '작업'을 파악합니다. 예를 들어 '그들이 데이터 분석가와 협업해 작업을 수행하는 대신, 셀프서비스 데이터 제품을 사용해 달성하려는 목표는 무엇인가'를 생각해야 합니다.

데이터가 많을수록 질문이 많아지는 만큼 데이터는 더 많이 필요합니다. 셀프서비스 사용자의 증가하는 요구 사항을 예측해야 합니다. 또한 고객이 잘못된 결과나 혼란 없이 가치와 인사이트를 찾을 수 있도록 돕는, 유연성과 가드레일(제한성) 사이의 미세한 균형을 이해해야 합니다.

9.1.5 데이터 정의 및 논리

데이터 정의는 조직 전체에서 이해되는 데이터의 의미를 나타냅니다. 예를 들어 고객은 기업 내부와 부서 간에 정확한 의미가 있습니다. 고객에 대한 정의가 다른 경우에는 이러한 내용을 문서화해 데이터를 사용하는 모든 사람이 이용할 수 있도록 해야 합니다. 데이터 정의는 대부분 암묵적으로 제공되는데, 이는 쿼리, 대시보드 또는 ML 모델에 데이터를 제공할 때마다 데이터와 파생된 측정 지표가 일관되고 정확하게 표시된다는 것을 의미합니다.

데이터 로직(논리)은 데이터로부터 측정 지표(예: 총매출액 또는 고객 생애 가치)를 도출하는 공식을 규정합니다. 적절한 데이터 로직은 데이터 정의와 통계 계산의 세부 사항을 인코딩해야 합니다. 예를 들어 고객 이탈 측정 지표를 계산하려면 '고객은 누구인가?'에 대한 정의가 필요하고, 순이익을 계산하려면 총수입에서 어떤 비용을 공제해야 할지를 결정하는 일련의 논리적 규칙이 필요합니다. 

데이터 정의와 논리는 조직 내에서 지식의 형태로 전달되는 경우도 많습니다. 제도적 지식은 종종 자체적인 생명력을 가지게 되는데, 이는 데이터 기반의 인사이트, 의사결정 및 행동을 대신할 일화가 되고, 오히려 이들을 대체하기도 합니다. 대신 데이터 카탈로그와 데이터 엔지니어링 수명 주기 시스템 모두에서 데이터 정의와 논리를 공식적으로 선언하면 데이터의 정확성, 일관성 및 신뢰성을 보장하는 데 큰 도움이 됩니다.

9.1.6 데이터 메시

데이터 메시는 (중앙 집중식 데이터 레이크 및 데이터 웨어하우스 같은) 거대한 모놀리식 데이터 플랫폼과, 운영 데이터와 분석 데이터 사이에서 환경이 구분되는 '데이터 격차'에 대한 최근의 대응책입니다(3장).

데이터 메시는 조직 내에서 데이터를 처리하는 방법을 근본적으로 변화시킵니다. 사일로화된 데이터 팀이 내부 구성 요소를 처리하는 대신, 모든 도메인 팀은 분산형 P2P 데이터 서비스의 다음 두 가지 측면을 담당합니다.

1. 팀은 데이터를 사용할 수 있도록 준비함으로써 다른 팀에 데이터를 제공할 책임이 있다. 데이터는 조직 전체의 데이터 애플리케이션, 대시보드, 분석 및 BI 도구에서 사용하기 편리해야 한다.
2. 각 팀은 잠재적으로 셀프서비스를 위한 대시보드와 분석을 실행할 수 있다. 팀은 해당 도메인 내의 특정 요구 사항에 따라 조직 전체의 데이터를 소비한다. 다른 팀에서 소비되는 데이터는 임베디드 분석 또는 ML 기능을 통해 도메인 팀이 설계한 소프트웨어로 유입될 수도 있다.

이렇게 하면 서빙의 세부 사항과 구조가 극적으로 변화합니다.

 

9.2 분석

가장 먼저 접하게 될 데이터 서빙 활용 사례는 데이터 내에서 주요 인사이트와 패턴을 발견, 탐색, 식별 및 가시화하는 분석입니다. 분석을 위해 데이터를 제공하기 전에 가장 먼저 해야 할 일은 최종 사용 사례를 파악하는 것입니다. 비즈니스 분석, 운영 분석, 임베디드 분석은 각각 다른 목표와 고유한 서비스 요구 사항이 존재합니다.

9.2.1 비즈니스 분석

비즈니스 분석에서는 과거 데이터와 현재 데이터를 사용해 전략적이고 실행 가능한 결정을 내립니다. 장기적인 추세를 고려하는 경향이 있고, 종종 도메인 전문 지식과 인간의 판단이 통계 및 추세 분석과 함께 혼합되어 사용됩니다. 비즈니스 분석은 일반적으로 대시보드, 보고서 및 애드혹 분석으로 나뉩니다.

대시보드는 의사결정자에게 매출 및 고객 유지율 같은 몇 가지 핵심 측정 지표에 대한 조직의 성과를 간결하게 보여줍니다. 이러한 핵심 측정 지표는 시각화(예: 차트 또는 히트맵), 요약 통계 또는 단일 숫자로 제공됩니다. 현재 BI 플랫폼을 사용해 태블로, 루커, 시젠스, 파워BI 또는 아파치 슈퍼셋이나 아파치 프리셋 같은 대시보드를 생성할 수 있습니다.

분석가는 종종 비즈니스 이해관계자로부터 보고서 작성을 의뢰받는데, 보고서의 목표는 데이터를 사용해 인사이트와 행동을 유도하는 것입니다. 예를 들어 온라인 소매업체에서 여성용 러닝바지의 반품률이 예상보다 높은 요인을 조사해달라는 요청을 받았을 때, 몇 가지 SQL 쿼리를 실행해 반품 코드를 집계해 원단 품질이 문제임을 파악하고, 이해관계자에게 결과를 통지할 수 있습니다.

이 사례에서 분석가는 잠재적인 문제를 파헤치고 인사이트를 도출해달라는 요청을 받았습니다. 이것은 애드혹 분석의 한 사례입니다. 보고서는 보통 애드혹 요청으로 시작되는데, 애드혹 분석 결과에 영향력이 있는 경우에는 보고서나 대시보드에 표시될 때가 많습니다. 보고서 및 애드혹 분석에 사용되는 기술은 대시보드와 유사하지만 엑셀, 파이썬, R 기반 노트북, SQL 쿼리 등이 포함될 수 있습니다.

9.2.2 운영 분석

비즈니스 분석이 데이터를 사용해 실행 가능한 인사이트를 도출하는 것이라면, 운영 분석에서는 데이터를 사용해 즉각적인 조치를 취합니다. 운영 분석과 비즈니스 분석의 가장 큰 차이점은 시간인데, 비즈니스 분석은 장기적인 관점인데 반해 운영 분석은 문제가 발생했을 때 실시간 갱신이 문제를 해결하는 데 큰 영향을 미칩니다.

예로는 실시간 애플리케이션 모니터링이 있습니다. 많은 소프트웨어 엔지니어링 팀은 애플리케이션의 성능을 알고 싶어 하며, 문제가 발생하면 즉시 통지받기를 원합니다. 엔지니어링 팀에는 초당 요청 수, 데이터베이스 I/O 또는 그 외 중요한 측정 지표와 같은 핵심 측정 지표를 보여주는 대시보드가 있을 수 있습니다. 

구글 컴퓨트 엔진의 주요 측정 지표를 보여주는 운영 분석 대시보드

특정 조건에 다라 스케일링 이벤트가 트리거될 수 있으며, 서버에 과부하가 걸리면 용량을 더 추가할 수 있습니다. 특정 임곗값을 초과할 경우 모니터링 시스템은 문자 메시지, 그룹 채팅 및 이메일을 통해 경고를 보낼 수도 있습니다.

9.2.3 임베디드 분석

비즈니스 및 운영 분석은 내부에 초점을 맞추지만, 최근의 추세는 외부 또는 임베디드 분석입니다. 많은 데이터가 애플리케이션을 지원함에 따라 기업은 최종 사용자에게 분석 기능을 제공하는 경우가 늘고 있습니다. 이러한 대시보드를 일반적으로 데이터 애플리케이션이라고 하며, 애플리케이션 자체에 분석 대시보드가 내장되는 경우가 많습니다. 임베디드 분석이라고도 하는 이러한 최종 사용자용 대시보드는 사용자에게 애플리케이션과의 관계에 대한 주요 측정 지표를 제공합니다. 예로는 스마트 온도 조절기가 있는데, 실시간으로 온도를 보여주는 모바일 애플리케이션과 최신 전력 소비 측정 지표를 갖추고 있어 에너지 효율이 높은 난방 및 냉방 일정을 만들 수 있습니다.

임베디드 분석의 성능에는 세 가지 문제점이 있습니다.

• 앱 사용자는 사내 분석가만큼 빈번하지 않은 배치 처리에 관대하지 않다. 이와 동시에 사용자는 짧은 데이터 지연을 원한다.
• 데이터 앱 사용자는 빠른 쿼리 성능을 기대한다.
• 데이터 앱은 많은 대시보드와 수많은 고객에 걸쳐 매우 높은 쿼리 속도를 지원해야 한다. 즉, 높은 동시성이 중요하다.

구글을 비롯한 데이터 앱 분야의 초기 주요 업체들은 이러한 문제에 대처하기 위해 이색적인 기술을 개발했고, 신규 스타트업의 경우 초기 아키텍처에서 벗어나 차세대 데이터베이스에 접근할 수 있습니다.

9.3 머신러닝

데이터 서빙을 위한 두 번째 주요 영역은 머신러닝(ML)입니다. 데이터 엔지니어는 다른 환경에서 모든 데이터 처리를 처리한 다음 모델 학습을 위해 ML 엔지니어에게 데이터를 전달합니다. 데이터 엔지니어는 데이터의 특성화와 같은 ML 고유의 일부 작업도 처리할 수 있습니다. 데이터 엔지니어와 ML 엔지니어가 협력해 기능화 파이프라인을 설계하고, 데이터 엔지니어가 파이프라인을 구현 및 유지 관리합니다.

9.4 데이터 엔지니어가 ML에 관해 알아야 할 사항

데이터 엔지니어가 ML을 깊이 이해할 필요는 없지만, ML의 기본을 알면 데이터 과학자와 함께 데이터 제품을 구축하는 데 큰 도움이 됩니다. 데이터 엔지니어가 숙지해야 할 몇몇 사항을 살펴보겠습니다.

• 지도 학습, 비지도 학습, 준지도 학습의 차이점을 파악한다.
• 분류 기법과 회귀 기법의 차이점을 파악한다.
• 시계열 데이터를 처리하는 다양한 기술을 파악한다.
• 로지스틱 회귀, 트리 기반 학습, 지원 벡터 머신 등의 고전적 기법을 사용할 때와 딥러닝을 사용할 대를 판단한다.
• 자동화된 머신러닝과 ML 모델을 수작업으로 사용하는 경우는 언제인가?
• 정형 데이터와 비정형 데이터에 사용되는 데이터 랭글링 기술은 무엇인가?
• 범주형 데이터의 인코딩 방법과, 다양한 유형의 데이터에 대한 임베딩 방법을 확인한다.
• ML 모델에 배치 및 스트리밍 데이터를 적용할 때의 차이점을 파악한다.
• 결과를 실시간으로 반환하는가? 아니면 배치로 반환하는가?
• 정형 데이터와 비정형 데이터를 사용한다.

---

Q1. 데이터 서빙의 일반적인 고려 사항으로 틀린 것은?

① 데이터 품질에 대한 신뢰를 구축하기 위한 프로세스는 데이터 엔지니어링 수명 주기 전체에 걸쳐 적용되어야 한다.

② 새로운 데이터 프로젝트를 시작할 때는, 사용 사례와 사용자의 관점이 아닌 도구에 초점을 맞추는 것이 유용하다.

③ 데이터 제품을 제작할 때는 '실행해야 할 작업'을 생각하는 것이 유용하다.

④ 데이터 로직(논리)은 데이터로부터 측정 지표를 도출하는 공식을 규정한다.

⑤ 데이터 메시는 조직 내에서 데이터를 처리하는 방법을 근본적으로 변화시킨다.

 

답(드래그): ② 사용자와 사용 사례의 관점에서 접근해 고객의 기대와 목표를 이해하면 뛰어난 데이터 제품을 더 쉽게 만들 수 있다.

 

Q2. 아래 특징을 가진 유형의 분석은 무엇인가?

데이터 애플리케이션 자체에 분석 대시보드가 내장되어 있는 경우가 많다. 사용자에게 애플리케이션과의 관계에 대한 주요 측정 지표를 제공한다. 짧은 지연 시간, 빠른 쿼리 성능, 높은 동시성이 중요하다.

 

답(드래그): 임베디드 분석