MLOps 02 - 데이터 파이프라인과 피처 엔지니어링

좋은 모델은 좋은 데이터에서 나온다

머신러닝 프로젝트에서 가장 흔한 착각은 모델 아키텍처가 성능을 결정한다는 것이다. 더 복잡한 모델을 쓰면 더 좋은 결과가 나올 것이라 기대하지만, 현실은 다르다. 데이터의 품질이 낮으면 아무리 정교한 모델을 사용해도 성능은 올라가지 않는다. 오히려 단순한 모델이라도 잘 정제된 데이터를 사용하면 복잡한 모델보다 나은 결과를 보이는 경우가 많다.

그렇다면 원시 데이터를 학습에 적합한 형태로 만드는 과정은 어떻게 체계화할 수 있을까? 이것이 데이터 파이프라인의 역할이다.

데이터 파이프라인의 구조

데이터 파이프라인은 원시 데이터를 수집하고, 변환하고, 저장하는 일련의 자동화된 과정이다. 데이터가 생성되는 시점부터 모델이 소비하는 시점까지의 흐름을 정의하고 관리하는 것이다.

이 과정에서 가장 기본적인 패턴이 ETL과 ELT이다.

ETL(Extract, Transform, Load)은 데이터를 소스에서 추출한 후, 변환을 거쳐 목적지에 적재하는 방식이다. 전통적인 데이터 웨어하우스 환경에서 주로 사용되며, 변환 과정에서 데이터의 품질을 보장할 수 있다는 장점이 있다. 반면 ELT(Extract, Load, Transform)는 원시 데이터를 먼저 목적지에 적재한 후, 필요에 따라 변환하는 방식이다. 클라우드 기반의 데이터 레이크 환경에서 유리한데, 저장 비용이 저렴해지면서 원시 데이터를 보존한 채 다양한 형태로 변환할 수 있기 때문이다.

ETL: 소스 → 추출 → 변환 → 적재 → 웨어하우스
ELT: 소스 → 추출 → 적재 → 데이터 레이크 → 변환 → 서빙

ML 파이프라인에서는 ELT 패턴이 더 자주 선택된다. 원시 데이터를 보존해두면 나중에 새로운 피처를 추가하거나 전처리 방식을 변경할 때 데이터를 다시 수집할 필요가 없기 때문이다.

피처 엔지니어링이 중요한 이유

피처 엔지니어링은 원시 데이터에서 모델이 학습할 수 있는 의미 있는 변수를 추출하거나 생성하는 과정이다. 동일한 데이터셋이라도 어떤 피처를 만들어내느냐에 따라 모델 성능이 크게 달라진다.

예를 들어 전자상거래의 구매 예측 모델을 만든다고 하자. 단순히 사용자의 방문 횟수만 피처로 사용하는 것과, 최근 7일간 방문 횟수, 평균 세션 시간, 장바구니 추가 후 구매까지의 평균 시간 등을 조합하여 피처로 사용하는 것은 결과에 큰 차이를 만든다. 후자의 피처들은 사용자의 구매 의도를 더 정확하게 반영하기 때문이다.

문제는 이러한 피처 엔지니어링이 일회성 작업이 아니라는 점이다. 데이터가 변하고, 비즈니스 요구사항이 바뀌고, 모델이 개선됨에 따라 피처도 지속적으로 갱신되어야 한다. 이 과정이 수작업으로 이루어지면 재현성이 떨어지고, 학습 환경과 서빙 환경에서 피처가 다르게 계산되는 학습-서빙 스큐(Training-Serving Skew) 문제가 발생하게 된다.

데이터 검증의 필요성

파이프라인이 자동화되면 데이터가 문제없이 흐를 것이라 기대하기 쉽다. 하지만 과연 그러한가? 실제로는 상류 시스템의 스키마가 예고 없이 변경되거나, 특정 필드에 null 값이 갑자기 증가하거나, 데이터의 분포가 과거와 완전히 달라지는 상황이 빈번하게 발생한다.

이러한 문제를 감지하지 못한 채 모델을 학습시키면 성능 저하의 원인을 파악하기 어려워진다. 모델의 문제인지 데이터의 문제인지 구분할 수 없게 되는 것이다. 따라서 파이프라인의 각 단계에서 데이터의 품질을 검증하는 과정이 필수적이다.

검증 항목은 스키마 검증(예상한 컬럼과 타입이 맞는지), 통계적 검증(값의 범위, 분포, 결측치 비율이 허용 범위 내인지), 비즈니스 규칙 검증(도메인 특화 규칙이 지켜지고 있는지) 등으로 나눌 수 있다.

주요 도구들

데이터 파이프라인과 피처 엔지니어링을 지원하는 도구들이 있다.

Apache Airflow는 파이프라인의 각 단계를 DAG(Directed Acyclic Graph)로 정의하여 실행 순서와 의존성을 관리한다. 특정 태스크가 실패했을 때 해당 단계부터 재실행할 수 있어 장애 복구가 용이하다.

dbt는 데이터 변환을 SQL로 정의하고, 이를 버전 관리할 수 있게 한다. 변환 로직에 대한 테스트를 작성할 수 있어, 변환 결과의 정확성을 보장하는 데 유용하다.

Great Expectations는 데이터에 대한 기대값을 선언적으로 정의하고, 파이프라인의 각 단계에서 자동으로 검증을 수행한다. 검증 결과를 문서화하여 데이터 품질의 이력을 추적할 수도 있다.

피처 스토어는 비교적 최근에 등장한 개념으로, 피처의 정의, 계산, 저장, 서빙을 중앙에서 관리하는 시스템이다. Feast와 같은 도구를 사용하면 학습 시와 서빙 시에 동일한 피처 계산 로직을 사용하게 되어 학습-서빙 스큐 문제를 근본적으로 해결할 수 있다.

데이터 품질이 곧 모델 품질이다

결국 MLOps에서 데이터 파이프라인은 단순히 데이터를 옮기는 배관이 아니다. 데이터의 품질을 보장하고, 피처를 체계적으로 관리하며, 문제 발생 시 빠르게 감지하고 대응할 수 있는 시스템을 구축하는 것이 핵심이다. 모델의 성능을 1% 올리기 위해 아키텍처를 변경하는 것보다, 데이터의 품질을 개선하는 것이 더 큰 효과를 가져오는 경우가 대부분이다.

다음 포스트에서는 모델 학습 과정을 체계적으로 관리하기 위한 실험 추적과 학습 관리를 살펴본다.