📂[Blog series] Airflow로 구축하는 NASA 배터리 파이프라인-1

2026. 1. 6. 16:36

제1편: 데이터 엔지니어링의 기초와 Airflow 도입 배경

NASA 배터리 데이터를 활용한 Airflow 파이프라인 구축기

데이터 분석가나 ML 엔지니어가 가장 많은 시간을 쏟는 곳은 역설적이게도 '모델링'이 아닌 '데이터 준비' 단계입니다. 저 또한 NASA의 배터리 충방전 데이터를 분석하며, 복잡한 시계열 데이터를 수동으로 전처리하는 과정에서 휴먼 에러와 비효율이라는 벽에 부딪혔습니다.

단순히 '한 번 돌아가는 코드'를 짜는 것은 어렵지 않습니다. 하지만 실제 운영 환경에서는 시스템이 멈추더라도 언제든 재실행 가능해야 하며, 데이터의 정합성이 깨지지 않아야 합니다. 이를 위해 저는 Airflow를 도입하여 전처리 과정을 자동화하고, 엔지니어링의 핵심 원칙인 '멱등성(Idempotency)'과 '트랜잭션(Transaction)'을 설계에 녹여냈습니다.

본 시리즈에서는 노션에 기록해 온 저의 기술 문서를 바탕으로, 안정적인 데이터 파이프라인을 구축하기 위한 저의 고민과 구현 과정을 상세히 공유하고자 합니다.

시작하며: NASA 배터리 데이터를 선택한 이유와 프로젝트의 목적

배터리 데이터셋을 선택한 이유는 다변량 시계열 이상 탐지에 적합하고, 국내 배터리 산업의 중요성 때문입니다. 최근 전기차 수요 둔화에도 불구하고 ESS(에너지 저장장치) 등 에너지 저장 시장이 가파르게 성장하고 있어 산업적 의의가 매우 큽니다.

실제 ESS나 전기차 관리 시스템에서는 수천 개의 배터리 셀 데이터가 매일 밤 혹은 주기적인 배치(Batch) 단위로 중앙 서버에 전송됩니다. 저는 이 방대한 시계열 데이터를 수동 작업 없이 안정적으로 처리하기 위해 워크플로우 오케스트레이션 도구인 Airflow를 도입했습니다. Airflow를 통해 복잡하게 얽힌 전처리 및 적재 과정을 하나의 유기적인 파이프라인으로 연결하고, 정해진 스케줄에 따라 작업을 자동화하여 운영 효율성을 극대화하고자 했습니다.

특히, 본 프로젝트에서 사용한 LOWESS 스무딩은 노이즈 제거에 탁월하지만 연산 복잡도가 높습니다. 대규모 데이터를 한 번에 처리할 경우 시스템 부하로 인한 실패 가능성이 존재하므로, 이를 Airflow 내에서 독립적인 Task로 분리하여 설계했습니다. 이를 통해 특정 단계에서 오류가 발생하더라도 전체 파이프라인을 멈추지 않고 실패한 부분만 자동으로 재시도하거나 해당 지점부터 복구할 수 있는 관리의 편의성과 파이프라인의 탄력성을 확보했습니다.

또한, 배터리 사이클별로 데이터 길이가 가변적이라는 특징은 데이터베이스 저장 시 스키마 설계의 유연성을 요구합니다. 고정된 테이블 구조에 이를 억지로 맞추려 하면 불필요한 NULL 값이 발생하고 저장 효율이 떨어지기 때문입니다. 이러한 가변적 데이터를 효율적으로 관리하기 위해 고성능 클라우드 데이터 웨어하우스인 Snowflake를 선택하여, 대용량 시계열 데이터를 압축 저장하고 전처리 전후의 데이터를 신속하게 쿼리할 수 있는 최적의 환경을 구축했습니다.

데이터 파이프라인이란?: 분석가와 엔지니어 사이의 가교 역할

데이터 분석가와 데이터 엔지니어

데이터 파이프라인 안에서 두 직무는 '데이터'라는 같은 재료를 다루지만, 그 목적과 과정에서 뚜렷한 차이가 있습니다.

데이터 엔지니어 (Data Engineer): 데이터의 길을 닦는 사람
- 핵심 역할: 산재한 Raw 데이터를 수집하여 분석 가능한 형태로 가공하고, 이를 안정적으로 저장소에 전달하는 인프라를 구축합니다.
- 주요 과업: ETL/ELT 파이프라인 구축, 데이터 품질 관리, 워크플로우 자동화.
- 사용 도구: Airflow, Snowflake, Spark, Kafka 등
데이터 분석가 (Data Analyst): 데이터에서 답을 찾는 사람
- 핵심 역할: 엔지니어가 닦아놓은 길(인프라)을 통해 들어온 데이터를 분석하여 비즈니스 의사결정에 필요한 인사이트를 도출합니다.
- 주요 과업: 지표 정의, 통계 및 머신러닝 분석, 대시보드 시각화.
- 사용 도구: Python, SQL, Tableau, PowerBI 등

현업에서는 분석가가 신뢰할 수 있는 데이터를 바탕으로 모델을 만들기 위해, 엔지니어의 안정적인 파이프라인 구축이 선행되어야 합니다. 저는 두 영역의 접점인 '데이터 파이프라인 자동화'를 이해하기 위해 Airflow를 학습하며, 엔지니어링적 안정성과 분석적 가치를 동시에 확보하는 것을 목표로 삼았습니다.

데이터 파이프라인

데이터 생성 → 수집 → 저장 → 가공 → 분석의 전체 과정을 하나의 흐름으로 정의하고 자동화하는 시스템입니다.

구체적으로 모델 개발과 운영을 연결하는 핵심 인프라입니다. 수동 작업 없이 새로운 데이터가 지속적으로 모델에 반영되어 예측 성능을 유지하고, 실시간 배포 환경에서 안정적인 서비스를 제공할 수 있습니다.

1. 데이터 생성 (Data Generation)

센서, 로그, 트랜잭션 등에서 원시 데이터 발생
본 프로젝트: NASA 배터리 충방전 사이클 데이터 (전압, 전류, 온도, 용량 등)

2. 데이터 수집 (Data Ingestion)

분산된 소스에서 데이터를 중앙화
본 프로젝트: Local CSV → S3 → Snowflake 적재 (Airflow DAG 1)
실무 시나리오: ESS/전기차의 수천 개 셀 데이터를 배치 단위로 전송

3. 데이터 저장 (Data Storage)

Raw 데이터와 가공 데이터를 구조화하여 보관
본 프로젝트: Snowflake 3-layer 구조 (Raw → Processed → Predictions)
가변 길이 시계열 데이터 효율적 압축 저장

4. 데이터 가공 (Data Transformation)

노이즈 제거, 특징 추출, 정규화 등 전처리
본 프로젝트: LOWESS 스무딩으로 노이즈 제거 + 통계적 특징 추출 (Airflow DAG 2)
Task 단위 분리로 고연산 작업의 독립적 실행 및 재시도 가능

5. 데이터 분석 (Data Analysis)

머신러닝 모델 학습 및 예측 수행
본 프로젝트: LOF + Anomaly Transformer 학습 → 이상 점수 산출 (Airflow DAG 3)
MLflow 실험 추적, Streamlit 대시보드 시각화

자동화의 핵심 가치

스케줄 기반 실행: 정해진 시간에 파이프라인 자동 트리거 (cron expression)
의존성 관리: 이전 단계 성공 시에만 다음 단계 실행
오류 복구: Task 실패 시 자동 재시도, 특정 지점부터 복구 가능
모니터링: 각 단계별 실행 상태 및 로그 추적

데이터 파이프라인 문서화

데이터 파이프라인 문서화는 데이터의 출처, 변환 과정, 저장 위치, 품질 규칙 등을 체계적으로 기록하는 작업입니다. 목적은 장애 대응, 변경 영향 분석, 신규 인력 온보딩, 재현 가능한 분석(데이터/실험)을 가능하게 하는 것입니다. 실무에서는 설계 문서 + 다이어그램(DAG, 데이터 흐름도) + 각 테이블/컬럼 메타데이터 + 운영/장애 기록(포스트모템) 정도가 한 세트가 됩니다.

데이터 카탈로그

정의: 조직 내 모든 데이터 자산의 메타데이터를 중앙에서 관리하는 시스템(무슨 데이터인지 설명하는 데이터 자산의 사전 역할)

포함 정보:

데이터셋 이름, 위치, 스키마
소유자, 생성일, 업데이트 주기
데이터 품질 지표
비즈니스 용어 설명
접근 권한 정보

# 데이터 카탈로그 메타데이터 예시
{
    "table_name": "customer_transactions",
    "location": "s3://bucket/data/transactions/",
    "schema": {
        "user_id": "INTEGER",
        "amount": "DECIMAL(10,2)",
        "timestamp": "TIMESTAMP"
    },
    "owner": "data_team@company.com",
    "update_frequency": "daily",
    "last_updated": "2024-12-15",
    "description": "고객 거래 내역 데이터"
}

데이터 리니지

데이터 리니지(lineage)는 데이터가 “원천 → 중간 산출물 → 최종 테이블/리포트”로 이동 및 변환되는 전체 경로와 의존성을 기록 및 시각화한 것입니다.

리니지가 있으면 다음이 쉬워집니다.

어느 소스가 장애 나면 어떤 다운스트림 테이블/리포트가 깨지는지 영향 분석
컬럼 하나 삭제/정의 변경 시 어디까지 영향을 주는지 확인
특정 지표가 “정확히 어떤 변환을 거쳤는지” 감사/설명(Explainability, Audit) 대응

※ 문서화–카탈로그–리니지 관계

데이터 파이프라인 문서화: 전체 프로세스(작업 단위, 스케줄, 장애 대응 포함)에 대한 서술 중심
데이터 카탈로그: “정지된 상태의 자산 목록”에 대한 정의와 설명 중심
데이터 리니지: 자산들 사이의 “그래프(흐름/의존성)” 중심

세 가지를 같이 사용하면 어떤 테이블이 무슨 의미인지(카탈로그), 어디서 어떻게 만들어졌는지(리니지), 파이프라인 입‧출력, 스케줄, 운영 방식이 무엇인지(문서화)를 한 번에 이어서 볼 수 있어서, 데이터 규모가 커질수록 필수에 가깝게 됩니다.

ETL과 ELT의 차이

ETL (Extract → Transform → Load) - 전통적 방식

데이터 추출 → 외부에서 변환 → DB 저장
장점: 변환 로직 집중 관리, 복잡한 Python/Spark 라이브러리 활용 가능, 민감 데이터 전처리 후 저장으로 보안 강화, DB 부하 감소
단점: 변환 서버의 처리 능력이 병목, 확장성 제한적

ELT (Extract → Load → Transform) - 현대적 방식

데이터 추출 → DB에 먼저 저장 → DB 내에서 변환
장점: 클라우드 DW의 강력한 컴퓨팅 파워 활용, SQL 기반 병렬 처리로 대용량 데이터 변환 빠름, 유지보수 용이, Raw 데이터 보존으로 재처리 유연
단점: DB 컴퓨팅 비용 발생, SQL로 구현 어려운 복잡한 변환 제한적

선택 기준

복잡한 변환 로직 + 외부 라이브러리 필요 (Python/Spark) → ETL
레거시 시스템 + 제한된 DB 성능 → ETL
단순 집계/조인 중심 + 클라우드 DW 활용 → ELT
데이터 크기 > 수십 GB + SQL 변환 가능 → ELT

본 프로젝트 적용: ETL 방식

CSV 추출 → S3 → Snowflake Raw 적재 (DAG 1)
Snowflake에서 추출 → Airflow/Python에서 LOWESS 전처리 → Snowflake Processed 적재 (DAG 2)
Snowflake에서 추출 → Python에서 모델 학습 → Snowflake Predictions 적재 (DAG 3)

ETL 선택 이유:

LOWESS 전처리: Python statsmodels 라이브러리 필수, Snowflake SQL로 구현 불가
복잡한 특징 추출: 통계 기반 Feature Engineering을 Python으로 모듈화
Task 독립성: Airflow에서 전처리를 별도 Task로 분리하여 실패 시 해당 단계만 재시도

배치 처리와 실시간 처리의 차이

배치 처리 (Batch Processing)

정의: 일정 주기(시간, 일, 주)에 따라 누적된 데이터를 한 번에 처리
특징:
- 구조 간단, 디버깅 용이, 유지보수 비용 낮음
- 높은 처리량(Throughput) - 대용량 데이터 효율적 처리
- 지연 발생 (Latency) - 분~시간 단위
- 실패 시 재처리 용이
기술 스택: Apache Airflow, Apache Spark, Cron
사용 케이스:
- 일별 매출 집계, 월간 리포트 생성
- 머신러닝 모델 학습 (historical data)
- 데이터 웨어하우스 ETL
- 예측 유지보수 (Predictive Maintenance)

실시간 처리 (Real-time/Stream Processing)

정의: 데이터 발생 즉시 처리하여 밀리초~초 단위 응답
특징:
- 실시간 의사결정 가능
- 낮은 지연 (Low Latency)
- 구조 복잡, 장애 대응 어려움, 운영 비용 높음
- 데이터 순서 보장, 중복 처리 등 고려사항 많음
기술 스택: Apache Kafka, Apache Flink, AWS Kinesis, Spark Streaming
사용 케이스:
- 이상 거래 탐지 (fraud detection)
- 실시간 추천 시스템
- IoT 센서 모니터링 알람
- 주식 트레이딩

본 프로젝트 적용: 배치 처리 가정

처리 방식: Airflow 스케줄 기반 배치 파이프라인
주기: 새 데이터 추가 시 또는 일정 주기로 실행
처리 흐름: CSV → S3 → Snowflake → LOWESS 전처리 → 모델 학습 → 예측 결과 저장

배치 처리 선택 이유:

도메인 특성: 배터리 열화는 수백~수천 사이클에 걸쳐 진행되는 점진적 현상, 즉각 대응 불필요
데이터 수집 패턴: ESS/전기차는 매일 밤 또는 주기적으로 배치 전송 (실시간 스트리밍 아님)
예측 유지보수: 사전 경고가 목적이므로 시간~일 단위 지연 허용
LOWESS 연산 복잡도: 고연산 전처리를 배치로 효율적 처리
운영 효율성: 단순한 파이프라인 구조로 소규모 팀 운영 가능

실무 시나리오

ESS 관리 시스템에서 수천 개 배터리 셀의 충방전 데이터를 매일 밤 12시에 수집 → Airflow가 자동으로 전처리 및 이상 탐지 수행 → 다음날 아침 관리자에게 열화 위험 배터리 리스트 제공. 실시간 모니터링 대비 인프라 비용 1/3, 유지보수 인력 50% 절감 가능.

'Data Engineering' 카테고리의 다른 글

yaml 파일이란? (1)	2026.01.13
📂[Blog series] Airflow로 구축하는 NASA 배터리 파이프라인-3.2 (0)	2026.01.08
📂[Blog series] Airflow로 구축하는 NASA 배터리 파이프라인-3.1 (1)	2026.01.08
📂[Blog series] Airflow로 구축하는 NASA 배터리 파이프라인-2 (0)	2026.01.08
[SQL] 기본 개념 정리 (0)	2025.09.01

Open Brain