백엔드 데이터 인프라 1편 — PostgreSQL이란 + MySQL과의 비교

2026-05-17백엔드 데이터 인프라

백엔드 데이터 인프라 1편. PostgreSQL이 한국 회사 백엔드 신규 표준이 된 이유와 MySQL과의 정확한 차이를 풀어쓴 학습 노트.

📚 백엔드 데이터 인프라 · 1편 — PostgreSQL이란 + MySQL과의 비교

이 글은 백엔드 데이터 인프라 시리즈 70편 중 1편이에요. 자바 백엔드 입문 59편 을 끝까지 보신 분에게 — 그 위에 올라가는 "데이터를 어디에 어떻게 담느냐" 단계. 시리즈 2는 PostgreSQL 46편 + Redis 11편 + Kafka 13편 = 70편 의 큰 호흡이에요.

📚 학습 노트

이 시리즈는 PostgreSQL 18.4 공식 문서, Redis 공식 문서, Apache Kafka 공식 문서를 참고해 한국어 학습 노트로 풀어쓴 자료입니다.

로컬에 Docker로 PostgreSQL·Redis·Kafka를 직접 띄우고 한두 개 만져 보면 본문이 머리에 훨씬 잘 박혀요.

왜 시리즈 2가 데이터부터 시작하나

자바 백엔드 입문 59편이 "Spring으로 코드를 어떻게 짜는가" 였다면, 데이터 인프라 시리즈는 "그 코드가 다루는 데이터를 어디에 담느냐". 백엔드 = "비즈니스 로직 + 데이터 영속화". 영속화 단계가 빠지면 백엔드는 "메모리 위 장난감".

한국 회사 신규 프로젝트의 사실상 표준은 세 가지로 굳었어요. PostgreSQL 이 영속 데이터의 본진(RDBMS), Redis 가 캐시·세션·실시간 처리(인메모리), Kafka 가 이벤트 스트리밍과 시스템 간 메시징. 이 셋의 조합이 거의 모든 백엔드 시스템의 데이터 영역을 채워요. 1편은 그 중 첫 번째 — PostgreSQL 부터.

PostgreSQL이란

PostgreSQL = "객체 관계형 데이터베이스 시스템" (ORDBMS — Object-Relational Database Management System, 관계형에 객체 지향 개념을 얹은 DB). 1986년 UC Berkeley에서 시작한 POSTGRES 프로젝트가 뿌리, 1996년 SQL 지원 추가하며 "PostgreSQL" 로 개명. 35년+ 역사 의 오픈 소스 데이터베이스.

핵심 특성을 한 호흡에 요약하면 — 오픈 소스(PostgreSQL 라이선스, MIT 비슷해서 상업 사용 자유)이고, ACID (Atomicity·Consistency·Isolation·Durability — 트랜잭션 4대 보장) 트랜잭션으로 데이터 무결성을 지키며, SQL 표준 준수도가 MySQL보다 강해요. 인덱스 종류·데이터 타입·언어·외부 데이터 등 확장이 풍부하고, JSONB (JSON Binary — 이진 형식으로 저장해 인덱싱과 부분 갱신이 가능한 PG의 JSON 타입) 로 JSON을 일급 시민처럼 다뤄요. 동시성은 MVCC (Multi-Version Concurrency Control — 같은 데이터의 여러 버전을 두고 읽기·쓰기 충돌을 피하는 방식) 로 — 읽는 사람이 쓰는 사람을 막지 않아요.

현재 최신 안정 버전 = PostgreSQL 18.4 (2026년 기준). 이 시리즈는 18.4 공식 문서를 기반으로 작성.

PostgreSQL vs MySQL — 정확한 비교

한국 회사 면접에서 가장 자주 묻는 비교. 둘 다 RDBMS인데 — 왜 골라야 하나?

PostgreSQL MySQL
시작 1986 (Berkeley POSTGRES) 1995 (MySQL AB)
라이선스 PostgreSQL (오픈 무료) GPL + 상업 (Oracle 소유)
타입 분류 ORDBMS — 객체 관계형 RDBMS — 관계형
SQL 표준 매우 높은 준수도 표준 준수도 낮음 (MySQL 방언 많음)
동시성 MVCC (스냅샷 격리) InnoDB 락 기반
JSON JSONB 1급 지원 (인덱스·연산자) JSON 타입 있지만 PG보다 약함
데이터 타입 풍부 (배열·범위·기하·UUID·네트워크 등) 표준 + 일부 확장
인덱스 B-Tree·Hash·GIN·GiST·BRIN·SP-GiST 등 B-Tree·Hash·Full-text
복제 논리·물리 둘 다 마스터-슬레이브 표준
성능 복잡한 쿼리 강함 단순 쿼리·읽기 빈도 강함
운영 도구 psql + pg_admin mysql + Workbench
한국 시장 신규 프로젝트 증가 레거시 + 일부 신규

한국 회사가 PostgreSQL로 가는 이유

2020년대 중반부터 한국 회사 신규 백엔드 프로젝트가 점점 PostgreSQL을 선택해요. 이유 네 가지를 차례로 풀어볼게요.

(1) JSONB의 압도적 매력

스키마 진화가 빠른 도메인 — 회원 프로필 추가 필드, 상품 옵션, 로그 데이터 — "DDL 없이 JSON 박아두는 게 편한 경우" 가 많아요. PG의 JSONB 는 단순한 JSON 저장에서 멈추지 않아요. GIN (Generalized Inverted Index — 배열·JSON처럼 한 행에 값이 여러 개인 컬럼을 빠르게 검색하는 역색인) 인덱스를 걸 수 있고, ->·->>·@> 같은 연산자가 풍부해서 JSON 안쪽 키를 직접 질의할 수 있어요. 부분 갱신도 지원해서 — "PG 하나로 RDBMS + NoSQL 둘 다" 가능해요. MongoDB 별도 운영 부담을 PG 한 통으로 해결.

(2) SQL 표준 준수 + 풍부한 기능

윈도우 함수, CTE (Common Table Expression — WITH 절로 임시 결과를 만들어 재귀·가독성을 잡는 SQL 표준 문법), LATERAL JOIN (앞쪽 행의 값을 받아 매 행마다 따로 서브쿼리를 도는 조인), 풀텍스트 검색, 범위 타입 등 — "MySQL에선 못 하는 또는 어색한" 쿼리가 PG에선 자연스러움. 복잡한 비즈니스 도메인 (전자상거래·금융·구독·SaaS 등) 에 강함.

(3) MVCC의 우아함

자바 백엔드 입문 47편 영속성 컨텍스트 에서 다룬 동시성 — PG는 MVCC로 "읽는 트랜잭션이 쓰는 트랜잭션을 막지 않음" 을 보장. 같은 행을 동시에 누가 읽고 누가 고쳐도 서로 대기열에 걸리지 않고 각자 자기 시점의 스냅샷을 봐요. 6편에서 깊이.

(4) 오라클 소유의 위험에서 자유

MySQL은 Oracle 소유 (Sun 인수 후). 라이선스·정책 변경 위험이 누적돼서 — Oracle 종속을 피하려는 회사가 PG 또는 MariaDB로. PG는 "진정한 오픈 소스 + 단일 회사 종속 X".

PostgreSQL이 잘 안 어울리는 시나리오

PG가 만능은 아니에요. 다음은 신중:

  • 읽기 빈도 압도적으로 높은 단순 KV (Key-Value — 키 하나로 값 하나만 꺼내는 단순 저장 패턴) — Redis가 더 적합
  • 거대 단순 카운터·로그 — 시계열 DB (InfluxDB·TimescaleDB) 검토
  • 단순 CRUD + 외부 호스팅 비용 민감 — MySQL Cloud (Aurora·RDS MySQL) 가 더 싸기도
  • 레거시 MySQL 운영 + 인력 — 기존 자산 활용 가능

SQL — 시리즈 2 핵심 언어

이 시리즈 PG 46편 거의 모두 SQL을 다뤄요. SQL은 4대 분류로 나뉘는데 — 구조를 정의하는 DDL (Data Definition Language, CREATE·ALTER·DROP), 데이터를 조작하는 DML (Data Manipulation Language, INSERT·UPDATE·DELETE), 조회 전용인 DQL (Data Query Language, SELECT — DML 안에 포함해서 보기도 해요), 권한을 제어하는 DCL (Data Control Language, GRANT·REVOKE) 네 가지. 8편(pg-sql-basics) 부터 표준 SQL을 본격으로 다루고 — 19편부터 PG SQL 깊이 (Part 2) 로.

Spring Data JPA와의 관계

자바 백엔드 입문 44~50편 JPA"엔티티 ↔ 테이블" 자동 매핑이었어요. JPA가 자동 생성하는 SQL이 — 어차피 결국 PG로 흘러들어요. JPA만 알고 PG를 모르면 어디가 막히냐 — 느린 쿼리를 진단할 수 없고, 인덱스를 설계할 수 없고, N+1 문제를 우회할 수 없고, 대용량 데이터 운영이 안 돼요. JPA + PG 양쪽 다 알아야 자바 백엔드 개발자 — 이 시리즈가 그 "양쪽 다" 의 다른 절반.

🎯 시리즈 2 진행

총 70편 = PostgreSQL 46편 + Redis 11편 + Kafka 13편. PG는 튜토리얼(1~18) → SQL 깊이(19~41) → 운영(42~46) 순서로 자연스럽게 흐름. 한 편 800~1,500자, 한 호흡에 한 주제.

한 줄 정리 — PostgreSQL = 35년+ 역사의 ORDBMS. SQL 표준 준수·MVCC·JSONB·풍부한 인덱스로 한국 회사 신규 백엔드 표준 자리. MySQL은 단순 쿼리·레거시 영역에 여전히 강함. JPA만 알고 PG 모르면 운영 단계에서 막힘.

시험 직전 한 번 더 — PostgreSQL 입문자가 매번 헷갈리는 것

  • PostgreSQL = ORDBMS — 객체 관계형 데이터베이스
  • 1986년 Berkeley POSTGRES → 1996년 SQL 추가 → PostgreSQL
  • 오픈 소스 + PostgreSQL 라이선스 (MIT 비슷)
  • 최신 안정 = 18.4 (2026년 기준)
  • ACID 트랜잭션 보장
  • MVCC = 읽는 사람이 쓰는 사람을 막지 않음
  • JSONB = JSON 1급 지원 + GIN 인덱스
  • SQL 표준 준수도 = MySQL보다 높음
  • 풍부한 데이터 타입 = 배열·범위·기하·UUID·네트워크 등
  • 인덱스 종류 = B-Tree·Hash·GIN·GiST·BRIN·SP-GiST
  • 한국 회사 신규 = PG 우세 (2020년대 중반 이후)
  • MySQL = Oracle 소유, 라이선스 위험
  • PG가 잘 어울리는 = 복잡한 쿼리·JSON·동시성
  • PG가 잘 안 어울리는 = 단순 KV(Redis) · 거대 시계열(TimescaleDB)
  • SQL 4대 분류 = DDL·DML·DQL·DCL
  • 시리즈 2 = PG 46 + Redis 11 + Kafka 13
  • JPA만 알고 PG 모르면 = 운영 단계 막힘
  • 인덱스·EXPLAIN·MVCC = 면접 단골
  • psql = PG 표준 CLI
  • pg_admin = PG GUI 도구

시리즈 다른 편 (앞뒤 글 모음)

다음 글:

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

답글 남기기

error: Content is protected !!