최근 공개된 한 실험적 프로젝트는 그래프 데이터베이스, TypeScript 타입 시스템, 그리고 Y.js 같은 CRDT를 한데 묶었습니다. 핵심은 "타입 안전한 그래프 질의"와 "오프라인을 포함한 실시간 협업"을 같은 데이터 모델 안에서 다루겠다는 시도입니다.1
이게 지금 중요한 이유는 분명합니다. 로컬-퍼스트와 협업 소프트웨어가 더 이상 문서 편집기에만 머물지 않기 때문입니다. 이제는 앱 상태, 지식 그래프, 워크플로우, 에디터 콘텐츠까지 "연결된 데이터" 자체를 여러 사용자가 동시에 만지는 쪽으로 가고 있습니다. 그때 기존 DB의 충돌 해결, 클라이언트 타입 안정성, 오프라인 동기화는 따로따로 붙이기 어려운 문제였습니다.234
이 조합의 본질은 "그래프 저장소"가 아니라 "협업 가능한 애플리케이션 상태"다
확인 가능한 사실부터 보죠. 공개된 설명과 커뮤니티 논의를 보면, 이 프로젝트는 Gremlin 스타일 API로 TypeScript 쿼리 타입 안정성을 얻고, 스키마는 Zod류 런타임/컴파일타임 도구로 정의하며, 저장과 동기화는 Y.js 기반 CRDT에 기대고, 필요하면 Cypher도 지원하는 방향입니다.15
이 조합이 뜻하는 바는 단순히 "그래프 DB 하나 더 나왔다"가 아닙니다. 오히려 그래프를 협업 가능한 상태 모델로 취급한다는 데 가깝습니다. 노드와 엣지의 속성에 일반 JSON만 넣는 것이 아니라, Y.Text 같은 CRDT 자체를 속성으로 담을 수 있다는 점이 특히 그렇습니다.5 즉 "관계 구조"와 "동시 편집되는 콘텐츠"를 같은 데이터 계층에 놓으려는 설계입니다.
실무적으로는 이런 그림이 가능합니다. 예를 들어 제품 기획 툴에서 화면, 컴포넌트, 요구사항, 담당자, 링크 관계는 그래프로 표현하고, 각 노드의 설명문은 동시에 편집되는 CRDT 텍스트로 유지하는 식입니다. 보통은 그래프 DB, 문서 저장소, 협업 편집 엔진을 따로 엮어야 했던 문제를 한 모델로 줄이려는 접근입니다.
CRDT가 해결하는 것과, 해결하지 않는 것
CRDT의 강점은 명확합니다. 여러 복제본이 조정 없이 독립적으로 업데이트돼도, 병합 규칙이 교환법칙·결합법칙·멱등성을 만족하면 결국 같은 상태로 수렴할 수 있습니다.2 그래서 오프라인 편집, 멀티디바이스 동기화, 지연이 큰 네트워크에서 특히 유리합니다.
하지만 여기서 흔한 오해를 걷어낼 필요가 있습니다. CRDT는 "충돌이 없다"가 아니라 "충돌을 데이터 타입 내부 규칙으로 흡수한다"에 가깝습니다.26 텍스트, 카운터, 집합처럼 병합 의미를 잘 정의할 수 있는 데이터에는 강하지만, 비즈니스 규칙 전체를 자동으로 해결해주지는 않습니다. 예를 들어 승인 워크플로우, 재고 차감, 상호 배타 제약은 여전히 별도 설계가 필요합니다.
로컬-퍼스트 시스템도 마찬가지입니다. UX는 빨라지지만, 데이터셋 크기 한계, 브라우저 저장소 제약, 스키마 마이그레이션, 명시적 충돌 정책 같은 비용이 따라옵니다.47 그러니 "그래프 + CRDT"는 만능 조합이 아니라, 협업과 연결성이 핵심인 도메인에서만 비로소 복잡성을 정당화합니다.
그래프 DB여야 하느냐는 여전히 열려 있다
커뮤니티 반응에서 흥미로운 지점은 "이걸 꼭 그래프 DB로 해야 하느냐"는 질문이었습니다. 일부는 Datalog나 관계형 모델로도 재귀 질의와 타입 안정성을 얻을 수 있다고 지적했고, 반대로 그래프 쿼리는 경로 탐색과 패턴 매칭, 결과를 그래프 형태로 다루는 점에서 더 자연스럽다는 반론도 나왔습니다.58
이 논쟁에서 중요한 건 승부가 아니라 기준입니다. 관계가 깊고 가변적이며, 몇 홉 떨어진 연결 패턴을 자주 탐색해야 한다면 그래프 모델이 개발자 경험에서 유리할 수 있습니다.8 반면 데이터의 핵심이 엄격한 제약, 집계, 대규모 표 형식 처리라면 관계형이나 Datalog 계열이 더 낫습니다. 즉 이번 시도의 참신함은 "그래프가 최고"가 아니라, 그래프를 협업 가능한 로컬-퍼스트 상태로 만들었다는 데 있습니다.
실무 판단 기준은 단순합니다.
여러 사용자가 같은 연결 구조를 동시에 바꾸는가.
오프라인 편집이 필수인가.
텍스트 같은 협업형 필드가 노드/엣지 안에 함께 있어야 하는가.
그리고 TypeScript 수준의 end-to-end 타입 안전성이 제품 개발 속도에 실제로 도움이 되는가.
이 질문에 여러 개가 "예"라면, 이런 접근은 실험이 아니라 꽤 현실적인 선택지가 됩니다.
결국 이 소식이 말해주는 변화는 하나입니다. 협업 시스템의 중심이 "문서"에서 "구조화된 연결 데이터"로 넓어지고 있다는 점입니다. 지금 이 흐름을 가장 유심히 봐야 할 사람은 협업 SaaS, 내부 도구, 지식 관리, 설계/편집 제품을 만드는 팀입니다. 반대로 단순 CRUD 앱이라면, 이 아키텍처는 혁신이라기보다 과한 무기일 가능성이 큽니다.
참고
1A type-safe, realtime collaborative Graph Database in a CRDT
2Conflict-free replicated data type - Wikipedia
3Why Local-First Software Is the Future and what are its Limitations
5A type-safe, realtime collaborative Graph Database in a CRDT | Hacker News
6CRDT - Conflict-free replicated data type Database | RxDB - JavaScript Database
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.