Neo4j 캘버 시대 중간 점검 — 블록 포맷, Cypher 25, 그리고 GQL이 엔진에 착지하는 방식

들어가며 — RAG 말고, 엔진 이야기
릴리스 모델 — 매달 나오고, 다음 달이면 지원이 끝난다
스토리지 — 블록 포맷이 기본이 된 뒤, record는 조용히 저문다
언어 — Cypher에 버전을 붙이다
GQL — 표준 문서에서 체인지로그로 착지하는 방식
실행 엔진 — 병렬 런타임, 그리고 교착을 예방하는 스케줄러
수평 확장 — Infinigraph 프로퍼티 샤딩, 단 별도 구독
어느 트랙에 설 것인가 — 판단 기준
마치며
참고 자료

들어가며 — RAG 말고, 엔진 이야기

이 블로그에서 그래프는 최근 주로 RAG의 재료로 다뤘습니다 — Graph RAG란 무엇인가와 Graph RAG를 굴리는 도구들이 그 줄기입니다. 오늘은 한 층 아래로 내려갑니다. 그래프를 실제로 저장하고 질의를 실행하는 데이터베이스 엔진 층에서, 지난 1년 반 사이에 꽤 큰 일들이 조용히 진행됐기 때문입니다.

무대는 대부분 Neo4j입니다. 좋아하든 아니든 서버형 프로퍼티 그래프의 기본값이고(2026년 그래프 DB 지형 정리 참고), 무엇보다 지금 이 엔진에서 세 가지 전환이 동시에 일어나고 있습니다. 릴리스 모델이 바뀌었고(캘린더 버저닝), 스토리지 기본값이 바뀌었고(블록 포맷), 언어가 버전을 갖게 됐습니다(Cypher 5 vs Cypher 25 — 그리고 그 뒤의 ISO GQL 표준). 셋 다 "업그레이드 버튼을 누르면 끝"이 아니라 운영 판단이 필요한 변화입니다.

모든 버전·날짜·정책은 Neo4j 공식 체인지로그와 문서, 지원 정책 페이지, endoflife.date에서 직접 확인했고, 출처를 본문에 걸었습니다.

릴리스 모델 — 매달 나오고, 다음 달이면 지원이 끝난다

Neo4j는 5.26을 마지막으로 시맨틱 버저닝을 접고 캘린더 버저닝으로 전환했습니다. endoflife.date의 Neo4j 이력 기준으로 첫 캘버 릴리스 2025.01이 2025년 2월 초에 나왔고, 이후 2026.06(2026년 7월 8일 GA)까지 약 17개월 동안 피처 릴리스가 18개 쌓였습니다. 대략 매달 하나입니다.

중요한 건 속도가 아니라 지원 정책입니다. Neo4j 공식 지원 버전 문서는 각 릴리스의 핫픽스 제공 기간을 "일반적으로 다음 마이너 릴리스가 나올 때까지"라고 명시합니다. 실제 표가 그렇습니다 — 2026.05의 핫픽스는 2026.06이 나오는 순간 끝. 즉 캘버 릴리스 하나의 실질 수명은 4~6주입니다.

트랙	버전	상태 (2026-07-17 기준)
LTS	4.4	2025-11-30 EOL
LTS	5.26 (2024-12-06)	핫픽스 2028-06-06까지, 최신 패치 5.26.28 (2026-06-30)
캘버 트레인	2025.01 ~ 2026.06	최신 릴리스만 지원, 이전 버전은 즉시 지원 종료

그리고 이 글을 쓰는 시점까지 캘버 라인에는 LTS가 하나도 없습니다. 지원 버전 문서와 endoflife.date 어디에도 2025.x나 2026.x에 LTS 표기가 없습니다. 그 결과 자가 운영(self-managed) 환경의 선택지는 딱 둘입니다.

5.26 LTS에 머문다 — 2028년 6월까지 핫픽스를 받는다. 대신 이후에 나온 모든 것(Cypher 25, VECTOR 타입, 새 GQL 문법, ABAC 등)을 못 쓴다.
트레인에 올라탄다 — 새 기능과 버그 픽스를 매달 받는다. 대신 매달 업그레이드하지 않으면 지원 없는 버전을 굴리게 된다.

"1년에 한 번 메이저 업그레이드" 관행을 가진 조직에게는 셋째 선택지가 없다는 게 이 모델의 핵심이자, 가장 논쟁적인 부분입니다.

올라타는 비용도 구체적으로 적어 둡니다. 5.26 → 2025.x 업그레이드 가이드에 따르면 2025.01부터 Java 21이 필수(Java 17 지원 종료, Java 25는 2025.10부터 지원)이고, 클러스터 디스커버리 서비스 v1이 제거되어 v2 전환을 업그레이드 전에 마쳐야 하며, Kafka·Spark 커넥터와 GraphQL 라이브러리도 호환 패치 버전 이상으로 올려야 합니다.

스토리지 — 블록 포맷이 기본이 된 뒤, record는 조용히 저문다

캘버 전환의 발밑에는 스토리지 포맷 세대교체가 있습니다. 공식 스토어 포맷 문서 기준으로 현재 상태는 이렇습니다.

block — Enterprise Edition 권장 포맷이자, 별도 설정이 없으면 기본값. 프로퍼티를 노드·관계와 같은 블록에 인라인 저장해 포인터 추적을 줄이고, 페이지 몇 장으로 쿼리를 서빙하는 데이터 지역성이 설계 목표입니다. 고밀도 노드는 다중 루트 세대형 B+ 트리 기반의 dense store로 넘칩니다.
aligned — Community Edition의 기본 포맷. 블록 포맷은 CE에 없습니다.
standard, high_limit — 5.23에서 폐기 예고(deprecated). 신규 데이터베이스에 쓰지 말라고 명시되어 있습니다.

업그레이드 가이드는 5.26 LTS 사용자에게 2025.x로 올라가기 전에 블록 포맷 마이그레이션을 먼저 끝내라고 강하게 권합니다. 마이그레이션에는 제약이 하나 있는데, 블록 포맷의 토큰 이름(레이블·프로퍼티 키·관계 타입)은 GQL 식별자 최대 길이인 16,383자까지만 허용됩니다 — 스토리지 포맷 스펙에 ISO 표준의 흔적이 박혀 있는 첫 지점입니다.

방향은 체인지로그에서 더 선명합니다. 2025.10 체인지로그는 VECTOR를 "Cypher, 블록 스토어 포맷, v6 드라이버가 지원하는 새 타입"으로 소개합니다 — 새 타입 시스템이 블록 포맷을 전제로 자랍니다. 반대편에서 legacy record 포맷은 2026년 들어 교정 항목으로만 등장합니다. 2026 체인지로그에서 2026.04는 "record 포맷에서 노드가 동시에 dense로 전환될 때 관계 순회가 잘못된 결과를 반환할 수 있는 버그"를, 2026.06은 "record 포맷에서 여러 관계 타입의 무방향 스캔이 형제 관계를 누락해 출력이 약 50% 적게 세어지는 버그"를 고쳤습니다. 잘못된 결과를 반환하는 수준의 버그가 이제야 발견된다는 건, 테스트와 투자의 무게중심이 어디로 옮겨갔는지를 말해 줍니다. record 포맷 위에 아직 앉아 있다면, 이 두 항목이 마이그레이션 품의서의 근거 문단이 되어 줄 겁니다.

언어 — Cypher에 버전을 붙이다

2025.06(2025년 7월 GA)은 이 시대에서 가장 개념적인 변화를 담았습니다. 쿼리 언어 자체에 버전이 생겼습니다. Cypher 버전 선택 문서가 규칙을 정확히 적어 놨습니다.

Cypher 5는 동결됐습니다. CYPHER 5로 실행하면 "2025.06 릴리스 시점에 존재하던 Cypher 5"로 동작하고, 이후의 언어 변경은 그 쿼리에 영향을 주지 않습니다.
Cypher 25는 굴러갑니다. CYPHER 25로 실행하면 지금 돌고 있는 Neo4j 버전의 Cypher 25로 동작합니다. 즉 Cypher 25는 매달 릴리스와 함께 자라는 언어입니다.

CYPHER 25
MATCH (n:Order)-[r:SHIPPED_TO]->(:Address)
SET n = properties(r)

버전은 쿼리 접두사 말고도 데이터베이스 단위 기본값(db.query.default_language)으로 정할 수 있고, 프로시저·함수(APOC 포함)도 언어 버전에 묶입니다 — 같은 APOC 배포판에서 Cypher 5로는 보이는 프로시저가 Cypher 25에서는 제거되어 있을 수 있습니다. 그리고 2026.02 체인지로그 기준, 신규 자가 운영 설치본의 기본 언어가 CYPHER_25로 바뀌었습니다. 새로 설치하면 이제 Cypher 25가 기본입니다.

Rust의 에디션이나 C++ 표준 스위치를 아는 사람에게는 익숙한 그림입니다. 오래된 쿼리를 깨지 않으면서 언어를 표준 쪽으로 밀고 가려면 이 장치가 필요합니다. 그런데 여기엔 비대칭이 하나 숨어 있습니다 — Cypher 25는 2025.06 이후 버전에만 존재하므로, 5.26 LTS에 머무는 팀은 Cypher 25도, 그 위에 얹히는 GQL 문법도 쓸 수 없습니다. 언어의 미래와 지원의 안정 사이에서 하나를 골라야 하는 구조가 현재의 실제 모습입니다.

GQL — 표준 문서에서 체인지로그로 착지하는 방식

ISO/IEC 39075:2024, 즉 GQL은 2024년 4월에 출판된 610쪽짜리 국제 표준입니다(현재 ISO 단계는 90.92, 개정 검토 중). SQL 이후 ISO가 만든 첫 데이터베이스 언어 표준이라는 상징성은 충분히 소비됐으니, 여기서는 실제 착지만 봅니다. 표준은 어떻게 실행 중인 엔진 안으로 들어오는가.

Neo4j의 방식은 "빅뱅 전환"이 아니라 매달 조금씩 Cypher 25에 GQL 문법을 심는 것입니다. 체인지로그를 시간순으로 늘어놓으면 궤적이 보입니다.

2025.06 — FILTER 절(중간 필터링), LET 절(중간 변수 투영), 쿼리 선형 결합용 NEXT 키워드, 중괄호로 감싼 쿼리 블록. 모두 "GQL conformant"로 명시. Cypher Shell 기본 에러 포맷도 GQLSTATUS 기반 gql로 변경.
2026.02 — ceiling, local_time, zoned_datetime, collect_list, percentile_disc, stdev_pop 같은 GQL 호환 함수 별칭 일괄 추가(기존 구현으로 리다이렉트, 동작 변화 없음).
2026.04 — UNWIND의 GQL 대안인 FOR .. IN 절, 레이블 검사 술어 IS LABELED.
2026.05 — GPM 최단경로(ANY SHORTEST, SHORTEST k 등)에 ACYCLIC 같은 명시적 경로 모드 지원.
2026.07(집필 시점 미출시, 체인지로그에 등재) — WITH·RETURN의 GROUP BY 서브클로즈("Cypher를 GQL 표준에 더 정렬하기 위해 도입"이라고 적시), GQL 기능 GF12에 해당하는 cardinality() 함수.

이걸 "Neo4j는 GQL을 지원한다"라고 요약하면 과장이 됩니다. 정확한 상태는 Neo4j가 직접 문서화해 놨습니다. GQL 정합성 부록은 표준 24.2절에 따른 최소 정합(minimum conformance) 선언이고, 지원 항목 옆에 각주가 붙습니다 — 예컨대 GQL의 FLOAT·INTEGER는 정밀도 선택지가 있지만 Cypher의 FLOAT는 항상 64비트 double, INTEGER는 항상 64비트입니다. 그리고 같은 부록에 아직 미지원인 필수(mandatory) 기능 목록이 그대로 있습니다: GQL의 세션 관리 명령(SESSION SET 등), 트랜잭션 명령(START TRANSACTION, COMMIT, ROLLBACK — Neo4j에서는 드라이버 API가 그 역할), CURRENT_GRAPH 같은 그래프 표현식, 스키마 선택 AT 절, 그리고 예약어 목록의 불일치까지.

엔진 지형 전체로 넓혀도 결론은 비슷합니다. Google Spanner Graph는 자사 문서 표현으로 "ISO GQL 호환(compatible) 그래프 쿼리 인터페이스"를 제공하고, Memgraph와 FalkorDB의 문서는 여전히 Cypher를 전면에 둡니다. 요약하면 — GQL은 표준으로서는 실재하지만, 2026년 중반 현재 "GQL로 쓰면 어디서나 돈다"는 이식성은 존재하지 않습니다. 표준의 필수 기능조차 대표 구현체에 다 들어가지 않았고, 각 벤더의 표현("conformant", "compatible")은 서로 다른 것을 의미합니다. GQL 때문에 엔진을 고르는 결정은 아직 이르고, 지금 GQL이 주는 실익은 "새로 배우는 문법이 표준 방향과 일치한다" 정도로 보는 게 정직합니다.

실행 엔진 — 병렬 런타임, 그리고 교착을 예방하는 스케줄러

쿼리 실행 쪽도 같은 기간에 계속 움직였습니다. 배경 지식 하나: Neo4j의 병렬 런타임은 Enterprise 전용이고 읽기 쿼리만 지원합니다. 파이프라인을 morsel 단위 태스크로 쪼개 워커 스레드들이 나눠 먹는 구조인데, 스케줄링이 중앙 큐가 아니라 워커별 분산 스케줄러라는 점이 특징입니다. 2026.05에서는 입력 카디널리티가 1일 때 가변 길이 패턴을 Repeat 연산자로 계획하던 휴리스틱이 기본 비활성화로 바뀌었습니다 — 병렬 런타임을 쓴다면 실행 계획이 조용히 달라졌을 수 있는 지점입니다(쿼리 옵션으로 되돌릴 수 있습니다).

쓰기 쪽에서 눈에 띄는 건 2026.05~2026.06에 걸쳐 들어온 트랜잭션 배치 스케줄링입니다. CALL 서브쿼리를 IN CONCURRENT TRANSACTIONS로 병렬 실행할 때(대량 임포트의 단골 패턴) 지금까지는 교착이 나면 감지 후 재시도였는데, 2026.06의 새 Cypher 25 문법 DISJOINT BY는 교착을 예방하는 쪽으로 접근합니다. 잠금이 걸릴 자원을 식별하는 표현식을 기준으로 행을 배치로 나누고, 자원을 공유하는 배치는 순차로, 공유하지 않는 배치만 동시에 실행합니다.

DISJOINT BY (expr, ...)   -- 잠금 자원을 식별하는 표현식을 직접 선언
DISJOINT BY AUTO          -- 서브쿼리 정적 분석으로 잠금 표현식을 추론
DISJOINT BY NONE          -- 배치 스케줄링을 명시적으로 비활성화

체인지로그의 한계 서술도 그대로 옮겨 둡니다 — AUTO의 정적 분석은 유니크 제약과 인덱스가 받쳐 주는 MERGE 같은 흔한 패턴만 커버하고, 추론이 실패하면 아무 제약 없이 실행되며, 같은 외부 쿼리에서 나온 배치 사이의 교착만 막지 별개의 동시 쿼리 사이 교착은 막지 못합니다. 관계 대량 생성에서 교착 재시도 루프에 데어 본 적이 있다면 시도해 볼 가치가 있고, 그게 아니라면 아직 기본값(비활성)이 답입니다.

트레인 위의 삶이 어떤 것인지 보여 주는 항목도 같은 체인지로그에 있습니다. 2026.02.1은 "ON MATCH 표현식이 병합 중인 변수에 의존할 때 MERGE의 잠재적 데이터 손실"을 고쳤고, 2026.02.3은 pipelined 런타임의 EXISTS 서브쿼리 버그를 고치면서 "최악의 경우 잘못된 데이터가 기록됐을 이론적 위험이 있으나 실제 사례는 확인되지 않았다"고 적었습니다. 매달 릴리스는 이런 픽스가 빨리 도착한다는 뜻이기도 하고, 픽스가 필요한 리그레션이 그만큼 자주 생긴다는 뜻이기도 합니다. 트레인에 탄다면 패치 노트 읽기가 월간 운영 업무에 포함되어야 합니다.

수평 확장 — Infinigraph 프로퍼티 샤딩, 단 별도 구독

체인지로그 곳곳에 등장하는 "sharded property database"는 Infinigraph라는 이름의 분산 아키텍처입니다. 구조가 흥미로운데, 그래프를 통째로 파티셔닝하는 게 아니라 구조와 프로퍼티를 분리합니다. 노드·관계 구조는 단일 "그래프 샤드"에 그대로 두고, 프로퍼티만 해시 함수로 여러 "프로퍼티 샤드"에 고르게 분산합니다. 쿼리 의미와 ACID 보장은 유지된다는 게 문서의 주장이고, 그래프 순회가 구조 샤드 안에서 끝나므로 분산 조인 지옥을 피하는 설계입니다.

뒤집어 말하면 한계도 명확합니다 — 구조 자체는 여전히 한 샤드에 들어가야 하므로, 이건 "프로퍼티가 무거운 그래프"를 위한 확장이지 "구조가 한 머신을 넘는 그래프"를 위한 것이 아닙니다. 그리고 결정적으로, 문서에 명시된 대로 표준 Enterprise Edition에 포함되지 않는 별도 Infinigraph 구독 상품입니다(영업 문의 필요). 엔진 개발은 공개 체인지로그에서 계속 보입니다 — 2026.07 체인지로그(미출시)에는 샤디드 배포용 배치 인덱스 시크 연산자(RemoteNodeIndexSeek)가 올라와 있습니다. 기능의 존재와 기능에 대한 접근은 별개라는 것까지가 이 절의 사실관계입니다.

어느 트랙에 설 것인가 — 판단 기준

정리하면 이렇게 갈립니다.

5.26 LTS에 머무를 때

업그레이드 창구가 분기·반기 단위로 묶여 있고, 지원 계약이 중요한 운영 환경이다. 2028년 6월까지 핫픽스가 나온다(5.26.28이 2026년 6월 30일에도 나왔습니다).
단, 블록 포맷 마이그레이션은 지금 해 두는 게 좋다 — 어차피 5.26의 기본값이고, 나중에 캘버로 갈 때의 선행 조건처럼 권고된다.
Cypher 25, VECTOR 타입, 새 GQL 문법, ABAC 없이 사는 것을 받아들인다.

캘버 트레인에 올라탈 때

매달(최소한 격월) 업그레이드를 자동화할 파이프라인과, 패치 노트를 읽는 운영 습관이 있다.
Cypher 25의 새 문법이나 벡터 기능이 실제 요구사항이다.
지원되는 버전은 항상 "최신 하나"라는 사실을 조직이 이해하고 있다.

Community Edition이라면 — 블록 포맷도 병렬 런타임도 없는(aligned 포맷, 단일 스레드 런타임) 다른 제품을 쓰고 있다고 생각하는 편이 정확합니다. 엔진 관점의 이번 세대 개선 대부분은 EE 쪽에 떨어졌습니다.

GQL 이식성을 노린다면 — 아직 계약이 아니라 방향입니다. 표준 필수 기능 미지원 목록이 대표 구현체 문서에 남아 있는 동안은, GQL은 "언젠가 갈아탈 수 있게 표준 방향의 문법을 익혀 두는 것" 이상을 보장하지 않습니다.

임베디드 그래프 엔진을 찾고 있었다면 — 이 지형은 지난가을에 크게 흔들렸습니다. 임베디드의 대표 주자였던 Kùzu는 저장소가 2025년 10월 10일자로 아카이브됐고(마지막 릴리스 v0.11.3, 저장소), 커뮤니티 포크로 이어지는 중입니다. 선택지 정리는 도구 편에서 이미 다뤘으니 그쪽을 참고하세요.

마치며

캘버 전환 후 1년 반의 Neo4j를 한 문장으로 줄이면 이렇습니다 — 엔진은 블록 포맷 위에서 매달 자라고, 언어는 GQL을 향해 버전 단위로 이동 중이며, 그 속도의 대가는 "지원되는 버전은 항상 최신 하나"라는 운영 모델이 치른다. 표준(GQL)은 출판됐지만 이식성은 아직 오지 않았고, LTS를 원하는 팀과 새 기능을 원하는 팀은 현재 서로 다른 메이저 버전을 쓰는 것과 다름없는 거리에 서 있습니다.

그래프를 RAG 재료로만 쓰는 입장이라면 이 글의 대부분은 당장 무관합니다 — 관리형 서비스나 임베디드 스토어 뒤에 숨은 층이니까요. 하지만 그래프 DB를 직접 운영하거나, 지금 엔진을 고르는 중이거나, "GQL 표준 지원"이라는 마케팅 문구를 평가해야 하는 입장이라면, 판단 재료는 벤더 슬라이드가 아니라 위에 링크한 체인지로그와 정합성 문서에 있습니다. 표준이 엔진에 착지하는 과정은 화려하지 않습니다. 매달, 절 하나씩, 함수 별칭 한 묶음씩 — 그게 실제 모습입니다.