NodeDB가 Multi-Model을 다르게 처리하는 방법

발행: 1일 전 (2026년 4월 5일 AM 09:09 GMT+9)

16 분 소요

원문: Dev.to

Source: Dev.to

위에 제공된 링크만으로는 번역할 실제 텍스트가 포함되어 있지 않습니다. 번역을 원하시는 본문을 복사해서 여기 채팅창에 붙여 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.

Introduction

이전 기사에서 NodeDB가 현재 멀티‑모델 환경에서 어떤 위치에 있는지 설명했습니다.

이번 글에서는 다음 질문을 다룹니다: 실제로 어떻게 작동하나요?

짧은 답변: 하나의 엔진으로 모든 것을 처리할 수는 없습니다.

NodeDB는 문제를 핵심 엔진 패밀리로 나눈 뒤, 적절한 기반 위에 특화된 모델을 구축합니다—모든 것을 단일 데이터베이스 경계 안에 유지하면서 말이죠.

핵심 아이디어

일부 모델은 자체 실제 엔진을 가집니다.
일부 모델은 다른 강력한 네이티브 엔진 위에서 성장합니다.
플래너가 그 차이를 인식합니다.
사용자는 워크로드가 확대된다고 해서 스택을 여러 데이터베이스로 나눌 필요가 없습니다.

Source: …

핵심부터 시작하고, 라벨부터는 시작하지 마세요

사람들이 “멀티‑모델 데이터베이스” 라고 말할 때, 그 문구는 보통 몇 가지 지름길을 숨기고 있습니다. 이는 다음을 의미할 수 있습니다:

확장이 가능한 하나의 강력한 데이터베이스.
더 넓은 마케팅 표면을 가진 하나의 문서 시스템.
하나의 제품 이름 아래에 모여 있는 여러 서비스.
너무 많은 모델에 걸쳐 늘어난 하나의 일반화된 저장 형태.

그것은 내가 원한 경로가 아닙니다.

NodeDB의 시작 질문은 더 간단하면서도 동시에 더 어려웠습니다:

이 데이터베이스가 새로운 요구 사항마다 추가적인 스티칭 없이 다양한 워크로드를 처리하려면 실제로 어떤 엔진 패밀리가 필요할까?

현재 엔진 패밀리

Document
Strict
Graph
Vector
Columnar
Key‑Value
Full‑Text Search

또한 이미 적절한 기반을 가지고 있다면 별도의 엔진 패밀리를 완전히 분리할 필요가 없는 네이티브 모델도 있습니다:

Time‑Series (Columnar 위)
Spatial (Columnar 위)

이러한 구분이 중요한 이유는 두 가지 나쁜 극단을 피할 수 있기 때문입니다:

모든 모델을 내부적으로 동일하게 가장하는 것.
각 기능마다 별도의 미니‑데이터베이스를 만드는 것.

핵심 엔진 패밀리

구체적인 부분은 이 엔진들이 실제로 무엇인지 입니다.

Document – 유연한 레코드 엔진. NodeDB에서는 스키마가 없는 레코드, MessagePack 저장소, 그리고 로컬‑우선 사용 사례를 위한 CRDT‑지향 동기화 경로를 의미합니다.
Strict – 구조화된 레코드 엔진. 행‑지향 접근에 가깝고, 다른 저장 형태를 사용하며, 문서 위에 스키마 검증만 하는 것이 아니라 예측 가능한 필드와 더 빠른 직접 접근을 필요로 하는 워크로드를 위해 설계되었습니다.
Graph – “문서에 링크를 추가한 것”이 아닙니다. 자체적인 인접 구조, 탐색 경로, 그리고 그래프‑네이티브 연산을 가지고 있습니다.
Vector – “임베딩을 어디에든 추가하는 것”이 아닙니다. 자체적인 ANN 경로, 양자화 파이프라인, 거리 계산 방식을 갖추고 있습니다.
Columnar – 분석용 기반: 압축, 스캔‑중심 읽기, 프레디케이트 푸시‑다운, 그리고 워크로드가 OLTP보다 분석에 가깝게 될 때 원하는 레이아웃을 제공합니다.
Key‑Value – 더 무거운 모델을 거치지 않고도 간단하고 저렴하게 직접 조회할 수 있는 워크로드를 위해 존재합니다.
Full‑Text Search – 자체적인 랭킹 및 토크나이징 동작(BM25, 형태소 분석, 불용어 처리, 퍼지 매칭, 하이브리드 검색)을 가지고 있습니다. 이러한 기능은 일반 필터링으로 흉내 내서는 안 됩니다.

이것들은 많은 멀티‑모델 제품이 흐릿하게 다루는 부분입니다. 이름은 쉽지만, 실제 엔진 선택이 어려운 부분입니다.

왜 Strict가 이렇게 중요한가

Strict는 특히 다중‑모델 시스템이 모호해지는 부분이기 때문에 중요합니다. 외부에서 보면 Strict는 “문서와 스키마 규칙”처럼 보일 수 있습니다. 그러나 그것만으로는 충분하지 않습니다.

NodeDB에서 Strict가 존재하는 이유는 구조화된 워크로드가 별도의 경로를 필요로 하기 때문입니다:

고정된 필드 기대치.
다른 저장 동작.
다른 접근 패턴.
다른 플래너 가정.
다른 성능 목표.

현재 저장소 방향에서는 Strict를 행‑형식 저장 모드로 취급하며, 직접 필드 접근을 지원합니다—단순히 잘못된 쓰기를 거부하는 문서 컬렉션이 아닙니다.

이 구분이 중요한 이유는, 다중‑모델 데이터베이스가 구조화된 데이터에 자체적인 실질적인 경로를 제공하지 못한다면, “다중‑모델”이라는 이야기가 이미 많은 실제 애플리케이션에 대해 약해지기 때문입니다.

Specialized models should grow from the right foundation

This is where Time‑Series and Spatial fit.

I do not think every model deserves its own isolated engine family just for the sake of appearances. Sometimes the right design is to start from a strong native base and specialize from there. In NodeDB that base is Columnar.

Time‑Series (on Columnar)

Columnar layout fits scan‑heavy reads.
Compression matters.
Aggregation matters.
Retention and roll‑ups matter more than point‑update behavior.

The current repo reflects this: Time‑Series is described as a columnar profile with ILP ingest, continuous aggregation, PromQL support, and time‑oriented SQL functions.

Spatial (on Columnar)

Belongs near Columnar because analytical and geospatial workloads often overlap.
Adds native behavior: spatial indexes, geohash/H3‑style locality tools, and geometry predicates.

Pattern:

Separate engine families where the workload is genuinely different.
Specialized native profiles where another engine already provides the right foundation.

NodeDB가 일관성을 유지하는 방법

여러 엔진을 하나의 브랜드 아래에 모은다고 해서 멀티‑모델 문제가 해결되는 것은 아닙니다; 단지 상자들을 더 가깝게 옮길 뿐입니다. 더 어려운 문제는 일관성입니다:

혼합 워크로드가 어떻게 하나의 시스템에 머물 수 있을까?
플래너는 각 모델에 대해 올바른 경로를 어떻게 선택할까?
인터페이스를 동일하게 보이게 만들기 위해 모든 모델을 약화시키는 일을 어떻게 피할까?

NodeDB에 대한 답은 모든 것에 대해 단일 일반 쿼리 경로를 제공하는 것이 아니라—그렇게 하면 모델이 평탄해집니다.

대신, 우리는 모델 의미가 크게 달라지는 경우에 전용 쿼리 및 플래너 처리를 사용하면서도 여전히 하나의 데이터베이스 경계 안에 유지합니다.

Strict는 스키마가 없는 문서와는 달리 더 강한 가정을 가지고 계획됩니다.
Vector, Graph, Full‑Text Search 및 기타 특수화된 모델은 각각 자체 최적화된 플래닝 경로를 받습니다.

각 엔진 패밀리에게 적절한 처리를 제공함으로써 NodeDB는 단일하고 일관된 데이터베이스 시스템의 단순성을 희생하지 않으면서 성능과 기능 풍부함을 유지합니다.

멀티‑모델 데이터베이스에서의 일관성

우리가 일관성에 대해 이야기할 때는 “하나의 쿼리 언어” 혹은 “하나의 제품”을 넘어서는 의미를 담고 있습니다.
이는 다음을 의미합니다:

하나의 데이터베이스 경계 – 사용자가 상호작용하는 단일 논리 시스템.
공유 시스템‑레벨 조정 – 공통 메타데이터, 보안 및 트랜잭션 처리.
필요에 따라 모델‑특화 실행 경로 – 각 모델(그래프, 벡터, 시계열 등)이 자체 최적화 엔진을 가짐.
다양한 모델이 혼합된 워크로드에서 교차 시스템 홉을 최소화.

왜 이것이 “가짜” 멀티‑모델과 다른가

내가 가장 중요하게 생각하는 구분은 “가짜” 멀티‑모델 솔루션이 보통 두 가지 방식 중 하나로 실패한다는 점이다:

모든 것이 하나의 일반적인 코어를 통해 전달된다 – 모델은 존재하지만 약하게 느껴진다.
모든 진지한 모델이 또 다른 확장, 서비스, 혹은 외부 데이터베이스가 된다 – 모델은 강력하게 유지되지만, 사용자는 통합 비용을 감당해야 한다.

NodeDB는 이 두 실패 사이에 머무르는 것을 목표로 한다. 그래서 설계가 현재와 같이 나뉘었다:

실제 엔진 패밀리 – 워크로드에 실제 특화가 필요할 때.
네이티브 프로파일 – 이미 강력한 기반이 존재할 때.
플래너‑레벨 존중 – 모델 간 차이를 고려한다.
하나의 데이터베이스 경계 – 혼합 워크로드를 위해.

실제 의미

NodeDB가 내가 원하는 대로 작동한다면, 실제 결과는 몇 가지 구체적인 측면에서 차이가 날 것입니다:

그래프 쿼리는 엣지를 단순히 또 다른 문서 필드로 가장하는 대신, 그래프‑네이티브 구조와 알고리즘을 따릅니다.
벡터 검색은 얇은 부가 기능이 아니라 자체 인덱싱 및 양자화 옵션을 갖춘 실제 ANN(근사 최근접 이웃) 경로를 사용합니다.
엄격한 컬렉션은 더 강력한 플래너 가정과 빠른 직접 필드 접근을 제공하는 진지한 구조화 모델처럼 동작합니다.
시계열은 부적합한 엔진 위에 시뮬레이션되는 것이 아니라 컬럼형 실행의 장점을 물려받습니다.
공간은 사용자를 다른 데이터베이스로 강제 이동시키지 않고 네이티브 공간 동작을 제공합니다.
레코드, 벡터, 검색, 그래프를 혼합하는 워크로드가 원격 호출 체인으로 변하지 않고 하나의 시스템 안에 머무릅니다.

이러한 테스트는 제품이 단순히 많은 모델 이름을 나열할 수 있는지 여부를 묻는 것보다 더 의미가 있습니다.

위험

fewer engines으로 시작하는 것이 더 쉽다.
flatten more behavior를 하나의 일반 레이어에 통합하는 것이 더 쉽다.
delay the planner work를 미루는 것이 더 쉽다.
more models를 later add‑ons로 전환하는 것이 더 쉽다.

위험은 실제 워크로드가 설계의 모든 구석을 밀어붙일 때 NodeDB가 이 깊이와 일관성을 유지할 수 있는가이다.

Why I Still Prefer This Route

Even with that risk, I still think this is the more honest way to build a true multi‑model database.

The point is not only to support many models.
The point is to support them with the right engine shape, the right planner behavior, and the right database boundary.

If that holds up, then NodeDB becomes interesting for a real reason, not just because it can claim a long feature list.

If you want to follow how NodeDB works at the engine level—where this design holds up and where it still needs to prove itself—follow the NodeDB blog. I will keep sharing the architecture, trade‑offs, and deeper implementation decisions as the database evolves.