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

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

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

아날로그 데이터 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) 패턴

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

단점:

1. 데이터가 자주 바뀌면 테이블이 급격히 커짐
2. 현재 상태 조회 시 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 이벤트 스트리밍 플랫폼

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

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

메시지 큐(Queue)

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

전달 의미론:

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

멱등성(Idempotency):

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

스트리밍 플랫폼(Streaming)

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

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

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

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

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

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

보안

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

데이터 관리

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

데이터 옵스

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

데이터 아키텍처

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

오케스트레이션

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

소프트웨어 엔지니어링

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