Redis는 이제 단순한 키-값(Key-Value) 저장소를 넘어, 매우 다양한 기능을 지원하는 강력한 데이터 플랫폼으로 진화했습니다.
최근 Redis를 공부하면서 문득 궁금한 점이 생겼습니다. 바로 데이터를 String 타입으로 저장하는 것과 RedisJSON 모듈을 사용하는 것의 결정적인 차이가 무엇인가 하는 점이었습니다. 단순히 "JSON 전용 명령어를 더 제공한다"거나 "성능이 조금 더 빠르다" "네트워크 비용 절감"정도의 차이만 있는 걸까요? 두 방식 사이에는 생각보다 다양한 차이점이 숨어 있었습니다.
근본적인 차이
Redis String과 RedisJSON의 가장 근본적인 차이는 데이터를 서버 메모리 내에 저장하는 방식에서 차이점이 있습니다. Redis String은 '바이너리 세이프(Binary-safe)' 문자열로, 한 번에 내부 구조를 알 수 없는 바이트 배열로 구성되어 있습니다. 따라서 1MB 크기의 JSON을 String으로 저장하면 Redis는 이를 그저 단순한 1MB의 데이터 덩어리로 취급합니다. 이 때문에 특정 필드에 접근하거나 데이터 조작하는 것이 힘듭니다.
반면, Redis Stack의 RedisJSON은 데이터를 단순한 문자열로 보관하는 것이 아니라 수신된 JSON 데이터를 역직렬화하여 서버 내부에 계층적인 '트리(Tree)' 구조로 재구성합니다. 특히 RedisJSON 2.0 버전부터는 성능 극대화와 메모리 안전성을 위해 Rust로 재작성되었으며, 덕분에 Path 표현식을 통한 정교한 탐색이 가능합니다.
비교 요약
| 구분 | Redis String | RedisJSON |
| 데이터 형태 | 바이너리 세이프 문자열 | 역직렬화된 계층 트리 구조 |
| 구현 언어 | C | Rust |
| 서버가 인식하는 형태 | 데이터 덩어리(내부 구조 인지 불가) | 구조화된 문서 (필드 및 데이터 타입 인지) |
메모리 관리와 데이터 효율성
데이터를 구조화하여 저장하는 RedisJSON의 방식은 기능적으로는 우월할 수 있지만, 메모리 점유율 측면에서는 Redis String이 훨씬 유리합니다. Redis String은 데이터를 별도의 해석 없이 압축된 바이트 배열 형태로 보관하기 때문에 메모리 오버헤드가 매우 낮습니다. 단순히 값의 길이에 비례하여 메모리를 사용하므로, 저장 공간을 극도로 효율적으로 관리할 수 있다는 강점이 있습니다.
반면, RedisJSON은 각 필드와 값에 대해 메타데이터 등 개별적으로 유지해야 합니다. 데이터를 트리 형태로 재구성하는 과정에서 실제 데이터 크기보다 더 많은 메모리를 점유하게 됩니다. 실제로 RedisJSON은 각 값마다 최소 8바이트 이상의 기본 공간이 필요하며, 구조가 복잡해질수록 이 비용은 더욱 늘어납니다.
| 대상 파일 | String 메모리 점유량 (Bytes) | RedisJSON 메모리 점유량 (Bytes) | MessagePack |
| pass-100.json (nested object) |
381 | 1069 | 140 |
| pass-json-parser-0000.json (Deeply nested object) |
3718 | 5469 | 2393 |
| pass-jsonsl-yahoo2.json (현실적인 데이터) |
22466 | 26901 | 16869 |
| pass-jsonsl-yelp.json (현실적인 데이터) |
46333 | 57513 | 35529 |
RedisJSON 공식 문서의 테스트 결과에 따르면, JSON 파일을 RedisJSON에 저장했을 때 실제 파일 크기보다 약 1.2~3배 정도의 메모리가 더 소요되는 것으로 나타났습니다. 이러한 구조적 오버헤드는 RedisJSON의 단점입니다 이를 보완하기 위해 전역 문자열 재사용 메커니즘을 사용합니다. 문자열 값이 동일한 JSON 문서 내에서 또는 동일한 노드의 여러 문서에서 여러 번 나타나는 경우, Redis는 해당 문자열의 복사본을 하나만 저장하고 이를 참조로 사용합니다.
여러 모듈과 시너지
데이터를 저장하는 것만큼이나 중요한 것이 바로 '원하는 데이터를 얼마나 효율적으로 찾아내는가'입니다. 이 부분에서 RedisJSON은 다른 모듈들과 결합하여 Redis String 방식에서는 볼 수 없는 이점이 생깁니다.
Redis String에 저장된 JSON은 Redis 입장에서 그저 '의미 없는 바이트의 연속'일 뿐입니다. 특정 필드 값으로 데이터를 필터링하거나 검색하는 것이 기본적으로 불가능하죠. 이를 구현하려면 애플리케이션 레벨에서 별도의 Set이나 Sorted Set을 생성해 수동으로 인덱스를 관리해야 합니다.
그에 비해 RedisJSON은 RediSearch 모듈과 결합했을 때 좋은 시너지를 발휘하는데, FT.CREATE 명령으로 JSON 문서에 인덱스를 한 번만 설정해두면 Redis가 JSONPath를 통해 필드 변경 사항을 실시간으로 감시하고 인덱스에 자동 반영해 줍니다. 이를 통해 키워드 검색이나 오타 교정이 가능한 전문 검색(Full-Text Search)을 수행할 수 있으며, 물론 Elasticsearch 비해 한국어 지원은 아직 미흡한 편이지만 수치 범위나 태그 기반 검색 등 데이터의 특성에 맞는 다양한 쿼리 기능을 효율적으로 활용할 수 있습니다.
결론
서론에서 던졌던 질문인 "단순히 명령어가 더 많고 네트워크 비용이 절감되는 수준의 차이일까?"에 대한 답을 명확히 찾은 것 같습니다. Redis String과 RedisJSON이 데이터를 바라보는 관점 자체가 완전히 다르다는 점이었습니다. 단순히 바이트 배열로 데이터를 취급하는 String 방식과 달리, RedisJSON은 데이터를 계층 트리 구조로 인식합니다. 이러한 시각의 차이가 결국 원자성, 네트워크 비용 절감, 성능의 차이를 만들어내는 근본적인 원인이었습니다.
특히 가장 인상 깊었던 점은 RedisJSON이 RediSearch와 결합했을 때 발휘하는 시너지였습니다. 인덱싱과 쿼리 기능을 통해 복잡한 검색을 할 수 있다는 내용이 Redis가 이제는 단순한 캐시 서버를 넘어 메모리 기반의 데이터베이스의 기능을 할 수 있다는 생각을 가지게 되었습니다.
참고자료
Redis JSON RAM Usage
Debugging memory consumption
redis.io
Redis JSON RAM Usage
Debugging memory consumption
redis.io