MongoDB 와 Redis 는 NoSQL 을 다룰 때 가장 자주 마주치는 두 도구다. 같은 NoSQL 범주에 들어가지만 실무에서 맡는 역할은 다르다. MongoDB 는 Document store 로 영구 저장의 주 저장소 역할을 하고, Redis 는 메모리 기반 저장소로 캐시·세션 같은 보조 역할에 주로 쓰인다.
채팅 시스템 chat-services 를 개발할 때 처음에는 Redis 에 메시지를 저장했다가 영속성이 필요해져 MongoDB 로 옮긴 적이 있다. 회고에서는 짧게 짚고 지나간 결정인데, 같은 NoSQL 인데 두 도구의 역할이 왜 갈리는지를 데이터 모델·스토리지·스키마·확장·사용 사례를 기준으로 풀어둔다.
데이터 모델
두 도구가 가장 먼저 갈리는 곳은 저장 단위다.
Redis 는 Key-Value 저장소다. 키 하나에 값 하나를 매핑하는 단순한 구조 위에 String, List, Set, Sorted Set, Hash, Stream 같은 자료구조를 값 타입으로 다룰 수 있다. 단일 키 조회·쓰기가 가장 자연스러운 접근이고, 복합 조회는 클라이언트나 별도 인덱스에 맡긴다.
MongoDB 는 Document store 다. 키-값을 넘어 JSON-like 문서(BSON) 를 단위로 저장한다. 한 문서에 중첩 필드, 배열, 다양한 타입이 들어갈 수 있고 컬렉션 단위로 묶인다. 한 문서가 한 엔티티에 대응하는 경우가 많아 도메인 모델을 그대로 옮기기에 자연스럽다.
스토리지와 영속성
Redis 는 데이터를 메모리에 보관한다. 영속성은 선택 사항으로, 스냅샷 방식의 RDB 와 명령 단위 로그 방식의 AOF 가 있다. RDB 만 활성화된 일반 구성에서는 마지막 스냅샷 이후의 변경이 장애 시 유실될 수 있다. AOF 를 켜면 변경 단위로 로그가 남아 손실 범위가 줄지만, 주 저장 매체가 메모리라는 점은 그대로다.
MongoDB 는 디스크를 주 저장 매체로 쓴다. 스토리지 엔진은 기본으로 WiredTiger 가 쓰이고, 쓰기는 저널과 함께 디스크에 기록된다. 처음부터 영속성을 전제로 동작한다. 여기에 replica set 을 구성하면 여러 노드에 복제본을 두어 단일 노드 장애에서도 데이터를 유지할 수 있다.
스키마와 쿼리
Redis 의 쿼리는 명령 단위다. GET, SET, HGETALL, ZRANGE 같은 자료구조별 명령을 직접 호출한다. 조건 검색 같은 복합 쿼리는 명령만으로 표현하기 어려워 RediSearch 같은 모듈을 따로 붙여야 한다. 스키마 개념이 없어, 값을 어떻게 해석할지는 애플리케이션이 책임진다.
MongoDB 는 자체 쿼리 언어 MQL 을 제공한다. find, aggregate, update 같은 연산으로 조건 검색, 집계, 부분 갱신을 표현한다. 컬렉션에 스키마를 강제하지 않지만, 필요하면 JSON Schema 기반 검증을 걸어 일부 필드의 형태를 제한할 수 있다. 도메인이 자주 변하는 초기에는 이 유연함이 잘 맞고, 안정화된 뒤에는 검증을 점진적으로 더해가는 운영도 가능하다.
확장과 가용성
Redis Cluster 는 키 공간을 일정 수의 슬롯으로 나누어 여러 노드에 분산한다. 각 슬롯이 노드에 할당되고, 한 노드가 자기 슬롯의 키를 책임진다. 복제는 master-replica 구조로 구성한다. 장애가 나면 sentinel 또는 Cluster 가 replica 를 master 로 승격한다.
MongoDB 의 확장은 sharded cluster 와 replica set 두 가지 방식으로 나뉜다. sharded cluster 는 컬렉션을 shard key 기준으로 잘라 여러 shard 에 나눠 담는다. replica set 은 데이터 사본을 여러 노드에 두고, primary 가 장애를 겪으면 secondary 중 하나가 자동으로 새 primary 로 선출된다. 자동 장애 조치가 기본 동작에 포함된다.
사용 사례
두 도구의 역할이 여기서 갈린다.
Redis 는 캐시, 세션 저장, rate limit, 분산 lock, 짧은 큐 같은 보조 역할에 주로 쓰인다. 빠른 응답과 낮은 지연시간이 중요할 때, 잠시 보관해도 되는 데이터를 메모리에서 처리할 때 잘 맞는다.
MongoDB 는 primary store 자리다. 영구 저장이 필요한 도메인 데이터를 본 저장소로 다루고, 스키마 변경이 잦거나 문서 구조가 자연스러운 도메인에서 자주 선택된다. 사용자, 콘텐츠, 주문, 로그 같은 데이터가 전형이다.
같은 NoSQL 이지만 실무에서는 “이 데이터를 영구 저장할 것인가, 보조 캐시로 둘 것인가” 라는 질문이 선택을 가른다.
함께 쓰는 패턴
실무에서는 둘 중 하나만 쓰는 경우보다 함께 쓰는 경우가 더 잦다.
가장 흔한 형태는 MongoDB 를 primary store 로 두고 Redis 를 그 앞에 캐시 계층으로 두는 구성이다. 자주 조회되는 데이터를 Redis 에 캐싱해 디스크 접근을 줄이고, 캐시 미스가 나면 MongoDB 에서 읽어 다시 캐시에 채워 넣는다. 세션 저장, rate limit, 일회성 토큰 같은 보조 데이터는 Redis 에만 두고 MongoDB 는 도메인 데이터에 집중하게 한다.
chat-services 의 메시지 저장도 Redis 로 시작했다가 영속성이 필요해지면서 MongoDB 로 옮겼다. 여기에 캐시 계층으로 Redis 를 추가하면, 같은 두 도구를 역할에 맞게 나눠 쓰는 구성이 된다.
선택 기준
지금까지의 비교 항목을 표로 정리하면 다음과 같다.
| 항목 | Redis | MongoDB |
|---|---|---|
| 데이터 모델 | Key-Value | Document |
| 주 저장 매체 | 메모리 | 디스크 |
| 영속성 기본값 | 옵션 (RDB/AOF) | 기본 활성 (저널 + replica set) |
| 쿼리 | 명령 기반 | MQL (find/aggregate) |
| 스키마 | 없음 | 유연 + 선택적 검증 |
| 확장 | Cluster (슬롯 분산) | sharded cluster (shard key) |
| 자동 장애 조치 | sentinel/Cluster | replica set 기본 |
| 주된 역할 | 캐시, 세션, rate limit | primary store |
다음 세 가지를 따져보면 된다.
- 영구 저장이 필요하면 MongoDB 를 primary 로 두고 Redis 를 보조 캐시로 둔다.
- 지연시간이 가장 중요한 경로라면 Redis.
- 스키마가 자주 변한다면 MongoDB 의 Document 모델이 잘 맞는다.
같은 NoSQL 이지만 두 도구는 결국 서로 다른 역할을 맡는다. 그래서 함께 쓰는 구성이 흔하다.
참고
- chat-services — Redis → MongoDB 전환 맥락
- RDB Transaction 의 ACID 가 실제로 보장하는 것 — RDB 의 트랜잭션 보장
- MongoDB 공식 docs — Storage Engines, Replica Set, Sharded Cluster
- Redis 공식 docs — Persistence, Cluster, Replication