NoSQL의 등장 배경

모든 데이터를 RDB에 넣어야 하나요? — 트래픽 규모, 데이터 구조, 일관성 요구 수준에 따라 최적의 선택이 달라집니다.

NoSQL은 관계형 데이터베이스만으로는 다루기 어려운 문제를 해결하기 위해 등장한 여러 데이터베이스 계열을 묶어 부르는 말입니다. 2000년대 중후반 대규모 인터넷 서비스에서 수평 확장, 대량 쓰기, 유연한 스키마 요구가 커지면서 널리 알려졌고, 현재는 서비스 규모와 데이터 모델에 따라 RDB와 함께 선택됩니다.

관계형 데이터베이스의 성공과 한계

RDB가 성공한 이유

관계형 데이터베이스는 1970년 에드거 코드(Edgar F. Codd)의 논문에서 시작되어 50년 넘게 데이터 관리의 표준으로 자리 잡았습니다.

RDB의 확장 한계

관계형 데이터베이스는 수십 년간 데이터 저장의 표준이었습니다. 하지만 대규모 트래픽과 비정형 데이터가 폭발적으로 증가하면서 한계가 드러났습니다.

확장 방식	설명	전통적 RDB에서의 난점
스케일 업 (Scale Up)	서버 성능을 높임 (CPU, RAM 추가)	단순하지만 장비 한계와 비용 증가가 큼
스케일 아웃 (Scale Out)	서버 수를 늘림 (분산)	조인, 트랜잭션, 일관성 조율이 복잡해짐

RDB에서 스케일 아웃이 어려운 이유

새로운 데이터 요구사항

2000년대 이후, 기존 RDB로는 처리하기 어려운 새로운 유형의 데이터가 급증했습니다.

RDB에 맞지 않는 데이터 유형

* 소셜 미디어 게시물 — 스키마가 자주 변함
  사진, 동영상, 리액션, 댓글, 공유... 계속 새로운 필드 추가

* IoT 센서 데이터 — 초당 수만 건 쓰기
  온도, 습도, 위치... 시간 순서로 쌓이기만 함

* 사용자 세션/캐시 — 단순 키-값 조회
  복잡한 관계 불필요, 빠른 읽기/쓰기만 중요

* 소셜 네트워크 관계 — 복잡한 그래프 구조
  "친구의 친구의 친구" 같은 다단계 관계 탐색은 그래프 모델이 더 자연스러울 수 있음

* 상품 카탈로그 — 카테고리마다 속성이 다름
  전자제품: 화면크기, 배터리, CPU
  의류: 사이즈, 색상, 소재
  → 정규화, EAV, JSON/문서 모델 중 선택 필요

NoSQL의 탄생

Not Only SQL

오늘날 NoSQL은 보통 Not Only SQL(SQL만이 아닌)의 의미로 이해합니다. 관계형 모델을 부정하는 것이 아니라, 특정 데이터 모델과 확장 방식에 더 적합한 대안을 함께 선택한다는 뜻입니다.

NoSQL의 공통 특성

CAP 정리

CAP 정리(CAP Theorem)는 에릭 브루어(Eric Brewer)가 2000년에 제시한 분산 시스템의 핵심 관찰이며, 이후 Gilbert와 Lynch가 형식화했습니다. 네트워크 분할이 발생한 상황에서는 일관성과 가용성 사이의 선택이 필요하다는 것이 핵심입니다.

속성	영문	설명
일관성	Consistency	모든 노드가 같은 데이터를 보여줌
가용성	Availability	모든 요청이 응답을 받음
분할 내성	Partition Tolerance	네트워크 단절에도 시스템 동작

각 선택의 의미

CP (일관성 + 분할 내성) 예시

노드 A와 노드 B 사이 네트워크 단절 발생!

CP 시스템의 동작
  사용자 → 노드 A에 쓰기 요청
  노드 A: "노드 B에 복제할 수 없으므로 쓰기를 거부합니다"
  → 일관성 유지, 가용성 희생

  은행 시스템에 적합
  잔액이 다른 노드에서 다르게 보이면 큰 문제!

선택 경향	의미	적합한 경우 예시
일관성 우선	일부 요청을 거절하더라도 최신성/정합성 우선	금융, 재고, 예약
가용성·지연 시간 우선	일시적 불일치를 허용하고 응답 지속	피드, 로그, 추천, 캐시
단일 노드 또는 비분산	네트워크 분할을 설계 전제로 두지 않음	작은 서비스, 단일 인스턴스 업무

CAP 정리의 현실적 해석

실제로는 CAP의 경계가 흑백으로 나뉘지 않습니다. MongoDB, Cassandra, DynamoDB 같은 현대 시스템은 읽기/쓰기 옵션, quorum, 트랜잭션, 리전 구성에 따라 일관성 수준과 가용성 특성을 조절합니다.

BASE vs ACID

전통적인 RDB는 트랜잭션의 ACID 보장을 중심으로 발전했고, 많은 NoSQL 시스템은 BASE나 최종적 일관성을 통해 확장성과 가용성을 우선했습니다. 다만 최신 NoSQL도 트랜잭션이나 강한 읽기 옵션을 제공할 수 있고, 분산 SQL/NewSQL 계열은 SQL과 ACID를 수평 확장 구조와 결합하려고 합니다.

최종적 일관성의 실제 예시

NoSQL이 적합한 경우 vs 부적합한 경우

NoSQL의 역사적 흐름

구글 Bigtable과 아마존 Dynamo 논문은 NoSQL 흐름의 중요한 기폭제였습니다. Bigtable은 넓은 컬럼/컬럼 패밀리 계열에, Dynamo는 키-값 저장소와 quorum 기반 복제 설계에 큰 영향을 주었습니다.

NewSQL/분산 SQL: ACID + 수평 확장

NoSQL의 수평 확장 아이디어와 RDB의 SQL/ACID 트랜잭션을 결합하려는 계열입니다. Google Spanner, CockroachDB 같은 시스템은 분산 복제와 트랜잭션 조율을 통해 강한 일관성과 확장을 함께 제공하려고 합니다.

NoSQL의 대표 유형 미리보기

NoSQL은 데이터 모델에 따라 대표적으로 키-값, 문서, 컬럼 패밀리, 그래프 계열로 설명합니다. 실제 제품은 여러 모델을 함께 지원하기도 하므로, 여기서는 전체 그림을 먼저 파악합니다.

RDB와 NoSQL 유형별 비교

분산 시스템의 핵심 개념

NoSQL을 이해하려면 분산 시스템의 기본 개념을 알아야 합니다.

샤딩 (Sharding)

데이터를 여러 노드에 수평으로 분할하여 저장하는 기법입니다.

복제 (Replication)

동일한 데이터를 여러 노드에 복사하는 기법입니다. 복제는 동기, 비동기, quorum 방식에 따라 일관성, 지연 시간, 장애 허용 방식이 달라집니다.

핵심 정리

다음 절에서는 NoSQL의 구체적인 유형별 특성(키-값, 문서, 컬럼 패밀리, 그래프)을 다루겠습니다.

목차