안녕하세요. 자바파커입니다.

먼저 영상으로 동기화 문제와 멀티모델 흐름을 확인한 뒤, 아래에서 스키마와 쿼리를 따라가도 좋습니다.

GraphRAG를 만들다 보면 데이터베이스가 하나씩 늘어납니다.

• 원문과 메타데이터는 Document DB
• 임베딩은 Vector DB
• 엔티티 관계는 Graph DB
• 키워드 검색은 Search Engine
• 원본 시스템은 RDBMS

각 도구는 자기 역할을 잘합니다. 문제는 같은 Chunk가 여러 시스템에 복사된다는 것입니다.

원문을 수정했는데 벡터 인덱스는 예전 내용이고, 엔티티를 지웠는데 그래프에는 간선이 남을 수 있습니다. 이를 막으려고 ETL, CDC, 메시지 큐와 재처리 파이프라인을 붙이면 검색 시스템보다 동기화 시스템이 더 복잡해집니다.

ArcadeDB가 제안하는 방향은 다릅니다.

데이터를 여러 DB에 복사하지 말고, 같은 데이터가 문서·그래프·벡터·전문 검색 모델에 동시에 참여하게 합니다.

ArcadeDB는 그래프를 중심으로 문서, Key-Value, 전문 검색, 벡터, 시계열을 한 엔진에서 다루는 오픈소스 멀티모델 DBMS입니다. 모든 모델이 같은 저장 계층, 트랜잭션 관리자와 쿼리 인프라를 공유합니다.

이번 글에서는 제품 기능 목록보다 다음 질문에 집중합니다.

1. 멀티모델 DB가 실제로 무엇을 줄여 주는가
2. 같은 Chunk를 벡터와 그래프로 어떻게 조회하는가
3. GraphRAG를 어떤 스키마와 쿼리로 시작하는가
4. ArcadeDB를 선택하면 안 되는 경우는 언제인가

ArcadeDB란?

ArcadeDB는 OrientDB에서 개념적으로 갈라져 나온 네이티브 멀티모델 데이터베이스입니다. 공식 문서가 설명하는 모델은 다음 여섯 가지입니다.

여기서 중요한 것은 “기능이 여섯 개다”가 아닙니다.

하나의 레코드, 여러 모델

GraphRAG의 Chunk를 예로 들어 보겠습니다.

Chunk
├─ content: 문서 본문                ← Document
├─ source, page, section: 메타데이터 ← Document
├─ embedding: [0.12, ...]            ← Vector
├─ tokens, weights                   ← Sparse Vector / Search
└─ MENTIONS → Entity                 ← Graph

Chunk는 문서 속성을 가진 그래프 정점입니다. 여기에 임베딩을 저장하고 벡터 인덱스를 만들 수 있습니다. 같은 정점에서 MENTIONS 간선을 따라 엔티티로 이동할 수도 있습니다.

즉, 벡터 DB의 레코드 ID와 그래프 DB의 노드 ID를 별도로 매핑할 필요가 없습니다.

하나의 트랜잭션

원문 Chunk를 만들고 엔티티 간선을 연결하고 임베딩을 인덱싱하는 작업이 같은 트랜잭션에 참여합니다.

여러 DB를 사용할 때는 이런 순서가 됩니다.

Document 저장 성공
→ Vector 저장 성공
→ Graph 저장 실패
→ 보상 처리 또는 재시도 필요

멀티모델 엔진에서는 한 트랜잭션으로 묶을 수 있으므로 중간 상태를 줄일 수 있습니다.

멀티모델의 핵심 가치는 쿼리 언어 개수가 아니라 모델 사이의 동기화 경계가 사라지는 것입니다.

Polyglot Persistence와 비교하기

여러 전문 데이터베이스를 조합하는 방식을 Polyglot Persistence라고 부릅니다. 잘못된 방식은 아닙니다. 각 워크로드에 가장 강한 제품을 선택할 수 있기 때문입니다.

따라서 ArcadeDB의 주장은 “전문 DB는 필요 없다”가 아닙니다.

데이터가 강하게 연결되어 있고 모델 사이 일관성이 중요한 경우, 여러 저장소로 나누는 비용이 전문화의 이점보다 큰지 다시 계산하자는 쪽에 가깝습니다.

Docker로 ArcadeDB 실행하기

공식 Docker 이미지를 사용하면 로컬에서 빠르게 확인할 수 있습니다.

docker run --rm \
  --name arcadedb \
  -p 2480:2480 \
  -p 2424:2424 \
  -e ARCADEDB_SETTINGS="-Darcadedb.server.rootPassword=change-this-password" \
  arcadedata/arcadedb:latest

브라우저에서 http://localhost:2480으로 접속하면 ArcadeDB Studio를 열 수 있습니다.

운영 환경에서는 latest 대신 검증한 버전을 고정하고 다음 항목을 먼저 확인하세요.

• 컨테이너 메모리 제한과 JVM 힙
• 데이터 볼륨 영속화
• 백업과 복구 절차
• 인증서와 외부 노출 포트
• HA·복제 토폴로지
• 업그레이드 전 벡터 인덱스 호환성

GraphRAG 스키마 만들기

아래 예시는 문서 Chunk와 Entity를 그래프로 연결합니다.

CREATE VERTEX TYPE Chunk;
CREATE PROPERTY Chunk.content STRING;
CREATE PROPERTY Chunk.source STRING;
CREATE PROPERTY Chunk.chunkIndex INTEGER;
CREATE PROPERTY Chunk.embedding LIST OF FLOAT;

CREATE VERTEX TYPE Entity;
CREATE PROPERTY Entity.name STRING;
CREATE PROPERTY Entity.kind STRING;

CREATE EDGE TYPE MENTIONS;
CREATE EDGE TYPE RELATES_TO;

벡터 인덱스를 추가합니다.

CREATE INDEX ON Chunk (embedding) LSM_VECTOR METADATA {
  dimensions: 1536,
  similarity: 'COSINE',
  quantization: 'INT8'
};

dimensions는 사용하는 임베딩 모델과 정확히 같아야 합니다. 모델을 바꿔 차원이 달라지면 같은 인덱스에 섞지 말고 버전이 다른 속성이나 타입으로 분리하는 편이 안전합니다.

벡터 검색하기

질문 임베딩과 가까운 Chunk 5개를 찾습니다.

SELECT content, source, distance FROM (
  SELECT expand(
    vector.neighbors('Chunk[embedding]', :queryVector, 5)
  )
);

vector.neighbors()는 근사 최근접 이웃을 반환하고 expand()가 결과 목록을 행으로 펼칩니다.

ArcadeDB의 LSM_VECTOR는 JVector 기반이며 Vamana 계열의 단일 계층 그래프와 계층형 HNSW 구성을 지원합니다. HNSW의 탐색 원리가 궁금하다면 HNSW란? 벡터 DB가 모든 벡터를 비교하지 않는 방법을 함께 보세요.

efSearch 조정

쿼리별로 검색 후보 폭을 조절할 수 있습니다.

SELECT expand(
  vector.neighbors(
    'Chunk[embedding]',
    :queryVector,
    10,
    { efSearch: 300 }
  )
);

efSearch가 커지면 더 많은 후보를 탐색해 recall이 좋아질 가능성이 커지지만 지연과 CPU 사용량도 늘어납니다. 기본값부터 시작해 실제 데이터로 Recall@K와 p95 지연을 함께 측정하세요.

그래프 관계로 컨텍스트 확장하기

벡터 검색은 문장이 비슷한 Chunk를 잘 찾습니다. 하지만 “이 회사의 공급망과 관련된 다른 사건”처럼 여러 관계를 건너야 하는 질문은 임베딩 거리만으로 부족할 수 있습니다.

먼저 Chunk가 언급한 Entity를 연결합니다.

CREATE EDGE MENTIONS
FROM (SELECT FROM Chunk WHERE source = 'report-2026.pdf' AND chunkIndex = 12)
TO   (SELECT FROM Entity WHERE name = 'Arcade Data');

관계를 따라 다른 Chunk까지 확장합니다.

MATCH (c:Chunk)-[:MENTIONS]->(e:Entity)
      -[:RELATES_TO*1..2]-(related:Entity)
      <-[:MENTIONS]-(other:Chunk)
WHERE c.source = 'report-2026.pdf'
RETURN related.name, other.content, other.source

이 구조에서는 다음 검색 흐름을 만들 수 있습니다.

질문
→ Vector Search: 의미가 가까운 시작 Chunk
→ Graph Traversal: 연결된 Entity와 다른 Chunk 확장
→ Full-Text / Sparse Search: 고유명사와 정확한 용어 보강
→ Rerank
→ LLM Context

문서의 구조와 출처를 보존하는 방법은 비정형 문서를 하이브리드 Markdown으로 디지털화하기에서 다뤘습니다. 정형 데이터의 업무 의미를 붙이는 과정은 Semantic Layer·TAG·SAG 실전 설계와 연결됩니다.

Dense와 Sparse 검색 합치기

의미는 비슷하지만 행동이 반대인 문장이 있습니다.

• 도난 후 카드를 정지하는 방법
• 여행 후 카드를 정지 해제하는 방법

Dense embedding은 두 문장을 가깝게 볼 수 있습니다. Sparse 검색은 정지와 해제처럼 판별력이 큰 토큰을 유지하는 데 유리합니다.

ArcadeDB 공식 GraphRAG 예제는 dense 결과와 sparse 결과를 RRF로 합치는 쿼리를 제공합니다.

SELECT expand(
  vector.fuse(
    vector.neighbors('Chunk[embedding]', :denseQuery, 50),
    vector.sparseNeighbors(
      'Chunk[tokens,weights]', :queryIndices, :queryValues, 50
    ),
    { fusion: 'RRF', groupBy: 'source', groupSize: 1 }
  )
) LIMIT 10;

groupBy: 'source'는 같은 문서의 비슷한 Chunk가 컨텍스트를 독점하는 현상을 줄입니다.

어떤 쿼리 언어를 써야 할까?

ArcadeDB는 SQL, Cypher, Gremlin, GraphQL과 여러 호환 프로토콜을 제공합니다. 그렇다고 한 프로젝트에서 전부 사용할 필요는 없습니다.

팀의 기본 언어 하나를 정하고, 표현력이 부족한 일부 쿼리에만 다른 언어를 쓰는 편이 유지보수하기 쉽습니다.

특히 MongoDB·Redis 호환 프로토콜은 모든 명령을 완전히 대체한다고 가정하지 말고 애플리케이션이 사용하는 명령 집합을 먼저 테스트하세요.

ArcadeDB가 잘 맞는 경우

1. GraphRAG

Chunk, Entity, embedding과 출처를 함께 갱신하고 벡터 검색 뒤에 다단계 관계 탐색이 필요할 때 잘 맞습니다.

2. 추천 시스템

사용자·상품·행동 관계와 상품 임베딩, 시간에 따른 이벤트를 함께 다룰 수 있습니다.

3. 사기 탐지

계정·기기·결제 관계를 그래프로 탐색하면서 벡터나 시계열 특징을 같은 레코드에 연결할 수 있습니다.

4. AI 메모리와 지식 그래프

대화, 사실, 엔티티, 관계, 임베딩을 하나의 생명주기로 관리하려는 경우입니다.

ArcadeDB를 선택하지 말아야 하는 경우

1. 단순 CRUD 서비스

관계 탐색이나 벡터 검색이 없고 일반적인 트랜잭션 CRUD가 대부분이면 익숙한 RDBMS가 더 단순합니다.

2. 모델별 독립 확장이 중요할 때

벡터 검색과 시계열 수집의 트래픽 패턴이 완전히 다르고 각각 독립적으로 확장해야 한다면 전문 시스템 분리가 유리할 수 있습니다.

3. 특정 전문 기능이 절대 조건일 때

특정 검색 엔진 플러그인, 관리형 벡터 DB의 SLA, 그래프 분석 생태계가 필수라면 멀티모델의 운영 단순화보다 전문 제품의 깊이가 중요합니다.

4. 운영 경험이 없는 상태에서 핵심 시스템을 바로 이전할 때

새 데이터베이스 도입은 쿼리 데모보다 복구 훈련, 장애 대응, 업그레이드와 모니터링 검증이 더 중요합니다. 작은 읽기 전용 워크로드부터 시작하세요.

도입 전 검증 체크리스트

데이터 모델

• Chunk와 Entity의 삭제 수명주기가 명확한가
• 간선에 출처와 추출 버전을 저장하는가
• embedding 모델과 차원을 버전 관리하는가
• 원문 좌표와 provenance를 보존하는가

검색 품질

• Exact Search 기준 Recall@K를 측정했는가
• dense·sparse·graph 각각의 기여도를 분리했는가
• 같은 문서의 중복 Chunk를 제한했는가
• 필터 조건별 후보 부족을 테스트했는가

운영

• 백업에서 실제 복구해 보았는가
• 벡터 인덱스 재구축 시간과 디스크 여유를 측정했는가
• 대량 쓰기 중 검색 지연을 확인했는가
• 버전과 Docker 이미지 태그를 고정했는가
• 호환 프로토콜에서 사용하는 명령을 회귀 테스트했는가

자주 묻는 질문

ArcadeDB가 임베딩도 생성하나요?

일반적으로 임베딩은 외부 모델이나 임베딩 서비스에서 생성하고 ArcadeDB에는 결과 벡터를 저장합니다. 데이터베이스의 역할은 벡터를 인덱싱하고 다른 모델과 함께 조회하는 것입니다.

Neo4j와 같은 그래프 DB인가요?

그래프가 핵심 모델인 것은 맞지만 문서, 벡터, 전문 검색, Key-Value와 시계열도 같은 엔진에서 다루는 멀티모델 DB입니다. 제품 비교는 기능표보다 실제 쿼리, 운영 요구와 팀 경험으로 판단해야 합니다.

HNSW를 사용하나요?

LSM_VECTOR 인덱스는 JVector를 기반으로 하며 계층형 HNSW와 단일 계층 Vamana 구성을 지원합니다. 데이터 크기와 차원, 업데이트 패턴에 맞춰 선택해야 합니다.

한 DB에 다 넣으면 단일 장애점이 되지 않나요?

운영 단위가 줄어드는 대신 엔진 하나의 영향 범위가 커집니다. HA와 복제, 백업·복구 검증 없이 “DB 수가 줄었다”는 이유만으로 핵심 시스템을 합치면 안 됩니다.

기존 DB를 모두 ArcadeDB로 바꿔야 하나요?

아닙니다. 먼저 동기화 비용이 가장 큰 경계 하나를 고르세요. 예를 들어 GraphRAG의 Chunk·Entity·embedding만 ArcadeDB에서 관리하고 원본 업무 시스템은 기존 RDBMS에 둘 수 있습니다.

정리

ArcadeDB의 핵심은 데이터베이스 기능을 여섯 개 모았다는 데 있지 않습니다.

같은 데이터가 문서·그래프·벡터·검색 모델에 동시에 참여하고, 모델 사이 갱신을 한 트랜잭션으로 다룰 수 있다는 점이 핵심입니다.

GraphRAG처럼 Chunk, Entity, embedding과 키워드가 강하게 연결된 시스템에서는 이 구조가 ETL과 ID 매핑, 동기화 실패를 크게 줄일 수 있습니다.

반대로 모델마다 독립적인 확장과 깊은 전문 기능이 중요하다면 여러 전문 DB를 유지하는 편이 나을 수 있습니다.

도입 여부는 “몇 개 모델을 지원하는가”가 아니라 다음 질문으로 판단하세요.

우리 시스템의 복잡성은 쿼리에서 오는가, 아니면 같은 데이터를 여러 DB에 맞추는 과정에서 오는가?

후자라면 ArcadeDB를 검토할 이유가 충분합니다.

공식 자료

• ArcadeDB Multi-Model Architecture
• ArcadeDB Vector Search
• ArcadeDB GraphRAG Use Case
• ArcadeDB Vector Search Tutorial
• ArcadeDB GitHub Repository