MongoDB, Redis, Couchbase는 모두 NoSQL로 분류되지만 같은 문제를 같은 방식으로 해결하지는 않는다. 문서 조회와 집계가 중요한 서비스, 만료가 있는 짧은 상태를 빠르게 처리하는 서비스, 모바일 오프라인 동기화가 필요한 서비스는 선택 기준이 다르다.
이 글은 세 제품의 데이터 모델, 접근 경로, 일관성, 장애 복구와 운영 비용을 비교한다. 성능 순위를 매기는 벤치마크는 아니다. 자체 운영 제품과 관리형 서비스, 서버와 모바일 제품의 기능도 구분한다.
1. 데이터 모델과 주된 접근 방식
| 항목 | MongoDB | Redis | Couchbase |
|---|---|---|---|
| 중심 모델 | BSON 문서와 컬렉션 | 키와 다양한 자료구조 | 키로 식별하는 JSON 문서 |
| 대표 접근 | MQL 조회·집계 파이프라인 | 자료구조별 명령 | KV API·SQL++ |
| 설계 출발점 | 함께 읽고 수정할 데이터를 문서로 모델링 | 필요한 연산에 맞는 자료구조 선택 | 키 기반 접근과 인덱스 질의를 구분 |
| 함께 검토할 비용 | 인덱스·샤드 키·집계 | 메모리·키 수명·복제·영속화 | 서비스별 자원·인덱스·복제·리밸런싱 |
MongoDB와 Couchbase가 유연한 문서를 지원한다는 것은 스키마 설계가 필요 없다는 뜻이 아니다. 필수 필드, 타입, 중복 데이터 갱신과 문서 크기를 관리해야 한다. BSON 역시 날짜·숫자·바이너리 등 타입을 표현하는 형식이지 JSON보다 언제나 더 작은 형식은 아니다.
Redis에는 String 외에도 Hash, List, Set, Sorted Set, Stream 등이 있다. 예를 들어 순위 갱신은 Sorted Set, 만료되는 인증 보조 상태는 TTL을 가진 키처럼 필요한 연산을 기준으로 모델을 고른다. 검색·JSON 등의 기능은 설치한 버전과 제품 구성에 맞춰 지원 범위를 확인한다.
2. MongoDB: 문서 조회와 집계를 중심으로 보기
MongoDB는 중첩 문서와 배열을 포함한 데이터를 조회하고 집계 파이프라인으로 필터링·그룹화·변환할 수 있다. 문서 단위의 원자적 변경을 활용하면 여러 필드를 함께 갱신하는 로직이 단순해질 수 있다. 여러 문서에 걸친 불변 조건에는 별도의 트랜잭션 설계가 필요하다.
WiredTiger의 캐시와 디스크 저장을 함께 사용하므로 “디스크 DB라서 모든 조회가 느리다”고 설명하는 것은 부정확하다. working set이 메모리에 들어가는지, 인덱스를 타는지, 반환 문서와 집계 중간 결과가 얼마나 큰지가 실제 비용을 좌우한다.
복제와 샤딩은 목적이 다르다. Replica Set은 데이터 사본과 장애 전환을 제공하고, 샤딩은 샤드 키를 기준으로 데이터를 나눠 부하와 저장 용량을 분산한다. 부적절한 샤드 키는 특정 샤드에 쓰기를 몰거나 여러 샤드에 질의를 보내게 만들 수 있다. 노드를 추가한다고 모든 질의가 자동으로 선형 확장되지는 않는다.
Primary 읽기와 일관성은 같은 설정이 아니다
| 설정 | 결정하는 것 |
|---|---|
readPreference | 어느 노드에서 읽을지 |
readConcern | 읽은 데이터에 어떤 보장을 요구할지 |
writeConcern | 어떤 확인을 받아야 쓰기 성공으로 볼지 |
Primary에서 읽는다는 사실만으로 모든 장애 상황에서 최신성과 내구성이 보장되지는 않는다. majority 읽기는 다수 복제본이 확인한 데이터를 읽는 보장이고, 가장 최근의 모든 쓰기를 즉시 반영한다는 뜻은 아니다. 단일 문서의 실시간 순서 보장이 필요한 경우 linearizable 읽기와 majority 쓰기 등 문서화된 조건을 검토한다. 이런 보장에는 추가 통신과 대기 비용이 따른다.
사용자 자신의 쓰기를 이어서 읽는 요구에는 인과적 일관성 세션과 읽기·쓰기 설정의 조합을 고려한다. “MongoDB는 강한 일관성”이라는 한 줄보다 어떤 연산에 어떤 조건을 적용하는지 쓰는 편이 정확하다.
3. Redis: 메모리 연산과 복구 정책을 함께 보기
Redis는 메모리 중심으로 자료구조 연산을 처리한다. 그렇다고 모든 명령이 상수 시간인 것은 아니다. 큰 키를 순회하거나 비용이 큰 명령·스크립트를 실행하면 다른 요청의 지연에도 영향을 줄 수 있다. 명령 복잡도, 키 크기, 네트워크 왕복을 같이 봐야 한다.
자료구조 변경의 원자성은 유용하지만 외부 DB와 하나의 트랜잭션이 되는 것은 아니다. Redis에서 재고를 차감한 뒤 주문 DB 저장이 실패하면 별도 복구가 필요하다. Lua 스크립트도 DB와의 일관성이나 장애 이후의 데이터 보존까지 보장하지 않는다.
영속화와 복제는 서로 다른 장치다
| 장치 | 역할 | 확인할 경계 |
|---|---|---|
| RDB | 시점 스냅샷으로 복구 | 스냅샷 이후 변경분의 손실 가능성 |
| AOF | 쓰기 기록을 이용해 복구 | fsync 정책, 재작성 비용과 복구 시간 |
| 복제 | 다른 노드에 데이터 사본 유지 | 복제 지연과 장애 전환 시 손실 가능성 |
| 백업 | 실수·손상 등에서 과거 데이터 복원 | 보존 기간과 실제 복원 가능 여부 |
기본 복제는 비동기다. Replica 읽기에는 지연이 있을 수 있고, Primary에서 확인받은 쓰기도 복제 전에 장애가 나면 잃을 수 있다. WAIT는 복제 확인 수를 늘리는 도구지만 강한 일관성과 무손실 장애 전환을 자동으로 제공하지는 않는다.
Sentinel은 감시와 장애 전환을, Redis Cluster는 데이터 분산과 장애 처리를 담당한다. Cluster에서 여러 키를 함께 사용하는 연산은 키 배치 제약을 확인해야 한다. 상용·관리형 제품의 다중 지역 기능을 일반 Redis Open Source 구성의 기본 동작과 섞지 않는다.
캐시로 사용할 때는 TTL과 eviction 정책을 정하고 원본을 다시 읽을 수 있게 한다. 재생성할 수 없는 데이터를 같은 정책으로 관리하면 메모리 부족 시 업무 데이터가 사라질 수 있다. “빠르다”는 특성과 “원본 저장소로 어떤 복구 수준을 제공한다”는 판단은 따로 한다.
4. Couchbase: KV와 SQL++의 경계를 보기
Couchbase는 문서 키로 직접 접근하는 KV API와 SQL++ 질의를 함께 제공한다. Data, Query, Index 같은 서비스의 역할과 자원 요구를 구분할 수 있어, 구성에 따라 서비스를 나누어 확장할 수 있다. 대신 서비스 배치와 인덱스 가용성을 관리해야 한다.
메모리를 적극적으로 사용하지만 모든 읽기가 언제나 메모리에서 끝나는 것은 아니다. 메모리 적재 비율, 데이터 크기, 저장 엔진과 eviction 동작에 따라 디스크 접근이 발생할 수 있다. “메모리 우선이므로 MongoDB보다 항상 빠르다”는 결론에는 동일 조건의 측정이 필요하다.
쓰기 내구성과 인덱스 최신성은 별개다
일반 쓰기와 durable write는 성공 응답의 조건이 다르다. majority, majorityAndPersistActive, persistToMajority처럼 복제와 디스크 저장에 대해 요구하는 수준을 선택할 수 있다. 타임아웃으로 결과가 모호한 경우에는 업무 식별자와 조회·재시도 정책이 필요하다.
KV로 읽은 문서와 SQL++의 보조 인덱스를 통해 찾은 결과도 구분한다. 인덱스 갱신을 기다리지 않는 질의는 방금 쓴 문서를 바로 찾지 못할 수 있다. 필요한 요청에 request_plus 또는 쓰기 토큰을 이용한 일관성 옵션을 적용하되 대기 비용을 고려한다. request_plus가 시스템의 모든 미래 쓰기를 포함한 실시간 스냅샷을 뜻하지는 않는다.
Couchbase는 여러 문서에 걸친 트랜잭션도 제공한다. 따라서 “키-값 DB는 다중 문서 트랜잭션을 못 한다”는 식으로 분류하지 않는다. 트랜잭션 범위, 지원 SDK, 내구성 설정과 시간 제한을 실제 사용 버전에서 확인한다.
5. 모바일 오프라인 동기화는 별도 제품 범위다
Couchbase의 모바일 구성은 Couchbase Lite와 Sync Gateway 등을 함께 검토하는 영역이다. 서버만 설치했다고 오프라인 동기화가 완성되지는 않는다. 기기 저장소, 인증·접근 정책, 충돌 해결과 동기화 토폴로지를 설계해야 한다.
MongoDB의 Atlas Device Sync는 2025-09-30에 지원이 종료됐다. Realm이라는 로컬 데이터베이스와 종료된 클라우드 동기화 서비스를 구분해야 한다. Realm을 사용한다는 이유로 기존 Atlas 동기화 기능이 계속 제공된다고 안내하면 안 된다.
Redis 서버 자체를 모바일 로컬 저장소와 자동 동기화 플랫폼으로 비교하는 것도 범위가 다르다. 오프라인 기능이 핵심이라면 서버 DB의 단일 질의 속도보다 충돌 모델, 로컬 질의, 배터리·네트워크 사용, 운영 지원을 먼저 평가한다.
6. MongoDB + Redis와 Couchbase를 비교하는 방법
MongoDB에 원본 문서를 두고 Redis에 자주 읽는 값을 캐시하는 구성을 선택할 수 있다. 대신 캐시 무효화, 만료, 쓰기 후 반영 지연, 두 저장소의 장애를 관리해야 한다. 캐시 적중률만 보고 전체 설계가 단순하다고 판단하지 않는다.
Couchbase로 KV와 문서 질의를 통합하는 구성도 검토할 수 있다. 제품 수가 줄어드는 장점이 있더라도 인덱스, 복제, 쿼리 서비스, 백업과 모바일 구성의 운영 비용이 사라지는 것은 아니다. 동일한 업무 기능과 복구 목표를 놓고 비교해야 한다.
| 상황 | 먼저 검토할 방향 | 결정 전에 확인할 것 |
|---|---|---|
| 유연한 상품 문서와 집계 | MongoDB의 문서 모델·인덱스·집계 | 문서 경계, 조회 계획, 트랜잭션 요구 |
| 세션·캐시·랭킹·짧은 수명 상태 | Redis 자료구조와 만료 정책 | 메모리 비용, 명령 복잡도, 유실 허용 여부 |
| 키 조회와 SQL 계열 문서 질의 병행 | Couchbase KV·SQL++ | 인덱스 최신성, 서비스별 자원과 운영 경험 |
| 모바일 오프라인 우선 기능 | 지원 중인 동기화 제품 생태계 | 충돌 해결, 기기 지원, 인증·비용·장기 지원 |
| 여러 저장소의 운영 부담 감소 | 단일화한 구성의 실증 평가 | 잃는 기능, 이전 비용, 복구·확장 절차 |
이 표는 후보를 좁히는 기준이다. “최상·보통·부적합” 점수를 제품 전체에 붙이는 방식은 워크로드와 보장 수준을 숨기기 쉽다.
7. 측정 조건을 맞춰야 비교가 된다
비교 실험에는 제품·SDK 버전, 에디션, 노드 수와 사양, 인덱스, 데이터 크기, 읽기·쓰기 비율, 캐시 상태, 복제·내구성 설정을 기록한다. 약한 쓰기 보장을 사용한 결과와 디스크·다수 복제본 확인을 기다린 결과를 그대로 비교하지 않는다.
처리량 외에도 p95·p99 지연, 오류율, 장애 전환 시간, 복구 후 유실·중복 여부, 백업 복원 시간, 운영 인력과 비용을 본다. CAP은 네트워크 분할 시의 보장과 가용성을 논하는 틀이며, 제품 전체에 CP/AP 꼬리표를 붙여 모든 연산을 설명하는 도구는 아니다.
선택은 “어느 DB가 더 좋은가”보다 어떤 데이터와 연산에 어떤 보장을 요구하는가에서 시작한다. 그 요구를 만족하는 구성끼리 비교해야 성능과 비용에 대한 결론도 재현할 수 있다.
