RDBMS vs NoSQL 완벽 비교: 선택 기준부터 CAP 이론, 실무 사례까지
“왜 이 프로젝트에서 MySQL 대신 MongoDB를 썼나요?”, “CAP 이론이 뭔가요?” — RDBMS와 NoSQL의 차이와 선택 기준은 신입 백엔드 면접의 단골 주제다. 단순히 “관계형이냐 아니냐”가 아니라, 데이터 모델·확장성·일관성 관점에서 왜 그 선택을 했는지 설명할 수 있어야 한다.
1. RDBMS란
1.1 핵심 특징
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| ┌─────────────────────────────────────────────────────────────────────┐
│ RDBMS 핵심 특징 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 정형 스키마 (Structured Schema) │
│ → 테이블 생성 시 컬럼·타입을 미리 정의 │
│ → ALTER TABLE 없이는 구조 변경 불가 │
│ │
│ 2. SQL (Structured Query Language) │
│ → 표준화된 질의 언어로 데이터 조작 │
│ → JOIN, 서브쿼리, 집계 등 강력한 질의 가능 │
│ │
│ 3. ACID 트랜잭션 │
│ → Atomicity : 전부 성공 or 전부 실패 │
│ → Consistency : 트랜잭션 전후 데이터 무결성 보장 │
│ → Isolation : 동시 트랜잭션 간 간섭 없음 │
│ → Durability : 커밋된 데이터는 영구 보존 │
│ │
│ 4. 정규화 & 관계 │
│ → 데이터 중복 최소화 │
│ → FK로 테이블 간 관계 정의 │
│ │
│ 대표 DB: MySQL, PostgreSQL, Oracle, MariaDB │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
1.2 RDBMS가 강한 영역
- 금융/결제: 잔고 정합성 → ACID 필수
- 주문/재고: 동시성 제어 + 트랜잭션
- 관계가 복잡한 도메인: 다양한 JOIN이 필요한 경우
- 데이터 정합성이 최우선인 시스템
2. NoSQL이란
2.1 NoSQL의 등장 배경
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| ┌─────────────────────────────────────────────────────────────────────┐
│ 왜 NoSQL이 필요해졌는가 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 데이터 폭증 │
│ → SNS, IoT, 로그 등 비정형 대용량 데이터 │
│ → RDBMS의 수직 확장(Scale-Up)만으로는 한계 │
│ │
│ 2. 유연한 스키마 필요 │
│ → 서비스 초기엔 스키마가 자주 변경됨 │
│ → ALTER TABLE은 대용량 테이블에서 매우 느림 │
│ │
│ 3. 수평 확장(Scale-Out) │
│ → 서버를 추가해서 처리량을 늘리는 구조 필요 │
│ → RDBMS의 JOIN은 분산 환경에서 비용이 큼 │
│ │
│ 4. 고가용성 & 낮은 지연시간 │
│ → 글로벌 서비스에서 항상 응답 가능해야 함 │
│ │
│ NoSQL = Not Only SQL (SQL만이 답은 아니다) │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
2.2 NoSQL 유형별 비교
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| ┌─────────────────────────────────────────────────────────────────────┐
│ NoSQL 4가지 유형 │
├───────────────┬─────────────────────────────────────────────────────┤
│ 유형 │ 특징 │
├───────────────┼─────────────────────────────────────────────────────┤
│ │ • key로 value 조회 (가장 단순) │
│ Key-Value │ • 초고속 읽기/쓰기 │
│ │ • 캐시, 세션 저장에 최적 │
│ │ • 대표: Redis, Memcached, DynamoDB │
├───────────────┼─────────────────────────────────────────────────────┤
│ │ • JSON/BSON 형태의 문서 저장 │
│ Document │ • 스키마 유연 (필드 자유 추가) │
│ │ • 중첩 구조 표현에 강함 │
│ │ • 대표: MongoDB, CouchDB │
├───────────────┼─────────────────────────────────────────────────────┤
│ │ • 행 키 + 컬럼 패밀리 구조 │
│ Column-Family │ • 대규모 쓰기에 최적화 │
│ │ • 시계열, 로그, 분석 데이터에 적합 │
│ │ • 대표: Cassandra, HBase │
├───────────────┼─────────────────────────────────────────────────────┤
│ │ • 노드(Node)와 관계(Edge)로 데이터 표현 │
│ Graph │ • 관계 탐색이 매우 빠름 │
│ │ • SNS 친구관계, 추천 시스템에 적합 │
│ │ • 대표: Neo4j, Amazon Neptune │
└───────────────┴─────────────────────────────────────────────────────┘
|
3. CAP 이론
3.1 CAP 정리
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| ┌─────────────────────────────────────────────────────────────────────┐
│ CAP 이론 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 분산 시스템에서 아래 3가지를 동시에 만족할 수 없다. │
│ 최대 2가지만 선택 가능하다. │
│ │
│ C (Consistency) │
│ 일관성: 모든 노드가 │
│ 같은 데이터를 봄 │
│ /\ │
│ / \ │
│ / \ │
│ / CA \ CP │
│ / 영역 \ 영역 │
│ / \ │
│ /____________\ │
│ A (Availability) P (Partition Tolerance) │
│ 가용성: 항상 분단 내성: 네트워크 │
│ 응답을 반환 단절에도 동작 │
│ \ / │
│ \ AP / │
│ \ 영역 / │
│ \_______/ │
│ │
│ ※ 실제 분산 환경에서 P(네트워크 분단)는 피할 수 없으므로 │
│ 현실적으로는 CP vs AP 선택이 된다 │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
3.2 DB별 CAP 분류
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| ┌─────────────────────────────────────────────────────────────────────┐
│ CAP 분류별 DB │
├──────────┬──────────────────────┬────────────────────────────────────┤
│ 분류 │ 특징 │ 대표 DB │
├──────────┼──────────────────────┼────────────────────────────────────┤
│ CP │ 일관성 + 분단 내성 │ MongoDB, HBase, Redis(Cluster) │
│ │ → 네트워크 문제 시 │ Zookeeper │
│ │ 가용성 포기 │ │
├──────────┼──────────────────────┼────────────────────────────────────┤
│ AP │ 가용성 + 분단 내성 │ Cassandra, DynamoDB, CouchDB │
│ │ → 네트워크 문제 시 │ │
│ │ 일관성 일시 포기 │ (Eventual Consistency) │
├──────────┼──────────────────────┼────────────────────────────────────┤
│ CA │ 일관성 + 가용성 │ 전통 RDBMS (단일 노드) │
│ │ → 분산하지 않으면 │ MySQL, PostgreSQL │
│ │ P가 불필요 │ (단, 분산 시 CP 쪽) │
└──────────┴──────────────────────┴────────────────────────────────────┘
|
4. ACID vs BASE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ┌─────────────────────────────────────────────────────────────────────┐
│ ACID vs BASE 비교 │
├──────────────────┬──────────────────────────────────────────────────┤
│ ACID (RDBMS) │ BASE (NoSQL) │
├──────────────────┼──────────────────────────────────────────────────┤
│ Atomicity │ Basically Available │
│ 원자성 │ 기본적으로 가용 (항상 응답) │
├──────────────────┼──────────────────────────────────────────────────┤
│ Consistency │ Soft state │
│ 일관성 │ 상태가 시간에 따라 변할 수 있음 │
├──────────────────┼──────────────────────────────────────────────────┤
│ Isolation │ Eventually consistent │
│ 격리성 │ 최종적으로 일관성 달성 │
├──────────────────┼──────────────────────────────────────────────────┤
│ Durability │ │
│ 지속성 │ │
├──────────────────┼──────────────────────────────────────────────────┤
│ → 강한 일관성 │ → 높은 가용성 + 성능 │
│ → 금융, 결제 │ → SNS, 로그, 캐시 │
└──────────────────┴──────────────────────────────────────────────────┘
|
5. RDBMS vs NoSQL 핵심 비교
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| ┌─────────────────────────────────────────────────────────────────────┐
│ RDBMS vs NoSQL 비교표 │
├──────────────┬──────────────────────┬────────────────────────────────┤
│ 항목 │ RDBMS │ NoSQL │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 데이터 모델 │ 테이블 (행/열) │ 문서, Key-Value, 그래프 등 │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 스키마 │ 고정 (사전 정의) │ 유연 (스키마리스) │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 확장 방식 │ 수직 확장 (Scale-Up) │ 수평 확장 (Scale-Out) │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 트랜잭션 │ ACID (강력) │ BASE (최종 일관성) │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 질의 언어 │ SQL (표준화) │ 각 DB마다 다름 │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ JOIN │ 자유롭게 가능 │ 불가 또는 제한적 │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 정규화 │ 정규화로 중복 제거 │ 비정규화 (데이터 중복 허용) │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 일관성 │ 강한 일관성 │ 최종 일관성 (설정에 따라 강) │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 읽기 성능 │ 인덱스 기반 빠름 │ Key 기반 초고속 (캐시형) │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 쓰기 성능 │ 보통 │ 대량 쓰기에 강함 │
├──────────────┼──────────────────────┼────────────────────────────────┤
│ 적합한 데이터│ 정형, 관계가 복잡 │ 비정형, 대용량, 빈번한 변경 │
└──────────────┴──────────────────────┴────────────────────────────────┘
|
6. 실무 선택 기준
6.1 RDBMS를 선택해야 할 때
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| ┌─────────────────────────────────────────────────────────────────────┐
│ RDBMS가 적합한 경우 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ✓ 데이터 정합성이 최우선 │
│ → 결제, 송금, 재고 관리 │
│ │
│ ✓ 데이터 간 관계가 복잡하고 JOIN이 많이 필요 │
│ → 주문-상품-회원-배송 관계 │
│ │
│ ✓ 스키마가 안정적이고 잘 변하지 않음 │
│ → 이미 도메인이 확정된 서비스 │
│ │
│ ✓ 복잡한 조건 검색, 집계, 리포트 │
│ → GROUP BY, HAVING, 윈도우 함수 등 │
│ │
│ ✓ 트랜잭션 단위의 롤백이 필수 │
│ → 주문 생성 + 재고 차감 + 결제를 하나의 단위로 │
│ │
│ 예시: 쇼핑몰, 은행, ERP, 예약 시스템 │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
6.2 NoSQL을 선택해야 할 때
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| ┌─────────────────────────────────────────────────────────────────────┐
│ NoSQL이 적합한 경우 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ✓ 대용량 데이터의 빠른 읽기/쓰기 │
│ → 초당 수만 건 이상의 처리 │
│ │
│ ✓ 스키마가 자주 변경되거나 비정형 데이터 │
│ → 로그, 사용자 행동 데이터, 센서 데이터 │
│ │
│ ✓ 수평 확장이 필수인 대규모 서비스 │
│ → 글로벌 서비스, 수억 건 이상 데이터 │
│ │
│ ✓ 단순한 조회 패턴 (Key로 조회) │
│ → 캐시, 세션, 설정값 저장 │
│ │
│ ✓ 최종 일관성으로 충분한 도메인 │
│ → SNS 피드, 좋아요 수, 조회수 │
│ │
│ 예시: 채팅, 실시간 피드, 로그 수집, 추천 시스템 │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
6.3 혼합 사용 (Polyglot Persistence)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| ┌─────────────────────────────────────────────────────────────────────┐
│ 실무에서의 혼합 사용 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 실제 서비스에서는 하나의 DB만 쓰지 않는다! │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ MySQL │ │ Redis │ │ MongoDB │ │
│ │ (주문/결제) │ │ (캐시/세션) │ │ (로그/검색) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └────────────────────┼────────────────────┘ │
│ │ │
│ ┌─────────┴─────────┐ │
│ │ Application │ │
│ │ (Spring Boot) │ │
│ └───────────────────┘ │
│ │
│ 예시: │
│ • 주문/결제 → MySQL (ACID 필수) │
│ • 인증 토큰/세션 → Redis (빠른 만료 관리) │
│ • 상품 검색 → Elasticsearch (전문 검색) │
│ • 사용자 활동 로그 → MongoDB (유연한 스키마) │
│ • 추천 관계 → Neo4j (그래프 탐색) │
│ │
└─────────────────────────────────────────────────────────────────────┘
|
7. MongoDB vs MySQL 구체 비교
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ┌─────────────────────────────────────────────────────────────────────┐
│ MongoDB vs MySQL 비교 │
├──────────────┬────────────────────┬──────────────────────────────────┤
│ 항목 │ MySQL │ MongoDB │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 저장 단위 │ Row (행) │ Document (문서, BSON) │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 스키마 │ CREATE TABLE 필수 │ 컬렉션에 아무 문서나 저장 가능 │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 관계 표현 │ FK + JOIN │ 임베딩 또는 참조 ($lookup) │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 트랜잭션 │ 완전 지원 │ 4.0부터 멀티 문서 트랜잭션 지원 │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 확장 │ 레플리카 + 샤딩 │ 자체 샤딩 (네이티브) │
│ │ (설정 복잡) │ (비교적 간단) │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 인덱스 │ B-Tree, Hash 등 │ B-Tree, 텍스트, 지리공간 등 │
├──────────────┼────────────────────┼──────────────────────────────────┤
│ 질의 │ SQL │ MQL (find, aggregate) │
└──────────────┴────────────────────┴──────────────────────────────────┘
|
MongoDB Document 예시
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| // RDBMS: 회원 테이블 + 주소 테이블 (정규화, JOIN 필요)
// MongoDB: 하나의 문서에 임베딩
{
"_id": ObjectId("507f1f77bcf86cd799439011"),
"name": "김개발",
"email": "dev@example.com",
"addresses": [
{
"type": "home",
"city": "서울",
"zipcode": "06234"
},
{
"type": "work",
"city": "판교",
"zipcode": "13487"
}
],
"orders": [
{ "product": "키보드", "price": 89000, "date": "2026-03-27" }
]
}
|
정규화 vs 비정규화: RDBMS는 주소를 별도 테이블로 분리하지만, MongoDB는 한 문서에 임베딩해서 JOIN 없이 한 번에 조회한다.
8. Redis 활용 패턴
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| ┌─────────────────────────────────────────────────────────────────────┐
│ Redis 주요 활용 패턴 │
├──────────────────────┬──────────────────────────────────────────────┤
│ 용도 │ 설명 │
├──────────────────────┼──────────────────────────────────────────────┤
│ 캐시 (Cache) │ DB 조회 결과를 캐싱해서 응답 속도 개선 │
│ │ TTL 설정으로 자동 만료 │
├──────────────────────┼──────────────────────────────────────────────┤
│ 세션 저장소 │ 분산 서버 환경에서 세션 공유 │
│ │ Spring Session + Redis │
├──────────────────────┼──────────────────────────────────────────────┤
│ 분산 락 │ Redisson으로 분산 환경 동시성 제어 │
│ │ SET key NX EX (단순 락) │
├──────────────────────┼──────────────────────────────────────────────┤
│ Rate Limiting │ API 호출 횟수 제한 │
│ │ INCR + EXPIRE 조합 │
├──────────────────────┼──────────────────────────────────────────────┤
│ 메시지 큐 │ List의 LPUSH/BRPOP으로 간단한 큐 │
│ │ Stream으로 Kafka-like 처리도 가능 │
├──────────────────────┼──────────────────────────────────────────────┤
│ 랭킹/리더보드 │ Sorted Set으로 실시간 순위 관리 │
│ │ ZADD, ZRANK, ZRANGE │
└──────────────────────┴──────────────────────────────────────────────┘
|
면접에서 자주 묻는 질문
Q1. RDBMS와 NoSQL의 가장 큰 차이는?
RDBMS는 고정 스키마와 ACID 트랜잭션으로 데이터 정합성을 보장하고, SQL로 복잡한 관계 질의가 가능합니다. NoSQL은 유연한 스키마와 수평 확장에 강점이 있으며, BASE 모델로 가용성과 성능을 우선합니다. 핵심 차이는 “일관성 vs 확장성” 트레이드오프입니다.
Q2. CAP 이론을 설명해주세요.
분산 시스템에서 Consistency(일관성), Availability(가용성), Partition Tolerance(분단 내성) 중 최대 2개만 동시에 만족할 수 있다는 이론입니다. 현실적으로 네트워크 분단(P)은 피할 수 없으므로, CP(일관성 우선)와 AP(가용성 우선) 중 선택하게 됩니다. MongoDB는 CP, Cassandra는 AP에 가깝습니다.
Q3. 언제 NoSQL을 선택하나요?
대용량 데이터의 빠른 읽기/쓰기가 필요하거나, 스키마가 자주 변경되거나, 수평 확장이 필수인 경우 선택합니다. 캐시(Redis), 로그 저장(MongoDB), 실시간 피드(Cassandra) 등이 대표적입니다. 단, 데이터 정합성이 중요한 결제나 주문 핵심 로직은 RDBMS가 적합합니다.
Q4. Eventual Consistency(최종 일관성)가 뭔가요?
분산 환경에서 데이터 업데이트 후 모든 노드가 즉시 동일한 값을 보지는 않지만, 일정 시간이 지나면 결국 같은 값으로 수렴하는 모델입니다. SNS 좋아요 수가 사용자마다 잠시 다르게 보이는 것이 대표적인 예입니다. 강한 일관성(Strong Consistency)과 반대 개념이며, 가용성과 성능을 위한 트레이드오프입니다.
Q5. MongoDB에서 트랜잭션이 지원되나요?
MongoDB 4.0부터 멀티 문서 트랜잭션을 지원합니다. 하지만 RDBMS만큼 성숙하지 않고, 분산 환경에서 성능 오버헤드가 있습니다. MongoDB의 설계 철학은 한 문서 안에 관련 데이터를 임베딩해서 단일 문서 수준의 원자성으로 해결하는 것이므로, 트랜잭션이 자주 필요하다면 데이터 모델링을 재검토하거나 RDBMS를 고려해야 합니다.
Q6. Redis는 NoSQL인가요? 어떤 상황에서 쓰나요?
Redis는 Key-Value 기반 인메모리 NoSQL입니다. 모든 데이터를 메모리에 저장하므로 읽기/쓰기가 매우 빠르며(O(1)), 주로 캐시, 세션 저장, 분산 락, Rate Limiting, 실시간 랭킹 등에 사용합니다. 메모리 기반이라 데이터 영속성은 RDB/AOF 스냅샷으로 보완하지만, 메인 저장소보다는 보조 저장소로 활용하는 것이 일반적입니다.
Q7. 하나의 서비스에서 RDBMS와 NoSQL을 같이 쓸 수 있나요?
네, 실무에서는 Polyglot Persistence 전략으로 혼합 사용합니다. 주문/결제 같은 핵심 도메인은 MySQL로, 인증 토큰/세션은 Redis로, 검색은 Elasticsearch로, 비정형 로그는 MongoDB로 저장하는 식입니다. 각 데이터의 특성에 맞는 최적의 저장소를 선택하는 것이 현대 백엔드 아키텍처의 핵심입니다.
핵심 정리: RDBMS vs NoSQL은 어느 쪽이 우월한 게 아니라, 데이터 특성과 요구사항에 따른 선택이다. 정합성이 중요하면 RDBMS, 확장성과 유연성이 중요하면 NoSQL, 실무에서는 둘을 함께 쓰는 Polyglot Persistence가 일반적이다.