Nosql on kastori

[DB 완전 정복 #9] 어떤 DB를 왜 선택하는가 — MySQL, PostgreSQL, Redis, MongoDB 선택 기준

Wed, 03 Jun 2026 00:00:00 +0900

“왜 이 DB를 쓰나요?”

기술 면접에서 DB 관련 질문은 보통 여기서 끝난다. “MySQL 쓰셨다고 하셨는데, 왜 MySQL을 선택하셨나요?”

“익숙해서요"는 답이 아니다. “팀에서 써왔어서요"도 부족하다. 트레이드오프를 설명할 수 있어야 한다. 이 시리즈 마지막 편에서는 각 DB를 선택하는 근거를 정리한다.

SQL vs NoSQL — 먼저 이 구분부터

NoSQL이 SQL보다 무조건 빠른 게 아니다. 다른 문제를 풀기 위해 만들어진 도구다.

SQL을 선택할 때:
 - 데이터 간 관계가 명확하고 JOIN이 자주 필요한 경우
 - 트랜잭션(ACID) 보장이 필수인 경우 (결제, 계좌)
 - 스키마가 안정적이고 자주 바뀌지 않는 경우
 - 복잡한 집계·분석 쿼리가 필요한 경우

NoSQL을 선택할 때:
 - 스키마가 유동적이거나 비정형 데이터 (로그, 이벤트)
 - 수평 확장(Sharding)이 필수인 대규모 트래픽
 - 단순 키-값 조회 또는 단일 문서 읽기/쓰기 위주
 - 최종 일관성(Eventual Consistency)으로 충분한 경우

MySQL — 웹 서비스의 검증된 선택

MySQL을 선택하는 진짜 이유:

기술적 근거

InnoDB의 MVCC와 행 레벨 락으로 높은 동시성
Clustered Index로 기본키 조회 최고 성능
갭 락으로 Phantom Read 방지 (REPEATABLE READ 기본)

실무적 근거

Spring Boot + JPA 조합의 레퍼런스 압도적
AWS RDS, Aurora MySQL 등 클라우드 지원 완벽
DBA, 운영 인력 시장에서 경험자가 가장 많음

언제 MySQL이 부족한가: JSON 데이터를 쿼리하고 인덱스도 필요할 때, 지리 데이터를 다룰 때, AI 벡터 검색이 필요할 때.

PostgreSQL — 기능과 확장성이 필요할 때

JSONB가 필요하다면 PostgreSQL

-- 상품의 동적 속성을 JSON으로 저장하고 쿼리
CREATE INDEX idx_meta ON products USING GIN (meta);
SELECT * FROM products WHERE meta @> '{"color": "red", "size": "L"}';

MySQL에서 같은 쿼리를 하려면 Generated Column + 인덱스 트릭이 필요하다.

AI/ML 연동이 필요하다면 PostgreSQL

-- pgvector: 텍스트 임베딩을 저장하고 유사도 검색
SELECT *, embedding <-> '[0.1, 0.2, ...]' AS distance
FROM documents
ORDER BY distance LIMIT 5;

LLM 기반 서비스를 만든다면 pgvector를 지원하는 PostgreSQL이 사실상 표준이다.

지리 데이터라면 PostGIS

위경도 거리 계산, 반경 내 검색, 지도 위에서의 공간 쿼리가 필요하면 PostGIS 확장이 있는 PostgreSQL이다.

Redis — 인메모리의 다양한 역할

Redis를 캐시로만 쓰면 절반만 쓰는 것이다.

캐시

@Cacheable(value = "product", key = "#id")
public Product findById(Long id) { return productRepository.findById(id); }

DB 조회가 많고 데이터 변경이 적은 경우 Redis 캐시로 DB 부하를 줄인다. TTL을 설정해 무효화를 자동화한다.

세션 저장소

다중 서버 환경에서 세션을 공유할 때. 서버가 재시작되거나 로드밸런서가 다른 서버로 요청을 보내도 세션이 유지된다.

분산 락

// 다중 서버 환경에서 재고 차감을 안전하게
RLock lock = redissonClient.getLock("lock:product:" + productId);
if (lock.tryLock(3, 5, TimeUnit.SECONDS)) { ... }

단일 서버에서는 synchronized로 충분하지만, 서버가 2대 이상이면 Redis 분산 락이 필요하다.

실시간 랭킹

ZADD ranking 2300 "user:2"
ZREVRANGE ranking 0 9 // 상위 10명 — O(log N)

Sorted Set의 O(log N) 연산으로 수백만 명 랭킹도 실시간 처리 가능하다.

MongoDB — 스키마가 유연해야 할 때

임베딩이 JOIN을 대체한다

관계형 DB에서 3개 테이블을 JOIN해야 하는 상품 정보를, MongoDB에서는 단일 문서 조회 1번으로 처리한다. 계층 구조 데이터에서 읽기 성능이 좋다.

초기 개발의 스키마 유연성

서비스 초기에 데이터 구조가 자주 바뀐다. 관계형 DB에서 컬럼 추가/삭제는 마이그레이션이 필요하다. MongoDB는 문서 구조가 자유로워 마이그레이션 없이 바꿀 수 있다.

단, 복잡한 관계와 트랜잭션이 많은 도메인은 MySQL이 맞다.

실무 조합 패턴

일반 웹 서비스:
 MySQL ← 메인 데이터
 Redis ← 캐시, 세션, 분산 락

JSON 데이터가 많은 서비스:
 PostgreSQL (JSONB) ← 메인 데이터
 Redis ← 캐시, 세션

로그·이벤트 처리:
 MySQL / PostgreSQL ← 핵심 비즈니스 데이터
 MongoDB ← 로그, 이벤트, 비정형 데이터
 Redis ← 실시간 집계, 캐시

CAP 이론 — 왜 NoSQL은 최종 일관성인가

분산 데이터베이스는 세 가지를 동시에 보장할 수 없다.

C (Consistency) — 모든 노드가 같은 데이터를 봄
A (Availability) — 모든 요청이 응답을 받음
P (Partition Tolerance) — 네트워크 분리 상황에서도 동작

네트워크 분리(P)는 분산 시스템에서 항상 발생 가능한 사건이다. P를 포기할 수 없으니, 실제로는 C와 A 중 하나를 선택한다.

MySQL → CP (일관성 우선, 가용성 희생 가능)
Redis Cluster → AP (가용성 우선, 최종 일관성)
Cassandra → AP
MongoDB → 기본 CP, 설정에 따라 AP

Redis가 캐시에 어울리는 이유도 여기 있다. 캐시는 약간 오래된 데이터를 써도 괜찮다(AP). 반면 결제는 항상 최신 데이터가 필요하다(CP, MySQL).

면접 답변 정리

“어떤 DB를 선택하시겠어요?”

“서비스 특성에 따라 다릅니다. 관계형 데이터와 ACID 트랜잭션이 중요하면 MySQL을, JSON 데이터 쿼리나 지리 기능이 필요하면 PostgreSQL을 선택합니다. 캐시와 세션은 Redis를, 스키마가 유동적이고 계층 구조 데이터가 많으면 MongoDB를 고려합니다.”

“MySQL을 쓰는 이유가 뭔가요?”

“Spring + JPA 조합에서 레퍼런스가 가장 많고, InnoDB의 MVCC와 행 레벨 락으로 높은 동시성을 지원하며, AWS RDS와 Aurora MySQL을 통한 운영 편의성도 고려했습니다.”

시리즈를 마치며

DB는 단순히 데이터를 저장하는 도구가 아니다. 각 DB는 특정 문제를 풀기 위해 설계됐고, 그 설계 철학이 성능과 트레이드오프를 결정한다.

인덱스부터 시작해서 트랜잭션, 쿼리 최적화, 정규화, 커넥션 풀, MySQL vs PostgreSQL, Redis, MongoDB, 그리고 DB 선택 기준까지. 이 시리즈에서 다룬 내용이 면접과 실무에서 근거 있는 선택을 하는 데 도움이 되길 바란다.

[DB 완전 정복 #8] MongoDB는 왜 임베딩을 권장하나 — 문서 모델과 WiredTiger

Tue, 02 Jun 2026 00:00:00 +0900

“MongoDB는 그냥 JSON 저장하는 DB 아닌가요?”

MongoDB를 처음 접하면 이런 인식이 생기기 쉽다. 실제로 저장 형태가 JSON처럼 보이기 때문이다. 하지만 MongoDB가 진짜로 해결하려는 문제는 “JSON 저장"이 아니라 관계형 모델이 맞지 않는 데이터 구조다.

문서 모델 — 계층 구조를 그대로 저장한다

관계형 DB는 데이터를 정규화해서 여러 테이블에 나눠 저장한다. 조회 시 JOIN으로 합친다. MongoDB는 반대로, 관련 데이터를 하나의 문서 안에 중첩해서 저장한다.

상품 정보를 예로 들어보자.

관계형 DB:
 products (id, name, price)
 product_options (id, product_id, size, color, stock)
 product_images (id, product_id, url, order)
 → 조회 시 3개 테이블 JOIN

MongoDB:
 {
 _id: ObjectId("..."),
 name: "운동화",
 price: 89000,
 options: [
 { size: "260", color: "black", stock: 10 },
 { size: "270", color: "white", stock: 5 }
 ],
 images: [
 { url: "https://...", order: 1 },
 { url: "https://...", order: 2 }
 ]
 }
 → 단일 문서 조회 1번

JOIN 없이 한 번의 조회로 모든 데이터를 가져온다. 그리고 컬렉션 내 문서마다 구조가 달라도 된다 — 어떤 상품은 options 필드가 없어도 괜찮다.

임베딩 vs 참조 — MongoDB 설계의 핵심 결정

MongoDB 설계에서 가장 중요한 질문은 “관련 데이터를 한 문서 안에 넣을까(임베딩), 별도 컬렉션으로 분리할까(참조)?“다.

임베딩 — 함께 조회되는 데이터

// 주문과 주문 아이템을 한 문서에
{
 _id: ObjectId("order1"),
 orderNo: "ORD-001",
 member: { id: 100, name: "홍길동" },
 items: [
 { productId: 200, name: "노트북", qty: 1, price: 1500000 },
 { productId: 201, name: "마우스", qty: 2, price: 30000 }
 ],
 totalAmount: 1560000
}

임베딩이 맞는 경우:

항상 함께 조회하는 데이터
1:1 또는 1:소수 관계
임베딩된 데이터가 독립적으로 존재할 필요가 없는 경우

주문 생성 당시의 상품 정보를 함께 저장하는 것은 의미가 있다. 나중에 상품 가격이 바뀌어도 주문 당시 가격이 보존된다.

참조 — 무제한 증가하거나 독립 조회가 필요한 경우

// 게시글과 댓글을 별도 컬렉션으로
// posts
{ _id: ObjectId("post1"), title: "글 제목", content: "..." }

// comments
{ _id: ObjectId("c1"), postId: ObjectId("post1"), text: "댓글1" }
{ _id: ObjectId("c2"), postId: ObjectId("post1"), text: "댓글2" }
// ... 댓글이 수천 개가 되어도 posts 문서 크기는 그대로

참조가 맞는 경우:

배열이 무제한 증가할 수 있는 경우 (댓글, 로그)
양쪽 데이터를 독립적으로 수정하는 경우
N:M 관계

문서 크기 한도는 16MB다. 배열에 데이터를 계속 추가하면 결국 이 한도에 부딪힌다.

WiredTiger — MongoDB의 스토리지 엔진

MongoDB 3.2부터 기본 스토리지 엔진이다.

문서 레벨 락

구 엔진(MMAPv1)은 컬렉션 전체에 락을 걸었다. 같은 컬렉션 안의 다른 문서도 동시 쓰기가 불가능했다.

WiredTiger는 문서 레벨 락을 지원한다. 같은 컬렉션의 다른 문서에 동시에 쓸 수 있다. MVCC도 지원해서 읽기와 쓰기가 서로를 방해하지 않는다.

압축

디스크 사용량을 자동으로 줄여준다.

기본 압축: snappy (빠름, 적당한 압축률)
높은 압축: zlib 또는 zstd (더 강한 압축, CPU 비용 있음)
→ 실제로 디스크 사용량 50~80% 감소

WAL (Journal)

쓰기 전에 Journal(WAL)에 먼저 기록한다. 서버가 갑자기 꺼져도 Journal로 복구할 수 있다. 기본적으로 100ms마다 또는 128KB마다 flush된다.

집계 파이프라인 — SQL의 GROUP BY를 대체하는 방법

MongoDB에서 집계 쿼리는 파이프라인 방식이다. 문서가 여러 단계를 순서대로 통과한다.

// SQL: SELECT status, COUNT(*), SUM(amount)
// FROM orders WHERE created_at >= '2026-01-01'
// GROUP BY status HAVING COUNT(*) > 10
// ORDER BY SUM(amount) DESC

db.orders.aggregate([
 { $match: { createdAt: { $gte: new Date("2026-01-01") } } },
 { $group: {
 _id: "$status",
 count: { $sum: 1 },
 totalAmount: { $sum: "$amount" }
 }},
 { $match: { count: { $gt: 10 } } },
 { $sort: { totalAmount: -1 } }
])

성능 팁: $match를 파이프라인 앞에 배치해서 처리 문서 수를 먼저 줄여야 한다. 뒤에 두면 전체 문서를 집계한 다음 필터링하는 낭비가 생긴다.

트랜잭션

MongoDB는 단일 문서 내 업데이트는 항상 원자적이다. 여러 필드를 한 번에 수정해도 일부만 반영되는 일이 없다.

멀티 문서 트랜잭션은 4.0부터 지원되지만, 관계형 DB 트랜잭션보다 비용이 높다. MongoDB 설계 철학은 트랜잭션이 필요 없도록 임베딩으로 설계하는 것이다. 트랜잭션은 임베딩으로 해결이 안 되는 경우에만 쓴다.

언제 MongoDB를 선택하나

✅ 이런 경우 MongoDB
 - 스키마가 자주 바뀌는 초기 개발 단계
 - 상품 옵션, 설정값처럼 구조가 문서마다 다른 데이터
 - 로그, 이벤트 등 대량 쓰기 + 계층 구조
 - 지리 데이터 (2dsphere 인덱스 내장)

❌ 이런 경우 MongoDB 비적합
 - 복잡한 JOIN이 많은 경우 ($lookup은 있지만 SQL JOIN보다 느림)
 - 결제, 재고처럼 강한 ACID 트랜잭션이 필요한 경우
 - 복잡한 집계·분석 쿼리가 중심인 경우

마치며

MongoDB의 강점은 “스키마 없이 저장한다"가 아니라 계층 구조 데이터를 JOIN 없이 한 번에 읽는다는 것이다. 임베딩 vs 참조를 올바르게 선택하는 것이 MongoDB 성능의 핵심이다.

마지막 편에서는 이번 시리즈를 정리하며 각 DB를 어떤 기준으로 선택하는지 종합한다.

[DB 완전 정복 #7] Redis가 빠른 진짜 이유 — 단일 스레드, 이벤트 루프, 자료구조

Mon, 01 Jun 2026 00:00:00 +0900

“Redis가 빠른 이유가 인메모리라서 아닌가요?”

인메모리인 것은 맞지만, 그것만으로는 설명이 부족하다. Memcached도 인메모리인데 Redis만큼 다양하게 쓰이지 않는다. Redis가 특별한 이유는 단일 스레드 + 이벤트 루프 + 정교한 자료구조의 조합이다.

단일 스레드인데 왜 느리지 않나

Redis는 모든 명령을 단일 스레드가 처리한다. 멀티코어 서버에서 코어 하나만 쓴다는 뜻이다. 직관적으로 비효율적으로 보이지만, 이것이 Redis의 핵심 설계 철학이다.

멀티 스레드의 문제는 동기화 비용이다. 여러 스레드가 같은 데이터에 접근할 때 Race Condition을 막으려면 뮤텍스와 락이 필요하다. 락을 거는 것 자체가 비용이고, Context Switch도 비용이다.

Redis는 이 문제를 처음부터 단일 스레드로 설계해 피해갔다.

단일 스레드의 장점:
 - Lock 없음 → Race Condition 없음
 - 모든 명령이 원자적(Atomic) 보장
 - Context Switch 없음
 - 예측 가능한 성능

그렇다면 I/O는 어떻게 처리할까? 단일 스레드가 소켓을 하나씩 읽으면 느리지 않나?

이벤트 루프 + I/O Multiplexing

Redis는 epoll(Linux) 또는 kqueue(macOS) 같은 OS 레벨 I/O Multiplexing을 사용한다.

[클라이언트 수백 개]
 Client A ──┐
 Client B ──┤──▶ epoll (OS 커널) ──▶ 이벤트 큐
 Client C ──┘
 │
 ▼
 [단일 스레드 처리]
 명령 실행 → 응답

OS 커널이 수백 개의 소켓을 동시에 감시하다가, 읽을 데이터가 생기면 이벤트 큐에 넣는다. 단일 스레드는 큐에서 이벤트를 꺼내 처리한다. I/O 대기 시간을 OS가 흡수하므로 단일 스레드도 충분히 많은 클라이언트를 처리할 수 있다.

결국 Redis가 빠른 이유는: 인메모리 + Lock 없는 단일 스레드 + OS가 처리하는 I/O 대기 세 가지의 조합이다.

6.0+에서 멀티스레드 I/O

Redis 6.0부터 네트워크 I/O(패킷 읽기/쓰기)는 멀티스레드로 처리하도록 개선됐다. 하지만 실제 명령 실행은 여전히 단일 스레드다. 원자성과 단순함을 유지하면서 대용량 데이터 전송 성능만 개선한 것이다.

자료구조별 내부 구현

Redis의 또 다른 강점은 상황에 따라 내부 인코딩을 자동으로 최적화한다는 것이다.

Sorted Set — 실시간 랭킹의 핵심

데이터가 128개 이하: listpack (연속 메모리, 캐시 효율)
데이터가 많아지면: skiplist + hashtable 조합
 - skiplist: 정렬된 순서로 빠른 범위 조회 (O(log N))
 - hashtable: 멤버 → 점수 O(1) 조회

ZADD ranking 1500 "user:1"
ZADD ranking 2300 "user:2"
ZADD ranking 1800 "user:3"

ZREVRANGE ranking 0 9 WITHSCORES → 상위 10명 O(log N + 10)
ZRANK ranking "user:1" → 내 순위 O(log N)
ZSCORE ranking "user:2" → 점수 조회 O(1)

점수 변경이 잦은 실시간 랭킹에 최적이다.

Hash — 세션 저장의 패턴

필드가 128개 이하: listpack (연속 메모리)
필드가 많아지면: hashtable

HSET session:abc userId 1 username "kastori" // O(1)
HGET session:abc userId // O(1)
// 필드별 부분 업데이트 가능 (전체 덮어쓰기 필요 없음)

사용자 세션 데이터를 Hash로 저장하면 필드별로 읽고 쓸 수 있어 효율적이다.

자료구조 시간복잡도 요약

자료구조	주요 연산	시간복잡도
String	SET/GET	O(1)
List	LPUSH/RPUSH, LPOP/RPOP	O(1)
Hash	HSET/HGET	O(1)
Set	SADD/SISMEMBER	O(1)
Sorted Set	ZADD/ZSCORE	O(log N)
Sorted Set	ZRANGE	O(log N + M)

영속성 — 인메모리인데 재시작하면 데이터는?

Redis는 기본적으로 인메모리라 서버가 꺼지면 데이터가 사라진다. 영속성이 필요하다면 두 가지 방법이 있다.

RDB — 스냅샷

주기적으로 현재 메모리를 .rdb 파일로 저장
 → fork() 로 자식 프로세스가 저장, 부모는 계속 요청 처리

장점: 파일 크기 작음, 복구 빠름
단점: 마지막 스냅샷 이후 데이터 유실 가능

AOF — 명령 로그

모든 쓰기 명령을 파일에 순서대로 기록
재시작 시 파일을 재실행해서 복구

appendfsync everysec → 1초마다 flush (권장, 최대 1초 유실)

장점: 데이터 유실 최소화
단점: 파일 크기 큼, 복구 시간 느림

권장: 혼합 모드

# redis.conf
aof-use-rdb-preamble yes

→ AOF 파일 앞: RDB 스냅샷 (빠른 로딩)
→ AOF 파일 뒤: 스냅샷 이후 증분 명령 (데이터 안전)

실무에서 꼭 지켜야 할 것

KEYS 명령 절대 금지

KEYS * → 전체 키 순회, O(N), 단일 스레드 완전 블로킹
 → 운영 환경에서 1초도 안에 서버 응답 불가 상태 만들 수 있음

대신 SCAN:
 SCAN 0 MATCH user:* COUNT 100 → 커서 기반, 블로킹 없음

TTL 설정 필수

캐시 목적의 키는 반드시 만료 시간을 설정해야 한다. 안 하면 메모리가 계속 쌓이다가 maxmemory에 도달하고, eviction 정책에 따라 데이터가 예고 없이 삭제된다.

SET key value EX 3600 // 1시간 후 자동 만료

마치며

Redis를 “그냥 캐시"로만 알면 반쪽이다. 단일 스레드 이벤트 루프가 어떻게 동시 처리를 하는지, 자료구조마다 다른 내부 인코딩이 성능에 어떤 영향을 주는지 이해하면 Redis를 더 잘 쓸 수 있다. 다음 편에서는 문서 지향 DB인 MongoDB의 내부 구조를 다룬다.