Open Brain

yaml 파일이란?

월요일zoa — Tue, 13 Jan 2026 11:20:39 +0900

Docker Compose를 통해 Airflow 환경을 구축하다 보면 반드시 보게 되는 파일이 있습니다. 바로 .yaml 파일입니다. 프로젝트의 핵심 설정이 담기는 yaml 파일은 현대 개발 생태계에서 빼놓을 수 없는 요소입니다.

저도 부트캠프 최종 프로젝트에서 Airflow를 구축하며 처음으로 docker-compose.yaml 파일을 마주했습니다. 가이드에 따라 파일을 설치하고 실행하니 마법처럼 Airflow가 구동되었습니다. 하지만 문득 궁금해졌습니다. 이 파일 안에 가득한 지시어들은 정확히 어떤 의미일까? 왜 하필 .yaml 파일일까? 무심코 지나칠 수 있었던 YAML에 대해 제가 공부한 내용을 정리해 보았습니다.

이번 포스팅에서는 프로젝트 경험을 바탕으로 YAML의 정의부터 주요 특징, 그리고 왜 많은 도구들이 YAML을 설정 파일 형식으로 채택하는지를 심도 있게 다뤄보고자 합니다.

airflow의 docker-compose.yaml 파일 예시

airflow docker install

https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html

yaml이란

YAML은 원래 'Yet Another Markup Language(또 다른 마크업 언어)'의 약자였지만, 나중에는 'YAML Ain't Markup Language(YAML은 마크업 언어가 아니다)'라는 뜻으로 이름이 바뀌었습니다.

이걸 꼭 알아야 하냐고요? 아뇨. 하지만 전 꼭 말해드리고 싶었습니다. 어쨌든, YAML은 Docker Compose나 Kubernetes 같은 많은 유명한 도구들의 설정을 구성하는 데 사용됩니다.

그리고 괄호나 태그(acorn)를 사용해 형식을 맞추는 JSON, XML과는 달리, YAML은 '공백 들여쓰기'를 사용합니다.

# yaml(공백 중심)
user:
  name: "dong-ho"
  role: "ML engineer"
  skills:
    - Python
    - Docker
    
# json(괄호 중심)
{
  "user": {
    "name": "dong-ho",
    "role": "ML engineer",
    "skills": ["Python", "Docker"]
  }
}

# XML(태그 중심)
<user>
  <name>dong-ho</name>
  <role>ML engineer</role>
  <skills>
    <skill>Python</skill>
    <skill>skill>Docker</skill>
  </skills>
</user>

Scalars(data type)

Yaml에서 scalars는 단일 값을 나타내는 기본 단위이며, Yaml은 데이터 타입을 명시하지 않아도 알아서 판단하는 똑똑한 능력이 있습니다. Sclars의 종류는 총 5가지가 있습니다.

문자열(string): 텍스트 데이터. 따옴표 없이 표현 가능하며, 특수문자나 공백이 포함되면 따옴표 사용
숫자 (Number): 정수와 부동소수점. 8진수(0o), 16진수(0x), 지수 표기법 지원
불린 (Boolean): true/false, yes/no, on/off 등 여러 표현 가능
Null: 값이 없음을 나타냄. null, ~, 빈 값으로 표현
날짜/시간: ISO 8601 형식 지원

# Integer
positive: 34
zero: 0
negative: -12
hex: 0xDEADBEEF

# Boolean
# recommended boolean usage
is_gold: true
is_released: false
# legacy boolean usage(avoid)
is_gold: on
is_released: off

# Date
# YYYY-MM-DD
created: 2027-02-11
# YYYY-MM-DD HH:mm:ss
created: 2027-02-11 11:02:56

# Float
positive: 3.14
negative: -8.6
infinity: .inf
not-a-number: .nan

문자열(strings) 표현법

YAML 스칼라 중 가장 강력하고 복잡한 것이 문자열입니다. 따옴표를 쓰느냐 안 쓰느냐에 따라 의미가 달라집니다.

방식	예시	특징
Plain (따옴표 없음)	name: Gemini	가장 간결함. 특수문자가 포함되면 오류 가능성 있음.
Single Quotes ('' )	'Hello \n World'	있는 그대로 인식. \n을 줄바꿈으로 해석하지 않음.
Double Quotes (" ")	"Hello \n World"	이스케이프 시퀀스 해석. \n을 실제 줄바꿈으로 인식함.

여러 줄 스칼라

Docker Compose나 Airflow 설정을 하다 보면 긴 스크립트를 써야 할 때가 있습니다. 이때 사용하는 두 가지 기호가 핵심입니다.

1. 리터럴 스타일 (|): 줄바꿈을 포함하여 작성한 모양 그대로를 저장합니다.

description: |
  첫 번째 줄입니다.
  두 번째 줄입니다.
  (줄바꿈이 유지됩니다.)

2. 폴디드 스타일 (>): 작성할 때는 여러 줄이지만, 실제 데이터로 읽을 때는 중간의 줄바꿈을 공백 하나로 바꿉니다. (문단 끝의 줄바꿈만 유지)

summary: >
  이 내용은 여러 줄로
  작성되었지만 실제로는
  한 줄의 문장으로 읽힙니다.

Mapping(object)

YAML에서 데이터를 구조화하는 가장 기본적인 단위는 매핑(Mapping)입니다. 우리가 흔히 프로그래밍에서 말하는 '객체'와 같은 개념입니다. 재미있는 점은 YAML이 '공백'에 매우 민감하다는 것입니다. 단순히 글자를 적는 게 아니라, 콜론 뒤에 한 칸을 띄우고 아래 줄에서 들여쓰기를 하는 그 '빈 공간'이 데이터 간의 부모-자식 관계를 결정합니다.

Airflow 설정 파일에서 services: 아래에 airflow-webserver: 같은 항목이 들어가는 것도 바로 매핑 원리를 이용한 것입니다.

# Yaml
info:
    lang: python
    version: 3.14.1
    type: open-source

# json
{
    "info": {
    	"lang": "python"
        "version": "3.14.1"
        "type": "open-source"
    }
}

Sequence(List)

Yaml에서 배열을 생성하기 위해서는 dash나 공백을 사용합니다. 배열은 파이썬에서 사용하는 그것과 같은 개념으로 순서가 존재합니다.

1. 블록 스타일: 가장 일반적입니다. dash 뒤에 반드시 공백이 있어야 합니다. 공백을 사용하지 않으면 문자열로 인식됩니다.

# block style
language:
    - python
    - java
    - go

2. 괄호 스타일: json과 유사하게 괄호를 사용하는 방식입니다.

# flow style
language: [python, java, go]

Sequence와 Mapping의 조합

실제 docker compose나 airflow 설정에서는 '객체들을 담은 리스트' 형태를 가장 많이 마주합니다.

employee
    - name: jnb
      role: designer
    - name: kxn
      role: pm

employee라는 객체 안에 두 개의 sequence가 들어가 있는 형태입니다. 각 dash는 새로운 시작점입니다. 이때도 마찬가지로 dash 후에 꼭 공백을 작성해야 합니다!

docker-compose.yaml 파일 분석

version: '3.8'  # [스칼라] 키-값 쌍의 버전 정보

services:        # [매핑] 서비스들을 담는 최상위 객체
  airflow-webserver:  # [매핑] 웹서버 서비스 정의
    image: apache/airflow:2.7.1  # [스칼라] 이미지 이름
    restart: always              # [스칼라] 재시작 정책
    
    volumes:      # [리스트] 여러 경로를 연결하기 위한 목록
      - ./dags:/opt/airflow/dags      # [리스트 항목 1]
      - ./logs:/opt/airflow/logs      # [리스트 항목 2]
      - ./plugins:/opt/airflow/plugins # [리스트 항목 3]

    environment:  # [매핑] 환경 변수 설정 객체
      _PIP_ADDITIONAL_DEPENDENCIES: "pandas numpy" # [스칼라]

구조적 계층: services라는 큰 바구니(매핑) 안에 airflow-webserver라는 작은 바구니가 있고, 그 안에 다시 이미지 이름(스칼라)과 볼륨 목록(리스트)이 담겨 있습니다.
들여쓰기의 마법: 별도의 괄호가 없어도 들여쓰기만으로 volumes가 airflow-webserver에 속한 설정이라는 것을 명확히 알 수 있습니다.

Airflow가 yaml 파일을 사용하는 이유

Airflow에서 docker compose를 위해서 yaml을 사용하는 이유는 명확한 기술적 이점이 있기 때문입니다.

① 개발자를 배려하는 '가독성'

Docker Compose나 Airflow의 설정은 인프라 구조를 정의합니다. JSON처럼 { }와 ,가 가득하면 눈이 피로하고 구조를 한눈에 파악하기 어렵지만, YAML은 문서처럼 읽히기 때문에 복잡한 컨테이너 간의 관계를 파악하는 데 최적입니다.

② 주석(#)의 존재 (가장 큰 이유 중 하나)

JSON은 공식적으로 주석을 지원하지 않습니다. 하지만 인프라 설정 파일에는 "이 포트를 왜 열었는지", "이 볼륨은 왜 연결했는지" 기록하는 것이 필수적입니다. YAML은 #을 통해 상세한 설명을 남길 수 있어 협업과 유지보수에 유리합니다.

③ 유연한 데이터 표현

Airflow는 DAG(작업 흐름)를 정의할 때 환경 변수나 의존성을 복잡하게 설정해야 합니다. YAML은 문자열을 여러 줄로 쓰거나(|), 복잡한 리스트 안에 객체를 넣는 작업을 기호의 방해 없이 깔끔하게 처리할 수 있게 해줍니다.

④ 인프라 업계의 표준 (Infrastructure as Code)

Kubernetes, Docker 등 현대 인프라 도구들은 모두 YAML을 기본으로 채택하고 있습니다. 따라서 Airflow 환경을 구축할 때 YAML을 사용하는 것은 다른 도구들과의 호환성 및 생태계 통합 면에서 매우 유리한 선택입니다.

결국 YAML이 Docker와 Airflow에서 사랑받는 이유는 컴퓨터도 잘 알아듣지만, 사람에게 가장 친절한 언어이기 때문입니다. 부트캠프 프로젝트를 진행하며 무심코 복사했던 그 코드들 속에 들여쓰기와 콜론 하나하나가 인프라의 뼈대를 구성하는 정교한 설계도였다는 것을 이해하니 설정 파일이 더 이상 어렵게 느껴지지 않았습니다.

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

월요일zoa — Thu, 8 Jan 2026 15:44:39 +0900

3.1에서 이어지는 ML/DL 후속 Airflow dag 설명 글입니다.

DAG 코드 주요 로직 및 엔지니어링 포인트 분석

Dag 3: LOF build and experiment

3번째 DAG는 가공된 데이터를 바탕으로 LOF(Local Outlier Factor) 모델을 학습시키고, 최적의 임계치(Threshold)를 설정하여 결과를 저장하는 MLOps의 핵심 워크플로우를 수행합니다.

from airflow.decorators import dag, task
from airflow.providers.snowflake.hooks.snowflake import SnowflakeHook
from airflow.providers.amazon.aws.hooks.s3 import S3Hook
from datetime import datetime
import os
import json
import pandas as pd
import numpy as np

from sklearn.preprocessing import StandardScaler
from sklearn.neighbors import LocalOutlierFactor
import joblib


# ----------------------------
# Config (battery_dag_02_load.py 패턴 준수)
# ----------------------------
AWS_CONN_ID = "aws_conn"
SNOWFLAKE_CONN_ID = "snowflake_conn"

S3_BUCKET = "bucket"
S3_PREFIX = "battery/ml_lof/"  # ML 결과 저장 prefix

BATTERY_ID = "B0005"

SNOWFLAKE_DB = "BATTERY_DATABASE"
SNOWFLAKE_SCHEMA = "RAW_DATA"

# battery_dag_02_load.py가 생성/적재하는 LOWESS 결과 테이블
LOWESS_TABLE = f"BATTERY_{BATTERY_ID}_LOWESS"  # BATTERY_B0005_LOWESS

# ML 결과 적재 테이블
RESULT_TABLE = f"BATTERY_{BATTERY_ID}_LOF_RESULTS"  # BATTERY_B0005_LOF_RESULTS

SNOWFLAKE_INTERNAL_STAGE_PATH = "@~/battery_upload"

# b0005.ipynb에서 사용한 피처 구성(원본 + lowess 파생)
FEATURE_COLS = [
    "Voltage_measured", "Current_measured", "Temperature_measured",
    "Current_load", "Voltage_load",
    "Voltage_measured_smooth", "Voltage_measured_residual", "Voltage_measured_trend",
    "Current_measured_smooth", "Current_measured_residual", "Current_measured_trend",
    "Temperature_measured_smooth", "Temperature_measured_residual", "Temperature_measured_trend",
    "Current_load_smooth", "Current_load_residual", "Current_load_trend",
    "Voltage_load_smooth", "Voltage_load_residual", "Voltage_load_trend",
]

# quantile 후보(Validation 기준)
THRESHOLD_QUANTILES = [0.99, 0.995, 0.999]
DEFAULT_THRESHOLD_Q = 0.995

# LOF 하이퍼파라미터(노트북 기본 흐름 반영)
LOF_N_NEIGHBORS = 30


def _safe_float_df(df: pd.DataFrame, cols: list[str]) -> pd.DataFrame:
    """문자/NULL 혼입 방어: 숫자 변환 불가값은 NaN 처리 후 drop."""
    out = df.copy()
    for c in cols:
        out[c] = pd.to_numeric(out[c], errors="coerce")
    return out

# =========================================================
# 공통 유틸 (Snowflake 대문자 문제 완전 차단)
# =========================================================
def snowflake_select_expr(cols: list[str]) -> str:
    """
    Snowflake 실제 컬럼은 대문자,
    pandas 컬럼은 원래 이름 유지
    """
    return ",\n    ".join([f"{c.upper()} AS {c}" for c in cols])


@dag(
    dag_id="battery_dag_03_ml_lof",
    start_date=datetime(2024, 12, 1),
    schedule=None,
    catchup=False,
    tags=["battery", "ml", "lof", "anomaly", "lowess"],
)
def battery_ml_lof_pipeline():
    @task
    def extract_lowess_from_snowflake() -> str:
        hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)

        sql = f"""
            SELECT
                CYCLE_IDX,
                VOLTAGE_MEASURED,
                CURRENT_MEASURED,
                TEMPERATURE_MEASURED,
                CURRENT_LOAD,
                VOLTAGE_LOAD,
                VOLTAGE_MEASURED_SMOOTH,
                VOLTAGE_MEASURED_RESIDUAL,
                VOLTAGE_MEASURED_TREND,
                CURRENT_MEASURED_SMOOTH,
                CURRENT_MEASURED_RESIDUAL,
                CURRENT_MEASURED_TREND,
                TEMPERATURE_MEASURED_SMOOTH,
                TEMPERATURE_MEASURED_RESIDUAL,
                TEMPERATURE_MEASURED_TREND,
                CURRENT_LOAD_SMOOTH,
                CURRENT_LOAD_RESIDUAL,
                CURRENT_LOAD_TREND,
                VOLTAGE_LOAD_SMOOTH,
                VOLTAGE_LOAD_RESIDUAL,
                VOLTAGE_LOAD_TREND
            FROM {SNOWFLAKE_DB}.{SNOWFLAKE_SCHEMA}.{LOWESS_TABLE}
            ORDER BY CYCLE_IDX
        """

        df = hook.get_pandas_df(sql)

        # 디버깅
        print("[DEBUG raw Snowflake columns]:", df.columns.tolist())

        rename_map = {
            "CYCLE_IDX": "cycle_idx",
            "VOLTAGE_MEASURED": "Voltage_measured",
            "CURRENT_MEASURED": "Current_measured",
            "TEMPERATURE_MEASURED": "Temperature_measured",
            "CURRENT_LOAD": "Current_load",
            "VOLTAGE_LOAD": "Voltage_load",
            "VOLTAGE_MEASURED_SMOOTH": "Voltage_measured_smooth",
            "VOLTAGE_MEASURED_RESIDUAL": "Voltage_measured_residual",
            "VOLTAGE_MEASURED_TREND": "Voltage_measured_trend",
            "CURRENT_MEASURED_SMOOTH": "Current_measured_smooth",
            "CURRENT_MEASURED_RESIDUAL": "Current_measured_residual",
            "CURRENT_MEASURED_TREND": "Current_measured_trend",
            "TEMPERATURE_MEASURED_SMOOTH": "Temperature_measured_smooth",
            "TEMPERATURE_MEASURED_RESIDUAL": "Temperature_measured_residual",
            "TEMPERATURE_MEASURED_TREND": "Temperature_measured_trend",
            "CURRENT_LOAD_SMOOTH": "Current_load_smooth",
            "CURRENT_LOAD_RESIDUAL": "Current_load_residual",
            "CURRENT_LOAD_TREND": "Current_load_trend",
            "VOLTAGE_LOAD_SMOOTH": "Voltage_load_smooth",
            "VOLTAGE_LOAD_RESIDUAL": "Voltage_load_residual",
            "VOLTAGE_LOAD_TREND": "Voltage_load_trend",
        }

        df = df.rename(columns=rename_map)

        # 방어 로직
        if "cycle_idx" not in df.columns:
            raise ValueError(f"cycle_idx missing after rename. columns={df.columns.tolist()}")

        out_path = f"/tmp/{BATTERY_ID}_lowess_ml_input.csv"
        df.to_csv(out_path, index=False)

        print(f"[OK] Extracted LOWESS for ML: rows={len(df)}")
        return out_path
    @task
    def validate_ml_data(file_path: str) -> str:
        """
        ML 입력 검증:
        - cycle_idx 존재
        - feature 컬럼 존재
        - 결측/비수치 방어(필요시 drop)
        """
        df = pd.read_csv(file_path)

        assert len(df) > 0, "Empty dataframe"
        assert "cycle_idx" in df.columns, "cycle_idx missing"

        missing = [c for c in FEATURE_COLS if c not in df.columns]
        assert len(missing) == 0, f"Missing feature cols: {missing}"

        # 숫자 변환(에러는 NaN) 후 결측 drop
        df = _safe_float_df(df, FEATURE_COLS)
        before = len(df)
        df = df.dropna(subset=["cycle_idx"] + FEATURE_COLS).copy()
        after = len(df)

        assert after > 0, "All rows dropped after numeric coercion / NaN removal"

        # cycle_idx는 int로 캐스팅
        df["cycle_idx"] = pd.to_numeric(df["cycle_idx"], errors="coerce").astype(int)

        clean_path = f"/tmp/{BATTERY_ID}_lowess_for_ml_clean.csv"
        df.to_csv(clean_path, index=False)

        print(f"✓ Validation passed: before={before}, after={after}, saved={clean_path}")
        return clean_path

    @task
    def train_score_lof(clean_path: str) -> str:
        """
        cycle 기반 6:2:2 split
        - scaler fit(train)
        - LOF fit(train, novelty=True)
        - train/val/test score 산출
        결과(행 단위) 저장 후 path 반환
        """
        df = pd.read_csv(clean_path)
        df["cycle_idx"] = df["cycle_idx"].astype(int)

        cycle_list = sorted(df["cycle_idx"].unique().tolist())
        total_cycles = len(cycle_list)
        assert total_cycles >= 10, f"Too few cycles for split: total_cycles={total_cycles}"

        train_cycles = int(total_cycles * 0.6)
        val_cycles = int(total_cycles * 0.8)  # train+val

        train_threshold_cycle = cycle_list[train_cycles - 1]
        val_threshold_cycle = cycle_list[val_cycles - 1]

        train_df = df[df["cycle_idx"] <= train_threshold_cycle].copy()
        val_df = df[(df["cycle_idx"] > train_threshold_cycle) & (df["cycle_idx"] <= val_threshold_cycle)].copy()
        test_df = df[df["cycle_idx"] > val_threshold_cycle].copy()

        print(f"총 Cycle 수: {total_cycles}")
        print(f"Train: <= {train_threshold_cycle} (cycles={train_cycles}) rows={len(train_df)}")
        print(f"Val:   ({train_threshold_cycle}, {val_threshold_cycle}] rows={len(val_df)}")
        print(f"Test:  >  {val_threshold_cycle} rows={len(test_df)}")

        # Feature matrix
        X_train = train_df[FEATURE_COLS].values
        X_val = val_df[FEATURE_COLS].values
        X_test = test_df[FEATURE_COLS].values

        scaler = StandardScaler()
        X_train_scaled = scaler.fit_transform(X_train)
        X_val_scaled = scaler.transform(X_val)
        X_test_scaled = scaler.transform(X_test)

        lof = LocalOutlierFactor(
            n_neighbors=LOF_N_NEIGHBORS,
            contamination="auto",
            novelty=True,
        )
        lof.fit(X_train_scaled)

        # 점수: 클수록 이상(outlier)으로 해석하기 위해 음수부호 처리 흐름을 유지
        train_scores = -lof.negative_outlier_factor_
        val_scores = -lof.score_samples(X_val_scaled)
        test_scores = -lof.score_samples(X_test_scaled)

        # 결과 DF (행 단위)
        train_out = train_df[["cycle_idx"]].copy()
        train_out["split"] = "train"
        train_out["score"] = train_scores

        val_out = val_df[["cycle_idx"]].copy()
        val_out["split"] = "val"
        val_out["score"] = val_scores

        test_out = test_df[["cycle_idx"]].copy()
        test_out["split"] = "test"
        test_out["score"] = test_scores

        scored = pd.concat([train_out, val_out, test_out], axis=0, ignore_index=True)

        # 아티팩트 저장
        model_dir = f"/tmp/{BATTERY_ID}_lof_artifacts"
        os.makedirs(model_dir, exist_ok=True)

        joblib.dump(scaler, os.path.join(model_dir, "scaler.joblib"))
        joblib.dump(lof, os.path.join(model_dir, "lof.joblib"))

        scored_path = os.path.join(model_dir, f"{BATTERY_ID}_scored_rows.csv")
        scored.to_csv(scored_path, index=False)

        meta = {
            "battery_id": BATTERY_ID,
            "total_cycles": total_cycles,
            "train_threshold_cycle": int(train_threshold_cycle),
            "val_threshold_cycle": int(val_threshold_cycle),
            "feature_cols": FEATURE_COLS,
            "lof_n_neighbors": LOF_N_NEIGHBORS,
        }
        with open(os.path.join(model_dir, "run_meta.json"), "w", encoding="utf-8") as f:
            json.dump(meta, f, ensure_ascii=False, indent=2)

        print(f"✓ LOF trained & scored. artifacts_dir={model_dir}")
        print(f"✓ scored_rows={scored_path}, rows={len(scored)}")
        return model_dir

    @task
    def select_threshold(artifacts_dir: str) -> str:
        """
        Validation split의 score 분포를 기준으로 quantile threshold 비교 후 선택.
        선택된 threshold/quantile을 meta에 기록.
        """
        scored_path = os.path.join(artifacts_dir, f"{BATTERY_ID}_scored_rows.csv")
        scored = pd.read_csv(scored_path)

        val_scores = scored.loc[scored["split"] == "val", "score"].dropna().astype(float).values
        assert len(val_scores) > 0, "No validation scores found"

        results = []
        for q in THRESHOLD_QUANTILES:
            thr = float(np.quantile(val_scores, q))
            # val에서 q-quantile이면 대략 (1-q) 비율이 이상으로 잡힘
            val_anom_rate = float((val_scores >= thr).mean())
            results.append({"quantile": q, "threshold": thr, "val_anom_rate": val_anom_rate})

        # 기본: DEFAULT_THRESHOLD_Q, 없으면 중앙값에 가까운 후보 선택
        chosen = next((r for r in results if abs(r["quantile"] - DEFAULT_THRESHOLD_Q) < 1e-12), results[0])

        print("=== Threshold candidates (validation) ===")
        for r in results:
            print(f"q={r['quantile']:.3f} thr={r['threshold']:.6f} val_anom_rate={r['val_anom_rate']:.4f}")

        print(f"✓ Chosen threshold: q={chosen['quantile']:.3f}, thr={chosen['threshold']:.6f}")

        # meta 업데이트
        meta_path = os.path.join(artifacts_dir, "run_meta.json")
        with open(meta_path, "r", encoding="utf-8") as f:
            meta = json.load(f)

        meta["threshold_quantile"] = chosen["quantile"]
        meta["threshold_value"] = chosen["threshold"]
        meta["threshold_candidates"] = results

        with open(meta_path, "w", encoding="utf-8") as f:
            json.dump(meta, f, ensure_ascii=False, indent=2)

        return artifacts_dir

    @task
    def persist_outputs(artifacts_dir: str):
        """
        1) S3 업로드: scaler/lof/meta/scored_rows
        2) Snowflake 적재: BATTERY_B0005_LOF_RESULTS (행 단위 결과)
        """
        run_ts = datetime.utcnow().strftime("%Y%m%d_%H%M%S")
        s3_hook = S3Hook(aws_conn_id=AWS_CONN_ID)
        sf_hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)

        # --- S3 upload ---
        files_to_upload = [
            os.path.join(artifacts_dir, "scaler.joblib"),
            os.path.join(artifacts_dir, "lof.joblib"),
            os.path.join(artifacts_dir, "run_meta.json"),
            os.path.join(artifacts_dir, f"{BATTERY_ID}_scored_rows.csv"),
        ]

        for fp in files_to_upload:
            key = f"{S3_PREFIX}{BATTERY_ID}/{run_ts}/{os.path.basename(fp)}"
            s3_hook.load_file(filename=fp, key=key, bucket_name=S3_BUCKET, replace=True)
            print(f"✓ Uploaded: s3://{S3_BUCKET}/{key}")

        # --- Snowflake load (COPY via PUT) ---
        scored_path = os.path.join(artifacts_dir, f"{BATTERY_ID}_scored_rows.csv")

        conn = sf_hook.get_conn()
        cur = conn.cursor()
        try:
            cur.execute(f"USE DATABASE {SNOWFLAKE_DB};")
            cur.execute(f"USE SCHEMA {SNOWFLAKE_SCHEMA};")

            # 결과 테이블 생성
            cur.execute(f"""
                CREATE TABLE IF NOT EXISTS {RESULT_TABLE} (
                    cycle_idx INT,
                    split STRING,
                    score FLOAT,
                    run_ts STRING
                );
            """)

            # 로컬 CSV에 run_ts 컬럼을 추가한 임시 파일 생성
            df = pd.read_csv(scored_path)
            df["run_ts"] = run_ts
            tmp_path = f"/tmp/{BATTERY_ID}_scored_rows_with_runts.csv"
            df.to_csv(tmp_path, index=False)

            # temp table
            cur.execute(f"CREATE TEMP TABLE temp_lof_results LIKE {RESULT_TABLE};")

            abs_path = os.path.abspath(tmp_path)
            filename = os.path.basename(abs_path)

            cur.execute(
                f"PUT 'file://{abs_path}' {SNOWFLAKE_INTERNAL_STAGE_PATH} auto_compress=false overwrite=true;"
            )

            cur.execute(f"""
                COPY INTO temp_lof_results
                FROM {SNOWFLAKE_INTERNAL_STAGE_PATH}/{filename}
                FILE_FORMAT = (TYPE = 'CSV' SKIP_HEADER = 1 FIELD_OPTIONALLY_ENCLOSED_BY='"')
                ON_ERROR = 'ABORT_STATEMENT';
            """)

            # (정책 선택) append 적재: run_ts로 구분하여 누적
            cur.execute(f"INSERT INTO {RESULT_TABLE} SELECT * FROM temp_lof_results;")

            cnt = cur.execute(f"SELECT COUNT(*) FROM {RESULT_TABLE} WHERE run_ts='{run_ts}';").fetchone()[0]
            print(f"✓ Inserted into {RESULT_TABLE}: run_ts={run_ts}, rows={cnt}")

        finally:
            cur.close()
            conn.close()

    # Dependency
    extracted = extract_lowess_from_snowflake()
    cleaned = validate_ml_data(extracted)
    artifacts = train_score_lof(cleaned)
    artifacts2 = select_threshold(artifacts)
    persist_outputs(artifacts2)


battery_ml_lof_pipeline()

1. 머신러닝을 위한 데이터 무결성 가드레일 (validate_ml_data)

로직: _safe_float_df 유틸리티를 통해 수치형 변환이 불가능한 데이터를 강제로 NaN 처리하고 dropna로 제거합니다.
엔지니어링 의도: ML 모델은 데이터에 문자열이나 결측치가 섞여 있을 때 치명적인 오류를 냅니다. 파이프라인 중간에 'ML-Ready' 상태를 보장하는 검증 단계를 두어 모델 학습의 안정성을 확보했습니다.

2. 시계열 특성을 고려한 시간순 데이터 분할 (Chronological Split)

로직: 일반적인 랜덤 샘플링(train_test_split) 대신, cycle_idx를 기준으로 데이터를 정렬한 뒤 6:2:2 비율로 순차 분할합니다.
엔지니어링 의도: 배터리 데이터는 시간(Cycle)에 따라 상태가 변하는 시계열 데이터입니다. 미래의 데이터가 과거의 학습에 포함되는 데이터 누수(Data Leakage)를 방지하기 위해 철저히 시간 흐름에 따른 검증 전략을 채택했습니다.

3. 통계 기반의 동적 임계치(Threshold) 선정 기법

로직: select_threshold 태스크에서 Validation 세트의 이상 점수(Anomaly Score) 분포를 분석하고, 상위 0.995 분위수(Quantile)를 기준으로 임계치를 동적으로 결정합니다.
엔지니어링 의도: "어디서부터 이상치인가?"라는 질문에 하드코딩된 숫자로 답하지 않고, 데이터의 통계적 분포에 근거한 유연한 의사결정 로직을 파이프라인에 통합했습니다.

4. 모델 아티팩트 및 메타데이터 관리

로직: 학습된 scaler와 lof 모델 객체를 joblib으로 저장함과 동시에, 학습에 사용된 피처 목록과 파라미터를 run_meta.json이라는 메타데이터 파일로 기록합니다.
엔지니어링 의도: 나중에 모델 성능이 변했을 때 "어떤 피처로, 어떤 설정으로 학습했는가?"를 즉시 추적할 수 있도록 실험 관리(Experiment Tracking)의 기초를 설계했습니다.

5. 버전 관리를 포함한 하이브리드 저장 전략

로직: 모델 파일과 메타데이터는 AWS S3에 보존하고, 행 단위의 이상 탐지 결과는 run_ts(실행 타임스탬프)와 함께 Snowflake에 누적 적재합니다.
엔지니어링 의도: 대용량 바이너리 파일(모델)과 구조화된 쿼리가 필요한 데이터(결과값)를 각각 최적의 저장소에 배치했습니다.

Dag 3: LOF build and experiment

마지막 DAG는 최신 딥러닝 모델인 Anomaly Transformer를 활용하여 배터리의 미세한 열화 징후를 탐지합니다.

from airflow.decorators import dag, task
from airflow.providers.snowflake.hooks.snowflake import SnowflakeHook
from airflow.providers.amazon.aws.hooks.s3 import S3Hook
from datetime import datetime
import os
import json
import pandas as pd
import numpy as np
import mlflow
import sys

# Anomaly Transformer 모델 import
anomaly_transformer_path = '/opt/airflow/plugins/Anomaly-Transformer'
sys.path.insert(0, anomaly_transformer_path)
sys.path.insert(0, os.path.join(anomaly_transformer_path, 'model'))
sys.path.insert(0, os.path.join(anomaly_transformer_path, 'data_factory'))
sys.path.insert(0, os.path.join(anomaly_transformer_path, 'utils'))

from solver import Solver

# ----------------------------
# Config
# ----------------------------
AWS_CONN_ID = "aws_conn"
SNOWFLAKE_CONN_ID = "snowflake_conn"

S3_BUCKET = "bucket"
S3_PREFIX = "battery/anomaly_transformer/"

BATTERY_ID = "B0005"

SNOWFLAKE_DB = "BATTERY_DATABASE"
SNOWFLAKE_SCHEMA_RAW = "RAW_DATA"
SNOWFLAKE_SCHEMA_ANALYTICS = "ANALYTICS"

# LOWESS 결과 테이블 (RAW_DATA 스키마)
LOWESS_TABLE = f"BATTERY_{BATTERY_ID}_LOWESS"

# Anomaly Transformer 결과 테이블 (ANALYTICS 스키마)
RESULT_TABLE = f"BATTERY_{BATTERY_ID}_AT_RESULTS"

SNOWFLAKE_INTERNAL_STAGE_PATH = "@~/battery_upload"

# Feature columns
FEATURE_COLS = [
    "Voltage_measured", "Current_measured", "Temperature_measured",
    "Current_load", "Voltage_load",
    "Voltage_measured_smooth", "Voltage_measured_residual", "Voltage_measured_trend",
    "Current_measured_smooth", "Current_measured_residual", "Current_measured_trend",
    "Temperature_measured_smooth", "Temperature_measured_residual", "Temperature_measured_trend",
    "Current_load_smooth", "Current_load_residual", "Current_load_trend",
    "Voltage_load_smooth", "Voltage_load_residual", "Voltage_load_trend",
]

# Anomaly Transformer hyperparameters
# main.py 파라미터 기준
AT_PARAMS = {
       "lr": 1e-4,
       "num_epochs": 10,  # epochs → num_epochs
       "k": 3,
       "win_size": 100,
       "input_c": len(FEATURE_COLS),  # 20
       "output_c": len(FEATURE_COLS),  # 20
       "batch_size": 32,
       "stride": 1,
       "dataset": "nasa_battery",
       "anormly_ratio": 1.00,
       "split_mode": "two",  # train/test 8:2
   }

# MLflow
MLFLOW_TRACKING_URI = "http://mlflow:5000"
MLFLOW_EXPERIMENT_NAME = "battery_anomaly_transformer"

@dag(
    dag_id="battery_dag_04_ml_transformer",
    start_date=datetime(2024, 12, 1),
    schedule=None,
    catchup=False,
    tags=["battery", "ml", "anomaly_transformer", "deep_learning", "lowess"],
)

def battery_ml_transformer_pipeline():

    @task
    def extract_lowess_from_snowflake() -> str:
        """Snowflake에서 LOWESS 전처리된 데이터 추출"""
        hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)

        sql = f"""
            SELECT
                CYCLE_IDX,
                VOLTAGE_MEASURED,
                CURRENT_MEASURED,
                TEMPERATURE_MEASURED,
                CURRENT_LOAD,
                VOLTAGE_LOAD,
                VOLTAGE_MEASURED_SMOOTH,
                VOLTAGE_MEASURED_RESIDUAL,
                VOLTAGE_MEASURED_TREND,
                CURRENT_MEASURED_SMOOTH,
                CURRENT_MEASURED_RESIDUAL,
                CURRENT_MEASURED_TREND,
                TEMPERATURE_MEASURED_SMOOTH,
                TEMPERATURE_MEASURED_RESIDUAL,
                TEMPERATURE_MEASURED_TREND,
                CURRENT_LOAD_SMOOTH,
                CURRENT_LOAD_RESIDUAL,
                CURRENT_LOAD_TREND,
                VOLTAGE_LOAD_SMOOTH,
                VOLTAGE_LOAD_RESIDUAL,
                VOLTAGE_LOAD_TREND
            FROM {SNOWFLAKE_DB}.{SNOWFLAKE_SCHEMA_RAW}.{LOWESS_TABLE}
            ORDER BY CYCLE_IDX
        """

        df = hook.get_pandas_df(sql)
        print("[DEBUG raw Snowflake columns]:", df.columns.tolist())

        rename_map = {
            "CYCLE_IDX": "cycle_idx",
            "VOLTAGE_MEASURED": "Voltage_measured",
            "CURRENT_MEASURED": "Current_measured",
            "TEMPERATURE_MEASURED": "Temperature_measured",
            "CURRENT_LOAD": "Current_load",
            "VOLTAGE_LOAD": "Voltage_load",
            "VOLTAGE_MEASURED_SMOOTH": "Voltage_measured_smooth",
            "VOLTAGE_MEASURED_RESIDUAL": "Voltage_measured_residual",
            "VOLTAGE_MEASURED_TREND": "Voltage_measured_trend",
            "CURRENT_MEASURED_SMOOTH": "Current_measured_smooth",
            "CURRENT_MEASURED_RESIDUAL": "Current_measured_residual",
            "CURRENT_MEASURED_TREND": "Current_measured_trend",
            "TEMPERATURE_MEASURED_SMOOTH": "Temperature_measured_smooth",
            "TEMPERATURE_MEASURED_RESIDUAL": "Temperature_measured_residual",
            "TEMPERATURE_MEASURED_TREND": "Temperature_measured_trend",
            "CURRENT_LOAD_SMOOTH": "Current_load_smooth",
            "CURRENT_LOAD_RESIDUAL": "Current_load_residual",
            "CURRENT_LOAD_TREND": "Current_load_trend",
            "VOLTAGE_LOAD_SMOOTH": "Voltage_load_smooth",
            "VOLTAGE_LOAD_RESIDUAL": "Voltage_load_residual",
            "VOLTAGE_LOAD_TREND": "Voltage_load_trend",
        }

        df = df.rename(columns=rename_map)

        if "cycle_idx" not in df.columns:
            raise ValueError(f"cycle_idx missing after rename. columns={df.columns.tolist()}")

        out_path = f"/tmp/{BATTERY_ID}_lowess_transformer_input.csv"
        df.to_csv(out_path, index=False)

        print(f"[OK] Extracted LOWESS for Anomaly Transformer: rows={len(df)}")
        return out_path

    @task
    def validate_ml_data(file_path: str) -> str:
        """AT 입력 검증"""
        df = pd.read_csv(file_path)

        assert len(df) > 0, "Empty dataframe"
        assert "cycle_idx" in df.columns, "cycle_idx missing"

        missing = [c for c in FEATURE_COLS if c not in df.columns]
        assert len(missing) == 0, f"Missing feature cols: {missing}"

        # 숫자 변환 (NaN 처리)
        def _safe_float_df(df: pd.DataFrame, cols: list[str]) -> pd.DataFrame:
            out = df.copy()
            for c in cols:
                out[c] = pd.to_numeric(out[c], errors="coerce")
            return out

        df = _safe_float_df(df, FEATURE_COLS)
        before = len(df)
        df = df.dropna(subset=["cycle_idx"] + FEATURE_COLS).copy()
        after = len(df)

        assert after > 0, "All rows dropped after numeric coercion / NaN removal"

        # cycle_idx int 변환
        df["cycle_idx"] = pd.to_numeric(df["cycle_idx"], errors="coerce").astype(int)

        clean_path = f"/tmp/{BATTERY_ID}_lowess_for_transformer_clean.csv"
        df.to_csv(clean_path, index=False)

        print(f"✓ Validation passed: before={before}, after={after}, saved={clean_path}")
        return clean_path

    @task
    def train_model(clean_path: str) -> str:
        """
        Anomaly Transformer 학습
        - Solver 활용
        - MLflow tracking
        """
        # MLflow 설정
        mlflow.set_tracking_uri(MLFLOW_TRACKING_URI)
        mlflow.set_experiment(MLFLOW_EXPERIMENT_NAME)
        
        # Artifacts 저장 경로
        model_dir = f"/tmp/{BATTERY_ID}_transformer_artifacts"
        os.makedirs(model_dir, exist_ok=True)
        
        # Config 생성 (Solver에 전달할 딕셔너리)
        config = {
            "lr": AT_PARAMS["lr"],
            "num_epochs": AT_PARAMS["num_epochs"],
            "k": AT_PARAMS["k"],
            "win_size": AT_PARAMS["win_size"],
            "input_c": AT_PARAMS["input_c"],
            "output_c": AT_PARAMS["output_c"],
            "batch_size": AT_PARAMS["batch_size"],
            "stride": AT_PARAMS["stride"],
            "dataset": AT_PARAMS["dataset"],
            "data_path": clean_path,  # Task 2에서 받은 경로
            "model_save_path": model_dir,
            "anormly_ratio": AT_PARAMS["anormly_ratio"],
            "split_mode": AT_PARAMS["split_mode"],
        }
        
        # MLflow Run 시작
        with mlflow.start_run() as run:
            run_id = run.info.run_id
            print(f"MLflow Run ID: {run_id}")
            
            # Hyperparameters logging
            mlflow.log_params(config)
            mlflow.log_param("battery_id", BATTERY_ID)
            
            # Solver 초기화 및 학습
            solver = Solver(config)
            solver.train()
            
            # Training history 로깅
            history_path = os.path.join(model_dir, 'training_history.pkl')
            if os.path.exists(history_path):
                import pickle
                with open(history_path, 'rb') as f:
                    history = pickle.load(f)
                
                # Epoch별 metrics 로깅
                for epoch, (train_loss, vali_loss1, vali_loss2) in enumerate(
                    zip(history['train_loss'], history['vali_loss1'], history['vali_loss2'])
                ):
                    mlflow.log_metric("train_loss", train_loss, step=epoch)
                    mlflow.log_metric("vali_loss1", vali_loss1, step=epoch)
                    mlflow.log_metric("vali_loss2", vali_loss2, step=epoch)
                
                mlflow.log_artifact(history_path)
            
            # Checkpoint 로깅
            checkpoint_path = os.path.join(model_dir, f"{config['dataset']}_checkpoint.pth")
            if os.path.exists(checkpoint_path):
                mlflow.log_artifact(checkpoint_path)
            
            # Meta 정보 저장
            meta = {
                "battery_id": BATTERY_ID,
                "mlflow_run_id": run_id,
                "config": config,
            }
            meta_path = os.path.join(model_dir, "train_meta.json")
            with open(meta_path, "w", encoding="utf-8") as f:
                json.dump(meta, f, ensure_ascii=False, indent=2)
            mlflow.log_artifact(meta_path)
            
            print(f"✓ Training completed. artifacts_dir={model_dir}")
            print(f"✓ MLflow Run ID: {run_id}")
        
        return model_dir

    @task
    def test_model(artifacts_dir: str) -> str:
        """
        Anomaly Transformer 테스트
        - Train set으로 threshold 계산
        - Test set anomaly score 계산
        - Cycle별 anomaly score 계산
        """
        # MLflow 설정 (train과 동일한 experiment)
        mlflow.set_tracking_uri(MLFLOW_TRACKING_URI)
        mlflow.set_experiment(MLFLOW_EXPERIMENT_NAME)
        
        # Train meta 읽기
        meta_path = os.path.join(artifacts_dir, "train_meta.json")
        with open(meta_path, "r", encoding="utf-8") as f:
            meta = json.load(f)
        
        config = meta["config"]
        
        # MLflow Run 시작 (train과 연결하려면 같은 run_id 사용 가능)
        with mlflow.start_run(run_id=meta["mlflow_run_id"]):
            print(f"MLflow Run ID: {meta['mlflow_run_id']}")
            
            # Solver 초기화 및 테스트
            solver = Solver(config)
            accuracy, precision, recall, f_score = solver.test()
            
            # Test metrics 로깅
            mlflow.log_metric("test_accuracy", accuracy)
            mlflow.log_metric("test_precision", precision)
            mlflow.log_metric("test_recall", recall)
            mlflow.log_metric("test_f_score", f_score)
            
            # Test results 로깅
            test_results_path = os.path.join(artifacts_dir, 'test_results.pkl')
            if os.path.exists(test_results_path):
                import pickle
                with open(test_results_path, 'rb') as f:
                    results = pickle.load(f)
                
                # Threshold 로깅
                mlflow.log_param("threshold", results['threshold'])
                
                # Cycle별 anomaly scores를 CSV로 저장
                if 'cycle_scores' in results:
                    cycle_scores_df = pd.DataFrame([
                        {"cycle_idx": cycle, "anomaly_score": score}
                        for cycle, score in results['cycle_scores'].items()
                    ])
                    cycle_scores_path = os.path.join(artifacts_dir, f"{BATTERY_ID}_cycle_scores.csv")
                    cycle_scores_df.to_csv(cycle_scores_path, index=False)
                    
                    print(f"✓ Cycle scores saved: {len(cycle_scores_df)} cycles")
                    mlflow.log_artifact(cycle_scores_path)
                
                # Test results artifact 로깅
                mlflow.log_artifact(test_results_path)
            
            print(f"✓ Testing completed.")
            print(f"  Accuracy: {accuracy:.4f}, Precision: {precision:.4f}")
            print(f"  Recall: {recall:.4f}, F-score: {f_score:.4f}")
        
        return artifacts_dir

    @task
    def persist_outputs(artifacts_dir: str):
        """S3 및 Snowflake에 결과 저장"""
        run_ts = datetime.utcnow().strftime("%Y%m%d_%H%M%S")
        s3_hook = S3Hook(aws_conn_id=AWS_CONN_ID)
        sf_hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)

        # --- S3 upload ---
        files_to_upload = [
            os.path.join(artifacts_dir, f"{AT_PARAMS['dataset']}_checkpoint.pth"),
            os.path.join(artifacts_dir, "train_meta.json"),
            os.path.join(artifacts_dir, "training_history.pkl"),
            os.path.join(artifacts_dir, "test_results.pkl"),
            os.path.join(artifacts_dir, f"{BATTERY_ID}_cycle_scores.csv"),
        ]

        for fp in files_to_upload:
            if os.path.exists(fp):
                key = f"{S3_PREFIX}{BATTERY_ID}/{run_ts}/{os.path.basename(fp)}"
                s3_hook.load_file(filename=fp, key=key, bucket_name=S3_BUCKET, replace=True)
                print(f"✓ Uploaded: s3://{S3_BUCKET}/{key}")
            else:
                print(f"⚠ File not found, skipping: {fp}")

        # --- Snowflake load ---
        cycle_scores_path = os.path.join(artifacts_dir, f"{BATTERY_ID}_cycle_scores.csv")
        
        if not os.path.exists(cycle_scores_path):
            print("⚠ cycle_scores.csv not found, skipping Snowflake load")
            return

        conn = sf_hook.get_conn()
        cur = conn.cursor()
        try:
            cur.execute(f"USE DATABASE {SNOWFLAKE_DB};")
            
            # ANALYTICS 스키마 생성 (없으면)
            cur.execute(f"CREATE SCHEMA IF NOT EXISTS {SNOWFLAKE_SCHEMA_ANALYTICS};")
            cur.execute(f"USE SCHEMA {SNOWFLAKE_SCHEMA_ANALYTICS};")

            # 결과 테이블 생성
            cur.execute(f"""
                CREATE TABLE IF NOT EXISTS {RESULT_TABLE} (
                    cycle_idx INT,
                    anomaly_score FLOAT,
                    run_ts STRING
                );
            """)

            # run_ts 컬럼 추가
            df = pd.read_csv(cycle_scores_path)
            df["run_ts"] = run_ts
            tmp_path = f"/tmp/{BATTERY_ID}_cycle_scores_with_runts.csv"
            df.to_csv(tmp_path, index=False)

            # Temp table
            cur.execute(f"CREATE TEMP TABLE temp_at_results LIKE {RESULT_TABLE};")

            abs_path = os.path.abspath(tmp_path)
            filename = os.path.basename(abs_path)

            cur.execute(
                f"PUT 'file://{abs_path}' {SNOWFLAKE_INTERNAL_STAGE_PATH} auto_compress=false overwrite=true;"
            )

            cur.execute(f"""
                COPY INTO temp_at_results
                FROM {SNOWFLAKE_INTERNAL_STAGE_PATH}/{filename}
                FILE_FORMAT = (TYPE = 'CSV' SKIP_HEADER = 1 FIELD_OPTIONALLY_ENCLOSED_BY='"')
                ON_ERROR = 'ABORT_STATEMENT';
            """)

            # Append 적재
            cur.execute(f"INSERT INTO {RESULT_TABLE} SELECT * FROM temp_at_results;")

            cnt = cur.execute(f"SELECT COUNT(*) FROM {RESULT_TABLE} WHERE run_ts='{run_ts}';").fetchone()[0]
            print(f"✓ Inserted into {RESULT_TABLE}: run_ts={run_ts}, rows={cnt}")

        finally:
            cur.close()
            conn.close()
    
    # Dependency 정의
    extracted = extract_lowess_from_snowflake()
    cleaned = validate_ml_data(extracted)
    artifacts_train = train_model(cleaned)
    artifacts_test = test_model(artifacts_train)
    persist_outputs(artifacts_test)
    
# DAG 실행
battery_ml_transformer_pipeline()

1. MLflow를 활용한 실험 관리 및 추적 (Experiment Tracking)

로직: mlflow.start_run()을 통해 학습 과정을 세션화하고, 하이퍼파라미터(log_params)와 Epoch 별 손실 함수(log_metric), 그리고 최종 모델 파일(log_artifact)을 중앙 서버에서 관리합니다.
엔지니어링 의도: 딥러닝은 파라미터 변화에 따른 성능 차이가 큽니다. 단순히 결과를 저장하는 것이 아니라, MLflow를 통해 수많은 실험 중 '최적의 모델'이 무엇인지 시각적으로 비교하고 관리할 수 있는 MLOps 환경을 구축했습니다.

2. 외부 딥러닝 모듈의 동적 통합 (Plugin System)

로직: sys.path.insert를 사용해 Airflow 플러그인 경로에 위치한 외부 Anomaly-Transformer 소스 코드를 동적으로 불러와 Solver 객체를 초기화합니다.
엔지니어링 의도: 연구용 코드를 실제 운영 환경(Airflow)에 통합할 때 발생하는 경로 문제를 해결했습니다. 이를 통해 모델 아키텍처 코드를 수정하지 않고도 파이프라인 내에 딥러닝 엔진을 이식하는 유연성을 확보했습니다.

3. 데이터 분석을 위한 스키마 분리 (Schema Isolation)

로직: 결과 데이터를 기존 RAW_DATA 스키마가 아닌 별도의 ANALYTICS 스키마에 적재합니다.
엔지니어링 의도: 원천 데이터(Raw)와 가공 데이터(Preprocessed), 그리고 모델이 생성한 통계 결과(Analytics)를 물리적으로 분리했습니다. 이는 데이터 거버넌스 측면에서 분석가들이 신뢰할 수 있는 데이터만 조회할 수 있게 하는 실무적인 설계입니다.

4. 평가 지표의 자동화된 로깅 (Evaluation Automation)

로직: test_model 태스크에서 Accuracy, Precision, Recall, F-score를 계산하고 이를 다시 MLflow에 기록합니다.
엔지니어링 의도: 모델의 '학습'과 '검증'을 분리된 태스크로 정의하여, 학습이 완료된 후 즉시 객관적인 성능 지표를 산출합니다. 이는 배포 여부를 결정하는 CI/CD 파이프라인의 판단 근거가 됩니다.

5. 체크포인트 기반의 아티팩트 보존 전략

로직: 학습 중 생성된 .pth 체크포인트와 training_history.pkl을 S3와 Snowflake 내부 스테이지에 이중으로 백업합니다.
엔지니어링 의도: 딥러닝 모델은 학습 시간이 길고 자원이 많이 소모됩니다. 장애가 발생하거나 특정 시점의 모델로 롤백해야 할 경우를 대비해 학습의 결과물(Artifacts)을 체계적으로 버전 관리하도록 설계했습니다.

Trouble shooting

sys.path.insert를 사용 이유

문제 상황: Anomaly Transformer는 논문 구현을 위한 커스텀 코드로 구성되어 있어, 내부적으로 from solver import Solver와 같은 상대 경로 참조가 가득했습니다. 하지만 Airflow Worker 환경이나 MLflow가 이 코드를 실행할 때, 실행 위치(Working Directory)가 달라지면서 모듈을 찾지 못하는 ModuleNotFoundError가 발생했습니다.
원인: Airflow의 Python 인터프리터는 프로젝트 루트를 기준으로 모듈을 찾지만, 커스텀 모델 패키지는 독립된 폴더(plugins/Anomaly-Transformer) 아래에 있어 인식이 되지 않았습니다.
해결: sys.path.insert(0, path)를 통해 파이썬이 모듈을 검색하는 우선순위 리스트에 직접 커스텀 코드 경로를 주입했습니다. 특히 MLflow 전송 시에도 모델 소스 코드가 유실되지 않도록 경로를 명시적으로 제어하여 코드 성공률을 100%로 만들었습니다.

마치며

ML/DL 파이프라인을 구축하며 가장 중요하게 생각한 것은 '모델의 재현성'이었습니다. 단순히 한 번의 학습으로 끝나는 것이 아니라, 새로운 데이터가 들어올 때마다 동일한 검증 과정을 거치고, 그 결과가 메타데이터와 함께 기록되어 언제든 복기할 수 있는 구조인 MLOps의 본질을 구현하고자 했습니다.

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

월요일zoa — Thu, 8 Jan 2026 11:42:30 +0900

24시간 멈추지 않는 스마트 팩토리: Airflow와 Snowflake 기반 자동화 시스템

앞선 포스팅을 통해 데이터 파이프라인의 기초와 장애에 대비하는 설계 원칙(멱등성, 트랜잭션)에 대해 심도 있게 다루었습니다. 하지만 훌륭한 설계 원칙도 실제 구현 환경에서 제대로 작동하지 않는다면 무용지물입니다.

시리즈의 마지막인 이번 글에서는 NASA 배터리 시계열 데이터를 처리하기 위해 제가 구축한 End-to-End 파이프라인의 실체를 공개합니다. 복잡한 센서 노이즈를 제거하는 LOWESS 전처리부터, 데이터 웨어하우스인 Snowflake로의 안정적인 적재까지의 전 과정을 코드를 통해 상세히 분석해보려 합니다.

단순히 '돌아가는 코드'를 작성하는 것에 그치지 않고, 왜 이 기술 스택을 선택했는지, 그리고 개발 과정에서 마주친 예기치 못한 에러들을 어떻게 엔지니어링적으로 해결했는지에 대한 저의 치열한 고민 과정을 담았습니다. 이 기록이 안정적인 MLOps 환경을 구축하려는 분들에게 실질적인 가이드가 되기를 바랍니다.

Snowflake와 Airflow를 사용한 이유

본 프로젝트에서 Airflow와 Snowflake를 선택한 이유는 배터리 이상 탐지 시스템의 자동화와 확장성을 확보하기 위함이었습니다.

Airflow는 배터리 데이터 전처리(LOWESS smoothing)부터 모델 학습, 평가까지의 전체 워크플로우를 오케스트레이션하는 역할을 수행합니다. 이를 통해 주기적인 재학습과 배치 처리를 자동화할 수 있으며, 각 태스크 간 의존성 관리와 실패 처리를 체계적으로 구현할 수 있었습니다.

Snowflake는 50,000개 이상의 timestep을 가진 멀티배터리 시계열 데이터를 중앙 집중식으로 저장하고 쿼리하는 데이터 웨어하우스로 활용되었습니다. 여러 배터리(B0005, B0006, B0007) 간 cross-battery 분석을 지원하며, 확장 가능한 스토리지와 빠른 쿼리 성능을 제공합니다.

스마트 팩토리 환경에서 이러한 툴들은 더욱 중요한 의미를 갖습니다. 실제 제조 현장에서는 여러 배터리 팩과 ESS 장비에서 멀티소스 센서 데이터가 지속적으로 발생하며, 이를 통합 관리하고 실시간 모니터링과 이상 탐지를 수행해야 합니다. Airflow와 Snowflake의 조합은 프로덕션 환경에서 지속적인 모델 업데이트와 배포를 자동화하는 확장 가능한 MLOps 파이프라인의 핵심 인프라입니다.

DAG 코드 주요 로직 및 엔지니어링 포인트 분석

Dag 1: Data Ingestion

from airflow.decorators import dag, task
from airflow.providers.snowflake.hooks.snowflake import SnowflakeHook
from airflow.providers.amazon.aws.hooks.s3 import S3Hook
from datetime import datetime
import pandas as pd
import os

SNOWFLAKE_CONN_ID = 'snowflake'
S3_BUCKET = 'bucket'
S3_PREFIX = 'battery/raw/'

@dag(
    dag_id='battery_dag_01_load',
    start_date=datetime(2024, 12, 1),
    schedule=None,
    catchup=False,
    tags=['battery', 'load']
)
def battery_load_pipeline():
    
    @task
    def extract_battery_data():
        """CSV 배터리 데이터 추출 및 기본 전처리"""
        csv_path = '/opt/airflow/data/B0007_discharge.csv'
        df = pd.read_csv(csv_path)
        
        # 정렬
        df = df.sort_values(['cycle_idx']).reset_index(drop=True)
        
        # 불필요한 컬럼 제거
        drop_cols = ['start_time_raw', 'Capacity', 'type', 'ambient_temperature', 'Time']
        df = df.drop([col for col in drop_cols if col in df.columns], axis=1)
        
        # snowflake 스키마와 동일하게 컬럼 순서 재배치
        df = df[['cycle_idx', 'Voltage_measured', 'Current_measured', 
             'Temperature_measured', 'Current_load', 'Voltage_load']]
        
        # 임시 저장
        file_path = '/tmp/battery_b0007_raw.csv'
        df.to_csv(file_path, index=False)
        
        print(f"✓ Extracted {len(df)} rows, cycles {df['cycle_idx'].min()}-{df['cycle_idx'].max()}")
        return file_path
    
    @task
    def validate_data(file_path: str):
        """데이터 검증"""
        df = pd.read_csv(file_path)
        
        # 검증
        assert df.isnull().sum().sum() == 0, "Missing values detected"
        assert len(df) > 0, "Empty dataframe"
        assert (df['Voltage_measured'] > 0).all(), "Invalid voltage values"
        
        print(f"✓ Validation passed: {len(df)} rows")
        return file_path
    
    @task
    def upload_to_s3(file_path: str):
        """S3 업로드"""
        s3_hook = S3Hook(aws_conn_id='aws_conn')
        s3_key = f"{S3_PREFIX}{os.path.basename(file_path)}"
        
        s3_hook.load_file(
            filename=file_path,
            key=s3_key,
            bucket_name=S3_BUCKET,
            replace=True
        )
        
        print(f"✓ Uploaded to s3://{S3_BUCKET}/{s3_key}")
        return s3_key
    
    @task
    def load_to_snowflake(s3_key: str):
        """Snowflake 적재 (S3 Stage 경유)"""
        hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)
        conn = hook.get_conn()
        cur = conn.cursor()
        
        try:
            cur.execute("USE DATABASE BATTERY_DATABASE;")
            cur.execute("USE SCHEMA RAW_DATA;")
            
            # 테이블 생성 (PRIMARY KEY 제거)
            cur.execute("""
                CREATE TABLE IF NOT EXISTS BATTERY_B0007_RAW (
                    cycle_idx INT,
                    Voltage_measured FLOAT,
                    Current_measured FLOAT,
                    Temperature_measured FLOAT,
                    Current_load FLOAT,
                    Voltage_load FLOAT
                );
            """)
            
            # Staging 테이블
            cur.execute("CREATE TEMP TABLE temp_battery LIKE BATTERY_B0007_RAW;")
            
            # S3에서 COPY
            cur.execute(f"""
                COPY INTO temp_battery
                FROM @battery_s3_stage/{os.path.basename(s3_key)}
                FILE_FORMAT = (TYPE = 'CSV' SKIP_HEADER = 1)
                ON_ERROR = 'ABORT_STATEMENT';
            """)
            
            # TRUNCATE + INSERT 방식으로 적재
            cur.execute("TRUNCATE TABLE BATTERY_B0007_RAW;")
            cur.execute("INSERT INTO BATTERY_B0007_RAW SELECT * FROM temp_battery;")
            
            # 결과 확인
            result = cur.execute("SELECT COUNT(*) FROM BATTERY_B0007_RAW;").fetchone()
            print(f"✓ Total rows in BATTERY_B0007_RAW: {result[0]}")
            
        finally:
            cur.close()
            conn.close()

    # Task 의존성
    file_path = extract_battery_data()
    validated_path = validate_data(file_path)
    s3_key = upload_to_s3(validated_path)
    load_to_snowflake(s3_key)

battery_load_pipeline()

1. Upstream에서의 데이터 품질 검증 (Data Quality Check)

데이터가 데이터 웨어하우스에 들어가기 전, validate_data 태스크를 통해 엄격한 검증 과정을 거칩니다.

로직: assert 문을 사용하여 결측치 여부, 데이터 유무, 그리고 도메인 지식을 반영한 전압값(Voltage)의 유효성을 체크합니다.
의도: 잘못된 데이터가 하류(Downstream)로 흘러가 분석 결과나 모델 성능을 오염시키는 것을 원천 차단했습니다.

2. S3 Staging을 통한 클라우드 최적화

로컬 데이터를 직접 Snowflake로 넣지 않고 중간에 AWS S3를 거치도록 설계했습니다.

이유: Snowflake의 COPY INTO 명령은 클라우드 스토리지를 활용할 때 가장 높은 성능을 발휘합니다. S3를 Staging 영역으로 활용함으로써 대용량 시계열 데이터를 효율적이고 안정적으로 적재할 수 있는 기반을 마련했습니다.

3. SQL 트랜잭션을 활용한 멱등성(Idempotency) 확보

가장 공을 들인 부분은 load_to_snowflake 태스크의 적재 전략입니다.

전략: TEMP TABLE 생성 → COPY INTO로 데이터 로드 → 최종 테이블 TRUNCATE → INSERT
의도: 2편에서 강조했던 멱등성을 실무적으로 구현한 부분입니다. 네트워크 오류 등으로 DAG가 재실행되더라도 데이터가 중복으로 쌓이지 않고, 항상 최신의 단일 상태를 유지하게 하여 데이터 정합성을 보장했습니다.

4. Python Decorators를 통한 가독성 높은 DAG 설계

Airflow의 최신 방식인 Taskflow API(@dag, @task)를 사용하여 파이프라인을 구축했습니다.

장점: 기존의 Operator 방식보다 태스크 간 데이터 흐름(XCom)이 직관적으로 보이며, 코드의 가독성이 높아 유지보수가 용이합니다.

Dag 2: lowess feature engineering

from airflow.decorators import dag, task
from airflow.providers.snowflake.hooks.snowflake import SnowflakeHook
from airflow.providers.amazon.aws.hooks.s3 import S3Hook
from datetime import datetime
import pandas as pd
import numpy as np
import os
import warnings
from statsmodels.nonparametric.smoothers_lowess import lowess

# battery_dag_01_load.py의 S3 업로드 패턴과 동일한 형태로 구성 
S3_BUCKET = "bucket"
S3_PREFIX = "battery/preprocess/"
AWS_CONN_ID = "aws_conn"
SNOWFLAKE_CONN_ID = 'snowflake_conn'

# 입력 CSV (discharge only)
# CSV_PATH = "/opt/airflow/data/B0005_discharge.csv"
BATTERY_ID = "B0007"

SNOWFLAKE_DB = "BATTERY_DATABASE"
SNOWFLAKE_SCHEMA = "RAW_DATA"
SOURCE_TABLE = f"BATTERY_{BATTERY_ID}_RAW"      # BATTERY_B0005_RAW
TARGET_TABLE = f"BATTERY_{BATTERY_ID}_LOWESS"   # BATTERY_B0005_LOWESS

SNOWFLAKE_INTERNAL_STAGE_PATH = "@~/battery_upload"

# build_dataset.py 기본값 
LOWESS_FRAC = 0.05

# build_dataset.py에서 LOWESS 대상 컬럼 
TARGET_COLS = [
    "Voltage_measured",
    "Current_measured",
    "Temperature_measured",
    "Current_load",
    "Voltage_load",
]

# build_dataset.py에서 drop 대상 컬럼 
DROP_COLS = ["start_time_raw", "Capacity", "type", "ambient_temperature", "Time"]


def apply_lowess_by_cycle(df: pd.DataFrame, col: str, frac: float) -> pd.DataFrame:
    """
    build_dataset.py의 apply_lowess 로직(사이클별 LOWESS -> smooth/residual/trend) 동일 구현
    """
    smooth_data, residual_data, trend_data, indices = [], [], [], []

    for cycle in sorted(df["cycle_idx"].unique()):
        mask = df["cycle_idx"] == cycle
        cycle_idx = df[mask].index
        values = df.loc[mask, col].values

        n = len(values)
        if n == 0:
            continue

        time_idx = np.arange(n)
        with warnings.catch_warnings():
            warnings.simplefilter("ignore")
            smoothed = lowess(values, time_idx, frac=frac, return_sorted=False)

        residual = values - smoothed
        trend = np.gradient(smoothed)

        smooth_data.extend(smoothed)
        residual_data.extend(residual)
        trend_data.extend(trend)
        indices.extend(cycle_idx)

    df[f"{col}_smooth"] = pd.Series(smooth_data, index=indices).reindex(df.index)
    df[f"{col}_residual"] = pd.Series(residual_data, index=indices).reindex(df.index)
    df[f"{col}_trend"] = pd.Series(trend_data, index=indices).reindex(df.index)

    return df


@dag(
    dag_id="battery_dag_02_load",
    start_date=datetime(2024, 12, 1),
    schedule=None,
    catchup=False,
    tags=["battery", "discharge", "lowess", "dataset"],
)
def battery_build_dataset_discharge_lowess_pipeline():
    @task
    def extract_and_preprocess_discharge() -> str:
        """
        Snowflake의 RAW 테이블(BATTERY_B0005_RAW)에서 데이터를 읽어서
        정렬/전처리 후 로컬 tmp CSV로 저장
        """
        hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)

        sql = f"""
            SELECT
                CYCLE_IDX,
                VOLTAGE_MEASURED,
                CURRENT_MEASURED,
                TEMPERATURE_MEASURED,
                CURRENT_LOAD,
                VOLTAGE_LOAD
            FROM {SNOWFLAKE_DB}.{SNOWFLAKE_SCHEMA}.{SOURCE_TABLE}
            ORDER BY CYCLE_IDX
        """

        # SnowflakeHook는 pandas df를 바로 받을 수 있습니다.
        df = hook.get_pandas_df(sql)

        # 1. 실제 Snowflake에서 넘어온 컬럼 확인 (디버깅 핵심)
        print("DEBUG [raw Snowflake columns]:", df.columns.tolist())

         # 2. 컬럼명 표준화 (대문자 → DAG 전체 기준 컬럼명)
        rename_map = {
            "CYCLE_IDX": "cycle_idx",
            "VOLTAGE_MEASURED": "Voltage_measured",
            "CURRENT_MEASURED": "Current_measured",
            "TEMPERATURE_MEASURED": "Temperature_measured",
            "CURRENT_LOAD": "Current_load",
            "VOLTAGE_LOAD": "Voltage_load",
        }

        df = df.rename(columns=rename_map)

        # (방어) drop (존재하는 컬럼만)
        df = df.drop([c for c in DROP_COLS if c in df.columns], axis=1)

        # 정렬/인덱스 정리
        df = df.sort_values(["cycle_idx"]).reset_index(drop=True)

        file_path = f"/tmp/{BATTERY_ID}_discharge_preprocessed.csv"
        df.to_csv(file_path, index=False)

        print(f"✓ Loaded from Snowflake {SOURCE_TABLE}: {len(df)} rows, cycles {df['cycle_idx'].min()}-{df['cycle_idx'].max()}")
        return file_path

    @task
    def validate_data(file_path: str) -> str:
        """
        데이터 검증
        """
        df = pd.read_csv(file_path)

        assert len(df) > 0, "Empty dataframe"
        assert "cycle_idx" in df.columns, "cycle_idx missing"
        assert df.isnull().sum().sum() == 0, "Missing values detected"

        # LOWESS 대상 컬럼 중 실제 존재하는 컬럼만 검증
        existing_targets = [c for c in TARGET_COLS if c in df.columns]
        assert len(existing_targets) > 0, f"No target cols exist among {TARGET_COLS}"

        # load 파이프라인에서도 voltage > 0 검증을 했으므로 유지
        if "Voltage_measured" in df.columns:
            assert (df["Voltage_measured"] > 0).all(), "Invalid Voltage_measured (<=0) detected"

        print(f"✓ Validation passed: {len(df)} rows, target_cols={existing_targets}")
        return file_path

    @task
    def build_lowess_features(file_path: str) -> str:
        """
        build_dataset.py의 apply_lowess(discharge-only) 구현 
        """
        df = pd.read_csv(file_path)

        # 존재하는 컬럼만 LOWESS 처리 (방어)
        existing_targets = [c for c in TARGET_COLS if c in df.columns]
        for col in existing_targets:
            print(f"LOWESS 처리 중: {col}")
            df = apply_lowess_by_cycle(df, col=col, frac=LOWESS_FRAC)

        out_path = f"/tmp/{BATTERY_ID}_discharge_with_lowess_features.csv"
        df.to_csv(out_path, index=False)

        print(f"✓ LOWESS done: {out_path}, shape={df.shape}")
        return out_path

    @task
    def upload_to_s3(file_path: str) -> str:
        """
        s3 업로드 
        """
        s3_hook = S3Hook(aws_conn_id=AWS_CONN_ID)
        s3_key = f"{S3_PREFIX}{os.path.basename(file_path)}"

        s3_hook.load_file(
            filename=file_path,
            key=s3_key,
            bucket_name=S3_BUCKET,
            replace=True,
        )

        print(f"✓ Uploaded to s3://{S3_BUCKET}/{s3_key}")
        return s3_key
    
    @task
    def load_to_snowflake(file_path: str):
        """LOWESS 결과를 Snowflake(BATTERY_B0005_LOWESS)에 적재 (S3 경유 X)"""
        hook = SnowflakeHook(snowflake_conn_id=SNOWFLAKE_CONN_ID)
        conn = hook.get_conn()
        cur = conn.cursor()

        try:
            cur.execute(f"USE DATABASE {SNOWFLAKE_DB};")
            cur.execute(f"USE SCHEMA {SNOWFLAKE_SCHEMA};")

            # 결과 CSV를 읽어서 컬럼 목록 기반으로 테이블 스키마 생성(간단 매핑)
            df = pd.read_csv(file_path)
            cols = df.columns.tolist()

            # cycle_idx는 INT, 나머지는 FLOAT로 가정 (LOWESS 파생은 모두 수치)
            col_defs = []
            for c in cols:
                if c == "cycle_idx":
                    col_defs.append(f"{c} INT")
                else:
                    col_defs.append(f"{c} FLOAT")

            create_sql = f"""
                CREATE TABLE IF NOT EXISTS {TARGET_TABLE} (
                    {", ".join(col_defs)}
                );
            """
            cur.execute(create_sql)

            # 임시 테이블 (동일 스키마)
            cur.execute(f"CREATE TEMP TABLE temp_lowess LIKE {TARGET_TABLE};")

            # PUT: 로컬 파일 -> Snowflake 내부 stage
            abs_path = os.path.abspath(file_path)
            filename = os.path.basename(abs_path)
            cur.execute(f"PUT 'file://{abs_path}' {SNOWFLAKE_INTERNAL_STAGE_PATH} auto_compress=false overwrite=true;")

            # COPY: 내부 stage -> temp
            cur.execute(f"""
                COPY INTO temp_lowess
                FROM {SNOWFLAKE_INTERNAL_STAGE_PATH}/{filename}
                FILE_FORMAT = (TYPE = 'CSV' SKIP_HEADER = 1 FIELD_OPTIONALLY_ENCLOSED_BY='"')
                ON_ERROR = 'ABORT_STATEMENT';
            """)

            # 풀 리프레시(기존 패턴 유지)
            cur.execute(f"TRUNCATE TABLE {TARGET_TABLE};")
            cur.execute(f"INSERT INTO {TARGET_TABLE} SELECT * FROM temp_lowess;")

            result = cur.execute(f"SELECT COUNT(*) FROM {TARGET_TABLE};").fetchone()
            print(f"✓ Total rows in {TARGET_TABLE}: {result[0]}")

        finally:
            cur.close()
            conn.close()
    # Task 의존성 
    preprocessed = extract_and_preprocess_discharge()
    validated = validate_data(preprocessed)
    lowess_csv = build_lowess_features(validated)
    upload_to_s3(lowess_csv)
    load_to_snowflake(lowess_csv)


battery_build_dataset_discharge_lowess_pipeline()

1. 도메인 지식을 반영한 통계적 피처 엔지니어링 (LOWESS)

로직: apply_lowess_by_cycle 함수를 통해 배터리 사이클별로 데이터를 분할하고, 센서 노이즈가 제거된 smooth, 원본과의 차이인 residual, 변화율인 trend라는 3가지 새로운 피처를 생성합니다.
엔지니어링 의도: 배터리 센서 데이터는 미세한 전압 변화가 중요하지만 노이즈에 취약합니다. 이를 단순히 머신러닝 모델에 넣기보다, 통계적 평활화(Smoothing)를 선행하여 모델이 데이터의 본질적인 패턴(열화 경향)을 더 잘 학습할 수 있도록 설계했습니다.

2. 'Fail-Fast'를 위한 방어적 데이터 검증

로직: validate_data 태스크에서 cycle_idx 존재 여부, 결측치(Null) 검사, 전압값 유효성 등을 다시 한번 체크합니다.
엔지니어링 의도: 전처리는 연산 비용이 높습니다. 잘못된 데이터가 전처리 단계로 진입하여 리소스를 낭비하지 않도록, 중간 관문을 두어 파이프라인의 효율성을 높였습니다.

3. Snowflake 내부 스테이지(Internal Stage) 활용 능력

로직: load_to_snowflake에서 PUT 명령어를 사용해 로컬 파일을 Snowflake의 내부 스테이지(@~/battery_upload)로 직접 업로드한 뒤 COPY INTO를 실행합니다.
엔지니어링 의도: dag 1에서는 S3(외부 스테이지)를 썼다면, dag 2에서는 Snowflake 고유의 내부 스테이지를 활용했습니다.

4. 유연한 스키마 설계 (Dynamic Schema Generation)

로직: Pandas DataFrame의 컬럼 리스트를 기반으로 Snowflake 테이블의 CREATE TABLE 문을 동적으로 생성합니다.
엔지니어링 의도: LOWESS 처리를 거치면 기존 피처 수의 3배가 넘는 컬럼이 생성됩니다. 이를 하드코딩하지 않고 코드 기반으로 스키마를 동적 생성하게 함으로써, 추후 가공 피처가 추가되거나 변경되어도 파이프라인 수정 없이 대응할 수 있는 확장성을 확보했습니다.

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

월요일zoa — Thu, 8 Jan 2026 11:36:11 +0900

성공하는 파이프라인보다 중요한 것은, 실패해도 안전한 파이프라인

데이터 엔지니어링의 세계에서 "완벽한 시스템"이란 존재하지 않습니다. 네트워크 장애, 데이터 소스의 급격한 변화, 혹은 예상치 못한 서버 다운까지, 우리가 구축한 파이프라인은 언제나 실패할 가능성에 노출되어 있습니다.

진정한 엔지니어링 역량은 멱등성과 트랜잭션으로 완성할 수 있습니다.

저 역시 NASA 배터리 데이터 파이프라인을 구축하며 Raw data load와 연산량이 많은 LOWESS 전처리 과정에서 여러 차례의 태스크 중단을 경험했습니다. 이때 제가 고민한 것은 단순히 에러를 고치는 것이 아니라, 수십 번을 재실행해도 데이터 정합성이 깨지지 않는 구조를 만드는 것이었습니다.

이번 포스팅에서는 안정적인 MLOps 시스템의 근간이 되는 설계 원칙들을 살펴보고, 제가 프로젝트에서 장애를 대비해 어떤 '안전장치'들을 설계했는지 공유하고자 합니다.

멱등성이란?

정의

멱등성은 어떤 연산이나 작업을 여러 번 반복해도 결과가 한 번 했을 때와 달라지지 않는 성질을 말합니다. 특히, API와 HTTP 설계에서 중요한 개념입니다. f(f(x))=f(x)

중요한 이유

멱등성을 보장하면 네트워크 장애로 요청이 중복 전송되더라도 데이터가 중복으로 생성되거나 깨지는 위험을 줄일 수 있습니다. 그래서 결제 API를 설계할 때는 같은 작업을 여러 번 전송해도 결과가 한 번만 반영되도록 "멱등 키" 같은 것을 만들어 멱등성을 구현하는 경우가 많습니다.

특징

웹, API 에서 멱등성은 "동일한 요청을 여러 번 보내도 서버 상태와 결과가 첫 요청과 같게 유지되는 성질"을 뜻합니다. 예를 들어 HTTP GET, PUT, DELETE 같은 메서드는 올바르게 설계하면 여러 번 호출하더라도 서버의 최종 상태가 한 번 호출했을 때와 동일하므로 멱등 메서드로 간주됩니다.

# 멱등적 연산 예시
user.update(name="John")  # 여러 번 호출해도 같은 결과
user.update(name="John")  

# 비멱등적 연산 예시
user.increment_count() -> 3  # 호출할 때마다 값이 변함
user.increment_count() -> 4

멱등성이 깨지면 아래와 같은 문제가 발생할 수 있습니다.

# 나쁜 예: 멱등성 없음
def load_data(date):
    df = extract_data(date)
    df = transform(df)
    # 매번 INSERT만 함 → 중복 데이터 발생!
    db.execute(f"INSERT INTO sales VALUES {df}")

# 실행 결과
# 1차 실행: sales 테이블에 100건
# 2차 실행: sales 테이블에 200건 (중복!)
# 3차 실행: sales 테이블에 300건 (중복!)

멱등성 확보 방법

# 좋은 예 1: DELETE + INSERT
def load_data(date):
    df = extract_data(date)
    df = transform(df)
    
    # 해당 날짜 데이터 먼저 삭제
    db.execute(f"DELETE FROM sales WHERE date = '{date}'")
    # 새로 삽입
    db.execute(f"INSERT INTO sales VALUES {df}")

# 좋은 예 2: MERGE (UPSERT)
def load_data(date):
    df = extract_data(date)
    df = transform(df)
    
    # 있으면 UPDATE, 없으면 INSERT
    db.execute(f"""
        MERGE INTO sales USING staged_data
        ON sales.id = staged_data.id
        WHEN MATCHED THEN UPDATE SET ...
        WHEN NOT MATCHED THEN INSERT ...
    """)

# 좋은 예 3: TRUNCATE + INSERT (전체 교체)
def load_data():
    df = extract_all_data()
    df = transform(df)
    
    db.execute("TRUNCATE TABLE sales")
    db.execute(f"INSERT INTO sales VALUES {df}")

SQL transaction 이란?

정의

SQL 트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적 작업 단위로 처리되는 일련의 SQL 연산들이다. 트랜잭션은 데이터베이스의 상태를 변경하는 여러 SQL 문(INSERT, UPDATE, DELETE 등)을 하나의 논리적인 작업으로 묶은 것이다. 묶음 안에 있는 연산들은 전부 성공해서 반영되거나, 하나라도 실패하면 전체를 원래 상태로 되돌려야 한다는 특징을 가진다.

예를 들어 계좌이체에서 “A 계좌에서 1만원 출금”과 “B 계좌에 1만원 입금” 두 UPDATE가 하나의 트랜잭션이 되고, 둘 다 성공해야만 실제로 돈이 옮겨진 것으로 인정된다.

# Transaction 없이 (위험)
def load_without_transaction(date):
    db.execute(f"DELETE FROM sales WHERE date = '{date}'")
    # ⚠️ 여기서 에러 발생하면?
    # → DELETE는 완료, INSERT는 안됨 → 데이터 유실!
    db.execute(f"INSERT INTO sales VALUES {df}")

# Transaction 사용 (안전)
def load_with_transaction(date):
    try:
        db.begin_transaction()
        
        db.execute(f"DELETE FROM sales WHERE date = '{date}'")
        db.execute(f"INSERT INTO sales VALUES {df}")
        
        db.commit()  # 모두 성공 시 저장
    except Exception as e:
        db.rollback()  # 하나라도 실패 시 전부 취소
        raise e

특성

1. Atomicity (원자성)

모든 연산이 완전히 수행되거나, 전혀 수행되지 않음

2. Consistency (일관성)

트랜잭션 완료 후 데이터베이스가 일관된 상태 유지
제약조건, 규칙 위반 불가

3. Isolation (격리성)

동시 실행되는 트랜잭션들이 서로 간섭하지 않음
각 트랜잭션은 독립적으로 실행

4. Durability (지속성)

완료된 트랜잭션 결과는 영구적으로 저장

-- 주요 명령어

BEGIN;  -- 트랜잭션 시작
-- SQL 연산들
COMMIT;  -- 변경사항 확정
-- 또는
ROLLBACK;  -- 변경사항 취소
-- 또는
SAVEPOINT; -- 중간 롤백을 위한 저장 지점

※ 멱등성과 SQL 트랜잭션

여러 번 실행해도 결과가 동일한 멱등성 + 여러 작업을 하나의 논리적 작업 단위로 묶어 안전하게 실행하는 SQL 트랜잭션

→ ETL 및 Airflow 재실행 시 안정성 확보 측면에서 유리함

멱등성과 transaction을 고려한 핵심 설계 원칙

1. 반복 실행 전제 (Rerunnable Design)

ETL = 스케줄러 기반 반복 실행

↓ 과거 데이터도 재실행 가능해야 함 (Backfill)

↓ 설계 단계부터 "여러 번 실행" 가정

Backfill이 중요한 이유

데이터 누락 발견 시 과거 기간 재처리
로직 변경 시 전체 데이터 재계산
Airflow가 backfill 지원 우수

2. Load 실행 전 안전 장치 고려

Extract → Transform → Load

↓ ↓ ↓

재실행 O 재실행 O 되돌리기 X

Load의 특수성

DB에 한 번 적재되면 복구 어려움
잘못된 데이터가 downstream으로 전파
비즈니스 의사결정에 직접 영향

Load 설계 시 고려사항

멱등성 확보 (DELETE+INSERT / MERGE)
Transaction 사용
적재 전 validation (row count, null check)
적재 후 검증 로직

마치며

데이터 파이프라인에서 멱등성이 무너지면 중복 데이터가 발생하고, 이는 결국 잘못된 분석 결과로 이어져 비즈니스 의사결정을 망칩니다. 이번 설계를 통해 엔지니어링의 사소한 빈틈이 데이터의 신뢰성을 어떻게 파괴할 수 있는지를 체감했습니다.

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

월요일zoa — Tue, 6 Jan 2026 16:36:25 +0900

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

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

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

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

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

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

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

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

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

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

Airflow를 활용한 데이터 파이프라인

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

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

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

데이터 엔지니어 (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 & 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% 절감 가능.

배터리 데이터를 활용한 다변량 시계열 이상탐지 모델 및 MLOps 파이프라인 개발 프로젝트

월요일zoa — Sat, 3 Jan 2026 16:35:31 +0900

주제

데이터 분석 부트캠프 최종 주제로 '배터리셋을 활용한 다변량 시계열 이상탐지 모델 및 MLOps 파이프라인 개발 프로젝트'를 수행했다. 본 프로젝트는 배터리셋을 분석하는 다변량 시계열 이상탐지 모델을 개발하고, 실무 현장에 적용 가능한 데이터 파이프라인을 설계하는 것을 목표로 했다.

핵심 연구 목표는 다음과 같다.

리튬 이온 배터리의 열화 진행 과정 정밀 관찰
비지도 이상탐지 모델 개발

열화는 단발성으로 일어나는 것이 아닌, 사이클에 따라 점진적으로 누적되는 시간적 추세(trend)를 가지는 현상이다.

리튬 이온 배터리에서 나타나는 열화는 크게 3가지가 있다.

데이터셋

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

데이터셋은 NASA PCoE Battery Dataset으로, RUL 및 이상탐지 연구의 벤치마크로 활용된다. 총 4개 배터리 셀로 구성되며, 실온에서 정격 용량 30%까지 실험했다.각 셀은 종료 전압과 조건이 상이하다.

데이터는 충전, 방전, 임피던스로 구분되며, 하나의 방전을 1 사이클로 정의한다. 사이클별 길이는 가변적이고, 임피던스는 40 사이클 이후 측정되었다.

본 프로젝트는 방전 데이터만 사용했다. 선행 연구에서 주로 방전 데이터로 RUL과 이상탐지를 수행했으며, 열화 현상이 방전 데이터에서만 관찰되기 때문이다.

또한 Raw 데이터에 LOWESS smoothing 방법을 적용한 파생 feature 데이터셋을 실험에 사용했다. LOWESS(Locally Weighted Scatterplot Smoothing)는 국소 가중 회귀 기반 스무딩 기법으로, 센서 노이즈를 제거하면서 열화 추세를 보존한다. 다양한 도메인의 시계열 이상탐지 연구에서 LOWESS 적용 시 모델 성능이 향상된 바 있으며, 본 프로젝트에서도 노이즈 감소를 통한 이상 패턴 검출 성능 개선을 목적으로 사용했다.

EDA

이제부터 전압, 전류, 온도와 열화와의 EDA 결과를 설명하겠다.

전압

전압은 초기 방전 사이클에서는 특별한 패턴을 보이지 않다가 400 사이클 이후부터는 특별한 패턴을 보이기 시작했다. EDA 결과 전압은 열화에 가장 민감한 신호임을 알 수 있었다.

전류

전류는 방전 사이클 초기에는 큰 변화를 보였지만 후기부터는 안정적인 패턴을 확인할 수 있었다. 전압과 달리 열화가 지속될 수록 변동성이 급감한다는 점을 발견했다.

온도

온도는 열화의 누적을 반영하지만 초기 이상이나 특정 사이클에서의 이상을 직접적으로 나타내지 않는다. 열화가 뚜렷하지 않은 초기에도 변동이 클 수 있고, 열화가 나타나는 후기에도 변동이 클 수 있다.

결론을 종합하자면 배터리 열화는 모든 변수에서 동시에 나타나지 않으며 사이클마다 상이하다. 따라서 평균 용량 감소보다 순간적인 전압 불안정성(spike, noise)으로 먼저 감지된다. 또한, 가장 먼저 배터리 상태를 보여주는 것은 전압의 trend 속에서 나타나는 spike 혹은 noise이다.

Capacity와 사이클 평균 전압의 trend

열화는 선형적이지 않으며, 초기 안정 구간 → 중기 급변 구간 → 후기 저용량 구간으로 비선형적으로 진행된다. 또한, 열화 초기에는 다양한 변수가 열화에 영향을 미치지만 후기로 갈 수록 영향을 미치는 변수들이 줄어들고, 전압이 열화에 가장 큰 영향을 미치는 것을 확인했다.

머신러닝

본 연구에서는 대표적인 이상탐지 머신러닝 모델인 Isolation Forest와 LOF 모델을 비교하여 LOF 모델을 선택했다. LOF 모델은 Isolation Forest에 비해 더 local한 데이터 포인터 간 관계를 파악하는 데 적합하기 때문에 열화 국면에서 발생하는 국소적인 이상 반응을 명확히 포착하는 데 더 적합하다.

본 연구에서는 raw 데이터셋과 lowess 기반 feature 추출 방법을 사용한 데이터셋을 비교하여 실험했다. 분석 결과 사이클 별 최대 이상 점수보다 평균과 중앙 이상 점수의 R_ohmic 간 상관관계가 파생피처 사용 모델에서 더 높았다. 이는 LOWESS 파생 피처가 극단값의 영향을 줄이고 평균적 열화 경향을 포착하여 더 안정적인 이상 탐지를 가능하게 했음을 의미한다.

※ R_ohmic이란

배터리 내부 오믹 저항을 직접 반영하는 물리적 지표
방전(load) 시작 시 발생하는 순간 전압 강하(IR drop)를 기반으로 계산
Anomaly score와의 높은 상관성은 실제 물리적 열화 반영을 의미
데이터 기반 지표의 물리적 타당성 검증 근거

딥러닝

본 연구에서는 다양한 다변량 시계열 이상탐지 딥러닝 모델 중 Anomaly Transformer(AT)를 선택했다. AT를 선정한 이유도 머신러닝 모델 선정 이유와 동일하다. AT는 prior association과 series assocation 간의 차이를 minmax 전략을 사용해서 극대화하여 열화의 국소적인 이상 반응을 시간적인 문맥을 고려해서 명확히 포착할 수 있다.

AT로 사이클별 이상 점수를 분석한 결과, Raw 데이터에서는 capacity와의 상관관계가 -0.015로 거의 없었으나, LOWESS 적용 후 -0.747의 강한 음의 상관관계가 나타났다. 이는 LOWESS 파생 피처를 사용할 경우 이상 점수가 물리적 열화 지표(capacity fade)와 일치하는 패턴을 보이며, 열화 진행에 따른 이상 변화를 효과적으로 포착했음을 의미한다.

모델 활용 전략

본 연구는 LOF와 Anomaly Transformer를 상호보완적으로 활용하여 이상 탐지의 신뢰성을 높였다. LOF는 window 단위 feature 기반 분석으로 "이 구간에서 무슨 일이 일어나는가?"라는 국소적 이상을 탐지하고, Anomaly Transformer는 시계열 전체 맥락에서 재구성 오류를 분석하여 "전체적으로 의미가 있는 패턴인가?"를 판단한다. 두 모델의 교차 검증을 통해 검증된 열화 신호만을 추출하여 false positive를 감소시켰다.

MLOps 시스템

본 프로젝트는 Airflow 기반 MLOps 파이프라인으로 구성된다. 데이터 처리 단계에서는 3개의 DAG를 통해 NASA 배터리 데이터를 수집하고(DAG 1), LOWESS 기반 피처 엔지니어링을 수행하며(DAG 2), LOF와 Anomaly Transformer 모델을 학습한다(DAG 3&4). 저장 계층은 Snowflake에서 원본 데이터, 전처리된 피처, 예측 결과를 관리하고, AWS S3에 모델 학습 이력을 저장하며, MLflow로 실험 추적 및 하이퍼파라미터를 기록한다. 최종적으로 Streamlit 대시보드를 통해 Overview, Anomaly Scores, Health Indicators, Correlation Analysis, Model Comparison 5개 탭으로 시각화하여 배터리 관리자와 ML 엔지니어 모두에게 인사이트를 제공한다. Streamlit 대시보드는 s3에서 데이터를 실시간으로 다운로드 받고, github과 코드가 연동되어 있어 수정 사항을 즉각적으로 반영할 수 있다.

Dag 1 & 2

DAG 1은 데이터 수집 파이프라인으로, NASA 원본 CSV 파일을 추출(Extract)하고 데이터 검증 및 변환(Transform)을 거쳐 Snowflake Layer 1에 적재(Load)한다. DAG 2는 피처 엔지니어링 파이프라인으로, Snowflake Layer 1에서 원본 데이터를 추출한 후 LOWESS 기반 파생 변수 생성 및 전처리(Transform)를 수행하고, 최종 결과를 Snowflake Layer 2에 저장한다. 두 DAG는 순차적으로 실행되며 Snowflake를 중간 저장소로 활용하여 데이터 계층을 분리한다.

※ Dag: 실행해야 할 작업들의 흐름과 의존성을 표현한 워크플로우 정의로 무엇을 어떤 순서로 실행할지 선언하는 ‘설계도’

Dag 3 & 4

DAG 3&4는 모델 학습 및 실험 관리 파이프라인으로, Snowflake Layer 2에서 전처리된 데이터를 추출(Extract)하고 Train/Test로 분할한다. 학습 단계(Train Task)에서는 LOF와 Anomaly Transformer 모델을 학습하며, MLflow를 통해 하이퍼파라미터, 메트릭, 아티팩트를 실시간으로 추적한다. 학습 완료 후 예측 결과와 성능 지표를 Snowflake Layer 3에 저장(Load Task)하고, 학습된 모델은 AWS S3 object storage에 버전 관리하여 저장한다(Model Save). MLflow UI와 Optuna를 통해 실험 비교, 하이퍼파라미터 튜닝 이력, 성능 시각화를 제공하여 모델 개선 및 재현성을 보장한다.

※ MLFlow: 머신러닝 / 딥러닝 실험 진행을 기록하기 위한 실험 관리 플랫폼

※ Optuna: 파이썬 기반의 하이퍼파라미터 최적화 (hyperparameter optimization) 프레임워크

대시보드

대시보드는 ML 엔지니어와 현장 배터리 실험 엔지니어의 데이터 기반 의사결정 니즈를 충족시키는 것을 목표로 설계했다.

첫번째 화면의 가장 상단에서는 모델과 데이터셋 별 주요 실험 결과를 확인할 수 있다. 또한 배터리 셀 별 실험 결과도 드롭박스로 변경해가며 실험 결과를 비교할 수 있다.

Overview Tab

오버뷰 탭에서는 사이클 변화에 따라 주요 데이터들의 용량, 온도, 전압, 전류 변화를 한 눈에 확인할 수 있다. 이를 통해 사용자는 배터리의 전반적인 건강 상태와 열화 진행 추이를 직관적으로 파악하고, 주요 변수 간 상호작용을 신속하게 모니터링할 수 있다.

Anomaly Scores

Anomaly Score Analysis 탭에서는 사이클별 이상 점수 추이를 시계열 그래프로 확인할 수 있으며, threshold(빨간 점선)를 초과하는 Top 5 이상 사이클이 빨간 점으로 강조 표시된다.
하단의 Top 5 Anomalous Cycles 섹션에서는 이상 점수가 높은 사이클을 랭킹 순으로 나열하고, 각 사이클의 Warning 수준과 정확한 이상 점수를 수평 바 차트로 시각화한다.
사용자는 각 이상 사이클 옆 체크박스를 통해 조치 완료 여부를 기록할 수 있어, 배터리 관리자가 실시간으로 이상 사이클에 대한 대응 현황을 추적하고 관리할 수 있다.

Feature Importance

Feature Importance 탭에서는 SHAP(SHapley Additive exPlanations)을 활용하여 LOF 모델의 예측에 각 feature가 미치는 영향을 정량적으로 분석한다.

상단에는 가장 중요한 feature(Current_load_residual)와 그 중요도 점수(4.4045)가 표시되며, Feature Contribution 섹션에서는 전체 feature의 중요도를 수평 막대 차트로 시각화하여 상대적 기여도를 비교할 수 있다. 사용자는 Top N Features 드롭다운으로 표시할 feature 개수를 조정 가능하다.

SHAP Value Analysis에서는 각 feature의 값(Feature Value)에 따른 SHAP value를 산점도로 표현하여, feature 값의 변화가 이상 탐지에 미치는 영향의 방향성과 크기를 직관적으로 파악할 수 있다.

주요 Feature 설명 섹션에서는 각 변수의 의미(_trend: LOWESS 추세, _smooth: 이동평균, _residual: 잔차)를 제공하여, 도메인 지식이 없는 사용자도 feature의 물리적 의미를 이해하고 모델 판단 근거를 해석할 수 있다

Health Indicator

Health Indicator 탭에서는 배터리 건강 지표의 변동성을 통해 열화 진행 상태를 분석한다. Statistical Summary에서는 안정 임계값(Stable Threshold), 초기 구간 변동성(Early Phase HI Volatility), 후기 구간 변동성(Late Phase HI Volatility)을 정량적으로 제시한다. 초기 대비 후기의 변동성이 감소하는 것은 열화가 진행되면서 배터리 거동이 상대적으로 안정화됨을 의미한다.

Variability Analysis에서는 세 가지 지표를 시각화한다

HI_ema(파란선): 지수이동평균 기반 건강 지표의 전체 추세
HI Absolute Change(보라색): 사이클 간 절대 변화량으로 급격한 변동 구간 파악
HI Slope Volatility(오렌지): 기울기 변동성으로 추세 변화의 불안정성 측정 Threshold(점선)를 초과하는 구간에서 이상 징후를 조기 경고하며, Test/Event 구분선을 통해 특정 시점의 배터리 상태 변화를 추적할 수 있다.

Correlation Tab

Correlation Analysis 탭에서는 이상 점수와 물리적 열화 지표 간의 상관관계를 통해 모델 검증을 수행한다.
상단 산점도는 Anomaly Score와 Capacity(Pearson r=-0.947), R_ohmic(Pearson r=0.937)의 강한 상관관계를 보여준다. Capacity와의 강한 음의 상관관계는 용량 감소 시 이상 점수가 증가함을 의미하고, R_ohmic과의 강한 양의 상관관계는 저항 증가 시 이상 점수가 동반 상승함을 나타낸다.

하단 시계열 그래프는 사이클 진행에 따른 Anomaly Score와 물리적 지표의 동시 변화를 시각화하여, 이상 탐지 결과가 실제 배터리 열화 패턴과 일치하는지 검증한다. 이는 Ground Truth Label이 없는 비지도 학습 환경에서 물리적 degradation signal을 통한 교차 검증(Cross-modal Validation)을 수행하는 것이다.

배운 점

팀장으로서 1달 반의 기간 동안 프로젝트를 리드하며 상당히 많은 것을 배웠다.

팀장은 실무로 바쁘면 안된다. 일을 많이 하기 보다 프로젝트가 제대로 된 방향으로 흘러가는지, 팀원 간 의사소통에 오해는 없는지를 수시로 확인하는 것이 더 중요하다. 이번 프로젝트의 경우 내가 짊어진 부분이 많아 프로젝트 관리에 생각보다 많은 공수를 투자하기 현실적으로 어려웠다. 하지만 다음 프로젝트에서는 이런 점을 반영하여 좀 더 원활한 프로젝트 관리를 할 것이다.
새로운 기술을 가장 빨리 배우는 법은 에러를 마주하는 것이다. 사전에 디버깅을 꼼꼼히 해서 에러가 발생하지 않는다면 더할 나위 없이 좋겠지만, 우선 실행하고 그 속에서 새빨간 에러를 해결하는 것이 프로젝트 일정도 준수하면서 기술 공부도 가능하게 한다. 완벽보다는 완성을 추구하자.
코드는 리팩토링과 모듈화가 생명이다. 처음에는 귀찮고, 코드를 짜지도 않았는데 어떤 걸 리팩토링 할지 감도 안온다. 하지만 어느 정도 구상은 해야 한다. 일례로 streamlit 대시보드를 만들 때, 전체 코드를 하나의 파이썬 파일에 적었다. 이런 방식으로 하니 디버깅할 때 굉장히 머리가 아팠다. Streamlit의 경우 앞쪽의 tab이 뒤쪽의 tab에 영향을 미치기 때문에 디버깅하기 까다로웠다. 다시 처음으로 돌아가 tab들과 dataloader를 전부 쪼개기 시작했다. 그 이후로는 에러도 거의 발생하지 않을 뿐더러 에러 메세지를 통해 어느 tab에서 에러가 발생하는지 한 눈에 확인할 수 있었다.
하드코딩 하지 말자. 하드 코딩을 하면 처음에만 편하고 추후에 디버깅을 하거나 실험 조건들을 변경할 때 많이 귀찮아진다. 파일 경로, threshold 값, 하이퍼파라미터 등을 코드에 직접 작성하면 배터리 셀을 변경하거나 모델을 재학습할 때마다 여러 파일을 수정해야 한다. 대신 config 파일이나 환경변수로 분리하면 실험 조건 변경이 간편하고 재사용성과 유지보수성이 높아진다. 특히 MLOps 파이프라인에서는 DAG 파라미터화를 통해 동일한 코드로 다양한 실험을 자동화할 수 있다.
갈등 관리 시 가장 중요한 점은 경청이다. 가장 어려운 건 소프트스킬이다. 이번 프로젝트에서는 기술적 구현 못지않게 팀원 간 갈등 관리에 집중했다. AI 도구와 튜터의 도움으로 기술적 허들을 넘는 법을 배웠으나, 동시에 가장 어려운 과제는 팀원 간의 의견 조율임을 체감했다. 소프트스킬은 온전히 인간의 몫이기에 팀원들 간 분쟁이나 언쟁이 생겼을 때 어떻게 조율해야 할지 많이 고민했다. 갈등 관리 시 가장 중요한 점은 경청이다. 상대의 불만을 정확히 파악하는 것이 프로젝트의 지연을 막고 최종 목표를 향해 원팀으로 나아가는 가장 빠른 길임을 배울 수 있었다. ML 엔지니어와 MLOps 직무는 협업이 필수적이기에 다양한 이해관계자와 협업이 필수적이다.

Battery prognostics and health management from a machine learning perspective

월요일zoa — Thu, 20 Nov 2025 12:56:48 +0900

안녕하세요.

다변량 배터리 충방전 시계열 데이터 분석을 진행하기 앞서 머신러닝 관점에서 배터리 PHM을 진행한 연구를 리뷰한 survey 논문을 정리해 보았습니다. survey 논문에서 프로젝트와 관련된 부분만 정리하였으니 이외의 내용은 논문을 참고하시기 바랍니다.

PHM이란 운용 유지 단계에서 센서를 이용하여 장비나 기계시스템의 상태를 모니터링하고, 고장 징후를 진단(diagnostic)과 잔여유효수명(RUL)을 예지(prognostic)하는 효과적인 건정성 기술을 의미합니다.

Abstract

전기 배터리는 여러 이점을 바탕으로 다양한 분야에서 활용되고 있다. 다양한 이점에도 불구하고, 배터리의 수명을 단축시키는 열화 문제는 여전히 도전 과제로 남아 있다. 열화 문제를 해결하기 위해 전통적인 물리, 분자적 접근법을 활용하여 연구하고 있지만 이러한 모델들은 높은 컴퓨팅 비용과 불확실성으로 인해 내재된 문제점들을 충분히 포착하고 있지 못한다.

최근 들어, 머신러닝 모델 기반의 접근이 주목 받고 있다. 이러한 접근법은 복잡한 데이터 구조로 부터 패턴과 시공간적 특징 포착한다. 특히, 물리적 과정과 딥러닝의 유연성을 결합한 하이브리드 모델링 전략이 큰 연구 성과를 거두었다. 따라서, 본 논문에서는 배터리 PHM을 DNN과 커널 기반 회귀 네트워크를 중점으로 설명한다.

Introduction

배터리 열화로 인한 성능 저하는 운전 거리 감소, 잔여 용량 예측의 부정확성 등과 같이 배터리 시스템 전반에 걸쳐 부정적인 영향을 미친다. 열와 원리는 두 가지 주요 카테고리로 나눌 수 있다. 첫째, 물리적 원리(열 및 기계적 스트레스). 둘째, 화학적 원리(전기화학적 부작용).

열화 문제를 해결하기 위해 data-driven 방법을 사용할 수 있다. data-driven 방법은 여러 장점을 제공한다. 화학적 특정에 구애 받지 않고, 모델링할 수 있는 능력, 시스템 고유의 복잡성을 해결하는 능력, 그리고 관측된 데이터를 설명할 뿐만 아니라 복잡한 조건에서도 주석이 달리지 않은 샘플에 대해 예측을 수행할 수 있는 능력을 포함한다. 최근 AI의 한 분야인 머신러닝은 배터리 분석 분야에서 지속적인 혁신을 위한 새로운 지평을 열고 있다.

최근 연구에서는 LSTM, RNN과 같은 시계열 모델들이 State of Charge 리튬 이온 배터리 라이프 사이틀 예측에서 유의미한 성과를 얻고 있다. 강화된 feedforward-lstm이나 anti-noise adpative lstm과 같은 방법론들이 배터리 안정성과 RUL 예측 분야에서 후속 연구에 활용되고 있다.

배터리 PHM

머신러닝 기반의 배터리 PHM 시스템 연구

data-driven 연구에서 머신러닝 기반의 PHM 연구는 다중 스케일과 다중 물리 배터리 시스템의 본질적인 복잡성을 해결하고, 학계와 산업계 간의 기술 이전을 가속화하는 대안적인 방법으로 부상하고 있다. 이러한 머신러닝 기반 배터리 PHM은 광범위한 기술과 역량에 걸친 지속적인 협력을 필요로 한다.

이러한 기술들은 물리 시스템이 확장된 시공간적 규모 속에서 탐지 또는 분류에 필요한 데이터 표현을 포착한다. 머신러닝 방법론들은 불확실성을 표현하고 관리하는 강력한 프레임워크를 제공한다.

PCA와 클러스터링

PCA의 목표는 중복 정보를 제공하고 계산 비용을 절감하여 배터리 시스템의 수명을 예측하는 것이다. 이러한 관점에서 grey relational analysis는 건강 특성과 용량의 연관성을 분석하는 도구를 제공한다. 실제 응용 분야에서는 수백 또는 수천 개의 셀이 직렬/병렬 구조로 연결된다. 이 때, PCA와 같은 비지도 학습이 일관성 평가 및 이상탐지를 위한 강력한 방법론으로 사용된다.

일반화 성능 증가를 위한 물리 정보 기반의 머신러닝

순수 데이터 기반 모델은 관측치에 잘 부합할 수 있지만, 낮은 일반화 성능을 초래할 수 있다. 따라서 사전 정보나 강력한 이론적 제약을 제공할 수 잇는 물리 규칙을 머신러닝 모델에 부여하여 근본적인 물리 법칙과 도메인 지식을 결합하는 것이 중요하다. 물리 정보 기반 머신러닝은 결측치 또는 노이즈가 있는 데이터 환경에서도 강건하며, 일반화 작업에서도 정확하고 물리적으로 일관된 예측을 제공할 수 있는 보다 해석 가능한 머신러닝 방법론을 만드는데 기여한다.

최근 NASA ARC 연구원들은 무인 항공기 배터리 모델링 및 예지(prognosis)를 위해 신경망 내부에 네른스트 및 버틀러-볼머 방정식을 구현하여 하이브리드 모델링 접근 방식[1]을 확립했다. 또한 NASA PRoE에서 제공하는 공개 실험 데이터를 사용해서 배터리 SOH 예지를 위한 다중 충실도 모델을 갖춘 물리 정보 기반 머신러닝[2]이 개발되었다. 또한, 나사 공개 실험 데이터로 RUL을 예측하기 위해 물리 정보 기반 LSTM과 물리 기반 캘린더 및 사이클 노화 모델을 결합하는 것을 제안했다. 물리 정보 기반 머신러닝의 최근 발전이 RUL 예측에 사용되는 초기 예측 모델의 성능을 크게 향상시키고 있다.

장기 시계열 예측을 위한 attention 기반 transformer

트랜스포머 모델의 핵심 구성 요소는 셀프 어텐션 매커니즘, positional encoding, 그리고 한 개 이상의 encoder/decoder 구조가 있다. 최근 여러 연구들은 자기지도학습 프레임워크를 사용하는 트랜스포머 모델이 동적인 충방전 주기 하에서도 배터리 상태를 정확하게 예측할 수 있음을 보여줬다.

본 survey 논문의 저자도 다중 물리 배터리 시스템에 필수적인 symplectic 구조를 보전하도록 설계된 듀얼 인코더 기반 아키텍처를 설계했고, 후속 연구에서는 적응형 슬라이딩 윈도우를 갖춘 특수 트랜스포머 모델을 통합했다.

트랜스포머 모델은 데이터에 상당한 노이즈가 존재하더라도 배터리 RUL을 예측하도록 구축될 수 있다. denoising auto-encoder는 손실 함수 재구성을 통해 노이즈가 있는 입력으로부터 강건한 표현을 학습할 수 있다.

더욱 흥미로운 점은 CNN과 트랜스포머를 결합함으로써, 정확도를 향상시켜 다중물리 배터리 애플리케이션에서 실시간으로 정확한 예측을 달성하는 것이 가능하다는 것이다. 특히, CNN은 local information을 추출하는 도구를 제공하고, self-attetion transformer는 global representation을 포착할 수 있다.

추후 연구 방향

강건함과 일반화 성능

배터리 건강 예측 작업에서 순수 데이터 기반의 머신러닝 모델은 사전 지식과 물리 규칙 부재로 인해 낮은 일반화 성능을 보일 수 있다. 모델에서 관측되지 않은 데이터에 대한 예측을 할 때, 불확실성이 근본적인 문제로 작용할 수 있다. 반면에 수학, 물리, 공학 과학에서 얻은 사전 지식으로 예측 정확도를 높일 수 있다. 따라서 물리와 머신러닝 모델을 결합하면 강건성과 일반화 성능이 향상될 뿐만 아니라, 모델의 신뢰성과 일관성까지 고려할 수 있다. 더 나아가, 비지도 사전학습은 작은 데이터에 대한 과적합을 줄이는데 도움이 되고, 전이 상황에서 일반화 성능을 높이는데 도움이 된다.

해석 가능한 머신러닝

재료 과학 응용 분야에서 배터리 연구를 위한 표준 성능 지표, 정형화된 예측 모델 및 설명 가능한 프레임워크의 부족은 딥러닝과 같은 머신러닝 기술을 셀 동작의 근간이 되는 재료, 특성 및 메커니즘과 연결하는 잠재력을 제한한다. 물리 지식을 머신러닝에 통합하는 것이 불확실성(노이즈 데이터)을 보다 효과적으로 관리할 수 있다.

결론

강화학습을 통한 지능형 배터리 건정성 관리, 물리 정보 기반 머신러닝, 어텐션 기반 트랜스포머, 전이 학습, 공개 데이터가 배터리 PHM 분야 발전에 핵심적이다.

물리 정보 기반 머신러닝 모델은 더욱 신뢰할 수 있는 모델을 만드는데 도움이 된다. 또한, 어텐션 기반 트랜스포머 모델은 시계열 데이터에서 장기 의존성을 포착하는 데 탁월한 능력을 보여주기 때문에, 배터리 열화 과정을 정확하게 모델링하는데 매우 중요하다.

나의 생각

1. RUL 예측에서는 feature extraction이 핵심이다. 용량 열화 분석과 높은 상관관계를 가진 변수를 추출한 뒤에 고차원 입력 값으로 사용해야 좋은 결과를 얻을 수 있기 때문이다.

- 그렇다면 배터리 이상탐지에서도 도메인 지식으로 feature를 추출하는게 중요하지 않을까?

- grey relational analysis같은 통계적 feature extraction으로 AutoEncoder 혹은 Transformer 같은 이상탐지 모델을 고도화할 수 있지 않을까?

2. 물리 정보 기반 머신러닝이 강건함에서 강점을 보이니 통계적 방법으로 새로운 feature를 추가하는 것도 강건함 증가에 많은 도움이 될 것이다.

3. 강건함을 높일 수 있는 도메인 지식 + 성능과 해석 가능성을 높일 수 있는 Transformer

4. GNN을 사용하는 것도 해석 가능성을 높일 수 있는 차별점이 될 수 있다.

참고자료

[1] R.G. Nascimento, M. Corbetta, C.S. Kulkarni, F.A. Viana, Hybrid physics-informed neural networks for lithium-ion battery modeling and prognosis, J. Power Sources 513 (2021), 230526

[2] S. Kohtz, Y. Xu, Z. Zheng, P. Wang, Physics-informed machine learning model for battery state of health prognostics using partial charging segments, Mech. Syst. Signal Process. 172 (2022), 109002.

데이터 사이언스 기술 면접 스터디 12회차

월요일zoa — Fri, 31 Oct 2025 18:47:51 +0900

50개의 작은 의사결정 나무는 큰 의사결정 나무보다 괜찮을까요? 왜 그렇게 생각하나요?

100개의 의사결정 나무가 더 좋은 결과를 만들 확률이 높다. 개별 의사결정 나무는 분산이 높기 때문에 과적합 가능성이 높고, 고차원 학습 데이터를 깊이 있게 학습하지 못한다. 100개의 의사결정 나무가 모인다면 분산을 줄이고, 과적합 가능성을 크게 낮춰 더 안정적인 예측이 가능하다.

앙상블 방법에는 어떤 것들이 있나요?

Bagging (Bootstrap Aggregating)

Bagging

원본 학습 데이터에서 여러 데이터셋을 복원(Bootstrap) 추출로 만든 후 각각의 데이터셋을 동일한 모델에게 학습시켜, 모델의 결과를 평균 내거나 다수의 결과로 최종 결과를 선정하는 방법이다.

원본 데이터셋을 다양한 측면에서 학습할 수 있기 때문에 분산을 줄여 과적합을 낮추는데 효과적인 방법이다.

대표 모델
- RandomForest

Boosting

모델을 순차적으로 학습시켜 최종적으로 강력한 예측 모델을 만드는 방법이다. 처음에는 모든 데이터에 동일한 가중치로 모델을 학습시키지만, 이전 모델이 틀린 데이터에 더 높은 가중치를 주는 방식으로 오차를 줄여나간다. 주로 편향을 감소시키고 예측 성능을 극대화한다.

대표 모델
- XGBoost
- GBM
- LGBM
- AdaBoost

Stacking

여러 개의 개별 모델이 출력한 결과를 입력 값으로 새롭게 사용하여 모델의 성능을 높이는 방법이다. 개별 모델이 학습한 결과를 모은 모델을 Meta 모델이라 하고, 여기에 시험 데이터로 모델의 성능을 평가한다. 이전 학습의 결과를 다시 입력값으로 사용하기 때문에 과적합에 유의해야 한다.

Voting

Linear Regression, Decision Tree 와 같이 여러 모델들의 결과 값을 평균이나 다수결로 최종 값을 예측하는 방법이다. 다른 방법들에 비해 비교적 단순하기 때문에 성능이 상대적으로 낮게 나올 확률이 높다.

앙상블 모델의 장점

높은 정확도: 여러 모델들을 결합해서 사용하기 때문에 하나의 모델을 사용하는 것보다 데이터의 패턴을 더 다양한 관점에서 학습할 수 있다.
강건함: 여러 모델의 결과 값을 종합해서 최종 결과 값을 도출하기 때문에 하나의 모델을 사용하는 것보다 특정 데이터에 크게 의존하는 가능성을 줄일 수 있다.
과적합 방지: 높은 분산을 가진 의사결정 나무와 같은 모델의 분산을 평균 내거나 투표하는 방식으로 줄일 수 있다.
확장 가능성: 앙상블 모델은 분류나 회귀처럼 여러 task에 활용되기 적합하다.

참고자료

https://datasciencedojo.com/blog/ensemble-methods-in-machine-learning/

XGBoost 모델을 아시나요? 왜 캐글에서 유명할까요?

XGBoost(eXtreme Gradient Boosting)는 경사하강법을 활용하는 지도 학습 부스팅 알고리즘인 그레이디언트 부스트 Decision Trees를 사용하는 분산형 오픈 소스 머신 러닝 라이브러리이다. 속도, 효율성, 대규모 데이터 세트에 대한 확장성이 뛰어난 것으로 잘 알려져 있다.

XGBoost

먼저 Gradient Boosting은 기본 의사결정 나무를 생성한다. 이후에 기존 모델의 실수를 바탕으로 residual을 줄이는 방향으로 새로운 트리를 생성해가며 모델의 성능을 점점 개선한다. 이때, 잔차를 집계하여 손실함수(경사하강법)를 사용하여 모델에 점수를 매긴다.

XGBoost의 기능

병렬 및 분산 컴퓨팅
- 라이브러리는 블록이라는 인메모리 단위로 데이터를 저장한다. 개별 블록을 여러 컴퓨터에 분산하거나 아웃오브코어 컴퓨팅을 사용하여 외부 메모리에 저장할 수 있다. 또한 XGBoost는 계산 속도를 높이기 위해 여러 컴퓨터 클러스터에 분산된 학습과 같은 고급 사용 사례도 지원한다. Apache Spark, Dask 또는 Kubernetes와 같은 툴을 사용하여 분산 모드로 구현할 수도 있다.
캐시 인식 사전 페칭 알고리즘
- XGBoost는 대규모 데이터 세트의 런타임을 줄이는 데 도움이 되는 캐시 인식 사전 페칭 알고리즘을 사용한다. 라이브러리는 단일 시스템에서 다른 기존 프레임워크보다 10배 이상 빠르게 실행할 수 있다. 인상적인 속도 덕분에 XGBoost는 더 적은 리소스를 사용하여 수십억 개의 예제를 처리할 수 있으므로 확장 가능한 트리 부스팅 시스템이 된다.
정규화 기능 내장
- 일반 그레이디언트 부스팅과 달리 XGBoost는 학습 목표의 일부로 정규화를 포함한다. 하이퍼 파라미터 튜닝을 통해 데이터를 정규화할 수도 있다. XGBoost에 내장된 정규화를 사용하면 라이브러리가 일반 사이킷런(scikit-learn) 그레이디언트 부스팅 패키지보다 더 나은 결과를 제공할 수 있다.
- 또한, 트리 기반 모델이기 때문에 정규화를 필수적으로 요구하지 않는다.
자동 결측치 처리
- XGBoost는 희소 데이터에 희소성 인식 알고리즘을 사용한다. 데이터 세트에 값이 누락된 경우 데이터 포인트는 기본 방향으로 분류되고 알고리즘은 누락된 값을 처리하기 위한 최적의 방향을 학습한다.

캐글에서 유명한 이유

캐글에서 유명한 이유는 위 XGBoost의 기능 때문이다. 대규모 데이터에 대한 빠른 학습, 분산형 컴퓨팅을 통한 안정적인 학습, 자동 전처리 등 다양한 기능을 편리하게 제공하기 때문에 프로그래밍에 미숙한 데이터 과학자도 쉽게 대규모 데이터를 분석할 수 있다.

참고 자료

https://www.geeksforgeeks.org/machine-learning/implementation-of-xgboost-extreme-gradient-boosting/

https://www.nvidia.com/ko-kr/glossary/xgboost/

https://www.ibm.com/kr-ko/think/topics/xgboost

데이터 사이언스 기술 면접 스터디 11회차

월요일zoa — Wed, 29 Oct 2025 19:56:20 +0900

회귀/분류 시 알맞은 metric은 무엇일까요?

회귀

MAE(Mean Absolute Error)
- 예측값과 실제값의 차이를 절대값으로 변환하여 평균한 값이다. 오차의 크기를 직관적으로 파악하기 용이하다.

MAE

MSE(Mean Squared Error)
- 예측값과 실제값 차이를 제곱하여 평균한 값이다. 오차에 제곱을 취하기 때문에, 큰 오차에 더 큰 패널티를 부여한다. 따라서, 이상치에 민감한 모습을 보인다.

MSE

RMSE(Root Mean Squared Error)
- MSE에 루트를 씌운 것으로 MSE와 마찬가지로 이상치에 민감하지만 루트로 인해 값이 작아져 해석에 용이하다.

R-sqaure
- 회귀 모델의 설명력을 나타내는 것으로 0 ~ 1 사이의 값을 가진다. 1에 가까울 수록 설명력이 높다고 해석한다.

데이터 사이언스 기술 면접 스터디 10회차

월요일zoa — Wed, 1 Oct 2025 16:19:14 +0900

고유값(eigenvalue)과 고유벡터(eigenvector)에 대해 설명해주세요. 그리고 왜 중요할까요?

기본 개념

정방행렬 A에 대해 Ax = $\lambda$x (상수 $\lambda$가 성립하는 0이 아닌 벡터 x가 존재할 때, 상수 $\lambda$를 행렬 A의 고유값(eigenvalue), x를 이에 대응하는 고유벡터 (eigenvector)라고 한다.

쉽게 말해서, 고유벡터는 방향이 변하지 않는 선, 고유 값은 선이 줄어들고 늘어나는 비율이다. 보통의 벡터는 값에 변화를 주면 길이가 달라지게 되지만 고유벡터는 방향이 절대 변하지 않는다. 이처럼, 선의 형태는 그대로 유지하면서 길이가 늘어나고 줄어드는 것을 선형 변환이라고 한다. 참고로 Eigen은 독일어로 '전형적인', '고유의' 라는 뜻을 가진 말이다.

고유값과 고유벡터는 선형대수의 근본적인 개념으로 PCA와 같은 차원축소 기법에서 활용된다.

Eigen value와 Eigen Vector

$A\vec{x}$와 $\lambda\vec{x}$이 평행하기 때문에 $A\vec{x}$ 의 실수 배로 표현할 수 있다.

정의

주의사항

0 벡터는 고유벡터로 보지 않는다.
무수히 많은 고유 벡터가 존재한다.

선형 변환

계산 방법

고유값 ($\lambda$)를 찾는 방법: $det(A - \lambda I) = 0$

A: 어떤 물체에 가해지는 '변화'를 나타내는 행렬
I: 항등행렬. 숫자 1과 같은 행렬로 어떤 행렬에 곱해도 행렬 그 자체가 변하지 않는 행렬이다.
det(): 행렬식으로 행렬이 변화시키는 만큼을 숫자로 나타낸 것. det()가 0이라면 원래의 변화 A에서 어떤 특별한 비율 $\lambda$의 변화를 뺐더니, 특정 방향으로의 모든 변화가 0이 되어 사라져 버리는 특별한 비율을 찾는 것이다.
쉽게 말해서 A와 같은 $\lambda$를 찾는 것이다.

고유벡터(v)를 찾는 방법: $(A - \lambda I)v$ = 0

위에서 고유값을 찾았다면 위 식에 고유값을 넣어준다.

v: 우리가 찾고 싶은 고유 벡터이다.
$(A - \lambda I)$ = 0: "위에서 찾은 특별한 $\lambda$ 값을 이용하여$(A - \lambda I)$라는 변화를 주었을 때, 사라져서 0이 되어버리는 벡터 v가 무엇인가?"를 묻는 식이다.
즉, 고유값이 정해졌으니, 그 $\lambda$에 해당하는 '특별한 방향(v)'이 어떤 것인지 식을 풀어서 찾아내는 것이다.

중요한 이유

고유값과 고유벡터는 데이터의 주요 정보가 어느 방향으로 가장 크게 퍼져 있는지를 알려주기 때문에 매우 중요하다. 이는 데이터를 효율적으로 간략화하는 차원 축소 과정에서 핵심적인 역할을 하며, 특히 대표적인 차원 축소 알고리즘인 주성분 분석(PCA)의 기본 원리가 된다.

데이터의 주요 방향 찾기: 고유벡터는 데이터가 가장 크게 흩어져 있는 방향, 즉 데이터의 분산이 큰 방향을 알려준다.
중요한 정보만 남기기: 고유값이 클수록 그 방향(고유벡터)로 데이터가 많이 흩어져 있다는 뜻이고, 그 만큼 중요한 정보가 많다는 것을 의미한다. 따라서 우리는 고유값이 큰 일부 고유벡터만 선별해서 줄일 수 있다.
결과적으로, 여러 feature들을 결합해서 핵심 성분만 남기게 된다.

차원을 줄이면 좋은 점

모델이 더 빠르게 연산하고, 메모리 사용량을 줄일 수 있다.
데이터의 핵심 표현을 효과적으로 학습할 수 있다.

참고자료

https://www.youtube.com/watch?v=PFDu9oVAE-g

https://rfriend.tistory.com/181

https://www.geeksforgeeks.org/engineering-mathematics/eigen-values/

https://www.youtube.com/watch?v=xDARfmKauuA

https://www.samsungsds.com/kr/insights/mathematics_for_ml.html