NoSQL 3대장 · CAP 정리
Document(MongoDB) · KV(Redis) · Wide-Column(Cassandra) + CAP = 분산 시스템의 숙명.
"왜 Redis를 SQL 대신 쓰지?", "MongoDB vs Postgres 언제?" 판단 기준. CAP 정리를 이해하면 "클라우드 DB가 왜 일시적 불일치를 허용하는지" 감이 잡힌다.
NoSQL은 단일 기술이 아니라 우산 용어. SQL이 아닌 여러 DB를 묶음. 3가지 주요 계열이 있다.
| 유형 | 대표 제품 | 데이터 모양 | 강점 | 약점 |
|---|---|---|---|---|
| Document | MongoDB, Firestore | JSON 문서 | 스키마 유연, 중첩 구조 | 조인·트랜잭션 약함 |
| Key-Value | Redis, DynamoDB | `key → value` | O(1) 초고속 | 복잡 쿼리 불가 |
| Wide-Column | Cassandra, ScyllaDB | 행+수많은 동적 컬럼 | 대규모 쓰기·지리 분산 | 모델링 난이도 |
| Graph | Neo4j | 노드·엣지 | 관계 추적 | 범용성 낮음 |
| Search | Elasticsearch, OpenSearch | 역색인 | 전문 검색·로그 분석 | 주 저장소 부적합 |
| Time-Series | InfluxDB, Timescale | 시간 중심 | 지표·IoT | 범용 CRUD 약함 |
// ━━━ Redis (KV) — 초고속 캐시·세션·큐 ━━━
await redis.set("user:42:name", "짓친"); // 즉시 저장
await redis.get("user:42:name"); // 즉시 조회
await redis.expire("user:42:name", 3600); // 1시간 후 자동 삭제 (세션)
await redis.lpush("queue:jobs", JSON.stringify({ id: 1 })); // 리스트 = 큐
await redis.brpop("queue:jobs", 0); // 블로킹 pop (워커)
await redis.zadd("leaderboard", 1500, "user:42"); // sorted set = 랭킹
await redis.zrevrange("leaderboard", 0, 9); // top 10
// ━━━ MongoDB (Document) — 스키마 유연 ━━━
await db.users.insertOne({
_id: ObjectId(),
name: "짓친",
profile: { age: 25, tags: ["dev", "music"] }, // 중첩 문서
posts: [{ title: "...", likes: 10 }], // 배열 필드
});
await db.users.findOne({ "profile.tags": "dev" });
// ━━━ Postgres + JSONB (실은 관계형 + NoSQL 하이브리드) ━━━
// 실무 기본 선택지. JSONB 컬럼으로 NoSQL 유연성도 확보
// SELECT * FROM users WHERE profile->>'tags' @> '["dev"]';Redis는 "메모리 기반 다기능 자료구조 서버". 캐시 + 큐 + 세션 + 랭킹이 한 서버로 해결. 바이브코더가 두 번째로 자주 만나는 DB.
2026년 실무 현실 — "일단 Postgres". 관계형 + JSONB로 NoSQL 유연성까지 커버. 캐시·세션·큐는 Redis. 전문 검색이 필요하면 Elasticsearch. 셋 조합이 현대 풀스택의 대세.
CAP 정리(CAP Theorem) — 분산 시스템은 세 가지를 모두 만족할 수 없다. ① Consistency(모든 노드 같은 값) ② Availability(항상 응답) ③ Partition tolerance(네트워크 단절 견딤). 분산 시스템에선 P는 전제 → 실제 선택은 CP vs AP.
| 선택 | 의미 | 예시 |
|---|---|---|
| CP (일관성 + 파티션) | 장애 시 거부 응답 | 전통 RDB, ZooKeeper, HBase |
| AP (가용성 + 파티션) | 장애 시 옛 값 응답 (결국 일치) | Cassandra, DynamoDB, Redis Cluster |
| CA | 이론상 | 단일 노드 DB만 가능 (분산 아님) |
Eventual Consistency(결국 일관성) — AP 시스템이 약속하는 것. "지금은 불일치할 수 있지만 시간 지나면 결국 같아진다". Amazon DynamoDB·Cassandra가 표준. 장점: 가용성. 단점: "방금 저장한 게 바로 안 보여요" 사용자 경험.
PACELC 정리 — CAP의 확장. 파티션(P)일 때는 A vs C 선택, 정상(E, Else)일 때는 Latency vs Consistency 선택. 예: DynamoDB는 기본이 PA/EL(가용성+저지연), 강한 일관성 모드는 PA/EC. "느림 vs 최신" 트레이드오프.
바이브코더 선택 가이드. ① 단일 앱·중간 규모 → Postgres(+ JSONB) 하나면 충분. ② 캐시·세션·랭킹·큐 → Redis 추가. ③ 전문 검색 → Elasticsearch. ④ 모바일 실시간 동기화 → Firestore. ⑤ 수십만 TPS + 지리 분산 → Cassandra/DynamoDB.
분산 시스템에서 네트워크 단절 시 일관성과 가용성을 동시에 만족할 수 없다는 원리의 이름은?
Redis는 디스크 DB이므로 캐시 용도로 부적절하다.
"지금은 불일치지만 시간이 지나면 일치한다"는 분산 DB의 일관성 모델 이름은?