[견고한 데이터 엔지니어링] 03장
[견고한 데이터 엔지니어링] 3장. 우수한 데이터 아키텍처 설계
읽은 책: Fundamentals of Data Engineering (Joe Reis, Matt Housley) 목표: 좋은 데이터 아키텍처의 원칙을 이해하고, 주요 아키텍처 패턴(데이터 웨어하우스·레이크·레이크하우스·메시)의 트레이드오프를 파악하기
0. 이 장이 던지는 질문
2장이 수명 주기의 각 단계를 해부했다면, 3장은 그 전체를 하나의 아키텍처로 어떻게 연결하는가를 다룬다.
이 장의 핵심 질문:
- 데이터 아키텍처란 정확히 무엇인가?
- 좋은 아키텍처와 나쁜 아키텍처를 구분하는 원칙은 무엇인가?
- 데이터 웨어하우스, 데이터 레이크, 레이크하우스, 데이터 메시는 어떤 맥락에서 등장했으며 어떤 트레이드오프를 가지는가?
- 람다(Lambda)·카파(Kappa) 아키텍처는 언제 쓰는가?
1. 데이터 아키텍처란
1.1 아키텍처의 두 층위
책은 아키텍처를 두 층위로 나눈다.
| 층위 | 설명 | 예시 |
|---|---|---|
| 운영 아키텍처(Operational Architecture) | 비즈니스 요구사항과 데이터 흐름의 전체 그림 | 어떤 팀이 어떤 데이터를 소비하는가, 데이터 거버넌스 정책 |
| 기술 아키텍처(Technical Architecture) | 실제로 어떤 시스템과 도구를 어떻게 연결하는가 | Airbyte → BigQuery → dbt → Looker |
개인 메모: 도구 선택(기술 아키텍처)부터 시작하는 실수를 자주 본다. 올바른 순서는 “비즈니스 요구사항 → 운영 아키텍처 → 기술 아키텍처”다. 도구는 마지막에 고른다.
1.2 아키텍처의 목표
아키텍처는 트레이드오프의 연속이다. 완벽한 아키텍처는 없고, “현재 요구사항에 가장 잘 맞는 아키텍처”만 있다.
좋은 아키텍처의 목표:
- 비즈니스 요구사항을 충족한다
- 변화에 유연하게 대응할 수 있다
- 운영 비용과 복잡도를 통제할 수 있다
2. 우수한 데이터 아키텍처의 원칙
2.1 공용 컴포넌트를 신중하게 선택하라
공용 컴포넌트(Common Components)란 여러 팀이 공유하는 인프라다. 잘못 선택하면 조직 전체가 영향받는다.
- 오브젝트 스토리지(S3, GCS), 메시지 큐(Kafka), 데이터 웨어하우스가 대표적인 공용 컴포넌트
- 표준화와 유연성 사이의 균형을 찾아야 한다
2.2 장애를 계획하라
“장애가 발생하지 않을 것”이 아니라 “장애는 반드시 발생한다”는 전제에서 설계해야 한다.
- 파이프라인이 실패했을 때 재시도 가능한가?
- 데이터 유실 없이 복구할 수 있는가?
- 장애가 하위 시스템으로 전파되지 않는가?
개인 메모: Airbyte에서 sync가 중간에 실패했을 때 어떻게 되는가를 꼭 확인해야 한다. Incremental 모드라면 다음 실행 시 이어서 처리되지만, Full Refresh라면 처음부터 다시 시작한다. 파이프라인 설계 시 실패 시나리오를 반드시 함께 고려해야 한다.
2.3 확장성을 위해 설계하라
데이터 볼륨은 예상보다 빠르게 늘어난다.
- 수평 확장(Scale-out)이 가능한 시스템인가?
- 데이터가 10배 늘었을 때 비용도 10배가 되는가, 아니면 더 효율적인가?
2.4 아키텍처는 리더십이다
좋은 데이터 아키텍처는 기술 결정이 아니라 조직적 결정이다.
- 아키텍처 결정은 팀 전체의 합의가 필요하다
- 아키텍처는 지속적으로 진화해야 한다. 한 번 설계하고 끝나는 게 아니다
2.5 항상 아키텍처를 개선하라(Always Be Architecting)
현재 아키텍처가 완벽하다는 생각은 위험하다. 새로운 도구, 증가하는 데이터 볼륨, 변화하는 비즈니스 요구사항에 맞춰 지속적으로 검토하고 개선해야 한다.
2.6 느슨하게 결합된 시스템을 만들어라
시스템 간 의존성이 강하면 한 곳의 변경이 전체에 영향을 준다.
- API, 이벤트 스트림, 파일 교환 방식으로 컴포넌트 간 경계를 명확히 유지한다
- 특정 벤더나 도구에 강하게 종속(Lock-in)되지 않도록 한다
개인 메모: 오픈 테이블 포맷(Apache Iceberg, Delta Lake)을 사용하는 이유 중 하나가 여기 있다. 데이터를 특정 웨어하우스 전용 포맷이 아닌 개방형 포맷으로 저장하면, 쿼리 엔진을 교체해도 데이터를 그대로 활용할 수 있다.
2.7 되돌릴 수 있는 결정을 우선하라
아키텍처 결정은 두 종류다.
| 종류 | 설명 | 접근 방식 |
|---|---|---|
| 되돌릴 수 있는 결정 | 나중에 교체 가능 | 빠르게 실험하고 검증 |
| 되돌리기 어려운 결정 | 교체 비용이 매우 큼 | 신중하게 장기적으로 검토 |
개인 메모: 데이터 웨어하우스 선택(BigQuery vs Snowflake vs Redshift)은 되돌리기 어려운 결정이다. 반면 dbt 모델 구조나 스테이징 레이어 설계는 상대적으로 되돌리기 쉽다. “이 결정을 나중에 바꾸려면 얼마나 비용이 드는가”를 항상 먼저 물어봐야 한다.
2.8 보안을 우선하라
보안은 나중에 덧붙이는 기능이 아니라, 처음부터 설계에 내재되어야 한다.
- 최소 권한 원칙(Least Privilege): 각 시스템·사용자에게 필요한 최소한의 권한만 부여
- 데이터 분류(Data Classification): 민감도에 따라 접근 정책을 다르게 적용
2.9 FinOps를 수용하라
클라우드 비용은 방치하면 폭발적으로 증가한다.
- 데이터 볼륨 증가에 따라 쿼리 비용, 저장 비용이 함께 증가한다
- 비용을 가시화하고, 데이터 엔지니어링 팀이 클라우드 비용에 책임감을 가져야 한다
개인 메모: BigQuery에서 파티션과 클러스터링을 제대로 설계하지 않으면 쿼리 한 번에 수십 달러가 나올 수 있다. 저장 비용뿐만 아니라 쿼리 비용도 아키텍처 설계 단계에서 고려해야 한다.
3. 주요 아키텍처 패턴
3.1 데이터 웨어하우스(Data Warehouse)
가장 오래되고 검증된 패턴이다. 구조화된 데이터를 분석 목적에 최적화하여 저장한다.
두 가지 설계 철학:
| 방법론 | 제안자 | 핵심 아이디어 | 특징 |
|---|---|---|---|
| Kimball(킴볼) | Ralph Kimball | 비즈니스 프로세스 중심의 Dimensional Modeling | Star Schema, 사용자가 이해하기 쉬운 구조 |
| Inmon(인몬) | Bill Inmon | 기업 전체 통합 데이터 모델(EDW) 중심 | 정규화, 하향식(Top-down) 설계 |
현대 클라우드 데이터 웨어하우스(BigQuery, Snowflake, Redshift)는 두 방법론을 절충해서 사용한다.
개인 메모: dbt 프로젝트에서
fct_(팩트 테이블),dim_(차원 테이블) 네이밍 컨벤션이 바로 Kimball의 Dimensional Modeling에서 온 것이다. mart 레이어를 설계할 때 Star Schema 개념을 알면 훨씬 명확하게 구조를 잡을 수 있다.
3.2 데이터 레이크(Data Lake)
원시 데이터를 그대로, 대량으로 저장하는 접근 방식이다. 2010년대 빅데이터 시대에 등장했다.
- 장점: 비정형·반정형 데이터 포함 모든 형태의 데이터 저장 가능, 낮은 저장 비용
- 단점: “데이터 늪(Data Swamp)”이 되기 쉬움 — 거버넌스와 품질 관리가 어렵다
| 특성 | 데이터 웨어하우스 | 데이터 레이크 |
|---|---|---|
| 데이터 형태 | 구조화 데이터 | 구조화·비정형 모두 |
| 스키마 | 적재 시 스키마 확정(Schema-on-Write) | 읽을 때 스키마 적용(Schema-on-Read) |
| 쿼리 성능 | 높음 | 낮음(최적화 필요) |
| 거버넌스 | 강함 | 약함 |
| 비용 | 높음(쿼리·저장) | 낮음(저장) |
개인 메모: 데이터 레이크가 만능처럼 홍보됐던 시절도 있었지만, 실제로는 관리가 너무 어렵다. “일단 다 쌓아두자”는 전략은 데이터 늪으로 가는 지름길이다. 무엇을 위해 쌓는가를 먼저 정의해야 한다.
3.3 데이터 레이크하우스(Data Lakehouse)
데이터 레이크의 유연성과 데이터 웨어하우스의 관리 기능을 결합한 현재의 주류 아키텍처다.
핵심 기술: 오픈 테이블 포맷
| 포맷 | 개발 주체 | 특징 |
|---|---|---|
| Apache Iceberg | Netflix | ACID 트랜잭션, 타임 트래블, 스키마 진화 |
| Delta Lake | Databricks | ACID 트랜잭션, 스트리밍 지원, Z-order 클러스터링 |
| Apache Hudi | Uber | upsert 최적화, CDC 통합 |
레이크하우스의 주요 기능:
- ACID 트랜잭션: 데이터 웨어하우스처럼 데이터 일관성 보장
- 타임 트래블(Time Travel): 특정 시점의 데이터로 조회·롤백 가능
- 스키마 진화(Schema Evolution): 기존 데이터를 건드리지 않고 컬럼 추가·변경
- 멀티 엔진 접근: Spark, Presto, Trino, BigQuery Omni 등 다양한 쿼리 엔진으로 접근 가능
개인 메모: 처음 시작할 때는 BigQuery나 Snowflake 같은 관리형 웨어하우스가 현실적이다. 레이크하우스(S3 + Iceberg + Spark 등)는 운영 복잡도가 크기 때문에, 데이터 규모와 팀 역량이 뒷받침될 때 고려하는 것이 맞다.
3.4 데이터 메시(Data Mesh)
기술 아키텍처가 아니라 조직적·사회적 아키텍처다. 중앙 집중형 데이터 팀의 병목 문제를 해결하기 위한 접근 방식이다.
4가지 원칙:
| 원칙 | 설명 |
|---|---|
| 도메인 소유권(Domain Ownership) | 데이터는 그것을 가장 잘 아는 도메인 팀이 소유하고 관리 |
| 데이터 프로덕트(Data as a Product) | 각 도메인은 다른 팀이 사용할 수 있는 데이터 프로덕트를 제공 |
| 셀프 서비스 플랫폼(Self-serve Platform) | 도메인 팀이 데이터를 생산·소비할 수 있는 인프라 제공 |
| 연합 거버넌스(Federated Governance) | 전사적 표준은 중앙에서, 실행은 도메인별로 |
개인 메모: 데이터 메시는 중앙 집중형 데이터 팀이 모든 파이프라인을 소유하는 구조의 한계에서 나왔다. 도메인 수가 많고 중앙 팀이 병목이 될 때 고려할 수 있지만, 소규모 조직에서는 오히려 복잡도만 증가한다. 조직 규모에 맞는 아키텍처를 선택해야 한다.
3.5 람다 아키텍처(Lambda Architecture)
배치와 스트리밍을 동시에 처리하여 정확성과 실시간성을 모두 확보하는 패턴이다.
소스 데이터
|
+---> [배치 레이어] → 정확하지만 느린 결과 (시간 단위)
|
+---> [스피드 레이어] → 빠르지만 근사적인 결과 (초 단위)
|
v
[서빙 레이어] → 두 결과를 병합하여 최종 응답
- 장점: 실시간 응답과 정확한 배치 결과를 모두 제공
- 단점: 두 파이프라인을 동시에 유지해야 하므로 복잡도가 두 배
개인 메모: 람다 아키텍처는 스트리밍 처리 기술이 덜 성숙했던 시절에 많이 쓰였다. 배치와 스트리밍 로직이 분리되어 있으면 코드 중복과 불일치가 발생하기 쉽다. 현재는 Flink, Spark Structured Streaming 등으로 배치와 스트리밍을 통합 처리하는 방향으로 진화하고 있다.
3.6 카파 아키텍처(Kappa Architecture)
람다 아키텍처의 복잡도를 줄이기 위해 스트리밍 단일 파이프라인으로 통합한 패턴이다.
소스 데이터 → [스트리밍 레이어만] → 서빙 레이어
- 장점: 단일 파이프라인으로 유지·관리 단순화
- 단점: 스트리밍으로 처리하기 어려운 복잡한 배치 계산에 한계
개인 메모: “배치는 스트리밍의 특수한 경우”라는 아이디어가 카파 아키텍처의 출발점이다. 실시간 집계가 핵심인 광고·금융 플랫폼에서 많이 쓰인다. 하지만 대부분의 분석 워크로드에서는 여전히 배치가 더 간단하고 저렴하다.
4. 현대 데이터 스택과 아키텍처 선택
4.1 Modern Data Stack(MDS)이란
클라우드 기반의 관리형 SaaS 도구를 조합하여 데이터 파이프라인을 구성하는 접근 방식이다.
Airbyte(수집) → 클라우드 데이터 웨어하우스(저장) → dbt(변환) → BI 도구(서빙)
MDS의 특징:
- SQL 중심: 데이터 엔지니어링 진입 장벽을 낮춘다
- 관리형 서비스: 인프라 운영 부담이 적다
- 빠른 시작: 몇 주 안에 파이프라인을 구축할 수 있다
4.2 아키텍처 선택 기준
| 상황 | 추천 아키텍처 |
|---|---|
| 팀이 작고, 빠르게 시작해야 함 | Modern Data Stack(MDS) + 클라우드 웨어하우스 |
| 대용량 비정형 데이터, ML 워크로드 | 데이터 레이크하우스(S3 + Iceberg + dbt) |
| 도메인 팀이 많고 중앙 병목이 심각 | 데이터 메시 |
| 실시간 응답이 반드시 필요 | 람다 또는 카파 아키텍처 |
개인 메모: 아키텍처를 선택할 때 “가장 최신 기술”이 아니라 “지금 우리 상황에 맞는 기술”을 골라야 한다. Kafka + Flink + Iceberg 조합은 멋있어 보이지만, 5명짜리 팀에서는 운영이 불가능하다. 단순하게 시작하고, 복잡도는 필요에 의해 증가시켜라.
5. 데이터 엔지니어와 아키텍처
5.1 데이터 엔지니어의 아키텍처 역할
모든 데이터 엔지니어가 전담 아키텍트는 아니지만, 아키텍처 사고는 필수다.
- 도구를 선택할 때 단기 생산성뿐 아니라 장기 유지보수성도 함께 고려한다
- 새로운 요구사항이 들어왔을 때 기존 아키텍처와의 적합성을 판단한다
- 기술 부채(Technical Debt)가 쌓이기 전에 선제적으로 개선을 제안한다
5.2 아키텍처 결정 기록(ADR)
중요한 아키텍처 결정은 문서로 남겨야 한다.
- 왜 이 도구를 선택했는가?
- 어떤 대안을 고려했고, 왜 선택하지 않았는가?
- 이 결정의 트레이드오프는 무엇인가?
개인 메모: “왜 이걸 썼어요?”라는 질문에 “그냥요”라고 대답하는 팀이 너무 많다. ADR은 거창할 필요 없다. 슬랙 메시지나 짧은 Notion 문서라도 결정 이유를 기록하는 것이 중요하다. 6개월 후의 나에게 보내는 편지라고 생각하자.
6. 이 장의 결론
- 데이터 아키텍처는 도구 선택이 아니라 비즈니스 요구사항에서 출발하는 설계 결정이다.
- 좋은 아키텍처의 공통 원칙: 느슨한 결합, 장애 계획, 되돌릴 수 있는 결정, 보안 우선, FinOps 인식.
- 데이터 웨어하우스·레이크·레이크하우스·메시는 우열이 없다. 각자 적합한 맥락이 있다.
- 람다 아키텍처는 배치+스트리밍을 결합하지만 복잡하고, 카파 아키텍처는 스트리밍만으로 단순화한다.
- 팀 규모와 요구사항이 작다면 단순하게 시작하고 필요에 따라 복잡도를 높여라.
7. 내가 적용해볼 체크리스트
- 현재 사용 중인 데이터 스택에서 “되돌리기 어려운 결정”이 무엇인지 파악하고 있는가?
- 파이프라인 장애 시 재시도·복구 시나리오가 설계되어 있는가?
- 데이터 웨어하우스에서 파티션·클러스터링 등 쿼리 비용 최적화가 적용되어 있는가?
- dbt mart 레이어가 Kimball의 Star Schema 원칙에 따라 설계되어 있는가?
- 각 아키텍처 결정의 이유가 어디에든 기록되어 있는가?
- 특정 벤더나 도구에 강하게 종속되는 결정을 내리기 전에 대안을 충분히 검토했는가?
8. 한 줄 요약(5줄)
- 데이터 아키텍처는 도구 선택이 아니라 비즈니스 요구사항에서 출발하며, 트레이드오프의 연속이다.
- 좋은 아키텍처는 느슨한 결합, 장애 계획, 되돌릴 수 있는 결정, 보안 우선, FinOps 인식을 원칙으로 한다.
- 데이터 웨어하우스·레이크·레이크하우스·메시는 각자 적합한 맥락이 있으며, 최신이 최선이 아니다.
- 람다 아키텍처는 배치와 스트리밍을 결합하여 정확성과 실시간성을 확보하지만 복잡도가 높고, 카파 아키텍처는 스트리밍 단일 파이프라인으로 단순화한다.
- 팀 규모와 현재 요구사항에 맞게 단순하게 시작하고, 실제 필요가 생길 때 복잡도를 높여가는 것이 실용적인 원칙이다.
Leave a comment