메모리 걱정 없이 그래프 탐색을 — 읽기 중심 워크로드에 특화한 경량 그래프 DB 'Slater'

그래프 데이터베이스라고 하면 어떤 이미지가 떠오르세요? 강력하지만 무겁고, 서버 메모리를 왕창 잡아먹는 비싼 물건이라는 인상이 강한데요. 이런 통념에 도전하는 프로젝트가 하나 공개됐어요. Hikari Systems가 오픈소스로 내놓은 'Slater'라는 그래프 DB인데, 핵심 컨셉이 아주 명확해요. "읽기가 압도적으로 많은 그래프를, 적은 메모리로 빠르게 탐색하자"는 거예요.

그래프 DB가 뭐냐면

먼저 그래프 데이터베이스가 뭔지부터 짚고 갈게요. 우리가 흔히 쓰는 관계형 DB(MySQL, PostgreSQL)는 데이터를 표(테이블)에 담아요. 반면 그래프 DB는 데이터를 점(노드)과 선(엣지)으로 저장해요. "철수가 영희를 팔로우한다", "이 상품은 저 카테고리에 속한다" 같은 '관계' 자체를 일급 시민으로 다루는 거죠.

관계형 DB에서 "친구의 친구의 친구"를 찾으려면 JOIN을 여러 번 겹쳐야 하는데, 데이터가 커질수록 이게 급격히 느려져요. 그래프 DB는 노드에서 연결된 엣지를 따라가기만 하면 되니까 이런 '관계 탐색'이 훨씬 빠르거든요. 추천 시스템, 소셜 그래프, 권한 관리, 지식 그래프 같은 곳에서 그래프 DB를 쓰는 이유예요.

왜 '저메모리'와 '읽기 중심'이 포인트일까

문제는 기존 그래프 DB들의 비용이에요. 대표주자인 Neo4j는 JVM 위에서 돌아가는데, 제대로 성능을 내려면 그래프의 상당 부분을 힙 메모리에 올려둬야 해요. Memgraph 같은 인메모리 DB는 아예 전체 그래프를 램에 올리는 걸 전제로 하고요. 그래프가 수억 엣지 규모로 커지면 램 수십 기가짜리 서버가 필요해지는 거죠.

그런데 실제 서비스를 뜯어보면, 그래프 데이터의 상당수는 "가끔 갱신되고, 엄청나게 자주 읽히는" 패턴이에요. 추천 그래프, 카테고리 트리, 조직도, 권한 그래프 같은 것들은 하루 몇 번 배치로 갱신되고 나머지 시간엔 읽기만 하잖아요? 범용 그래프 DB는 실시간 쓰기를 위해 잠금(락), 트랜잭션 로그, 복잡한 인덱스 구조 같은 비용을 항상 지불하는데, 읽기 중심 워크로드에선 이게 전부 낭비거든요.

Slater는 바로 이 지점을 노려요. 쓰기 경로에 들어가는 복잡한 장치를 덜어내는 대신, 그래프를 읽기에 최적화된 촘촘한 구조로 저장해서 디스크에서 바로 읽어도 빠르게 만드는 접근이에요. 이런 계열의 엔진들이 흔히 쓰는 기법이 압축 인접 리스트(CSR) 같은 건데요. 이게 뭐냐면, 각 노드의 이웃 목록을 포인터 덩어리로 여기저기 흩어놓는 게 아니라 커다란 배열 하나에 착착 이어 붙여놓는 방식이에요. 메모리 사용량이 확 줄고, CPU 캐시 적중률도 좋아져서 탐색이 빨라져요. 여기에 운영체제의 메모리 매핑(mmap)을 활용하면 전체를 램에 올리지 않아도 "자주 읽는 부분만 알아서 램에 올라와 있는" 효과를 얻을 수 있고요. 덕분에 램이 그래프 크기보다 훨씬 작아도 읽기 성능을 유지할 수 있는 거예요.

업계 흐름에서 보면

최근 몇 년 사이 데이터베이스 판의 재미있는 흐름 중 하나가 '임베디드·경량화'예요. SQLite가 재조명받고, 분석 쪽에서는 DuckDB가 대세가 됐잖아요. "서버 한 대 더 띄우지 말고, 내 프로세스 안에서 가볍게 해결하자"는 거죠. 그래프 쪽에서도 KùzuDB 같은 임베디드 그래프 DB가 나오면서 같은 흐름이 만들어지고 있어요. Slater도 이 연장선에 있다고 보면 돼요. "Neo4j 클러스터를 띄울 정도는 아닌데, 관계형 DB에서 재귀 쿼리를 돌리자니 괴로운" 그 애매한 중간 구간을 노리는 거예요.

한국 개발자에게는

실무 관점에서 보면, "이거 그래프 문제인 건 아는데 그래프 DB 도입은 부담스러워서" PostgreSQL의 재귀 CTE나 애플리케이션 레벨 캐시로 버텨온 팀이 꽤 많을 거예요. 팔로우 그래프, 추천 로직, 조직도·권한 트리 같은 것들요. 이런 데이터가 '읽기 중심'이라면 경량 그래프 엔진이 현실적인 대안이 될 수 있어요. 다만 아직 초기 단계의 프로젝트인 만큼, 프로덕션에 바로 넣기보다는 사이드 프로젝트나 내부 도구에서 먼저 검증해보는 걸 추천해요. 그 과정에서 CSR, 메모리 매핑 같은 저수준 최적화 기법을 직접 공부하게 되는 것 자체가 큰 수확이기도 하고요.

한 줄 정리: 모든 그래프 워크로드에 무거운 범용 그래프 DB가 필요한 건 아니다 — 읽기 중심이라면 훨씬 가벼운 선택지가 생기고 있다.

여러분 서비스엔 "사실상 그래프인데 관계형 DB로 억지로 풀고 있는" 데이터가 있나요? 있다면 어떤 방식으로 버텨오셨는지, 경량 그래프 DB가 나오면 갈아탈 의향이 있는지 궁금해요.