금융 데이터, 통합만이 답일까? - 데이터 메시(Data Mesh)

금융 데이터 관점에서 본 데이터 웨어하우스(Data Warehouse)

데이터 통합, 그러나…

기업 내 분산된 데이터를 통합해 제공해 주는 DW(Data Warehouse)는 사실상 기업 데이터 아키텍처의 표준으로 자리 잡았습니다. 이러한 DW는 기업 내 조직별로 사일로(Silo)화된 데이터를 통합하고 일관성 있게 제공함으로써 기업이 효율적으로 데이터를 활용할 수 있도록 지원합니다. 하지만 보통 효율적인 데이터 통합을 위해서 DW팀을 별도로 구성하다 보니, 도메인 내 데이터의 변화가 DW까지 추적 관리되고 정합성을 유지하는 데는 많은 자원이 소요됩니다. 특히 금융 시스템의 경우 이러한 어려움은 더 커집니다. 그 이유는 무엇일까요?

데이터 규모보다 중요한 데이터 신뢰성

금융은 신뢰를 기반으로 합니다. 단 1원의 고객 계좌 잔액 불일치만으로도 금융사의 신뢰도가 하락할 수 있습니다. 또한 금융당국 및 타 금융기관들과 외환, 대출 등 다양한 금융정보를 교환해야 하기 때문에 금융 사업에서 데이터 신뢰는 매우 중요합니다. 이러한 이유로 금융 데이터는 업무를 가장 잘 이해하고 있는 도메인팀이 다루는 것이 합리적입니다.

잦은 데이터 변경

최근 금융상품이 다양화되면서 데이터 구조의 복잡성이 높아지고 있습니다. 또한 오픈뱅킹, 마이데이터 등 금융당국의 정책에도 대응해야 하기 때문에 금융사 내외적인 요인으로 인한 데이터 변경이 자주 발생됩니다. 이렇게 데이터 변경이 잦은 금융 데이터 특성상 도메인팀과 분리된 DW팀이 일관성 있는 데이터를 유지하는 데는 많은 어려움이 있습니다. 예를 들어, 입금을 구분하는 코드가 변경되었을 때, 해당 코드를 변경한 도메인팀은 당연히 변경 내역을 잘 반영하겠지만, 그것을 후행으로 사용하는 DW팀 입장에서는 변경 사항을 인지하고 반영하기가 쉽지 않습니다. 또한 코드 변경 시 DW 내 데이터 활용까지 고려하기 어렵기 때문에, DW팀이 보고 자료나 데이터 마트 등을 제공하는 데 곤란을 겪기도 합니다.

엄격한 컴플라이언스 대응

금융 사업은 법에 기반한 규제 산업입니다. 신용과 관련된 개인/기업 정보를 다루기 때문에 데이터 관리 시 엄격한 컴플라이언스가 요구됩니다. 공통적으로 적용되는 컴플라이언스 대응에는 통합된 DW 가 유리하겠지만, AML, 외환 거래, 개인정보 등 업종 지식이 동반된 규제의 경우 데이터를 통합하는 팀이 대응하기에는 한계가 있습니다.

데이터 메시(Data Mesh)^[1]

이와 같이 업무의 이해가 중요한 금융 데이터의 경우, 데이터 메시 아키텍처를 통해 데이터 관리에 대한 새로운 시사점을 발견할 수 있습니다. 데이터 메시는 ‘업무 도메인별 데이터 분산 관리’, ‘상품 개념의 데이터 제공’, ‘도메인팀 스스로 데이터 제공 및 활용이 가능한 데이터 플랫폼’, ‘도메인 간 상호 운용성 높은 거버넌스’를 바탕으로 하는 데이터 아키텍처 개념입니다.

[그림 1] 데이터 메시 주요 개념(출처: Data Mesh Architecture)

업무 도메인별 데이터 분산 관리(Domain Ownership)

데이터의 소유권은 기술이 아닌 해당 데이터를 가장 잘 이해하고 있는 도메인팀이 가집니다. 이 경우 업무 프로세스가 변경될 때 처리 프로세스뿐만 아니라 데이터 마트, 리포트, 외부 인터페이스 등 데이터를 활용하는 부분까지 변경사항을 일관되게 반영할 수 있습니다. 더불어 데이터에 문제가 발생하더라도 데이터 생산자인 도메인팀이 바로 대응함으로써 별도 커뮤니케이션 비용 없이 적시 대응이 가능해집니다.

상품 개념의 데이터 제공(Data as a Product)

데이터 소유권자는 데이터를 상품의 개념으로 제공합니다. 데이터뿐만 아니라 데이터 설명, 적재 주기, 관리 기준 등이 포함된 데이터 계약서(Data Contract)를 함께 제공함으로써 사용자가 쉽게 데이터를 활용할 수 있습니다. 제공자 입장에서는 자신의 데이터가 전사적으로 어떻게 활용되는지 파악할 수 있기 때문에, 비즈니스 요건 변경 시 데이터 활용 레벨까지 감안할 수 있게 됩니다.

도메인팀 스스로 데이터 제공 및 활용이 가능한 데이터 플랫폼(Self-Serve Data Platform)

데이터 소유자와 사용자들은 공통의 데이터 플랫폼이 필요합니다. 이를 통해 데이터 소유자는 자신이 가진 데이터를 직접 구성하고 공유할 수 있으며, 데이터 사용자들은 필요한 데이터를 스스로 찾고 활용할 수 있습니다. 이 데이터 플랫폼은 별도 전담 기술팀이 지원하고 배포함으로써, 도메인팀들은 기술적 구애 없이 일관된 방식으로 데이터를 제공하고 도메인팀 간 활용할 수 있게 됩니다.

도메인 간 상호 운용성 높은 거버넌스(Federated Governance)

각 도메인팀에 분산된 데이터들은 일관된 기준으로 통제되어야 합니다. 이를 통해 데이터가 고립되거나 중복되는 것을 방지하고, 각 도메인 간 연계를 원활하게 합니다. 그뿐만 아니라 일관된 권한 체계 적용을 통해 데이터의 오남용을 방지하고, 업계 컴플라이언스를 준수할 수 있게 합니다.

데이터 메시를 도입을 위한 주요 기술

데이터 아키텍처 개념인 데이터 메시는 특정 솔루션이나 프레임워크를 의미하지는 않지만, 여러 기술 요소를 활용해 데이터 메시의 목적을 달성할 수 있습니다.

데이터 카탈로그^[2]

데이터 카탈로그는 기업 내 다양한 유형의 데이터 자산을 목록화해 사용자가 필요한 정보를 빠르게 찾을 수 있게 하는 기술입니다. 자동 프로파일링을 통해 데이터 품질을 관리하고, 다양한 메타정보를 데이터와 함께 제공함으로써 데이터 거버넌스(Federated Governance)와 데이터 상품화(Data as a Product)에 활용될 수 있습니다. 데이터 카탈로그 관련 솔루션으로는 Data Catalog(Azure), Glue(AWS), Dataplex(Google), Unity Catalog(Databricks) 등이 있습니다.

[그림 2] DataPlex Overview Diagram(출처: InfoWorld)^[3]

쿼리 페더레이션(Query Federation)

쿼리 페더레이션이란 서로 다른 종류의 데이터들을 하나의 쿼리로 함께 조회할 수 있는 기술입니다. 분산된 도메인들의 데이터 기술 구조 및 위치에 상관없이, 데이터 카탈로그를 기반으로 서로 쉽게 연계해 활용할 수 있기 때문에 데이터 상품화(Data as a Product)를 가속화할 수 있습니다. 쿼리 페더레이션과 관련된 솔루션으로는 BigQuery(Google), Unity Catalog의 Lakehouse Federation(Databricks) 등이 있습니다.

[그림 3] Lakehouse Federation in Unity Catalog(출처: Databricks)^[4]

이렇게 논리적으로 통합된 데이터들은 별도의 데이터 복제 없이 바로 연계 활용 가능하다는 편리함이 있지만, 느린 데이터 조회 성능, 네트워크 트래픽의 증가 등의 한계도 존재합니다. 때문에 기존 ETL을 통한 데이터 복제와 혼용해 목적에 맞게 활용하는 것이 바람직합니다.

데이터 스트리밍(Data Streaming)

분산된 데이터들을 여러 저장소에 공유해야 하는 경우 데이터 스트리밍 기술을 고려할 수 있습니다. 데이터 스트리밍은 데이터 구조 및 값 변경 이벤트를 거의 실시간으로 전파함으로써 이벤트를 구독한 분산된 데이터 저장소의 기술 구조에 맞춰 동기화할 수 있습니다.

[그림 4] 데이터 스트리밍을 통한 분산된 저장소의 데이터 동기 처리(출처: KAI WAEHNER)^[5]

또한 데이터 변경 이벤트들은 데이터 스트리밍 플랫폼에 별도 저장되기 때문에, 데이터 원천 시스템의 부하 없이 많은 시스템에 데이터 공급이 가능합니다. 이런 변경 이벤트들은 저비용의 파일 형식으로 무제한 저장 가능하고 저장된 이벤트들을 재활용할 수 있기 때문에 데이터 복구에도 활용할 수 있습니다. 데이터 스트리밍과 관련된 솔루션으로는 Kafka(Apache), Dataflow(Google), Kinesis(Amazon) 등이 있습니다.

IaC (Infrastructure as Code)

각 도메인에 분산된 데이터를 표준화된 방법으로 활용(Inter Operation)하고, 기업의 거버넌스를 일괄 적용하기 위해서는 데이터 표준 플랫폼이 반드시 필요합니다. 이러한 표준 플랫폼은 새로운 도메인이 생길 때 적용이 쉬워야 하며, 플랫폼의 변경사항은 각 도메인의 데이터 플랫폼에 빠르게 적용되어야 합니다. 이를 위해 IaC(Infrastructure as Code)를 고려해 볼 수 있습니다.

IaC란 인프라를 수작업이 아닌 코드를 통해 관리하고 제공하는 기술입니다. 인프라 사양이 코드로 구성됨에 따라 동일한 인프라를 구성하기가 쉬워지며 템플릿화함으로써 인프라 구성을 자동화할 수 있습니다^[6]. 이를 통해 데이터 카탈로그, 쿼리 페더레이션, 데이터 스트리밍 등 데이터 메쉬를 지원할 기술과 관련된 인프라 요소를 코드화해 각 도메인에 동일하게 적용할 수 있습니다. IaC와 관련된 툴로는 Terraform(HashiCorp), CloudFormation(Amazon), Ansible(Red Hat) 등이 있습니다.

[그림 5] Terraform으로 구성한 Data Mesh 예제 코드^[7]

생성형 AI (Generative AI)

도메인 데이터를 외부와 공유하기 위해서는 사용자들이 해당 데이터를 이해할 수 있는 메타 정보가 필요합니다. 하지만 수많은 종류의 데이터들을 사람이 일일이 그 유형과 속성을 정의하기에는 많은 시간과 노력이 필요하며 이로 인해 유지 보수성 또한 떨어지게 됩니다. 이 경우 데이터 프로파일링에 AI를 활용해 데이터를 주제별로 자동 분류하고, 데이터 속성에 대한 설명 등을 자동 생성해 줌으로써 효율적인 메타데이터 관리가 가능해집니다[8]. 또한 특정 데이터를 확인하기 위해 보고서나 테이블을 조회해 찾는 것이 아니라, 생성형 AI를 통해 대화식으로 문의하고 원하는 부분만 바로 확인하는 등[9] 보다 직관적인 사용자 경험을 제공함으로써 데이터 활용을 확대시킬 수 있습니다.

데이터 메시 적용 시 고려사항

기술보다는 조직 관점의 접근^[10]

데이터 메시의 핵심은 “데이터 소유권을 누가 관리하는가?”라고 할 수 있습니다. 그만큼 데이터 메시를 적용하는 데 있어 조직 체계는 매우 중요합니다. 지금까지 도메인팀이 데이터 소유권을 가졌을 때의 장점을 살펴보았지만 단점도 존재합니다. 예를 들어 도메인팀의 경우 기존 업무에 더해 자료제공, 보안 등 데이터와 관련된 부가 업무가 가중될 수 있습니다. 또한 도메인 간 이기주의로 인해 데이터가 고립될 가능성도 있습니다. 때문에 각 조직들은 데이터 메시의 목적을 잘 이해하고, 각자의 역할과 책임을 명확히 해야 합니다. 또한 데이터 관리 성과에 대한 조직 차원의 보상이 필요할 수도 있습니다.

기술 지원 조직 필요

성공적인 데이터 메시 적용을 위해서는 이를 위한 데이터 메시 전담 기술지원팀이 필요합니다. 보통 도메인팀은 비즈니스 기반의 조직으로 DW팀에 비해 데이터 처리 기술이 부족합니다. 기술 지원팀은 도메인팀이 데이터를 관리하는 데 있어 기술적 문제를 해결해 주고, DataOps, 데이터 아키텍트 등을 지원함으로써 데이터 메시의 정착을 가속화합니다.

단계적 적용

데이터를 무조건 도메인별로 나누어 관리하는 것은 좋은 방법이 아닙니다. 오히려 조직이 작다면 데이터를 통합하여 관리하는 것이 더 효과적일 수 있습니다. 큰 조직의 경우라도 데이터 메시를 적용할 때는 작은 도메인부터 단계별로 적용해 가며 보완 확장해 나가는 것이 좋습니다.

마치며

지금까지 금융 데이터 관점에서 데이터 메시의 개념과 필요성, 관련 기술을 살펴보고, 적용 시 고려 사항도 알아보았습니다. 한편으로는 데이터 메시가 DW를 도입하기 전의 시절로 다시 회귀하는 것처럼 보일 수 있습니다. 하지만 데이터 메시는 도메인팀이 데이터를 관리함으로써 데이터 품질은 높이고, 분산된 데이터의 고립 등 과거에 해결하지 못했던 단점들은 발전된 기술을 활용해 해결합니다. 이렇게 데이터 메시를 도입하게 되면, 데이터를 통합하는 DW팀이나 데이터를 한곳에 수집하는 데이터 레이크가 필요 없게 될까요? 그렇진 않습니다. 다소 역할이 축소될 수 있으나, 여러 도메인 간 데이터를 통합해 제공해야 하는 업무 또한 데이터 메시 내 하나의 도메인으로서 역할을 할 것입니다.

데이터를 통합하여 관리할 것인가? 각 도메인이 데이터를 관리하되 활용 관점의 통합을 추구할 것인가? 데이터 메시를 달성하기 위한 방법은 여러 가지가 있을 수 있으며, 적용할 조직에 맞게 필요한 개념만 일부 채택할 수도 있습니다. 여러분께 데이터 메시가 데이터 관리의 새로운 인사이트가 되길 기대해 봅니다.



References
[1] DATA MESH ARCHITECTURE (Data Mesh Architecture (datamesh-architecture.com))
[2] 데이터 카탈로그란 무엇입니까? (https://www.tibco.com/ko/reference-center/what-is-a-data-catalog)
[3] Google Cloud Dataplex wows (https://www.infoworld.com/article/3692892/preview-google-cloud-dataplex-wows.html)
[4] Introducing Lakehouse Federation Capabilities in Unity Catalog (https://www.databricks.com/blog/introducing-lakehouse-federation-capabilities-unity-catalog)
[5] The Heart of the Data Mesh Beats Real-Time with Apache Kafka (https://www.kai-waehner.de/blog/2022/07/28/the-heart-of-the-data-mesh-beats-real-time-with-apache-kafka/)
[6] 코드형 인프라(IaC)란? (https://www.redhat.com/ko/topics/automation/what-is-infrastructure-as-code-iac)
[7] Infra As Code for Data products (https://medium.com/@jonatas.junior/infra-as-code-for-data-products-part-1-design-use-case-c2f70128ba43)
[8] Using generative AI to enrich Snowflake metadata with data.world (https://data.world/blog/using-generative-ai-to-enrich-snowflake-metadata/)
[9] Dremio’s Generative AI Features for Easy Analysis (https://www.dremio.com/generative-ai/)
[10] Bringing Data Mesh to life with Team Topologies (https://www.linkedin.com/pulse/bringigng-data-mesh-life-team-topologies-omar-khawaja)


▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.