[견고한 데이터 엔지니어링] CH3. 우수한 아키텍처 설계

왜 데이터 아키텍처가 중요한가

데이터 아키텍처는 단순히 “시스템을 어떻게 구성할 것인가”의 문제가 아니다.

기업이 현재 상태의 문제(품질 저하, 확장성 한계, 비용 증가)에서 바람직한 미래 상태(민첩한 데이터 활용, 확장 가능한 구조, 비즈니스 개선)로 어떻게 이동할지를 정의하는 변화 관리의 도구다.

데이터 아키텍처의 출발점: 엔터프라이즈 아키텍처(EA)

엔터프라이즈 아키텍처란?

엔터프라이즈 아키텍처(EA)는 비즈니스, 기술, 애플리케이션, 데이터, 프로세스, 인프라를 포함하는 기업 전체 또는 특정 도메인의 구조를 의미한다. 여러 프레임워크에서 공통적으로 강조하는 핵심은 다음과 같다.

• TOGAF / The Open Group
• → 기업이 보유한 자원과 이들의 상호작용 구조
• Gartner
• → 파괴적인 변화에 능동적으로 대응하기 위한 변화 실행의 식별·분석
• EABOK
• → 전략·운영·기술을 정렬해 성공으로 가는 로드맵을 만드는 조직 모델

엔터프라이즈 아키텍처는 “현재를 설명하는 그림”이 아니라

“미래로 이동하기 위한 설계”다.

오늘날 EA의 핵심 키워드: 유연성 + 트레이드오프

왜 유연성이 중요한가

• 세상은 계속 변하고, 미래는 예측 불가능
• 조직은 성장할수록 구조가 경직되기 쉬움

그래서 현대 아키텍처는

→ 되돌릴 수 있는 의사결정(가역적 결정) 을 선호한다.

가역적 의사결정과 변경관리

단방향 vs 양방향 의사결정

• 단방향(비가역): 한 번 선택하면 되돌리기 어렵고 리스크 큼
• 양방향(가역): 실험 가능, 실패 비용이 낮음

변경관리(Change Management)

가역성을 중시해도 기업은 큰 이니셔티브를 수행해야 한다.

변경관리의 핵심은 큰 변화를 작은 단계로 쪼개 관리하는 것이다.

아키텍트의 역할은:

• 비즈니스 문제를 식별하고
• 기술 솔루션을 “목적”이 아닌 “수단”으로 설계하며
• 작고 구체적인 실행 단계를 반복적으로 쌓는 것

데이터 아키텍처란 무엇인가

데이터 아키텍처 정의

데이터 아키텍처는 기업의 데이터 요구사항을 파악하고, 이를 충족하기 위한 마스터 청사진(blueprint) 을 설계·유지하는 활동이다.

이 청사진은:

• 데이터 통합을 안내하고
• 데이터 자산을 제어하며
• 데이터 투자를 비즈니스 전략과 정렬한다

데이터 아키텍처는 트레이드오프를 신중히 평가해 유연하고 되돌릴 수 있는 의사결정을 내리는 시스템 설계다.

운영 아키텍처 vs 기술 아키텍처

운영 아키텍처 (What 관점)

• 어떤 비즈니스 프로세스를 지원하는가?
• 데이터 품질은 어떻게 관리되는가?
• 데이터 생성 시점부터 쿼리 가능 시점까지 허용 지연시간은?
• 사람·프로세스·조직·기술 요구사항은 무엇인가?

기술 아키텍처 (How 관점)

• 데이터를 어떻게 수집하는가?
• 어디에 저장하는가?
• 어떻게 변환하고 제공하는가?
• 데이터 엔지니어링 수명 주기를 어떤 시스템으로 구현하는가?

우수한 데이터 아키텍처의 조건

좋은 아키텍처

• 유연성을 유지
• 현실적인 트레이드오프 선택
• 재사용 가능한 공통 컴포넌트 활용

나쁜 아키텍처

• 권위적이고 획일적인 결정
• 긴밀 결합, 중앙집중화
• 비즈니스 변화에 대응 불가

민첩성(Agility)은 데이터 아키텍처의 기반이다.

데이터 엔지니어링 아키텍처 9대 원칙

1. 공통 컴포넌트를 현명하게 선택하라
2. 장애에 대비하라
3. 확장성을 고려해 설계하라
4. 아키텍처는 리더십이다
5. 아키텍처에 충실하라
6. 느슨하게 결합된 시스템을 구축하라
7. 되돌릴 수 있는 의사결정을 하라
8. 보안을 최우선으로 고려하라
9. 핀옵스(FinOps)를 수용하라

공통 컴포넌트를 현명하게 선택하라

공통 컴포넌트와 관행은:

• 팀 간 협업 촉진
• 사일로 감소
• 공유 지식 기반 형성

대표적인 공통 컴포넌트:

• 객체 스토리지
• 버전 관리 시스템
• 관찰 가능성/모니터링
• 오케스트레이션 시스템
• 처리 엔진

또한 컴퓨팅과 스토리지 분리는 필요한 데이터에만 접근해 쿼리·처리를 가능하게 한다.

장애에 대비하라: 가용성·신뢰성·RTO·RPO

• 가용성: 시스템이 정상 작동 상태에 있는 시간 비율
• 신뢰성: 일정 기간 의도된 기능을 수행할 확률
• RTO: 장애 후 허용 가능한 최대 복구 시간
• RPO: 허용 가능한 최대 데이터 손실 시점

데이터 시스템은 장애 시 운영 중단 + 데이터 손실이 동시에 발생할 수 있다.

확장성을 위한 아키텍처 설계

• 스케일 업/아웃: 대규모 부하 처리
• 스케일 다운: 부하 감소 시 자동 축소
• 서버리스: 사용하지 않을 때 0에 가까운 확장

로드 스파이크를 측정하고 미래 부하를 예측해 DB/플랫폼 구조의 적합성을 판단해야 한다.

아키텍처는 리더십이다

좋은 데이터 아키텍트는:

• 기술적으로 유능하고
• 팀을 멘토링하며
• 조직 전체의 목표를 기술로 연결한다

아키텍트는 단순 설계자가 아니라 전문 지식을 전파하는 리더다.

아키텍처에 충실하라 (Sequencing Plan)

아키텍트는:

• 현재 아키텍처를 깊이 이해하고
• 목표 아키텍처를 정의하며
• 변경 우선순위와 순서를 담은 시퀀싱 계획을 수립한다

목표 아키텍처는 고정되지 않는다. 비즈니스·기술 변화에 따라 지속적으로 조정된다.

느슨하게 결합된 시스템을 구축하라

느슨한 결합의 특징:

1. 많은 소규모 컴포넌트
2. API/메시지 기반 상호작용
3. 내부 변경이 외부에 영향 없음
4. 전체 시스템을 묶어 배포하지 않음

기술 구조는 곧 조직 구조로 확장된다.

보안 우선순위: 제로 트러스트

• 전통적 모델: 내부 신뢰 / 외부 불신
• 현대 모델: 제로 트러스트

클라우드 환경에서는 데이터 엔지니어도 보안 엔지니어의 책임을 진다

(S3 퍼블릭 액세스 같은 설정 포함).

핀옵스(FinOps)

핀옵스는:

• 데이터 기반 지출 결정
• 클라우드 자원/비용 관리
• 지속적인 비용 모니터링

→ 비용도 아키텍처의 일부다.

주요 아키텍처 개념

도메인과 서비스

• 도메인: 설계 대상이 되는 주제/업무 영역
• 서비스: 특정 작업을 수행하는 기능 집합

도메인과 서비스는 사용자·이해관계자와의 대화로 정의한다.

분산 시스템과 확장성

• 확장성: 용량 증가
• 탄력성: 동적 확장
• 분산 시스템: 수평 확장으로 가용성/신뢰성 향상
• 리더 노드: 워크로드 관리의 중심

공유 디스크 vs 비공유 아키텍처

• 공유 디스크(shared-disk): 동일 디스크/메모리 접근
• 비공유(shared-nothing): 각 노드 자원 완전 분리 → 확장성↑

강한 결합 vs 느슨한 결합

• 강한 결합: 재사용·변경 어려움
• 느슨한 결합: 독립적 배포/개선 가능

계층형·모놀리식·마이크로서비스

• 단일/모놀리식: 운영 환경에서 비추천
• 다층(3-tier): 데이터 → 로직 → 프레젠테이션
• 마이크로서비스: 도메인 기반 분산 구조

중앙 데이터 웨어하우스는 본질적으로 모놀리식 성향을 가짐.

싱글 테넌트 vs 멀티 테넌트

멀티테넌시는:

• 성능
• 보안
• 데이터 격리
• 를 반드시 고려해야 한다.

이벤트 기반 아키텍처

상태 변화(Event)를 중심으로

서비스 간 통신을 구성하는 방식.

브라운필드 vs 그린필드

• 브라운필드: 레거시 점진적 개선(스트랭글러 패턴)
• 그린필드: 백지 설계

데이터 아키텍처 유형

데이터 웨어하우스

• 분석/보고 중심 중앙 허브
• ELT + CDC + 스트리밍 배치

데이터 마트

• 특정 부서/LOB 중심
• 접근성·성능 개선

데이터 레이크

• 정형/비정형 데이터 중앙 저장

데이터 레이크하우스

• 레이크 + 웨어하우스
• ACID, 관리/제어 강화

모던 데이터 스택

• 플러그 앤 플레이
• 모듈식, 비용 효율적

람다 아키텍처

• 배치 + 스트림 + 서빙 분리

카파 아키텍처

• 스트림을 데이터 처리 백본으로 사용

IoT 아키텍처

• 디바이스 → 게이트웨이 → 수집 → 저장 → 서빙

데이터 메시

• 도메인 기반 분산 데이터 소유
• 제품으로서의 데이터
• 셀프서비스 플랫폼
• 통합 거버넌스

기타:

• 데이터 패브릭
• 데이터 허브
• 메타데이터 우선 아키텍처
• 라이브 데이터 아키텍처