Database 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의 내부 구조를 다룬다.

[DB 완전 정복 #6] MySQL과 PostgreSQL, 뭐가 다른가 — MVCC 구현부터 JSONB까지

Sun, 31 May 2026 00:00:00 +0900

“그냥 MySQL 쓰면 안 되나요?”

사실 대부분의 경우 MySQL로 충분하다. 하지만 “왜 MySQL인가요?“라는 질문에 “익숙해서요"는 좋은 답이 아니다. 두 DB의 내부 구조 차이를 알면, 상황에 따른 선택 근거를 만들 수 있다.

MVCC 구현 방식 — 가장 근본적인 차이

앞서 MVCC가 트랜잭션의 일관된 읽기를 보장한다고 배웠다. 그런데 MySQL과 PostgreSQL은 이 MVCC를 다른 방식으로 구현한다.

MySQL InnoDB: Undo Log 방식

[테이블 페이지]
 행 데이터: TX_ID=200, name="수정됨" ← 항상 최신 버전
 │
 └──(포인터)──▶ [Undo Log]
 TX_ID=100, name="원본" ← 이전 버전
 │
 └──▶ [Undo Log]
 TX_ID=50, name="초기값"

현재 데이터 페이지에는 최신 버전만 저장한다. 이전 버전은 별도 Undo Log 공간에 체인으로 보관한다. 읽기 시 자신의 스냅샷보다 최신 데이터면 Undo Log에서 이전 버전을 찾아 읽는다.

PostgreSQL: Heap 방식

[테이블 파일 (Heap)]
 t_xmin=100, t_xmax=200, name="원본" ← 이전 버전 (dead tuple)
 t_xmin=200, t_xmax=0, name="수정됨" ← 현재 버전 (live tuple)

같은 테이블 파일 안에 여러 버전이 공존한다. 각 행에 생성 트랜잭션(t_xmin)과 삭제 트랜잭션(t_xmax)을 기록한다. 읽기 시 내 트랜잭션 기준으로 어떤 버전을 볼지 visibility check로 판단한다.

운영상 차이

항목	MySQL	PostgreSQL
이전 버전 위치	별도 Undo Log	같은 테이블 파일
정리 방법	Purge 스레드 자동	VACUUM 필수
운영 주의점	긴 트랜잭션 (Undo 과다)	table bloat, autovacuum 튜닝

PostgreSQL은 오래된 dead tuple이 쌓이면 table bloat 현상이 발생한다. autovacuum이 자동으로 정리하지만, 대용량 테이블에서는 VACUUM 튜닝이 운영의 핵심이다.

인덱스 구조 — Clustered vs Heap

MySQL의 기본키 인덱스는 Clustered Index다. 리프 노드에 실제 행 데이터가 저장되고, 기본키 순서로 물리적으로 정렬된다.

MySQL Secondary Index 조회:
 인덱스에서 PK 찾기 → PK로 Clustered Index 조회 (2단계)

PostgreSQL 모든 인덱스 조회:
 인덱스에서 heap tuple pointer 찾기 → heap에서 행 조회 (1단계)

MySQL의 Secondary Index는 2단계를 거치지만, 기본키 조회는 Clustered Index 덕분에 최고 성능이다. PostgreSQL은 모든 인덱스가 동등한 구조를 가진다.

JSONB — PostgreSQL이 MySQL을 압도하는 부분

반정형 데이터(JSON)를 DB에 저장해야 한다면, PostgreSQL의 JSONB가 압도적으로 유리하다.

-- MySQL JSON: 텍스트로 저장, 조회마다 파싱
ALTER TABLE products ADD COLUMN meta JSON;

-- 인덱스를 걸려면 Generated Column 트릭 필요
ALTER TABLE products
ADD COLUMN meta_color VARCHAR(50)
 GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(meta, '$.color'))) STORED;
CREATE INDEX idx_color ON products(meta_color);

-- PostgreSQL JSONB: 바이너리 파싱 후 저장, GIN 인덱스 직접 가능
ALTER TABLE products ADD COLUMN meta JSONB;
CREATE INDEX idx_meta ON products USING GIN (meta);

-- 풍부한 연산자
SELECT * FROM products WHERE meta @> '{"color": "red"}'; -- 포함 여부
SELECT * FROM products WHERE meta ? 'color'; -- 키 존재 여부

PostgreSQL JSONB는 바이너리로 저장해 파싱 없이 빠르고, GIN 인덱스로 JSON 내부 키에 직접 인덱싱할 수 있다. MySQL은 이 수준의 JSON 쿼리 지원이 없다.

PostgreSQL의 확장 생태계

PostgreSQL은 확장(Extension)으로 기능을 추가할 수 있다.

PostGIS → 지리 데이터, 위경도 거리 계산, 공간 인덱스
pgvector → AI 벡터 임베딩 저장 및 유사도 검색 (LLM 연동)
pg_trgm → 문자열 유사도 검색 (LIKE '%검색어%' 인덱스)
TimescaleDB → 시계열 데이터 최적화

LLM, AI 서비스와 연동하거나 지리 기능이 필요하다면 PostgreSQL이 사실상 유일한 선택이다.

라이선스 차이

MySQL은 GPL 라이선스다. 오픈소스 프로젝트에서 MySQL을 수정해 배포하면 소스를 공개해야 한다. MariaDB 포크가 생긴 배경이기도 하다.

PostgreSQL은 BSD 계열(PostgreSQL License)로 상업용 포함 완전 자유다.

선택 기준 정리

MySQL을 선택하는 경우:
 - Spring Boot + JPA 조합 (레퍼런스와 생태계 압도적)
 - 단순 CRUD 위주의 일반 웹 서비스
 - 팀에 MySQL 운영 경험이 있는 경우
 - AWS Aurora MySQL 사용 계획

PostgreSQL을 선택하는 경우:
 - JSON 데이터를 쿼리하고 인덱스도 필요한 경우 (JSONB)
 - 지리 데이터 (PostGIS)
 - AI/ML 벡터 검색 (pgvector)
 - 복잡한 분석 쿼리 위주 서비스
 - 오픈소스 라이선스 자유도가 중요한 경우

마치며

MySQL은 웹 서비스의 검증된 선택이고, PostgreSQL은 확장성과 기능 다양성에서 강하다. 어느 쪽이 낫다는 게 아니라, 사용하는 이유를 설명할 수 있느냐가 중요하다.

다음 편에서는 관계형 DB와 전혀 다른 구조로 설계된 Redis의 내부 동작 원리를 다룬다.

[DB 완전 정복 #5] HikariCP와 커넥션 풀 — 설정 하나가 서비스를 멈춘다

Sat, 30 May 2026 00:00:00 +0900

요청 1000개에 커넥션 1000개를 만들면?

트래픽이 급증하는 상황을 상상해보자. 매 요청마다 DB 커넥션을 새로 만들면 어떻게 될까.

DB 커넥션 생성 과정:
 1. TCP 소켓 연결 (3-way handshake)
 2. DB 서버 인증 (사용자/비밀번호 검증)
 3. 세션 초기화 (인코딩, 타임존, 옵션 설정)

→ 수십 ~ 수백 ms 소요
→ 초당 1000 요청이면 커넥션 생성만으로 서버 과부하

커넥션 풀은 이 문제를 미리 만들어 두고 재사용하는 방식으로 해결한다.

HikariCP — Spring Boot의 기본 커넥션 풀

Spring Boot 2.0부터 HikariCP가 기본이다. “세상에서 가장 빠른 커넥션 풀"이라는 별명이 있다. 별도 설정 없이도 동작하지만, 기본값이 모든 상황에 맞지 않다는 게 함정이다.

동작 원리

애플리케이션 시작
 → 미리 커넥션 N개 생성해서 풀에 보관

HTTP 요청 처리
 → 풀에서 유휴 커넥션 꺼내기 (borrow)
 → DB 작업 수행
 → 커넥션 반납 (close가 아님, return)

풀이 비어있을 때
 → connectionTimeout 동안 대기
 → 초과 → SQLTimeoutException

핵심은 커넥션을 닫지 않고 반납한다는 것이다. 코드에서 connection.close()를 호출해도 실제로 닫히지 않고 풀로 돌아간다.

풀 사이즈 공식 — 너무 크면 오히려 느리다

직관적으로는 커넥션이 많을수록 좋을 것 같다. 하지만 커넥션이 너무 많으면 DB 서버 자체가 부하를 받는다.

HikariCP 공식 문서가 제안하는 공식:

maximumPoolSize = (CPU 코어 수 × 2) + 유효 디스크 수

예: CPU 4코어 + SSD 1개 = 9개

놀랍도록 작은 숫자처럼 보인다. 하지만 실제로 DB 연산은 CPU와 I/O를 번갈아 쓰므로, 코어당 2개가 적절하다. 그 이상은 Context Switch 오버헤드만 늘어난다.

# application.yml
spring:
 datasource:
 hikari:
 maximum-pool-size: 10 # 최대 커넥션 수
 minimum-idle: 5 # 유지할 최소 유휴 커넥션 수
 connection-timeout: 30000 # 커넥션 대기 최대 시간 (ms)
 idle-timeout: 600000 # 유휴 커넥션 유지 시간 (ms)
 max-lifetime: 1800000 # 커넥션 최대 수명 (ms)

max-lifetime 주의사항

max-lifetime은 DB 서버의 wait_timeout보다 반드시 짧게 설정해야 한다.

DB 서버 wait_timeout: 8시간 (기본값)
max-lifetime: 30분 (권장)
→ DB가 연결을 끊기 전에 풀에서 먼저 커넥션을 교체

max-lifetime이 wait_timeout보다 길면, DB가 이미 닫은 커넥션을 풀이 계속 들고 있다가 사용 시점에 Connection is closed 에러가 난다.

커넥션 고갈 — 가장 흔한 장애 원인

풀의 모든 커넥션이 사용 중이면, 새 요청은 connectionTimeout까지 대기한다. 시간이 초과되면 에러다.

HikariPool-1 - Connection is not available, request timed out after 30000ms

커넥션 고갈의 주요 원인

1. 트랜잭션 안에서 외부 I/O

@Transactional
public void processOrder(Long orderId) {
 Order order = orderRepository.findById(orderId); // 커넥션 획득
 sendEmail(order); // 이메일 전송 (3~5초)
 // 이메일 전송하는 동안 커넥션을 계속 들고 있음
 orderRepository.save(order);
} // 여기서 커넥션 반납

이메일 전송이 5초 걸리는 동안 커넥션 1개가 묶여 있다. 동시 요청이 많으면 풀이 금방 고갈된다.

해결: 트랜잭션 밖으로 느린 I/O를 분리한다.

public void processOrder(Long orderId) {
 Order order = orderService.getOrder(orderId); // 짧은 트랜잭션
 sendEmail(order); // 트랜잭션 밖
 orderService.completeOrder(orderId); // 짧은 트랜잭션
}

2. 풀 사이즈가 너무 작음

요청 동시성 대비 풀이 작으면 대기 큐가 쌓인다. 모니터링으로 실제 사용량을 확인하고 조정해야 한다.

3. 긴 쿼리

인덱스 없는 쿼리가 10초씩 걸리면 그동안 커넥션이 묶인다. 쿼리 최적화로 해결한다.

모니터링 — Actuator로 풀 상태 보기

Spring Boot Actuator를 쓰면 커넥션 풀 상태를 실시간으로 볼 수 있다.

# application.yml
management:
 endpoints:
 web:
 exposure:
 include: health, metrics

GET /actuator/metrics/hikaricp.connections.active
GET /actuator/metrics/hikaricp.connections.pending
GET /actuator/metrics/hikaricp.connections.timeout

pending(대기 중)이 0이 아니거나 timeout이 발생하기 시작하면 풀 사이즈 조정 또는 쿼리 최적화를 검토해야 한다.

마치며

커넥션 풀은 조용히 잘 동작하다가 특정 임계점을 넘으면 갑자기 서비스 전체가 멈춘다. 평소에 maximum-pool-size, max-lifetime 설정을 확인하고, 트랜잭션 안에 느린 I/O가 없는지 리뷰하는 것만으로도 많은 장애를 예방할 수 있다.

다음 편부터는 심화 시리즈로, MySQL과 PostgreSQL의 내부 구조 차이를 다룬다.

[DB 완전 정복 #4] 정규화는 언제 깨야 하나 — 1NF부터 3NF, 실무 비정규화까지

Fri, 29 May 2026 00:00:00 +0900

테이블 하나에 다 넣으면 안 되나요?

DB를 처음 설계할 때 이런 생각을 한 적이 있을 것이다. 그냥 필요한 정보를 테이블 하나에 다 넣으면 조인도 없고 편하지 않을까?

실제로 해보면 금방 문제가 생긴다.

이상 현상 — 설계가 나쁠 때 생기는 일

이런 테이블이 있다고 해보자.

주문_정보 (비정규화)
| order_id | member_id | member_name | member_email | product_id | product_name | price |
|----------|-----------|-------------|---------------|------------|--------------|-------|
| 1 | 100 | 홍길동 | hong@test.com | 200 | 노트북 | 1500 |
| 2 | 100 | 홍길동 | hong@test.com | 201 | 마우스 | 30 |
| 3 | 101 | 김철수 | kim@test.com | 200 | 노트북 | 1500 |

삽입 이상: 주문이 없는 신규 회원을 등록하고 싶다. order_id가 없으니 행을 추가할 수 없다.

삭제 이상: 주문 1번을 삭제한다. 그런데 홍길동의 이메일 정보가 주문 2번에만 남는 게 아니라, 만약 주문이 1번 하나뿐이었다면 회원 정보 자체가 사라진다.

수정 이상: 홍길동이 이메일을 변경했다. order_id = 1과 order_id = 2 두 군데를 모두 수정해야 한다. 하나만 고치면 같은 사람의 이메일이 두 개가 된다.

이것이 **이상 현상(Anomaly)**이다. 정규화는 이 문제를 해결하기 위한 설계 원칙이다.

1NF — 원자값 원칙

모든 컬럼의 값이 더 이상 분리할 수 없는 원자적인 값이어야 한다.

❌ 1NF 위반
| order_id | products |
|----------|------------------|
| 1 | 노트북, 마우스 | ← 여러 값이 한 컬럼에

✅ 1NF 준수
| order_id | product_id | product_name |
|----------|------------|--------------|
| 1 | 200 | 노트북 |
| 1 | 201 | 마우스 |

컬럼에 여러 값을 콤마로 넣거나, 배열처럼 넣는 것이 대표적인 위반이다. 이렇게 하면 WHERE products LIKE '%마우스%'처럼 검색해야 하고, 인덱스도 제대로 못 탄다.

2NF — 부분 함수 종속 제거

기본키가 복합키일 때, 모든 일반 컬럼이 복합키 전체에 종속되어야 한다. (기본키의 일부에만 종속되면 안 된다)

order_items 테이블 (1NF)
기본키: (order_id, product_id)

| order_id | product_id | product_name | qty |
|----------|------------|--------------|-----|
| 1 | 200 | 노트북 | 1 |
| 1 | 201 | 마우스 | 2 |

문제: product_name은 product_id에만 종속 (order_id와는 무관)
 → 노트북 이름이 바뀌면 여러 주문 행을 모두 수정해야 함

✅ 2NF 준수 (분리)
order_items: (order_id, product_id, qty)
products: (product_id, product_name, price)

3NF — 이행적 함수 종속 제거

기본키가 아닌 일반 컬럼 간의 종속이 없어야 한다.

members 테이블 (2NF)
기본키: member_id

| member_id | zip_code | city | district |
|-----------|----------|--------|----------|
| 1 | 06130 | 서울 | 강남구 |
| 2 | 06130 | 서울 | 강남구 |

문제: city와 district는 zip_code에 종속 (member_id → zip_code → city/district)
 → 06130 우편번호의 시/구가 바뀌면 모든 행을 수정해야 함

✅ 3NF 준수 (분리)
members: (member_id, zip_code)
zip_codes: (zip_code, city, district)

정규화 vs 비정규화 — 트레이드오프

정규화를 하면 데이터 무결성이 좋아지지만, 조회 시 조인이 많아진다.

정규화의 장점:
 ✅ 데이터 중복 없음 → 수정 이상 없음
 ✅ 삽입/삭제 이상 없음
 ✅ 저장 공간 절약

정규화의 단점:
 ❌ 조회 시 JOIN 필요 → 쿼리 복잡
 ❌ 성능이 중요한 읽기 위주 서비스에서 조인 비용

실무에서는 의도적으로 정규화를 깨는 경우도 있다.

비정규화가 정당한 경우

1. 집계 결과를 미리 저장

-- 매번 COUNT 집계 쿼리 실행
SELECT COUNT(*) FROM posts WHERE member_id = 1;

-- 비정규화: members 테이블에 post_count 컬럼 추가
-- 게시글 INSERT/DELETE 시 post_count를 함께 업데이트
SELECT post_count FROM members WHERE id = 1; -- 빠름

2. 자주 함께 조회되는 컬럼 중복 저장

-- orders 테이블에 member_name을 중복 저장
-- 주문 목록 조회 시 members 테이블 JOIN 불필요
| order_id | member_id | member_name | total_amount |

주문 당시의 회원명을 보존한다는 의미도 있다(회원이 탈퇴해도 주문 이력 유지).

3. 읽기 전용 분석 테이블

OLAP(분석 쿼리) 용도의 테이블은 처음부터 비정규화로 설계한다. 수십 개 테이블을 조인하는 분석 쿼리보다 평탄화된 넓은 테이블이 훨씬 빠르다.

JPA와 정규화의 관계

JPA 연관관계(@OneToMany, @ManyToOne)는 정규화된 테이블을 객체로 매핑하는 방식이다. 정규화가 잘 되어 있으면 JPA 설계도 자연스럽게 따라온다.

비정규화를 하면 JPA 매핑이 어색해질 수 있다. 그래서 비정규화는 신중하게, 이유가 명확할 때만 해야 한다.

마치며

정규화는 목표가 아니라 도구다. 이상 현상을 없애기 위해 필요한 만큼 하고, 성능이 중요하고 이유가 명확한 경우에만 의도적으로 비정규화를 선택한다. “정규화를 깨는 이유가 뭔가요?“라는 질문에 답할 수 있다면 충분하다.

다음 편에서는 DB 연결 자체의 비용을 다루는 커넥션 풀(HikariCP)을 다룬다.

[DB 완전 정복 #3] 느린 쿼리를 잡아라 — EXPLAIN 읽는 법과 페이징 최적화

Thu, 28 May 2026 00:00:00 +0900

쿼리가 느리다. 어디서부터 봐야 할까

개발 환경에서는 데이터가 몇 백 건이라 빠르다. 그런데 운영 환경에 올라가면 특정 페이지가 버벅인다. 로그를 보면 DB 쿼리가 범인이다.

이때 시작점은 하나다. EXPLAIN.

EXPLAIN — 옵티마이저의 속마음을 보는 방법

EXPLAIN은 MySQL 옵티마이저가 쿼리를 어떻게 실행할지 보여주는 명령이다.

EXPLAIN SELECT o.*, m.name
FROM orders o
JOIN members m ON o.member_id = m.id
WHERE o.status = 'PENDING'
ORDER BY o.created_at DESC
LIMIT 20;

출력에서 봐야 할 컬럼 네 가지:

컬럼	의미	좋은 값	나쁜 값
`type`	테이블 접근 방식	const, ref, range	ALL (풀스캔)
`key`	실제 사용한 인덱스	인덱스명	NULL
`rows`	예상 스캔 행 수	작을수록	클수록
`Extra`	부가 정보	Using index	Using filesort, Using temporary

type 값 — 빠른 순서

const → PK로 단 1개 행 조회 (가장 빠름)
eq_ref → 조인에서 PK로 1개 행 조회
ref → 일반 인덱스로 여러 행 조회
range → 인덱스 범위 스캔 (BETWEEN, >, <)
index → 인덱스 풀 스캔 (테이블보다는 낫지만 느림)
ALL → 테이블 풀 스캔 (가장 느림, 즉시 개선 필요)

type: ALL이 보이면 인덱스가 없거나 무력화된 것이다.

Extra 해석

Using index → 커버링 인덱스. 테이블 접근 없음 (좋음)
Using where → 인덱스 후 WHERE 필터링 (보통)
Using filesort → ORDER BY를 정렬 버퍼에서 처리 (느림, 인덱스로 해결 가능)
Using temporary → 임시 테이블 사용 (느림, GROUP BY/DISTINCT 최적화 필요)
Using index condition → ICP (인덱스 레벨에서 조건 필터링, 개선)

Using filesort와 Using temporary가 함께 나오면 위험 신호다. ORDER BY나 GROUP BY 컬럼에 인덱스를 추가하는 것을 검토해야 한다.

슬로우 쿼리 로그 — 운영에서 느린 쿼리 찾기

EXPLAIN은 알고 있는 쿼리를 분석할 때 쓴다. 운영에서 어떤 쿼리가 느린지 모를 때는 슬로우 쿼리 로그를 켠다.

-- 슬로우 쿼리 로그 설정
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- 1초 이상 걸리는 쿼리 기록
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

로그에 쌓인 쿼리를 mysqldumpslow로 집계하면 가장 자주 느린 쿼리 순으로 정렬할 수 있다.

Spring Boot에서는 p6spy 라이브러리를 추가하면 JPA가 실행하는 쿼리의 실행 시간을 콘솔에서 볼 수 있다.

조인 최적화 — 드라이빙 테이블이 결과를 결정한다

MySQL은 조인 시 **드라이빙 테이블(Driving Table)**을 먼저 읽고, 그 결과로 드리븐 테이블(Driven Table)을 검색한다.

SELECT o.*, m.name
FROM orders o
JOIN members m ON o.member_id = m.id
WHERE o.status = 'PENDING';

옵티마이저는 어떤 테이블을 드라이빙으로 할지 결정한다. 일반적으로 결과 행 수가 적은 테이블이 드라이빙이 된다.

핵심 원칙: 드리븐 테이블의 조인 조건 컬럼에는 반드시 인덱스가 있어야 한다. 없으면 드라이빙 테이블의 행마다 드리븐 테이블 풀스캔이 반복된다.

-- members.id에 인덱스가 없으면
-- orders 행 수만큼 members 풀스캔 반복 → O(N*M)
-- members.id에 인덱스 있으면
-- 각 orders 행에서 members를 O(log M)으로 조회 → O(N*log M)

OFFSET 페이징의 함정

가장 많이 쓰는 페이징 쿼리다.

SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 100000;

문제는 OFFSET 100000이다. MySQL은 첫 번째 행부터 100,020번째 행까지 읽어서, 앞 100,000개를 버리고 20개만 반환한다. 페이지 번호가 높아질수록 버리는 데이터가 늘어난다.

페이지 1: 20개 읽기
페이지 5000: 100,020개 읽고 100,000개 버리기

해결책 1: 커버링 인덱스 + 서브쿼리

-- 1단계: 인덱스만으로 PK 목록 조회 (테이블 접근 없음)
SELECT id FROM orders
ORDER BY created_at DESC
LIMIT 20 OFFSET 100000;

-- 2단계: PK로 실제 데이터 조회
SELECT o.* FROM orders o
JOIN (
 SELECT id FROM orders
 ORDER BY created_at DESC
 LIMIT 20 OFFSET 100000
) AS sub ON o.id = sub.id;

서브쿼리는 인덱스만 읽으니 빠르고, 최종 데이터는 PK 20개로만 조회한다.

해결책 2: 커서 기반 페이징 (No Offset)

-- 첫 페이지
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20;
-- 마지막으로 받은 created_at이 '2026-05-01 12:00:00'이라면

-- 다음 페이지 (OFFSET 없이 조건으로)
SELECT * FROM orders
WHERE created_at < '2026-05-01 12:00:00'
ORDER BY created_at DESC LIMIT 20;

OFFSET 없이 항상 인덱스 범위 스캔으로 처리된다. 몇 백만 페이지가 되어도 속도가 일정하다. 단, 임의 페이지 이동(페이지 번호 클릭)이 필요하면 쓸 수 없다. 무한 스크롤에 최적이다.

마치며

쿼리 최적화의 순서:

1. EXPLAIN으로 실행 계획 확인
2. type: ALL → 인덱스 추가
3. Using filesort → ORDER BY 컬럼에 인덱스
4. 조인: 드리븐 테이블 조인 조건에 인덱스
5. 페이징: OFFSET 높으면 커버링 인덱스 또는 커서 기반으로 전환

다음 편에서는 테이블 설계의 기초인 정규화와, 실무에서 의도적으로 정규화를 깨는 경우를 다룬다.

[DB 완전 정복 #2] MySQL이 동시 요청을 처리하는 방법 — MVCC, 갭 락, 데드락

Tue, 26 May 2026 00:00:00 +0900

동시에 100명이 같은 행을 읽고 있다면

서버에 동시 요청이 들어오면 여러 트랜잭션이 같은 데이터를 동시에 읽고 쓴다. 이때 두 가지 문제가 생긴다.

첫 번째는 일관성. A가 읽는 도중 B가 데이터를 수정하면, A는 수정 전을 봐야 할까 수정 후를 봐야 할까?

두 번째는 성능. 읽기마다 락을 걸면 안전하지만, 100개 스레드가 모두 대기 상태가 된다.

MySQL InnoDB는 MVCC로 이 두 문제를 동시에 해결한다.

MVCC — 락 없이 일관된 읽기

MVCC(Multi-Version Concurrency Control)는 각 트랜잭션이 자신이 시작한 시점의 스냅샷을 본다는 개념이다.

InnoDB는 모든 행에 숨겨진 컬럼을 둔다.

DB_TRX_ID : 이 행을 마지막으로 수정한 트랜잭션 ID
DB_ROLL_PTR : Undo Log 포인터 (이전 버전으로 가는 링크)

트랜잭션이 시작되면 스냅샷 ID가 부여된다. 이후 데이터를 읽을 때, 해당 행의 DB_TRX_ID가 자신의 스냅샷 ID보다 크면(= 내가 시작한 이후에 수정됨) Undo Log에서 이전 버전을 찾아 읽는다.

[현재 데이터] TX_ID=200, name="수정됨"
 │
 └──▶ [Undo Log] TX_ID=100, name="원본" ← TX 150이 읽는 버전
 │
 └──▶ [Undo Log] TX_ID=50, name="초기값"

트랜잭션 150은 TX 200이 수정한 내용을 보지 않는다. 락 없이도 일관된 데이터를 읽는다. 이것이 MVCC의 핵심이다.

덕분에 읽기는 쓰기를 방해하지 않고, 쓰기는 읽기를 방해하지 않는다.

행 레벨 락 — 필요한 행만 잠근다

읽기는 MVCC로, 쓰기는 행 레벨 락으로 처리한다.

S락 (Shared Lock) : 읽기 락. 여러 트랜잭션이 동시에 획득 가능
X락 (Exclusive Lock): 쓰기 락. 하나의 트랜잭션만 획득 가능

S + S → 허용
S + X → 대기
X + X → 대기

InnoDB는 테이블 전체가 아닌 특정 행에만 락을 건다. id = 1에 락이 걸려 있어도 id = 2는 다른 트랜잭션이 자유롭게 수정할 수 있다.

BEGIN;
SELECT * FROM orders WHERE id = 1 FOR UPDATE; -- id=1에만 X락
-- id=2, 3, 4 ... 다른 트랜잭션이 자유롭게 접근 가능

갭 락 — Phantom Read를 막는 방법

REPEATABLE READ 격리 수준에서는 같은 쿼리를 두 번 실행해도 결과가 같아야 한다. 하지만 락 없이 범위 조회를 하면, 그 사이 다른 트랜잭션이 새 행을 삽입(INSERT)할 수 있다. 이것이 Phantom Read다.

InnoDB는 이를 **갭 락(Gap Lock)**으로 막는다.

-- orders에 id: 10, 20, 30이 있다고 가정
SELECT * FROM orders WHERE id BETWEEN 10 AND 30 FOR UPDATE;
-- 10~30 범위의 "빈 공간(갭)"에도 락 → 이 범위에 INSERT 불가

갭 락은 인덱스 레코드 사이의 공간에 걸린다. 행이 없어도 “그 자리"를 잠가서 새 INSERT를 막는다.

실무에서 갭 락 주의사항: 인덱스가 없는 컬럼으로 UPDATE하면 범위를 특정할 수 없어 테이블 전체에 갭 락이 걸린다. 다른 트랜잭션의 INSERT가 전부 막힌다.

데드락 — 서로를 기다리는 교착 상태

두 트랜잭션이 서로 상대방의 락이 풀리기를 기다리면 데드락이 발생한다.

-- TX A -- TX B
BEGIN; BEGIN;
UPDATE orders SET ... WHERE id = 1; UPDATE orders SET ... WHERE id = 2;
-- A가 id=1 X락 획득 -- B가 id=2 X락 획득

UPDATE orders SET ... WHERE id = 2; UPDATE orders SET ... WHERE id = 1;
-- id=2 락 대기 (B가 가지고 있음) -- id=1 락 대기 (A가 가지고 있음)
-- → 영원히 대기 = 데드락

InnoDB는 데드락을 자동으로 감지해서 한쪽 트랜잭션을 강제 롤백한다.

ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction

데드락 예방 4가지

1. 모든 트랜잭션에서 테이블/행 접근 순서를 일관되게 유지
 (항상 id 오름차순으로 락을 잡으면 교차가 발생하지 않는다)

2. 트랜잭션을 짧게 유지 — 락 보유 시간 최소화

3. 인덱스를 통한 정확한 행 접근 — 갭 락 범위 최소화

4. @Transactional(timeout = 5) — 일정 시간 후 자동 롤백

낙관적 락 vs 비관적 락 — 언제 뭘 써야 하나

충돌이 드문지 잦은지에 따라 전략이 달라진다.

낙관적 락 — “충돌이 드물다”

읽을 때는 락을 걸지 않고, 수정할 때 version 조건을 추가한다.

-- 읽기 (락 없음)
SELECT id, stock, version FROM products WHERE id = 1;
-- 결과: stock=10, version=5

-- 수정 (version 조건 추가)
UPDATE products SET stock = 9, version = 6
WHERE id = 1 AND version = 5;
-- 영향받은 행이 0이면 → 다른 트랜잭션이 먼저 수정 → 애플리케이션에서 재시도

JPA에서는 @Version 어노테이션으로 자동 처리된다.

적합한 케이스: 게시글 수정, 사용자 프로필 변경 — 동시 수정이 드문 경우

비관적 락 — “충돌이 잦다”

읽을 때부터 X락을 걸어 다른 트랜잭션의 접근 자체를 막는다.

SELECT * FROM products WHERE id = 1 FOR UPDATE; -- X락
UPDATE products SET stock = stock - 1 WHERE id = 1;
COMMIT; -- 커밋 시 락 해제

적합한 케이스: 재고 차감, 선착순 쿠폰, 포인트 사용 — 동시 수정이 잦고 정확성이 중요한 경우

마치며

MVCC는 읽기와 쓰기가 서로를 방해하지 않게 해준다. 행 레벨 락은 필요한 부분만 잠근다. 갭 락은 Phantom Read를 막는다. 그리고 데드락은 락 순서를 통일하면 예방할 수 있다.

@Transactional을 쓸 때 격리 수준을 설정하는 이유, JPA의 @Version이 하는 일 — 모두 여기서 나온다. 다음 편에서는 느린 쿼리를 진단하는 EXPLAIN을 다룬다.

[DB 완전 정복 #1] 쿼리가 느린 이유는 대부분 인덱스에 있다

Sun, 24 May 2026 00:00:00 +0900

“인덱스 걸었는데 왜 느리죠?”

개발하다 보면 이런 상황을 만난다. 분명히 인덱스를 걸었는데 쿼리가 여전히 느리다. EXPLAIN을 돌려보면 type: ALL이 찍혀 있다. 풀스캔이다.

인덱스를 걸었는데 왜 안 탈까? 이 글에서는 그 이유를 포함해서, 인덱스가 실제로 어떻게 동작하는지 처음부터 짚어본다.

인덱스는 책의 목차다

테이블에서 특정 행을 찾는 방법은 두 가지다. 첫 번째는 처음부터 끝까지 전부 읽는 것(Full Table Scan), 두 번째는 목차를 먼저 보고 해당 페이지로 바로 가는 것(Index Scan)이다.

100만 건짜리 테이블에서 member_id = 123인 주문을 찾는다고 해보자.

-- 인덱스 없음: 100만 건 전부 스캔
SELECT * FROM orders WHERE member_id = 123;

-- 인덱스 있음: B-Tree로 O(log N) 탐색
CREATE INDEX idx_member_id ON orders(member_id);
SELECT * FROM orders WHERE member_id = 123;

인덱스는 조회를 빠르게 하지만 쓰기를 느리게 한다. 행을 삽입·수정·삭제할 때마다 인덱스도 같이 업데이트되기 때문이다. 트레이드오프를 이해하고 써야 한다.

B-Tree — MySQL 인덱스의 기본 자료구조

MySQL InnoDB의 기본 인덱스는 **B-Tree(Balanced Tree)**다.

 [ 루트 노드: 50 ]
 / \
 [ 내부 노드: 20, 35 ] [ 내부 노드: 65, 80 ]
 / | \ / | \
 [리프] [리프] [리프] [리프] [리프] [리프]
 10,15 20,25 35,40 50,55 65,70 80,90

리프 노드끼리는 이중 연결 리스트로 연결되어 있다. 덕분에 범위 검색(BETWEEN, >, <)이 효율적이다. 50 이상을 찾으면 50이 있는 리프 노드에서 오른쪽으로 쭉 따라가면 된다.

Clustered Index vs Secondary Index

InnoDB에는 두 가지 인덱스가 있다.

Clustered Index (기본키 인덱스)
→ 리프 노드에 실제 행 데이터 저장
→ 테이블당 1개, 기본키 기준으로 물리적 정렬

Secondary Index (일반 인덱스)
→ 리프 노드에 기본키 값만 저장
→ 조회 시: 인덱스에서 PK 찾기 → PK로 다시 Clustered Index 조회 (2단계)

Secondary Index 조회는 2단계를 거친다. 이 2단계 과정이 “인덱스 랜덤 I/O"다. 후술할 커버링 인덱스가 이 비용을 없애는 방법이다.

복합 인덱스 — 순서가 전부다

여러 컬럼을 하나의 인덱스로 묶을 때, 컬럼 순서가 핵심이다.

CREATE INDEX idx_member_status ON orders(member_id, status);

인덱스는 왼쪽부터 순서대로 사용된다. 이걸 “선두 컬럼 규칙"이라 한다.

-- ✅ member_id + status 둘 다 인덱스 사용
SELECT * FROM orders WHERE member_id = 1 AND status = 'DONE';

-- ✅ member_id만 인덱스 사용 (선두 컬럼)
SELECT * FROM orders WHERE member_id = 1;

-- ❌ 인덱스 사용 불가 (선두 컬럼 없음)
SELECT * FROM orders WHERE status = 'DONE';

컬럼 순서 결정 기준:

카디널리티 높은 것 먼저 — 값이 다양한 컬럼. member_id(수백만 종류)가 status(5종류)보다 앞에
등호(=) 먼저, 범위(>, <) 나중 — 범위 조건이 앞에 오면 뒤 컬럼은 인덱스를 못 씀

커버링 인덱스 — 테이블을 아예 안 보는 방법

쿼리에 필요한 모든 컬럼이 인덱스 안에 있으면, 테이블 본체를 읽지 않아도 된다. 이것이 커버링 인덱스다.

CREATE INDEX idx_cover ON orders(member_id, status, amount);

-- 커버링 인덱스 적용
-- SELECT 절의 member_id, status, amount가 모두 인덱스에 있음
SELECT member_id, status, amount
FROM orders
WHERE member_id = 1 AND status = 'DONE';

EXPLAIN에서 Extra: Using index가 보이면 커버링 인덱스가 작동 중이다. 테이블 랜덤 I/O가 없으니 성능이 극적으로 좋아진다.

JPA + QueryDSL을 쓴다면 페이징 COUNT 쿼리에서 커버링 인덱스를 활용할 수 있다. COUNT(*)는 실제 행 데이터가 필요 없으니 인덱스만으로 처리 가능하다.

인덱스가 무력화되는 6가지 패턴

인덱스를 걸었는데도 안 타는 경우가 있다. 실수하기 쉬운 패턴들이다.

-- 1. 컬럼에 함수 적용
WHERE YEAR(created_at) = 2026 -- ❌ 인덱스 무력화
WHERE created_at >= '2026-01-01' -- ✅ 범위로 변환

-- 2. 앞쪽 와일드카드 LIKE
WHERE name LIKE '%홍길동' -- ❌
WHERE name LIKE '홍길동%' -- ✅ 뒤 와일드카드는 인덱스 사용

-- 3. 컬럼이 다른 OR 조건
WHERE member_id = 1 OR status = 'DONE' -- ❌ (보통 풀스캔)
-- → UNION으로 분리하거나 각각 인덱스 조회 후 합치는 방식 검토

-- 4. 데이터 타입 불일치
WHERE member_id = '123' -- ❌ INT 컬럼에 문자열 → 묵시적 형변환
WHERE member_id = 123 -- ✅

-- 5. 부정 조건
WHERE status != 'DONE' -- ❌ 대부분 풀스캔
WHERE status IN ('PENDING', 'PROCESSING') -- ✅ 이 패턴으로 변환

-- 6. 카디널리티 낮은 컬럼
-- status가 'Y'/'N' 두 가지뿐이면 옵티마이저가 인덱스 대신 풀스캔 선택
-- (50% 이상 행을 어차피 읽어야 하니 풀스캔이 더 효율적이라 판단)

인덱스를 걸어야 할 때, 피해야 할 때

✅ 인덱스를 걸어야 하는 경우
 - WHERE 절에 자주 등장하는 컬럼
 - JOIN 조건으로 쓰이는 컬럼 (FK)
 - ORDER BY, GROUP BY에 사용되는 컬럼
 - 카디널리티가 높은 컬럼

❌ 인덱스를 피해야 하는 경우
 - 카디널리티가 낮은 컬럼 (성별, Y/N 등)
 - 자주 변경되는 컬럼 (INSERT/UPDATE/DELETE 비용 증가)
 - 테이블 데이터가 아주 적은 경우 (풀스캔이 오히려 빠름)
 - 인덱스가 너무 많으면 쓰기 성능 전체 저하

마치며

“쿼리가 느리다"는 증상의 원인 대부분은 인덱스에 있다. 인덱스가 없거나, 있어도 무력화되거나, 복합 인덱스 순서가 잘못됐거나.

느린 쿼리를 만나면 가장 먼저 EXPLAIN을 돌려보자. type: ALL이 보이면 인덱스 문제다. 다음 편에서는 EXPLAIN을 읽는 방법과 트랜잭션·락 동작 원리를 다룬다.