과거의 데이터 파이프라인과 현대적 데이터 스택의 차이

모놀리식에서 마이크로서비스로, 온프레미스에서 클라우드로 전환되던 그 거대한 흐름처럼, 데이터 처리의 세계에도 지각변동이 일어났습니다. 과거의 데이터 파이프라인 구축 방식은 이제 '레거시'로 불리며, '현대적 데이터 스택(Modern Data Stack, MDS)'이라는 새로운 패러다임이 그 자리를 빠르게 대체하고 있습니다. 이 글은 단순히 두 방식의 차이점을 나열하는 것을 넘어, 왜 이러한 변화가 필연적이었는지, 그리고 미래의 데이터 엔지니어가 무엇을 준비해야 하는지에 대한 깊이 있는 통찰을 공유하고자 합니다.

우리가 만들던 과거의 데이터 파이프라인은 마치 잘 짜인 공장의 생산 라인과 같았습니다. 원자재(Raw Data)가 들어오면, 정해진 규격에 맞춰 가공(Transform)하고, 완제품(Processed Data)을 창고(Data Warehouse)에 적재(Load)하는 방식, 즉 ETL(Extract, Transform, Load)이 지배적이었습니다. 이 방식은 수십 년간 데이터 처리의 표준이었지만, 데이터의 폭발적인 증가와 비즈니스의 빠른 변화 속도를 감당하기에는 너무나 무겁고, 느리고, 비쌌습니다. 바로 이 지점에서 현대적 데이터 스택은 완전히 다른 철학을 제시합니다.

전통적인 데이터 스택: 견고하지만 경직된 거인

2000년대 초반부터 2010년대 중반까지 데이터 엔지니어링의 세계를 지배했던 전통적인 데이터 스택을 이해하는 것은 현대적 스택의 혁신성을 이해하기 위한 필수적인 과정입니다. 당시의 목표는 명확했습니다. 여러 운영 시스템(ERP, CRM 등)에 흩어져 있는 정형 데이터를 중앙 데이터 웨어하우스(Data Warehouse, DW)로 통합하여, 경영진이 비즈니스 인텔리전스(BI) 리포트를 통해 의사결정을 내릴 수 있도록 지원하는 것이었습니다. 이 과정의 핵심에는 'ETL'이라는 강력한 개념이 자리 잡고 있었습니다.

ETL 패러다임의 특징과 한계

ETL은 이름 그대로 추출(Extract), 변환(Transform), 적재(Load)의 세 단계로 이루어집니다. 이 과정의 핵심은 '변환(Transform)' 단계가 '적재(Load)'보다 먼저 일어난다는 점입니다. 왜 그랬을까요? 당시의 데이터 웨어하우스(예: Oracle, Teradata)는 저장 공간과 컴퓨팅 성능이 매우 비쌌기 때문입니다. 원본 데이터를 그대로 저장하는 것은 상상할 수 없는 비용 낭비였고, 따라서 필요한 데이터만 정제하고, 집계하고, 비즈니스 로직에 맞게 가공하여 '깨끗하고 작은' 데이터로 만든 후에야 비로소 비싼 웨어하우스에 적재할 수 있었습니다.

이러한 변환 작업은 주로 Informatica PowerCenter, IBM InfoSphere DataStage, Talend와 같은 그래픽 사용자 인터페이스(GUI) 기반의 강력한 ETL 툴 또는 숙련된 개발자가 작성한 복잡한 Java, Python 스크립트를 통해 이루어졌습니다. 이 툴들은 매우 강력하고 안정적이었지만, 몇 가지 치명적인 한계를 내포하고 있었습니다.

높은 전문성과 비용: GUI 기반의 상용 ETL 툴은 라이선스 비용이 매우 비쌌고, 이를 다루기 위해서는 고도로 훈련된 소수의 전문 데이터 엔지니어가 필요했습니다. 이는 데이터 처리 작업이 소수에게 집중되는 병목 현상을 초래했습니다.
낮은 유연성과 개발 속도: 비즈니스 요구사항이 변경되어 리포트에 새로운 컬럼 하나를 추가해야 한다고 가정해 봅시다. 데이터 소스부터 ETL 로직, 데이터 웨어하우스 스키마까지 모든 단계를 수정하고 테스트해야 했습니다. 이 과정은 수 주에서 수 개월이 걸리기 일쑤였고, 빠르게 변하는 시장 상황에 대응하기 어려웠습니다.
데이터 손실 가능성: 변환 과정에서 '당장은 필요 없다'고 판단된 데이터는 버려졌습니다. 하지만 몇 달 뒤, 새로운 분석 기법이나 비즈니스 모델이 등장하면서 바로 그 '버려진' 데이터가 필요하게 되는 경우가 비일비재했습니다. 원본 데이터가 없으니, 과거 데이터를 다시 분석하는 것은 불가능에 가까웠습니다.

전통적인 ETL 방식의 가장 큰 딜레마는 '미래에 어떤 데이터가 중요해질지 현재 시점에서 예측해야 한다'는 점이었습니다. 이는 사실상 불가능한 과제였고, 수많은 기회비용을 발생시켰습니다.

결과적으로 전통적인 데이터 파이프라인은 한번 구축되면 변경하기 어려운 '콘크리트' 아키텍처와 같았습니다. 안정성은 높았지만, 데이터 분석가나 현업 사용자들이 새로운 데이터를 탐색하고 실험하기에는 너무나 큰 장벽이 존재했습니다. 데이터는 소수의 엔지니어에게 종속되었고, 데이터 기반 의사결정은 더디게 이루어졌습니다. 이러한 고통스러운 경험들이 바로 새로운 패러다임, 현대적 데이터 스택의 등장을 촉발시킨 것입니다.

현대적 데이터 스택(MDS)의 등장: 패러다임의 전환

2010년대 중반, 두 가지 거대한 기술적 변화가 데이터 엔지니어링의 판도를 뒤흔들었습니다. 첫째는 클라우드 컴퓨팅의 보편화이고, 둘째는 저장 비용의 혁신적인 하락입니다. AWS S3, Google Cloud Storage와 같은 객체 스토리지는 거의 무한에 가까운 데이터를 매우 저렴한 비용으로 저장할 수 있게 해주었습니다. 동시에, Snowflake, Google BigQuery, Amazon Redshift와 같은 클라우드 데이터 웨어하우스는 저장(Storage)과 컴퓨팅(Compute)을 분리하는 혁신적인 아키텍처를 선보였습니다.

이러한 변화는 전통적인 ETL의 근간을 이루던 가정, 즉 '저장 공간과 컴퓨팅은 비싸다'는 전제를 완전히 무너뜨렸습니다. 이제 우리는 더 이상 원본 데이터를 버릴 필요가 없어졌습니다. 오히려 모든 원본 데이터를 일단 저렴한 클라우드 스토리지나 웨어하우스에 그대로 쏟아부은 다음, 필요할 때마다 강력한 컴퓨팅 파워를 이용해 가공하는 것이 훨씬 효율적인 방식이 되었습니다. 바로 여기서 ETL의 순서를 뒤집은 ELT(Extract, Load, Transform) 패러다임과 현대적 데이터 스택이 탄생했습니다.

ELT: 순서 하나가 바꾼 모든 것

ELT는 말 그대로 먼저 데이터를 추출(Extract)하여 데이터 웨어하우스에 적재(Load)하고, 그 이후에 웨어하우스 내부의 강력한 컴퓨팅 성능을 활용하여 데이터를 변환(Transform)하는 방식입니다. 이 간단한 순서의 변화가 가져온 결과는 혁명적이었습니다.

모든 원본 데이터 보존: 더 이상 미래를 예측할 필요가 없습니다. 일단 모든 데이터를 원본 형태 그대로 저장하기 때문에, 나중에 어떤 분석이 필요하든 과거 데이터 전체를 대상으로 작업할 수 있습니다. 이는 데이터 과학자와 분석가들에게 엄청난 자유를 부여했습니다.
유연성과 속도의 향상: 데이터 변환 로직이 데이터 웨어하우스 내부에서 SQL 쿼리 형태로 실행됩니다. 이는 기존의 복잡한 ETL 툴이나 코드를 수정하는 것보다 훨씬 빠르고 간편합니다. 분석가는 SQL만 알면 직접 데이터를 변환하고 탐색하며 새로운 비즈니스 인사이트를 신속하게 도출할 수 있습니다.
역할의 분리와 전문화: 데이터 엔지니어는 데이터 소스에서 웨어하우스까지 데이터를 안정적으로 '옮기는' 역할(E와 L)에 집중할 수 있게 되었습니다. 데이터 변환(T)은 분석가나 '분석 엔지니어(Analytics Engineer)'라는 새로운 직군이 담당하게 되면서, 병목 현상이 해소되고 전체 데이터 팀의 생산성이 극대화되었습니다.

MDS의 핵심 철학: 모듈화와 Best-of-Breed

전통적인 스택이 Informatica나 IBM처럼 하나의 거대한 벤더가 모든 것을 제공하는 '올인원(All-in-one)' 방식이었다면, 현대적 데이터 스택은 각 기능별로 최고의 도구를 선택하여 레고처럼 조립하는 '베스트 오브 브리드(Best-of-Breed)' 철학을 따릅니다.

데이터 수집은 Fivetran이나 Airbyte, 데이터 웨어하우스는 Snowflake나 BigQuery, 데이터 변환은 dbt, 데이터 시각화는 Tableau나 Looker를 사용하는 식입니다. 각 도구는 API를 통해 유기적으로 연결되며, 특정 도구에 문제가 생기거나 더 좋은 대안이 나타나면 해당 부분만 교체하면 됩니다. 이는 마치 풀스택 개발에서 프론트엔드는 React, 백엔드는 Node.js, 데이터베이스는 PostgreSQL, 배포는 Docker와 Kubernetes를 사용하는 것처럼, 각 영역에서 가장 효율적인 기술을 조합하여 전체 시스템의 유연성과 확장성을 극대화하는 방식과 동일합니다.

전통적 스택 vs 현대적 스택: 한눈에 보는 비교

두 스택의 차이점을 보다 명확하게 이해하기 위해 주요 특징들을 표로 비교해 보겠습니다. 이 표는 여러분이 새로운 데이터 엔지니어링 프로젝트를 구상하거나 기존 시스템의 현대화를 고려할 때 중요한 의사결정 기준이 될 수 있습니다.

구분	전통적인 데이터 스택	현대적 데이터 스택 (MDS)
핵심 패러다임	ETL (Extract, Transform, Load)	ELT (Extract, Load, Transform)
주요 아키텍처	온프레미스(On-premise) 중심, 모놀리식(Monolithic)	클라우드 네이티브(Cloud-native), 모듈식(Modular), 서버리스(Serverless)
데이터 저장소	Oracle, Teradata, SQL Server 등 전통적 RDBMS 기반 DW	Snowflake, Google BigQuery, Amazon Redshift 등 클라우드 DW
변환(Transform) 위치	ETL 서버 등 웨어하우스 외부의 중간 처리 계층	데이터 웨어하우스 내부 (In-warehouse transformation)
변환(Transform) 방식	GUI 기반 ETL 툴(Informatica, Talend), Java/Python 스크립트	SQL 기반, dbt(data build tool)를 활용한 코드 기반 관리
원본 데이터 처리	변환 과정에서 대부분의 원본 데이터가 유실되거나 요약됨	모든 원본 데이터를 웨어하우스에 그대로 보존 (Schema-on-read)
주요 사용자	소수의 전문 데이터 엔지니어, BI 개발자	데이터 엔지니어, 분석 엔지니어, 데이터 분석가, 데이터 과학자 등
개발 및 유지보수	개발 사이클이 길고, 변경에 대한 저항이 큼. 높은 유지보수 비용.	애자일(Agile) 방식 개발, CI/CD 통합. 낮은 초기 비용, 사용량 기반 과금.
확장성	수직적 확장(Scale-up) 중심, 확장에 많은 비용과 시간 소요.	수평적 확장(Scale-out) 중심, 거의 무한한 확장성, 필요에 따라 즉시 확장/축소.
데이터 거버넌스	중앙 집중적이고 엄격한 통제 방식.	분산화된 데이터 소유권(Data Mesh), 자동화된 문서 및 테스트.

이 표에서 볼 수 있듯, 현대적 데이터 스택은 단순히 기술의 조합이 아니라 데이터 엔지니어링, 분석, 그리고 비즈니스 전반에 걸친 문화적인 변화를 의미합니다. 데이터에 대한 접근성을 높이고, 실험을 장려하며, 더 많은 사람이 데이터 기반 의사결정에 참여하도록 만드는 민주화의 과정이라고 할 수 있습니다.

현대적 데이터 스택의 핵심 구성 요소 분해

현대적 데이터 스택을 구성하는 각 요소를 좀 더 깊이 있게 살펴보겠습니다. 풀스택 개발자가 프론트엔드, 백엔드, 데이터베이스, 인프라를 이해하듯, 현대의 데이터 엔지니어는 이 구성 요소들의 역할과 상호작용을 명확히 파악해야 합니다.

1. 데이터 수집 (Ingestion): 자동화의 시작

ELT의 'E'와 'L'을 담당하는 영역입니다. 과거에는 각 데이터 소스(API, DB, 파일 등)에 연결하고 데이터를 추출하여 웨어하우스에 넣는 파이프라인 코드를 직접 작성하는 것이 일반적이었습니다. 하지만 이는 매우 반복적이고 오류가 발생하기 쉬운 작업입니다. 현대적 스택에서는 Fivetran, Stitch, Airbyte와 같은 자동화된 데이터 수집 도구를 사용합니다.

이 도구들은 수백 개의 데이터 소스(SaaS 애플리케이션, 데이터베이스, 광고 플랫폼 등)에 대한 커넥터를 미리 내장하고 있어, 사용자는 몇 번의 클릭만으로 데이터 파이프라인을 설정할 수 있습니다. 스키마 변경 감지, API 변화 대응, 데이터 타입 정규화 등 귀찮은 작업들을 모두 알아서 처리해주기 때문에, 엔지니어는 더 중요한 문제에 집중할 수 있습니다.

Airbyte는 오픈소스 데이터 통합 플랫폼으로, 커뮤니티의 힘을 빌려 빠르게 커넥터를 확장하고 있습니다. 특정 SaaS에 대한 커넥터가 필요하다면 직접 개발하여 기여할 수도 있다는 점에서 높은 유연성을 제공합니다.

2. 데이터 웨어하우스 (Storage): 무한한 확장성의 심장

현대적 데이터 스택의 심장부입니다. Snowflake, Google BigQuery, Amazon Redshift, Databricks Lakehouse 등이 이 영역의 대표주자입니다. 이들의 공통적인 특징은 앞서 언급한 '저장과 컴퓨팅의 분리' 아키텍처입니다.

저장 (Storage): 데이터는 저렴한 클라우드 객체 스토리지(S3, GCS)에 저장됩니다. 비용이 매우 저렴하여 사실상 모든 원본 데이터를 영구적으로 보관할 수 있습니다.
컴퓨팅 (Compute): 데이터 처리와 쿼리 실행은 '가상 웨어하우스(Virtual Warehouse)' 또는 '클러스터'라 불리는 독립적인 컴퓨팅 자원에 의해 수행됩니다. 데이터 수집, 변환, 분석 등 각 워크로드에 따라 독립적인 컴퓨팅 클러스터를 할당할 수 있습니다. 예를 들어, 대규모 데이터 변환 작업이 BI 대시보드 쿼리 성능에 영향을 주지 않도록 할 수 있습니다.

이러한 구조는 거의 무한한 확장성을 제공합니다. 데이터가 아무리 많아져도 저장 비용은 선형적으로 증가할 뿐이며, 쿼리 성능이 느려지면 클릭 몇 번으로 컴퓨팅 자원을 즉시 늘릴 수 있습니다. 이는 전통적인 온프레미스 웨어하우스의 값비싼 하드웨어 증설 과정과는 비교할 수 없는 민첩성입니다.

3. 데이터 변환 (Transformation): dbt가 일으킨 혁명

ELT의 'T'를 담당하는, 어쩌면 현대적 데이터 스택에서 가장 혁신적인 부분일 것입니다. dbt(data build tool)는 데이터 변환 작업을 소프트웨어 엔지니어링의 방식으로 처리할 수 있게 해주는 도구입니다.

과거에는 변환 로직이 복잡한 스크립트나 GUI 툴 내부에 흩어져 있어 관리하기 어려웠습니다. dbt는 모든 변환 로직을 오직 'SQL'로만 작성하도록 합니다. 하지만 그냥 SQL 파일의 모음이 아닙니다. dbt는 여기에 소프트웨어 개발의 핵심 프랙티스를 더했습니다.

버전 관리(Version Control): 모든 변환 로직(SQL)은 Git을 통해 관리됩니다. 누가, 언제, 무엇을 변경했는지 추적할 수 있으며, 코드 리뷰와 협업이 가능해집니다.
모듈화와 재사용성: Jinja 템플릿을 사용하여 SQL을 동적으로 생성하고, 공통 로직을 매크로로 만들어 재사용할 수 있습니다. ref() 함수를 통해 모델(테이블) 간의 의존성을 자동으로 파악하고 그래프를 그려줍니다.
테스트(Testing): Not null, unique, referential integrity 등 데이터의 정합성을 보장하기 위한 테스트를 YAML 파일에 간단히 정의할 수 있습니다. dbt test 명령 한 줄로 전체 데이터 파이프라인의 품질을 검증할 수 있습니다.
문서화(Documentation): 코드에 설명을 추가하면 dbt가 자동으로 깔끔한 데이터 계보(lineage) 다이어그램과 함께 웹 기반 문서를 생성해줍니다.

dbt는 SQL만 아는 데이터 분석가도 체계적인 데이터 모델링과 파이프라인 개발에 참여할 수 있도록 장벽을 낮추었고, '분석 엔지니어(Analytics Engineer)'라는 새로운 직무를 탄생시켰습니다. 이는 데이터 엔지니어링의 민주화에 결정적인 역할을 했습니다.


-- models/marts/core/fct_orders.sql

WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}
),

payments AS (
    SELECT * FROM {{ ref('stg_payments') }}
),

order_payments AS (
    SELECT
        order_id,
        SUM(CASE WHEN payment_method = 'credit_card' THEN amount ELSE 0 END) as credit_card_amount,
        SUM(CASE WHEN payment_method = 'bank_transfer' THEN amount ELSE 0 END) as bank_transfer_amount,
        SUM(amount) as total_amount
    FROM payments
    GROUP BY 1
),

final AS (
    SELECT
        orders.order_id,
        orders.customer_id,
        orders.order_date,
        order_payments.total_amount
    FROM orders
    LEFT JOIN order_payments
        ON orders.order_id = order_payments.order_id
)

SELECT * FROM final

위 예시는 dbt 모델의 단순한 예입니다. {{ ref(...) }} 함수는 dbt가 자동으로 `stg_orders`와 `stg_payments` 테이블을 먼저 빌드한 후에 이 모델을 실행하도록 의존성을 관리해줍니다. 이러한 방식은 복잡한 데이터 파이프라인을 매우 체계적이고 안정적으로 구축할 수 있게 해줍니다.

4. 데이터 오케스트레이션 (Orchestration): 파이프라인의 지휘자

데이터 수집, 변환, 그리고 후속 작업들은 정해진 순서와 스케줄에 따라 실행되어야 합니다. 이 전체 워크플로우를 조율하고 관리하는 것이 오케스트레이션 도구의 역할입니다. 대표적으로 Apache Airflow, Prefect, Dagster가 있습니다.

이 도구들은 데이터 파이프라인을 DAG(Directed Acyclic Graph, 방향성 비순환 그래프) 형태로 정의합니다. 각 작업(Task)과 그들 간의 의존 관계를 코드로 명확하게 표현할 수 있어, 복잡한 워크플로우도 시각적으로 파악하고 관리하기 용이합니다. 실패한 작업만 재실행하거나, 특정 조건에 따라 동적으로 파이프라인을 구성하는 등 정교한 제어가 가능합니다. 현대의 데이터 엔지니어에게 Airflow와 같은 오케스트레이션 툴에 대한 이해는 필수적입니다.

5. 비즈니스 인텔리전스(BI) 및 데이터 활성화

잘 정제된 데이터는 최종적으로 비즈니스 가치를 창출해야 합니다. Tableau, Looker, Metabase, Superset과 같은 BI 툴은 데이터 웨어하우스에 직접 연결되어 사용자가 데이터를 시각적으로 탐색하고 대시보드를 만들 수 있게 해줍니다.

최근에는 여기서 한 단계 더 나아가 '리버스 ETL(Reverse ETL)' 또는 '데이터 활성화(Data Activation)'라는 개념이 중요해지고 있습니다. 이는 웨어하우스에서 잘 만들어진 고객 데이터(예: 구매 예측 점수, 이탈 가능성)를 다시 Salesforce, Marketo와 같은 운영 시스템으로 보내는 것을 의미합니다. 이를 통해 영업팀은 잠재 고객에게 더 정확한 제안을 할 수 있고, 마케팅팀은 개인화된 캠페인을 실행할 수 있습니다. Hightouch, Census와 같은 도구들이 이 영역을 담당하며, 데이터 팀의 역할이 단순히 리포트를 제공하는 것을 넘어 비즈니스 액션을 직접 주도하는 방향으로 확장되고 있음을 보여줍니다.

Apache Airflow vs dbt: 경쟁자인가, 동반자인가?

데이터 엔지니어링을 처음 접하는 분들이 자주 헷갈리는 주제 중 하나가 바로 Airflow와 dbt의 관계입니다. 둘 다 데이터 파이프라인을 다루는 것처럼 보이기 때문입니다. 결론부터 말하자면, 이 둘은 경쟁 관계가 아니라 서로의 부족한 점을 완벽하게 보완해주는 최고의 파트너입니다.

핵심 요약: Airflow는 '언제, 어떤 순서로' 실행할지를 결정하는 지휘자(Orchestrator)이고, dbt는 '무엇을, 어떻게' 변환할지를 정의하는 연주자(Transformer)입니다.

	Apache Airflow	dbt (data build tool)
주요 목적	범용 워크플로우 오케스트레이션 (스케줄링, 의존성 관리, 재시도 등)	데이터 웨어하우스 내에서의 SQL 기반 데이터 변환
작업 단위	Task (PythonOperator, BashOperator 등 거의 모든 작업 가능)	Model (기본적으로 SQL `SELECT` 문)
의존성 관리	DAG 내에서 Task 간의 상하 관계(upstream/downstream)로 정의	`ref()` 함수를 통해 모델 간의 의존성을 자동으로 추론
실행 환경	독립적인 서버(또는 클러스터)에서 실행	데이터 웨어하우스에 쿼리를 전송하여 실행
강점	높은 유연성, 다양한 시스템과의 연동, 복잡한 로직 구현	SQL 중심, 테스트 및 문서화 자동화, 분석가의 참여 용이

최고의 조합: Airflow + dbt

가장 일반적이고 강력한 패턴은 Airflow를 사용하여 전체 ELT 파이프라인을 오케스트레이션하고, 그중 'T' 부분을 dbt에 위임하는 것입니다. 예를 들어, Airflow DAG는 다음과 같이 구성될 수 있습니다.

데이터 수집 (E & L): Fivetran이나 Airbyte의 데이터 동기화 작업을 API로 트리거하는 `FivetranOperator` 또는 `BashOperator`를 사용합니다.
데이터 변환 (T): 데이터 수집이 완료되면, dbt run과 dbt test 명령을 실행하는 BashOperator 또는 커뮤니티에서 제공하는 DbtCloudOperator를 실행합니다. dbt는 내부적으로 모델 간의 의존성을 파악하여 올바른 순서로 SQL을 실행합니다.
데이터 활성화 (Reverse ETL): dbt 작업이 성공적으로 끝나면, Hightouch나 Census의 동기화 작업을 트리거하여 변환된 데이터를 운영 시스템으로 보냅니다.

이렇게 구성하면 각 도구의 장점을 최대한 활용할 수 있습니다. Airflow는 전체적인 흐름과 예외 처리를 담당하고, dbt는 데이터 변환 로직의 품질과 유지보수성을 책임집니다. 데이터 엔지니어는 안정적인 파이프라인 인프라 구축에, 분석 엔지니어는 비즈니스 로직 구현에 집중할 수 있는 이상적인 협업 구조가 만들어집니다.

실시간 데이터 처리: 현대적 데이터 스택의 다음 단계

지금까지 설명한 현대적 데이터 스택은 주로 배치(Batch) 처리에 중점을 둡니다. 즉, 1시간 또는 24시간 주기로 데이터를 모아서 한 번에 처리하는 방식입니다. 하지만 사기 탐지, 실시간 추천, 재고 관리 등 일부 비즈니스 영역에서는 데이터가 발생하는 즉시 처리해야 하는 '실시간(Real-time)' 또는 '스트리밍(Streaming)' 데이터 처리가 필수적입니다.

이 영역에서는 Apache Kafka, Amazon Kinesis와 같은 메시지 큐 시스템이 데이터 스트림을 수집하고, Apache Spark Streaming, Apache Flink, ksqlDB와 같은 스트림 처리 엔진이 이를 실시간으로 분석하고 변환합니다. 이는 배치 중심의 MDS와는 다른 기술 스택과 아키텍처적 고려가 필요합니다.

실시간 데이터 처리는 현대적 데이터 스택을 대체하는 것이 아니라 보완하는 역할을 합니다. 많은 기업이 이 두 아키텍처를 결합한 '람다(Lambda)' 또는 '카파(Kappa)' 아키텍처를 사용합니다.
Martin Kleppmann, Designing Data-Intensive Applications 저자

람다 아키텍처(Lambda Architecture): 동일한 데이터 스트림을 배치 처리 파이프라인(MDS)과 스트리밍 처리 파이프라인으로 동시에 보냅니다. 배치 파이프라인은 정확하고 완전한 과거 데이터를 제공하고(Serving Layer), 스트리밍 파이프라인은 최근 데이터에 대한 빠른 결과를 제공합니다(Speed Layer). 쿼리는 이 두 계층의 결과를 조합하여 사용자에게 보여줍니다.
카파 아키텍처(Kappa Architecture): 람다 아키텍처의 복잡성을 줄이기 위해 배치 레이어를 없애고 모든 것을 스트리밍으로만 처리하려는 시도입니다. 데이터에 문제가 생기면 Kafka와 같은 로그 기반 메시지 큐의 처음부터 데이터를 다시 읽어와 재처리하는 방식을 사용합니다.

현대의 데이터 엔지니어는 배치 처리 중심의 MDS에 대한 깊은 이해를 바탕으로, 비즈니스 요구사항에 따라 이러한 실시간 처리 기술을 통합하고 운영할 수 있는 능력까지 갖추어야 합니다. 스트리밍 데이터와 배치 데이터를 모두 웨어하우스(또는 데이터 레이크하우스)에서 통합하여 분석하는 것이 최근의 트렌드입니다.

데이터 엔지니어를 위한 현대적 데이터 스택 학습 로드맵

이 글을 통해 현대적 데이터 스택의 매력에 빠졌다면, 이제 무엇부터 시작해야 할지 막막할 수 있습니다. 특히 비전공자나 다른 개발 분야에서 전환을 꿈꾸는 분들을 위해 제가 추천하는 학습 로드맵을 단계별로 제시합니다. 이 로드맵은 단순히 기술을 나열하는 것이 아니라, 각 기술이 전체 스택에서 어떤 역할을 하는지 이해하며 학습하는 것을 목표로 합니다.

1단계: 기본기 다지기 (The Foundation)

SQL, SQL, and SQL: 데이터 엔지니어링의 알파이자 오메가입니다. 단순히 SELECT, JOIN, GROUP BY를 넘어 윈도우 함수(Window Functions), CTE(Common Table Expressions), 성능 최적화까지 깊이 있게 파고들어야 합니다. MDS의 핵심인 dbt와 데이터 웨어하우스 모두 SQL을 기반으로 동작합니다.
Python 프로그래밍: Airflow DAG를 작성하고, 간단한 데이터 처리 스크립트를 만들고, 다양한 라이브러리(Pandas, SQLAlchemy)를 활용하기 위해 필수적입니다. 알고리즘이나 복잡한 웹 프레임워크보다는 데이터 구조, API 연동, 파일 처리 등 데이터 관련 작업에 초점을 맞추세요.
리눅스/셸 스크립트 및 Git: 모든 인프라의 기반이 되는 리눅스 환경에 익숙해져야 합니다. 커맨드 라인 인터페이스(CLI)를 자유자재로 다루고, Git을 통해 코드를 관리하는 것은 기본 중의 기본입니다.

2단계: 클라우드와 웨어하우스 (The Infrastructure)

클라우드 플랫폼 기초: AWS, GCP, Azure 중 하나를 선택하여 핵심 서비스를 경험해보세요. 특히 컴퓨팅(EC2, GCE), 스토리지(S3, GCS), IAM(권한 관리), 네트워킹(VPC)에 대한 기본 개념을 확실히 이해해야 합니다.
클라우드 데이터 웨어하우스 선택 및 심화 학습: Google BigQuery(무료 티어로 시작하기 좋음)나 Snowflake를 선택하여 직접 데이터를 적재하고 쿼리를 날려보세요. 각 웨어하우스의 아키텍처적 특징, 비용 모델, 성능 최적화 기법을 학습하는 것이 중요합니다.

3단계: 핵심 MDS 툴 마스터하기 (The Core Stack)

데이터 변환 - dbt: dbt CLI를 로컬에 설치하고, 간단한 프로젝트를 만들어보세요. dbt run, dbt test, dbt docs generate 등의 기본 명령어를 익히고, ref 함수와 소스, 시드 기능을 활용하여 모델링을 연습합니다. dbt 공식 문서와 튜토리얼이 매우 잘 되어 있습니다.
데이터 오케스트레이션 - Apache Airflow: Docker를 이용해 로컬에 Airflow를 띄우고, 간단한 DAG를 작성해보세요. BashOperator로 셸 스크립트를 실행하고, PythonOperator로 파이썬 함수를 실행하며 Task 간의 의존성을 설정하는 연습을 합니다.
데이터 수집 - Airbyte/Stitch (선택): Airbyte(오픈소스)를 로컬에 설치하여 구글 시트나 공개 API 데이터를 여러분의 웨어하우스로 옮겨보는 실습을 해보세요. 자동화된 수집 도구가 얼마나 편리한지 직접 체감하는 것이 중요합니다.

4. 실전 프로젝트 및 심화 학습 (The Next Level)

개인 프로젝트: 지금까지 배운 기술들을 총동원하여 자신만의 데이터 파이프라인을 구축해보세요. 예를 들어, '공공데이터 API에서 데이터를 주기적으로 수집(Airflow)하여 BigQuery에 적재하고, dbt로 데이터를 가공하여, Metabase로 시각화 대시보드 만들기'와 같은 프로젝트는 훌륭한 포트폴리오가 됩니다.
컨테이너 및 인프라 자동화: Docker와 Kubernetes(K8s)에 대한 이해는 현대적인 인프라 환경에서 필수적입니다. Terraform과 같은 IaC(Infrastructure as Code) 도구를 학습하면 데이터 파이프라인 인프라를 코드로 관리하는 경험을 쌓을 수 있습니다.
스트리밍 데이터 처리 입문: Kafka와 Spark/Flink의 기본 개념을 학습하고, 간단한 스트리밍 파이프라인을 구축해보는 것도 좋습니다.

현실적인 데이터 엔지니어 기술 면접 질문 예시

이 로드맵을 따라 학습했다면 다음과 같은 질문에 답할 수 있어야 합니다.

ETL과 ELT의 차이점은 무엇이며, 왜 최근 ELT가 대세가 되었나요?
Snowflake(또는 BigQuery)의 아키텍처가 기존 RDBMS와 다른 점은 무엇인가요?
dbt를 사용했을 때의 장점은 무엇이며, dbt 프로젝트의 일반적인 폴더 구조에 대해 설명해주세요.
Airflow에서 Task 간의 데이터 전달은 어떻게 하나요? XComs에 대해 설명해주세요.
데이터 파이프라인에서 데이터 품질을 어떻게 보장할 수 있을까요? (dbt test, Great Expectations 등)
수백만 건의 데이터를 처리하는 SQL 쿼리의 성능을 어떻게 최적화할 수 있을까요?

결론: 미래의 데이터 엔지니어링을 준비하며

전통적인 데이터 스택에서 현대적 데이터 스택으로의 전환은 단순한 기술의 변화가 아닙니다. 이는 데이터를 다루는 방식, 데이터를 통해 가치를 창출하는 속도, 그리고 데이터 팀이 일하는 문화 전반에 걸친 근본적인 혁신입니다. 과거의 데이터 엔지니어가 무거운 파이프라인을 구축하고 유지보수하는 '인프라 관리자'에 가까웠다면, 현대의 데이터 엔지니어는 최고의 도구들을 활용하여 데이터의 흐름을 설계하고, 데이터 플랫폼의 신뢰성과 확장성을 책임지며, 분석가와 과학자들이 더 빠르게 인사이트를 얻을 수 있도록 돕는 '플랫폼 설계자'이자 '기술적 조력자'로 진화하고 있습니다.

이러한 변화의 흐름에 올라타기 위해서는 특정 툴의 사용법을 익히는 것을 넘어, 왜 이 도구들이 등장했는지, 그리고 이들이 어떻게 유기적으로 연결되어 시너지를 내는지를 이해하는 것이 중요합니다. 이 글에서 제시한 개념과 로드맵이 여러분이 성공적인 데이터 엔지니어로 성장하는 여정에 훌륭한 나침반이 되기를 바랍니다. 변화는 이미 시작되었고, 현대적 데이터 스택의 시대는 이제 막 활짝 열렸습니다.