콘텐츠로 이동
Data Prep
상세

데이터 엔지니어링 (Data Engineering)

데이터 엔지니어링의 목적은 데이터를 빠르게 만드는 것이 아니라, 잘못 만들어졌을 때 쉽게 되돌릴 수 있게 하는 것.

설계 판단 프레임

기술 선택 전에 반드시 답해야 할 질문들:

데이터에 대해

질문 의미
늦게 와도 되는가? 실시간 vs 배치 결정
틀려도 되는가? 정확도 vs 속도 트레이드오프
다시 만들 수 있는가? 멱등성, 재처리 가능 여부
누가 이 데이터를 믿고 의사결정을 하는가? 데이터 품질 기준

파이프라인에 대해

질문 의미
끊어져도 되는가? 장애 허용 범위
부분 실패가 허용되는가? 트랜잭션 경계 설정
복구에 얼마나 걸려도 되는가? SLA 정의

왜 이 질문이 중요한가

이 질문들에 답하지 않으면:

  • Kafka vs Batch
  • Lambda vs Medallion
  • Spark vs Flink

이런 논쟁은 전부 의미 없음. 정답은 "상황에 따라 다르다"가 아니라, "목적에 따라 결정됨".

설계 판단 체크리스트

모든 파이프라인 설계 전 확인:

  • [ ] 이 선택은 되돌릴 수 있는가?
  • [ ] 실패 시 영향 범위는 어디까지인가?
  • [ ] 목적이 바뀌면 이 설계는 유지 가능한가?
  • [ ] 1% 오차가 허용되는가?
  • [ ] 하루 늦어도 비즈니스에 문제없는가?

토픽 목록

ETL/ELT

  • ETL과 ELT: 추출, 변환, 적재 파이프라인

데이터 파이프라인

스토리지 시스템

스트리밍 처리

왜 데이터 엔지니어링이 필요한가

분야 관련성
LLM 사전학습 TB~PB 규모 텍스트 처리
파인튜닝 데이터 정제, 형식 변환
RAG 파이프라인 임베딩 생성, 벡터 저장
모델 서빙 실시간 로그 수집, 분석
피드백 루프 사용자 상호작용 저장

데이터 파이프라인 아키텍처

+-------------+    +-----------+    +------------+    +-----------+
|   데이터    |    |   수집    |    |    처리    |    |   저장    |
|   소스      |--->|  (Ingest) |--->|  (Process) |--->|  (Store)  |
+-------------+    +-----------+    +------------+    +-----------+
     |                  |                 |                 |
     |                  |                 |                 v
  API, DB,           Kafka,           Spark,           S3, GCS,
  파일, 웹          Kinesis           Flink            BigQuery

LLM 데이터 파이프라인 예시

원본 데이터 (웹, 책, 코드)
        |
        v
    +--------+
    | 수집   |  -> 크롤링, API, 덤프
    +--------+
        |
        v
    +--------+
    | 정제   |  -> 중복 제거, 품질 필터링
    +--------+
        |
        v
    +--------+
    | 변환   |  -> 토크나이징, 형식 표준화
    +--------+
        |
        v
    +--------+
    | 저장   |  -> Parquet, HDF5, 분산 파일시스템
    +--------+
        |
        v
    +--------+
    | 학습   |  -> 데이터 로더, 배치 생성
    +--------+

학습 우선순위

1. ETL/ELT 개념 (기반)
       |
       v
2. 스토리지 시스템 (데이터 저장)
       |
       v
3. 파이프라인 오케스트레이션 (자동화)
       |
       v
4. 스트리밍 처리 (실시간)

참고 자료