GitOps로 계약 배포 + Airflow 버전화/Latest 저장 + Feast 조회까지 E2E 증명

🧭 목차

이 글은 설명이 아니라 증거(Proof)만 남깁니다.

각 섹션은

캡처 → 확인 포인트 → 결론 구조로 고정되어 있으며,

독자가 캡처만 봐도 시스템 상태를 판단할 수 있도록 구성했습니다.

A. GitOps & Dev/Prod 분리

A-1) ArgoCD Applications 상태 증명

📸 proof-fs-01-argocd-applications.png

• ArgoCD Applications 화면에서

  feature-store-dev, feature-store-prod

  (및 Feast 관련 Application) 확인

• Status: Synced / Healthy

확인 포인트

• dev/prod가 서로 다른 Application으로 존재
• Git 변경이 없을 때 idempotent 상태 유지
• namespace 기준으로 운영 경계가 명확

👉 결론

Feature Store 구성은 GitOps 기준으로 dev/prod가 완전히 분리되어 있으며,

의도하지 않은 변경 없이 Synced/Healthy 상태가 유지됨이 확인됩니다.

B. Contract(계약) 운영 리소스화 & 마운트 검증

B-1) Feature Schema / Metadata 계약 배포 증명

📸 proof-fs-02-01-configmap-schema.png

• ConfigMap: feature-store-resources
• 포함 파일:
  • user_features.schema.json
  • metadata.json.j2

확인 포인트

• 계약이 코드가 아니라 **운영 리소스(ConfigMap)**로 배포됨
• dev/prod에 동일한 계약이 적용됨

👉 결론

Feature 계약은 GitOps로 관리되며,

파이프라인 코드는 계약을 읽기만 하는 구조로 고정됩니다.

B-2) Airflow Pod 계약 마운트 증명

📸 proof-fs-02-02-airflow-mount.png

• Airflow Pod 내부에서 파일 확인:
  • /opt/airflow/feature-store/user_features.schema.json
  • /opt/airflow/feature-store/metadata.json.j2

확인 포인트

• mountPath가 표준화되어 있음
• dev/prod 실행 환경이 동일하게 재현 가능

👉 결론

Airflow는 GitOps로 배포된 계약을

동일한 경로로 마운트받아 실행 조건이 고정됩니다.

B-3) Feast Repo 계약(subPath) 마운트 증명

📸 proof-fs-02-03-feast-subpath.png

• ConfigMap: feast-repo
• subPath로 파일 단위 마운트:
  • /feast-repo/feature_store.yaml
  • /feast-repo/repo.py

확인 포인트

• ConfigMap 전체 mount 시 발생하는 파일 구조 이슈 차단
• Feast repo 자체가 운영 계약으로 안정적으로 고정

👉 결론

Feast 계약(repo)은 GitOps + subPath 마운트 방식으로

운영 중 변형되지 않는 형태로 표준화됩니다.

C. Airflow 파이프라인 E2E 검증

C-1) DAG Graph View 성공 증명

📸 proof-fs-03-01-airflow-dag-graph.png

• DAG: data_pipeline_daily_dev_v4 (또는 v5)

• Task 흐름:

  extract_raw_data → validate_data → build_features → store_features → summarize_run

확인 포인트

• DAG는 연결만 담당
• 실제 로직은 mlops_lib/dp/*로 분리
• 마지막 task에서 prefix / version / uri가 남음

👉 결론

계약 기반 Feature Store 파이프라인이 E2E로 실행되어 산출물이 저장됨이 증명됩니다.

DAG는 흐름만 정의하며, Feature 생성 로직은 코드 레벨에서 재사용·테스트 가능하도록 분리되었습니다.

D. S3 저장 정책 증명 (Version + Latest)

D-1) Version prefix 생성 증명

📸 proof-fs-04-01-s3-version-prefix.png

• 생성 규칙:
  • s3://<feature_base>/<feature_set>/v_YYYYMMDDTHHMMSS/
• 동일 prefix에:
  • features.csv
  • schema.json
  • metadata.json

👉 결론

버전은 depth가 아니라 **운영 표준(1단)**으로 고정되어

재현성을 보장합니다.

D-2) Version + Latest 동시 유지 증명

📸 proof-fs-04-02-s3-version-latest.png

• version 유지:
  • .../<feature_set>/v_YYYY.../
• latest overwrite:
  • .../<feature_set>/latest/
• 동일 구조로:
  • features.parquet
  • features.csv
  • schema.json
  • metadata.json

👉 결론

재현성(version)과 운영 편의(latest)가 동시에 충족되어,

하위 시스템은 latest 기준으로 단순하게 소비할 수 있습니다.

E. 재현성(Operational Reproducibility) 증명

E-1) metadata.json 기록 증명

📸 proof-fs-05-01-metadata-json.png

• metadata.json 필드:
  • schema_hash
  • generated_at
  • feature_uri
  • source
  • pipeline

👉 결론

“오늘 만든 feature.csv”가 아니라,

언제 / 무슨 계약으로 / 어떤 소스에서 생성됐는지가

시스템이 해석 가능한 형태로 남습니다.

F. Feast 운영 검증

F-1) s3fs 포함 이미지 증명

📸 proof-fs-06-01-feast-s3fs-version.png

• Feast 서버에서 s3fs version: 2026.1.0 출력

👉 결론

Feast 서버는

S3 parquet 접근을 위한 필수 의존성을 포함한 상태로 운영됩니다.

F-2) materialize 성공 증명

📸 proof-fs-06-02-feast-materialize.png

• 로그:
  • Materializing 1 feature views
  • into the redis online store

👉 결론

Offline(S3 parquet) → Online(Redis) 적재가

실제로 동작함이 확인됩니다.

F-3) online(redis) 조회 성공 증명

📸 proof-fs-06-03-feast-online-query.png

👉 결론

Feature Store는 “저장”에서 끝나지 않고,

학습·서빙에서 동일한 Feature 정의를 사용하는 조회 가능한 피처 플랫폼으로 완성되었습니다.

🏁 정리

• GitOps로 dev/prod가 분리 배포되고
• Feature 계약이 운영 리소스로 고정되어 파이프라인은 읽기만 하며
• Airflow 파이프라인은 E2E로 실행되어 S3에 버전화 산출물이 저장되고
• Version + Latest 정책으로 소비 계층이 단순화되며
• Feast를 통해 offline/online 조회가 실제로 동작함이 증명되었습니다.

이 검증을 통해 Feature Store 시리즈는

설계 설명이 아닌, 운영 가능한 상태가 증명된 구현으로 완결됩니다.