NoSQL (CAP, MongoDB, 캐시)
관계형 데이터베이스(RDB)는 50년 가까이 데이터 저장의 표준이었지만, 2000년대 후반부터 그 표준이 모든 영역에 맞지 않는다는 사실이 분명해졌다. 대량의 비정형 로그·실시간 캐시·소셜 네트워크의 그래프 관계 같은 영역에서 RDB의 스키마와 ACID가 오히려 발목을 잡는 경우가 늘었다. 본 글은 이 빈자리를 채우기 위해 등장한 NoSQL의 네 가지 유형, 분산 시스템 설계의 핵심 정리인 CAP 정리, 그리고 가장 자주 만나는 두 NoSQL인 MongoDB와 Redis의 실전 선택 기준을 정리한다(출처: 위키백과 — NoSQL). 제가 4학년 비정형 데이터 처리 수업에서 처음 MongoDB로 뉴스 기사 만 건을 그대로 JSON으로 던져 넣고 인덱스 한 줄만 추가하자 즉시 검색이 돌아가는 모습을 본 후로는 "스키마를 미리 정하지 않아도 되는 자유로움이 만들 수 있는 차이"를 손끝으로 받아들였다.
NoSQL의 네 가지 유형 (키-값, 문서, 컬럼, 그래프)
NoSQL이라는 이름은 "Not Only SQL"의 줄임으로, SQL을 부정한다는 의미가 아니라 SQL이 아닌 데이터 모델도 같이 쓰겠다는 의미로 통한다. 모든 NoSQL은 다음 네 가지 모델 중 하나에 속한다.
첫 번째가 키-값(Key-Value) 모델이다. 가장 단순한 구조로, 키 하나가 값 하나에 대응하는 사전 자료구조를 그대로 데이터베이스로 만든 형태다. Redis·Memcached가 대표적이며, 메모리에 자리 잡아 마이크로초 단위로 응답한다. 캐시·세션 저장소·실시간 카운터 같은 영역에서 표준 도구로 자리 잡았다.
두 번째가 문서(Document) 모델이다. JSON·BSON 같은 중첩 구조 문서를 한 단위로 저장하며, 같은 컬렉션 안에서 문서마다 필드가 달라도 된다. 여기서 컬렉션이란 RDB의 테이블에 대응하는 NoSQL의 데이터 그룹 단위를 가리킨다. MongoDB·Couchbase가 대표이며, 스키마가 자주 바뀌는 초기 서비스·이질적인 로그·콘텐츠 관리 시스템 영역에서 빛을 발한다.
세 번째가 컬럼 패밀리(Column-family) 모델이다. 행 단위가 아닌 컬럼 단위로 디스크에 저장하는 구조이며, 같은 컬럼의 값이 연속적으로 모이기 때문에 대량 집계 쿼리에서 압도적인 압축률과 속도를 낸다. Apache Cassandra·HBase·Google Bigtable이 대표이며, 시계열 데이터·로그 분석·IoT 대량 수집 환경에서 표준이다.
네 번째가 그래프(Graph) 모델이다. 노드와 간선으로 이루어진 그래프 구조를 그대로 저장한다. RDB로는 6단 자기 조인이 필요한 "친구의 친구의 친구" 같은 다단 관계 탐색을 단일 쿼리로 처리한다. Neo4j가 대표이며, 소셜 네트워크·추천·사기 탐지·지식 그래프 영역에서 핵심 도구다.
다만 NoSQL이 만능 해결책이 아니라는 점은 분명하다. 솔직히 제 경험상 입문 단계에서 가장 자주 마주치는 오해가 "NoSQL은 RDB보다 빠르다"인데, 영역별 도구의 성격이 다른 것일 뿐이며 동일한 트랜잭션 워크로드에서는 RDB가 여전히 가장 빠르고 안전한 경우가 흔하다.
CAP 정리 (일관성, 가용성, 분할 내성)
분산 시스템 설계에서 가장 자주 인용되는 정리가 CAP 정리다. 2000년 에릭 브루어(Eric Brewer)가 제안하고 2002년 MIT 연구팀이 증명한 이 정리는 다음 한 줄로 요약된다: 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 세 가지를 동시에 만족할 수 없다(출처: 위키백과 — CAP theorem).
여기서 일관성이란 모든 노드가 같은 시점에 같은 데이터를 보여 주는 성질을, 가용성은 어떤 요청이든 항상 응답을 받는 성질을, 분할 내성은 네트워크가 끊겨 노드 간 통신이 불가능한 상황에서도 시스템이 계속 동작하는 성질을 의미한다. 핵심은 네트워크 분할은 분산 환경에서 사실상 피할 수 없으므로 P는 거의 모든 분산 DB가 선택할 수밖에 없고, 남은 선택지는 C와 A 사이의 트레이드오프라는 점이다.
이 트레이드오프는 다음 두 진영을 만든다. CP 시스템은 네트워크 분할이 생기면 일관성을 지키기 위해 일부 노드의 응답을 거절한다(가용성 희생). MongoDB·HBase·Redis Cluster가 이쪽에 가깝다. AP 시스템은 분할이 생기면 일단 응답을 돌려보내고 나중에 데이터를 맞춘다(일관성 희생). Cassandra·DynamoDB·CouchDB가 대표적이다.
다만 CAP은 분산 시스템 입문 단계에서 자주 과장된다. 흔한 오해 하나를 짚으면 "RDB는 C, NoSQL은 A"라는 단순화인데, 실제 시스템은 그 두 축 위에서 미세한 정도를 조절하며 동작한다. 대부분의 NoSQL은 일관성 수준(Strong·Eventual·Causal 등)을 설정으로 바꿀 수 있고, RDB도 동기·반동기·비동기 복제 모드에 따라 가용성을 다양하게 가져간다. 즉 CAP은 "어느 한쪽을 100% 포기하라"는 절대 명제가 아니라 "한쪽으로 미세 조정될 수밖에 없다"는 트레이드오프 프레임으로 이해해야 한다.
MongoDB와 Redis 실전 선택 기준 (문서 vs 캐시)
마지막으로 가장 자주 만나는 두 NoSQL인 MongoDB와 Redis의 선택 기준을 짚는다. 둘은 같은 NoSQL 묶음으로 묶이지만 사실상 다른 카테고리의 도구다.
MongoDB는 문서 데이터베이스로, 영구 저장이 주 역할이다. 스키마가 자주 바뀌는 초기 서비스·콘텐츠 관리·로그 수집처럼 "지금은 어떤 필드가 있을지 모르겠지만 일단 저장하고 나중에 정리한다"는 영역에서 강하다. 본인이 학교 비정형 데이터 처리 수업에서 뉴스 기사를 그대로 던져 넣을 때 가장 빛을 본 것이 이 유연함이었다. 다만 그 유연함의 대가가 데이터 일관성에 대한 책임이 애플리케이션으로 옮겨 온다는 점이며, 스키마가 결국 안정되는 시점에는 RDB로의 이전을 고민하게 된다.
Redis는 인메모리 키-값 저장소로, 캐시·실시간 카운터·세션 저장소·메시지 큐가 주 역할이다(출처: Redis 공식 문서). 디스크가 아닌 메모리에 자리 잡아 응답 시간이 마이크로초 단위이며, 단일 노드로도 초당 수십만 건의 요청을 처리한다. 다만 메모리가 곧 한계이므로 영구 저장소로 쓰는 것이 아니라 "RDB·MongoDB 앞단의 가속기"로 쓰는 것이 표준 패턴이다.
선택 기준을 한 줄로 정리하면, 저장이 주 역할이면 MongoDB, 캐시·실시간이 주 역할이면 Redis, 그리고 RDB로 충분히 풀리는 워크로드면 RDB 그대로다. 솔직히 이건 시험엔 자주 안 나오지만 실무에서 가장 자주 의사결정이 필요한 지점이다. NoSQL을 도입하는 결정은 "더 빠른 도구"를 찾는 결정이 아니라 "지금 풀려는 문제의 모양이 어떤 데이터 모델에 가장 잘 맞는가"를 묻는 결정에 가깝고, 그 질문에 정확히 답할 수 있을 때 비로소 NoSQL의 유형 선택이 손에 잡힌다.