Kwangmin Kim - Designing Good Data Architecture

1 이 포스트의 목적

Reis & Housley (2022) Fundamentals of Data Engineering Ch.3은 “좋은 데이터 아키텍처란 무엇인가”라는 질문에 대해 엔터프라이즈 아키텍처 정의 → 데이터 아키텍처 정의 → “좋은” 아키텍처의 특성 → 9대 원칙 → 주요 아키텍처 개념 → 아키텍처 유형 사례 순서로 답한다. 이 overview 포스트는 챕터 전체를 조감하면서, 후속 상세 포스트를 연결하는 앵커 역할을 한다.

데이터 아키텍처는 데이터 엔지니어링 수명주기의 6대 저류(undercurrents) 중 하나이다. Ch.2에서 수명주기의 5단계(생성 → 수집 → 저장 → 변환 → 서빙)를 다루었다면, Ch.3은 이 5단계가 어떤 설계 위에서 작동하는가를 다룬다. 도구와 기술은 2~3년마다 바뀌지만, 아키텍처 원칙은 10년 단위로 지속된다. 이 차이가 Ch.3이 중요한 이유이다.

2 왜 데이터 아키텍처인가

데이터 파이프라인을 하나 만드는 것과 조직 전체의 데이터 시스템을 설계하는 것은 근본적으로 다른 종류의 작업이다. 파이프라인은 특정 소스에서 특정 목적지로 데이터를 이동시키는 전술적 행위이고, 아키텍처는 그 파이프라인들이 어떻게 공존하고 진화하는지를 결정하는 전략적 청사진이다.

반사실적 비교

아키텍처 없이 파이프라인만 계속 추가하면 어떻게 되는가? 각 파이프라인이 독자적인 스토리지, 인증 체계, 스케줄러를 사용하게 되어, 3년 후에는 아무도 전체 시스템을 이해하지 못하는 “빅 볼 오브 머드(big ball of mud)”가 된다. 하나를 수정하면 다른 셋이 깨지는 상태 — 이것이 나쁜 아키텍처의 실체이다.

3 엔터프라이즈 아키텍처에서 데이터 아키텍처로

데이터 아키텍처는 엔터프라이즈 아키텍처(EA)의 하위 집합이다. EA에는 비즈니스, 기술, 애플리케이션, 데이터 아키텍처가 포함된다.

교재는 TOGAF, Gartner, EABOK 세 프레임워크의 정의를 비교한 후 공통 패턴을 추출한다.

프레임워크	핵심 강조점	공통 요소
TOGAF	기업 전체 또는 특정 도메인의 정보·기술·프로세스·인프라	변화 관리
Gartner	파괴적 변화에 대한 선제적 대응	전략 정렬
EABOK	전략·운영·기술을 정렬하는 조직 모델	로드맵

이 세 정의에서 Reis가 추출한 공통 실(common thread)은 변화(change), 정렬(alignment), 트레이드오프 평가(trade-off evaluation)이다.

정의: Enterprise Architecture (Reis의 정의)

엔터프라이즈 아키텍처는 기업의 변화(change in the enterprise)를 지원하는 시스템 설계이며, 트레이드오프의 신중한 평가(careful evaluation of trade-offs)를 통해 도달한 유연하고 가역적인 결정(flexible and reversible decisions)으로 달성된다. (Reis, 2022, Ch.3)

4 데이터 아키텍처의 정의

정의: Data Architecture (Reis의 정의)

데이터 아키텍처는 기업의 진화하는 데이터 요구(evolving data needs)를 지원하는 시스템 설계이며, 트레이드오프의 신중한 평가를 통해 도달한 유연하고 가역적인 결정으로 달성된다. (Reis, 2022, Ch.3)

EA 정의와 데이터 아키텍처 정의를 비교하면, “기업의 변화”가 “기업의 진화하는 데이터 요구”로 구체화된 것뿐이다. 핵심 메커니즘 — 유연하고 가역적인 결정 + 트레이드오프 평가 — 은 동일하다.

데이터 아키텍처에는 두 가지 측면이 있다.

측면	질문	예시
운영 아키텍처 (Operational)	무엇을(What) 해야 하는가?	데이터 품질 요구사항, 레이턴시 SLA, 비즈니스 프로세스
기술 아키텍처 (Technical)	어떻게(How) 구현하는가?	매시간 10TB를 소스 DB에서 데이터 레이크로 이동하는 방법

5 “좋은” 데이터 아키텍처

Mark Richards와 Neal Ford의 말을 빌리면, “최고의 아키텍처가 아니라 최소한으로 나쁜 아키텍처를 목표로 하라(Never shoot for the best architecture, but rather the least worst architecture).”

좋은 데이터 아키텍처의 핵심 특성은 다음 세 가지이다.

유연성(flexibility): 비즈니스 요구와 기술 변화에 적응할 수 있다
재사용성(reusability): 공통 빌딩 블록을 조직 전체에서 활용할 수 있다
적절한 트레이드오프: 모든 선택에는 대가가 있으며, 그 대가를 의식적으로 수용한다

반대로 나쁜 데이터 아키텍처는 밀결합(tightly coupled), 경직(rigid), 과도하게 중앙화(overly centralized)되어 있거나 잘못된 도구를 사용한다.

6 9대 아키텍처 원칙

Reis는 AWS Well-Architected Framework와 Google Cloud의 5대 클라우드 네이티브 원칙에서 영감을 받아 데이터 엔지니어링 아키텍처 9대 원칙을 제시한다.

번호	원칙	핵심 메시지
1	공통 컴포넌트를 현명하게 선택하라	오브젝트 스토리지, 모니터링 등 조직 전체에서 재사용
2	장애를 계획하라	가용성, 신뢰성, RTO, RPO를 설계 시점에 고려
3	확장성을 위해 설계하라	스케일 업/다운/제로, 탄력적 시스템
4	아키텍처는 리더십이다	기술 결정 + 멘토링 + 전파
5	항상 아키텍팅하라	현재 상태 → 목표 아키텍처 → 시퀀싱 플랜
6	소결합 시스템을 구축하라	Bezos API Mandate, 팀 간 독립성
7	가역적 결정을 내려라	양방향 문(two-way doors), 실험 비용 최소화
8	보안을 우선하라	제로 트러스트, 공동 책임 모델
9	FinOps를 수용하라	클라우드 비용의 동적 관리

이 9대 원칙은 크게 설계 철학(1, 5, 7), 운영 견고성(2, 3), 조직 문화(4, 6), 크로스커팅 관심사(8, 9)로 분류할 수 있다. 어느 하나를 무시해도 시스템 전체가 취약해진다.

7 주요 아키텍처 개념

Ch.3의 중반부는 아키텍처를 구성하는 핵심 개념을 다룬다.

7.1 도메인과 서비스

도메인(domain)은 소프트웨어가 적용되는 실세계 주제 영역이다. 서비스(service)는 특정 작업을 수행하는 기능 집합이다. 예를 들어, 영업(sales) 도메인 안에 주문 처리, 송장 발행, 제품 관리라는 세 서비스가 있을 수 있다.

도메인 간 서비스 공유도 가능하다. 영업과 회계 도메인이 송장 서비스를 공유하는 것이 대표적인 사례이다.

7.2 분산 시스템과 장애 설계

확장성(scalability), 탄력성(elasticity), 가용성(availability), 신뢰성(reliability) — 이 네 속성이 분산 시스템 설계의 핵심이다. 단일 머신은 수직 확장(vertical scaling)이 가능하지만 물리적 한계가 있고 단일 장애점(SPOF)이 된다. 수평 확장(horizontal scaling)은 리더-워커 구조로 워크로드를 분산하고 데이터를 복제하여 장애에 대비한다.

7.3 결합도: 모놀리스 vs 마이크로서비스

특성	모놀리스	마이크로서비스
결합도	밀결합	소결합
배포	전체 릴리스	개별 서비스 독립 배포
복잡도	내부 복잡, 외부 단순	내부 단순, 운영 복잡
적합한 상황	빠른 프로토타이핑, 소규모 팀	대규모 팀, 독립적 확장 필요

교재의 핵심 조언: 모놀리스가 반드시 나쁜 것은 아니다. 빠르게 움직여야 할 때 모놀리스로 시작하되, 언젠가 분해할 준비를 하라.

7.4 이벤트 기반 아키텍처

이벤트(event)는 상태 변화이다. 이벤트 기반 아키텍처는 이벤트 생산(production) → 라우팅(routing) → 소비(consumption)의 흐름을 소결합된 서비스 간에 비동기적으로 전파한다. 한 서비스가 다운되어도 다른 서비스가 영향받지 않는다.

8 아키텍처 유형 사례

Ch.3의 후반부는 실제 아키텍처 패턴을 사례로 제시한다.

아키텍처	핵심 아이디어	현재 위치
데이터 웨어하우스	ETL/ELT → 중앙 분석 저장소	클라우드 DW로 진화
데이터 레이크	모든 데이터를 오브젝트 스토리지에 원본 저장	1.0은 실패 교훈, 2.0으로 진화
데이터 레이크하우스	레이크 + 웨어하우스 통합 (ACID 지원)	Databricks 주도, 수렴 추세
모던 데이터 스택	플러그앤플레이 모듈화	분석 엔지니어링의 기본 선택
Lambda	배치 + 스트리밍 병렬 처리	레거시, 권장하지 않음
Kappa	스트리밍 단일 백본	아이디어는 유효, 실무 채택은 제한적
Dataflow 모델	배치 = 유한 스트림, 통합 처리	Beam, Flink, Spark 채택
데이터 메시	도메인별 분산 소유, 데이터를 제품으로	탈중앙화 트렌드의 최전선

이 아키텍처들은 상호 배타적이지 않다. 실무에서는 데이터 레이크하우스 위에 모던 데이터 스택을 구축하고, 일부 도메인에 데이터 메시 원칙을 적용하는 하이브리드가 일반적이다.

9 Brownfield vs Greenfield

새 아키텍처를 설계할 때 출발점이 완전히 다르다.

프로젝트 유형	정의	핵심 전략
Brownfield	기존 아키텍처를 리팩토링	Strangler 패턴 — 레거시 컴포넌트를 점진적으로 교체
Greenfield	백지 상태에서 시작	요구사항 우선, 이력서 주도 개발(resume-driven development) 경계

두 경우 모두 핵심은 가역적이고 높은 ROI의 결정을 내리는 것이다.

10 핵심 시사점과 후속 포스트 연결

Ch.3이 전달하는 핵심 메시지는 세 가지이다.

첫째, 데이터 아키텍처는 도구 선택이 아니라 설계 철학이다. “Snowflake를 쓸까, Databricks를 쓸까?”는 아키텍처 질문이 아니다. “우리 시스템이 변화에 어떻게 적응하는가?”가 아키텍처 질문이다.

둘째, 좋은 아키텍처의 핵심은 가역성이다. Bezos의 양방향 문(two-way doors) 개념처럼, 대부분의 결정을 저비용으로 되돌릴 수 있게 설계하면 더 많은 실험과 더 빠른 학습이 가능하다.

셋째, 아키텍처는 기술이 아니라 조직의 문제이다. 소결합은 기술 시스템뿐 아니라 팀 구조에도 적용된다. 팀이 독립적으로 테스트하고 배포할 수 있어야 시스템도 독립적으로 진화할 수 있다.

후속 포스트 안내

이 overview 포스트의 각 섹션을 심화하는 상세 포스트가 이어진다.

What Is Data Architecture? + Defined — EA와 데이터 아키텍처의 정의를 분해하고, 운영/기술 아키텍처 구분을 상세히 다룬다
Principles + Concepts — 9대 원칙 각각의 실무 적용과 도메인/서비스, 분산 시스템, 결합도, 이벤트 기반 아키텍처를 깊이 다룬다
Examples + Conclusion — DW, 데이터 레이크, 레이크하우스, 모던 데이터 스택, Lambda/Kappa, 데이터 메시를 사례와 함께 비교 분석한다

11 용어 정리

용어	정의
Data Architecture	기업의 진화하는 데이터 요구를 지원하는 시스템 설계
Enterprise Architecture	기업의 변화를 지원하는 시스템 설계 (데이터 아키텍처의 상위 집합)
Operational Architecture	무엇을 해야 하는지 정의하는 기능적 요구사항
Technical Architecture	어떻게 구현하는지 정의하는 기술적 설계
Loose Coupling (소결합)	서비스 간 의존성을 최소화하여 독립적 변경을 가능케 하는 설계
Reversible Decisions (가역적 결정)	되돌릴 수 있는 결정, Bezos의 “양방향 문”
FinOps	클라우드 비용을 데이터 기반으로 관리하는 재무 운영 프레임워크
Data Lakehouse	데이터 레이크와 웨어하우스의 장점을 통합한 아키텍처
Data Mesh	도메인 중심 분산 데이터 소유 아키텍처
Strangler Pattern	레거시 시스템을 점진적으로 교체하는 마이그레이션 전략

12 참고 문헌

Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.3.
Richards, M. & Ford, N. (2020). Fundamentals of Software Architecture. O’Reilly.
Dehghani, Z. (2022). Data Mesh. O’Reilly.
Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly.