Lv.2 초급데이터 엔지니어링

2026.04.2120분 읽기Lv.2 초급

Data Engineering 플레이북 — Part 2: 데이터 아키텍처 설계 심층 가이드

데이터 아키텍처는 한 번 잘못 결정하면 수년간 기술 부채로 남는다. 이 글에서는 Data Warehouse, Data Lake, Data Lakehouse 3대 저장 아키텍처를 완전 비교하고, Medallion 패턴과 Apache Iceberg·Delta Lake·Hudi 오픈 테이블 포맷 3파전의 선택 기준을 정리한다. 이어서 처리 아키텍처인 Lambda vs Kappa의 장단점, 분산 소유권 패러다임인 Data Mesh의 4대 원칙과 도입 로드맵, 그리고 Data Fabric과의 차이까지 체계적으로 다룬다. 아키텍처 의사결정 플로우차트와 실전 체크리스트를 통해 현재 조직에 맞는 최적 설계를 직접 도출할 수 있다.

시리즈 구성

• Part 1 — 개요 & 2026 핵심 트렌드 (완료)
• Part 2 — 데이터 아키텍처 설계 (현재 편)
• Part 3 — 데이터 파이프라인 구축 (ETL/ELT, Orchestration, Streaming) (연재 예정)
• Part 4 — 데이터 품질 & 거버넌스 (연재 예정)
• Part 5 — 클라우드 & 인프라 (FinOps, IaC) (연재 예정)
• Part 6 — AI-Native 데이터 엔지니어링 (연재 예정)
• Part 7 — DataOps & 팀 운영 플레이북 (연재 예정)

목차

1. 아키텍처 선택이 왜 중요한가?
2. 3대 저장 아키텍처 완전 비교
3. Medallion 아키텍처 — Bronze / Silver / Gold
4. 오픈 테이블 포맷 3파전
5. Lambda vs Kappa — 처리 아키텍처 선택법
6. Data Mesh — 분산 소유권 패러다임
7. Data Fabric vs Data Mesh
8. 아키텍처 의사결정 플로우차트
9. 실전 체크리스트

1. 아키텍처 선택이 왜 중요한가?

데이터 아키텍처는 한 번 잘못 결정하면 수년간 기술 부채로 남는다. 동시에 81%의 IT 리더들이 클라우드 비용 절감 또는 동결을 C레벨로부터 요구받는 2026년 현재, 성능과 비용 사이의 균형을 잡는 설계가 그 어느 때보다 중요하다.

아키텍처 선택은 단순한 기술 결정이 아니다. 조직의 AI 경쟁력, 데이터 신뢰성, 운영 비용을 동시에 결정짓는 전략적 선택이다.

설계에 앞서 반드시 답해야 할 핵심 질문 3가지가 있다.

1. 어떤 종류의 데이터를 얼마나 빠르게 쿼리해야 하는가?
2. AI/ML 워크로드를 지원해야 하는가?
3. 팀의 규모와 운영 역량은 어느 수준인가?

2. 3대 저장 아키텍처 완전 비교

2-1. Data Warehouse — 빠르고 안정적인 BI의 황금 표준

데이터 웨어하우스는 여러 소스의 구조화 데이터를 정제·통합하여 저장하는 중앙 집중형 저장소다. 처리가 완료된 데이터만 저장하는 Schema-on-Write 방식으로, 보고서와 비즈니스 인텔리전스에 최적화되어 있다.

[소스 DB]  →  ETL (정제/변환 먼저)  →  [웨어하우스]  →  BI 도구

장점

• 빠른 쿼리 성능 (인덱싱, 사전 집계)
• 강력한 데이터 품질 보장 (입력 시 스키마 강제)
• SQL 기반, 분석가 친화적
• ACID 트랜잭션 완전 지원

단점

• 비정형·반정형 데이터 처리 어려움
• 스케일 확장 시 비용 급증
• ETL 파이프라인 변경 시 스키마 수정 필요
• ML/AI 워크로드에 비효율적

대표 도구: Snowflake, Google BigQuery, Amazon Redshift, Azure Synapse Analytics

적합한 상황: 정형 데이터 중심의 BI·리포팅이 주요 워크로드, 컴플라이언스가 엄격한 산업 (금융, 의료), 쿼리 속도와 일관성이 최우선

2-2. Data Lake — 저렴하고 유연한 원시 데이터의 바다

모든 데이터를 원시 형태(Raw)로 저장하는 방식. Schema-on-Read 방식으로, 데이터를 읽을 때 비로소 스키마를 적용한다. 오브젝트 스토리지(S3, GCS, ADLS)에 Parquet, Avro, JSON 등 다양한 포맷으로 저장된다.

[모든 소스]  →  (변환 없이) 원시 저장  →  [데이터 레이크]  →  필요할 때 처리

장점

• 구조화·반구조화·비구조화 데이터 모두 저장
• 오브젝트 스토리지 기반의 극저비용
• ML/AI·탐색적 분석에 최적
• 엑사바이트 수준으로 확장 가능

단점

• ACID 트랜잭션 미지원 → 데이터 불일치 위험
• 거버넌스 부재 시 "데이터 스왐프(Data Swamp)"로 전락
• 느린 쿼리 성능
• 행 수준 업데이트/삭제 어려움

대표 도구: AWS S3, Azure Data Lake Storage, Google Cloud Storage + Apache Spark

적합한 상황: ML·AI 학습용 대규모 비정형 데이터 보관, 탐색적 데이터 분석(EDA), 저비용 장기 데이터 아카이빙

데이터 스왐프 주의보: 거버넌스 없는 데이터 레이크는 누가 무슨 데이터를 넣었는지 아무도 모르는 "데이터 늪"이 된다. 데이터 카탈로그와 거버넌스 정책은 레이크 구축 첫날부터 함께 시작해야 한다.

2-3. Data Lakehouse — 두 세계의 최선을 하나로

2020년대 데이터 아키텍처의 대세. 데이터 레이크의 저비용·유연성과 데이터 웨어하우스의 성능·거버넌스를 오픈 테이블 포맷이라는 메타데이터 레이어를 통해 통합한다.

오브젝트 스토리지 (S3/GCS)
        +
오픈 테이블 포맷 메타데이터 레이어 (Iceberg/Delta/Hudi)
        ↓
  BI 쿼리 ↔ ML 학습 ↔ 스트리밍 ↔ 실시간 분석  (하나의 플랫폼에서)

핵심 기능 4가지

1. ACID 트랜잭션: 대규모 데이터셋에서도 안정적인 읽기/쓰기 보장
2. 스키마 진화(Schema Evolution): 기존 워크플로우를 중단하지 않고 컬럼 추가·변경 가능
3. 타임 트래블(Time Travel): 과거 특정 시점의 데이터 스냅샷 조회 가능
4. 멀티 엔진 지원: Spark, Trino, Flink, Snowflake, BigQuery가 같은 테이블을 읽고 쓸 수 있음

2026년 현황: 이미 많은 대형 기업들이 Lakehouse를 기본 아키텍처로 채택했으며, 새로운 데이터 플랫폼을 처음 구축하는 조직들의 사실상 기본 출발점이 되었다.

대표 플랫폼: Databricks Lakehouse, Microsoft Fabric, AWS Lake Formation + Glue + Athena

3대 아키텍처 비교표

2026 실무 조언: 대부분의 성숙한 조직은 셋 중 하나만을 선택하지 않는다. 웨어하우스를 BI의 골든 레이어로 유지하면서, 레이크하우스를 AI/ML 및 탐색 분석의 기반으로 활용하는 하이브리드 접근이 현실적이다.

3. Medallion 아키텍처

Lakehouse 환경에서 가장 널리 쓰이는 데이터 조직화 패턴. 데이터를 품질 수준에 따라 **3개의 레이어(메달)**로 분리 관리한다.

Medallion 아키텍처의 핵심 원칙

• Bronze는 절대 수정하지 않는다: 소스에서 받은 데이터는 있는 그대로 보존한다. 버그 픽스가 필요하면 Silver/Gold를 재처리한다.
• 레이어 간 이동은 단방향: Bronze → Silver → Gold로만 흐른다.
• Gold는 도메인별로 여러 개: 영업팀용, 마케팅용, 재무팀용 Gold 레이어가 각각 존재할 수 있다.

dbt를 활용한 Medallion 아키텍처 구현 예시는 다음과 같다.

4. 오픈 테이블 포맷 3파전

Lakehouse의 핵심 기술. Parquet 파일 위에 메타데이터 레이어를 추가하여 ACID 트랜잭션, 스키마 진화, 타임 트래블을 가능하게 한다. 이들은 스토리지 포맷이 아니라 **메타데이터 명세(Specification)**임을 기억하자.

Apache Iceberg

2026년 기준 가장 강력한 채택 모멘텀을 보유. Spark, Trino, Flink, Presto, Snowflake, BigQuery, Redshift가 모두 동일한 Iceberg 테이블을 읽고 쓸 수 있는 엔진-독립적 설계가 최대 강점이다.

-- 어제 오후 3시 기준 데이터 조회
SELECT * FROM catalog.db.orders
TIMESTAMP AS OF '2026-04-16 15:00:00';

-- 특정 스냅샷 ID로 조회
SELECT * FROM catalog.db.orders
VERSION AS OF 8954789234567;

강점: 멀티 엔진 지원에서 압도적, 대규모 테이블 관리 최적화 (파티션 프루닝, 컬럼 통계), AWS·Netflix·Apple 등 대규모 채택 레퍼런스

Delta Lake

Databricks가 주도하는 포맷. Databricks 생태계 내에서 최적의 성능을 발휘하며, 오픈소스화로 외부 엔진에서도 사용 가능하다.

강점: Databricks 환경에서 최고 성능, DML 연산(UPDATE, DELETE, MERGE) 처리 성숙, Unity Catalog와의 통합으로 강력한 거버넌스

Apache Hudi

스트리밍 Upsert 처리에 특화. 변경 데이터 캡처(CDC) 워크로드와 근실시간 데이터 수집에 강점을 보인다. Uber, Amazon이 대규모로 사용하는 레퍼런스를 보유.

강점: CDC 및 스트리밍 Upsert 처리 최적, 인크리멘탈 처리 파이프라인에 효율적

포맷 선택 가이드

5. Lambda vs Kappa — 처리 아키텍처 선택법

배치와 스트리밍을 어떻게 처리할 것인가에 대한 두 가지 철학이다.

Lambda 아키텍처

Nathan Marz(2011)가 제안한 3레이어 아키텍처. 배치와 스트리밍을 병렬로 처리하고, 서빙 레이어에서 결합한다.

언제 Lambda를 선택하는가?

• 방대한 역사적 데이터와 실시간 데이터를 동시에 분석해야 할 때
• 배치 레이어가 스피드 레이어의 오류를 보정하는 이중 안전망이 필요할 때
• 금융·의료처럼 정확도가 속도보다 중요한 규제 환경

단점: 배치·스트리밍 두 벌의 코드베이스를 유지해야 하는 **"복잡세(Complexity Tax)"**가 크다. 같은 비즈니스 로직을 두 번 작성하고, 두 시스템을 모두 운영해야 한다.

Kappa 아키텍처

Jay Kreps(Apache Kafka 공동 창시자, 2014)가 제안한 Lambda의 단순화 버전. 배치 레이어를 제거하고, 모든 데이터를 스트림으로 처리한다. Kafka 등 불변(Immutable) 로그를 소스 오브 트루스로 삼아, 역사 데이터 재처리가 필요할 땐 로그를 재생(Replay)한다.

언제 Kappa를 선택하는가?

• 운영 단순성이 최우선이고, 코드베이스를 하나로 유지하고 싶을 때
• IoT, 사기 탐지, 개인화 추천 등 실시간 처리가 지배적인 워크로드
• 스트림 처리 팀의 역량이 충분할 때

Shopify, Uber, Twitter 등 많은 기업들이 Lambda에서 Kappa로 마이그레이션한 이유가 바로 코드베이스 단순화다.

단점: 페타바이트 규모의 역사 데이터 재처리는 여전히 비용이 크다. Kafka 로그 보존 기간 설계가 중요하다.

Lambda vs Kappa 선택 기준

2026년의 트렌드: Apache Flink가 배치와 스트리밍을 하나의 엔진으로 처리하면서 두 아키텍처의 경계가 점점 흐릿해지고 있다. "수렴 아키텍처(Converged Architecture)"로 Lambda와 Kappa의 장점을 모두 취하는 접근도 현실적 선택지다.

6. Data Mesh — 분산 소유권 패러다임

왜 Data Mesh가 등장했는가?

중앙화된 데이터 팀은 조직이 커질수록 병목이 된다. 마케팅팀이 자신의 데이터를 쓰려면 중앙 데이터 엔지니어링 팀에 요청하고 수주를 기다려야 한다. 중앙 팀은 모든 도메인의 데이터를 이해해야 하지만 실제로는 어떤 도메인도 깊이 이해하지 못한다.

Data Mesh는 Zhamak Dehghani(2019)가 제안한 패러다임으로, 마이크로서비스 아키텍처가 단일 앱을 분해한 것처럼 모놀리식 데이터 플랫폼을 도메인 단위로 분해한다.

"마치 중앙 주방이 모든 음식을 서비스하던 식당에서, 각 도메인이 자신의 주방을 운영하는 푸드코트로 전환하는 것"

4대 핵심 원칙

Data Mesh 구현 예시 (도메인별 데이터 제품)

Data Mesh 도입 로드맵

Data Mesh 파일럿은 36개월, 조직 전체 롤아웃은 1224개월을 예상해야 한다.

Phase 1 (0~3개월): 파일럿 도메인 선정

• 경계가 명확하고 측정 가능한 성과를 낼 수 있는 2~3개 파일럿 도메인 선정
• 도메인 팀에 데이터 엔지니어링 역량 내재화
• 셀프서비스 플랫폼 기본 구성 (Databricks Unity Catalog, AWS DataZone 등)

Phase 2 (3~9개월): 데이터 제품 표준화

• 도메인 간 공통 데이터 계약(Data Contract) 정의
• 연합 거버넌스 정책 수립 (메타데이터, 접근 제어, 품질 SLA)
• 파일럿 성과 측정 및 템플릿화

Phase 3 (9~24개월): 전사 확산

• 재사용 가능한 패턴 라이브러리 구축
• 전체 도메인으로 순차적 확장

Data Mesh가 적합하지 않은 경우

Gartner에 따르면 거버넌스 성숙도가 충분한 조직은 **18%**에 불과하다. 다음에 해당하면 Data Mesh 도입을 서두르지 말 것.

• 조직 규모가 작고 도메인이 2개 미만
• 도메인 팀에 데이터 엔지니어링 역량이 없음
• C레벨의 강력한 후원이 없음
• 현재 중앙 데이터 팀도 제대로 운영되지 않는 상태

핵심 교훈: Data Mesh 성패는 기술이 아닌 문화와 조직 변화에 달려 있다. Thoughtworks의 2026년 분석에 따르면, 성공한 조직들은 완벽한 아키텍처보다 지속 가능한 조직 패턴에 집중했다.

7. Data Fabric vs Data Mesh

두 접근법을 자주 혼동하지만, 철학이 근본적으로 다르다.

2026년의 현실: 많은 선도 기업들은 둘 중 하나를 선택하는 대신 하이브리드 접근을 택하고 있다. Data Fabric을 지능형 인프라 자동화 레이어로 사용하면서, Data Mesh의 도메인 소유권 구조를 동시에 적용한다.

8. 아키텍처 의사결정 플로우차트

9. 실전 체크리스트

아키텍처를 확정하기 전, 다음 질문에 반드시 답해야 한다.

저장 아키텍처

• 주요 쿼리 패턴이 BI/리포팅인지, ML/탐색적 분석인지 정의했는가?
• 비정형 데이터(이미지, 텍스트, 로그)의 처리가 필요한가?
• 벤더 락인을 최소화하기 위한 오픈 테이블 포맷 사용을 검토했는가?
• 스토리지와 컴퓨트 분리를 통한 독립적 스케일링이 필요한가?
• 멀티 엔진(Spark + Trino + Flink) 환경을 지원해야 하는가?

처리 아키텍처

• 최대 허용 지연 시간(Latency SLA)이 정의되어 있는가?
• 역사 데이터 재처리 빈도가 어느 정도인가?
• 팀에 스트림 처리 전문 역량이 있는가?
• 배치와 스트리밍을 위해 별도 코드베이스를 유지할 준비가 되어 있는가?

조직 아키텍처 (Data Mesh 검토 시)

• 비즈니스 도메인이 3개 이상이며 각각 독립적인 데이터 생산자인가?
• 도메인 팀에 데이터 엔지니어링 역량을 내재화할 수 있는가?
• C레벨 이상의 조직 변화 후원이 있는가?
• 연합 거버넌스를 위한 공통 플랫폼을 구축할 수 있는가?
• Data Contract 표준을 정의하고 강제할 메커니즘이 있는가?

공통

• 선택한 아키텍처의 운영 복잡도를 감당할 팀 규모인가?
• 아키텍처별 총 소유 비용(TCO)을 추정했는가?
• 향후 3년간의 데이터 볼륨 증가 예측치가 있는가?
• 컴플라이언스(GDPR, 개인정보보호법 등) 요구사항을 반영했는가?

마치며

2026년 데이터 아키텍처의 핵심 메시지를 정리하면 다음과 같다.

1. Lakehouse가 기본값: 새로 구축하는 플랫폼은 Lakehouse로 시작하고, 기존 웨어하우스와 공존을 설계하라.
2. 오픈 포맷으로 자유를: Apache Iceberg를 기본 선택으로 검토하라. 멀티 엔진 지원과 벤더 독립성이 핵심이다.
3. 처리는 수렴 중: Lambda와 Kappa의 경계는 흐릿해지고 있다. Flink 하나로 두 워크로드를 처리하는 접근을 고려하라.
4. Data Mesh는 기술이 아닌 문화: 충분한 조직 역량과 경영진 후원 없이는 시작하지 마라.
5. 완벽한 아키텍처는 없다: 현재 팀의 역량과 비즈니스 요구사항에 맞는 "충분히 좋은(Good Enough)" 아키텍처가 최선이다.

다음 파트에서는 이 아키텍처 위에 실제 데이터 파이프라인을 구축하는 방법 — ETL/ELT 설계, 오케스트레이션, 스트리밍 파이프라인까지 — 을 심층 분석한다.

Part 3 예고: 데이터 파이프라인 구축 실전 가이드

• ETL vs ELT vs Zero-ETL 선택 기준
• Apache Airflow / Dagster / Prefect 오케스트레이터 비교
• Kafka + Flink 스트리밍 파이프라인 설계
• dbt 실전 패턴과 테스트 전략
• 파이프라인 모니터링 & 알림 설계

작성 기준: 2026년 4월 | 참고: Monte Carlo Data, Databricks, IBM, Algoscale, DataMesh Architecture, Atlan, Flexera, Materialize