Day 1 - 데이터 엔지니어링이란

회사에 데이터는 넘쳐난다. 주문 DB, 웹 로그, 결제 이벤트, 고객 문의, IoT 센서 값. 그런데 정작 "지난 분기 지역별 재구매율"을 뽑으려면 며칠이 걸리고, 매번 다른 숫자가 나온다. 데이터가 없어서가 아니라, 여러 시스템에 흩어진 원시 데이터를 신뢰할 수 있는 분석 가능한 형태로 옮기고 정제하는 사람이 없어서다. 그 사람이 데이터 엔지니어다.

DEA-C01(AWS Certified Data Engineer – Associate)은 바로 이 "흩어진 원시 데이터에서 분석 가능한 데이터까지"를 AWS 위에서 어떻게 다루는지를 묻는 자격증이다. 오늘은 데이터 엔지니어의 역할, 데이터 파이프라인이라는 개념, 그리고 모든 설계 판단의 출발점이 되는 두 가지 대비축 — OLTP vs OLAP, 데이터레이크 vs 웨어하우스 — 를 본다.

데이터 엔지니어가 하는 일

데이터 엔지니어의 산출물은 모델도 대시보드도 아니다. 파이프라인이다. 원시 데이터가 들어오면 자동으로 정제·변환되어, 분석가·과학자·BI 도구가 바로 쓸 수 있는 형태로 쌓이게 만드는 시스템이다.

분석가가 "왜 매출이 떨어졌나"를 SQL로 파헤친다면, 데이터 엔지니어는 그 SQL이 항상 정확한 최신 데이터를 가리키도록 **그 아래의 배관(plumbing)**을 책임진다. 데이터가 늦게 도착하거나, 중복되거나, 스키마가 깨지면 위층의 모든 분석이 조용히 틀려진다.

💡 관련 이론: 데이터 엔지니어링의 핵심 철학은 "garbage in, garbage out"이다. 아무리 정교한 모델이나 대시보드도 입력 데이터가 부정확하면 무의미하다. 그래서 데이터 엔지니어의 1순위 책임은 화려한 변환이 아니라 데이터 품질과 신뢰성이다. DEA-C01이 수집·변환뿐 아니라 데이터 품질·모니터링·거버넌스를 비중 있게 묻는 이유가 여기 있다.

데이터 파이프라인: ETL과 ELT

데이터를 한 곳에서 다른 곳으로 옮기며 정제하는 흐름을 파이프라인이라 부른다. 고전적인 형태는 ETL이다.

ETL (Extract → Transform → Load)
  추출 → 변환 → 적재
  원천에서 뽑고 → 중간에서 변환하고 → 목적지에 넣는다

ELT (Extract → Load → Transform)
  추출 → 적재 → 변환
  원천에서 뽑고 → 일단 다 넣고 → 목적지 안에서 변환한다

전통적 ETL은 변환을 별도 서버에서 미리 끝낸 뒤 웨어하우스에 깨끗한 데이터만 넣었다. 웨어하우스 저장·연산이 비쌌기 때문이다. 그런데 클라우드에서 S3 같은 저렴한 스토리지와 Redshift·Athena 같은 강력한 쿼리 엔진이 등장하면서 흐름이 바뀌었다. **원시 데이터를 일단 다 적재하고(L), 필요할 때 안에서 변환(T)**하는 ELT가 흔해졌다.

AWS에서 전형적인 파이프라인은 이렇게 생겼다.

[원천 DB/로그/스트림]
        │ Extract
        ▼
   [S3 원시 영역]  ← 저렴하게 일단 다 저장
        │ Transform (Glue / EMR / Athena)
        ▼
  [S3 정제 영역 / Redshift]  ← 분석 가능한 형태
        │
        ▼
   [QuickSight / SageMaker]  ← 소비

💡 관련 이론: ETL과 ELT의 선택은 "변환을 어디서 하느냐"의 문제다. ELT는 원시 데이터를 보존하므로, 나중에 변환 로직이 바뀌어도 원천을 다시 부르지 않고 재처리할 수 있다(reprocessing). 이 "원시 데이터를 버리지 않는다"는 원칙이 다음에 볼 데이터레이크의 핵심 사상이다.

OLTP vs OLAP: 처리의 두 세계

데이터 시스템을 이해하는 가장 중요한 대비축이다. 같은 "데이터베이스"라도 목적이 정반대다.

OLTP는 "1234번 고객의 잔액을 조회하고 1만 원 차감"처럼 소수의 행을 정확하고 빠르게 다룬다. OLAP는 "지난 3년 전 지역 매출을 월별로 집계"처럼 수억 행을 훑어 요약한다.

-- OLTP: 한 행을 정확히 (RDS/Aurora)
UPDATE accounts SET balance = balance - 10000 WHERE account_id = 1234;
 
-- OLAP: 수억 행을 집계 (Redshift/Athena)
SELECT region, DATE_TRUNC('month', order_date) AS m, SUM(amount)
FROM orders
WHERE order_date >= '2023-01-01'
GROUP BY region, m;

데이터 엔지니어의 흔한 임무 중 하나가 OLTP 시스템(운영 DB)에 부하를 주지 않으면서, 그 데이터를 OLAP 시스템(분석 환경)으로 안전하게 복제·이동하는 것이다. 운영 DB에 대고 무거운 집계 쿼리를 날리면 서비스가 느려지기 때문이다.

💡 관련 이론: OLAP가 컬럼형 저장(columnar)을 쓰는 이유가 이 워크로드 차이에서 나온다. 집계 쿼리는 보통 전체 컬럼 중 몇 개만 읽으므로, 컬럼 단위로 저장하면 필요한 컬럼만 스캔해 I/O를 크게 줄인다. Redshift·Parquet이 컬럼형인 배경이다. 컬럼형 vs 행형은 Day 4에서 깊이 다룬다.

데이터레이크 vs 데이터 웨어하우스

저장소 설계의 양대 축이다. 둘은 경쟁이 아니라 보통 함께 쓰인다.

• 데이터 웨어하우스(Warehouse): 스키마를 먼저 정하고(schema-on-write) 정제된 정형 데이터만 넣는다. 구조가 엄격해 쿼리가 빠르고 일관적이지만, 비정형 데이터나 스키마가 자주 바뀌는 데이터는 다루기 어렵다. AWS에서는 Redshift.
• 데이터레이크(Lake): 정형·반정형·비정형을 가리지 않고 원시 그대로 저장하고(schema-on-read), 읽을 때 구조를 입힌다. 유연하고 저렴하지만, 관리하지 않으면 아무도 못 쓰는 "데이터 늪(data swamp)"이 된다. AWS에서는 S3 + Glue Data Catalog + Athena/Lake Formation.

데이터 웨어하우스: schema-on-write
  넣기 전에 스키마 검증 → 깨끗하지만 경직됨

데이터레이크: schema-on-read
  일단 다 저장 → 읽을 때 스키마 적용 → 유연하지만 관리 필요

요즘은 둘의 장점을 합친 레이크하우스(Lakehouse) 패턴이 표준이다. S3 데이터레이크 위에 테이블 형식(Apache Iceberg 등)과 카탈로그를 얹어 웨어하우스급 쿼리·트랜잭션을 제공한다.

💡 관련 이론: "schema-on-write vs schema-on-read"가 레이크와 웨어하우스를 가르는 본질이다. 웨어하우스는 적재 시점에 스키마를 강제하므로 데이터 품질이 보장되지만 변경에 약하다. 레이크는 적재 시 어떤 형태든 받아들이므로 미래의 알 수 없는 분석을 대비할 수 있지만, 카탈로그·거버넌스 없이는 통제 불능이 된다. AWS Lake Formation은 바로 이 거버넌스 공백을 메우려는 서비스다.

DEA-C01이 묻는 것

시험은 데이터 파이프라인 수명주기를 4개 도메인으로 쪼개서 묻는다.

가장 큰 비중인 수집·변환(34%)이 데이터 엔지니어 업무의 핵심임을 보여준다. SAA가 "어떻게 아키텍처를 설계할 것인가"를 묻는다면, DEA는 "데이터를 어떻게 수집·저장·변환·운영하고 안전하게 통제할 것인가"를 묻는다.

정리하며

오늘 세운 그림은 세 가지다. 첫째, 데이터 엔지니어의 산출물은 신뢰할 수 있는 파이프라인이며, 1순위 책임은 데이터 품질이다. 둘째, **OLTP(거래)와 OLAP(분석)**는 워크로드가 정반대라 저장·쿼리 방식이 다르다. 셋째, **데이터레이크(schema-on-read)와 웨어하우스(schema-on-write)**는 저장 철학이 다르며, 둘을 합친 레이크하우스가 현대 표준이다.

다음 글에서는 데이터가 "언제, 얼마씩" 들어오는지에 따라 갈리는 두 처리 패러다임 — 배치와 스트리밍 — 을 본다.