그냥 Postgres를 쓰세요! 리뷰 데이터베이스를 하나 더 붙이기 전에 던져야 할 질

그냥 Postgres를 쓰세요! - 관계형 데이터베이스를 넘어 AI, 검색, JSON, 시계열, 지리 공간까지
데니스 마그다 지음, 윤명식 옮김 / 제이펍 / 2026년 9월

※ 이 글은 제이펍 서평단 활동을 통해 도서를 제공받아 읽고 작성한 리뷰입니다.

아키텍처 그림에 박스가 하나씩 늘어날 때

시스템 구축 프로젝트를 하다 보면 아키텍처 그림에 박스가 하나씩 늘어나는 순간이 있습니다. 업무 데이터는 관계형 데이터베이스에, 검색은 검색 엔진에, 임베딩은 벡터 데이터베이스에, 비동기 처리는 메시지 브로커에, 센서나 로그 데이터는 시계열 데이터베이스에 넣는 식입니다. 각각의 선택에는 이유가 있지만, 박스가 하나 늘 때마다 설치와 이중화, 백업, 모니터링, 계정과 권한 관리, 보안 점검, 데이터 동기화, 그리고 그것을 운영할 사람까지 함께 늘어납니다. 특히 망 분리가 적용된 공공·금융 환경에서는 새로운 제품 하나를 반입하고 검토받는 과정 자체가 일정에 영향을 줍니다.

『그냥 Postgres를 쓰세요!』는 바로 이 지점에서 질문을 던지는 책입니다. 새로운 데이터 요구가 생겼을 때 전용 데이터베이스를 추가하기 전에, 이미 쓰고 있는 Postgres로 해결할 수 있는지부터 확인해 보자는 것입니다. 제목은 도발적이지만, 저자는 책 앞부분에서 Postgres가 모든 문제의 정답이라는 뜻은 아니라고 분명히 선을 긋습니다. 그래서 이 책은 무조건 Postgres를 쓰라고 외치는 책이라기보다, 기술 스택을 늘리기 전에 한 번 더 따져 보게 만드는 실무 판단의 책에 가깝습니다.

책 정보

원제	Just Use Postgres!
저자	데니스 마그다(Denis Magda)
역자	윤명식
출판사	제이펍
출간일	2026년 9월 10일
분량	468쪽

저자는 썬 마이크로시스템즈와 오라클에서 자바 플랫폼 업무를 하다가 데이터베이스와 대규모 분산 시스템 분야로 옮겨 온 엔지니어입니다. 역자 윤명식 님은 25년 넘게 금융, 게임, 광고, 클라우드 현장에서 데이터베이스 엔지니어이자 아키텍트로 일했고, 은행과 제조 대기업의 PostgreSQL 전환 프로젝트를 여러 차례 수행한 분입니다. 현장에서 Postgres 전환을 직접 해 온 분이 옮겼다는 점은 번역서를 고를 때 적지 않은 신뢰 요소가 됩니다.

구성 — 기본기에서 확장 생태계까지

책은 3부 11장과 부록 2개로 구성됩니다.

• 1부 관계형 데이터베이스로서의 Postgres(1~4장): 도커로 Postgres를 띄우고 psql로 접속하는 것부터 시작해 테이블 설계, 데이터 무결성, 트랜잭션, 조인, 함수와 트리거, 뷰, 역할 기반 접근 제어를 다룹니다. 이어서 CTE, 재귀 쿼리, 윈도 함수 같은 현대적인 SQL과 EXPLAIN을 활용한 인덱스 설계로 넘어갑니다.
• 2부 관계형 모델을 넘어선 핵심 Postgres(5~6장): 별도의 확장 기능 없이 기본으로 제공되는 JSON 처리와 전문 검색을 다룹니다.
• 3부 확장 기능 및 광범위한 생태계(7~11장): 확장 기능의 개념을 짚은 뒤 pgvector를 이용한 벡터 검색과 RAG, TimescaleDB를 이용한 시계열 데이터, PostGIS를 이용한 지리 공간 데이터, LISTEN/NOTIFY와 pgmq를 이용한 메시지 큐까지 살펴봅니다.
• 부록: 다섯 가지 최적화 팁과 ‘Postgres를 사용하지 말아야 할 때’를 담았습니다.

각 장은 음악 서비스, 멀티플레이어 게임, 피자 주문, OpenStreetMap 같은 예제 데이터 세트를 불러와 직접 쿼리를 실행해 보는 흐름으로 진행됩니다. 개념 설명만 읽고 넘어가는 것이 아니라 손으로 확인하면서 읽을 수 있도록 짜여 있습니다.

실무 관점에서 눈여겨본 대목

1. 성능 이슈는 결국 인덱스에서 만난다 — 4장

다른 데이터베이스에서 Postgres로 옮기는 프로젝트든 새로 구축하는 프로젝트든, 오픈 직전에 가장 많이 부딪히는 문제는 느린 쿼리입니다. 4장은 EXPLAIN으로 실행 계획을 읽는 방법부터 단일 칼럼, 복합, 커버링, 부분, 함수 및 표현식 인덱스까지 같은 데이터 세트로 비교해 가며 설명합니다. 특히 조건에 맞는 일부 행에만 인덱스를 만드는 부분 인덱스는, 처리 상태 값이 있는 대용량 업무 테이블에서 바로 활용처가 떠오르는 내용이었습니다. 부록 A의 최적화 팁도 EXPLAIN 익히기, 인덱스 사용 시점 파악, 커넥션 풀링, 필요한 데이터만 조회하기, 데이터베이스의 연산 능력 활용하기로 정리되어 있어 성능 점검 체크리스트로 쓰기 좋습니다.

2. 반정형 데이터와 검색, 전용 제품을 붙이기 전에 — 5~6장

연계 시스템에서 받은 데이터나 설정 정보처럼 구조가 자주 바뀌는 데이터를 JSON으로 저장하고, 자주 조회하는 필드만 인덱스로 받쳐 주는 방식은 실제 설계에서 자주 쓰는 절충안입니다. 5장은 관계형 칼럼과 JSON 사이의 균형을 어떻게 잡을지, 그리고 JSON 데이터를 어떻게 인덱싱할지를 예제로 보여 줍니다. 6장의 전문 검색은 텍스트를 어휘소로 바꾸고, 검색 결과의 순위를 매기고, 결과를 강조하고, 인덱스로 성능을 확보하는 과정까지 다룹니다. 게시판이나 문서 목록 수준의 검색이라면 검색 엔진을 따로 운영하기 전에 충분히 검토해 볼 만한 선택지입니다.

다만 국내 프로젝트에 적용할 때는 따로 챙겨야 할 부분이 있습니다. Postgres의 기본 전문 검색은 한국어 형태소 분석을 기본으로 제공하지 않기 때문에, 한국어 검색 품질이 중요하다면 pg_bigm이나 PGroonga 같은 확장 기능, 또는 별도의 형태소 분석기 연동을 함께 검토해야 합니다.

3. 업무 데이터 옆에 임베딩을 두는 선택 — 8장

생성형 AI 플랫폼을 구축할 때 가장 먼저 나오는 질문 중 하나가 벡터 데이터베이스를 따로 둘 것인가입니다. 8장은 pgvector로 임베딩을 저장하고, 코사인 거리 같은 연산자로 유사도 검색을 수행하고, 임베딩 인덱스로 검색 속도를 확보한 뒤, RAG까지 구현하는 과정을 보여 줍니다.

실무 관점에서 크게 와닿은 부분은 성능보다 관리 측면이었습니다. 원본 업무 데이터와 임베딩이 같은 데이터베이스에 있으면, 문서가 수정되거나 삭제될 때 임베딩도 같은 트랜잭션 안에서 함께 처리할 수 있고, 2장에서 다룬 역할과 접근 제어 체계를 그대로 활용할 수 있습니다. 부서나 등급에 따라 볼 수 있는 문서가 다른 조직에서 RAG를 구축할 때, 권한이 없는 문서가 검색 결과에 섞이지 않도록 하는 일은 생각보다 까다롭습니다. 별도의 벡터 저장소와 원본 데이터베이스 사이의 동기화와 권한을 따로 맞추는 것보다 구조를 단순하게 가져갈 여지가 있다는 점에서 의미 있는 장이었습니다.

4. 메시지 브로커 없이 큐를 만든다면 — 11장

모든 비동기 처리에 전용 메시지 브로커가 필요한 것은 아닙니다. 처리량이 크지 않은 배치 작업이나 알림 발송이라면 테이블 기반 큐로 충분한 경우도 많습니다. 11장은 언제 Postgres를 메시지 큐로 쓰는 것이 적절한지부터 짚고, 커스텀 큐를 직접 구현한 뒤 LISTEN/NOTIFY를 활용하고, pgmq로 넘어가는 순서로 구성됩니다. 워커가 메시지를 가져간 뒤 장애가 나서 처리 중 상태에 멈춰 버린 메시지를 pg_cron으로 주기적으로 복구하는 방법처럼, 실제 운영에서 마주칠 상황까지 짚어 준다는 점이 좋았습니다.

5. 이 책의 균형 감각 — 부록 B

가장 인상적이었던 부분은 부록 B ‘Postgres를 사용하지 말아야 할 때’입니다. 한 가지 기술을 전면에 내세운 책이 스스로 한계를 정리해 두었다는 점에서 책 전체의 신뢰도가 올라갑니다. 기능적으로 가능하다는 것과 그 선택이 해당 조직과 시스템에 맞다는 것은 별개의 문제입니다. 고객에게 아키텍처를 제안하는 입장에서는 이 구분을 분명히 해 두는 것이 무엇보다 중요하기 때문에, 부록 B는 따로 표시해 두고 다시 볼 생각입니다.

참고할 점

• 주제별 깊이: 3부의 벡터 검색, 시계열, 지리 공간, 메시지 큐는 각각 책 한 권이 나올 만한 주제입니다. 이 책은 각 주제를 어디서부터 시작하면 되는지에 초점을 맞추고 있으므로, 대규모 운영이나 세부 튜닝은 공식 문서나 전문 서적으로 이어서 보는 편이 좋습니다.
• 확장 기능 사용 가능 여부: 3부의 내용은 pgvector, TimescaleDB, PostGIS, pgmq 같은 확장 기능을 전제로 합니다. 클라우드 관리형 서비스는 지원하는 확장 기능이 제한될 수 있고, 폐쇄망 환경에서는 확장 기능 패키지를 반입해 설치해야 합니다. 확장 기능마다 라이선스 조건도 다르므로 도입 전에 확인이 필요합니다.
• 분석 플랫폼과는 구분: 이 책이 주로 다루는 범위는 애플리케이션 워크로드입니다. 대용량 데이터를 모아 분석하는 데이터 웨어하우스나 빅데이터 플랫폼까지 Postgres 하나로 대체할 수 있는지는 데이터 규모와 분석 요구에 따라 별도로 판단해야 합니다.
• 실습 환경: 예제는 도커를 기반으로 진행되므로, 사내 PC에서 도커 사용이 제한된다면 실습 환경을 미리 준비해 두는 것이 좋습니다.

이런 분께 권합니다

• Postgres를 관계형 데이터베이스로만 써 왔고, 그 이상을 활용해 보고 싶은 개발자
• 새 요구사항이 생길 때마다 기술 스택이 늘어나는 것이 부담스러운 아키텍트와 PM
• 상용 데이터베이스에서 PostgreSQL로의 전환을 검토하고 있는 팀
• RAG를 구축하면서 벡터 데이터베이스를 따로 도입해야 할지 고민하는 AI 플랫폼 담당자

읽는 순서 제안

• Postgres 입문자: 1부부터 순서대로
• 백엔드 개발자: 3장(현대적인 SQL), 4장(인덱스), 부록 A 중심
• AI·검색 담당자: 5장(JSON), 6장(전문 검색), 8장(생성형 AI) 중심
• 아키텍트: 1장, 7장(확장 기능), 부록 B를 먼저 읽고 필요한 장으로 이동

한 줄 평

데이터베이스를 하나 더 붙이기 전에, 지금 쓰고 있는 Postgres로 되는지부터 확인하게 만드는 책입니다.