🗄️ 데이터 엔지니어링 학습 로드맵

데이터 엔지니어링은 시작 지점을 잡기가 유난히 어려운 분야입니다. 채용 공고에 적힌 도구 이름이 회사마다 다르고, 그 목록을 그대로 학습 계획으로 옮기면 어느 것 하나 깊이 들어가지 못한 채 설치와 예제만 반복하게 됩니다. 실제로 이 일을 해 보면 시간의 대부분이 도구 조작이 아니라 스키마를 어떻게 잡을지 정하는 일과 어제 잘못 들어간 데이터를 다시 계산해 넣는 일에 들어갑니다. 도구는 그 두 가지를 하기 위한 수단일 뿐이고, 수단은 회사를 옮기면 바뀝니다.

그래서 이 로드맵은 특정 제품군을 익히는 순서로 짜지 않았습니다. 실시간 스트리밍 처리, 분산 처리 엔진의 내부 튜닝, 머신러닝 파이프라인은 일부러 뺐습니다. 전부 실무에 존재하는 주제이지만, 배치 파이프라인 하나를 멱등하게 만들지 못하는 상태에서 손대면 장애를 재현하지도 못한 채 시간을 쓰게 됩니다. 전체를 도는 데 대략 5~7개월을 잡고, 단계마다 매일 자동으로 도는 결과물을 하나씩 남기십시오. 하루 한 번이라도 실제로 돌아가는 파이프라인이 있어야 다음 단계의 문제가 눈에 들어옵니다.

1단계 — SQL을 읽는 언어가 아니라 쓰는 언어로 만들기

이 분야에서 SQL은 보조 기술이 아니라 주력 언어입니다. SELECT와 JOIN을 아는 수준과, 집계 기준이 어긋난 쿼리를 보고 어디서 행이 불어났는지 짚어 내는 수준 사이에는 큰 간격이 있습니다. 조인으로 인한 행 증폭, 그룹화 기준의 선택, 윈도 함수로 순위와 누적을 계산하는 법, NULL이 비교와 집계에서 어떻게 다르게 취급되는지, 그리고 실행 계획을 읽어 어느 단계가 비싼지 확인하는 법까지가 이 단계의 범위입니다. 여기에 파이썬으로 파일과 API를 다루는 정도의 기본기를 얹으면 충분합니다.

완료 기준: 결과 건수가 예상과 다를 때, 데이터가 잘못된 것인지 쿼리가 잘못된 것인지를 스스로 가려낼 수 있으면 됩니다.
체크포인트: 주문·회원·상품 세 개 테이블을 직접 만들어 넣고, 월별 재구매율을 구하는 쿼리를 작성해 보십시오. 같은 값을 두 가지 다른 방법으로 계산해 숫자가 일치하는지 맞춰 보는 것까지가 한 세트입니다.
자주 막히는 곳: 일대다 관계를 조인한 뒤 금액을 SUM으로 더해 매출이 부풀려지는 경우입니다. 한 건이 여러 행으로 늘어난 상태에서 더하면 조용히 틀린 숫자가 나오고, 아무도 에러를 보지 못한 채 보고서에 실립니다.

파이썬 쪽 기본기는 Python 기초 문법 가이드와 파일 입출력 가이드에서 채울 수 있습니다.

2단계 — 원천에서 저장소까지 옮기는 배치 만들기

데이터를 가져와 형태를 맞추고 저장소에 넣는, 가장 기본적인 흐름을 직접 만들어 보는 단계입니다. 원천은 데이터베이스일 수도 API일 수도 업로드된 파일일 수도 있습니다. 여기서 익혀야 할 것은 추출 방식의 선택입니다. 매번 전체를 다시 가져올지, 변경분만 가져올지, 변경분을 판단하는 기준을 무엇으로 삼을지에 따라 이후 모든 설계가 달라집니다. 수정 시각 컬럼을 쓸 때 그 값이 신뢰할 만한지, 삭제된 행은 어떻게 알아챌지도 이 단계에서 부딪히게 됩니다.

완료 기준: 같은 배치를 두 번 돌려도 결과 테이블의 행 수와 값이 달라지지 않게 만들 수 있으면 됩니다.
체크포인트: 공개 API에서 매일 데이터를 받아 원본 그대로 저장하는 영역과 정제된 영역을 나누어 적재하고, 어제 날짜만 다시 돌려도 중복이 생기지 않게 만들어 보십시오.
자주 막히는 곳: 원본을 남기지 않고 변환된 결과만 저장하는 구조입니다. 변환 로직에 버그가 있었다는 사실을 나중에 알게 되면, 원본이 없는 기간은 복구할 방법이 없습니다. 원천 시스템은 대개 과거 데이터를 오래 보관해 주지 않습니다.

3단계 — 스키마를 정하는 일이 곧 설계

이 단계가 이 직무의 중심입니다. 어떤 테이블을 만들고, 무엇을 하나의 행으로 볼지, 어떤 값을 어디에 둘지를 정하는 일이 파이프라인의 수명을 결정합니다. 정규화가 왜 필요한지 — 같은 사실이 여러 곳에 적혀 있으면 언젠가 서로 달라진다는 점 — 를 먼저 이해하고, 그다음에 분석용 저장소에서는 왜 일부러 그 원칙을 깨고 스타 스키마처럼 사실 테이블과 차원 테이블로 나누는지를 이해하십시오. 두 방향이 모순처럼 보이지만 목적이 다릅니다. 앞은 쓰기의 정확성을, 뒤는 읽기의 단순함을 위한 선택입니다.

여기에 시간이 붙습니다. 고객의 등급이 지난달과 지금이 다르다면 과거 주문은 어느 등급으로 집계해야 하는지, 값이 바뀔 때 기존 행을 덮어쓸지 새 행을 추가할지 정해야 합니다. 이 결정을 미루면 나중에 과거 수치를 재현할 수 없게 됩니다.

완료 기준: 새로운 지표 요청을 받았을 때, 기존 테이블에 컬럼을 더할 문제인지 새 테이블이 필요한 문제인지를 근거를 들어 판단할 수 있으면 됩니다.
체크포인트: 2단계에서 쌓은 데이터를 사실 테이블과 차원 테이블로 다시 설계하고, 값이 바뀌는 차원 하나를 골라 변경 이력을 보존하는 형태로 만들어 보십시오.
자주 막히는 곳: 사실 테이블의 입도를 명시하지 않고 만드는 것입니다. 한 행이 주문 한 건인지 주문 상품 한 줄인지 정해 두지 않으면, 나중에 집계할 때마다 사람마다 다른 숫자를 들고 오게 됩니다.

모델링 판단을 말로 정리하는 연습은 데이터 모델링 면접 자료에서 이어 갈 수 있습니다.

4단계 — 실행 순서와 재실행을 관리하기

파이프라인이 몇 개를 넘어가면 손으로 돌릴 수 없게 됩니다. 워크플로 오케스트레이터를 도입해 작업 간 의존 관계를 선언하고, 일정에 따라 실행하고, 실패한 지점부터 다시 시작하는 흐름을 익히는 단계입니다. 제품은 여러 가지가 있지만 개념은 거의 같습니다. 작업을 방향성 있는 그래프로 표현하고, 각 실행을 대상 기간으로 구분하며, 실패와 재시도를 상태로 관리합니다.

도구 사용법보다 중요한 것은 멱등성입니다. 같은 대상 기간에 대해 몇 번을 다시 돌려도 최종 결과가 같아야 합니다. 그러려면 각 작업이 자기가 처리할 구간을 명시적으로 받고, 그 구간의 기존 결과를 지우고 다시 쓰는 방식이어야 합니다. 무조건 덧붙이는 방식은 재실행 한 번에 데이터가 두 배가 됩니다. 실무에서 원천 데이터가 뒤늦게 정정되어 지난 30일을 통째로 다시 계산하는 일은 드물지 않게 일어납니다.

완료 기준: 3주 전 특정 하루의 데이터가 잘못되었다는 연락을 받았을 때, 그 하루만 안전하게 다시 계산해 넣을 수 있으면 됩니다.
체크포인트: 추출·정제·집계 세 단계를 의존 관계로 묶어 매일 돌게 하고, 임의의 과거 날짜를 지정해 재실행하는 시나리오를 실제로 실행해 보십시오.
자주 막히는 곳: 작업 안에서 오늘 날짜를 직접 읽는 코드입니다. 이렇게 쓰면 과거를 재실행해도 항상 오늘 기준으로 계산되어, 겉으로는 성공했는데 잘못된 구간이 그대로 남습니다. 처리 대상 기간은 반드시 밖에서 주입받으십시오.

5단계 — 틀린 데이터를 먼저 알아채는 장치

파이프라인 장애의 절반은 실행이 실패하는 형태로 오지 않습니다. 성공했는데 값이 비어 있거나, 건수가 평소의 10분의 1이거나, 중복이 섞여 있는 형태로 옵니다. 이런 실패는 아무도 알려 주지 않기 때문에 며칠 뒤 보고서를 보던 사람이 발견하고, 그때는 이미 잘못된 숫자가 여러 곳에 인용된 뒤입니다.

그래서 마지막 단계는 검증을 파이프라인 안에 넣는 일입니다. 적재 후 건수가 정상 범위인지, 기본 키가 실제로 유일한지, 필수 컬럼에 빈 값이 없는지, 전날 대비 변동 폭이 지나치지 않은지를 자동으로 확인하고, 어긋나면 다음 단계로 넘기지 않고 멈추게 만듭니다. 여기에 각 테이블이 어느 원천에서 어떤 작업을 거쳐 나왔는지를 추적할 수 있게 해 두면, 문제가 생겼을 때 영향 범위를 짐작이 아니라 목록으로 말할 수 있습니다.

완료 기준: 데이터가 이상하다는 제보를 사용자보다 먼저 받을 수 있는 구조를 만들어 두었으면 됩니다.
체크포인트: 자신의 파이프라인에 건수·유일성·결측 검사를 붙이고, 일부러 원천 데이터를 훼손해 검사가 실제로 파이프라인을 멈추는지 확인해 보십시오.
자주 막히는 곳: 검증 실패를 경고 로그로만 남기고 파이프라인을 계속 진행시키는 것입니다. 경고는 몇 주만 지나면 아무도 보지 않게 되므로, 하류로 퍼지면 안 되는 조건은 경고가 아니라 중단으로 다뤄야 합니다.

지금은 미뤄도 되는 것

• 실시간 스트리밍 처리 — 배치에서 멱등성과 재처리를 다뤄 본 뒤에야 순서 보장이나 중복 처리 문제를 이해할 수 있습니다.
• 분산 처리 엔진의 내부 튜닝 — 데이터가 한 대에서 감당이 안 될 만큼 커진 다음에 필요한 이야기입니다.
• 머신러닝용 특징 저장소 — 모델을 실제로 운영하는 팀에 들어간 뒤에 배워도 늦지 않습니다.
• 여러 오케스트레이터 비교 — 하나로 파이프라인을 몇 달 운영해 봐야 차이가 어디서 오는지 보입니다.

바로 이어서 볼 자료