새발블로그

[견고한 데이터 엔지니어링] CH11 데이터 엔지니어링의 미래

EUG — Sun, 8 Feb 2026 15:31:27 +0900

1) 사라지지 않는 데이터 엔지니어링 수명 주기

조직이 데이터를 새로운 방식으로 활용하면, 그 요구를 해결하기 위한 새 시스템/워크플로가 필요해진다.
데이터 엔지니어링은 여전히 시스템의 디자인·설계·구축·유지관리의 중심에 있다.
결과적으로 “더 높은 작업 수준(추상화된 도구 위에서 더 큰 문제를 푸는 일)”로 이동한다.

2) 복잡성의 감소와 사용하기 쉬운 데이터

복잡성 감소는 “특정 기술/데이터 크기”에 덜 의존하게 되는 흐름.
SaaS/관리형 서비스 덕분에 빅데이터 시스템의 내부를 깊이 몰라도 일정 수준의 활용이 가능해짐.

예시로 등장한 흐름

클라우드 웨어하우스/분석: 구글 BigQuery, Snowflake
확장형 빅데이터 처리: Amazon EMR 등
서버리스 플랫폼: AWS Lambda, Google Cloud Functions
오케스트레이션의 관리형화: Cloud Composer(관리형 Airflow), AWS Managed Airflow
인프라 운영 추상화: 관리형 Kubernetes로 마이크로서비스 아키텍처 구축
데이터 수집 커넥터 상용화: Fivetran, Airbyte 등

3) 클라우드 규모의 데이터 OS와 향상된 상호 운용성

(벤 스탠실 언급) 데이터 파이프라인/데이터 애플리케이션을 만들기 위한 표준화된 데이터 API의 출현을 촉구하는 흐름
소수의 상호운용성 표준 중심으로 통합되는 방향
핵심 구성요소:
- 메타데이터 카탈로그: 스키마와 데이터 계층 구조를 설명 (기존 Hive Metastore가 맡던 역할을 더 확장)
- 스캐폴딩(초기 뼈대) 개선: 프로젝트 시작할 때부터 운영/배포/표준 구성이 갖춰진 상태를 지향
- 차세대 오케스트레이션: Dagster, Prefect 같은 도구가 더 “데이터 인식”을 갖춘 플랫폼으로 발전

차세대 데이터 오케스트레이션 플랫폼의 특징

향상된 데이터 통합 + 데이터 인식 기능
IaC 기능, 코드 배포 기능 내장
라이브 데이터(스트리밍 파이프라인/데이터베이스)를 기본으로 지원
스트리밍 DAG 배포를 단순화(예: “간단 코드로 스트리밍 DAG 배포”)
관리형 스트림 프로세서 확산(예: 키네시스, 데이터플로 같은 계열)

4) ‘엔터프라이즈’ 데이터 엔지니어링의 확산

데이터 엔지니어링이 더 “기업적(엔터프라이즈)”이 된다.
대규모 조직에서 쓰던 기술/관행이 아래로 내려오면서(다운스트림)
- 빅데이터/스트리밍의 어려운 부분은 점점 추상화
- 초점은 사용 편의성, 상호운용성 같은 생산성 개선으로 이동

5) 직책과 책임의 변화

소프트웨어 엔지니어링 / 데이터 엔지니어링 / 데이터 과학 / ML 엔지니어링 경계가 더 모호해진다.

ML 중심 엔지니어링이 강화되는 방향

알고리즘/ML 기술/모델 최적화/모델 모니터링/데이터 모니터링
모델 자동 학습, 성능 모니터링, ML 프로세스 운영 시스템

소프트웨어 엔지니어링과의 교차점

애플리케이션 분석과 결합(제품 내부에서 바로 분석/의사결정)
스트리밍, 파이프라인, 데이터 모델링, 데이터 품질 같은 전통 DE 영역이 SW 영역으로 더 들어감
스트리밍 및 이벤트 기반 아키텍처의 중요도가 커짐

6) 모던 데이터 스택(MDS)을 넘어 라이브 데이터 스택으로

“MDS는 모던하지 않다”는 비판: 배치 중심의 한계가 있음
분석은 점점 자동화로 대체될 수 있음
현재의 대시보드/보고서는 “무엇(what), 언제(when)” 질문에 강하지만,
- 라이브 환경은 “지금 바로 반응/행동”까지 연결해야 함

6-1. 라이브 데이터 스택이란?

스트리밍 기술로 실시간 분석과 ML을 애플리케이션에 융합
원천 시스템에서 데이터 처리 → ML까지 전체 데이터 수명주기를 포괄

6-2. 스트리밍 파이프라인 + 실시간 분석 데이터베이스

MDS는 데이터를 경계가 있는 배치로 다루는 경향
실시간 데이터 애플리케이션은 데이터를 경계 없는 연속 스트림으로 취급
실시간 분석 DB 특징:
- 빠른 수집
- 1초 미만 쿼리 같은 초저지연 지향
STL 개념:
- Stream → Transform → Load
레이크/웨어하우스는 “짧은 수집 지연 + 초고속 쿼리”에 최적화되어 있지 않을 수 있음
→ 라이브 데이터 스택은 OLAP DB 기반으로 구동된다는 관점

6-3. 데이터와 애플리케이션의 융합

애플리케이션과 데이터 계층이 합쳐지면서
- “애플리케이션이 곧 데이터 스택”이 되는 방향
스트리밍 + ML 기반으로 실시간 자동화/의사결정까지 통합

6-4. 애플리케이션과 ML 간의 긴밀한 피드백

대량 데이터 + 정교한 워크플로 + 액션 결합은 ML에 적합
데이터 피드백 루프가 짧아질수록 앱 ↔ ML 피드백도 긴밀해짐

6-5. 암흑 물질 데이터와 스프레드시트의 부상

“암흑 물질 데이터”: 공식 시스템 밖에서 생성/흐르는 데이터가 늘어남
스프레드시트는 단순 문서가 아니라 복잡한 분석을 지원하는 대화형 데이터 애플리케이션처럼 사용됨

[견고한 데이터 엔지니어링] CH10 보안과 개인정보보호

EUG — Sun, 8 Feb 2026 15:29:12 +0900

1) 사람(People)

1-1. 부정적인 사고의 힘

부정적인 사고는 재앙적 시나리오를 먼저 고려하게 하고, 예방 행동을 유도한다.
핵심 실천: 다운스트림에서 실제로 필요한 경우에만 민감한 데이터 수집

→ “일단 다 모으자”가 사고의 시작.

1-2. 항상 편집증적인 자세 유지

항상 주의를 기울인다.
특히 자격 증명(credential)을 요청받을 때는 의심부터 한다.

→ “왜 지금 이걸 요청하지?”를 자동으로 떠올리는 습관.

2) 프로세스(Process)

2-1. 보여주기식 보안 vs 습관화된 보안

기업 고객은 대개 규정준수(내부 규정, 법률, 표준 기관 권고사항)를 요구한다.
하지만 진짜 강한 보안은 “체크리스트”가 아니라 습관화다.
보안은 간단하고 효과적이어야 습관이 된다.
- 예: 한 달에 1번 이상 보안 교육 + 정책 검토 같은 루틴

2-2. 능동 보안(Active Security)

능동 보안 = 변화하는 세상에서 보안 위협을 계속 연구/학습하는 태도
- 성공적인 피싱 공격 사례 분석
- 보안 취약점 파악
“표준 규정 체크리스트 채택”만으로는 부족
→ 조직 내부의 취약성, 개인정보 유출, 오용 인센티브까지 같이 봐야 함

2-3. 최소 권한 원칙(Principle of Least Privilege)

개인/시스템에 작업 완료에 필요한 권한·데이터만 부여
필요할 때 해당 IAM 역할 제공하고, 필요 없으면 제거
열/행/셀 단위 접근 제어 구현

2-4. 클라우드에서의 책임 공유(Shared Responsibility)

클라우드 제공자는 데이터센터/하드웨어 같은 물리적 보안을 책임진다.
그러나 보안 침해의 많은 원인은:
- 의도하지 않은 잘못된 구성
- 실수, 감독 소홀, 부주의
- → 즉 “내가 만든 설정”이 사고의 핵심일 때가 많다.

2-5. 항상 데이터를 백업하라

정기적으로 데이터 백업
복원 테스트까지 해야 의미가 있다.
재해 방지(Disaster Recovery) 범주에 포함되는 기본기

2-6. 보안 정책 예시

(1) 자격증명 보호

모든 작업에 통합 인증 사용, 가능하면 비밀번호 대신 SSO 기본
SSO + 다단계 인증(MFA) 사용
비밀번호/자격 증명 공유 금지(클라이언트 비밀번호/자격 증명 포함)
피싱/사기전화 주의, 비밀번호 절대 알려주지 않기
이전 자격 증명 비활성화/삭제
자격 증명을 코드에 포함하지 않기
최소 권한 원칙 실천

(2) 장치 보호

모든 장치에 장치 관리 사용
모든 장치에 MFA 사용
회사 이메일 자격 증명으로 장치 로그인
자격 증명/행동 정책을 장치에도 동일 적용
장치는 “본인의 연장선”
화면 공유 시 공유 대상 명확히(문서/탭/창 단위만)
영상 통화 시 방해금지 모드 사용

(3) 소프트웨어 갱신 정책

갱신 알림 뜨면 웹 브라우저 재시작
마이너 OS 갱신 실행
중요 OS 식별 및 안내 제공
베타 OS 사용하지 않음
새 메이저 OS 릴리즈 직후가 아니라 안정화될 때까지 기다림

3) 기술(Technology)

3-1. 패치와 시스템 갱신

소프트웨어 보안 취약점은 계속 발견된다.
운영체제/소프트웨어를 항상 패치해야 한다.

3-2. 암호화(Encryption)

주의: 자격 증명 탈취 같은 “인적 보안 침해”가 발생하면 암호화가 만능은 아니다.
하지만 암호화는 네트워크 트래픽 가로채기 같은 기본 공격을 막는다.

(1) 미사용(At rest) 암호화

저장 장치가 유휴 상태일 때 암호화 여부 확인
전체 디스크 암호화 활성화
서버측 암호화도 포함

(2) 이동 중(In transit) 암호화

HTTPS 필요
FTP는 공용 네트워크에서 안전하지 않음(중간자 공격 취약)
레거시 프로토콜을 쓰더라도 “전송 구간 암호화”가 되는지 확인

3-3. 로깅, 모니터링, 알람

보안에서 “기록/탐지/대응”은 필수.

접근: 누가 언제, 어디서, 무엇에 접근했는지
- 새로운 접근권한 부여 같은 이벤트
리소스: 디스크/CPU/메모리/I/O 패턴 이상 징후 탐지
청구: SaaS/클라우드 관리형 서비스 비용 감독
초과권한: 사용하지 않는 권한 모니터링 → 제거해서 보안 허점 차단

3-4. 네트워크 접근

데이터 엔지니어는 DB/객체 스토리지/서버를 자주 다루므로 네트워크 보안 관행 준수 필요
항상 답할 수 있어야 하는 질문:
- 어떤 IP와 포트가
- 누구에게
- 왜 개방되었는가
접근 시스템 측면:
- 사용자 수신 IP 허용(allowlist) 같은 통제
클라우드 특성:
- 제로 트러스트 보안에 가까운 방향성

3-5. 로우 레벨 데이터 엔지니어링 관점

보안은 상위 레이어만이 아니라,
- 소프트웨어 라이브러리
- 스토리지 시스템
- 컴퓨팅 노드
- 로깅 라이브러리
- CPU 아키텍처/마이크로코드
- 메모리, CPI 등
- 아주 하단까지 영향을 받는다.
내부 보안 연구(능동 보안 접근)를 채택하는 이유도 여기에 있다.

[견고한 데이터 엔지니어링] CH9 5단계: 분석, 머신러닝 및 역 ETL을 위한 데이터 서빙

EUG — Sun, 8 Feb 2026 15:26:22 +0900

1) 데이터 서빙의 일반적인 고려사항

1-1. 신뢰(Trust)

최종 사용자가 데이터를 비즈니스의 신뢰 가능한 표현으로 받아들여야 한다.

데이터 품질 실현
데이터 검증: 재무정보/고객 상호작용/매출 등을 정확히 나타내는지 분석·확인
데이터 관찰 가능성(Observability): 데이터와 프로세스에 대한 지속적 뷰

→ “서빙 단계만”이 아니라 데이터 엔지니어링 수명 주기 전체에 적용

또한 신뢰는 “데이터 자체”뿐 아니라 “운영 약속”으로도 쌓인다.

최종 사용자·업스트림 이해관계자와 SLA/SLO 협의
- SLA 예: 데이터는 안정적으로 사용 가능하고, 고품질이어야 한다.

1-2. 사용사례는 무엇이고, 사용자는 누구인가

데이터는 행동으로 이어질 때 효과가 극대화된다.

사용사례를 정할 때 던질 질문은 다음과 같다:

이 데이터는 어떤 행동(작업)을 트리거하는가?
그 행동은 누가 수행하는가?
그 작업은 자동화할 수 없는가?

우선순위:

ROI가 높은 사용 사례에 우선순위 부여

체크리스트:

데이터를 누가, 어떻게 사용할지
이해관계자는 무엇을 기대하는지
데이터 이해관계자(DS/분석가/비즈니스 사용자)와 협력해 “현재 데이터가 실제로 어떻게 쓰이는지” 이해

1-3. 데이터 제품(Data Product)

데이터 제품: 데이터를 사용해 최종 목표 달성을 촉진하는 제품
데이터 제품 제작은 제품 + 비즈니스 + 기술의 융합물
“사람들이 사용하고 좋아할” 데이터 제품을 목표로
→ 만들 때 수행해야 할 작업(운영/문서/지원/권한/품질 등)을 함께 떠올리면 유용

1-4. 셀프서비스(Self-service) 여부

사용자가 데이터 제품과 어떻게 인터페이스하는지가 중요하다.

셀프서비스 데이터 제품: 사용자가 직접 제품/분석을 구축할 수 있게 지원
사용자별 기대치:
- 경영진: 명확·실행 가능한 KPI, 미리 정의된 대시보드
- 분석가: 이미 SQL 기반 셀프서비스 분석을 추진 중일 수도

1-5. 데이터 정의 및 논리(Definition & Logic)

데이터 유용성은 정확성과 신뢰성에 기반한다.

데이터 정확성 = 적절한 데이터 정의와 데이터 로직 포함
정의/로직은 원천 시스템 → 파이프라인 → BI → ML까지
수명주기 전 단계에 반영돼야 한다.

개념 정리:

데이터 정의: 조직 전체에서 공유되는 “의미”
- 예: ‘고객’이 부서마다 다른 의미를 갖지 않도록 공식화
데이터 로직: 지표를 도출하는 공식/규칙
제도적 지식(Institutional knowledge):→ 정의/로직을 “공식 선언”하면 정확성·일관성·신뢰에 도움
일화/암묵지 형태로 자체 생명력을 갖고 떠도는 것들

현실적으로는 암묵적으로 퍼지기 쉽다:

쿼리/대시보드/ML 모델이 각자 정의를 다르게 쓰면
파생 지표가 일관되지 않게 표시됨

해결 힌트:

시맨틱 계층을 쓰면 비즈니스 정의·로직을 재사용 가능한 방식으로 통합 가능

1-6. 데이터 메시(Data Mesh)

사일로화된 중앙 데이터팀이 전부 처리하는 대신, 도메인 팀이 P2P 데이터 서비스의 책임을 나눠 갖는 형태로 설명됨.

도메인 팀이 맡는 두 측면:

다른 팀이 쓰기 좋게 데이터를 준비해 제공
- 데이터 애플리케이션, 대시보드, 분석/BI에서 소비하기 편리한 형태
셀프서비스를 위한 대시보드/분석 실행 가능
- 다른 팀이 소비하는 데이터가 임베디드 분석/ML 기능을 통해
- 도메인팀이 설계한 소프트웨어로 유입될 수도 있음

2) 분석(Analytics)

2-1. 비즈니스 분석(Business Analytics)

과거/현재 데이터를 활용해 전략적이고 실행 가능한 결정
도메인 지식 + 인간의 판단 + 통계/추세 분석이 혼합

서빙 형태:

대시보드: 매출/고객 유지율 등 핵심 지표를 시각화(차트/히트맵), 요약 통계, 단일 숫자 KPI
KPI/OKR 기반 보고서 작성
보고서는 종종 애드혹 요청에서 시작

데이터 제공 방식:

DW/데이터 레이크에서 배치 모드로 제공되는 경우가 많음

2-2. 운영 분석(Operational Analytics)

비즈니스 분석이 “인사이트로 실행을 돕는 것”이라면, 운영 분석은 “즉각 조치”가 핵심.

차이의 핵심: 시간
예: 실시간 모니터링 대시보드(초당 요청 수, DB I/O 등)
스케일링 이벤트 트리거, 과부하 시 용량 추가
임계값 초과 시 SMS/그룹채팅/이메일 경고

2-3. 임베디드 분석(Embedded Analytics)

내부(비즈니스/운영) 분석 ↔ 외부 사용자에게 제공하는 분석

데이터 애플리케이션이 최종 사용자에게 분석 기능 제공
애플리케이션 자체에 대시보드를 내장하는 형태

문제/요구사항:

짧은 데이터 지연 허용(앱 사용자는 내부 분석가만큼 “느린 배치”에 관대하지 않음)
빠른 쿼리 성능(파라미터 조정 시 몇 초 내 반응)
높은 동시성(많은 고객/대시보드에 대해 높은 쿼리 속도)

3) 머신러닝(ML)

3-1. 경계가 흐려지는 영역

ML/데이터과학/데이터엔지니어링/ML엔지니어링의 경계가 모호해짐
DE는 데이터를 처리해 모델 학습용으로 전달하고,
경우에 따라 데이터 특성화(Feature) 같은 ML 고유 작업 일부도 맡을 수 있음

3-2. 데이터 엔지니어가 ML에 대해 알아야 할 것

“학습 항목” 형태로 그대로 정리하면:

지도/비지도/준지도 학습 차이
분류 vs 회귀 차이
시계열 처리 기술(시계열 분석/예측 포함)
로지스틱 회귀, 트리 기반, SVM 등 고전 기법 vs 딥러닝 사용 시점
AutoML vs 수작업 ML의 차이와 트레이드오프
정형/비정형 데이터별 데이터 랭글링
정형·반정형 제공 시, Feature Engineering 과정에서 적절한 변환이 가능한지
범주형 데이터 인코딩, 다양한 데이터 임베딩 방식
배치 학습 vs 온라인 학습 차이와 적용 방식
DE 수명주기와 ML 수명주기의 교차점 이해
(Feature Store, ML 관찰가능성 등 무엇을 인터페이스/지원할지)
로컬/클러스터/엣지 학습의 적절한 시점, CPU vs GPU 판단
배치 데이터(오프라인 학습) vs 스트리밍 데이터(온라인 학습) 적용 차이
데이터 캐스케이드(Data Cascade)와 ML 모델에 미치는 영향
결과 제공 방식: 실시간 반환 vs 배치 반환
(예: 음성 전사 모델은 API 호출 후 음성 샘플 처리, 텍스트 일괄 반환 등)
정형/비정형을 함께 다루는 방식(표 데이터 클러스터링, 이미지 신경망 등)

4) 분석 및 ML을 위한 데이터 서빙 방법

4-1. 파일 교환(File Exchange)

어디서나 가능(가장 단순)
처리 후 소비자에게 전달할 파일 생성
- 예: 고객 메시지 텍스트 파일(비정형), 송장 CSV, 엑셀을 이메일로 전송
단점:
- 파일 편차 발생
- 검색/추적이 어려움
객체 스토리지: 다양한 blob 파일 저장에 적합

4-2. 데이터베이스(Database, 주로 OLAP 관점)

데이터베이스 기반 서빙의 강점(너 메모 그대로):

스키마로 데이터에 구조 부여
테이블/열/행 수준의 세분화된 권한 제어
대규모 계산 집약 쿼리 + 높은 동시성 제공

BI 도구 사례:

Tableau: 초기 쿼리로 DB에서 데이터를 가져와 로컬 저장하는 방식이 흔함
Looker: 쿼리 푸시다운 계산 모델에 의존

4-3. 스트리밍 시스템(Streaming Systems)

기존 “쿼리”와는 다른 방식으로 방출된 측정 지표(이벤트/메트릭)를 포함할 수 있음
운영/임베디드 요구(지연/동시성)에 맞춰 서빙 계층으로 쓰일 수 있음

4-4. 쿼리 페더레이션(Query Federation)

데이터 레이크/RDBMS/DW 등 여러 원천에서 데이터를 가져옴
분산 쿼리/가상화 엔진이 데이터를 중앙 집중 저장하지 않아도 쿼리 가능

주의점:

최종 사용자가 여러 시스템을 동시에 쿼리할 수 있다는 점을 전제로 해야 함
시스템마다 사용 패턴/특이점/미묘한 차이가 있어 운영 난도가 올라감
장점: 애드혹 쿼리 허용 → 여러 시스템 데이터를 섞어 탐색 분석 가능
원천 시스템에는 보통 읽기 전용 접근 허용

4-5. 데이터 공유(Data Sharing)

클라우드 멀티테넌트 스토리지 시스템을 통한 공유
서빙의 초점이 “데이터를 만드는 엔지니어”보다
“데이터 소비자가 처리”하는 방향으로 이동
보안/접근제어 이슈가 핵심으로 올라옴

4-6. 시맨틱 계층 & 메트릭 계층(Semantic & Metric)

강력한 쿼리 엔진 ≠ 고품질 비즈니스 분석
→ 분석 품질은 정의/로직의 일관성에서 갈림
메트릭 계층: 비즈니스 로직을 유지·계산하는 도구(지표 정의의 표준화)
- BI 도구 또는 변환 쿼리 작성 소프트웨어
시맨틱 계층: 복잡한 비즈니스 로직을 재사용 가능하게 정의
- Looker/LookML: 가상의 복잡한 비즈니스 로직 정의
- dbt: SQL 흐름 + 표준 지표 정의를 포함하는 데이터 흐름 구성

4-7. 노트북 기반 서빙(Notebook Serving)

Jupyter Notebook: 오픈소스 노트북/서버 및 다양한 클라우드 관리형 서비스
DS는 API/DB/DW/데이터 레이크 등에 프로그래밍 방식으로 연결
Pandas: 파이썬 데이터 조작/분석 라이브러리
클라우드 기반 노트북: Dask/Ray/Spark 등과 결합 가능
예: Amazon SageMaker 등

5) 역 ETL(Reverse ETL)

OLAP 데이터베이스의 데이터를 원천(운영) 시스템으로 다시 적재해 제공
주의점:
- 본질적으로 피드백 루프
- 그래서 세심한 모니터링/감시 체계가 필수

6) 함께 작업하는 사람들

데이터 분석가
데이터 과학자
MLOps/ML 엔지니어
비즈니스(비기술 이해관계자)
관리자/경영진
데이터 엔지니어는 이 이해관계자들을 “지원”하는 역할

→ 직무와 관심사를 분리함으로써 협업이 쉬워질 수 있음

7) 드러나지 않는 요소(Hidden Layers)

7-1. 보안(Security)

사람/시스템 모두에 최소 권한 원칙
사용자(분석가/DS/경영진)와 대상(서빙 시스템)은 서로 다른 요구
고급 접근이 필요 없으면 읽기 전용 권한 부여
사용자 그룹을 특정 IAM 역할(또는 커스텀 역할)과 결합해 관리

멀티테넌트 환경 고려:

필터링된 뷰 제공
데이터 제품 사용 빈도 점검

→ “공유 중단”이 합당한 경우도 판단

7-2. 데이터 관리(Data Management)

사람들이 고품질·신뢰 가능한 데이터에 접근할 수 있게 하는 것
피드백 루프로 데이터 신뢰와 개선을 “적극적 프로세스”로 만들기
익명화 등(민감 데이터 처리)
엄격한 데이터 모델 + 시맨틱/메트릭 계층을 서빙 계층에 통합

→ 단일한 “진실의 원천”에 가까워짐

7-3. 데이터 옵스(DataOps)

모니터링 항목:

데이터 상태 및 데이터 다운타임
서빙 시스템(대시보드/DB 등)의 지연
데이터 품질
데이터/시스템 보안 및 접근
서빙되는 데이터와 모델 버전
SLO 달성을 위한 가동 시간

목표:

데이터 다운타임 최소화
데이터 품질 극대화

7-4. 데이터 아키텍처(Data Architecture)

피드백 루프가 빠르고 긴밀해야 함
필요할 때 필요한 데이터를 최대한 빨리 접근
개발/테스트/운영 환경 협업을 위해
공통 클라우드 시스템으로 마이그레이션해 운영 아키텍처를 정립

7-5. 오케스트레이션(Orchestration)

약속된 시간에 소비자에게 데이터 제공하도록 팀 간 데이터 흐름 조정
중앙집중식 vs 분산식
- 중앙 접근식: 단일 운영 자산 보호를 위한 게이트키핑 성격

7-6. 소프트웨어 엔지니어링(Software Engineering)

서빙 단계에서는 코드 작성 필요성이 줄어들 수 있지만,
- 로컬 코드를 변환해 운영용 보고서/기본 ML 모델로 “작동”시켜야 할 수 있음
코드/쿼리가 스토리지 시스템에서 어떻게 수행되는지 이해 필요
올바른 페이로드가 전달되도록 보장해야 함

[견고한 데이터 엔지니어링] CH8 4단계: 쿼리 모델링 및 데이터 변환

EUG — Sat, 31 Jan 2026 18:45:50 +0900

1) 쿼리(Query)

1-1. 쿼리란?

쿼리: 데이터를 검색하거나, 그 데이터에 대한 작업을 수행하는 것
CRUD 관점에서 다양한 언어 계층이 존재

데이터 정의 언어(DDL)

데이터 삽입 전에 필요한 DB 객체를 정의
CREATE, ALTER, DROP 등

데이터 조작 언어(DML)

데이터 조회/삽입/갱신/삭제
SELECT, INSERT, UPDATE, DELETE, COPY, MERGE

데이터 제어 언어(DCL)

누가 무엇에 접근 가능한지
GRANT, DENY, REVOKE

트랜잭션 제어 언어(TCL)

트랜잭션 확정/되돌림
COMMIT, ROLLBACK

1-2. 쿼리 수명 주기(Query Lifecycle)

SQL이 실행될 때 DB 내부에서 보통 이런 흐름을 탄다.

SQL 파싱/검증
- 객체 존재 여부, 권한 보유 여부 확인
바이트코드(또는 내부 실행 표현)로 변환
플래닝 & 최적화
- 실행 순서 변경, 리팩터링(조인 순서, 필터 푸시다운 등) 결정
실행 & 결과 반환

1-3. 쿼리 옵티마이저(Query Optimizer)

쿼리를 효율적인 단계로 분해하고 순서를 재배치해 성능·비용 최적화
조인 방식, 인덱스 활용, 스캔 크기, 기타 요소를 평가
엔진마다 “같은 SQL이라도” 실행 방식이 미묘하게 다를 수 있다

1-4. 쿼리 성능 향상 포인트

(1) 가치는 ‘결합(Join)’에서 나온다

테이블/파일 같은 단일 집합보다, 다른 집합과 결합할 때 가치가 커짐
조인은 가장 흔한 결합 수단

(2) 선조인(Pre-join)과 구조 활용

선조인: 미리 조인된 테이블/뷰를 만들어 반복 쿼리 비용을 줄임
새로운 데이터 구조(배열/구조체 등) 활용도 성능·모델링에 영향

(3) 표준화된 스키마 유지

분석/DS의 일반 활용 사례에 대해 “선조인된 표준 테이블”을 제공하면
다운스트림 생산성이 크게 올라간다.

(4) 조인 폭발(Row Explosion) 주의

다대다 매칭이 많으면 행이 폭발적으로 늘어날 수 있음
초기에 폭발이 생기면 쿼리 실패/비용 폭증 가능
조건절/조인 조건의 재정렬이 리소스 요구량을 줄이는 데 도움이 될 수 있음

(5) 쿼리 구조 가독성

중첩 서브쿼리/임시테이블 대신 CTE(공통 테이블 표현식) 사용하면
복잡한 쿼리를 읽기 쉽게 구성 가능
중간 테이블은 보통 임시 테이블 형태로 생성되는 경우가 많음

1-5. 실행계획 기반 성능 파악(EXPLAIN)

EXPLAIN으로 쿼리 단계(실행 계획)를 확인할 수 있음
모니터링해야 할 지표:
- 디스크/메모리/네트워크 등 주요 리소스 사용량
- 데이터 로딩 시간 vs 처리 시간
- 실행 시간, 레코드 수, 스캔한 데이터 크기, 셔플 데이터량
- 리소스 경합을 만드는 경쟁 쿼리
- 동시 연결 수(한도 초과 시 사용자 영향)

1-6. 전체 테이블 스캔 방지 & 가지치기(Pruning)

필요한 데이터만 쿼리해야 함
스캔 양을 줄이는 핵심:
- 열 지향: 필요한 컬럼만 선택
- 파티션/클러스터링 키 활용해 가지치기
- 행 지향: 인덱스 중심으로 최적화

주의:

성능 민감 쿼리는 인덱스를 만들 수 있지만
인덱스가 너무 많으면 쓰기/갱신 부담으로 성능이 오히려 저하될 수 있음

1-7. DB의 커밋 처리 방식(일관성/동시성)

커밋: 레코드/테이블/객체의 생성·갱신·삭제 확정
트랜잭션: 일관된 상태를 유지하기 위한 단위
ACID 준수 여부, dirty read 등 격리 수준이 영향을 준다.

엔진별 예시:

PostgreSQL: ACID 트랜잭션 적용 (단, 행 잠금 필요 → 단점)
BigQuery: 특정 시점 스냅샷에서 읽기만
- 실행시간(1초/2시간)과 무관하게 같은 스냅샷 기반
- 일관성 위해 “한 번에 하나의 쓰기”만 허용하는 특성이 있어
- 쓰기 동시성이 낮고 도착 순서대로 큐잉될 수 있음
MongoDB: 가변적 일관성 옵션 제공
- 높은 쓰기 성능 가능하지만 과부하 시 쓰기 폐기 등으로
- 정확한 통계/정확성 요구가 높은 애플리케이션에 부적합할 수 있음

1-8. Vacuum / Dead Records(데드 레코드)

오래된 레코드(데드 레코드)는 배큐밍으로 제거해야 할 수 있음
1. 공간 확보 → 새 레코드 저장 가능
2. 통계 정확도 개선 → 플래너 정확도 향상
3. 나쁜 인덱스 정리 → 인덱스 성능 개선
Redshift는 디스크 구성을 바탕으로 자동 처리하는 특성이 있고,
PostgreSQL/MySQL 같은 RDBMS에서는 트랜잭션이 많으면 데드 레코드가 빠르게 쌓여 vacuum 중요성이 커진다.
객체 스토리지는 공간이 곧 비용이라, 불필요한 데이터/버전이 누적되면 비용 문제가 생길 수 있음

1-9. 캐시된 쿼리 결과 활용

같은 쿼리를 반복 실행하며 비용을 내기보다
결과를 캐시/저장해서 즉시 재사용하는 게 효율적일 수 있음
구체화 뷰(Materialized View)는 쿼리 캐싱의 대표 형태

2) 스트리밍 데이터에 대한 쿼리

2-1. 스트림 기본 쿼리 패턴

패스트 팔로워(Fast-follower) 접근

운영 DB를 직접 분석 쿼리하면 운영 시스템이 느려지거나 충돌할 수 있음
CDC 기반으로 약간 지연된 통계/집계를 분석 DB에서 조회하면
운영 영향 최소화 가능

단, 한계:

배치 쿼리 패턴을 근본적으로 재고하지 않음
이벤트 기반 “동적 트리거”에 약함

2-2. 카파 아키텍처(Kappa)

이벤트를 테이블이 아니라 스트림으로 저장
스트리밍 스토리지를 단순 버퍼가 아니라,
과거 데이터까지 쿼리 가능한 저장소/DB처럼 취급
Kafka + ksql: 집계/통계/세션화 지원
요구가 복잡해지면 Spark 등 외부 도구, Flink/Beam 같은 스트림 프로세서로 확장

2-3. 윈도/트리거/워터마크/늦게 도착한 데이터

배치 세계: 외부 액터(크론/사람/대시보드)가 쿼리 실행을 “트리거”
스트리밍 세계: 데이터 자체가 트리거가 되어 계산이 발생

윈도 유형:

세션 윈도: 근접 이벤트를 그룹화, 비활성 구간 제거
- “소급 세션화”처럼 세션 종료 후 일정 시간이 지나 처리 가능
고정 시간 윈도: 고정 주기/고정 길이로 닫히며 처리
슬라이딩 윈도: 겹칠 수 있는 고정 길이 윈도(예: 30초마다 60초 윈도 생성)

워터마크:

늦게 도착한 데이터 판정 기준 타임스탬프 임계값
워터마크보다 오래된 데이터는 late data로 처리

2-4. 스트림과 다른 데이터의 결합

스트림 ↔ 테이블 조인(보강/enrichment)
- 예: 서버리스 함수로 인메모리 DB에서 이벤트에 정보 추가 후 다른 스트림으로 출력
스트림 간 조인
- 지연시간 차이로 인해 버퍼/보존 간격이 필요
- 보존 간격이 길수록 스토리지/리소스 사용 증가
- 보존 기간이 지나면 버퍼 데이터는 제거됨

3) 데이터 모델링(Data Modeling)

3-1. 왜 모델링이 중요한가

잘 구축된 아키텍처는 조직의 목표/비즈니스 논리를 반영해야 한다.
모델은 “데이터를 비즈니스 성과로 변환”하는 데 초점이 있어야 함
좋은 모델은 정의가 일관되고, 의사결정과 연결된다.

3-2. 데이터 모델이란?

데이터가 실제 세계와 연관되는 방식
데이터가 어떻게 구조화/표준화 되어야 하는지 반영

3-3. 개념적/논리적/물리적 모델

개념적 모델: 비즈니스 논리·규칙 포함, ERD로 관계 시각화
논리적 모델: 개념 모델이 실제로 구현되는 방법을 자세히
물리적 모델: 구현(저장/인덱스/파티션 등) 방법 정의

핵심: 데이터 그레인(해상도)

가능한 낮은 그레인으로 모델링하면
다양한 집계를 만들 수 있다.

3-4. 정규화(Normalization)

테이블/열 관계를 엄격히 제어해 중복 제거
기본 키, 부분 종속성, 전이 종속성 관리

3-5. 배치 분석 데이터 모델링 기법

(1) 인먼(Inmon)

원천 시스템과 분석 시스템 분리를 강조
특징:
- 주제 지향성 / 통합 / 비휘발성 / 시간변이성
높은 정규화 통합 모델을 중심으로,
ETL이 DW → 다운스트림 데이터마트로 공급하는 흐름

(2) 킴벌(Kimball)

상향식(Bottom-up)
데이터마트가 “데이터웨어하우스 자체”가 될 수 있다는 관점
핵심: 스타 스키마(팩트 + 차원)

팩트 테이블

숫자/수량/이벤트 중심
변경 불가, 추가 전용
열은 적고 행이 많음
가능한 최소 그레인 유지
집계/파생은 팩트에 넣지 말고 downstream(마트/뷰)에서

차원 테이블

이벤트의 맥락(내용/장소/시기) 제공
폭이 넓고 행이 비교적 적은 형태
비정규화로 중복 가능
변경 추적은 SCD(천천히 변화하는 차원) 필요

스타 스키마

조인 수 감소 → 성능 향상
BI 도구에서 직접 모델링/리포팅이 쉬움
“맞춰진 차원(Conformed Dimensions)”으로 여러 스타 스키마 재사용 가능

(3) 데이터 볼트(Data Vault)

워크로드 데이터를 입력 전용 방식으로 적재
구성:
- 허브(Hub): 비즈니스 키 저장(중심 엔티티), 입력 전용
- 링크(Link): 비즈니스 키 간 관계 추적(낮은 그레인 연결)
- 위성(Satellite): 속성/컨텍스트, (허브 키 + 로드 날짜) 기반 키

(4) 와이드 비정규화 테이블

요즘은 스토리지 비용이 저렴해지고, 중첩 데이터가 유행하며 완화됨
장점: 단순 조회에 빠를 수 있음
단점:
- 비즈니스 로직 손실
- 배열 요소 갱신 시 성능 저하

3-6. 스트리밍 데이터 모델링

배치 → 스트리밍 전환, 온프레미스 → 클라우드 진화에 따라
모델링도 함께 변해야 함

4) 변환(Transformation)

4-1. 변환이란?

데이터 파싱/클렌징/조인/결합/집약
쿼리 결과를 저장해서 “연산 부하 큰 작업을 한 번만” 수행하고 재사용 가능

개념 구분:

쿼리: 원천에서 데이터 검색(필터/조인 로직 포함)
변환: 그 결과를 목적에 맞게 “추가 가공”하여 데이터셋으로 만든다

4-2. 배치 변환

개별 데이터 청크 단위로 실행
고정 스케줄 기반

분산 조인(Distributed Join)

논리적 조인을 작은 조인으로 분할해 클러스터에서 실행
브로드캐스트 조인:
- 큰 테이블 분산 + 작은 테이블 단일 노드 적재
- 옵티마이저가 조인 재정렬을 중요하게 다룸
셔플 해시 조인:
- 테이블이 단일 노드에 들어갈 만큼 작지 않을 때 흔함
- 셔플 비용이 커질 수 있음

ETL vs ELT

ELT: 원시 데이터 로드 후, 웨어하우스에서 클렌징/변환
“로드 시점에 변환하지 않고, 미래 시점에 변환 가능”이 핵심 장점

4-3. SQL 기반 vs 코드 기반 변환

SQL의 강점

선언형 언어라 “최종 데이터 특성”을 규정하는 데 강함
CTE/스크립트/오케스트레이션으로 DAG 구성 가능
재사용:
1. 결과를 테이블로 커밋하거나 뷰 생성
2. dbt 같은 도구로 모델/테스트/문서화를 체계화

Spark 네이티브 코딩 주의점

일찍, 자주 필터링
핵심 Spark API에 의존하고 동작 방식을 이해
- 부족하면 잘 관리된 공공 라이브러리 활용
- 좋은 코드는 “실질적으로 선언적”
UDF 주의
SQL 혼합 사용은 검토 필요

4-4. 갱신 패턴(Updates)과 삭제/재적재

입력 전용(append-only)

이전 레코드를 변경/삭제하지 않고 새 레코드만 삽입
최신 상태는 기본 키로 최신 레코드를 찾아야 함
→ 단점: 조회 시 연산 비용 증가

삭제

컬럼형 시스템/데이터 레이크에서 삭제는 입력보다 비용이 크다
물리 삭제 vs 논리 삭제
“삭제 레코드 입력” 패턴(삭제 플래그를 가진 새 레코드 추가)

갱신 입력 & 병합(Merge)

소스 레코드와 타깃을 키로 매칭해 갱신
병합은 삭제까지 포함
원래 행 기반 DB 중심 패턴이며,
- 일부 레코드 변경/삭제만 있어도 파일 전체 재작성 + 포인터 교체
파일 기반 시스템은 제자리 갱신이 안돼 “쓰기 시 복사”가 발생:

4-5. 스키마 갱신

컬럼형 DB는 데이터 갱신이 어렵지만 스키마 갱신은 더 쉬울 수 있음
클라우드 DW는 JSON 인코딩 타입 같은 유연한 타입도 지원
자주 접근되는 데이터는 평면화 필드로 저장하는 전략이 흔함

4-6. 데이터 랭글링(Data Wrangling)

지저분한 데이터를 유용하고 깨끗한 데이터로 변환
Spark 변환은 수집/조인/쓰기까지 코드 기반 DAG로 구현되는 경우가 많음

4-7. 비즈니스 로직과 파생 데이터

파생 지표는 “저장된 다른 데이터에서 계산된 데이터”의 전형
지표 버전이 늘어나기 쉬움(이익 전/후 수익 등)
ETL 스크립트는 DRY 위반이 되기 쉬움DW나 도구로 계산 부하 큰 작업을 수행하는 방향이 권장됨

->비즈니스 로직은 메트릭 계층에서 관리하고,

4-8. MapReduce와 이후

MapReduce는 빅데이터 시대 배치 변환의 핵심 패턴
- map(블록 읽기) → shuffle(재분배) → reduce(집약)
이후에는 “디스크/대역폭 저렴”이라는 전제 위에서
초고속 쿼리를 위해 대량의 디스크를 투입하는 발상이 확산됨

5) 뷰/구체화 뷰/페더레이션/가상화

5-1. 뷰(View)

다른 테이블을 참조하는 “쿼리 그 자체”인 DB 객체
역할:
1. 보안(접근 제어)
2. 중복 제거된 현재 스냅샷 제공
3. 공통 접근 패턴 표준화

5-2. 구체화 뷰(Materialized View)

뷰의 일부/전부를 미리 연산하여 저장(조인 결과 포함 가능)

5-3. 구성 가능한 구체화 뷰

예: Databricks Live Tables
데이터 도착 시 갱신되며 비동기적으로 후속 테이블로 전달

5-4. 페더레이션 쿼리(Federated Query)

OLAP DB가 외부 소스(객체 스토리지/RDBMS 등)를 직접 조회
예: Snowflake 외부 테이블(External Table)로 S3 조회 지원

5-5. 데이터 가상화(Data Virtualization)

내부에 데이터를 저장하지 않고 처리/쿼리를 수행하는 시스템
대표: Trino(Starburst/Presto)
핵심 고려사항:
- 외부 소스 의존성
- 성능
- 쿼리 푸시다운(가능한 많은 작업을 소스로 내려 보내기)
  - 가상화 계층 연산 부담↓
  - 네트워크 전송량↓
조직 간 데이터 사일로를 완화하는 “장벽 추상화”로 쓰일 수 있고,
데이터 메시 논의와도 연결됨

6) 스트리밍 변환과 처리

6-1. 기본 관점

스트리밍은 “현재 뷰”를 동적으로 유지하는 느낌에 가깝다
변환과 쿼리는 연속체(경계가 고정되지 않음)

6-2. 스트리밍 DAG

Kafka 같은 스트리밍 저장소 + Flink 같은 스트림 프로세서 조합으로 구성 가능
잘못 만들면 “루브 골드버그 장치”처럼 복잡해질 수 있음

6-3. 마이크로배치 vs 진정한 스트리밍

마이크로배치: 배치 프레임워크를 스트리밍처럼(2분→1초까지)
진정한 스트리밍(Beam/Flink): 이벤트를 하나씩 처리
윈도/트리거 기반으로 배치처럼 처리하며
윈도 빈도/대기시간/지연 허용 등을 조정

결론적으로:

도메인 지식 + 실무 테스트를 대체할 수 있는 건 없다.

7) 함께 일할 담당자

7-1. 업스트림 이해관계자

비즈니스 정의 관리 담당자
데이터 생성 시스템 관리 담당자
알아야 할 것:
- 데이터 원천이 무엇이고 어떻게 쓰이는지
- 비즈니스 로직/정의
- 모델 설계/갱신 과정 참여
- 쿼리/변환이 원천 시스템에 주는 영향 최소화

7-2. 다운스트림 이해관계자

변환 단계는 다운스트림에 직접 가치를 제공
요구:
- 성능: 최대한 빠르고 비용 효율적으로
- 유용성: 품질/완전성 확보, 워크플로·데이터 제품에 통합 가능

8) 드러나지 않는 요소(Hidden Layers)

보안

서로 다른 데이터 집합 간 결합이 많아질수록
접근 권한/권한 경계 관리가 중요해짐

데이터 관리

변환은 “새로운 데이터셋”을 만들어 관리 부담을 증가시킴
기대치/명명 규칙/정의 정확성 필요
시맨틱·메트릭 계층 고려
데이터 계보(Lineage)는
- 엔지니어(변환 이해)
- 분석가(출처 파악)
- 모두에게 필요
법령 준수: 마스킹/난독화 등

데이터 옵스

데이터/시스템 변경 이상 감지 및 알림
품질 모니터링
성능 모니터링: 대기열 길이, 동시성, 메모리/스토리지, 네트워크 지연, 디스크 I/O
비용 관리 및 최적화

데이터 아키텍처

데이터를 파괴하지 않고 변환 가능한 시스템 구축
모델이 수집/스토리지와 어떻게 맞물리고,
쿼리가 어떻게 수행되는지까지 포함해 설계

오케스트레이션

단순 크론에서 시작하더라도
복잡해지면 의존성 기반(워크플로) 접근이 필요

소프트웨어 엔지니어링

SQL/파이썬/JVM 언어 등 다양한 도구/언어가 섞임
도구별 모범 사례 숙지 필요
dbt 같은 변환 도구 + CI/CD 파이프라인
GUI 기반 로우코드 도구도 워크플로 시각화에 도움
“깔끔하고 성능 좋은 코드” 자체가 중요한 역량

[견고한 데이터 엔지니어링] CH7 3단계: 데이터 수집

EUG — Sat, 31 Jan 2026 18:39:55 +0900

1) 데이터 수집이란

1-1. 정의

데이터 수집(Data Ingestion): 데이터를 한 장소에서 다른 장소로 옮기는 프로세스
원천 시스템 → 스토리지로 이동하며, 수집은 그 사이 “중간 단계”에서 발생

1-2. 데이터 수집 vs 데이터 통합

수집: A → B 로 “이동”
통합: 서로 다른 데이터를 결합해 “새 데이터셋 생성”

1-3. 수집은 ‘시스템 내부 수집’과 다르다

시스템(앱) 내부에서 로그를 쌓는 것과 달리, 데이터 엔지니어링에서 수집은:

데이터 파이프라인의 일부이며
이 시점부터 데이터 엔지니어가 파이프라인을 적극적으로 설계하기 시작한다.

여기서 등장하는 대표 패턴들:

ETL(전통적)
ELT(새로운 패턴)
역 ETL(확립된 관행이지만 새로운 명명도 많음)
데이터 공유(수집/이동의 또 다른 형태)

2) 수집 단계의 주요 엔지니어링 고려 사항

2-1. 유한 데이터 vs 무한 데이터

무한 데이터: 이벤트가 산발적/지속적으로 발생(스트림)
유한 데이터: 시간 경계 등으로 버킷화된 데이터(배치)

“모든 데이터는 유한해질 때까지 무한하다”

-> 결국 수집 설계는 “언제/how로 유한화할 건지” 선택이 들어간다.

2-2. 빈도(Frequency)

수집 빈도는 배치/마이크로배치/실시간(실시간에 가까움)까지 스펙트럼이다.

매우 느림: 연 1회 회계법인에 세무 데이터 전송
빠름: CDC로 1분마다 변경 로그 취득
더 빠름: IoT 센서 이벤트를 지속 수집해 수 초 내 처리

포인트:

“실시간”은 사실 “실시간에 가까움”이 더 정확
다운스트림은 여전히 배치 처리가 표준인 경우가 많음(ML 학습도 배치 단위가 흔함)
스트리밍 시스템은 데이터 원천 유형에 적합할 때 의미가 큼
(예: Kinesis, Kafka)

2-3. 동기 수집 vs 비동기 수집

동기 수집(Synchronous)

원천–수집–대상이 밀접 결합
의존성이 커지고, 순서가 강제됨
(예: 웨어하우스 로드 전에 반드시 변환해야 한다)
배치 처리에서 “모든 데이터가 수집될 때까지” 다운스트림 시작 불가

비동기 수집(Asynchronous)

수집 즉시 스토리지에서 사용 가능
마이크로서비스 환경처럼 “이벤트 단위”로 잘 맞음
각 단계가 병렬로 항목을 처리 가능

예시 흐름

애플리케이션 → Kinesis Data Streams → Apache Beam → Kinesis Data Streams → Firehose → S3
여기서 Kinesis Data Streams는 충격 흡수 장치(버퍼) 역할을 한다.

2-4. 직렬화/역직렬화

직렬화: 원천에서 데이터를 인코딩해 전송/중간저장에 적합하게 준비
수집 단계에서 중요한 체크:
- 받는 쪽이 역직렬화 가능한가?
- 스키마/포맷 호환이 깨지면 수집 자체가 멈춘다.

2-5. 처리량과 확장성(Throughput & Scalability)

수집이 병목이 되면 전체 파이프라인이 멈춘다.
데이터 생성 속도는 일정하지 않다(스파이크/폭발적 트래픽)
데이터 손실 방지를 위해 내장 버퍼링이 필요
샤드/워커/서버 추가를 수동으로 할 수는 있지만…

-> 결론은 자동화(오토스케일/프로비저닝)

2-6. 신뢰성과 내구성(Reliability & Durability)

신뢰성: 높은 가동시간, 장애 조치
내구성: 데이터 손실/손상 방지

특히 IoT 장치/캐시 계층처럼

한 번 놓치면 다시 수집이 어려운 데이터는
중복성/자가복구 설계가 중요하다.

비용 관점:

직접 비용: 클라우드 비용, 인건비
간접 비용: 팀 전체 생산성/운영 부담

2-7. 페이로드(Payload)

페이로드는 “옮길 데이터셋”이며 아래 특성을 가진다.

종류(Types & Formats)

유형(type): 표, 이미지, 비디오, 텍스트
형식(format): CSV, Parquet 등

형태(Shape)

차원/구조(예: 딥러닝 입력 RGB)
예: CSV에 열이 너무 많으면 DB 임포트 오류 발생

크기(Size)

바이트 수
청크로 분할해 작은 단위로 이동시키는 전략이 흔함

스키마와 데이터 유형

비정형(텍스트/이미지/오디오)은 명시 스키마가 없을 수 있음
대신 인코딩/형태/크기/파일 설명(기술 메타데이터)이 따라오기도 함
업/다운스트림 스키마 변경을 “검출/처리”해야 함
스키마 변경은 staging~downstream 파이프라인을 멈출 수 있음

스키마 레지스트리

메시지마다 스키마가 있는 스트리밍 환경에서 핵심
스키마 버전/이력 관리
생산자/소비자 간 직렬화/역직렬화를 가능하게 함

메타데이터

페이로드는 종종 메타데이터를 포함
메타데이터 = “데이터에 대한 데이터”

2-8. 푸시 vs 풀 vs 폴링

푸시: 원천이 대상으로 송신
풀: 대상이 원천에서 읽음
폴링: 원천에 변화가 있는지 정기 점검 후, 있으면 풀

3) 배치 수집 고려사항

3-1. 시간 간격 배치 vs 크기 기반 배치

시간 간격 배치: 전통 ETL(웨어하우징)에서 흔함
크기 기반 배치: 스트리밍 → 객체 스토리지 이동에서 흔함
(데이터를 블록 단위로 잘라 객체로 적재)

3-2. 스냅숏 vs 차등(증분) 추출

전체 스냅숏: 매번 현재 상태 전체 캡쳐 ->단순해서 일반적
차등/증분 갱신: 마지막 읽은 이후 변경분만 ->네트워크/스토리지 사용 최소화에 이상적

3-3. 파일 기반 익스포트 & 수집

원천 측에서 익스포트 프로세스를 실행
전처리 제어 가능
전달 방법: 객체 스토리지, SFTP, EDI, SCP 등

3-4. ETL vs ELT

추출(Extract): 원천에서 가져옴(푸시/풀 가능)
- 메타데이터 읽기, 스키마 변경 처리 포함될 수 있음
적재(Load): 변환 후 적재하거나, 변환 전 스토리지에 “일단 적재”할 수도 있음
주의점:
- 대상 시스템 유형
- 스키마
- 적재가 성능에 주는 영향

3-5. 입력/갱신/배치 크기

적은 수의 대규모 배치 vs 많은 수의 소규모 배치
→ 소규모 배치를 너무 많이 하면 성능 저하 가능
시스템 별 특성이 큼:
- Druid/Pinot: 높은 삽입 속도
- SingleStore: OLAP+OLTP 하이브리드
- BigQuery: 단일 행 입력은 약하지만 스트리밍 버퍼 공급 시 성능 우수

3-6. 데이터 마이그레이션

특정 테이블/전체 DB 이동 등 대량 이동이 발생
시스템마다 스키마 처리 방식에 미묘한 차이
데이터 시스템은 개별 행/이벤트보다 대량 이동에서 성능이 가장 좋다

4) 메시지 & 스트림 수집 고려사항

4-1. 스키마 진화

이벤트 데이터 처리에서 특히 자주 발생.

대응 방법

스키마 레지스트리로 변경 버전화
데드레터 큐로 처리 실패 이벤트 조사
저품질 루트는 업스트림과 정기 소통해 “수신측 뒷처리” 대신 “변경 자체를 함께 관리”

4-2. 늦게 도착하는 데이터(Late-arriving)

IoT/네트워크 지연 등으로 이벤트가 늦게 도착
이벤트 시간 ≠ 수집/처리 시간
“컷오프 시간”을 정해 더 이상 처리하지 않을 기준이 필요

4-3. 순서/중복 전달(Ordering & Duplication)

분산 스트리밍 플랫폼에서는 순서 보장/중복 전달 문제가 현실적으로 발생할 수 있다.

4-4. 재생(Replay)

RabbitMQ: 보통 소비 완료 후 메시지 삭제
Kafka/Kinesis/PubSub: 보존 + 재생 지원
특정 시점으로 이벤트 기록을 되감아 재처리 가능

4-5. 유효시간(TTL)

TTL 만료 후 수집되지 않은 이벤트는 사라질 수 있음
배압 완화, 불필요 이벤트량 감소에 도움
예시:
- GCP: 7일
- Kinesis: 364일
- Kafka: 무기한 설정 가능

4-6. 메시지 크기 제한

프레임워크가 최대 메시지 크기를 처리 가능한지 확인
예시:
- Kinesis: 1MB
- Kafka: 기본 1MB(설정으로 20MB+ 가능)

4-7. 에러 처리 & 데드레터 큐(DLQ)

토픽 없음 / 크기 초과 / TTL 만료 등으로 실패한 이벤트를 DLQ로 재라우팅해 조사한다.

4-8. 소비자 풀 vs 푸시

Kafka/Kinesis: 풀 기반 구독만 지원
Pub/Sub, RabbitMQ: 푸시 구독도 지원 가능

4-9. 위치(Location)

데이터 생성 위치와 가까울수록 대역폭/지연시간 개선
중복성과 소비 효율을 위해 멀티 리전에 스트리밍을 통합하는 선택도 가능

5) 데이터 수집 방법(현실 옵션들)

5-1. 직접 DB 연결(JDBC/ODBC)

ODBC: 드라이버로 쿼리 결과를 표준 형식으로 변환
JDBC: JDBC API ↔ DB 네이티브 네트워크 인터페이스 변환 계층
병렬 연결/쿼리 분할로 수집 가능하지만 원천 DB 부하 증가
네이티브 중첩 데이터 처리 어려움 → 우회로 파일 익스포트(Parquet/ORC/Avro 등)
클라우드 DW는 REST API도 제공하는 경우가 많음

5-2. 변경 데이터 캡처(CDC)

배치 지향 CDC

updated_at 같은 필드로 “특정 시점 이후 변경 행”만 추출
타깃 테이블을 차등 갱신
제약: “그 행에 적용된 모든 변경 이력”은 놓칠 수 있음→ 입력 전용 스키마로 완화 가능
(은행 인출 예시처럼 최종 잔액만 보일 수 있음)

연속 CDC

모든 쓰기를 이벤트로 처리 → 거의 실시간 복제/스트리밍 분석 가능
대표: 로그 기반 CDC
- DB 바이너리 로그가 변경 사항 기록
- CDC 도구가 로그를 읽고 Debezium+Kafka 같은 타깃으로 전송
관리형 CDC 패러다임
- 변경 시 서버리스 함수 트리거/이벤트 스트림 기록
- 캡처/전송 세부사항을 덜 신경씀

CDC와 DB 복제

스트림에 버퍼링 후 2차 DB에 비동기 기록 가능
동기 복제는 동일 DB 타입 요구(예: PostgreSQL→PostgreSQL)
읽기 복제본으로 쿼리 리다이렉트(배치 수집에도 자주 사용)
비동기 CDC 복제 장점: 느슨하게 결합된 아키텍처

CDC 고려사항

메모리/디스크/CPU/네트워크/스토리지 등 리소스 소비
부하 완화: 업무 외 시간, 읽기 복제본 활용 등

5-3. API 기반 수집

벤더가 클라이언트 SDK 제공
SaaS/OSS/관리형 OSS 커넥터 플랫폼이 존재(턴키 연결 + 커스텀 커넥터 프레임워크)
데이터 공유의 등장: BigQuery/Snowflake/Redshift/S3 같은 표준 플랫폼으로 교환
관리형 서비스는 스케줄링/동기화/실행 세부사항을 대신 처리하지만,
지원 안 되는 API는 결국 커스텀 작업 필요

5-4. 메시지 큐 & 이벤트 스트리밍

메시지: 개별 이벤트 단위, 확인 후 삭제되는 경우 많음
스트림: 정렬된 로그로 수집, 일정 기간 유지, 재생 가능
실시간 파이프라인에서는 짧은 지연시간 + 충분한 파티션/대역폭/처리량 프로비저닝이 핵심

5-5. 관리형 데이터 커넥터(추천 포인트)

커넥터를 직접 만들기 전에 먼저 자문:

“이미 있는 관리형 커넥터가 있나?”

관리형 커넥터는 보통:

원천/타깃 설정, 권한/자격증명, 주기 구성
실패 시 경고 + 원인 정보 제공
운영/모니터링 부담을 크게 줄여줌

5-6. 객체 스토리지로 데이터 이동

객체 스토리지는 멀티테넌트 대규모 저장에 강함
데이터 레이크 안팎/팀 간/조직 간 데이터 전송에 이상적
단기 접근도 가능하고 다양한 파일 크기/유형 지원

5-7. EDI(전자 문서 교환)

이메일/플래시 드라이브 같은 “비정형 교환”까지 포함해 지칭
자동화 패턴:
- 파일 수신 → 객체 스토리지 저장 → 조정 프로세스 트리거 → 수집 처리

5-8. DB/파일 익스포트

트랜잭션 시스템에 큰 부하(대용량 스캔)
부하 완화 전략 필요:
- 실행 시점 조정
- 키 범위/파티션 단위로 쿼리 분할
- 읽기 복제본 활용
클라우드 DW는 파일 익스포트에 최적화된 경우가 많음

5-9. 공통 파일 형식의 실질적 문제

CSV는 에러가 나기 쉬움
- 구분자/따옴표/이스케이프 등 처리 필요
- 스키마 정보 내장 X, 중첩 구조 지원 X
표현력 있는 형식:
- Parquet, Avro, Arrow, ORC, JSON
중첩 데이터:
- JSON은 내부 중첩 가능
- 컬럼형 엔진은 Parquet/Arrow/ORC 선호

5-10. 셸/CLI

스크립팅으로 수집 트리거 가능
클라우드 벤더는 CLI 기반 도구 제공 → 수집 워크플로에서 자주 사용

5-11. SSH / SFTP / SCP

SSH:
- SCP로 파일 전송
- SSH 터널로 DB에 안전한 격리 연결(중간 호스트/bastion)
SFTP/SCP:
- 보안 파일 전송 기술로 숙지 필요
- 네트워크 접근 제어(심층 방어) 설계가 중요

5-12. 웹훅(Webhook)

“역 API”
공급자가 API를 제공하는 대신, 소비자가 “호출될 엔드포인트”를 제공
취약/유지보수 어려움/비효율이라는 단점이 큼

AWS 패턴 예시

이벤트 수신 → Lambda → 버퍼링(Kinesis) → 실시간 분석(Flink) → 장기저장(S3)

5-13. 웹 인터페이스 / 웹 스크레이핑

웹 스크레이핑 주의

서드파티 데이터 대안이 있는지 먼저 검토
트래픽 속도 조절(DoS처럼 보이면 차단될 수 있음)
법적 의미 주의
HTML 구조가 자주 바뀌어 유지보수 어렵다

5-14. 전송 어플라이언스(대량 마이그레이션)

100TB 이상이면 인터넷 전송은 느리고 비쌈
물리 장치로 옮기는 방식 권장
AWS Snowball(임포트/익스포트), Snowmobile(페타바이트급)

하이브리드/멀티클라우드에서도 유용:

Snowball → 다른 어플라이언스 → GCP/Azure로 이동 가능

5-15. 데이터 공유

공급자가 가입자에게 데이터셋을 유료/무료 제공
보통 읽기 전용
소비자는 자체 데이터와 통합 가능하지만 “소유”하진 않는다

6) 함께 일할 담당자

6-1. 업스트림 이해관계자

소프트웨어 엔지니어/앱 팀이 “데이터 변경”을 공유하지 않으면 파이프라인 회귀가 발생
변경 사항에 대한 소통이 중요(스키마/이벤트 의미/로그 정책 등)

6-2. 다운스트림 이해관계자

데이터 과학자/분석가/ML 엔지니어/CTO 같은 실무자와 리더
동시에 마케팅/공급망/CEO 등 비즈니스 이해관계자도 최종 고객일 수 있음

-> 데이터 엔지니어링은 결국 “비즈니스”다.

7) 드러나지 않는 요소(Hidden Layers)

보안

위치 간 전송은 보안 취약점이 되기 쉬움
VPC 내부 이동은 안전한 엔드포인트 사용
클라우드↔사내 네트워크는 VPN/전용회선 등 비공개 연결 고려

데이터 관리

수집은 카탈로그 작성의 시작점
스키마 변경은 다운스트림 중단을 유발할 수 있음
(버전 제어, 개발/스테이징 버전 지원 등 필요)
윤리/개인정보보호/컴플라이언스:
- 해싱/토큰화(익명화)
- 민감 데이터는 암호화/윤리 규범 준수
- 개발/스테이징에서 “완전 해결 어려운” 비접촉 운영 현실도 고려

데이터 옵스

수집 단계는 모니터링이 특히 중요
가동시간/지연시간/처리 볼륨부터 시작
업스트림 이벤트 수, 평균 이벤트 크기, 서드파티 의존성까지 포함
테스트/배포 자동화, 실패 시 롤백 가능성 확보

데이터 품질 테스트

엔트로피가 높아 “예고 없이” 바뀔 수 있음
바이너리 룰 기반 감지(예: null이어야 하지 않을 곳에 null)
실패율/지연시간 임계치 모니터링
변화가 고객 행동 때문인지, 봇 트래픽인지 해석 필요
근본 해결은 소프트웨어 엔지니어와 협력해 upstream에서 해결하는 게 가장 강함

오케스트레이션

초기 성숙도는 크론잡 기반(취약, 배포/개발 속도 저하)
오케스트레이션 시스템은 작업을 올바른 시간에 시작/조정한다

소프트웨어 엔지니어링

수집은 엔지니어링 집약적
버전 관리/코드 리뷰/테스트 필수
원천/타깃 의존이 강한 모놀리식 수집 코드는 피하고 분리 설계 필요

[견고한 데이터 엔지니어링] CH6 2단계: 데이터 저장

EUG — Thu, 29 Jan 2026 23:02:15 +0900

1) 데이터 스토리지의 구성요소

1-1. 스토리지 “추상화” vs 스토리지 “시스템”

저장 이야기를 할 때 가장 먼저 구분해야 한다.

스토리지 추상화(Architecture/Layer)

데이터 레이크
데이터 레이크하우스
데이터 플랫폼
클라우드 데이터 웨어하우스

-> “사용 패턴(저장/쿼리/변환/거버넌스)”을 규정하는 큰 틀

스토리지 시스템(Implementation)

HDFS(하둡 분산 파일 시스템)
캐시/메모리 기반 스토리지
관계형 DB
객체 스토리지(S3 등)
스트리밍 스토리지(카프카 등)

-> “실제로 데이터를 담고 전달하는 기술”

1-2. 스토리지의 기본 구성요소(물리/논리)

스토리지 성능은 결국 아래 구성요소의 조합으로 결정된다.

HDD / SSD / RAM
네트워킹
CPU
직렬화(Serialization)
압축(Compression)
캐싱(Caching)

1-3. HDD(자기 디스크 드라이브)

용량 증가 = 면적 밀도에 의해 확장
전송속도 증가 = 선형 밀도에 의해 확장 (용량과 비례하지 않음)
탐색시간(Seek) + 회전지연(Rotation latency)이 병목이 되기 쉬움

1-4. SSD

플래시 메모리 셀에 전하로 저장
여러 컨트롤러가 병렬로 동작하는 파티션 구조 → 전송속도/IOPS 향상
OLTP 혁신의 핵심(상용 OLTP의 표준)
OLAP에서도 SSD 캐싱으로 자주 접근 데이터 쿼리 성능에 기여

1-5. RAM(임의 접근 메모리)

CPU 주소 공간에 매핑되어 코드/데이터를 저장
휘발성(volatile)
SSD보다 훨씬 빠른 전송 속도와 낮은 탐색 시간
단점: 비용↑, 용량 제약↑ (규모 확장 시 복잡성↑)

1-6. 네트워킹과 CPU

RAID 같은 표준은 단일 서버 내 병렬 디스크 구성을 지원
클라우드 객체 스토리지는 네트워크 기반 분산 + AZ(가용 영역) 단위 복제

AZ는 전력/물/자원 등이 독립된 표준 클러스터 환경으로, 다중 AZ는 가용성과 내구성을 높인다.

CPU는 단순 계산뿐 아니라

읽기 집계, 쓰기 분산
API 처리, 백엔드 구성요소 운영
로드밸런싱 등
스토리지 시스템을 “웹앱”처럼 동작하게 만든다.

-> 결국 네트워크 장치 성능/토폴로지가 고성능의 핵심이다.

1-7. 직렬화(Serialization)

직렬화는 데이터를 평탄화하고 표준 포맷으로 패킹하는 과정이고, 읽는 쪽은 이를 디코딩한다.

JSON/XML/CSV 같은 포맷은 범용 디코딩이 쉽지만 CPU 오버헤드가 커질 수 있음
직렬화 방식은 CPU 오버헤드/쿼리 지연시간에 직접 영향

대표 예시:

컬럼형 직렬화: Parquet
하이브리드 직렬화/테이블 관리: Hudi
인메모리 직렬화: Arrow
저수준 DB 내부 저장도 일종의 직렬화로 볼 수 있음

1-8. 압축(Compression)

고효율 압축의 장점:

디스크 공간 절약
디스크 당 체감 검색 속도 향상
네트워크 전송량 감소

단점:

압축/해제에 CPU 시간과 자원이 추가로 든다.

1-9. 캐싱(Caching)

스토리지 분석에서 캐시 계층을 어디에 두는지는 매우 중요하다.

모든 유형의 스토리지를 캐시 계층 안에 배치하면 유용할 수 있음
반대로 “보관 스토리지”는 역캐시(비상시 접근) 성격
- 백업/보존/컴플라이언스 목적
- 접근 특성은 나쁘지만 비용이 낮음

2) 데이터 스토리지 시스템

2-1. 단일 머신 vs 분산 스토리지

단일 머신: 단순하지만 규모/장애 한계가 뚜렷
분산 스토리지: 여러 서버에 분산 저장/검색/처리 + 중복성(복원성) 확보

2-2. 최종 일관성 vs 강력한 일관성

BASE

기본적으로 가용성을 보장
일관성을 강하게 보장하지 않음
“최선의 노력” 기반 읽기/쓰기

여기서 발생하는 상태:

소프트 상태(soft state): 트랜잭션이 커밋되었는지 불명확할 수 있음

최종 일관성(Eventual Consistency)

어떤 시점 이후에는 읽을 때 일관된 값이 반환됨

강력한 일관성(Strong Consistency)

항상 정확한 값을 보장하려 하지만

쿼리 시간 증가
리소스 사용 증가

일관성은 보통 3가지 레벨에서 결정된다.

DB 기술 자체의 일관성 모델
DB 설정 매개변수
개별 쿼리 수준의 일관성 옵션

(예: DynamoDB는 최종 일관/강력한 일관 읽기 모두 지원)

2-3. 파일 스토리지

파일은 유한 길이의 바이트 스트림이며

추가(append)
임의 접근(random access)
이 가능하다.

디렉터리 탐색은 각 계층의 메타데이터를 따라 포인터를 추적해 내려간다.

로컬 디스크 스토리지

OS가 파일 시스템 관리
저널링, 스냅숏, 중복성, 디스크 암호화/압축 등 지원
일반적으로 “쓰기 후 읽기(read-after-write) 일관성”을 제공

NAS(네트워크 결합 스토리지)

네트워크를 통해 파일 시스템 제공

클라우드 파일 시스템

여러 클라우드/VM/애플리케이션/외부 클라이언트까지 지원하는 관리형 파일 시스템
예: AWS EFS
- 사전 예약 없이 자동 확장
- 사용량 기반 과금
- 로컬 쓰기 후 읽기 일관성, 닫기 후 열기(close-to-open) 일관성 제공

2-4. 블록 스토리지

HDD/SSD가 제공하는 원시 스토리지 단위

클라우드에서 VM의 표준 스토리지 형태로 쓰인다.

블록 스토리지 애플리케이션

트랜잭션 DB는 블록 단위 접근으로 성능 최적화를 수행한다.

RAID

여러 디스크 동시 제어
내구성 향상 + 성능 개선 + 용량 결합

SAN(스토리지 영역 네트워크)

스토리지 풀에서 네트워크 기반으로 가상 블록 장치 제공

클라우드 가상화 블록 스토리지

SAN처럼 동작하지만, 운영/네트워킹 복잡성을 엔지니어가 직접 다루지 않음

예: AWS EBS

EC2 기본 스토리지
볼륨 사용 중 특정 시점 스냅숏 가능

로컬 인스턴스 스토리지

저렴, 낮은 지연시간, 높은 IOPS
복제되지 않음(내구성 약함)
고급 기능 제한
캐시 영역으로 활용 가능

2-5. 객체 스토리지(Object Storage)

S3, Azure Blob, GCS 같은 객체 스토리지는

TXT/CSV/JSON부터 이미지/비디오/오디오까지 모두 저장 가능하다.

특징:

관리/사용이 단순 (서버리스 성격)
키-값 형태
한 번 쓰고 나면 객체는 변경되지 않음(불변성)
병렬 읽기/쓰기 성능이 뛰어나 대규모 분석 엔진에 적합
가용성/내구성에 강함 → 빅데이터에 이상적

데이터 엔지니어링에서의 객체 스토리지

대규모 배치 읽기/쓰기
OLAP 사용 사례에 적합
데이터 레이크의 사실상 표준
비정형 데이터 저장에 최적

객체 조회 방식

실제 디렉터리는 없고, 디렉터리처럼 보이는 키(prefix)로 “디렉터리 시맨틱”을 흉내 낸다.

객체 일관성과 버전 관리

제자리 갱신(append/update) 불가
같은 키로 새 객체를 다시 써야 함
버전 관리는 복구/롤백에 큰 도움

스토리지 클래스(계층)

접근 빈도에 따라 계층화:

Standard / Standard-IA(검색 비용↑ 대신 저장 비용↓)
One Zone-IA(단일 AZ 복제)
Glacier / Glacier Deep Archive(아카이브 계층)

객체 저장소를 파일시스템처럼 쓰기

s3fs, S3 파일 게이트웨이 같은 방식이 존재

2-6. 캐시/메모리 기반 스토리지

Memcached: 쿼리 결과, API 응답 캐싱(키-값)
Redis: 지속성 옵션 포함(목록/집합/스냅숏/저널링 등)

2-7. HDFS(하둡 분산 파일 시스템)

구글 파일 시스템(GFS) 기반
데이터는 블록 단위로 분할
블록 위치 카탈로그를 네임노드가 관리
맵리듀스 모델과 결합해 처리

2-8. 스트리밍 스토리지

예: Apache Kafka

특징:

확장 가능한 스트리밍 프레임워크
과거 데이터 범위를 반환하는 리플레이(replay) 지원 → 표준 검색 메커니즘

2-9. 인덱스, 파티셔닝, 클러스터링

인덱스가 있으면 RDBMS는 초당 수천 행 조회/갱신 가능
컬럼형 저장은 필요한 열만 스캔 → 읽는 데이터 양 감소

행 기반 vs 열 기반

열 기반: 대규모 스캔, 집계, 통계, 복잡 조건 평가에 강함
단점: 개별 행을 다수 비동기로 조회할 땐 비효율적일 수 있음
열 기반 DB는 조인 성능도 크게 개선됨

파티션/클러스터링

파티션: 큰 덩어리로 분할
클러스터링: 파티션 내부를 더 세밀하게 정렬(유사 값 군집)

예: Snowflake의 마이크로 파티셔닝

유사 행을 묶으려는 시도
메타데이터 DB가 조건절에 따라 스캔 범위를 줄여줌

3) 데이터 엔지니어링 스토리지 “추상화” 개요

3-1. 데이터 웨어하우스

표준 OLAP 아키텍처
기술 플랫폼(예: BigQuery, Teradata)
데이터 중앙 집중화를 위한 조직 패턴

3-2. 데이터 레이크

원래는 “원시 데이터의 대규모 저장소”
현재는 컴퓨팅/스토리지 분리와 함께 발전
MPP 계열 기능을 흡수하는 방향으로 변화

3-3. 데이터 레이크하우스

레이크 + 웨어하우스 결합
메타데이터/파일 관리 계층 포함
Delta Lake(데이터브릭스), Apache Hudi, Apache Iceberg 등
테이블 이력, 갱신/삭제, 메타데이터 관리 제공
상호 운용성 이점이 있으나 “항상 테이블 구조가 강제되진 않을 수 있음”

3-4. 데이터 플랫폼

비정형 사용 사례에 강한 객체 스토리지와의 긴밀한 통합이 특징

3-5. Stream-to-Batch 스토리지 아키텍처

람다 아키텍처와 유사:

스트리밍 토픽을 통과하는 데이터
배치 스토리지에 장기 보존 + 배치 쿼리

예:

Kinesis Firehose가 트리거 기반으로 S3 객체 생성
BigQuery는 스트리밍 버퍼로 수집

4) 스토리지의 주요 동향(아이디어)

4-1. 데이터 카탈로그

중앙 집중식 메타데이터 저장소로 다양한 시스템/추상화와 통합된다.

구성요소:

카탈로그 애플리케이션 통합(API 기반 메타데이터 갱신)
자동화된 스캔(레이크/웨어하우스/운영DB에서 메타데이터 수집)
데이터 포털/소셜 계층(검색/관계 시각화/설명 편집)

사용 사례:

조직적 활용(검색/공유/책임)
기술적 활용(테이블 탐색/계보 추적)

-> 레이크하우스의 핵심 구성요소로 “쿼리를 위한 테이블 검색”과 연결된다.

4-2. 데이터 공유

정의된 권한과 함께 특정 데이터셋을 특정 엔티티와 공유하는 능력 자체가 중요한 기능이 됨.

4-3. 스키마: 쓰기 스키마 vs 읽기 스키마

쓰기 스키마: 쓰기 시점에 스키마 준수 강제(전통 DW)
읽기 스키마: 데이터 저장 후 읽을 때 해석(Parquet/JSON 등 내장 스키마 활용)

CSV는 스키마 불일치 문제가 쉽게 발생한다.

4-4. 컴퓨팅과 스토리지의 분리

코로케이션(공동 배치)

낮은 지연시간, 높은 대역폭
HDFS+MapReduce에서 “데이터가 있는 곳으로 작업을 보냄”

분리의 장점

임시성과 확장성: 큰 클러스터를 필요할 때만 띄우고 삭제 가능
내구성과 가용성: 데이터 손실 위험↓, 가동시간↑

하이브리드(분리 + 코로케이션)

멀티티어 캐싱
장기 보관은 객체 스토리지, 처리 단계는 로컬/HDFS/메모리 스토리지 활용

예:

EMR에서 S3 + 임시 HDFS
Spark의 인메모리 의존(고비용 가능)
Druid의 SSD 의존
S3 Select 같은 하이브리드 객체 스토리지 접근

무복사 복제(Zero-copy replication)

물리 복사 없이 객체에 대한 “새 포인터(가상 복사본)”를 생성

4-5. 데이터 스토리지 수명주기(온도/보존/컴플라이언스/비용)

핫: 즉각/빈번 접근, 가장 비쌈(캐시)
웜: 월 1회 수준 접근
콜드: 거의 접근 없음(아카이브)

권장:

자동 수명주기 정책으로 핫→콜드 스필오버 설계
“데이터는 무조건 쌓아야 한다”는 오류를 경계

고려 요소:

가치(즉시 사용/조직 전체 가치)
시간(보유 기간에 따라 가치 변동, TTL)
컴플라이언스(보관 의무)
비용(ROI 관점)

4-6. 싱글 테넌트 vs 멀티 테넌트 스토리지

싱글 테넌트: 테넌트별 격리(리소스 분리)
멀티 테넌트: 단일 DB/스토리지에 여러 테넌트 저장 → 보안/성능/격리 설계가 핵심

5) 함께 작업할 대상

스토리지는 데이터 엔지니어링 인프라의 핵심이기 때문에 데이터 팀만으로 결정하기 어렵다.

보안/거버넌스 조직
플랫폼/인프라 팀
운영 DB/애플리케이션 팀
비용/FinOps 관점의 이해관계자

6) 드러나지 않는 요소(Hidden Layers)

보안

미사용/이동 중 데이터 암호화
세분화된 접근 제어
최소 권한 원칙 실천

데이터 관리

데이터 카탈로그/메타데이터 투자
계보 추적으로 문제 원인 추적 시간 단축
객체 저장소의 데이터 버전 관리(복구/롤백)
GDPR 등 개인정보보호 규정이 설계에 직접 영향

데이터 옵스

스토리지 컴포넌트 감시(서버리스 포함)
데이터 통계/엔트로피 모니터링, 이상 탐지
논리적 불일치 테스트(규칙 기반 검증)

데이터 아키텍처

신뢰성/내구성 고려 설계
업스트림 수집 이후 저장·접근 방식 정렬
다운스트림 쿼리/모델 유형 이해
FinOps 적극 적용

오케스트레이션

파이프라인 흐름과 스토리지가 복잡하게 얽힘
저장 계층의 트리거/배치 생성/카탈로그 갱신 등과 연결됨

소프트웨어 엔지니어링

코드가 스토리지 특성(일관성/성능/비용)과 맞게 동작해야 함
스토리지 인프라를 코드로 정의(IaC), 임시 컴퓨팅 리소스와 함께 운영

[견고한 데이터 엔지니어링] CH5 1단계: 원천 시스템에서의 데이터 생성

EUG — Sun, 11 Jan 2026 17:10:09 +0900

데이터는 어떻게 생성될까?

책에서 데이터는 사실과 수치의 비조직적이고 맥락 없는 집합으로 출발한다. 이 데이터가 “의미 있는 정보”가 되기 전에, 먼저 생성 형태부터 다르다.

아날로그 데이터 vs 디지털 데이터

아날로그 데이터: 음성, 수화, 종이 글, 악기 연주처럼 연속적·물리적 형태
디지털 데이터:
- 아날로그를 디지털로 변환해서 생성되거나
- 디지털 시스템(앱, DB, 로그, 센서)의 기본 산물로 생성됨

원천 시스템(Source System) 유형

원천 시스템은 데이터 엔지니어링 수명주기의 “출발점”이며, 각 유형은 데이터의 형태/속도/품질/스키마를 다르게 만든다.

1) 파일과 비정형 데이터

파일은 바이트 시퀀스이며, 가장 보편적인 데이터 교환 매개체다.

현업에서 자주 보는 소스 파일 형식:

Excel
CSV
TXT
JSON
XML

특징:

쉽고 범용적이지만
스키마/품질/버전 관리가 느슨해지기 쉬움

2) API

API는 시스템 간 데이터를 교환하는 표준 방식이다.

특히 서비스 간 연동에서는 API 연결 유지(인증/버전/호환성)가 큰 과제가 된다.

3) OLTP 데이터베이스(트랜잭션 DB)

애플리케이션 데이터베이스는 애플리케이션 “상태(state)”를 저장한다. 대부분 OLTP(Online Transaction Processing) 특성을 가진다.

짧은 지연시간
높은 동시성
트랜잭션 중심

ACID

원자성(Atomicity)
일관성(Consistency)
독립성/격리성(Isolation)
내구성(Durability)

일부 분산 DB는 최종 일관성처럼 완화된 제약을 쓰기도 한다.

원자적 트랜잭션

여러 변경 사항이 하나의 단위로 커밋됨. “전부 성공” 또는 “전부 실패”를 보장.

트랜잭션+분석 혼합 = 데이터 애플리케이션

트랜잭션 워크로드와 분석 워크로드가 섞인 앱을 “데이터 애플리케이션” 관점으로 부르기도 한다.

4) OLAP 시스템(분석 DB)

OLAP(Online Analytical Processing)은 대규모 분석 쿼리를 위한 시스템이다.
대규모 대화형 분석 쿼리에 적합
개별 레코드 조회에는 비효율적일 수 있음
“OLAP 큐브”에만 국한되지 않음 (현대적 의미 확장)

5) 변경 데이터 캡처(CDC)

CDC(Change Data Capture)는 DB에서 발생하는 각 변경(Insert/Update/Delete)을 추출하는 방식이다.

목적:

실시간 복제
다운스트림 처리용 이벤트 스트림 생성

6) 로그(Logs)

로그는 시스템에서 발생한 이벤트 정보를 수집한다.

예: 웹 서버 트래픽, 사용자 사용 패턴, 시스템 동작 이력

로그는 최소한 다음을 담는다:

누가(시스템/서비스 계정)
무엇을(이벤트 메타데이터)
언제(타임스탬프)

로그 포맷(인코딩)

바이너리 인코딩
반정형 로그(JSON)
비정형 텍스트 로그

로그 해상도(Resolution)

로그에 캡처되는 이벤트 데이터의 “세밀함”

빅데이터 시스템은 모든 로그를 남기지 않고, 커밋 이벤트만 남길 수도 있음.

로그 레벨(Level)

에러/디버깅 등 “기록 조건”을 정의

로그 지연시간(Latency)

배치로 모을지, 실시간으로 흘릴지

7) 데이터베이스 로그(WAL 등)

DB 내부에는 복구/보장을 위한 로그 선행 기록(Write-Ahead Logging) 같은 로그가 존재하며, CDC의 기반이 되기도 한다.

8) CRUD와 입력 전용(Append-only)

CRUD

Create / Read / Update / Delete

RESTful HTTP 요청과 DB의 저장/조회 패턴을 설명하는 기본 단위다.

입력 전용(Append-only) 패턴

업데이트 대신 “변경 이력을 계속 쌓아” 테이블에서 이력을 유지하는 방식

단점:

데이터가 자주 바뀌면 테이블이 급격히 커짐
현재 상태 조회 시 max(created_timestamp) 같은 연산이 필요해 오버헤드 발생

9) 메시지와 스트림

메시지: 시스템 간 전달되는 원시 데이터 (불연속적 신호)
메시지 큐: 비동기 전송 메커니즘
이벤트 스트리밍 플랫폼: 대규모 이벤트 스트림을 저장/전달/처리

시간(Time)의 3가지 관점

데이터 파이프라인에서 시간은 한 종류가 아니다.

이벤트 시간(Event Time): 원본 이벤트가 발생한 시각
수집 시간(Ingestion Time): 시스템이 데이터를 받은 시각
처리 시간(Processing Time): 파이프라인이 처리한 시각

-> 지연, 늦게 도착한 데이터, 재처리(backfill) 설계에 직접 영향을 준다.

원천 시스템의 “실질적인 세부사항” (설계에 직접 영향)

데이터베이스(DBMS) 관점에서 확인할 것

인덱스: 조회 속도 (B-Tree, LSM Tree 등)
쿼리 옵티마이저
확장/분산 방식
모델링 패턴
CRUD 패턴
일관성 모델

관계형 vs NoSQL

NoSQL의 대표 유형:

키-값 저장소
도큐먼트 저장소(컬렉션 기반)
와이드 컬럼 DB
그래프 DB
검색 DB(텍스트 검색/로그 분석)
시계열 DB(정기 측정치, 이벤트 기반 시계열)

큰 차이 포인트

도큐먼트 저장소는 보통 조인이 약하거나 지원하지 않아

정규화 기반 설계가 어렵고, 결과적으로 일관성/중복 문제가 생기기 쉬움.

API의 실무 형태

REST

무상태성(stateless)
호출이 독립적
파이프라인 설정이 단순해지기 쉬움
데이터 동기화 라이브러리/툴이 풍부

GraphQL

쿼리 언어이자 REST 대안
JSON 중심

Webhook

이벤트 기반 전송 패턴
“역 API”라고도 함

RPC / gRPC

원격 프로시저 호출
gRPC는 효율적인 양방향 통신에 강점

데이터 공유 / 서드파티 데이터

멀티테넌트 환경에서는 테넌트 간 데이터 공유를 위한 보안 정책이 중요
데이터 마켓플레이스 같은 외부 데이터 소스도 원천이 될 수 있음
기술의 소비자화로 “모든 기업이 기술 기업”이 되는 흐름(플라이휠)도 배경

메시지 큐 vs 이벤트 스트리밍 플랫폼

이벤트 기반 아키텍처가 보급된 이유:

클라우드에서 설정/관리가 쉬워짐
데이터 앱 증가 → 실시간 트리거 + 준실시간 분석 수요 증가

메시지 큐(Queue)

게시/구독 모델 기반 비동기 전송
메시지 순서/전달 제어 가능

전달 의미론:

Exactly-once(이상적이지만 현실적으로 어렵고 제약이 큼)
At-least-once(중복 가능) → 그래서 멱등성이 중요

멱등성(Idempotency):

한 번 처리한 결과와 여러 번 처리한 결과가 같음

스트리밍 플랫폼(Streaming)

토픽(Topic): 관련 이벤트의 묶음
파티션(Partition): 스트림 분할, 같은 키는 같은 파티션
핫스포팅: 특정 파티션에 메시지가 몰림
내결함성/복원성: 분산 저장으로 레코드 손실 방지

원천 시스템에서 함께 일하는 사람들

원천 시스템은 데이터 팀만의 소유물이 아닌 경우가 많다.

시스템 이해관계자: 소프트웨어 엔지니어, 애플리케이션 개발자(원천 시스템 구축/운영)
데이터 이해관계자: 데이터 접근/소유/제어 주체(IT, 거버넌스 조직, 서드파티 등)

-> 업스트림에서 관계가 꼬이면, 수집 이후 단계가 전부 막힌다.

드러나지 않는 요소가 업스트림에 미치는 영향

보안

저장/전송 구간 암호화
공용 인터넷 vs VPC 같은 프라이빗 네트워크
비밀번호/토큰/자격증명 보관(비밀번호 관리자, SSO)
원천 시스템의 신뢰성/합법성 검증

데이터 관리

거버넌스: 업스트림 데이터가 이해하기 쉬운 방식인가?
데이터 품질/무결성 보장
스키마 변경 예상 및 알림
MDM(마스터 데이터 관리) 체계 존재 여부
개인정보 보호/윤리: 난독화, 최소 접근, 규정 준수

데이터 옵스

자동화: 코드 갱신, 기능 변경 반영
관찰 가능성: 모니터링 설정
사고 대응: 장애 시 오프라인 전환 포함 운영 계획

데이터 아키텍처

신뢰성/내구성/가용성 요구사항
아키텍처 변경이 예상되는지(사람/조직 관점 포함)

오케스트레이션

원천 시스템 접근 가능 여부
수집 주기/빈도(스케줄링)
공통 프레임워크(컨테이너/쿠버네티스) 사용 여부

소프트웨어 엔지니어링

네트워킹 접근성
인증/권한(자격증명)
접근 패턴(API/DB/파일)
오케스트레이션 프레임워크와 통합
병렬화 전략
배포 방식(소스 변경 배포 프로세스)

[견고한 데이터 엔지니어링] CH4. 데이터 엔지니어링 수명 주기 전체에 걸친 기술 선택

EUG — Thu, 8 Jan 2026 23:23:06 +0900

왜 기술 선택이 데이터 엔지니어링 수명 주기 전체에 걸쳐 중요한가

데이터 엔지니어링에서 기술 선택은 특정 단계(수집·저장·변환·서빙)에 국한되지 않는다.

한 번 선택한 기술은

운영 방식,
팀의 생산성,
비용 구조,
미래 확장 가능성

까지 수명 주기 전체에 장기적인 영향을 미친다. 따라서 기술 선택은 “최신인가?”가 아니라 “우리에게 맞는가?”의 문제다.

1 팀의 규모와 역량을 먼저 고려하라

카고-컬트 엔지니어링의 위험

소규모 데이터 팀이

대기업의 최첨단 스택이나 복잡한 아키텍처를 그대로 모방하는 것은 카고-컬트 엔지니어링의 전형적인 사례다.

문제점

운영·유지 불가
디버깅 불가능
팀 역량 대비 과도한 복잡성

현실적인 선택

소규모 팀, 기술 성숙도가 낮다면
→ 관리형 도구 + SaaS 적극 활용
팀이 이미 익숙한 기술과 워크플로를 우선 선택

→ 기술은 팀을 돕기 위한 것이지, 팀을 압도하면 안 된다.

2 시장 출시 속도(Time to Market)

빠르게 가치를 전달하지 못하는 기술은

아무리 정교해도 실패할 가능성이 크다.

중요한 기준:

이미 잘 아는 도구인가?
보안과 품질을 유지하면서 빠르게 배포 가능한가?
실험과 반복이 가능한가?

“완벽한 기술”보다 “빨리 전달할 수 있는 기술”이 이긴다.

3 상호 운용성(Interoperability)

기술은 혼자 존재하지 않는다. 항상 다른 기술과 연결되고 정보를 교환한다.

확인해야 할 질문:

다른 시스템과 쉽게 연결되는가?
표준 포맷/프로토콜을 지원하는가?
특정 벤더에 강하게 종속되는가?

⇒ 상호 운용성이 낮을수록 미래 변경 비용은 기하급수적으로 커진다.

4 비용 최적화와 비즈니스 가치

총소유비용(TCO, Total Cost of Ownership)

TCO는 직접 비용 + 간접 비용의 합이다.

직접 비용: 라이선스, 클라우드 사용료 등
간접 비용: 운영 인력, 장애 대응, 학습 비용

구매 방식의 차이

설비투자(CapEx)
→ 초기 대규모 투자, 유연성 낮음
운영비용(OpEx)
→ 종량제, 점진적 지출, 유연성 높음

클라우드는 본질적으로 운영비용 모델이다.

총소유 기회비용

기술·아키텍처·프로세스 선택으로 인해

하지 못하게 되는 것들의 비용도 고려해야 한다.

핀옵스(FinOps)

핀옵스는

클라우드 지출을 데이터 기반으로 관리하고
기술·재무·비즈니스 팀 간 협업을 가능하게 한다.

→ 비용은 사후 정산이 아니라 설계 단계의 요소다.

5 현재 vs 미래: 불변의 기술과 일시적 기술

불변의 기술

오랜 시간 살아남아 온 기술들:

클라우드 핵심 컴포넌트
(객체 스토리지, 네트워킹, 서버, 보안)
언어 및 도구
(SQL, Bash)

일시적 기술

특정 시기에 각광받았다가 사라질 수 있는 기술
예: 프런트엔드 프레임워크, 특정 쿼리 엔진

기술 선택 시 질문

“이 기술이 사라져도 대체할 수 있는가?”

6 장소(Location): 어디에서 실행할 것인가

온프레미스

하드웨어 직접 소유
컨테이너·쿠버네티스·CI/CD 도입 가능
하지만 운영 부담 큼

클라우드

IaaS / PaaS / SaaS
서버리스: 0에서 자동 확장
운영 부담 감소, 민첩성 증가

하이브리드 클라우드

온프레미스 + 클라우드 혼합
예: 온프레미스 Spark → 클라우드 임시 클러스터
대규모 작업을 빠르게 확장 가능

멀티클라우드

여러 퍼블릭 클라우드에 워크로드 분산
장점: 벤더 종속 완화
단점: 데이터 이그레스 비용, 네트워크 병목

탈중앙화: 블록체인과 엣지

데이터가 중앙이 아닌 가까운 위치에서 처리
IoT, 실시간 처리에서 중요

클라우드 송환(Cloud Repatriation)

드롭박스·넷플릭스처럼

규모가 충분하면 자체 인프라가 더 합리적일 수 있음.

⇒ 클라우드는 “항상 정답”은 아니다.

7 구축(Build) vs 구매(Buy)

구축이 필요한 경우

핵심 경쟁 우위를 제공
비즈니스에 직접적인 차별화 요소

구매가 나은 경우

이미 시장에 검증된 솔루션이 존재
운영 부담을 줄이는 것이 더 중요

8 오픈소스 소프트웨어(OSS) 선택 기준

OSS는 자유롭지만 책임도 함께 온다.

확인해야 할 요소:

인지도: GitHub 스타, 포크, 커밋
성숙도: 사용 기간, 실제 활용 사례
문제 해결: 커뮤니티 응답성
프로젝트 관리: 이슈 대응 방식
팀/후원: 기업 후원 여부
커뮤니티: 슬랙/포럼 존재 여부
기여 문화: PR 수용 여부
로드맵: 투명성
자체 호스팅 가능 여부
커뮤니티 환원 가능성

상용 OSS

OSS 기반이지만 상용 서비스로 제공
운영·유지관리 부담 감소
예: 데이터브릭스, 컨플루언트, dbt Labs

고려 요소:

제공 가치
지원 모델
릴리스/버그 수정 주기
가격 정책
회사의 재정적 지속 가능성
커뮤니티 지원 진정성

9 전용 폐쇄형 네트워크 서비스

클라우드 플랫폼 전용 서비스(DB, 스토리지 등)
성능과 편의성은 뛰어남
상호 운용성과 벤더 종속성은 신중히 평가

10 모놀리식 vs 모듈식

모놀리스

단일 시스템
추론이 쉽고 단순
하지만 깨지기 쉽고 확장·변경 어려움

모듈식

시스템을 독립 컴포넌트로 분리
API 기반 통신
리팩터링·교체 용이
다중 언어(polyglot) 가능

단점: 고려할 요소가 많고 운영 복잡성 증가

분산형 모놀리스 패턴

분산되어 있지만 강한 의존성
하나의 작업을 위해 전체 클러스터 라이브러리 필요
해결책: 임시 인프라 + 컨테이너

11 서버리스 vs 컨테이너 vs 서버

서버리스

작은 코드 단위 실행(FaaS)
자동 확장
이벤트가 많으면 비용 증가 가능

컨테이너

경량 가상 머신
쿠버네티스 기반
유연하지만 운영 복잡성 있음

서버 평가 기준

사용량
비용
장애 대응
오토스케일링
IaC 활용 여부

12 성능 최적화와 벤치마크

실제 데이터와 쿼리 크기를 시뮬레이션
과도한 벤치마크 경쟁은 무의미
비대칭 최적화
→ 행 기반 vs 열 기반 시스템의 차이 인식

13 드러나지 않는 요소들 (Hidden Layers)

데이터 관리

보안
개인정보 보호
호스팅 정책

데이터 옵스

배포 통제
모니터링
장애 알림 및 대응

관리형 서비스:

벤더 SLA
문제 인지 방식
복구 ETA

오케스트레이션

Airflow: 성숙하지만 병목 가능
스케줄러/DB 의존성
스키마·계보·카탈로그 미지원

대안:

Prefect
Dagster

소프트웨어 엔지니어링

데이터 스택 단순화
추상화 수준 향상
테스트·배포 자동화

[견고한 데이터 엔지니어링] CH3. 우수한 아키텍처 설계

EUG — Wed, 7 Jan 2026 23:52:42 +0900

왜 데이터 아키텍처가 중요한가

데이터 아키텍처는 단순히 “시스템을 어떻게 구성할 것인가”의 문제가 아니다.

기업이 현재 상태의 문제(품질 저하, 확장성 한계, 비용 증가)에서 바람직한 미래 상태(민첩한 데이터 활용, 확장 가능한 구조, 비즈니스 개선)로 어떻게 이동할지를 정의하는 변화 관리의 도구다.

데이터 아키텍처의 출발점: 엔터프라이즈 아키텍처(EA)

엔터프라이즈 아키텍처란?

엔터프라이즈 아키텍처(EA)는 비즈니스, 기술, 애플리케이션, 데이터, 프로세스, 인프라를 포함하는 기업 전체 또는 특정 도메인의 구조를 의미한다. 여러 프레임워크에서 공통적으로 강조하는 핵심은 다음과 같다.

TOGAF / The Open Group
→ 기업이 보유한 자원과 이들의 상호작용 구조
Gartner
→ 파괴적인 변화에 능동적으로 대응하기 위한 변화 실행의 식별·분석
EABOK
→ 전략·운영·기술을 정렬해 성공으로 가는 로드맵을 만드는 조직 모델

엔터프라이즈 아키텍처는 “현재를 설명하는 그림”이 아니라

“미래로 이동하기 위한 설계”다.

오늘날 EA의 핵심 키워드: 유연성 + 트레이드오프

왜 유연성이 중요한가

세상은 계속 변하고, 미래는 예측 불가능
조직은 성장할수록 구조가 경직되기 쉬움

그래서 현대 아키텍처는

→ 되돌릴 수 있는 의사결정(가역적 결정) 을 선호한다.

가역적 의사결정과 변경관리

단방향 vs 양방향 의사결정

단방향(비가역): 한 번 선택하면 되돌리기 어렵고 리스크 큼
양방향(가역): 실험 가능, 실패 비용이 낮음

변경관리(Change Management)

가역성을 중시해도 기업은 큰 이니셔티브를 수행해야 한다.

변경관리의 핵심은 큰 변화를 작은 단계로 쪼개 관리하는 것이다.

아키텍트의 역할은:

비즈니스 문제를 식별하고
기술 솔루션을 “목적”이 아닌 “수단”으로 설계하며
작고 구체적인 실행 단계를 반복적으로 쌓는 것

데이터 아키텍처란 무엇인가

데이터 아키텍처 정의

데이터 아키텍처는 기업의 데이터 요구사항을 파악하고, 이를 충족하기 위한 마스터 청사진(blueprint) 을 설계·유지하는 활동이다.

이 청사진은:

데이터 통합을 안내하고
데이터 자산을 제어하며
데이터 투자를 비즈니스 전략과 정렬한다

데이터 아키텍처는 트레이드오프를 신중히 평가해 유연하고 되돌릴 수 있는 의사결정을 내리는 시스템 설계다.

운영 아키텍처 vs 기술 아키텍처

운영 아키텍처 (What 관점)

어떤 비즈니스 프로세스를 지원하는가?
데이터 품질은 어떻게 관리되는가?
데이터 생성 시점부터 쿼리 가능 시점까지 허용 지연시간은?
사람·프로세스·조직·기술 요구사항은 무엇인가?

기술 아키텍처 (How 관점)

데이터를 어떻게 수집하는가?
어디에 저장하는가?
어떻게 변환하고 제공하는가?
데이터 엔지니어링 수명 주기를 어떤 시스템으로 구현하는가?

우수한 데이터 아키텍처의 조건

좋은 아키텍처

유연성을 유지
현실적인 트레이드오프 선택
재사용 가능한 공통 컴포넌트 활용

나쁜 아키텍처

권위적이고 획일적인 결정
긴밀 결합, 중앙집중화
비즈니스 변화에 대응 불가

민첩성(Agility)은 데이터 아키텍처의 기반이다.

데이터 엔지니어링 아키텍처 9대 원칙

공통 컴포넌트를 현명하게 선택하라
장애에 대비하라
확장성을 고려해 설계하라
아키텍처는 리더십이다
아키텍처에 충실하라
느슨하게 결합된 시스템을 구축하라
되돌릴 수 있는 의사결정을 하라
보안을 최우선으로 고려하라
핀옵스(FinOps)를 수용하라

공통 컴포넌트를 현명하게 선택하라

공통 컴포넌트와 관행은:

팀 간 협업 촉진
사일로 감소
공유 지식 기반 형성

대표적인 공통 컴포넌트:

객체 스토리지
버전 관리 시스템
관찰 가능성/모니터링
오케스트레이션 시스템
처리 엔진

또한 컴퓨팅과 스토리지 분리는 필요한 데이터에만 접근해 쿼리·처리를 가능하게 한다.

장애에 대비하라: 가용성·신뢰성·RTO·RPO

가용성: 시스템이 정상 작동 상태에 있는 시간 비율
신뢰성: 일정 기간 의도된 기능을 수행할 확률
RTO: 장애 후 허용 가능한 최대 복구 시간
RPO: 허용 가능한 최대 데이터 손실 시점

데이터 시스템은 장애 시 운영 중단 + 데이터 손실이 동시에 발생할 수 있다.

확장성을 위한 아키텍처 설계

스케일 업/아웃: 대규모 부하 처리
스케일 다운: 부하 감소 시 자동 축소
서버리스: 사용하지 않을 때 0에 가까운 확장

로드 스파이크를 측정하고 미래 부하를 예측해 DB/플랫폼 구조의 적합성을 판단해야 한다.

아키텍처는 리더십이다

좋은 데이터 아키텍트는:

기술적으로 유능하고
팀을 멘토링하며
조직 전체의 목표를 기술로 연결한다

아키텍트는 단순 설계자가 아니라 전문 지식을 전파하는 리더다.

아키텍처에 충실하라 (Sequencing Plan)

아키텍트는:

현재 아키텍처를 깊이 이해하고
목표 아키텍처를 정의하며
변경 우선순위와 순서를 담은 시퀀싱 계획을 수립한다

목표 아키텍처는 고정되지 않는다. 비즈니스·기술 변화에 따라 지속적으로 조정된다.

느슨하게 결합된 시스템을 구축하라

느슨한 결합의 특징:

많은 소규모 컴포넌트
API/메시지 기반 상호작용
내부 변경이 외부에 영향 없음
전체 시스템을 묶어 배포하지 않음

기술 구조는 곧 조직 구조로 확장된다.

보안 우선순위: 제로 트러스트

전통적 모델: 내부 신뢰 / 외부 불신
현대 모델: 제로 트러스트

클라우드 환경에서는 데이터 엔지니어도 보안 엔지니어의 책임을 진다

(S3 퍼블릭 액세스 같은 설정 포함).

핀옵스(FinOps)

핀옵스는:

데이터 기반 지출 결정
클라우드 자원/비용 관리
지속적인 비용 모니터링

→ 비용도 아키텍처의 일부다.

주요 아키텍처 개념

도메인과 서비스

도메인: 설계 대상이 되는 주제/업무 영역
서비스: 특정 작업을 수행하는 기능 집합

도메인과 서비스는 사용자·이해관계자와의 대화로 정의한다.

분산 시스템과 확장성

확장성: 용량 증가
탄력성: 동적 확장
분산 시스템: 수평 확장으로 가용성/신뢰성 향상
리더 노드: 워크로드 관리의 중심

공유 디스크 vs 비공유 아키텍처

공유 디스크(shared-disk): 동일 디스크/메모리 접근
비공유(shared-nothing): 각 노드 자원 완전 분리 → 확장성↑

강한 결합 vs 느슨한 결합

강한 결합: 재사용·변경 어려움
느슨한 결합: 독립적 배포/개선 가능

계층형·모놀리식·마이크로서비스

단일/모놀리식: 운영 환경에서 비추천
다층(3-tier): 데이터 → 로직 → 프레젠테이션
마이크로서비스: 도메인 기반 분산 구조

중앙 데이터 웨어하우스는 본질적으로 모놀리식 성향을 가짐.

싱글 테넌트 vs 멀티 테넌트

멀티테넌시는:

성능
보안
데이터 격리
를 반드시 고려해야 한다.

이벤트 기반 아키텍처

상태 변화(Event)를 중심으로

서비스 간 통신을 구성하는 방식.

브라운필드 vs 그린필드

브라운필드: 레거시 점진적 개선(스트랭글러 패턴)
그린필드: 백지 설계

데이터 아키텍처 유형

데이터 웨어하우스

분석/보고 중심 중앙 허브
ELT + CDC + 스트리밍 배치

데이터 마트

특정 부서/LOB 중심
접근성·성능 개선

데이터 레이크

정형/비정형 데이터 중앙 저장

데이터 레이크하우스

레이크 + 웨어하우스
ACID, 관리/제어 강화

모던 데이터 스택

플러그 앤 플레이
모듈식, 비용 효율적

람다 아키텍처

배치 + 스트림 + 서빙 분리

카파 아키텍처

스트림을 데이터 처리 백본으로 사용

IoT 아키텍처

디바이스 → 게이트웨이 → 수집 → 저장 → 서빙

데이터 메시

도메인 기반 분산 데이터 소유
제품으로서의 데이터
셀프서비스 플랫폼
통합 거버넌스

기타:

데이터 패브릭
데이터 허브
메타데이터 우선 아키텍처
라이브 데이터 아키텍처

[견고한 데이터 엔지니어링] CH2. 데이터 엔지니어링 수명 주기

EUG — Sun, 28 Dec 2025 16:31:06 +0900

데이터 엔지니어는 ‘데이터 생명주기 엔지니어’

데이터 엔지니어는 단순히 데이터를 옮기는 사람이 아닌 데이터 수명 주기(Data Lifecycle)를 이해하고 관리하는 엔지니어, 즉 데이터 생명주기 엔지니어로 사고해야 한다.

데이터 엔지니어링 수명 주기란, 원시 데이터를 분석가·데이터 과학자·ML 엔지니어가 사용할 수 있는 ‘최종 데이터 제품’으로 전환하는 전 과정을 의미한다.

(https://books.google.co.kr/books?id=cOvLEAAAQBAJ&pg=PT62&hl=ko&source=gbs_selected_pages&cad=1#v=onepage&q&f=false)

데이터 수명 주기 vs 데이터 엔지니어링 수명 주기

데이터 수명 주기 → 데이터가 생성되고, 사용되고, 보관·파기되는 전체 생애
데이터 엔지니어링 수명 주기→ 그중에서도 데이터 엔지니어가 직접 설계·운영하는 영역

즉, 데이터 엔지니어링 수명 주기는 데이터 수명 주기의 하위 집합이다.

데이터 엔지니어링 수명 주기의 전체 흐름

데이터 엔지니어링 수명 주기는 다음 흐름으로 구성된다.

데이터 생성 (원천 시스템)
데이터 저장
데이터 수집
데이터 변환
데이터 서빙

그리고 이 모든 단계에 드러나지 않는 공통 요소들이 겹쳐 있다.

1 데이터 생성: 모든 것은 원천 시스템에서 시작된다

원천 시스템(Source System)은 데이터 엔지니어링 수명 주기에서 사용되는 모든 데이터의 출발점이다.

중요한 점은, 데이터 엔지니어는 원천 시스템을 소유하지 않는 경우가 대부분이라는 것.

그래서 데이터 엔지니어는 다음을 이해해야 한다.

원천 시스템을 평가할 때 고려할 사항

데이터 원천의 성격
(애플리케이션 DB인지, IoT 디바이스 스웜인지)
데이터 보존 방식
(장기 보존 vs 일시적 데이터)
생성 빈도와 속도
(이벤트 발생량, 트래픽)
데이터 품질 문제
(NULL, 잘못된 포맷, 중복, 오류)
늦게 도착하는 데이터(Late-arriving data)
스키마 구조 및 스키마 변경 대응
데이터 수집 주기

핵심은 원천 시스템의 한계를 이해하고, 소유자와 지속적인 소통 라인을 유지하는 것

스키마: 가장 까다로운 차이점

원천 시스템마다 스키마 처리 방식이 다르다.

고착 스키마 (Schema-on-Write) → 관계형 데이터베이스
스키마리스 또는 유연한 스키마 (Schema-on-Read) → 메시지 큐, 플랫 파일, 객체 스토리지, MongoDB 같은 도큐먼트 DB

이 차이는 이후 데이터 저장·변환·서빙 설계에 직접적인 영향을 준다.

2 데이터 저장: 모든 단계에 관여하는 핵심 요소

데이터 저장은 단순한 “보관”이 아니다. 수집·변환·서빙 모든 단계에 지속적으로 관여한다.

대표적인 데이터 저장소

데이터 웨어하우스
데이터 레이크 / 레이크하우스
객체 스토리지
스트리밍 플랫폼 (Kafka, Pulsar 등)

최근에는 하나의 시스템이 저장 + 처리 + 쿼리를 동시에 수행하기도 한다.

데이터 온도(Data Temperature)

데이터 저장 전략은 접근 빈도, 즉 데이터 온도를 기준으로 나뉜다.

핫 데이터: 자주 조회되는 데이터
웜 데이터: 주기적으로 조회되는 데이터
콜드 데이터: 거의 조회되지 않는 아카이브 데이터

-> 비용 최적화와 직결되는 개념이다.

3 데이터 수집: 가장 큰 병목 지점

데이터 수집은 원천 시스템과 데이터 엔지니어링 수명 주기가 만나는 병목 구간이다.

수집 설계 시 반드시 던져야 할 질문들:

이 데이터는 어떤 사용 사례를 위한 것인가?
데이터를 재사용할 수 있는가?
시스템은 안정적으로 데이터를 생성·전송하는가?
수집 후 목적은 무엇인가?
접근 빈도와 데이터 용량은?

배치 vs 스트리밍

배치 수집 → 데이터를 일정 단위(청크)로 처리
스트리밍 수집 → 실시간 또는 준실시간 처리

데이터는 본질적으로 스트리밍이며, 배치는 이를 묶어서 처리하는 방식

푸시 vs 풀 수집 모델

푸시 모델 → 원천 시스템이 데이터를 타깃으로 직접 전송
풀 모델 → 수집 시스템이 원천 시스템에서 데이터를 가져옴

ETL의 Extract(E) 는 대표적인 풀 모델이다.

CDC(Change Data Capture)

CDC는 데이터베이스의 변경 사항만 캡처하는 방식이다.

대표적인 구현 방식:

행 변경 시 이벤트 발생 → 메시지 큐로 전송

-> 원천 시스템에 부담을 최소화하면서 증분 데이터 수집이 가능하다.

4 데이터 변환: 데이터에 의미를 부여하는 단계

수집·저장된 데이터는 그 자체로는 바로 쓸 수 없다.

변환 단계에서 수행하는 작업:

데이터 타입 변환
(문자열 → 숫자 / 날짜)
잘못된 데이터 제거
이벤트 타임스탬프 추가
비즈니스 로직 적용
데이터 보강(필드 계산)

변환은

배치로 수행할 수도 있고
스트리밍 중 실시간으로 수행할 수도 있다.

데이터 특성화(Feature Engineering)

변환의 한 형태로, 유용한 데이터 특성을 추출·강화하는 작업이다.

머신러닝과 직접적으로 연결된다.

5 데이터 서빙: 데이터가 가치를 만드는 순간

데이터는 사용될 때만 가치가 있다. 그래서 데이터 서빙은 수명 주기의 핵심 목표다.

주요 데이터 서빙 방식

분석 (Analytics)

BI 대시보드
임시 분석
셀프 서비스 분석

기업의 데이터 성숙도가 높아질수록 IT 개입 없이 비즈니스 사용자가 직접 분석한다.

운영 분석 (Operational Analytics)

실시간 재고 현황
웹·애플리케이션 상태 대시보드

임베디드 분석 (Embedded Analytics)

고객 대면 분석
멀티테넌시 환경에서 접근 제어 중요

머신러닝

특성 저장소(Feature Store)
백필링 지원
모델 운영과 연결

역 ETL

(https://books.google.co.kr/books?id=cOvLEAAAQBAJ&pg=PT62&hl=ko&source=gbs_selected_pages&cad=1#v=onepage&q&f=false)

데이터 웨어하우스 → CRM/CDP로 데이터 전송
(잘못 쓰면 안티패턴이 될 수 있음)

데이터 엔지니어링 수명 주기의 드러나지 않는 요소들

이 요소들은 모든 단계에 걸쳐 존재하지만 눈에 잘 드러나지 않는다.

보안(Security)

보안 최우선 원칙
최소 권한 원칙(Least Privilege)
필요한 데이터에, 필요한 기간 동안만 접근 허용

데이터 관리(Data Management)

데이터 관리란 데이터 자산의 가치를 제공·보호·제어·향상하기 위한 전사적 활동이다.

데이터 거버넌스 핵심 범주

발견 가능성
보안
책임

하위 영역:

데이터 품질
메타데이터
개인정보 보호

메타데이터란?

데이터에 대한 데이터

비즈니스 메타데이터
기술 메타데이터
운영 메타데이터
참조 메타데이터

데이터 카탈로그, 계보 추적 시스템, 메타데이터 관리 도구가 중요해진 이유다.

데이터 품질

정확도
완전성
적시성

마스터 데이터 관리(MDM)는 골든 레코드를 정의해 일관성을 유지한다.

데이터 옵스(DataOps)

DataOps는 애자일, DevOps, 통계적 공정 관리를 데이터 영역에 적용한 실천 방법론이다.

DataOps의 목표

빠른 실험과 혁신
높은 데이터 품질
낮은 오류율

DataOps 3대 요소

자동화
모니터링 및 관찰 가능성
사고 대응

오케스트레이션 도구(Airflow, Dagster 등)는 DataOps의 핵심이다.

데이터 아키텍처

데이터 아키텍처는 조직의 장기적인 데이터 전략과 현재·미래 상태를 연결한다.

데이터 엔지니어 ≠ 데이터 아키텍트 이지만 강하게 협업한다.

오케스트레이션

오케스트레이션이란, 여러 작업을 올바른 순서로, 안정적으로 실행되도록 조정하는 것이다.

고가용성
자동 감지 및 실행
사용자 개입 최소화

소프트웨어 엔지니어링 역량

현대 데이터 엔지니어는 다음 역량을 요구받는다.

Spark, SQL, Beam 활용 능력
데이터 프레임 기반 처리
테스트 전략 이해
스트리밍 처리 개념
코드형 인프라(IaC)
코드형 파이프라인