16. Data Engineering 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/16-data_engineering/source.md

짧은 소개

이 장은 머신러닝 시스템에서 데이터 엔지니어링이 왜 핵심 기반인지 설명해요. 모델이 아무리 좋아도 데이터가 부정확하거나, 한쪽으로 치우치거나, 학습 때와 실제 서비스 때 다르게 처리되면 production 환경에서 성능이 조용히 무너질 수 있어요.

원문은 데이터 엔지니어링을 단순한 전처리 작업이 아니라, 데이터 수집, ingestion, 처리, 라벨링, 저장, feature store, 개인정보 보호, lineage, audit까지 포함하는 시스템 설계 문제로 다룹니다. 특히 Quality, Reliability, Scalability, Governance라는 네 가지 기둥을 기준으로 모든 결정을 평가해야 한다고 설명해요.

읽는 방법

처음부터 모든 세부 기술을 한 번에 외우려고 하지 않아도 괜찮아요. 이 장은 반복해서 깊이를 높이는 방식으로 읽는 것이 좋아요.

1. 먼저 목차와 요약을 보며 “데이터가 흘러가는 큰 길”을 잡아요.
2. 그다음 네 가지 기둥이 각 단계에서 무엇을 요구하는지 확인해요.
3. 마지막으로 KWS, 즉 wake word를 감지하는 음성 시스템 사례를 따라가며 구체적인 설계 판단을 연결해요.

전체 흐름은 이렇게 보면 좋아요.

문제 정의와 거버넌스 원칙
  ↓
데이터 수집 전략
  ↓
데이터 ingestion
  ↓
데이터 처리와 feature 생성
  ↓
라벨링
  ↓
저장 구조와 feature store
  ↓
보안, privacy, lineage, audit

이 장의 한 줄 요약

ML 데이터 엔지니어링은 “학습 데이터를 준비하는 보조 작업”이 아니라, 품질, 신뢰성, 확장성, 거버넌스를 갖춘 데이터 기반을 설계해서 모델이 실제 환경에서도 믿을 수 있게 작동하도록 만드는 시스템 공학입니다.

1단계: 중학교 수준

데이터는 AI의 재료예요

맛있는 음식을 만들려면 좋은 재료가 필요하죠. 상한 재료로는 아무리 훌륭한 요리사도 좋은 음식을 만들기 어려워요. 머신러닝도 비슷해요. 모델은 데이터에서 행동을 배우기 때문에, 데이터가 잘못되어 있으면 모델도 잘못 배워요.

여기서 데이터 엔지니어링은 “재료 창고와 조리 준비대”를 잘 관리하는 일이라고 볼 수 있어요. 재료를 어디서 가져올지, 상하지 않았는지, 필요한 만큼 있는지, 누가 만졌는지, 나중에 문제가 생기면 어디서 온 재료인지 알 수 있게 만드는 일이에요.

데이터 파이프라인은 공장 컨베이어벨트 같아요

공장에서는 원재료가 들어오면 검사하고, 다듬고, 포장하고, 창고에 보관해요. 데이터도 마찬가지예요.

이 컨베이어벨트 중 한 곳에서 문제가 생기면 뒤쪽 단계가 모두 영향을 받아요. 잘못된 라벨이 붙으면 모델이 틀린 정답을 배우고, 서비스에서 들어오는 데이터가 학습 때와 다르게 생기면 모델은 당황하게 됩니다.

네 가지 기둥을 쉬운 말로 바꿔볼게요

이 네 가지는 따로따로가 아니에요. 예를 들어 데이터를 많이 모으면 확장성은 좋아 보일 수 있지만, 개인정보 동의를 제대로 받지 않았다면 거버넌스가 무너져요. 그래서 항상 함께 봐야 해요.

데이터 문제는 조용히 번져요

일반 프로그램은 잘못된 입력이 들어오면 오류 메시지를 내는 경우가 많아요. 하지만 ML 시스템은 더 위험할 수 있어요. 잘못된 데이터가 들어와도 겉으로는 작동하는 것처럼 보이다가, 모델 성능이 조금씩 나빠질 수 있거든요.

원문은 이런 현상을 데이터 cascade라고 설명해요. 작은 데이터 문제가 뒤 단계로 가면서 점점 커지는 상황이에요.

처음에 잘못 모은 데이터
  ↓
잘못된 라벨이나 feature
  ↓
잘못 배운 모델
  ↓
실제 서비스 성능 저하
  ↓
사용자에게 피해

그래서 데이터 엔지니어링은 “나중에 청소하면 되겠지”가 아니라, 처음부터 문제를 막는 일에 가까워요.

KWS 예시로 감을 잡아볼게요

KWS는 스마트폰이나 스마트 스피커가 “OK, Google”이나 “Alexa” 같은 wake word를 알아듣는 시스템이에요. 이 시스템이 잘 작동하려면 조용한 방에서 녹음한 음성만 있으면 부족해요.

사람마다 억양이 다르고, 아이와 어른의 목소리가 다르고, 주방 소음이나 자동차 소음도 있어요. 어떤 기기는 마이크 품질이 좋고, 어떤 기기는 그렇지 않아요. 그러니 좋은 KWS 모델을 만들려면 다양한 사람, 장소, 소음, 언어를 포함한 데이터가 필요해요.

여기서 데이터 엔지니어링은 음성을 모으고, 너무 시끄러운 녹음을 걸러내고, wake word가 어디에 있는지 표시하고, 개인정보를 보호하고, 나중에 어떤 데이터가 어떤 모델에 쓰였는지 기록하는 전체 과정이에요.

1단계 중간 정리

데이터 엔지니어링은 AI에게 좋은 “학습 환경”을 만들어주는 일이에요. 모델은 데이터에서 배워요. 그래서 데이터가 엉망이면 모델도 엉망이 되고, 데이터가 잘 관리되면 단순한 모델도 실제 환경에서 꽤 잘 작동할 수 있어요.

2단계: 고등학교 수준

블랙박스 안의 흐름을 열어볼게요

이제 데이터가 어떻게 흘러가는지 조금 더 논리적으로 보겠습니다.

Raw data
  ↓
Validation
  ↓
Cleaning
  ↓
Transformation
  ↓
Feature engineering
  ↓
Labeling
  ↓
Storage / Feature store
  ↓
Training and serving

여기서 중요한 점은 데이터가 한 번만 쓰이고 끝나지 않는다는 거예요. 학습 때도 쓰이고, 평가 때도 쓰이고, 실제 서비스에서도 같은 의미의 feature로 다시 쓰여요. 그래서 각 단계의 규칙이 명확해야 해요.

네 가지 기둥을 판단 기준으로 사용해요

예를 들어 web scraping으로 데이터를 많이 모으면 확장성은 좋아질 수 있어요. 하지만 저작권, 개인정보, 이용 약관 문제가 생기면 거버넌스가 약해져요. 반대로 전문가가 직접 검수한 데이터는 품질은 높지만 비용과 속도 면에서 확장성이 낮을 수 있어요.

데이터 품질은 간단한 숫자로도 감시할 수 있어요

데이터 파이프라인에서는 다음 같은 지표를 계속 봐요.

평균만 보면 놓치는 문제가 많아서, 원문은 95번째 백분위 latency 같은 지표도 중요하게 다뤄요. 95번째 백분위는 “전체 요청 중 95%가 이 시간 안에 끝난다”는 뜻이에요. 평균보다 실제 느린 사용자 경험을 더 잘 보여줄 때가 많아요.

학습과 서비스의 입력은 같은 규칙으로 만들어야 해요

이 장에서 가장 중요한 개념 중 하나가 training-serving consistency예요. 학습할 때 만든 feature와 실제 서비스에서 만든 feature가 같은 의미여야 한다는 뜻이에요.

예를 들어 학습 때는 “최근 30일 구매 횟수”를 계산했는데, 서비스에서는 실수로 “최근 7일 구매 횟수”를 넣는다면 모델은 같은 이름의 feature를 받아도 전혀 다른 의미로 해석하게 돼요.

간단히 쓰면 이렇게 볼 수 있어요.

[ \text{예측 결과} = f(\text{feature}) ]

여기서 모델 (f)는 학습 때 본 feature의 의미에 맞춰져 있어요. 그런데 서비스에서 feature의 계산 방식이 달라지면, 같은 함수에 다른 의미의 입력을 넣는 셈이에요. 그러면 성능이 떨어져도 오류 메시지는 안 나올 수 있어요.

Batch와 Streaming은 시간 감각이 달라요

원문은 실시간 처리가 batch보다 10배에서 100배까지 비쌀 수 있다고 설명해요. 항상 켜져 있어야 하고, 장애에 대비한 복제와 낮은 지연 시간 요구가 있기 때문이에요.

간단한 계산으로 KWS 데이터 규모를 느껴볼게요

원문의 KWS 예시에서는 2,300만 개의 1초 오디오 샘플을 생각해요. 오디오는 16 kHz, 16-bit PCM이라고 가정합니다.

[ \text{저장량} = 23 \times 10^6 \times 1 \times 16000 \times 2 ]

결과는 약 736 GB예요. “음성 1초”는 작아 보이지만, 수천만 개가 모이면 이미 큰 데이터가 됩니다.

또 feature 추출이 한 CPU core에서 실제 시간보다 100배 빠르다고 해도,

[ \frac{23 \times 10^6 \text{초}}{100} = 230000 \text{초} \approx 64 \text{시간} ]

즉 단일 core로는 오래 걸려요. 하지만 64개 core로 나누면 약 1시간 수준으로 줄일 수 있어요. 여기서 분산 처리와 병렬 처리의 필요성이 자연스럽게 나와요.

라벨링 비용도 수식으로 감을 잡을 수 있어요

라벨링은 “사람이 정답만 붙이면 끝”이 아니에요. 검수, 재작업, 전문가 리뷰가 함께 들어가요.

원문은 라벨링 비용을 이렇게 생각해요.

[ \text{Total Cost} = N \times \text{Cost}{label} \times (1 + R{review}) \times (1 + R_{rework}) ]

각 항의 의미는 이렇습니다.

라벨 하나가 싸 보여도 데이터가 백만 개, 천만 개로 커지면 전체 비용은 매우 커져요. 그래서 AI가 먼저 라벨 초안을 만들고 사람이 검수하는 pre-annotation, 불확실한 예시만 사람에게 보내는 active learning 같은 방법을 씁니다.

저장소는 “어디에 넣을까?”가 아니라 “어떻게 읽을까?”의 문제예요

학습은 보통 큰 데이터를 순서대로 많이 읽어요. 반면 서비스는 한 사용자에 대한 feature를 아주 빠르게 찾아야 해요. 그래서 한 가지 저장소만으로 모든 요구를 만족하기 어렵고, 여러 저장소를 역할별로 조합하게 됩니다.

2단계 중간 정리

이 장의 논리는 단순해요. ML 시스템의 행동은 데이터에서 나오고, 데이터는 파이프라인을 따라 계속 변해요. 따라서 각 단계마다 “품질이 좋은가, 실패해도 버티는가, 커져도 감당하는가, 규칙을 지키는가”를 확인해야 합니다.

3단계: 대학교 수준

1. Data Engineering as a Systems Discipline

원문은 데이터 엔지니어링을 ML workflow의 하위 보조 작업이 아니라 시스템 discipline으로 정의해요. 전통적인 소프트웨어에서는 동작이 주로 코드에 명시됩니다. 반면 ML 시스템에서는 동작이 데이터 패턴에서 생겨요. 그래서 데이터는 소스 코드처럼 엄격하게 관리해야 하는 1급 대상이 됩니다.

이 차이 때문에 ML 데이터 문제는 일반 소프트웨어 오류보다 탐지하기 어렵습니다. 잘못된 입력이 들어와도 프로그램이 즉시 실패하지 않고, 모델 성능이 서서히 낮아지는 형태로 나타날 수 있어요. 잘못된 라벨 몇 개가 개별적으로는 작아 보여도, 특정 feature 공간 전체를 오염시킬 수 있고, production 데이터 분포가 천천히 바뀌면 재학습이 필요할 때까지 문제가 숨어 있을 수 있습니다.

따라서 데이터 엔지니어링은 다음을 체계적으로 설계하는 일입니다.

중요한 점은 각 구성요소를 따로 최적화하지 않는다는 거예요. 수집 방식은 라벨링 비용에 영향을 주고, 저장 방식은 학습 속도와 feature 일관성에 영향을 주며, 거버넌스 정책은 수집과 보관 기간을 제한합니다.

2. Four Pillars Framework

원문은 데이터 엔지니어링 결정을 네 가지 기둥으로 평가해요.

이 네 기둥은 서로 긴장 관계를 가져요. 품질을 높이기 위해 전문가 검수를 늘리면 비용과 속도에 영향을 줍니다. 확장성을 위해 web scraping을 늘리면 privacy와 저작권 문제가 커질 수 있어요. 거버넌스를 강화하면 접근 절차가 복잡해져 개발 속도가 늦어질 수 있지만, 장기적으로는 신뢰성과 재현성을 높입니다.

원문은 데이터 과학자가 많은 시간을 data preparation에 쓴다는 현실을 언급하며, 이 시간을 줄이려면 ad-hoc cleaning이 아니라 네 기둥에 기반한 체계적 인프라가 필요하다고 설명해요.

3. Data Cascades and the Need for Systematic Foundations

Data cascade는 초기 데이터 품질 문제가 pipeline 전체로 증폭되는 실패 패턴이에요. ML 시스템에서는 “나쁜 입력이면 즉시 오류”가 아니라 “나쁜 입력을 조용히 학습하고, 나중에 production에서 성능이 무너짐”이 될 수 있어요.

이를 막으려면 데이터 수집 전에 다음이 먼저 정리되어야 합니다.

KWS case study

KWS 시스템은 wake word를 연속 오디오 스트림 안에서 낮은 latency로 감지해야 해요. 원문의 예시에서는 다음 요구가 함께 등장합니다.

KWS 데이터는 억양, 나이, 성별, 배경 소음, 발음 변형, 언어 다양성을 담아야 합니다. 기존 데이터셋은 빠른 시작점이지만 accent, 언어, 환경 다양성이 부족할 수 있어요. 그래서 web scraping, crowdsourcing, synthetic generation을 조합하게 됩니다.

4. Data Pipeline Architecture

데이터 파이프라인은 네 기둥을 실제 시스템으로 구현하는 곳이에요. 원문은 ML 파이프라인을 data sources, ingestion, processing, labeling, storage, ML training의 여러 layer로 봅니다.

중요한 제약은 CPU만이 아니에요. 원문은 storage hierarchy와 I/O bandwidth가 pipeline 설계의 핵심 병목이라고 강조해요. RAM은 대략 50-200 GB/s 수준의 bandwidth를 가질 수 있지만, spinning disk는 100-200 MB/s 수준에 머물 수 있어요. 실시간 serving에는 낮은 latency의 in-memory store가 필요할 수 있고, archive에는 object storage가 더 적절할 수 있습니다.

4.1 Quality through validation and monitoring

데이터 품질은 schema validation만으로 충분하지 않아요. 원문은 production ML failure의 큰 비율이 schema 변경, distribution drift, 조용한 데이터 손상에서 나온다고 설명해요.

실무적으로는 severity 기반 alerting을 둡니다.

숫자형 feature는 평균, 표준편차, quantile, Kolmogorov-Smirnov test 같은 통계 검정으로 training 분포와 serving 분포를 비교할 수 있어요. 범주형 feature는 category 빈도와 새 category 출현을 감시합니다.

동기 validation은 빠른 record 단위 검사에 적합해요. 예를 들어 필수 field가 null인지, 값 범위가 맞는지, 타입이 맞는지 확인합니다. 반대로 분포 비교처럼 많은 record가 필요한 검사는 ingestion을 막지 않도록 비동기로 수행해요. serving traffic의 1-10%를 sample로 모아 1시간, 24시간, 7일 rolling window를 보는 방식이 대표적입니다.

가장 까다로운 문제는 training-serving skew예요. 학습 pipeline은 batch join으로 feature를 만들고, serving은 real-time microservice나 materialized view로 feature를 만들면 미묘한 차이가 생길 수 있어요. 원문은 이런 차이가 production A/B test에서 큰 accuracy drop으로 이어질 수 있다고 설명합니다.

4.2 Reliability through graceful degradation

Reliability는 문제가 생겨도 전체 시스템이 무너지지 않도록 만드는 능력이에요. 실패 유형은 비교적 반복됩니다.

Exponential backoff는 1초, 2초, 4초처럼 재시도 간격을 늘려 복구 중인 서비스를 더 압박하지 않게 해요. Dead letter queue는 실패 데이터를 버리지 않고 따로 저장해서 나중에 분석하거나 재처리할 수 있게 합니다. Circuit breaker는 반복 실패한 component 호출을 잠시 중단해 장애 전파를 막아요.

Fallback도 중요해요. 추천 시스템에서 최근 30일 선호도를 계산할 수 없으면 최근 90일 선호도 같은 덜 정확하지만 쓸 수 있는 feature로 degraded service를 제공할 수 있습니다.

4.3 Scalability patterns

Scalability는 데이터 양과 사용자가 늘어도 시스템을 처음부터 다시 만들지 않도록 설계하는 일이에요. 원문은 batch ingestion, stream ingestion, hybrid approach를 구분합니다.

Stream processing에서는 backpressure가 중요해요. downstream이 처리 속도를 따라가지 못하면 buffer를 늘릴지, sample을 버릴지, producer를 늦출지 선택해야 합니다. 이 선택은 data loss, latency, memory 사용량 사이의 trade-off예요.

분산 처리는 data partitioning을 통해 scale out하지만, coordination overhead가 생겨요. local operation은 microsecond 단위로 끝날 수 있지만 network coordination은 millisecond 단위가 필요할 수 있어 약 1000배 차이가 납니다. 그래서 모든 작업이 같은 정도로 잘 병렬화되지는 않아요.

원문의 KWS 계산은 병목을 잘 보여줘요.

[ \text{Storage} = 23 \times 10^6 \times 1 \times 16000 \times 2 = 736 \text{ GB} ]

그리고 feature 추출이 100배 real-time으로 가능하다면 단일 core 기준 약 64시간이 걸려요.

[ \text{Processing time} = \frac{23 \times 10^6}{100} = 230000 \text{ sec} \approx 64 \text{ hours} ]

64 cores로 나누면 약 1시간으로 줄어듭니다. 하지만 736 GB를 GPU 서버로 옮기는 데도 bandwidth에 따라 수십 초 이상 걸릴 수 있어서, 학습 시간과 data movement 시간이 비슷해지는 상황이 생겨요. 그래서 storage bandwidth, NVMe, 고속 network가 ML workload에서 중요합니다.

4.4 Governance through observability

Governance는 pipeline을 투명하게 만드는 infrastructure로 구현됩니다.

이 정보가 있어야 모델 성능이 떨어졌을 때 원인을 추적하고, 규제 감사에서 적절한 처리를 증명하고, 예전 모델을 정확히 재현할 수 있어요.

5. Strategic Data Acquisition

Data acquisition은 “데이터를 많이 모으기”가 아니라 시스템의 한계와 가능성을 결정하는 전략입니다. 원문은 기존 데이터셋, web scraping, crowdsourcing, synthetic generation이 각각 다른 trade-off를 가진다고 설명해요.

5.1 Data source evaluation and selection

기존 데이터셋은 빠르게 시작할 수 있고 benchmark로 쓰기 좋아요. Kaggle, UCI, ImageNet, Google Speech Commands 같은 데이터셋은 prototype과 baseline에 유용합니다.

하지만 한계도 분명해요. 유명 데이터셋에도 label error가 있을 수 있고, documentation이 부족하면 수집 맥락을 오해할 수 있어요. 또 standard dataset에만 맞춰 성능을 올리면 real-world deployment와 어긋날 수 있습니다. 여러 시스템이 같은 데이터셋으로 학습하면 같은 blind spot을 공유하는 dataset convergence 위험도 생겨요.

KWS에서는 Google Speech Commands가 시작점이 될 수 있지만, accent 다양성, 녹음 환경, 언어 coverage가 부족할 수 있어요.

5.2 Scalability and cost optimization

Web scraping은 큰 scale의 데이터를 빠르게 모을 수 있지만, 법적/윤리적 제약과 품질 문제가 큽니다. 웹 구조가 바뀌면 pipeline이 깨질 수 있고, 검색 결과가 맥락에 맞지 않는 데이터를 끌어올 수 있어요.

Crowdsourcing은 사람의 판단이 필요한 라벨링과 데이터 수집에 유용합니다. ImageNet처럼 대규모 annotation을 가능하게 했고, Waze처럼 사용자의 실시간 보고를 데이터로 활용하는 사례도 있어요. 하지만 품질 관리, worker 교육, 공정한 보상, 민감 콘텐츠 노출 문제가 함께 따라옵니다.

Synthetic data는 rare edge case를 만들거나 데이터 부족을 보완하는 데 강력해요. 자율주행에서 드문 사고 상황을 simulation하거나, 음성 인식에서 noise, pitch, 속도 변형을 추가하는 augmentation이 예입니다. 하지만 synthetic data가 실제 세계를 충분히 닮지 않으면 모델이 잘못된 패턴을 배울 수 있어요.

5.3 Reliability across diverse conditions

Reliable한 ML 시스템은 다양한 환경에서 일관되게 작동해야 해요. 데이터는 지역, 인구통계, 시간 변화, edge case를 포함해야 합니다.

KWS에서는 조용한 침실, 거리 소음, 여러 억양, 아이와 노인의 목소리까지 포함해야 production reliability가 올라갑니다.

5.4 Governance and ethics in sourcing

데이터 수집의 governance는 법적 준수, privacy, 공정한 노동, 투명성을 포함해요. scraping은 이용 약관, 저작권, 개인정보 문제가 있고, crowdsourcing은 노동 조건과 보상이 핵심 윤리 문제가 됩니다.

원문은 민감한 annotation 작업에서 낮은 임금과 심리적 부담 문제가 발생한 사례를 언급하며, 데이터 sourcing이 사람의 노동과 연결되어 있음을 강조해요. 공정한 보상, 정신 건강 지원, task 목적의 투명한 설명, 원치 않는 작업을 거부할 권리가 필요합니다.

Privacy 보호 기법도 sourcing 단계부터 고려해야 해요.

5.5 Integrated acquisition strategy

현실의 ML 시스템은 한 가지 방법만 쓰지 않아요. KWS에서는 기존 speech dataset으로 baseline을 만들고, web scraping으로 자연스러운 음성 variation을 보완하고, crowdsourcing으로 부족한 accent와 언어를 채우고, synthetic data로 noise와 rare condition을 확장합니다.

이 조합이 바로 네 기둥의 균형이에요. curated data는 quality, web scraping과 synthetic data는 scalability, 다양한 source는 reliability, consent와 anonymization은 governance를 담당합니다.

6. Data Ingestion

Ingestion은 외부 데이터를 controlled pipeline 안으로 들여오는 경계입니다. 이 경계에서 잘못된 데이터가 들어오지 않도록 validation하고, source failure를 견디고, 처리량을 확보하고, 접근과 audit을 남겨야 해요.

6.1 Batch vs. streaming ingestion patterns

Batch ingestion은 데이터를 모아 일정한 시간에 처리합니다. 예를 들어 매일 밤 판매 로그를 처리해 다음 날 inventory prediction 모델을 갱신할 수 있어요. 장점은 계산 자원을 효율적으로 쓸 수 있고, 실패 시 checkpoint부터 재처리하기 쉽다는 점입니다.

Streaming ingestion은 이벤트가 들어오는 즉시 처리합니다. 사기 탐지처럼 몇 시간 뒤에 알면 의미가 없는 문제에 필요해요. 하지만 backpressure, late event, always-on infrastructure, fault tolerance 때문에 복잡하고 비용이 큽니다.

많은 시스템은 둘을 섞어요. 추천 시스템은 click, view, purchase 같은 실시간 interaction은 streaming으로 반영하고, user profile이나 item feature는 batch로 갱신할 수 있습니다.

6.2 ETL and ELT comparison

ETL은 안정된 schema와 명확한 변환이 있는 경우 좋아요. ELT는 cloud data warehouse나 data lake 환경에서 feature engineering 요구가 자주 바뀔 때 유리합니다. 실제 시스템은 데이터 source별로 ETL과 ELT를 혼합하는 경우가 많아요.

Streaming architecture에서는 CAP theorem 같은 distributed systems trade-off도 등장해요. Kafka, Pulsar, Kinesis 같은 시스템은 consistency, availability, partition tolerance 사이에서 서로 다른 선택을 합니다.

6.3 Multi-source integration strategies

다양한 source는 format, protocol, update frequency가 달라요. 따라서 source별 connector가 필요합니다.

Connector는 보통 다음을 처리해요.

이 단계의 transformation은 business feature engineering이 아니라 technical format 표준화에 가깝습니다.

6.4 KWS ingestion case

KWS는 streaming과 batch를 함께 씁니다. 실제 기기에서 들어오는 audio stream은 200 ms latency 요구를 만족해야 하므로 streaming path를 탑니다. 반면 crowdsourcing 녹음, synthetic audio, false rejection 사례 등은 batch로 모아 모델 개선에 사용합니다.

Ingestion 단계에서는 signal-to-noise ratio, sample rate, duration, speaker proximity 같은 audio quality를 검사해요. 유효하지 않은 sample은 버리지 않고 dead letter queue에 보내 나중에 edge case로 분석할 수 있습니다.

7. Systematic Data Processing

데이터 처리는 raw data를 ML-ready feature로 바꾸는 단계예요. 원문은 production ML failure의 큰 원인으로 training-serving inconsistency를 강조합니다. transformation logic, normalization parameter, category vocabulary가 학습과 serving에서 동일해야 해요.

7.1 Ensuring training-serving consistency

Data cleaning은 missing value, duplicate, outlier, formatting inconsistency를 다룹니다. 하지만 production에서는 “어떤 cleaning을 했는가”보다 “항상 같은 방식으로 했는가”가 더 중요해요.

예를 들어 normalization을 할 때 학습 데이터에서 계산한 평균과 표준편차를 저장해야 합니다.

[ x’ = \frac{x - \mu_{train}}{\sigma_{train}} ]

여기서 (\mu_{train})과 (\sigma_{train})은 serving 때 새로 계산하면 안 돼요. 학습 때 저장한 값을 그대로 써야 같은 feature 의미가 유지됩니다.

Categorical encoding도 마찬가지예요. 학습 때 본 category vocabulary를 저장하고, serving에서 처음 보는 category는 unknown 같은 안전한 값으로 보내야 합니다.

KWS에서는 raw waveform을 MFCC나 spectrogram으로 바꿔요. Training에서 쓰는 FFT window size, hop length, MFCC coefficient 수가 serving과 다르면 모델은 다른 모양의 입력을 받게 됩니다.

7.2 Building idempotent data transformations

Idempotency는 같은 변환을 여러 번 적용해도 최종 결과가 같다는 뜻이에요. 장애가 나서 같은 batch를 재처리할 때 중복 record가 생기면 안 됩니다.

KWS feature extraction도 deterministic해야 해요. 같은 audio file은 어느 서버에서 언제 처리해도 같은 MFCC feature를 만들어야 디버깅과 재처리가 가능합니다.

7.3 Scaling through distributed processing

데이터가 TB 단위로 커지면 단일 machine 처리만으로 부족할 수 있어요. 하지만 분산 처리에는 coordination cost가 있습니다.

원문은 Amdahl’s Law를 통해 병렬화 한계를 설명해요.

[ \text{Speedup} \leq \frac{1}{S + \frac{P}{N}} ]

여기서 (S)는 병렬화할 수 없는 serial fraction, (P)는 병렬화 가능한 fraction, (N)은 processor 수예요. 오디오 파일별 feature extraction처럼 서로 독립적인 작업은 (S \approx 0)에 가까워 큰 speedup을 얻을 수 있어요. 하지만 전체 데이터의 평균과 표준편차를 모아야 하는 global normalization은 aggregation 단계가 serial bottleneck이 됩니다.

분산 처리 도구로는 Spark, Beam, TensorFlow tf.data 같은 것이 등장해요. 다만 원문은 분산 시스템을 너무 빨리 도입하기보다 Parquet 같은 효율적 format, vectorized operation, multi-core 활용 등 단일 machine 최적화도 먼저 고려할 수 있다고 설명합니다.

7.4 Tracking transformation lineage

Transformation lineage는 raw data가 어떤 code version, parameter, library, runtime에서 어떤 feature로 바뀌었는지 기록하는 것입니다.

추적해야 할 정보는 다음과 같아요.

이 정보가 없으면 예전 모델을 재현하거나 processing bug를 고친 뒤 영향을 받은 dataset을 찾기 어렵습니다.

7.5 End-to-end processing pipeline design

좋은 processing pipeline은 modular하고 versioned되어야 해요. 각 transformation은 입력과 출력이 명확한 독립 component여야 하고, 개별 test와 교체가 가능해야 합니다.

TensorFlow Transform, Apache Beam, TFX 같은 도구는 training과 serving에 같은 transformation logic을 적용하는 데 도움을 줍니다. KWS에서는 batch training pipeline과 real-time inference pipeline이 같은 audio normalization parameter와 feature extraction setting을 공유해야 합니다.

8. Data Labeling

라벨링은 사람의 판단이 들어가는 data engineering 문제예요. 원문은 labeling을 human-in-the-loop system engineering으로 다룹니다.

8.1 Label types and system requirements

Segmentation은 1920x1080 이미지 하나에 약 2백만 pixel label이 필요할 수 있어 classification보다 훨씬 큰 저장과 검수 비용을 요구합니다.

8.2 Achieving label accuracy and consensus

라벨 오류는 완전히 없애기 어렵기 때문에 측정하고 관리해야 해요. 원문은 ambiguous data와 expert knowledge가 필요한 data를 구분합니다. 흐릿한 이미지처럼 누구도 확신하기 어려운 경우와, 전문가라면 맞힐 수 있는 경우는 다른 routing이 필요해요.

Production labeling system은 보통 다음을 조합합니다.

Expert review는 crowdsourcing보다 10-50배 비쌀 수 있어요. 그래서 모든 데이터를 전문가에게 보내기보다 agreement가 낮은 5-15% 정도의 어려운 case만 보내는 tiered approach를 씁니다.

8.3 Building reliable labeling platforms

대규모 labeling platform은 단순한 웹 폼이 아니에요.

원문은 10,000 annotations/hour나 100,000 concurrent annotators 같은 규모에서는 task serving latency와 database write capacity를 함께 고려해야 한다고 설명합니다.

라벨링 비용은 compute 비용보다 훨씬 커질 수 있어요. 단순 image classification은 label당 몇 cent일 수 있지만, medical image annotation은 study당 수십에서 수백 달러가 될 수 있습니다. 품질 검수와 재작업까지 포함하면 처음 예상보다 비용이 크게 증가합니다.

8.4 Scaling with AI-assisted labeling

AI-assisted labeling은 사람을 완전히 대체하는 것이 아니라 사람의 판단을 증폭하는 방식이에요.

Active learning은 random sampling보다 필요한 annotation을 크게 줄일 수 있지만, 모델이 이미 보는 방식에 따라 “어떤 데이터가 중요해 보이는지”가 편향될 수 있어요. 그래서 AI-human agreement, confidence calibration, override rate를 함께 모니터링해야 합니다.

8.5 Ethical and fair labeling

Labeling governance는 사람의 복지와 직접 연결됩니다. 공정한 보상, 민감 콘텐츠 노출 제한, mental health support, task 목적 투명성, skip 권리가 필요해요.

또 annotator의 문화적, 지역적, 개인적 bias가 label에 반영될 수 있어요. 다양한 annotator pool을 구성하고, label 분포가 특정 annotator 집단에 따라 체계적으로 달라지는지 bias audit을 해야 합니다.

Privacy도 중요해요. Healthcare나 finance 데이터는 annotation platform 자체가 HIPAA 같은 규정을 만족해야 하고, annotator가 불필요하게 개인식별정보를 보지 않도록 anonymization과 access control을 적용해야 합니다.

Concept drift도 labeling governance의 일부예요. 예전에 정확했던 label이 시간이 지나며 의미가 달라질 수 있으므로 label versioning, re-annotation policy, retirement strategy가 필요합니다.

8.6 KWS automated labeling

KWS에서는 수천만 개의 wake word sample을 사람이 모두 자르는 것이 비현실적이에요. 원문은 Multilingual Spoken Words Corpus를 예로 들어, 50개 언어와 34만 keyword, 2,340만 개 이상의 1초 spoken example을 설명합니다.

핵심 기술은 forced alignment예요. 문장 audio와 transcript를 함께 보고, 각 단어가 audio의 어느 시간 구간에 해당하는지 millisecond 수준으로 맞춥니다. 이를 통해 긴 문장에서 keyword 조각을 자동 추출할 수 있어요.

자동화만으로 끝나지는 않습니다. 배경 소음, 단어 길이, 발음 속도, 음질을 검사하고, unusual accent나 rare word 같은 어려운 case는 human verification으로 보완합니다.

9. Strategic Storage Architecture

Storage architecture는 “저장할 곳”을 고르는 문제가 아니라 ML lifecycle의 access pattern을 맞추는 문제예요.

9.1 ML storage system options

Database는 user profile lookup처럼 millisecond access에 강하지만, 수백만 record를 epoch마다 scan하는 학습에는 부적합할 수 있어요. Warehouse는 columnar storage 덕분에 필요한 feature column만 읽어 I/O를 줄입니다. Data lake는 schema-on-read로 유연하지만 metadata catalog가 없으면 data swamp가 됩니다.

원문은 storage 선택을 데이터 규모와 access pattern으로 판단하라고 설명해요.

성숙한 ML 조직은 보통 세 가지를 모두 씁니다. raw heterogeneous data는 lake, curated analytical data는 warehouse, serving feature는 database나 online feature store에 둡니다.

9.2 ML storage requirements and performance

ML workload는 storage bandwidth에 매우 민감해요. 원문은 KWS 736 GB dataset을 object storage에 장기 보관하면 월 $15-18 수준일 수 있지만, active training을 위해 NVMe에 올리면 더 비싸지만 약 50배 빠른 data loading이 가능하다고 설명합니다.

훈련 처리량은 다음처럼 볼 수 있어요.

[ \text{Training Throughput} = \min(\text{Compute Capacity}, \text{Data Supply Rate}) ]

[ \text{Data Supply Rate} = \text{Storage Bandwidth} \times (1 - \text{Overhead}) ]

GPU가 아무리 빨라도 storage가 데이터를 공급하지 못하면 GPU는 기다리게 됩니다. RAM은 50-200 GB/s, network storage는 1-10 GB/s, NVMe SSD는 1-7 GB/s 수준일 수 있어요. LLM이나 고해상도 computer vision에서는 data movement가 학습 병목이 됩니다.

ML model artifact도 큽니다. GPT-3의 175B parameters는 32-bit float 기준 약 700 GB 규모라고 원문은 설명해요. Git만으로는 큰 binary checkpoint versioning이 어렵기 때문에 DVC, MLflow 같은 artifact tracking이 필요합니다.

9.3 Storage across the ML lifecycle

Development에서는 dataset copy를 무작정 늘리면 저장량이 폭증해요. DVC처럼 pointer와 delta를 추적하는 방식이 유용합니다.

Training에서는 precomputed feature와 on-the-fly computation의 균형이 필요해요. 비싼 feature를 미리 계산하면 학습이 빨라지지만 logic이 바뀌면 전체 재계산이 필요해 stale해질 수 있습니다.

Serving에서는 10 ms latency budget 안에 feature를 찾아야 하는 경우 Redis 같은 in-memory store가 필요할 수 있어요. Edge deployment에서는 제한된 flash/SRAM, intermittent connectivity, model update 안전성까지 고려합니다.

Monitoring에서는 hot, warm, cold tier를 나눠 최근 데이터는 빠르게, 오래된 데이터는 싸게 보관합니다.

9.4 Feature stores

Feature store는 training-serving consistency를 위한 핵심 인프라예요. 하나의 feature definition을 offline training과 online serving에서 함께 쓰도록 관리합니다.

Feature store가 해결하는 문제는 이렇습니다.

Notebook에서 만든 feature logic
  ≠
Production service에서 다시 구현한 feature logic
  ↓
Training-serving skew

Feature store는 feature definition, transformation logic, parameter, history를 중앙에서 관리해 같은 feature가 같은 의미로 계산되도록 해요. 또한 여러 팀이 같은 feature를 재사용할 수 있어 중복 구현과 미세한 차이를 줄입니다.

보통 dual storage를 씁니다.

Time-travel도 중요해요. Churn prediction을 학습할 때 1월 15일에 churn한 사용자는 1월 14일 기준 feature를 써야 합니다. 현재 feature를 쓰면 미래 정보가 섞여 data leakage가 됩니다. 그래서 feature history를 보관해야 하지만, storage 비용이 크게 증가합니다.

9.5 KWS storage case

KWS storage는 tiered architecture가 적합해요.

Edge device는 network가 불안정해도 wake word를 감지해야 하므로 local cache와 model update integrity가 중요합니다.

10. Data Governance

Data governance는 storage와 pipeline 위에 나중에 붙이는 문서가 아니에요. 시스템이 실제로 권한을 제한하고, privacy를 보호하고, 규제를 만족하고, 추적 가능하게 만드는 engineering layer입니다.

10.1 Security and access control architecture

Production ML 시스템은 layered security를 둡니다.

KWS에서는 voice data가 민감하기 때문에 training zone, production serving zone, operations zone을 분리하는 것이 중요해요. Serving system compromise가 training data write 권한으로 이어지면 안 됩니다.

10.2 Technical privacy protection methods

Privacy는 접근 제어만으로 끝나지 않아요. 데이터 자체가 개인을 덜 드러내도록 설계해야 합니다.

KWS에서는 on-device wake word detection이 privacy에 유리해요. wake word가 감지되기 전 audio를 cloud로 보내지 않는 구조이기 때문입니다. Federated learning은 raw audio를 중앙 서버로 보내지 않고 device에서 학습한 update만 모을 수 있게 해요.

자동 삭제도 engineering requirement예요. 예를 들어 voice sample은 30일 후 삭제하고, 장기 연구용으로 별도 동의를 받은 데이터만 오래 보관하는 lifecycle policy를 storage에 설정할 수 있습니다. Feature store의 TTL도 사용자 voice pattern을 일정 시간 뒤 삭제하게 만들 수 있어요.

GDPR의 삭제 요청은 단순히 raw audio만 지우면 끝나지 않아요. derived feature, embedding, model training artifact, audit reference까지 lineage를 통해 찾아야 합니다.

10.3 Architecting for regulatory compliance

Regulatory compliance는 pipeline 설계를 바꿉니다.

Data card는 이런 요구를 운영 artifact로 바꿉니다. 데이터셋의 목적, 동의 근거, 지리적 제한, 보관 기간, 사용 가능 범위를 기록하고, training pipeline이 유효한 data card 없는 dataset을 거부하도록 만들 수 있어요.

10.4 Data lineage infrastructure

Lineage system은 dataset, transformation, model artifact 사이의 graph를 만듭니다. Airflow나 Kubeflow job이 S3 audio를 읽어 spectrogram을 만들고 warehouse에 쓰면, lineage graph는 이 관계를 자동으로 기록해요.

KWS에서는 lineage가 다음을 연결합니다.

Crowdsourced audio / web scraped audio / synthetic audio
  ↓
Audio normalization
  ↓
MFCC / spectrogram / embedding
  ↓
Training dataset version
  ↓
Model artifact
  ↓
Device deployment

이 graph가 있어야 특정 accent에서 성능이 떨어질 때 해당 accent data가 부족했는지 추적할 수 있고, 사용자 삭제 요청이 들어왔을 때 파생 artifact를 찾을 수 있습니다.

10.5 Audit infrastructure and accountability

Audit은 “누가 언제 무엇을 접근했는가”를 남기는 시스템이에요. HIPAA, SOX 같은 규제에서는 immutable audit log가 중요합니다.

대규모 ML 시스템은 audit event가 매우 많아요. Training data access, feature store query, model prediction마다 log가 생기면 하루 수십억 건이 될 수 있습니다. 그래서 append-only storage, efficient indexing, anomaly detection이 필요해요.

KWS에서는 edge device가 wake word detection, model update, privacy setting change 같은 event를 local log로 남기고 주기적으로 중앙에 upload할 수 있어요. Feature store는 어떤 service가 어떤 user feature를 조회했는지 기록하고, training infra는 어떤 job이 어떤 data partition을 읽었는지 기록합니다.

Lineage와 audit이 함께 있으면 규제 감사, 보안 조사, 모델 품질 디버깅을 모두 지원할 수 있어요.

11. Fallacies and Pitfalls

원문은 데이터 엔지니어링에서 흔한 오해를 정리합니다.

특히 “학습 데이터만 좋으면 된다”는 생각이 위험해요. Production serving data가 학습 데이터와 달라지는 순간 모델은 조용히 성능이 떨어질 수 있습니다.

12. Summary

이 장의 결론은 명확해요. 데이터 엔지니어링은 raw information을 ML 시스템의 신뢰 가능한 기반으로 바꾸는 infrastructure입니다. Acquisition, ingestion, processing, labeling, storage, governance의 모든 단계는 서로 영향을 주고, 한 단계의 부실한 선택은 downstream 전체에 cascade될 수 있어요.

핵심을 다시 정리하면 다음과 같습니다.

결국 데이터 엔지니어링을 잘한다는 것은 모델이 배울 세계를 올바르게 만들고, 그 세계가 시간이 지나도 신뢰 가능하게 유지되도록 시스템을 설계한다는 뜻입니다.

복습 질문

1. ML 시스템에서 데이터 엔지니어링이 전통적인 소프트웨어의 코드 관리만큼 중요한 이유는 무엇인가요?
2. Quality, Reliability, Scalability, Governance 네 기둥은 각각 어떤 문제를 막기 위한 기준인가요?
3. Data cascade가 production ML 시스템에서 특히 위험한 이유는 무엇인가요?
4. KWS 시스템에서 다양한 억양, 배경 소음, 기기 조건을 데이터에 포함해야 하는 이유는 무엇인가요?
5. Training-serving consistency가 깨지는 구체적인 예를 하나 들어보세요.
6. Batch ingestion과 streaming ingestion의 비용과 latency trade-off를 설명해보세요.
7. ETL과 ELT는 transformation을 언제 수행하느냐가 어떻게 다르며, 각각 언제 유리한가요?
8. Idempotent transformation이 장애 복구에서 중요한 이유는 무엇인가요?
9. 라벨링 시스템에서 consensus labeling과 expert escalation은 어떤 trade-off를 가지나요?
10. Data lake가 data swamp가 되지 않으려면 어떤 metadata와 governance가 필요할까요?
11. Feature store가 training-serving skew를 줄이는 원리를 설명해보세요.
12. GDPR의 삭제 요청이 raw data뿐 아니라 derived feature와 model artifact까지 영향을 줄 수 있는 이유는 무엇인가요?