레이블이 Data Mesh인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Data Mesh인 게시물을 표시합니다. 모든 게시물 표시

8/20/2025

Data Lake, Data Mesh, Data Fabric 주요 차이점



우리는 효과적인 의사 결정을 위해 데이터에 기반한 인사이트에 의존한다. 그래서 데이터 관리를 위한 적절한 프레임워크나 플랫폼을 선택하는 것이 매우 중요하다. 오늘날 가장 널리 사용되는 것은 Data Lake, Data Mesh, Data Fabrrc 등이 있다.

위에서 언급한 3가지의 주요 차이점을 이해하면 데이터 환경을 최적화학고 목표에 맞게 조정할 수 있다. 본 글에서는 가지에 대해서 비교하고 장단점을 간략하게 설명하려고 한다.


Data Lake란 무엇인가?

Data Lake는 방대한 양의 정형, 반정형 혹은 비정형 데이터를 정제되지 않은 원본 데이터 그대로 모두 한곳에 모아두는 거대한 저장소이다. 마치 도시 전체의 모든 물을 한 호수에 모아두는 것과 같다. 현재 툴들은 이 개념에 트랜잭션 제어 및 스키마를 결합한 레이크하우스로 진화하고 있다.


특징

  1. 모든 데이터가 한 곳에 모이기에 중앙 집중형이다.
  2. 데이터를 저장할 때 스키마(데이터 구조)를 미리 정의하지 않아도 된다. 데이터를 사용할 때 스키마를 적용한다. 이 방식을 Schema-on-read라고 한다.

장점

  1. 다양한 종류의 데이터를 한 곳에 모아서 분석하기 좋다.
  2. 분석각가 선호하는 다양한 도구를 사용할 수 있다.
  3. 데이터가 증가함에따라 효율적으로 확장된다.

단점

  1. 데이터가 너무 많고 정리가 안 되어 있으면, Data Swamp에 빠질 수 있다. 필요한 데이터를 찾거나 분석하기 어려울 수 있다. 그래서 체계적으로 정리하고 사용가능하게 유지하기 위한 거버넌스가 필요하다.
  2. 대규모 저장, 관리 및 분석은 비용이 많이 들 수 있다.
  3. 적절한 메타데이터 관리 및 거버넌스가 없다면, 관리가 어려운 저장소가 될 수 있다.

Data Mesh란 무엇인가?

Data Mesh는 데이터를 한곳에 모으지 않고, 각 데이터를 생성하는 곳에서 직접 관리하고 책임지는 분산형 아키텍처이다. 마치 동네마다 식수를 관리하는 정수장이 있는 것과 같다. 데이터의 소유권을 분산하여, 데이터를 사용하는 사람이 필요할 때 쉽게 접근하고 사용할 수 있게 만드는 개념이다.


특징

  • 소유권 분산: 데이터는 데이터를 가장 잘 아는 팀이 소유하고 관리한다.
  • 데이터를 상품처럼 취급: 각 팀은 대ㅔ이터를 잘 가공해서, 다른 팀이 쉽게 사용할 수 있는 “데이터 상품”으로 만들어 제공한다. 이 데이터 제품은 품질이 보장되고, 문서화되어 있으며 접근하기 쉬워야 한다.
  • 셆프 서비스: 데이터를 생성하고 소비하는 곳이 필요한 도구를 직접 사용할 수 있도록 도구를 제공한다.
  • 연합 통제: 중앙에서 모든 것을 통제하는 대신, 각 팀이 자율적으로 운영하되, 공통의 규칙과 표준을 준수한다.

장점

  1. 데이터 소유권이 명확하여 책임 소재가 분명하다.
  2. 데이터 소비자가 필요한 데이터를 더 빠르고 쉽게 찾고 사용할 수 있다.
  3. 거대한 중앙 집중 관리가 아니기에 민첩성이 높아진다.

단점

  1. 초기 도입이 복잡하고 어렵다.
  2. 조직 문화와 구조의 변화가 필수적이다.
  3. 공통의 표준을 유지하지 못하면 데이터 파편화가 발생할 수 있다.

Data Fabric

Data Fabric은 데이터가 어디에 있든 상관없이, 마치 하나의 논리적인 통로처럼 연결해서 사용할 수 있게 해주는 개념이다. 마치 여기저기 흩어져 있는 물탱크들을 하나의 거대한 파이프 시스템으로 연결해서, 어디서든 원하는 물을 끌어다 쓸 수 있게 하는 것과 같다.


특징

  • 데이터 카탈로그: 모든 데이터의 위치와 정보를 메타데이터 형태로 관리한다.
  • 데이터 가상화: 실제 데이터를 복제하지 않고, 마치 한 곳에 있는 것처럼 논리적으로 연결하여 실시간으로 접근하게 해준다.
  • AI 및 ML: 데이터를 자동으로 분류하고, 메타데이터를 생성하며, 데이터 흐름을 최적화하는데 사용된다.

장점

  • 데이터가 물리적으로 분산되어 있더라도 쉽게 접근하고 통합할 수 있다. (실시간 분석)
  • 기존 인프라를 크게 바꾸지 않고도 도입이 가능하다.
  • 데이터 이동을 최소화하여 데이터 보안과 거버넌스를 강화할 수 있다.

단점

  • 기술적으로 꽤 복잡하고, 구현 비용이 높을 수 있다.
  • 중앙 거버넌스와 각 데이터 소유자 간의 균형을 맞추려고 할 때 병목이 발생할 수 있다.
  • 도구 통합이 어려울 수 있다.

지금까지 3가지 기술에 대해서 알아보았다. 요약하면 아래와 같다.

  • Data Lake: 데이터를 저장하는 방식에 대한 개념이고 모든 데이터를 한곳에 모은다.
  • Data Mesh: 데이터를 관리하는 조직 및 문화에 대한 개념이다. 데이터 소유권을 분산시키고, 데이터를 상품처럼 다룬다.
  • Data Fabric: 데이터를 기술적으로 연결하는 솔루션에 대한 개념이다. 데이터가 어디에 있든 통합해서 사용할 수 있게 한다.

위에서 언급한 이 세 가지 개념은 서로 배타적이지 않고 상호 보완적이다. 예를 들어서 Data Lake를 기반으로 Data Mesh를 구축하거나, Data Fabric 기술을 활용하여 Data Mesh를 구현할 수 있다.

  • Data Lake는 데이터의 물리적 저장 공간을 제공
  • Data Mesh는 이 데이터를 누가 어떻게 책임지고 관리할지에 대한 조직적 접근 방식을 제시
  • Data Fabric은 데이터가 어디에 있든 간에 쉽게 접근하고 연결하는 기술적 솔루션을 제공

사용 사례

Data Lake

Twitter의 경우 방대한 양의 트윗 데이터, 사용자의 상호 작용 등의 데이터를 Lake에 저장한다. 이 원시 데이터 저장소는 피드 알고리즘 개선, 인기 트윗 파악 등의 분석을 지원한다.

Tesla의 경우는 Data Lake를 사용하여 차량, 제조 공정 및 충전 인프라의 센서 데이터를 저장한다. 포괄적인 데이터 수집을 통해 자율주행, 유지 보수 예측 및 운영 최적화를 위한 ML 학습데이터롤 사용된다.


Data Mesh

Uber는 분산형 소유권 체계를 이용해 여러 부서가 데이터를 독립적으로 관리한다. 승차 매칭, 운전자 온보딩, 결제 처리 등 각 영역별 자율적으로 데이터를 관리한다.

Netflix는 시청자 참여 패턴, 콘텐츠 성과 지표, 추천 효과 등을 포함하는 데이터 세트를 관리하는 독립적인 팀을 운영하고 있다. 이런 방법으로 개인화된 시청 경험을 제공하는 “데이터 상품”을 만든다.


Data Fabric

Cisco는 여러 데이터 소스를 통합하여 시장 동향을 분석하고, 제품을 개선하며, 고객 지원을 강화한다. 엔지니어링, 영업 및 지원 부서 전반에 실시간 인사이트를 제공하는 동시에 다양한 데이터 소스에 걸쳐 일관된 거버넌스 및 보안 정책을 유지한다.

Visa는 결제 처리 서비스 전반의 데이터를 통합하여 사기 탐지를 강화하고 규제 준수를 보장한다. 실시간 거래 모니터링을 지원하고 패턴 분석 및 위험 평가를 위한 과거 데이터에 대한 접근도 제공한다.


결론

위 사용 사례를 보면, 각 개념별 어떤 상황에서 사용해야 하는지가 대략적으로 나온다. 시나리오를 하나 만들어보자.

어떤 기업이 있다고 가정해보자. 이 기업은 여러 곳에서 생산되는 모든 데이터를 한 곳에 모아 분석하고 싶었다. 그래서 저렴한 대량의 원시 데이터를 저장할 수 있는 Data Lake를 구축했다. 즉, 모든 데이터는 중앙 호수에 모였다.

이렇게 사용하다보니, 데이터의 양이 기하급수적으로 늘어났다. 그러다가 Data Swamp로 변해갔다. 어떤 데이터가 유용한지, 누가 데이터를 소유하고 있는지 불분명해졌고, 데이타의 품질도 낮아졌다. Data Lake를 관리하는 조직은 모든 부서의 요청을 처리하느라 업무 부하가 커져갔다.

위 문제를 해결하기 위해 Data Mesh라는 새로운 개념을 도입하게 되었다. 생산되는 데이터에 대한 책임은 각 담당 부서에서 지고, 이 데이터를 “데이터 상품”으로 만들어 제공하기 시작했다. 다른 부서가 데이터를 원하면 중앙팀을 거치지 않고 해당 부서가 직접 제공하는 잘 정리된 데이터 제품을 사용하게 되었다.

Data Mesh를 도입했지만, 여전히 각 부서의 데이터가 서로 다른 시스템에 흩어져 있었다. 같이봐야 하는 상황들이 발생했지만, 쉽지 않았다. 이 문제를 해결하기 위해 Data Fabric을 도입했다. Data Fabric은 “데이터 상품”을 찾고 통합하여 필요한 곳에 제공하는 역할을 담당하게 되었다. LLM Agent와 같은 최신 기술이 모든 데이터 소스에 손쉽게 접근할 수 있게 되었다.

즉, Data Lake에 Data Mesh라는 구조를 보강하고, 그 구조를 원활하게 작동시키는 기술 레이어로 Data Fabric을 활용하는 것이 복잡한 데이터 환경에서 가장 이상적이고 일반적인 모델이 되어 가고 있다고 생각한다.

결국 데이터 플랫폼의 목표는 사용자가 원하는 시점에 필요한 데이터를 제공하는 것이다. Silo되게 관리가 되어 왔고, 이런 문제를 해결하기 위해 Data Lake에 몇 년전부터 주목을 했던 것 같다. 데이터를 한곳에 모았으니 이제 모든걸 다 할 수 있을지 알았다.

그러다가 Data Lake가 모든 문제를 해결할 수 있는 만능 열쇠가 아니라는 것을 알게 되었다. 우선 데이터를 복제해야 하기에 인프라에 막대한 투자 비용이 필요했고, 하나의 호수에서 어떠한 데이터든 찾을 수 있다는 발상은 좋았지만, 일부 전문가만이 원천 데이터를 가공하여 유의미한 인사이트를 얻을 수 있었다. 데이터를 한곳에 모아서 제공한다는 취지는 좋았지만, 활용면에서는 유용하지 못했기 때문이다.

데이터 플랫폼의 목표는 앞에서 언급한 것과 같이 “데이터를 원하는 사용자에게 원하는 시점에 필요한 데이터를 제공”하는 것이다. 여기서 원하는 사용자는 데이터 전문가가 아닌 일반인도 포함된다. 따라서 Data Lake는 사용자에게 전문적인 역량을 요구하기에 Gap이 발생하게 된다.

그래서 Data Mesh라는 개념이 나왔다. 데이터를 생산하는 조직이 소유권을 가지며 관리하는 전략이다. 해당 데이터 전문가도 해당 데이터를 다루는 곳에 분산 배치할 수 있게 된다. 각 조직에서 생산하는 데이터에 대해서는 빠르게 데이터 상품을 만들 수 있었고, 각 부서의 도메인 지식을 살린 데이터 관리 전략을 수립할 수 있게 되었다. 중앙화된 데이터 플랫폼을 통하지 않기에., 데이터의 실시간성을 확보할 수 있었다.

이렇게 사용하다보니, 다시 전사 데이터에 대한 Needs가 생겼다. 서로 다른 조직 간에 데이터를 조회하고 공유할 수 있도록 데이터 가상화나 데이터 페더레이션이 필요했다. 그렇다고 다시 Data Lake로 회귀할 순 없었다. 이미 경험한 과정이기 때문이다. 그래서 Data Fabric으로 전사 데이터를 물리적으로 통합하는 대신, 기존에 저장된 데이터 저장소들을 유기적으로 연결 할 수 있는 데이터 가상화 기술을 활용했다. 단일화된 데이터 가상화 플랫폼에서 데이터를 필요로 하는 사용자가 손쉽게 검색하고 빠르게 획득할 수 있는 파이프라인을 만들면서 데이터 사일로를 방지했다. 물리적 통합이 아닌 논리적 통합인 것이다.

데이터를 복제하지 않기에, 저장 관점에서는 비용 효율적이기도 했다. 보안적으로도 이점이 있다. 논리적인 통합이기에 가상 레이어에서 단일 통로로만 접근이 가능하기에 이력, 활동 내역등을 효과적으로 관리할 수 있게 되었다. 그러나 단점도 존재했다. 데이터의 실시간성을 확보할 순 있지만, 원천 데이터 저장소에 부하를 가할 수 있기 때문이다.

결론적으로, 배치와 실시간이라는 두 가지 데이터 처리 요구 사항에 맞춰 활용해야 할 것으로 판단된다. Data Lake가 대용량 데이터의 안정적인 배치 처리를 위한 기반이라면, Data Fabric은 분산된 데이터의 실시간 통합 및 분석을 위한 기반으로 생각된다.

이 모든게 원활하게 동작되려면, 데이터 카탈로그가 잘 구성되어야 할 것이다. 잘 관리된 메타데이터는 데이터들 간의 전사적 연결성을 보여줄 수 있기에 매우 중요한 요소다. 메타 데이터가 잘 관리된다면, 자동화할 수 있다면, 실시간성 확보와 품질를 확보할 수 있을 것이다.

Data Lake를 통해 장기적인 분석을 위한 “진실의 원천”을 Data Fabric으로 실시간 의사결정을 위한 “즉각적인 통찰”을 얻는 것이 장점을 모두 활용할 수 있는 방안이라 생각한다. 단 메타 데이터가 잘 구성되어 있어야 할 것이다.