소개
시각화 솔루션인 D3.js를 모르는 개발자는 없을 겁니다.
지금은 너무도 다양하고 편리한 차트 라이브러리가 존재하고 React, Vue와 같은 FE framework에 따라 라이브러리를 나누기도합니다.
그중에서도 2011년도에 Mike Bostock이라는 개발자가 만든 d3는 지금까지도 많은 개발자들 혹은 시각화 작업이 필요한 전문가들에게 꾸준히 사랑을 받고 있습니다.
Mike Bostock은 ObservablHQ라는 Notebook 서비스를 만들었습니다.
rxjs의 Observable다른 이야기 입니다. ^^;
잘 알려진 Jupyter Notebook과 비교했을때 Observable은 어떤 차별화한 기능을 가지고 있을까요?
어떠한 작업을 할 때 Observable Notebook을 선택해야 할까요?
마지막으로 우리들의 시간을 쪼개어 사용법을 익히기에 가치가 있는 솔루션인지 등을 고민해 봅니다.
Jupyter과 ObservableHQ와의 차이
Jupyter는 Python 기반의 데이터 분석을 할 때 주로 사용하는 오픈 소스 Notebook 입니다.
Jupyter에 영향을 받아 만든 Google Colab은 브라우저 상에서 Notebook 환경을 경험할 수 있습니다.
ObservableHQ는 Jupyter 처럼 단독으로 실행할 수 있는 오픈소스 구현체 없이 Google Colab과 같은 서비스를 시작했습니다.
이 부분이 가장 큰 차이이자 약점이였는데요.
데이터에 민감한 기업 사용자들이 ObservableHQ 환경에서 분석하기란 어려운 선택이였습니다.
하지만, ObservableHQ는 Observable Framework라는 오픈소스를 2024년도 즈음에 발표 합니다.
기존의 Notebook은 Python, NodeJS와 같은 language runtime의 REPL 기능을 활용해 프로그램 조각을 실행하여 결과를 표시하는 방식이였습니다.
하지만 Observable은 태생 부터 JavaScript 환경만을 지원하고 있었기 때문에 runtime 관리를 위한 서버사이드 아키텍쳐나 프로토콜이 필요하지 않았습니다.
따라서 npx @observablehq/framework@latest create 명령 한줄로 노트북 환경을 만들어 내고 static site generation을 통해 배포할 수 있는 매우 단순하고 이식성 높은 개발 환경을 제공할 수 있었습니다.
이러한 방식으로 공개할 수 없는 데이터가 있는 기업환경에서도 실행하고 배포할 수 있습니다.
Observable은 이름에서도 알 수 있듯 reactive programming 방식을 지원하여 순차적으로 수행하는 기존의 notebook 솔루션들과 달리 global 변수의 변경만으로 의존관계의 변수나 다이어그램을 업데이트 할 수 있습니다.
또한 d3 라이브러리와 함께 다음과 같은 라이브러리를 기본 내장하고 있습니다.
- Observable Plot: 시각화 라이브러리
- observablehq/inputs: Interactive 라이브러리
Observable 1.0에서 Observable 2.0로
앞서 설명드린 Observable Framework는 Observable 2.0이라고 불리며 오픈 소스로 이식성 높은 환경을 제공하는 데요.
SaaS로 제공하는 ObservableHQ를 편의상 Observable 1.0이라고 명명하도록 하겠습니다.
Observable 2.0은 Observable 1.0의 개발 경험을 최대한 동일하게 가져가고 있습니다.
Plot, Inputs, htl 등 주요 라이브러를 별도의 임포트 없이 활용할 수 있죠.
하지만 코드 재사용성에 관해서는 각각 다를 수 밖에 없습니다.
Observable 1.0의 경우 코드 재사용은 다른 notebook의 특정 cell을 가져오는 방식으로 가능합니다.
다시말해 다른 사용자가 만든 함수를 해당 노트북을 참조함으로 사용가능하기 합니다.
이 방식은 다소 호불호가 갈릴 수 있습니다.
공개된 데이터와 public 공유를 목적으로 한 컨텐트일 경우는 문제가 되지 않습니다.
하지만 기업 환경에서 데이터의 유출 이라던지, 특정 비지니스 로직을 담고 있는 라이브러리를 공유한다던지 하는 유연성을 기대하기는 어렵습니다.
Observable 2.0의 경우는 어떨까요?
npm이라는 이미 익숙한 개발환경, markdown 기반의 노트북 작성, es module 기반의 라이브러리 임포트, TypeScript 호환 등은 Observable 1.0에서 아쉬웠던 점을 단번에 해결해 주고 있습니다.
또한 통상적인 개발 practice의 적용, 예를들자면, vscode와 같은 개발자 치화적인 IDE의 사용, git 기반의 버전 관리, eslint와 같은 코딩 스타일 강제와 같은 옵션들이 가능해 집니다.
Jupyter에 비해 아쉬운 점은 무엇일까요?
Jupyter의 특성상 Python runtime을 그대로 실행하는 것이기 때문에 Python 환경이 제공하는 여러 개발 인프라를 가져올 수 없다는 점이 그대로 아쉬운 점으로 생각할 수 있습니다.
다시 말해 대규모 분산 데이터 처리, ML 및 과학적 연산 라이브러리 및 환경을 기대하기는 어렵습니다.
어느때 사용해야 하나?
Observable 2.0에서 Python에서 수행가능한 대규모 데이터, ML 등을 처리하기에는 한계가 있습니다.
따라서, 시각화가 필요한 데이터 정제와 이의 산출은 Jupyter 혹은 Airflow와 같은 솔루션을 사용할 수 있습니다.
Observable 2.0은 오히려 여러 시각화 툴, 예를들면 Apche Superset, Tableau 등과 비교의 대상이 되리라 생각합니다.
지금까지의 시각화 툴은 일반사용자 경험에 포커스가 되어 있다면, Observable 2.0은 개발자 친화적인 환경을 제공합니다.
따라서, 소규모에서 대규모까지의 유연하고 확장성 가능한 시각화, 리포팅 환경을 구축하려 한다면, Observable 2.0이 그 솔루션이 될 수 있습니다.
Observable 1.0의 특성상 공개된 데이터를 기반한 시각화 및 리포트를 일반 사용자들과 공유하기에 좋습니다.
마치며
Observable 1.0을 알게 된지는 오래 되었습니다.
d3 라이브러리를 익히기위해 검색하다 보면 마주하게 되는 interactive notebook 솔루션은 신기하기도 했고 서비스로서 성장할 수 있을까라는 의문도 들었습니다.
특별히 reactive한 동작과 타사용자의 코드를 쉽게 가져다 쓸 수 있는 기능은 매우 신선하고 영감을 주는 기능입니다.
그럼에도 불구하고 JavaScript 기반의 데이터 분석 툴로서의 환경은 오히려 Data-Forge Notebook: Exploratory coding and visualization for JS/TS에 기대를 하고 있었습니다.
확장가능한 솔루션을 만듦에 있어서 TypeScript의 지원은 Python 기반의 데이터 분석 환경과 차별점을 둘 수 있다고 생각했기 때문입니다.
하지만, NodeJS 런타임 생태계가 deno, bun 등으로 확장하고 있는 요즈음에도 대규모 분산 처리를 위한 목표를 가진 시도는 보이질 않고 있습니다.
그런 와중에 Observable 2.0는 SSG 방식으로 개발자 친화적이고 TypeScript 및 이미 익숙한 개발 프랙티스를 적용할 수 있는 솔루션으로 다가왔습니다.
비록 대규모 데이터는 아닐지라도, 로컬 환경에서 동작가능한 크기의 데이터나 intermediate 데이터를 탐색하고 시각화하는데 있어서는 지금까지 다른 솔루션들이 제시했던 방식과는 차별점을 보여 주고 있습니다.
무언가 더 좋은 BI툴을 기다리진 않았습니다. 다른 방식의 BI 툴이 필요했고 이제 Observable 2.0에 기대를 걸어 봅니다.