데이터를 움직이는 힘: 데이터 거버넌스 & 엔지니어링 실전 강의 정리

status

Public

date

Dec 6, 2025

slug

data-engineering-practice-review

summary

모두의 연구소 [데이터를 움직이는 힘: 데이터 거버넌스 & 엔지니어링 실전] 강의 수강

type

Post

1. 제조 데이터 실무 흐름 이해

제조 데이터를 다루면서 왜 데이터 거버넌스가 필요한지 이유를 확인해본다.

데이터는 많은데 부정확

부서마다 정의가 달라 혼선 발생

자동화되지 않아 매번 수작업으로 처리

조직은 일반적으로 다음 단계로 성장하며 데이터를 처리한다.

우리가 최종적으로 데이터 기반 업무를 위해서는 다음 단계 중 4. 신뢰 기반 데이터 의사결정을 이루기 위해서다.

데이터 수집만 하는 단계

수집 + 품질 관리

자동화된 파이프라인 구축

신뢰 기반 데이터 의사결정

3 단계를 통해 데이터를 어떻게 처리할 것인지 정리해본다면,

데이터 거버넌스 구축: 어떤 기준으로 데이터를 수집할 것인지

표준화 → 정의 일치

품질 진단: 데이터의 품질 고도화 및 정제

품질 진단 → 오류 감소

클라우드 연계: 자동화된 데이터 파이프라인 구축

자동화 → 운영 비용 절감
활용 → 정확한 의사결정

제조 데이터의 특징으로는

물리적 시간 흐름 중심 (공정 중심)

정형 + 비정형 혼합 (CSV 부터 이미지까지)

통합 키 부족 (시리얼/LOT/설비 코드 등 제각각)

이는 내가 일반적으로 다뤄왔던 비즈니스 데이터와 이런 점이 다르다.

ㅤ	일반 비즈니스 데이터	제조 데이터
주제	고객, 판매, 거래 등	설비, 공정, 품질 등
특징	정형 중심	정형 + 비정형 혼합
시간성	이벤트 중심	실시간 연속
출처	1~2개 시스템	5개 이상 다양

데이터 거버넌스를 정확하게 수립하지 않는다면 데이터 수집을 잘 하더라도 제대로 활용하기 어렵다.

정의 기준이 정해지지 않거나 > 부서마다 다른 정의를 사용하게 됨

품질 기준이 일관되지 않거나 > 분석 데이터의 신뢰도가 낮음

데이터 흐름 설계 없이 수집부터 시작할 경우 > 자동화 파이프라인이 실패할 수 있음

데이터 거버넌스 vs. 데이터 엔지니어링

: 명확하게 다르다고는 볼 수 없지만, 기업 입장에서 관리 혹은 개발 주체를 누구로 두냐에 초점을 맞춤

ㅤ	데이터 거버넌스	데이터 엔지니어링
목적	기준 정의 및 품질 관리	기술적 처리 및 자동화
관점	정책 중심, 관리	구현 중심, 처리
주체	품질 담당자, 관리자	개발자, 데이터 엔지니어

2. 데이터 거버넌스 핵심 개념 및 프레임워크 설계

데이터 거버넌스를 자산으로 만들기 위해서는 다음 관리 체계가 필요하다.

정책 Policy

책임 Role

기준 Quality Rule

거버넌스 수립은 실패하기가 쉬운데, 다음 문제를 조직 문화적으로 해결하지 못해서다.

문서 작업으로만 간주

책임자와 승인 프로세스 없음

실제 운영과 분리되어 활용되지 않음

거버넌스 설계 시 고려해야 할 점은 다음과 같다.

사람 Role = 데이터 오너 / 작성자 / 승인자

데이터 오너쉽을 누가 가지는가?

단일 책임자 모델 → 책임 명확, 속도 빠름
분산 거버넌스 모델 → 협업 유리, 제조 적합

프로세스 Workflow = 정의 → 문서화 → 승인 → 배포 → 변경 관리

도구 Tool = Wiki.js, WorkDocs, Data Catalog

강의에서 추천해준 가좋은 기준 문서의 요건과 버전 관리 전략

단위 및 허용 오차

책임 부서 명시

최신성 유지

항목 정의

버전 관리 전략 (변경 이력 기록, 리뷰 & 승인 프로세스)

3. 데이터 품질 진단과 표준화 실습

데이터 품질 진단의 정의는 [분석 이전에 데이터가 쓸 수 있는 상태인지 판단하기 위함] 이다.

분석 가능한 데이터는 (즉 우리가 추구해야 하는 데이터의 모습은) …

분석 결과를 왜곡하지 않는 상태

품질 기준에 부합한 상태

결측/오류가 관리된 데이터

느낌이 그렇지~ 가 아니라 정확하게 어느 부분이 문제가 있는지 기준을 명확하게 해야 데이터를 놓치는 부분 없이 처리할 수 있다.

정확성: 값 자체가 잘못됨

완전성: Null/공백 문제

일관성: 단위/포맷이 혼용

유효성: 범위 제한 초과

중복성: 동일 키 중복

좋은 품질의 데이터는 …

기준에 맞는 데이터: 진단 과정을 매번 수작업으로 반복하지 않아도 됨

의심없이 분석 가능한 데이터: 사람의 개입 없이 흐름을 재현하고 기록하는 구조 필요

outdated 되지 않은 데이터: 매일 들어오는 데이터를 기준으로 판단

실습 학습

히스토그램 bin

히스토그램에서 데이터를 나누는 구간의 개수
가로축을 몇 등분 할 것인가? (== 막대 그래프를 몇 개 그릴 것인가?)
너무 적을 경우 데이터가 뭉뚱그려져서 세밀한 분포를 알기 어려움 <> 너무 많을 경우 막대가 너무 얇아지고, 중간중간 빈 곳이 생겨서 전체적인 흐름(패턴)을 파악하기 어려움

데이터 정규화 : Min-Max Normalization

모든 샘플의 온도 데이터를 0-1 사이의 비율로 변환하는 것

코드 역할: 상대적 패턴 만들기

normalize 함수 수식:

절대적인 온도 값을 무시하고 온도가 변하는 모양(패턴)에만 집중하기 위함

왜 하는지?

머신러닝 svm 모델의 성능을 높이는 단계

환경 변수 제거: 여름에 찍은 제품과 겨울에 찍은 제품은 정상 제품이라도 온도가 다름 → 정규화를 통해 계절이나 환경 온도에 상관없이 온도 분포 모양만 비교

학습 속도/성능 향상: 데이터의 스케일(범위)이 같아지면 머신러닝 모델이 훨씬 빠르고 정확하게 하급

Hyperparameter 혹은 Threshold

현장의 절대적인 spec 혹은 데이터를 보고 분석가가 정한 통계적인 기준

4. 데이터 파이프라인 자동화 실습

데이터 파이프라인의 자동화된 흐름: 데이터 수집 → 처리 → 저장

데이터 파이프라인의 구성 요소로는 크게 다음과 같다.

source 데이터 소스: 센서 로그, 운영DB, 파일, API

processing 처리: 전처리, 정제, 변환, 필터링

storage 저장

consumer 활용: BI 도구, 리포트

데이터 파이프라인을 자동화하는 오케스트레이션 도구로 Airflow를 추천한다.

다양한 작업 (task) 을 시간 기반, 의존성 기반으로 실행

복잡한 흐름을 코드로 정의하고 시각적으로 관리

반복되는 데이터 흐름을 사람 개입 없이 자동 운영

오픈소스 기반, 데이터 팀의 사실상 표준 도구

airflow 사용 이유

기존 방식	airflow 도입 시 개선점
작업 실패 추적 어려움	웹 ui + 로그 + 상태 추적 가능
작업 순서 수동 관리	DAG로 작업 간 의존성 명시
에러 발생 시 알림 없음	slack, email 연동 쉬움
복잡한 흐름 관리 어려움	DAG 구조로 직관적 관리
일정별 파이프라인 구분 불가	DAG 단위 스케줄 분리 가능

DAG 란 Directed Acyclic Graph 로

방향이 있고 순환이 없는 그래프

각각의 task 가 의존성 기반으로 연결됨

DAG 구조는 작업 흐름을 시각화하고, 실행 순서를 보장

Airflow 구성 요소는 다음과 같다.

구성 요소	설명
Operator	개별 작업 정의
Task	실제로 실행되는 작업 인스턴스
DAG	여러 task 간의 실행 순서를 정의한 파이프라인
Schedule Interval	DAG가 실행되는 주기 설정
Trigger Rule	다음 작업을 언제 실행할지 조건 정의

실습을 통해 다음 단계를 경험해 보았다.

데이터 준비 → 전처리 → 라벨링 → 분류 → 리포트 생성

Airflow의 장점으로는 다음이 있으며

태스크 단위 구성

의존성 기반 실행

UI 기반 모니터링

재시도/실패 처리

일정 기반 실행

현업 적용 시 고려사항은 다음과 같다.

데이터 기준 값, 모델 경로 등은 환경에 따라 외부 설정화

알림 시스템과의 연동을 통해 모니터링 기능 강화

복잡한 파이프라인도 DAG 구조로 명확히 관리

airflow + gitops 로 운영 자동화 구성

5. 클라우드 기반 ETL 실습

온프레미스 방식의 한계와 클라우드 전환의 필요성

클라우드로 전환하는 이유	전통적인 온프레미스 방식의 문제점
유연한 스케링일(서버리스)	확장성 부족: 서버 증설 필요, 비용/공간 부담
자동화 가능한 파이프라인	유지 보수 어려움: 즉각 대응이 어려움
비용 절감 및 운영 안전성 확보	수작업 중심의 비효율: cron, shell

클라우드 환경에서의 일반적인 데이터 파이프라인 구조

데이터 소스

데이터 저장 : Amazon S3, Google Cloud Storage

데이터 처리 (ETL) : AWS Glue, Google Dataflow, Azure Data Factory

분석 및 활용 : Amazon Athena, BigQuery, BI Tool, ML 모델

+) 데이터 특성 및 과제 설정

데이터의 구조를 분석한다

시계열, 로그 형식, 파일 형식
데이터 소스 종류 별로 컬럼 구성과 단위가 상이

데이터 처리를 위한 품질 문제의 주요 사례를 확인한다

단위 불일치
이상치 포함

분석 전에 반드시 필요한 전처리를 정의한다

기준 수립
정제 작업 → 클린 데이터 확보

파이프라인이 길수록 복잡해진다

부서별 맞춤 ETL 을 개별 구성하면 중복 처리가 증가한다

스케줄 충돌, 설정 중복, 배포 혼선을 발생

파이프라인 관리 비용이 증가

따라서 중복을 줄이기 위한 전략적 접근

공통 처리 단계를 구성해 정제, 라벨링, 기준 매핑 등 1차 처리를 수행

그 결과를 기반으로 부서별 후처리 JOB 으로 분기

AWS Glue는 서버리스 ETL 파이프라인의 핵심이다.

서버리스

Spark 기반 분산 처리

통합 구성 요소 제공

Glue 에서 제공하고 있는 기능은

Glue Job: 데이터 처리 코드 실행

Glue Crawler: 메타 데이터 스캔

Data Catalog: 테이블 정의

Trigger & Workflow: 자동화 흐름

6. 실습 정리 및 현업 적용 가이드

우리 조직에는 어떻게 적용할 수 있을까?

나는 지금 어디에 있는가?

지금 내 조직의 데이터 흐름을 그림으로 그릴 수 있는가?
그 흐름 속에서 내가 담당하는 구간이 어디인지 설명할 수 있는가?
품질 기준을 명확히 문서화한 경험이 있는가?
반복되던 수작업을 자동화해본 적이 있는가?
이 경험을 공유할 수 있는가?

기술보다 중요한 것은 조직의 데이터 운영 문화

데이터의 기준이 명확히 정의되어 있는가
이 기준이 문서화되어 공유되고 있는가?
반복되는 수작업이 존재한느가?
데이터 진단 기준이 존재하거나 합의되어 있는가?
정기적인 자동화 흐름이 구축되어 있는가?

일단 자동화하면 좋다? ⇒ 자동화 = 무조건 효율은 착각이다.

유지보수가 더 힘들어짐

자동화 유지보수 비용도 생각해야 함

결국 사람이 다시 손을 대야 함

너무 작은 작업은 수동이 나음

모두가 만족하는 결과가 나오지 않음

한 명이 전체를 설계하면 생기는 문제

전사 협업 구조로 설계

운영, 분석 팀도 이해가능한 구조

문서화 및 팀 단위 공유 필수

데이터를 움직이는 힘: 데이터 거버넌스 & 엔지니어링 실전 강의 정리

1. 제조 데이터 실무 흐름 이해

2. 데이터 거버넌스 핵심 개념 및 프레임워크 설계

3. 데이터 품질 진단과 표준화 실습

4. 데이터 파이프라인 자동화 실습

5. 클라우드 기반 ETL 실습

6. 실습 정리 및 현업 적용 가이드

NEWPySpark: 대용량 분산 처리 DataFrame 기초

[SQL] 개발자가 반드시 알아야 할 쿼리 튜닝의 핵심

AWS DataZone에서 OpenLineage 기반의 Airflow 데이터 계보 그리기

데이터 엔지니어링 2025년 전망: 실무자의 시선으로 읽기