List
전략적 변곡점 그 이전: 전통적 분석 데이터 아키텍처의 한계
데이터 메시(Data Mesh)를 이해하기 위해서는, 먼저 기존 분석 데이터 아키텍처가 어떻게 발전해왔는지 알아보고 이를 통해서 현재 어떤 어려움에 직면했는지 살펴볼 필요가 있습니다. 이번 글에서는 1세대 데이터 웨어하우스부터 2세대 데이터 레이크, 그리고 3세대 멀티모달 클라우드 아키텍처에 이르는 변천 과정을 정리하고, 이들이 가진 공통적인 한계를 짚어보겠습니다.
분석 데이터 아키텍처의 진화
1. 1세대: 데이터 웨어하우스 아키텍처
과거 대부분의 조직은 데이터 웨어하우스(Data Warehouse)를 중심으로 분석 환경을 구축했습니다.
•
특징:
◦
운영 DB와 소스에서 데이터 추출 후, 웨어하우스 테이블에 적재
◦
SQL 쿼리를 통한 분석, BI 도구로 시각화 및 보고서 작성
◦
엔터프라이즈급 웨어하우스 솔루션은 독점적이고 비용이 비싸고, 전문지식이 필요
•
문제점:
◦
수천 개의 ETL 작업 및 테이블로 인한 기술 부채 발생
◦
CI/CD 등 현대적 엔지니어링 관행 적용 어려움
◦
기술 부채 해소를 위해 또 다른 웨어하우스 솔루션(BigQuery → Redshift)으로의 마이그레이션 악순환
예시: 회사 A는 수년간 웨어하우스를 통해 판매 데이터를 분석해왔습니다. 시간이 지날수록 데이터팀에 다양한 요청으로 ETL과 테이블이 기하급수적으로 증가했고, 일부 전문 데이터 엔지니어만 이 구조를 이해하며 유지보수할 수 있게 되었습니다. 결국 현대적 분석 요구와 빠른 변화에 대응하기 힘들어졌고, 새로운 웨어하우스 도입을 고민하는 악순환에 빠집니다.
2. 2세대: 데이터 레이크 아키텍처
2010년대 들어, 머신러닝 모델 훈련, 비정형 데이터 분석 등 새로운 요구사항이 등장하면서 데이터 레이크(Data Lake) 아키텍처가 부상했습니다.
•
특징:
◦
미가공(Raw) 데이터를 사전 변환 없이 최대한 원본 형식 유지
◦
객체 스토리지 인터페이스로 파일(2차원 배열) 형태 접근
◦
레이크쇼어마트(Lakeshore Mart)로 전용 데이터 마트 구성
◦
머신러닝 학습 위한 피처 스토어(Feature Store) 생성 가능
•
장점: 기존 웨어하우스 대비 유연성↑, 비정형 데이터 처리 용이
•
단점:
◦
여전히 중앙 집중식 관리 필요
◦
운영·분석 데이터 간 간극 완전히 해소 불가
◦
파이프라인 복잡성과 중복 문제 상존
예시: 회사 B는 사용자 청취 로그를 데이터 레이크에 저장하고 ML 모델을 학습합니다. 비정형 데이터 처리 유연성은 확보했으나, 여전히 모든 데이터를 중앙에서 관리하고 파이프라인 복잡성은 줄지 않아 어려움을 겪습니다.
3. 3세대: 멀티모달 클라우드 아키텍처
최근에는 실시간 분석, 클라우드 네이티브, 관리형 서비스 활용 등 현대적 요소가 가미된 멀티모달 클라우드 아키텍처가 등장했습니다.
•
특징:
◦
카파(Kappa) 아키텍처 등으로 실시간 스트리밍 지원
◦
아파치 빔(Apache Beam)을 통한 일괄·스트림 처리 통합
◦
클라우드 기반 관리형 서비스, 컴퓨팅·스토리지 분리
◦
데이터 웨어하우스와 레이크 통합 시도
•
여전히 남은 문제:
◦
구조적 모놀리식(Monolithic) 특성 완전 탈피 실패
◦
다양한 도메인 요구사항 반영 및 민첩한 대응 어려움
예시: 회사 C는 재고 예측을 위해 실시간 분석을 도입했지만, 여전히 중앙 집중식 관리로 인해 각 도메인의 다양한 데이터 요구사항을 충족시키기가 쉽지 않습니다.
분석 데이터 아키텍처의 공통 특징: 모놀리식 구조와 중앙 집중화
1세대에서 3세대에 이르는 분석 데이터 아키텍처는 지속적으로 진화해왔지만, 한 가지 특징은 변하지 않았습니다. 데이터를 중앙 집중식 방식으로 관리하고, 모놀리식(Monolithic) 아키텍처·기술·조직 구조를 유지하는 경향입니다. 이러한 특성은 현대 비즈니스 환경의 복잡성과 변화 속도에 적절히 대응하기 어렵게 만듭니다.
모놀리식 아키텍처의 특징
•
중앙 집중식 데이터 관리: 기업 내부 곳곳에서 발생하는 데이터를 하나의 중앙으로 모아 관리하고, 공통된 요구사항(클렌징, 보강, 변환 등)을 충족한 뒤 다양한 소비자에게 제공하는 방식이 일반적입니다.
•
데이터 파이프라인 복잡성: 데이터는 수많은 변환 단계를 거치며, 각각의 변환 과정마다 중복성과 의존성이 생깁니다. 이는 파이프라인이 점점 복잡해지고, 변경 사항이 발생할 때마다 대규모 조정이 필요한 환경을 조성합니다.
예시: 전국 수백 개 매장을 가진 유통 기업이 있다고 가정해봅시다. 매장별 판매 데이터, 재고 데이터, 고객 데이터를 모두 중앙 웨어하우스로 모아 클렌징·보강·변환한 뒤, 마케팅팀, 재무팀, 물류팀 등 다양한 소비자에게 제공하려고 합니다. 이 경우, 새로운 소비자의 요구사항이 생길 때마다 중앙 파이프라인에 수정이 필요하고, 여러 이해관계자의 우선순위를 조정하는 일이 점차 어려워집니다.
유비쿼터스(Ubiquitous) 데이터와 증식하는 사용 사례
•
유비쿼터스 데이터: 모바일 기기, IoT 센서, 외부 파트너 시스템 등 데이터 소스가 어디서나 발생합니다. 데이터 양과 다양성이 폭증하는 상황에서 중앙 팀이 모든 것을 관리하는 것은 비효율적입니다.
•
혁신 아젠다와 사용 사례 증가: 조직은 신속한 실험과 혁신을 추구합니다. 이로 인해 데이터 사용 사례가 기하급수적으로 늘어나고, 변환 횟수도 증가합니다. 중앙화된 구조에서는 이러한 증가에 신속히 대응하기 어렵습니다.
예시: 한 기업이 마케팅 실험, 고객 맞춤형 추천, 물류 최적화, CS 대응 자동화 등 각 영역에서 데이터 활용 실험을 진행한다고 생각해봅시다. 각 실험마다 새로운 데이터 세트, 변환, 정제 과정이 필요하며, 중앙 팀이 이를 모두 처리하려면 대기 시간과 우선순위 조정 문제가 심각해집니다.
조직의 복잡성과 변화에 대한 민첩성 부족
•
조직적 복잡성: 데이터 팀은 소스팀(데이터를 생성하는 시스템), 전문화된 데이터 엔지니어팀(데이터 파이프라인 관리), 소비자 팀(분석가, BI팀, 머신러닝 엔지니어) 사이에서 고립된 사일로를 형성합니다.
•
사일로로 인한 문제:
◦
소스팀은 도메인 전문성을 가지고 있지만, 데이터 공유 과정에서 단절
◦
데이터 엔지니어팀은 기술 스택과 파이프라인에 정통하지만, 도메인 이해 부족
◦
소비자팀은 필요한 데이터를 적시에 받지 못해 불만 증가
•
결과적으로 과도한 요구사항, 도메인 전문성 부족, 긴 대기 시간, 커뮤니케이션 비용 증가로 인해 데이터 팀은 실적을 인정받지 못하고, 변화에 민첩하게 대응하기 어려워집니다.
모놀리식 기술과 파이프라인 문제
•
DAG 기반 파이프라인 정의의 한계: 데이터 프로세싱 파이프라인은 비순환 방향 그래프(DAG)로 정의되고 오케스트레이션되지만, 인터페이스나 계약 구조가 부족합니다.
•
종속성과 복잡성 증가: 파이프라인이 커질수록 종속성이 늘어나며, “미로” 같은 복잡한 구조가 형성됩니다. 이는 데이터 변경이나 새로운 사용 사례 대응 시 방대한 조정 작업을 요구합니다.
•
가치 창출보다는 복잡성 해결에 집중: 결국 데이터 팀은 새로운 가치를 창출하기보다 복잡성 관리에 더 많은 시간과 자원을 투입하게 됩니다.
기술 중심 파티셔닝의 한계
•
기술적 기능별 분할: 기존에는 데이터 관리 한계를 해결하기 위해 팀을 ‘수집’, ‘클렌징’, ‘집계’, ‘보강’, ‘제공’ 같은 기술적 기능 중심으로 파티셔닝했습니다.
•
결과: 이러한 기술적 파티셔닝은 데이터 변화에 대한 대응 오버헤드를 증가시키며, 팀 간 동기화 비용을 높입니다.
•
활동별·결과별 세분화 시도: 팀을 활동별로 나눌 수도 있고, 결과별로 최적화하는 방식으로 접근할 수도 있습니다. 하지만 이러한 노력은 근본적으로 비즈니스 도메인보다는 구현 중심의 파티션으로, 여전히 속도와 스케일 달성에 한계가 있습니다.
•
어떤 방식으로든 모놀리식 아키텍처, 기술, 조직 구조로는 대규모 확장성과 민첩성을 확보하기 어렵습니다. 비즈니스 도메인을 중심으로 데이터 관리 방식을 전환하지 않는 한, 변화에 신속하고 유연하게 대응하는 것은 불가능에 가깝습니다.
마무리
이번 글에서는 전통적인 분석 데이터 아키텍처의 특징인 모놀리식 구조와 중앙 집중식 관리로 인해 비즈니스 변화에 민첩하게 대응하기 어렵고, 조직 전체의 데이터 요구를 효율적으로 충족시키지 못하는 한계를 확인했습니다. 이러한 방식은 데이터 양과 사용 사례 증가, 조직적 복잡성과 변화 속도에 대응하기 어렵게 만들고, 결과적으로 가치를 창출하기보다 복잡성 관리에 더 많은 시간을 쏟게 합니다.
다음 글에서는 이러한 문제를 해결하기 위한 데이터 메시의 논리적 아키텍처를 살펴봅니다. 데이터 프로덕트 퀀텀, 도메인별 분석 데이터 공유 인터페이스, 멀티플레인 플랫폼 아키텍처, 연합 컴퓨팅 거버넌스를 비롯한 핵심 개념을 통해, 데이터 메시가 어떻게 모놀리식 구조를 탈피하고 자율적이며 확장 가능한 데이터 생태계를 구현하는지 구체적으로 알아보겠습니다.