NoSQL 개요 — 문서·키밸류·컬럼·그래프, 언제 RDB 대신 쓰나

“NoSQL 쓸까요?”라는 질문에는 대개 잘못된 전제가 깔려 있다. NoSQL은 하나의 기술이 아니라, 관계형 모델을 벗어난 서로 다른 저장소들의 묶음이다. 문서·키값·컬럼 패밀리·그래프는 데이터 모델도 다르고 잘 맞는 문제도 다르다. 이 글은 네 유형이 각각 무엇에 강한지, 그리고 RDB 대신 언제 꺼내 드는지를 스키마·조인·확장·일관성 기준으로 정리한다.

1. NoSQL은 왜 나왔나

관계형 DB는 40년 넘게 데이터 저장의 기본값이었다. 정규화된 스키마, 조인, ACID 트랜잭션은 여전히 대부분의 업무 시스템에 최적이다. 그런데 2000년대 후반 대형 웹 서비스가 부딪힌 두 벽이 있었다.

• 스키마 경직성 — 컬럼 하나 추가하려면 ALTER TABLE이 걸리고, 수억 행 테이블에서는 이게 곧 장애 위험이다. 제품 카탈로그처럼 항목마다 속성이 제각각인 데이터를 정규화 테이블에 욱여넣으면 조인 지옥이 된다.
• 수평 확장의 한계 — RDB는 강한 일관성과 조인을 보장하려고 단일 노드에 최적화돼 있다. 트래픽이 한 대의 서버 용량을 넘으면, 더 큰 장비로 갈아타는 수직 확장(scale-up)이 기본 카드다. 여러 대로 나눠 담는 수평 확장(scale-out)은 샤딩·분산 트랜잭션이라는 어려운 문제를 부른다.

NoSQL은 “Not Only SQL”의 약자다. SQL을 부정하는 게 아니라, 관계형 모델이 유일한 답은 아니다라는 뜻이다. 각 제품은 특정 트레이드오프를 의도적으로 선택한다. 조인을 포기하고 수평 확장을 얻거나, 강한 일관성을 완화하고 가용성을 얻는 식이다.

NoSQL의 본질은 “SQL을 안 쓴다”가 아니라 “관계형이 강제하던 제약(고정 스키마·단일 노드 조인·강한 일관성) 중 일부를 놓아주고, 그 대가로 유연성이나 확장성을 얻는다”는 것이다.

2. 네 가지 유형

2-1. 문서 (Document)

데이터를 JSON(내부적으로는 BSON 등) 문서 단위로 저장한다. 한 문서 안에 중첩 객체·배열을 담을 수 있어, 애플리케이션의 객체 구조를 그대로 저장하기 좋다.

{
  "_id": "u-1024",
  "name": "김개발",
  "addresses": [
    { "type": "home", "city": "서울" },
    { "type": "work", "city": "성남" }
  ],
  "tags": ["premium", "beta"]
}

RDB라면 users / addresses / user_tags 세 테이블에 조인으로 흩어질 데이터가 문서 하나에 모인다. 스키마가 문서마다 달라도 되기 때문에, 항목마다 속성이 다른 데이터(제품 카탈로그, CMS 콘텐츠, 사용자 프로필)에 잘 맞는다.

• 대표 제품: MongoDB, Couchbase, Amazon DocumentDB
• 적합 사례: 반정형 데이터, 스키마가 자주 바뀌는 초기 서비스, 애그리거트(하나로 읽고 쓰는 덩어리) 중심 도메인
• 오해 주의: 예전엔 “MongoDB는 트랜잭션이 없다”는 말이 정설이었지만, MongoDB는 4.0(2018)부터 멀티문서 ACID 트랜잭션을, 4.2부터 샤딩 클러스터를 가로지르는 분산 트랜잭션을 지원한다. 지금은 “트랜잭션이 없어서 못 쓴다”가 아니라 “트랜잭션을 최대한 안 쓰도록 애그리거트를 설계한다”가 맞는 표현이다.

2-2. 키-값 (Key-Value)

가장 단순한 모델이다. 키로 값을 넣고 키로 값을 꺼낸다. 값의 내부 구조는 저장소가 신경 쓰지 않는다. 조회 경로가 키 하나로 고정돼 있어 지연 시간이 극도로 짧다.

SET session:9f3a  {"userId":1024,"exp":1751...}
GET session:9f3a

• 대표 제품: Redis(인메모리), Amazon DynamoDB, Riak
• 적합 사례: 세션 저장소, 캐시, 실시간 순위표, 레이트 리밋 카운터처럼 “키로 찍어 초고속으로 읽고 쓰는” 워크로드
• 참고: DynamoDB는 키-값이자 문서형 성격을 겸하고, Redis는 문자열뿐 아니라 리스트·셋·정렬셋·해시 같은 자료구조를 값으로 제공해 단순 키-값을 넘어선다. 유형 경계는 제품마다 흐릿하다.

2-3. 컬럼 패밀리 (Wide-Column)

행마다 컬럼 구성이 다를 수 있는 희소한 대형 테이블이다. 파티션 키로 데이터를 노드에 분산하고, 클러스터링 키로 파티션 내부를 정렬 저장한다. 대량 쓰기와 시계열에 강하다.

파티션키(sensor_id) | 클러스터링키(ts)       | value
--------------------+-----------------------+------
sensor-01           | 2026-07-03T10:00:00   | 21.4
sensor-01           | 2026-07-03T10:00:01   | 21.5

쓰기를 로그처럼 순차 반영하고 여러 노드에 복제·분산하는 구조라, 초당 수십만 건 쓰기 같은 부하를 수평 확장으로 받아낸다. 대신 쿼리는 미리 정한 파티션·클러스터링 키 경로에 갇힌다. 임의 컬럼 조건 검색이나 조인은 약하다 — 쿼리를 먼저 정하고 테이블을 그에 맞춰 설계하는 사고가 필요하다.

• 대표 제품: Apache Cassandra, ScyllaDB, HBase, Google Bigtable
• 적합 사례: IoT 센서·로그·메트릭 같은 시계열, 이벤트 스트림, 대규모 쓰기 인입

2-4. 그래프 (Graph)

데이터를 노드(정점)와 관계(엣지)로 저장한다. 핵심은 관계 자체를 1급 데이터로 다룬다는 것이다. RDB에서 다단계 조인으로 표현할 “친구의 친구의 친구”, “이 계좌에서 3단계 안에 닿는 계좌”를 그래프 탐색으로 값싸게 훑는다.

(김개발)-[:FOLLOWS]->(박서버)-[:FOLLOWS]->(이디비)

RDB에서 N단계 관계 탐색은 조인이 N번 겹치며 비용이 폭발한다. 그래프 DB는 각 노드가 인접 노드로의 포인터를 직접 들고 있어(index-free adjacency), 탐색 비용이 전체 데이터 크기가 아니라 실제 훑는 이웃 수에 비례한다.

• 대표 제품: Neo4j, Amazon Neptune, JanusGraph
• 적합 사례: 소셜 그래프, 추천 엔진, 사기 탐지, 지식 그래프, 네트워크/의존성 분석

유형 한눈에 비교

유형	데이터 모델	대표 제품	강점	약한 지점
문서	중첩 JSON 문서	MongoDB, Couchbase	스키마 유연, 애그리거트 저장	문서 간 복잡 조인
키-값	키 → 불투명 값	Redis, DynamoDB	단순 조회 초고속	값 내부 조건 검색
컬럼 패밀리	희소 대형 테이블	Cassandra, HBase	대량 쓰기·시계열·수평 확장	임의 조건 검색, 조인
그래프	노드+엣지	Neo4j, Neptune	다단계 관계 탐색	대량 집계·스캔

3. RDB vs NoSQL — 판단 기준

“NoSQL이 더 빠르다/현대적이다”는 이유로 고르면 대개 후회한다. 다음 축으로 판단한다.

기준	RDB 쪽으로	NoSQL 쪽으로
스키마 안정성	구조가 안정적·정형	항목마다 속성이 제각각·자주 변함
조인 필요성	여러 엔티티를 자유롭게 조합	애그리거트 단위로 읽고 씀, 조인 거의 없음
트랜잭션 강도	여러 행 걸친 강한 원자성 필수(금융)	단일 문서/키 원자성으로 충분
확장 방식	한 대로 감당 가능, 수직 확장	단일 노드 한계 초과, 수평 확장 필수
일관성 요구	항상 최신값 읽어야 함	약간의 지연·불일치 허용 가능
쿼리 유연성	임의 조건·집계·애드혹 분석	쿼리 경로가 고정적

정리하면, 정형 데이터 + 조인 + 강한 트랜잭션 + 애드혹 쿼리면 RDB가 기본값이다. 거대한 규모 + 유연한 스키마 + 고정된 접근 경로 + 확장 우선이면 NoSQL이 후보에 오른다. 규모가 크지 않다면 PostgreSQL 하나로 대부분 해결되고, PostgreSQL은 JSONB로 문서형 워크로드까지 상당 부분 흡수한다는 점도 기억해 둘 것.

4. 일관성 모델 — ACID vs BASE

RDB의 트랜잭션은 ACID를 지향한다. 원자성(Atomicity)·일관성(Consistency)·격리성(Isolation)·지속성(Durability). “커밋된 것은 모든 후속 읽기에 즉시 보인다”는 강한 보장이다.

여러 노드로 분산된 NoSQL은 흔히 BASE를 택한다.

• Basically Available — 일부 노드가 죽어도 시스템은 응답을 돌려준다(가용성 우선).
• Soft state — 외부 입력 없이도 복제가 전파되며 상태가 변할 수 있다.
• Eventual consistency(최종 일관성) — 새 쓰기가 없다면, 시간이 지나 모든 복제본이 결국 같은 값으로 수렴한다. “지금 당장 모든 노드가 같은 값”은 보장하지 않는다.

최종 일관성의 대가로 얻는 건 낮은 지연과 높은 가용성이다. 쓰기 직후 다른 노드에서 읽으면 이전 값이 나올 수 있으므로, 이 창을 견딜 수 있는 도메인(타임라인, 좋아요 수, 조회수)에서 값어치가 있다. 반대로 잔고·재고처럼 어긋나면 안 되는 값에는 위험하다.

CAP과의 연결

이 트레이드오프의 이론적 뿌리가 CAP 정리다. 네트워크 분단(P)은 분산 시스템에서 피할 수 없이 주어지므로, 분단이 발생한 순간 일관성(C)과 가용성(A) 중 하나를 포기해야 한다. 최종 일관성을 택한 NoSQL은 분단 상황에서 가용성을 지키고 일관성을 늦춘 것(AP 성향)이다.

단, “NoSQL = 최종 일관성”은 과한 단순화다. 요즘 저장소 다수는 일관성을 조절할 수 있다.

• DynamoDB: 기본은 최종 일관성 읽기지만, 요청에 ConsistentRead=true를 주면 강한 일관성 읽기가 된다(지연·비용은 올라감).
• Cassandra: 요청마다 정족수(QUORUM, ONE, ALL 등)를 지정해, 읽기 정족수 + 쓰기 정족수 > 복제 수를 만족시키면 강한 일관성을 얻는다.
• MongoDB: writeConcern과 readConcern으로 내구성·일관성 수준을 요청 단위로 조절한다.

즉 최신 NoSQL은 “약한 일관성 고정”이 아니라, 일관성을 요청 단위로 사고 파는 다이얼을 준다.

ACID vs BASE는 이분법이 아니라 스펙트럼이다. RDB도 격리 수준을 낮출 수 있고, NoSQL도 강한 읽기를 켤 수 있다. 핵심은 “이 읽기/쓰기가 최신값을 반드시 봐야 하는가?”를 데이터 항목별로 결정하는 것.

5. 폴리글랏 퍼시스턴스

현실의 서비스는 하나의 저장소로 통일되지 않는다. 한 서비스 안에서도 데이터마다 성격이 달라, 각각에 맞는 저장소를 섞어 쓰는 게 자연스럽다. 이를 폴리글랏 퍼시스턴스(polyglot persistence)라 한다.

예를 들어 이커머스 하나에서도 이렇게 나뉜다.

• 주문·결제·재고 → PostgreSQL (강한 트랜잭션, 조인)
• 상품 카탈로그 → MongoDB (항목마다 다른 속성)
• 세션·장바구니·캐시 → Redis (초고속 키-값)
• 클릭·이벤트 로그 → Cassandra (대량 쓰기 시계열)
• 상품 추천 → Neo4j (관계 탐색)

여기서 중요한 관점 전환.

NoSQL은 RDB를 대체하는 후계자가 아니다. 각자 잘하는 문제가 다른 도구다. 결제는 RDB가, 추천 그래프는 Neo4j가, 세션은 Redis가 맡는다. 선택 기준은 “무엇이 최신인가”가 아니라 “이 데이터의 접근 패턴·일관성 요구에 무엇이 맞는가”다.

물론 저장소를 늘리면 운영·백업·정합성 관리 비용도 함께 는다. 규모가 작다면 저장소 하나로 버티다가, 특정 데이터가 명확히 다른 저장소를 요구할 때 분리하는 게 건강하다.

6. 흔한 오해 — 스키마리스 ≠ 설계 불필요

NoSQL을 처음 쓸 때 가장 위험한 착각이 “스키마가 없으니 설계도 필요 없다”는 것이다. 정반대에 가깝다.

• RDB는 스키마를 DB가 강제한다. 잘못 넣으면 DB가 막아준다.
• NoSQL은 스키마를 애플리케이션이 책임진다. DB가 막아주지 않으므로, 문서 구조·키 설계를 개발자가 규율해야 한다. 방치하면 같은 컬렉션 안에 필드명이 제각각인 문서가 쌓이고, 결국 읽는 쪽 코드가 온갖 예외를 떠안는다.

게다가 NoSQL 설계는 쿼리 주도(query-first)다. RDB가 정규화로 데이터를 먼저 정리한 뒤 조인으로 조합한다면, NoSQL은 “이 데이터를 어떻게 읽을 것인가”를 먼저 정하고 그 접근 경로에 맞춰 데이터를 배치·중복(비정규화)한다. Cassandra에서 파티션 키를 잘못 잡으면 특정 노드에 부하가 쏠리는 핫스팟이 생기고, MongoDB에서 애그리거트 경계를 잘못 그으면 문서가 무한정 커지거나 불필요한 트랜잭션이 늘어난다.

“스키마리스”는 스키마 결정을 DB에서 애플리케이션으로 옮긴 것이지, 없앤 게 아니다. NoSQL은 설계를 덜 하는 게 아니라, 접근 패턴을 먼저 확정하는 다른 종류의 설계를 요구한다.

관련 글

글	요약
CAP 정리 — P는 고르는 게 아니라 주어진다	NoSQL이 택하는 일관성·가용성 트레이드오프의 이론
분산 DB 확장 — 샤딩·분산 트랜잭션·합의	NoSQL이 수평 확장에 강한 이유 — 샤딩·복제