Postgresql 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 완전 정복 #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의 내부 동작 원리를 다룬다.