데이터 분석가에서 데이터 엔지니어로: 12개월 자기주도 학습 로드맵

발행: (2026년 5월 17일 AM 12:00 GMT+9)
15 분 소요

출처: Towards Data Science

. 저의 일부는 데이터 엔지니어링이 현재 가장 뜨겁고 높은 연봉을 받는 직업 중 하나라는 이유로 이 여정을 시작했습니다. 그게 동기가 아니었다고는 할 수 없겠죠.

하지만 그보다 더 깊은 이유가 있습니다.

저는 이미 데이터 분석을 꽤 오래 배워왔습니다. SQL, Power BI, Python(Pandas, NumPy, 약간의 Polars), 데이터 정제, EDA 등등. 이름만 말하면 다 해봤고, 진심으로 즐기고 있습니다. 그런데 어느 순간, 데이터가 제 책상 위에 도착하기 전엔 무슨 일이 일어나는지 궁금해지기 시작했습니다. 데이터는 어떻게 이동할까? 누가 파이프라인을 만들까? 이 모든 뒤에 있는 인프라는 실제로 어떻게 생겼을까?

그 호기심이 씨앗을 틔웠습니다.

그 뒤로 AI가 제가 하는 많은 일을 더 빠르고 쉽게 만들어 주기 시작했습니다. 물론 좋은 일입니다. 하지만 동시에 생각하게 됐습니다: AI가 분석을 담당한다면, 제 강점은 무엇일까? 더 깊이 이해하고 만들 수 있는 것은 무엇일까? 저는 스타트업에서 IT 시스템 분석가로 일하고 있는데, 업무 자체는 즐겁지만 스스로에게 충분히 도전하고 있지는 않다는 걸 깨달았습니다. 더 큰 무언가를 원했습니다.

결정적인 계기는 Data With Baraa의 영상이었습니다. 그는 완전한 데이터 엔지니어링 로드맵을 제시했는데, 구조화되고 세분화된 모습을 보니 현실적이고 실현 가능하게 느껴졌습니다. 그래서 저는 여기까지 왔습니다.

저는 데이터 엔지니어링을 공개적으로 배우고 있습니다. 그리고 이 글이 그 여정의 시작점입니다.

덧붙여, 저는 Data With Baraa와는 아무런 연관이 없으며, 개인적인 여정을 공유하는 것임을 알려드립니다. 도움이 되길 바랍니다.

왜 데이터 엔지니어링인가

잠시 시간을 내어 이 질문에 진지하게 답하고 싶습니다.

데이터 분석은 데이터가 도착한 뒤에 어떻게 다루는지를 가르쳐 주었습니다. 정제하고, 탐색하고, 시각화하고, 인사이트를 도출하는 것이죠. 이 스킬셋은 확실히 가치가 있습니다. 하지만 배울수록 같은 벽에 부딪히게 되었습니다. 제가 다루던 데이터는 이미 누군가에 의해 형태가 잡히고 이동된 것이었습니다. 누군가가 저에게 데이터를 전달해 주는 파이프라인을 만들었고, 저장 방식, 구조, 갱신 주기도 정해 놓았습니다.

저는 그 사람이 되고 싶었습니다.

데이터 엔지니어링은 분석보다 상류에 위치합니다. 분석이 가능하도록 시스템을 구축하는 일, 즉 데이터 파이프라인, 스토리지 아키텍처, 워크플로우 오케스트레이션, 대규모 데이터 처리 등을 담당합니다. 이들이 바로 모든 것이 기반을 두는 토대이며, 솔직히 말해 순수 분석보다 이런 인프라 작업에 더 큰 매력을 느낍니다.

실용적인 이유도 있습니다. 데이터 엔지니어링 직무는 데이터 산업 내에서 꾸준히 높은 연봉을 기록합니다. AI 도구가 분석 레이어를 자동화할수록, 신뢰할 수 있는 데이터 인프라를 구축·유지할 인재에 대한 수요는 더욱 커질 것입니다. 저는 파이프를 사용하기보다는 직접 만드는 쪽이 더 좋습니다.

그리고 한 가지 더. 제가 일하는 스타트업은 제가 배우려는 도구들을 전혀 사용하지 않습니다. 즉, 제가 투자하는 모든 시간은 완전히 자율적이며, 배울 팀도, 적용할 프로젝트도 없습니다. 오직 저와 인터넷, 그리고 스스로 만들 수 있는 것들만이 있습니다. 이것이 제가 의도적으로 선택한 도전 과제입니다.

왜 공개적으로 진행하는가

배운 내용을 글로 정리하는 것은 제가 이미 깊이 신뢰하는 방식입니다. 설명하기 전에 스스로 이해해야 하게 만들고, 책임감을 부여하며, 시간이 지나면 이력서만으로는 전달할 수 없는 무언가를 쌓게 됩니다.

하지만 제 두려움도 솔직히 밝히고 싶습니다. 바로 이 점이 공개적으로 하는 이유이기도 합니다.

저는 반짝이는 새 물건에 눈이 뜹니다. 인정합니다. 그래픽 디자인, 애니메이션, 글쓰기, 마케팅, IT 등을 탐험하다가 데이터 분야에 도착했죠. 언제나 새로운 것이 저를 끌어당깁니다. 데이터 엔지니어링도 제가 의도하지 않으면 피드에 떠오르는 또 다른 화려한 무언가에 금방 대체될 수 있습니다.

일관성도 문제입니다. 저는 9시부터 5시까지 일하는데, 그 시간에는 배우게 될 도구들을 거의 접하지 못합니다. 업무에서 자연스럽게 강화되는 요소가 없고, 동료에게 Airflow 질문을 던질 사람도 없습니다. 저는 이 모든 것을 직장 업무와는 별개로, 전적으로 제 개인 시간에 구축하고 있습니다.

그리고 균형. 하루에 3~4시간을 목표로 잡고 있습니다. 어떤 날은 쉬울 것이고, 어떤 날은 불가능하게 느껴질 것입니다.

이 여정을 공개하는 것이 제 책임 시스템입니다. 제가 조용해지면, 여러분은 제가 미끄러졌다는 것을 알게 될 겁니다. 저는 미끄러지고 싶지 않으니까요.

제가 먼저 시작하는 것

저는 완전한 초보에서 시작하는 것이 아니라, 어느 정도 기반을 가지고 있습니다. 데이터 분석 업무를 통해 초중급 수준의 SQL, 기본적인 Python, 그리고 Pandas 실습 경험을 이미 갖추고 있죠. 따라서 처음부터 다시 시작하기보다 기존 기반 위에 쌓아올릴 수 있습니다.

아래는 제가 대략적인 순서대로 다룰 전체 학습 스택입니다.

1. SQL: 분석을 넘어선 깊이

SQL은 알고 있습니다. 하지만 분석용 SQL과 엔지니어링용 SQL은 전혀 다른 동물입니다. 저는 쿼리 최적화, 인덱싱, 초대용량 데이터셋 다루기, 그리고 탐색이 아닌 성능을 위해 설계된 SQL 작성에 대해 더 깊이 파고들 예정입니다. 단순히 데이터를 끌어오고 필터링하는 수준을 넘어, 그 밑에 숨은 또 다른 층을 이해하는 것이 중요합니다.

왜 먼저인가: 데이터 엔지니어링의 모든 작업은 결국 SQL과 마주합니다. 더 복잡한 도구들을 도입하기 전에 여기서 날카롭게 다듬어 두면 이후 여정이 한결 수월해집니다.

2. Python: 탐색에서 프로덕션 수준으로

기본은 알고 있습니다. Pandas, NumPy, 약간의 Polars까지. 하지만 지금까지 제가 작성한 Python 코드는 주로 노트북에 머물러 있습니다. 탐색적이고, 지저분하며, 지속성을 염두에 두지 않은 것이죠. 이제 목표는 더 깔끔하고 구조화된, 재사용 가능한 코드를 짜는 것입니다. 함수, 모듈, 예외 처리, 스크립트 등 파이프라인에 실제로 투입할 수 있는 Python을 만들겠습니다.

왜 중요한가: Python은 현대 데이터 엔지니어링 스택을 잇는 접착제와 같습니다. Airflow도 Python을 사용하고, PySpark도 Python 기반이죠. 여기서 편안해지는 것은 선택 사항이 아닙니다.

3. Git 및 GitHub: 제대로 된 버전 관리

솔직히 말씀드리면, 현재 제 Git 실력은 “명령어 복사하고 동작하길 바라는” 수준입니다. 이것은 반드시 바뀌어야 합니다. 버전 관리는 분석가가 아닌 엔지니어로 일하기 위한 기본 토대이기 때문이죠. 브랜치, 풀 리퀘스트, 프로젝트 간 코드 관리 등을 배우겠습니다.

왜 중요한가: 여기서부터 만드는 모든 프로젝트는 GitHub에 올릴 것입니다. 포트폴리오이자 규율이며, 실제 팀이 일하는 방식이기도 합니다.

4. Apache Spark 및 PySpark: 빅데이터 처리

여기가 진짜 흥미로운 부분입니다. Apache Spark는 대규모 데이터 처리를 위한 가장 널리 쓰이는 엔진 중 하나이며, PySpark는 그에 대한 Python API입니다. 즉, 이미 어느 정도 익숙한 언어로 분산 데이터를 다룰 수 있다는 뜻이죠.

Pandas에서 Spark로 넘어가는 것은 사고 방식의 전환을 요구합니다. Pandas는 단일 머신에서 동작하지만, Spark는 클러스터 전반에 걸쳐 실행됩니다. 분산 사고 방식을 익히는 것이 데이터 엔지니어와 분석가를 구분 짓는 핵심 스킬입니다.

왜 중요한가: 프로덕션 환경에서 빅데이터를 다루려면 Spark는 거의 피할 수 없습니다. 채용 공고에서도 꾸준히 등장하고, 제가 목표로 하는 Databricks 생태계의 핵심이기도 합니다.

5. Apache Airflow: 데이터 파이프라인 오케스트레이션

데이터 파이프라인은 스스로 실행되지 않습니다. 스케줄링, 모니터링, 장애 복구를 담당할 무언가가 필요하죠. 바로 워크플로우 오케스트레이션 도구이며, 저는 Airflow를 선택했습니다.

다른 옵션도 검토했습니다. Databricks Workflows는 Databricks 생태계에 깊이 들어가 있다면 훌륭하고, Azure Data Factory는 Azure 중심 환경에 적합합니다. 하지만 Airflow는 무료이며 오픈소스, 클라우드에 구애받지 않고 널리 쓰이기 때문에 비용을 최소화하면서도 핵심 개념을 배우기에 최적이라고 판단했습니다.

왜 중요한가: 오케스트레이션은 여러 스크립트를 실제 파이프라인으로 전환시키는 역할을 합니다. 이해하고 구현하는 능력은


0 조회
Back to Blog

관련 글

더 보기 »