Post

ML Systems Data Fundamentals

Posted Updated
By Hoon
11 min read
ML Systems Data Fundamentals

앞선 정리에서는 데이터 소스, 포맷, 모델을 중심으로
“데이터가 어떤 형태로 저장되는가(파일/스키마/피처 표현)”를 봤습니다.

이번 글은 한 단계 더 내려가서,

데이터가 어떤 저장 엔진에 놓이고
어떤 처리 엔진을 거쳐
어떤 파이프라인(ETL/ELT)로 흘러가며
그 결과가 ML 시스템 품질/비용/운영 안정성에 어떻게 연결되는지

즉, 데이터가 시스템 내부에서 “실제로 움직이는 방식”을 정리합니다.

실무에서 모델 성능 문제가 모델 자체가 아니라
데이터 수집 지연, 조인 누락, 스키마 변경, 배치 실패, 파티션 설계 실패 같은
저장·처리 구조에서 시작되는 경우가 많습니다.
그래서 이 레이어를 이해하면 “왜 문제가 생겼는지”를 더 빨리 찾을 수 있습니다.

데이터 저장 엔진과 처리

데이터 포맷과 모델이 “겉모습(인터페이스)”라면,
스토리지 엔진(데이터베이스/스토리지)은 이를 실제로 디스크/메모리에 저장하고 꺼내는 구현입니다.

전통적으로 데이터 시스템은 크게 두 워크로드에 맞춰 진화해 왔습니다.

  • 트랜잭션 처리용: OLTP (Online Transaction Processing)
  • 분석 처리용: OLAP (Online Analytical Processing)

이 구분은 “누가/무엇이/어떤 속도로 데이터를 읽고 쓰는가”가 다르기 때문에 생겼습니다.

트랜잭션 처리 (OLTP)

OLTP는 “사용자 행동이 발생하자마자 기록하고, 필요한 데이터를 즉시 조회하는” 시스템에 가깝습니다.

  • 예: 트윗 작성, 택시 호출, 결제 승인, 재고 차감, 로그인 세션 갱신
  • 패턴
    • 발생 즉시 삽입(insert), 필요 시 업데이트/삭제
    • 각 요청은 빠르게 끝나는 작은 작업이 많음
  • 요구사항
    • 낮은 지연(latency): 사용자가 기다리지 않도록
    • 높은 가용성(availability): 장애/피크에도 지속 동작
  • 구현 특성
    • “한 행(row)의 상태를 정확히 바꾸는 작업”이 많아 row-major와 잘 맞는 경우가 많습니다.

ACID

OLTP가 흔히 ACID를 강조하는 이유는,
한 번의 요청이 여러 상태를 동시에 바꾸기 때문입니다(결제/배차/재고 등).

  • Atomicity (원자성)
    • 전부 성공하거나 전부 취소
  • Consistency (일관성)
    • DB 규칙/제약(무결성)을 항상 만족
  • Isolation (고립성)
    • 동시에 일어나는 트랜잭션이 서로를 망치지 않게
  • Durability (지속성)
    • 커밋된 결과는 장애 후에도 남아야 함

다만 모든 시스템이 강한 ACID를 요구하진 않습니다.
규모/비용/지연을 고려해, 일부는 BASE(최종 일관성)로 설계되기도 합니다.
(예: “잠깐 늦게 맞춰져도 되는” 로그/추천 피드 같은 영역)

분석 처리 (OLAP)

OLAP는 “많은 데이터를 한 번에 읽고, 집계/통계를 내는” 시스템에 가깝습니다.

  • 예:
    • “지난 분기 상품 A의 국가별 매출은?”
    • “9월 서울 지역 사용자 재방문율은?”
  • 특징
    • 많은 행을 스캔하고, 그룹화/집계 수행
    • 열(column) 단위 연산이 많고 데이터 규모가 큼

그래서 전통적으로 OLTP는 서비스 운영 DB가,
OLAP는 웨어하우스/분석 엔진이 담당하도록 분리해 왔습니다.

OLTP / OLAP 경계 약화와 스토리지–컴퓨트 분리

책에서 OLTP/OLAP 용어가 점점 구식이 된다고 말하는 포인트는, “요즘은 저장과 처리가 1:1로 붙어있지 않기 때문”입니다.

  1. 기술 발전으로 두 영역이 수렴
    • 트랜잭션 DB가 분석 쿼리도 어느 정도 수행
    • 분석 엔진이 부분적으로 트랜잭션성 작업도 수행
  2. 스토리지와 컴퓨트(처리) 분리
    • 과거: 저장 방식이 곧 처리 방식(한 시스템에 결합)
    • 현재: 데이터는 공통 저장소(클라우드 오브젝트 스토리지)에 두고, 워크로드에 맞는 엔진을 붙여서 처리
    • 결과적으로 “어디에 저장했는지”보다 “어떤 엔진으로 처리했는지”가 더 중요해짐
    • 예: BigQuery, Snowflake, Teradata 등
  3. “Online”의 의미 확장
    • 단순히 인터넷 연결이 아니라, 프로덕션에서 즉시 접근 가능/실시간성 요구까지 포괄하는 의미로 사용됨

Online / Nearline / Offline (데이터 가용성 기준)

최근 문맥에서 online은 “접근 가능한 상태”를 뜻하는 경우가 많습니다.

  • Online: 지금 당장 읽기/쓰기 가능
  • Nearline: 자동으로 빠르게 online으로 전환 가능
  • Offline: 사람 개입/복구 절차가 있어야 online 전환 가능

이 구분은 비용/속도/운영 난이도(복구 절차)와 바로 연결됩니다.

ETL(Extract–Transform–Load) 과 ELT

저장 엔진을 이해했다면, 다음은 “데이터가 들어와서 쓸 수 있게 되는 과정”입니다.
ETL/ELT는 결국 검증·정제·변환을 언제/어디서 하느냐의 차이입니다.

ETL: Extract → Transform → Load

관계형 DB 중심 시대부터 쓰여 온 전통적인 파이프라인입니다.

  1. Extract (추출)
    • 여러 소스에서 데이터 수집
    • 포맷 오류/손상/필수 필드 누락 검증
    • 이 단계에서 잘 걸러내면 뒤 단계 비용이 크게 줄어듦
  2. Transform (변환) – “쓸 수 있게 만드는” 핵심
    • 정제(clean), 조인(join), 표준화(값 통일)
    • 중복 제거, 파생 피처 생성, 집계
    • 즉, 모델/분석이 바로 먹을 수 있는 형태로 구조를 맞춤
  3. Load (적재)
    • 타깃 스키마/저장 정책에 맞춰 저장

ETL의 철학은 간단히 말해 “정제한 뒤에 저장”입니다.
그래서 품질은 안정적이지만, 변환 로직이 커지면 유입 지연이 생길 수 있습니다.

ELT: Extract → Load → Transform

클라우드와 데이터 폭증 이후 등장한 방식으로, “먼저 쌓고 나중에 고친다”에 가깝습니다.

  • Extract 후 즉시 Data Lake에 저장

  • 필요할 때 꺼내서 변환(쿼리/잡/파이프라인)

  • 장점
    • 유입이 빠르고, 스키마 변화에 유연
  • 단점
    • 원시 데이터가 쌓여 탐색/정제 비용이 커짐
    • “같은 변환을 여러 팀이 중복 구현”하기 쉬움

최근에는 ELT만 고집하기보다, Raw(원시) + Curated(정제) 레이어를 함께 운영하는 형태가 흔합니다.

Data Lake vs Warehouse vs Lakehouse

이 셋은 “어디에 어떤 상태로 저장하느냐”의 관점입니다.

  • Data Warehouse
    • 정제된 구조화 데이터
    • BI/리포트/모델 학습에 바로 쓰기 좋음
  • Data Lake
    • 원시 데이터 중심(포맷/스키마 제약 적음)
    • 미래 활용 가능성을 위해 일단 저장
  • Lakehouse
    • Lake의 유연성과 Warehouse의 관리/ACID를 결합
    • 동일 데이터 위에서 다양한 워크로드(분석+학습+서빙) 지원
    • 예: Databricks, Snowflake

맺음말

ML 시스템을 이해할 때 모델은 “계산”이고,
데이터 저장/처리는 “현실을 시스템 안으로 끌고 오는 과정”입니다.

결국 성능/비용/운영 안정성은
데이터가 어디에 저장되고, 어떤 규칙으로 정제되며, 어떤 경로로 흘러가는지에 크게 좌우됩니다.
모델은 그 흐름 위에서 동작하는 하나의 컴포넌트일 뿐입니다.

mlops
mlops data storage data processsing
This post is licensed under CC BY 4.0 by the author.