데이터 아키텍쳐의 과거, 현재, 미래

데이터 아키텍처가 필요한 이유는 무엇일까요?

데이터 중심 조직으로 거듭나는 것은 여전히 많은 기업의 최우선 전략적 목표 중 하나입니다. 데이터 중심이란 조직 내에서 이루어지는 모든 의사 결정과 프로세스의 중심에 데이터를 두는 것을 의미합니다.

리더들은 데이터 중심 조직으로 전환하는 것이, 초개인화와 고객 여정 재설계를 통해 고객 경험을 개선하고, 자동화와 머신러닝을 통해 운영 비용을 절감하며, 고위 전략 및 시장 포지셔닝에 중요한 비즈니스 트렌드를 파악할 수 있는 유일한 방법임을 잘 알고 있습니다. 데이터 플랫폼은 데이터가 번성할 수 있는 유리한 환경을 조성합니다.

데이터 플랫폼은 조직의 모든 데이터를 저장하고 처리하는 공간입니다. 이 플랫폼은 데이터를 수집, 정제, 변환하고 이를 활용하여 비즈니스 인사이트를 도출합니다. 데이터 플랫폼은 종종 서로 다른 벤더(Dbt, Snowflake, Kafka 등)가 제공하는 여러 통합 도구로 구성되기 때문에, 때로는 ‘현대적 데이터 스택’이라고도 불립니다.

 

데이터 플랫폼의 핵심 요소 중 하나는 데이터 아키텍처입니다. 데이터 아키텍처란 조직의 데이터 자산 구조를 설계, 구축 및 관리하는 과정을 말합니다. 이는 다양한 소스와 애플리케이션의 데이터를 통합하기 위한 프레임워크와 같습니다.

잘 설계된 데이터 아키텍처의 주요 목표는 데이터 사일로를 줄이고, 데이터 중복을 최소화하며, 데이터 관리 프로세스의 전반적인 효율성을 높이는 것입니다.

지난 수십 년간 데이터 환경이 진화함에 따라 데이터 아키텍처도 함께 발전해 왔습니다. 그 진화 과정을 좀 더 자세히 살펴보겠습니다.

 

1세대: 데이터 웨어하우스 아키텍처

데이터 웨어하우스 아키텍처는 운영 시스템(SAP, Salesforce) 및 자사 데이터베이스(MySQL, SQL Server)에서 비즈니스 인텔리전스 시스템으로의 데이터 이동을 통해 정의됩니다. 데이터 웨어하우스는 스키마(스노우플레이크 스키마, 스타 스키마)가 정의되고 데이터가 차원 테이블과 팩트 테이블에 저장되는 중심점으로서, 이를 통해 기업은 운영 및 고객 상호작용의 변화를 추적하고 파악할 수 있습니다. 데이터는 다음과 같습니다:

 

1. 다양한 운영 데이터베이스 및 소스에서 추출
2. 다차원적이고 시간 변동성을 반영한 표 형식의 범용 스키마로 변환
3. CDC(변경 데이터 캡처) 프로세스를 통해 데이터 웨어하우스 테이블에 로드
4. SQL과 유사한 쿼리를 통해 접근
5. 주로 데이터 분석가의 보고 및 분석 시각화 용도로 활용

이러한 아키텍처 방식에서는 데이터 마트도 활용됩니다. 데이터 마트는 데이터 웨어하우스 위에 구축된 추가 계층(하나 또는 여러 개의 테이블로 구성됨)으로, 특정 스키마 형식을 통해 특정 부서의 비즈니스 문제를 해결하는 데 사용됩니다. 데이터 마트가 없다면, 해당 부서들은 필요한 내용과 형식의 데이터를 얻기 위해 웨어하우스 내에서 직접 데이터를 탐색하고 여러 쿼리를 작성해야 할 것입니다.

출처: Data Mesh Book

이 접근 방식의 주요 과제:

• 시간이 지남에 따라 수천 개의 ETL 작업, 테이블, 보고서가 축적되는데, 이를 이해하고 유지 관리할 수 있는 것은 소수의 전문가 그룹뿐입니다.
• CI/CD와 같은 현대적인 엔지니어링 관행이 적용되지 않습니다.
• 데이터 웨어하우스를 위한 데이터 모델과 스키마 설계가 너무 경직되어 있어, 다양한 소스에서 유입되는 방대한 양의 구조화 및 비구조화 데이터를 처리하기 어렵습니다.

이로 인해 차세대 데이터 아키텍처가 필요하게 되었습니다.

 

2세대: 데이터 레이크 아키텍처

데이터 레이크 아키텍처는 데이터 웨어하우스 아키텍처가 데이터의 새로운 활용 방식, 즉 머신러닝 모델 훈련 과정에서 데이터 과학자들이 데이터에 접근하는 요구를 충족하는 데 어려움을 겪자, 이에 대응하기 위해 2010년에 도입되었습니다.

데이터 과학자들은 머신러닝(ML) 모델 훈련 과정을 위해 원본 형태의 데이터가 필요합니다. 또한 ML 모델은 방대한 양의 데이터를 필요로 하는데, 이는 데이터 웨어하우스에 저장하기 어려울 수 있습니다.

초기 데이터 레이크는 클러스터화된 컴퓨팅 노드 세트에 걸쳐 Hadoop 분산 파일 시스템(HDFS)에 데이터를 저장하는 방식으로 구축되었습니다. 데이터는 MapReduce, Spark 및 기타 데이터 처리 프레임워크를 사용하여 추출 및 처리되었습니다.

 

데이터 레이크 아키텍처는 ETL 프로세스가 아닌 ELT 프로세스를 기반으로 작동합니다. 데이터는 운영 시스템에서 추출(E)되어 중앙 저장소(L)로 로드됩니다. 그러나 데이터 웨어하우징과 달리, 데이터 레이크는 데이터에 대한 사전 변환이나 모델링을 거의 또는 전혀 수행하지 않습니다. 목표는 데이터를 원본 형태에 가깝게 보존하는 것입니다. 데이터가 레이크에 유입되면, 아키텍처는 원시 데이터를 모델링하고 데이터 웨어하우스나 피처 스토어에 저장하기 위한 데이터 변환 파이프라인(T)으로 확장됩니다.

데이터 엔지니어링 팀은 레이크를 더 효율적으로 구성하기 위해 다양한 "존(zone)"을 생성합니다. 목표는 가장 원시적인 데이터부터 데이터 보강 단계, 그리고 가장 정제되고 접근성이 높은 데이터에 이르기까지, 정제 및 변환 정도에 따라 데이터를 저장하는 것입니다.

이 데이터 아키텍처는 데이터 웨어하우징에 필요한 광범위한 사전 모델링의 비효율성과 마찰을 개선하는 것을 목표로 합니다. 사전 변환은 데이터 액세스 및 모델 훈련의 반복 속도를 저하시키는 장애요인이 됩니다.

출처: Data Mesh Book

이 접근 방식의 주요 과제:

• 데이터 레이크 아키텍처는 복잡성과 성능 저하로 인해 데이터 품질과 신뢰성이 떨어지는 문제가 있습니다.
• 초전문화된 데이터 엔지니어들로 구성된 중앙 팀이 운영하는 복잡한 배치 또는 스트리밍 작업 파이프라인.
• 이로 인해 관리되지 않는 데이터 세트가 생성되는데, 이는 종종 신뢰할 수 없고 접근이 불가능하여 가치가 거의 없습니다.
• 데이터 계보와 종속성을 추적하기 어렵습니다.
• 사전에 포괄적인 데이터 모델링이 이루어지지 않아 서로 다른 데이터 소스 간의 의미적 매핑을 구축하는 데 어려움이 발생하며, 이로 인해 데이터 늪이 형성됩니다.

3세대: 클라우드 데이터 레이크 아키텍처

2세대 데이터 아키텍처에서 3세대 데이터 아키텍처로 넘어오면서 가장 큰 변화는 클라우드로의 전환, 실시간 데이터 가용성, 그리고 데이터 웨어하우스와 데이터 레이크의 융합이었습니다. 좀 더 자세히 살펴보면 다음과 같습니다.

• Kappa와 같은 아키텍처를 통해 스트리밍을 지원하여 준실시간 데이터 가용성을 확보합니다.
• Apache Beam과 같은 프레임워크를 사용하여 데이터 변환을 위한 배치 및 스트림 처리를 통합합니다.
• 클라우드 기반 관리형 서비스를 전면적으로 도입하고, 분리된 컴퓨팅 및 스토리지를 갖춘 최신 클라우드 네이티브 구현 방식을 활용합니다. 데이터 저장 비용이 대폭 절감됩니다.
• 데이터 웨어하우스를 확장하여 내장형 ML 훈련 기능을 포함시키거나, 반대로 데이터 웨어하우스의 무결성, 트랜잭션 처리, 쿼리 시스템을 데이터 레이크 솔루션에 통합함으로써 웨어하우스와 레이크를 하나의 기술로 융합합니. Databricks Lakehouse는 웨어하우스와 유사한 트랜잭션 및 쿼리 지원을 제공하는 전통적인 레이크 스토리지 솔루션의 예입니다.

Source: Databricks blog

클라우드 데이터 레이크는 이전 세대의 몇 가지 한계점을 해소하고 있습니다. 하지만 여전히 해결해야 할 과제가 남아 있습니다.

• 데이터 레이크 아키텍처는 관리가 여전히 매우 복잡하여 데이터 품질과 신뢰성에 영향을 미칩니다.
• 아키텍처 설계는 여전히 중앙 집중식이어서 고도로 전문화된 데이터 엔지니어 팀이 필요합니다.
• 인사이트 도출에 오랜 시간이 소요됩니다. 데이터 사용자들은 분석이나 머신러닝 활용을 위한 데이터 세트를 얻기 위해 여전히 수개월을 기다려야 합니다.
• 데이터 웨어하우스는 더 이상 데이터를 통해 현실 세계를 재현하지 못하여, 데이터 탐색 시 데이터 사용자의 경험에 부정적인 영향을 미치고 있습니다.

이러한 모든 과제는 우리를 4세대 데이터 아키텍처로 이끌었으며, 이 글이 게시되는 시점에서 이 아키텍처는 아직 초기 단계에 있습니다.

 

4세대: 데이터 메시 아키텍처

데이터 메시 아키텍처는 기존의 중앙 집중식 아키텍처에서 드러난 몇 가지 과제를 해결하기 위해 고안된, 비교적 새로운 데이터 아키텍처 접근 방식입니다.

데이터 메시는 마이크로서비스가 모놀리식 애플리케이션에 가져온 변화를 데이터 아키텍처에 적용합니다.

데이터 메시에서는 데이터가 분산화되며, 데이터에 대한 소유권이 여러 도메인에 분산됩니다. 각 도메인은 데이터 모델링, 저장, 거버넌스를 포함하여 해당 범위 내의 데이터에 대한 책임을 지며, 아키텍처는 각 도메인이 데이터를 독립적으로 관리할 수 있도록 지원하는 일련의 관행을 제공해야 합니다.

 

다음은 데이터 메시 아키텍처의 주요 구성 요소입니다:

1. 도메인 — 도메인은 자체 데이터를 소유하고 관리하는 독립적인 비즈니스 단위입니다. 각 도메인은 명확한 비즈니스 목적을 가지며, 데이터를 관리하기 위한 데이터 모델링, 엔티티, 스키마 및 정책을 정의할 책임이 있습니다. 이 개념은 마케팅이나 영업과 같은 서로 다른 팀을 위해 설계된 데이터 웨어하우스 아키텍처의 데이터 마트와는 다릅니다. 데이터 메쉬 아키텍처에서 영업 팀은 팀의 다양한 중점 분야나 영역에 따라 여러 도메인을 가질 수 있습니다.
2. 데이터 제품(Data Products) — 데이터 제품은 도메인에서 생성된 최종 결과물로, 다른 도메인이나 애플리케이션에서 활용할 수 있도록 제공됩니다. 각 데이터 제품은 명확한 비즈니스 목적을 가지고 있습니다. 하나의 도메인이 여러 데이터 제품을 처리할 수도 있습니다. 모든 데이터 자산이 데이터 제품으로 간주되거나 데이터 제품으로 취급되어야 하는 것은 아닙니다(비록 이상적인 상황에서는 그럴 수 있겠지만). 데이터 제품은 조직 내에서 핵심적인 역할을 수행하는 데이터 자산입니다.
3. 데이터 인프라 — 데이터 인프라는 소프트웨어 애플리케이션의 컨테이너화된 마이크로서비스와 유사하게, 도메인 내 데이터를 관리하는 데 필요한 도구와 기술을 포함합니다. 여기에는 데이터 저장, 처리 및 분석 도구가 포함됩니다.
4. 데이터 거버넌스 — 데이터 거버넌스는 각 도메인에서 관리합니다. 이는 데이터 품질, 개인정보 보호 및 보안을 관리하기 위한 일련의 절차를 의미합니다.
5. 메시 API — 마이크로서비스가 HTTP REST API를 통해 모든 기능을 노출하는 것처럼, 데이터 메시 도메인은 다른 도메인과 데이터 제품이 활용할 수 있는 명확하게 정의된 인터페이스를 통해 모든 기능을 노출합니다.

데이터 메시 아키텍처. 각 도메인 팀은 자체적으로 도메인 간 데이터 분석을 수행합니다. 해당 도메인은 운영 데이터를 수집하고, 분석 데이터 모델을 데이터 제품으로 구축한 뒤, 데이터 계약과 함께 이를 공개하여 다른 도메인의 데이터 요구 사항을 충족시킵니다. Source: datamesh-architecture.com

데이터 메시(Data Mesh)는 오늘날 데이터 아키텍처가 설계되는 방식과 데이터 팀이 조직되는 방식에 있어 패러다임의 전환으로 볼 수 있습니다:

• 데이터 팀은 소프트웨어 제품 팀이 서비스 지향적인 것처럼, 기술 분야가 아닌 하나 이상의 비즈니스 도메인을 전문으로 하는 크로스-기능 팀으로 변모합니다.
• 하나 또는 여러 개의 마이크로서비스로 구성된 각 비즈니스 도메인은, 마이크로서비스의 각 구성 요소가 독립적으로 작동하도록 컨테이너화되는 것과 마찬가지로, 자체적인 OLAP 데이터베이스와 분산 파일 스토리지 시스템을 갖추게 됩니다.
• 데이터 제품 A는 데이터 제품 B에 의해 소비되며, 애플리케이션 마이크로서비스들이 서로 통신하는 것처럼 두 제품 모두 스트리밍이나 REST API를 통해 다른 데이터 제품들과 통신하게 됩니다.
• 데이터 제품 API는 기존의 REST API 문서화 방식을 따르며, 데이터 제품은 메쉬 데이터 카탈로그를 통해 검색할 수 있습니다.

팀들이 다른 도메인의 데이터 제품을 사용할 때 이러한 연계 구조가 형성됩니다. 상류 도메인은 기사, 주문 및 고객 데이터 제품을 공개하며, 이러한 데이터 제품은 배송과 같은 다른 데이터 제품에 의해 상류에서 활용되거나, 머신러닝 모델, CRM 시스템 또는 분석 시스템과 같은 하류에서 활용됩니다. Source: datamesh-architecture.com

 

아키텍처 외에도 데이터 메시로 인해 어떤 변화가 일어나는가?

데이터 메시가 가져오는 가장 큰 변화는 아키텍처에 있습니다. 하지만 중앙 집중식 데이터 레이크에서 분산형 데이터 메시로 전환하는 것은 사회기술적 현상으로, 여러 가지 추가적인 변화를 수반합니다.

모놀리식 애플리케이션에서 마이크로서비스 애플리케이션으로의 전환은 소프트웨어 엔지니어링 팀이 개발 라이프사이클, 조직 구조, 동기, 기술 역량, 거버넌스를 변경하도록 만들었습니다. 바로 그때 애플리케이션이 실제 사용자의 문제를 해결할 수 있도록 보장하기 위해 제품 관리자(Product Manager)라는 역할이 등장했습니다.

데이터 메쉬 아키텍처를 적용할 때도 이와 같은 변화가 필요합니다.

 

<출처: https://aiverticaladvantage.substack.com/p/the-evolution-of-data-architecture>