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

 

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

1-1. 신뢰(Trust)

최종 사용자가 데이터를 비즈니스의 신뢰 가능한 표현으로 받아들여야 한다.

• 데이터 품질 실현
• 데이터 검증: 재무정보/고객 상호작용/매출 등을 정확히 나타내는지 분석·확인
• 데이터 관찰 가능성(Observability): 데이터와 프로세스에 대한 지속적 뷰

→ “서빙 단계만”이 아니라 데이터 엔지니어링 수명 주기 전체에 적용

 

또한 신뢰는 “데이터 자체”뿐 아니라 “운영 약속”으로도 쌓인다.

• 최종 사용자·업스트림 이해관계자와 SLA/SLO 협의
  • SLA 예: 데이터는 안정적으로 사용 가능하고, 고품질이어야 한다.

1-2. 사용사례는 무엇이고, 사용자는 누구인가

데이터는 행동으로 이어질 때 효과가 극대화된다.

사용사례를 정할 때 던질 질문은 다음과 같다:

• 이 데이터는 어떤 행동(작업)을 트리거하는가?
• 그 행동은 누가 수행하는가?
• 그 작업은 자동화할 수 없는가?

우선순위:

• ROI가 높은 사용 사례에 우선순위 부여

체크리스트:

• 데이터를 누가, 어떻게 사용할지
• 이해관계자는 무엇을 기대하는지
• 데이터 이해관계자(DS/분석가/비즈니스 사용자)와 협력해 “현재 데이터가 실제로 어떻게 쓰이는지” 이해

1-3. 데이터 제품(Data Product)

• 데이터 제품: 데이터를 사용해 최종 목표 달성을 촉진하는 제품
• 데이터 제품 제작은 제품 + 비즈니스 + 기술의 융합물
• “사람들이 사용하고 좋아할” 데이터 제품을 목표로
• → 만들 때 수행해야 할 작업(운영/문서/지원/권한/품질 등)을 함께 떠올리면 유용

1-4. 셀프서비스(Self-service) 여부

사용자가 데이터 제품과 어떻게 인터페이스하는지가 중요하다.

• 셀프서비스 데이터 제품: 사용자가 직접 제품/분석을 구축할 수 있게 지원
• 사용자별 기대치:
  • 경영진: 명확·실행 가능한 KPI, 미리 정의된 대시보드
  • 분석가: 이미 SQL 기반 셀프서비스 분석을 추진 중일 수도

1-5. 데이터 정의 및 논리(Definition & Logic)

데이터 유용성은 정확성과 신뢰성에 기반한다.

• 데이터 정확성 = 적절한 데이터 정의와 데이터 로직 포함
• 정의/로직은 원천 시스템 → 파이프라인 → BI → ML까지
• 수명주기 전 단계에 반영돼야 한다.

개념 정리:

• 데이터 정의: 조직 전체에서 공유되는 “의미”
  • 예: ‘고객’이 부서마다 다른 의미를 갖지 않도록 공식화
• 데이터 로직: 지표를 도출하는 공식/규칙
• 제도적 지식(Institutional knowledge):→ 정의/로직을 “공식 선언”하면 정확성·일관성·신뢰에 도움
• 일화/암묵지 형태로 자체 생명력을 갖고 떠도는 것들

현실적으로는 암묵적으로 퍼지기 쉽다:

• 쿼리/대시보드/ML 모델이 각자 정의를 다르게 쓰면
• 파생 지표가 일관되지 않게 표시됨

해결 힌트:

• 시맨틱 계층을 쓰면 비즈니스 정의·로직을 재사용 가능한 방식으로 통합 가능

1-6. 데이터 메시(Data Mesh)

사일로화된 중앙 데이터팀이 전부 처리하는 대신, 도메인 팀이 P2P 데이터 서비스의 책임을 나눠 갖는 형태로 설명됨.

도메인 팀이 맡는 두 측면:

1. 다른 팀이 쓰기 좋게 데이터를 준비해 제공
   • 데이터 애플리케이션, 대시보드, 분석/BI에서 소비하기 편리한 형태
2. 셀프서비스를 위한 대시보드/분석 실행 가능
   • 다른 팀이 소비하는 데이터가 임베디드 분석/ML 기능을 통해
   • 도메인팀이 설계한 소프트웨어로 유입될 수도 있음

2) 분석(Analytics)

2-1. 비즈니스 분석(Business Analytics)

• 과거/현재 데이터를 활용해 전략적이고 실행 가능한 결정
• 도메인 지식 + 인간의 판단 + 통계/추세 분석이 혼합

서빙 형태:

• 대시보드: 매출/고객 유지율 등 핵심 지표를 시각화(차트/히트맵), 요약 통계, 단일 숫자 KPI
• KPI/OKR 기반 보고서 작성
• 보고서는 종종 애드혹 요청에서 시작

데이터 제공 방식:

• DW/데이터 레이크에서 배치 모드로 제공되는 경우가 많음

2-2. 운영 분석(Operational Analytics)

비즈니스 분석이 “인사이트로 실행을 돕는 것”이라면, 운영 분석은 “즉각 조치”가 핵심.

• 차이의 핵심: 시간
• 예: 실시간 모니터링 대시보드(초당 요청 수, DB I/O 등)
• 스케일링 이벤트 트리거, 과부하 시 용량 추가
• 임계값 초과 시 SMS/그룹채팅/이메일 경고

2-3. 임베디드 분석(Embedded Analytics)

내부(비즈니스/운영) 분석 ↔ 외부 사용자에게 제공하는 분석

• 데이터 애플리케이션이 최종 사용자에게 분석 기능 제공
• 애플리케이션 자체에 대시보드를 내장하는 형태

문제/요구사항:

1. 짧은 데이터 지연 허용(앱 사용자는 내부 분석가만큼 “느린 배치”에 관대하지 않음)
2. 빠른 쿼리 성능(파라미터 조정 시 몇 초 내 반응)
3. 높은 동시성(많은 고객/대시보드에 대해 높은 쿼리 속도)

3) 머신러닝(ML)

3-1. 경계가 흐려지는 영역

• ML/데이터과학/데이터엔지니어링/ML엔지니어링의 경계가 모호해짐
• DE는 데이터를 처리해 모델 학습용으로 전달하고,
• 경우에 따라 데이터 특성화(Feature) 같은 ML 고유 작업 일부도 맡을 수 있음

3-2. 데이터 엔지니어가 ML에 대해 알아야 할 것

“학습 항목” 형태로 그대로 정리하면:

• 지도/비지도/준지도 학습 차이
• 분류 vs 회귀 차이
• 시계열 처리 기술(시계열 분석/예측 포함)
• 로지스틱 회귀, 트리 기반, SVM 등 고전 기법 vs 딥러닝 사용 시점
• AutoML vs 수작업 ML의 차이와 트레이드오프
• 정형/비정형 데이터별 데이터 랭글링
• 정형·반정형 제공 시, Feature Engineering 과정에서 적절한 변환이 가능한지
• 범주형 데이터 인코딩, 다양한 데이터 임베딩 방식
• 배치 학습 vs 온라인 학습 차이와 적용 방식
• DE 수명주기와 ML 수명주기의 교차점 이해
• (Feature Store, ML 관찰가능성 등 무엇을 인터페이스/지원할지)
• 로컬/클러스터/엣지 학습의 적절한 시점, CPU vs GPU 판단
• 배치 데이터(오프라인 학습) vs 스트리밍 데이터(온라인 학습) 적용 차이
• 데이터 캐스케이드(Data Cascade)와 ML 모델에 미치는 영향
• 결과 제공 방식: 실시간 반환 vs 배치 반환
• (예: 음성 전사 모델은 API 호출 후 음성 샘플 처리, 텍스트 일괄 반환 등)
• 정형/비정형을 함께 다루는 방식(표 데이터 클러스터링, 이미지 신경망 등)

4) 분석 및 ML을 위한 데이터 서빙 방법

4-1. 파일 교환(File Exchange)

• 어디서나 가능(가장 단순)
• 처리 후 소비자에게 전달할 파일 생성
  • 예: 고객 메시지 텍스트 파일(비정형), 송장 CSV, 엑셀을 이메일로 전송
• 단점:
  • 파일 편차 발생
  • 검색/추적이 어려움
• 객체 스토리지: 다양한 blob 파일 저장에 적합

4-2. 데이터베이스(Database, 주로 OLAP 관점)

데이터베이스 기반 서빙의 강점(너 메모 그대로):

1. 스키마로 데이터에 구조 부여
2. 테이블/열/행 수준의 세분화된 권한 제어
3. 대규모 계산 집약 쿼리 + 높은 동시성 제공

BI 도구 사례:

• Tableau: 초기 쿼리로 DB에서 데이터를 가져와 로컬 저장하는 방식이 흔함
• Looker: 쿼리 푸시다운 계산 모델에 의존

4-3. 스트리밍 시스템(Streaming Systems)

• 기존 “쿼리”와는 다른 방식으로 방출된 측정 지표(이벤트/메트릭)를 포함할 수 있음
• 운영/임베디드 요구(지연/동시성)에 맞춰 서빙 계층으로 쓰일 수 있음

4-4. 쿼리 페더레이션(Query Federation)

• 데이터 레이크/RDBMS/DW 등 여러 원천에서 데이터를 가져옴
• 분산 쿼리/가상화 엔진이 데이터를 중앙 집중 저장하지 않아도 쿼리 가능

주의점:

• 최종 사용자가 여러 시스템을 동시에 쿼리할 수 있다는 점을 전제로 해야 함
• 시스템마다 사용 패턴/특이점/미묘한 차이가 있어 운영 난도가 올라감
• 장점: 애드혹 쿼리 허용 → 여러 시스템 데이터를 섞어 탐색 분석 가능
• 원천 시스템에는 보통 읽기 전용 접근 허용

4-5. 데이터 공유(Data Sharing)

• 클라우드 멀티테넌트 스토리지 시스템을 통한 공유
• 서빙의 초점이 “데이터를 만드는 엔지니어”보다
• “데이터 소비자가 처리”하는 방향으로 이동
• 보안/접근제어 이슈가 핵심으로 올라옴

4-6. 시맨틱 계층 & 메트릭 계층(Semantic & Metric)

• 강력한 쿼리 엔진 ≠ 고품질 비즈니스 분석
• → 분석 품질은 정의/로직의 일관성에서 갈림
• 메트릭 계층: 비즈니스 로직을 유지·계산하는 도구(지표 정의의 표준화)
  • BI 도구 또는 변환 쿼리 작성 소프트웨어
• 시맨틱 계층: 복잡한 비즈니스 로직을 재사용 가능하게 정의
  • Looker/LookML: 가상의 복잡한 비즈니스 로직 정의
  • dbt: SQL 흐름 + 표준 지표 정의를 포함하는 데이터 흐름 구성

4-7. 노트북 기반 서빙(Notebook Serving)

• Jupyter Notebook: 오픈소스 노트북/서버 및 다양한 클라우드 관리형 서비스
• DS는 API/DB/DW/데이터 레이크 등에 프로그래밍 방식으로 연결
• Pandas: 파이썬 데이터 조작/분석 라이브러리
• 클라우드 기반 노트북: Dask/Ray/Spark 등과 결합 가능
• 예: Amazon SageMaker 등

5) 역 ETL(Reverse ETL)

• OLAP 데이터베이스의 데이터를 원천(운영) 시스템으로 다시 적재해 제공
• 주의점:
  • 본질적으로 피드백 루프
  • 그래서 세심한 모니터링/감시 체계가 필수

6) 함께 작업하는 사람들

• 데이터 분석가
• 데이터 과학자
• MLOps/ML 엔지니어
• 비즈니스(비기술 이해관계자)
• 관리자/경영진
• 데이터 엔지니어는 이 이해관계자들을 “지원”하는 역할

→ 직무와 관심사를 분리함으로써 협업이 쉬워질 수 있음

7) 드러나지 않는 요소(Hidden Layers)

7-1. 보안(Security)

• 사람/시스템 모두에 최소 권한 원칙
• 사용자(분석가/DS/경영진)와 대상(서빙 시스템)은 서로 다른 요구
• 고급 접근이 필요 없으면 읽기 전용 권한 부여
• 사용자 그룹을 특정 IAM 역할(또는 커스텀 역할)과 결합해 관리

멀티테넌트 환경 고려:

• 필터링된 뷰 제공
• 데이터 제품 사용 빈도 점검

→ “공유 중단”이 합당한 경우도 판단

7-2. 데이터 관리(Data Management)

• 사람들이 고품질·신뢰 가능한 데이터에 접근할 수 있게 하는 것
• 피드백 루프로 데이터 신뢰와 개선을 “적극적 프로세스”로 만들기
• 익명화 등(민감 데이터 처리)
• 엄격한 데이터 모델 + 시맨틱/메트릭 계층을 서빙 계층에 통합

→ 단일한 “진실의 원천”에 가까워짐

7-3. 데이터 옵스(DataOps)

모니터링 항목:

• 데이터 상태 및 데이터 다운타임
• 서빙 시스템(대시보드/DB 등)의 지연
• 데이터 품질
• 데이터/시스템 보안 및 접근
• 서빙되는 데이터와 모델 버전
• SLO 달성을 위한 가동 시간

목표:

• 데이터 다운타임 최소화
• 데이터 품질 극대화

7-4. 데이터 아키텍처(Data Architecture)

• 피드백 루프가 빠르고 긴밀해야 함
• 필요할 때 필요한 데이터를 최대한 빨리 접근
• 개발/테스트/운영 환경 협업을 위해
• 공통 클라우드 시스템으로 마이그레이션해 운영 아키텍처를 정립

7-5. 오케스트레이션(Orchestration)

• 약속된 시간에 소비자에게 데이터 제공하도록 팀 간 데이터 흐름 조정
• 중앙집중식 vs 분산식
  • 중앙 접근식: 단일 운영 자산 보호를 위한 게이트키핑 성격

7-6. 소프트웨어 엔지니어링(Software Engineering)

• 서빙 단계에서는 코드 작성 필요성이 줄어들 수 있지만,
  • 로컬 코드를 변환해 운영용 보고서/기본 ML 모델로 “작동”시켜야 할 수 있음
• 코드/쿼리가 스토리지 시스템에서 어떻게 수행되는지 이해 필요
• 올바른 페이로드가 전달되도록 보장해야 함