2021.07.06

데이터 애널리틱스 솔루션 제1 기준 세우기 "개방형 vs. 폐쇄형"

Tomer Shiran | InfoWorld
데이터 애널리틱스 솔루션이 맹렬한 속도로 계속 출현하고 있다. 데이터 부서는 폭풍의 중심에 있다. 이들은 액세스, 데이터 무결성, 보안, 정책이나 규제 준수가 따라붙는 거버넌스 등 온갖 요구 사이에서 균형을 유지해야 하고, 거버넌스는 정책과 규제에 대한 컴플라이언스를 수반한다. 기업은 최대한 신속히 정보를 얻고 싶어 하고, 위험한 균형 잡기를 인내해 줄 의사가 없다. 데이터 부서는 신속하고 영리하게 행동해야 한다.  
  
ⓒ Getty Images Bank

현재를 위한 시스템뿐 아니라 미래를 위한 플랫폼도 구축해야 한다는 점에서 예언자도 될 수 있어야 한다. 데이터 부서가 데이터 아키텍처에 있어 가장 먼저 결정할 요소는 개방형이냐 폐쇄형이냐다. 
 

개방형 vs. 폐쇄형 데이터 아키텍처 

우선 ‘데이터 아키텍처(Data Architecture)’라는 단어부터 살펴보자. 지난 50년 동안의 기업의 데이터 아키텍처 다이어그램을 그려본다면 이는 데이터 자체라기보다는 사실상 데이터에 작용하는 엔진인 데이터베이스이다. 대표적으로 오라클, DB2, SQL서버, 테라데이터(Teradata), 엑사데이터(Exadata), 스노우플레이크(Snowflake) 등이 있다. 이들은 모두 데이터베이스고, 업무나 분석에 필요한 데이터세트가 로드되는 곳이다. 그리고 ‘데이터 아키텍처’의 토대다.

기본적으로 이들 데이터베이스는 ‘폐쇄형 데이터 아키텍처(Closed Data Architecture)’다. 가치적 표현이 아니라 설명적 표현이다. 여기서 데이터는 다른 애플리케이션에서 격리되고 데이터베이스 엔진을 통해서만 액세스된다. 심지어 ETL(Extract, Transform, and Load) 작업을 하면서 데이터를 옮길 때도 마찬가지다. 내보내기나 가져오기를 할 때 일정 시점에서 반드시 데이터베이스를 거쳐야 하기 때문이다. 그게 최적의 방식인지 아닌지는 문제가 아니다. 데이터가 아키텍처의 나머지 부분에 대해 ‘닫혀’ 있다는 점이 중요하다. 

대조적으로, ‘개방형 데이터 아키텍처(Open Data Architecture)’는 데이터를 아키텍처 내의 데이터 전용 계층(Tier)에 저장한다. 따라서 조직의 다양한 분석 니즈를 위해 다양한 최고의 엔진을 이용할 수 있다. 애널리틱스 처리 니즈를 위한 만능의 수단이 있었던 적이 없었기 때문에 중요한 일이다. 앞으로도 만능의 수단은 없을 것이다. 개방형 아키텍처는 오늘날 또는 미래의 최고의 서비스를 이용하는 데 이상적이다.

정리하자면 폐쇄형 데이터 아키텍처는 데이터를 데이터베이스 엔진으로 가져오고, 개방형 데이터 아키텍처는 데이터베이스 엔진을 데이터로 가져온다.

개방형 아키텍처를 평가하는 간단한 방법은 미래에 새 엔진을 도입하기가 얼마나 어려울 것인지를 생각하는 것이다. 새 엔진을 기존의 엔진과 나란히 실행할 수 있을까(동일한 데이터 상에서), 아니라면 전면적인 (사실상 비현실적인) 마이그레이션이 불가피할까?
 
ⓒ Dremio

여기서 개방형(Open)이라는 뜻은 오픈소스(Open Source)와 아무런 관계가 없음을 유의하라. 첫 단계는 데이터를 개방형으로 만들어 데이터를 활용하려는 서비스에게 공개할 것인지를 판단하는 것이다. 그 다음에는 클라우드 세계에서의 개방형 데이터를 고려해야 한다.
 

개방형의 서비스 지향적인 데이터 아키텍처 

애플리케이션이 클라이언트-서버에서 웹으로 이동하면서 아키텍처가 근본적으로 변경되었다. 애플리케이션은 한 프로세스에서 실행되던 단일 애플리케이션으로부터 서비스 지향 애플리케이션으로 변화했고, 더 작고, 더 전문적인 소프트웨어 서비스로 분할되었다. 궁극적으로 이는 ‘마이크로서비스’라고 알려졌고, 웹 및 모바일 애플리케이션의 지배적 설계이다. 마이크로서비스 접근법은 클라우드 인프라의 본질로 인해 여러 장점이 있었다. 온디맨드 리소스 모델과 함께 작용하고 수많은 부서가 각종 기능성을 작업하는 스케일아웃 시스템에서, 애플리케이션은 수십, 수백 가지 마이크로서비스가 내재된 일종의 포장에 불과하다. 

이 접근법은 모듈형 및 조정형 애플리케이션을 제작할 때 장점이 많다. 이 패러다임이 데이터에 있어서는 그만큼 효과적이지 않다고 믿을 만한 이유가 있지만, 드레미오(Dremio)는 그렇게 생각하지 않는다. 애플리케이션과 동일한 개방형, 서비스 지향적 관점으로 데이터를 바라본다는 논리는 직관적으로 의심의 여지가 없고 적절하다. 실무적이고 전략적인 차원에서 개방형의 서비스 지향적 데이터 아키텍처는 당연히 타당하다.

이것이 바로 오픈소스 소프트웨어 문제가 부차적인 이유이다. 가장 중요한 것은 개방형 데이터 아키텍처가 폐쇄형 아키텍처보다 더 적절하다는 점이다. 일단 그렇게 되면 획기적인 이점이 생겨난다. 개방형 파일 및 표 포맷, 예를 들어 아파치 파켓(Apache Parquet), 아파치 아이스버그(Apache Iceberg) 등은 업계 전반에 걸쳐 혁신을 허용하기 때문에 결정적이다. 혁신은 독립 데이터 계층에 작용하는 서비스의 형태로 전달된다. 번잡하고 값비싸고 취약하고 컴플라이언스를 훼손하는 데이터 복제가 크게 줄어들거나 심지어 사라진다. 데이터 부서는 데이터와 작용할 최고의 서비스를 선택할 수 있고, 10년 넘게 애플리케이션 서비스에서 해온 것과 똑같이 아키텍처에 삽입하기만 하면 된다. 이제는 데이터 아키텍처에 속도를 더할 시간이다. 

개방형 데이터 아키텍처의 가치를 반박하는 정당한 주장이 없지는 않다. 너무 복잡하다는 것이다. 복잡성은 중대한 기술적 변화에 항상 수반된다. 중형 컴퓨터가 처음에는 기성의 메인프레임보다 관리하기가 더 까다로웠다. 인텔 기반의 서버는 처음에는 중형 시스템보다 관리하기가 더 까다로웠다. PC를 관리하는 일은 처음에는 기존의 지능이 없는 단말 장치를 관리하는 것보다 더 까다로웠다. 정리해보자. 기술 변화가 일어날 때마다 이는 일반적인 도입 곡선을 따라 주류로 편입된다. 관리 측면에서 초기 시절은 언제나 더 복잡하다. 그러나 시간이 가면서 새로운 툴과 접근법이 복잡성을 줄이고, 처음의 복잡성 비용을 훨씬 능가하는 혜택을 가져온다. 이것이 바로 혁신하는 이유이다.

개방형의 서비스 지향적 데이터 아키텍처를 훨씬 쉽고 훨씬 위력적으로 만들기 위해 제작된 클라우드 데이터 레이크 엔진의 한 예로 드레미오(Dremio)를 들 수 있다. SQL을 레이크하우스에서 실행하는 것은 간단하다. 모든 조각을 통합해놓았기 때문이다. 그리고 그 과정에서 획기적인 오픈소스 프로젝트, 예를 들어 네시(Nessie), 아파치 애로우(Apache Arrow), 애로우 플라이트(Arrow Flight) 등이 탄생했다. 이들은 오픈소스 프로젝트이고, 오픈소스 기술은 도입과 상호 운용성을 촉진한다. 조직의 데이터 아키텍처 내의 서비스 통합 계층에서 결정적인 역할을 한다. 업계 전체가 핵심 기술을 작업하고 혁신하기 때문에 고객은 한층 우수한 서비스를 받을 수 있다. 오픈소스 애호가는 이를 이해할 수 있도록, 심지어 개선할 수 있도록 코드에 접근한다. 그리고 이들 혁신은 레이크하우스 상에서 SQL을 빠르고 쉽게 만든다.

한 마디로 정리하자면, 업체가 아무리 ‘개방형’이라고 주장하더라도, 아무리 개방형 포맷과 개방형 표준을 지원한다고 말하더라도, 심지어 근본적으로 오픈소스 업체여도 데이터 아키텍처가 폐쇄형이면 폐쇄형이다. 

스노우플레이크는 최근 기사에서 비즈니스 요구사항을 충족하려면 데이터 포맷, 스토리지 소유권 등의 영역은 폐쇄형이어야 한다고 주장했다. 20년 전이라면 사실일 수 있다. 그러나 최근 클라우드 스토리지, 트랜잭션 테이블 포맷의 발전으로 인해 이제 개방형 아키텍처도 이런 요구사항을 충족할 수 있다. 개방형 아키텍처로 요구사항을 충족하면서 모든 혜택을 누릴 수 있다면 굳이 폐쇄형 아키텍처를 선택할 이유가 있을까? 이게 스노우플레이크가 많은 시간을 할애하면서 개방형이 중요하지 않다고 주장한 이유일지도 모른다. 
 

1등 시민으로서의 데이터 

개방형 아키텍처 옹호자의 목적은 데이터가 아키텍처 내의 1등 시민인 세계를 지향하면서 기업에 개방형 아키텍처의 혜택을 이해시키는 것이다. 개방형 아키텍처의 혜택이란 각종 작업에서 가장 적합한 최고의 엔진을 이용할 수 있는 유연성, 기업 데이터에 액세스해야 할 때 사기업 소유의 엔진에 종속되는 것을 방지, 미래 혁신 이점을 활용할 수 있도록 대비, 데이터의 끝없는 복제 및 이동에 따른 복잡성 제거를 말한다. 

개방형 아키텍처가 구현하고 사용하기가 쉬워질수록 폐쇄형 데이터 아키텍처보다 훨씬 큰 혜택을 가져올 것이다. 모멘텀이 강화되고 있고, 목적지는 개방형 데이터 아키텍처가 핵심이 되는 미래다. editor@itworld.co.kr


2021.07.06

데이터 애널리틱스 솔루션 제1 기준 세우기 "개방형 vs. 폐쇄형"

Tomer Shiran | InfoWorld
데이터 애널리틱스 솔루션이 맹렬한 속도로 계속 출현하고 있다. 데이터 부서는 폭풍의 중심에 있다. 이들은 액세스, 데이터 무결성, 보안, 정책이나 규제 준수가 따라붙는 거버넌스 등 온갖 요구 사이에서 균형을 유지해야 하고, 거버넌스는 정책과 규제에 대한 컴플라이언스를 수반한다. 기업은 최대한 신속히 정보를 얻고 싶어 하고, 위험한 균형 잡기를 인내해 줄 의사가 없다. 데이터 부서는 신속하고 영리하게 행동해야 한다.  
  
ⓒ Getty Images Bank

현재를 위한 시스템뿐 아니라 미래를 위한 플랫폼도 구축해야 한다는 점에서 예언자도 될 수 있어야 한다. 데이터 부서가 데이터 아키텍처에 있어 가장 먼저 결정할 요소는 개방형이냐 폐쇄형이냐다. 
 

개방형 vs. 폐쇄형 데이터 아키텍처 

우선 ‘데이터 아키텍처(Data Architecture)’라는 단어부터 살펴보자. 지난 50년 동안의 기업의 데이터 아키텍처 다이어그램을 그려본다면 이는 데이터 자체라기보다는 사실상 데이터에 작용하는 엔진인 데이터베이스이다. 대표적으로 오라클, DB2, SQL서버, 테라데이터(Teradata), 엑사데이터(Exadata), 스노우플레이크(Snowflake) 등이 있다. 이들은 모두 데이터베이스고, 업무나 분석에 필요한 데이터세트가 로드되는 곳이다. 그리고 ‘데이터 아키텍처’의 토대다.

기본적으로 이들 데이터베이스는 ‘폐쇄형 데이터 아키텍처(Closed Data Architecture)’다. 가치적 표현이 아니라 설명적 표현이다. 여기서 데이터는 다른 애플리케이션에서 격리되고 데이터베이스 엔진을 통해서만 액세스된다. 심지어 ETL(Extract, Transform, and Load) 작업을 하면서 데이터를 옮길 때도 마찬가지다. 내보내기나 가져오기를 할 때 일정 시점에서 반드시 데이터베이스를 거쳐야 하기 때문이다. 그게 최적의 방식인지 아닌지는 문제가 아니다. 데이터가 아키텍처의 나머지 부분에 대해 ‘닫혀’ 있다는 점이 중요하다. 

대조적으로, ‘개방형 데이터 아키텍처(Open Data Architecture)’는 데이터를 아키텍처 내의 데이터 전용 계층(Tier)에 저장한다. 따라서 조직의 다양한 분석 니즈를 위해 다양한 최고의 엔진을 이용할 수 있다. 애널리틱스 처리 니즈를 위한 만능의 수단이 있었던 적이 없었기 때문에 중요한 일이다. 앞으로도 만능의 수단은 없을 것이다. 개방형 아키텍처는 오늘날 또는 미래의 최고의 서비스를 이용하는 데 이상적이다.

정리하자면 폐쇄형 데이터 아키텍처는 데이터를 데이터베이스 엔진으로 가져오고, 개방형 데이터 아키텍처는 데이터베이스 엔진을 데이터로 가져온다.

개방형 아키텍처를 평가하는 간단한 방법은 미래에 새 엔진을 도입하기가 얼마나 어려울 것인지를 생각하는 것이다. 새 엔진을 기존의 엔진과 나란히 실행할 수 있을까(동일한 데이터 상에서), 아니라면 전면적인 (사실상 비현실적인) 마이그레이션이 불가피할까?
 
ⓒ Dremio

여기서 개방형(Open)이라는 뜻은 오픈소스(Open Source)와 아무런 관계가 없음을 유의하라. 첫 단계는 데이터를 개방형으로 만들어 데이터를 활용하려는 서비스에게 공개할 것인지를 판단하는 것이다. 그 다음에는 클라우드 세계에서의 개방형 데이터를 고려해야 한다.
 

개방형의 서비스 지향적인 데이터 아키텍처 

애플리케이션이 클라이언트-서버에서 웹으로 이동하면서 아키텍처가 근본적으로 변경되었다. 애플리케이션은 한 프로세스에서 실행되던 단일 애플리케이션으로부터 서비스 지향 애플리케이션으로 변화했고, 더 작고, 더 전문적인 소프트웨어 서비스로 분할되었다. 궁극적으로 이는 ‘마이크로서비스’라고 알려졌고, 웹 및 모바일 애플리케이션의 지배적 설계이다. 마이크로서비스 접근법은 클라우드 인프라의 본질로 인해 여러 장점이 있었다. 온디맨드 리소스 모델과 함께 작용하고 수많은 부서가 각종 기능성을 작업하는 스케일아웃 시스템에서, 애플리케이션은 수십, 수백 가지 마이크로서비스가 내재된 일종의 포장에 불과하다. 

이 접근법은 모듈형 및 조정형 애플리케이션을 제작할 때 장점이 많다. 이 패러다임이 데이터에 있어서는 그만큼 효과적이지 않다고 믿을 만한 이유가 있지만, 드레미오(Dremio)는 그렇게 생각하지 않는다. 애플리케이션과 동일한 개방형, 서비스 지향적 관점으로 데이터를 바라본다는 논리는 직관적으로 의심의 여지가 없고 적절하다. 실무적이고 전략적인 차원에서 개방형의 서비스 지향적 데이터 아키텍처는 당연히 타당하다.

이것이 바로 오픈소스 소프트웨어 문제가 부차적인 이유이다. 가장 중요한 것은 개방형 데이터 아키텍처가 폐쇄형 아키텍처보다 더 적절하다는 점이다. 일단 그렇게 되면 획기적인 이점이 생겨난다. 개방형 파일 및 표 포맷, 예를 들어 아파치 파켓(Apache Parquet), 아파치 아이스버그(Apache Iceberg) 등은 업계 전반에 걸쳐 혁신을 허용하기 때문에 결정적이다. 혁신은 독립 데이터 계층에 작용하는 서비스의 형태로 전달된다. 번잡하고 값비싸고 취약하고 컴플라이언스를 훼손하는 데이터 복제가 크게 줄어들거나 심지어 사라진다. 데이터 부서는 데이터와 작용할 최고의 서비스를 선택할 수 있고, 10년 넘게 애플리케이션 서비스에서 해온 것과 똑같이 아키텍처에 삽입하기만 하면 된다. 이제는 데이터 아키텍처에 속도를 더할 시간이다. 

개방형 데이터 아키텍처의 가치를 반박하는 정당한 주장이 없지는 않다. 너무 복잡하다는 것이다. 복잡성은 중대한 기술적 변화에 항상 수반된다. 중형 컴퓨터가 처음에는 기성의 메인프레임보다 관리하기가 더 까다로웠다. 인텔 기반의 서버는 처음에는 중형 시스템보다 관리하기가 더 까다로웠다. PC를 관리하는 일은 처음에는 기존의 지능이 없는 단말 장치를 관리하는 것보다 더 까다로웠다. 정리해보자. 기술 변화가 일어날 때마다 이는 일반적인 도입 곡선을 따라 주류로 편입된다. 관리 측면에서 초기 시절은 언제나 더 복잡하다. 그러나 시간이 가면서 새로운 툴과 접근법이 복잡성을 줄이고, 처음의 복잡성 비용을 훨씬 능가하는 혜택을 가져온다. 이것이 바로 혁신하는 이유이다.

개방형의 서비스 지향적 데이터 아키텍처를 훨씬 쉽고 훨씬 위력적으로 만들기 위해 제작된 클라우드 데이터 레이크 엔진의 한 예로 드레미오(Dremio)를 들 수 있다. SQL을 레이크하우스에서 실행하는 것은 간단하다. 모든 조각을 통합해놓았기 때문이다. 그리고 그 과정에서 획기적인 오픈소스 프로젝트, 예를 들어 네시(Nessie), 아파치 애로우(Apache Arrow), 애로우 플라이트(Arrow Flight) 등이 탄생했다. 이들은 오픈소스 프로젝트이고, 오픈소스 기술은 도입과 상호 운용성을 촉진한다. 조직의 데이터 아키텍처 내의 서비스 통합 계층에서 결정적인 역할을 한다. 업계 전체가 핵심 기술을 작업하고 혁신하기 때문에 고객은 한층 우수한 서비스를 받을 수 있다. 오픈소스 애호가는 이를 이해할 수 있도록, 심지어 개선할 수 있도록 코드에 접근한다. 그리고 이들 혁신은 레이크하우스 상에서 SQL을 빠르고 쉽게 만든다.

한 마디로 정리하자면, 업체가 아무리 ‘개방형’이라고 주장하더라도, 아무리 개방형 포맷과 개방형 표준을 지원한다고 말하더라도, 심지어 근본적으로 오픈소스 업체여도 데이터 아키텍처가 폐쇄형이면 폐쇄형이다. 

스노우플레이크는 최근 기사에서 비즈니스 요구사항을 충족하려면 데이터 포맷, 스토리지 소유권 등의 영역은 폐쇄형이어야 한다고 주장했다. 20년 전이라면 사실일 수 있다. 그러나 최근 클라우드 스토리지, 트랜잭션 테이블 포맷의 발전으로 인해 이제 개방형 아키텍처도 이런 요구사항을 충족할 수 있다. 개방형 아키텍처로 요구사항을 충족하면서 모든 혜택을 누릴 수 있다면 굳이 폐쇄형 아키텍처를 선택할 이유가 있을까? 이게 스노우플레이크가 많은 시간을 할애하면서 개방형이 중요하지 않다고 주장한 이유일지도 모른다. 
 

1등 시민으로서의 데이터 

개방형 아키텍처 옹호자의 목적은 데이터가 아키텍처 내의 1등 시민인 세계를 지향하면서 기업에 개방형 아키텍처의 혜택을 이해시키는 것이다. 개방형 아키텍처의 혜택이란 각종 작업에서 가장 적합한 최고의 엔진을 이용할 수 있는 유연성, 기업 데이터에 액세스해야 할 때 사기업 소유의 엔진에 종속되는 것을 방지, 미래 혁신 이점을 활용할 수 있도록 대비, 데이터의 끝없는 복제 및 이동에 따른 복잡성 제거를 말한다. 

개방형 아키텍처가 구현하고 사용하기가 쉬워질수록 폐쇄형 데이터 아키텍처보다 훨씬 큰 혜택을 가져올 것이다. 모멘텀이 강화되고 있고, 목적지는 개방형 데이터 아키텍처가 핵심이 되는 미래다. editor@itworld.co.kr


X