Mvcc on kastori

[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 완전 정복 #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을 다룬다.