Postgres 하나로 어디까지 가능한지 직접 확인하는 책

오늘날의 Postgres(PostgreSQL)는 관계형 데이터베이스를 넘어, 훨씬 넓은 세계를 품은 범용 데이터베이스로 발전했다. JSON 문서 처리, 전문 검색, 벡터 검색과 RAG, 시계열 데이터, 지리 공간 데이터, 메시지 큐 등 Postgres 하나로 다룰 수 있는 영역은 아주 넓다. 이 책은 바로 그 변화를 개발자가 직접 실행해 보며 납득할 수 있는 방식으로 보여준다. 제목 “그냥 Postgres를 쓰세요!”는 과장된 주장이 아니라, 새로운 데이터 요구가 생길 때마다 용도별로 데이터베이스를 추가하기 전에 먼저 Postgres의 가능성을 확인해 보자는 실용적인 제안이다.
1부는 Postgres를 관계형 데이터베이스로 제대로 사용하는 데 필요한 기본기를 다룬다. Postgres를 시작하고 psql로 연결하는 방법부터 데이터베이스 구조 설계, 데이터 쿼리와 조작, 제약 조건, 외래 키, 트랜잭션, 조인, 함수, 트리거, 뷰, 접근 제어까지 RDBMS로서의 핵심 기능을 차근차근 살핀다. 이어 CTE, 재귀 쿼리, 윈도 함수 같은 현대적 SQL 기능과 다양한 인덱스 활용법을 다루며, Postgres를 단순 저장소가 아니라 애플리케이션 성능과 구조를 함께 책임지는 도구로 바라보게 한다.
2부는 관계형 모델을 넘어 Postgres가 기본으로 제공하는 JSON 처리와 전문 검색을 다룬다. JSON 객체 저장, 조회/수정, B-트리와 GIN 인덱스로 검색 성능을 높이는 과정, 그리고 텍스트를 어휘소로 변환하는 것부터 순위 매기기, 검색 결과 강조, GIN/GiST 인덱싱까지의 과정을 살펴본다.
3부는 Postgres의 확장 생태계를 훑어본다. pgvector를 이용해 임베딩을 저장하고 벡터 유사도 검색과 RAG 흐름을 구성하는 장은 생성형 AI 시대의 요구와 직접 맞닿아 있고, TimescaleDB를 활용한 시계열 데이터 관리/분석, PostGIS를 활용한 공간 데이터 처리, LISTEN/NOTIFY와 pgmq를 이용한 메시지 큐 패턴까지 차례로 살펴본다. 넓은 각 주제에 대해 세부 이론에 매몰되지 않고 “내 애플리케이션에서 어디부터 시작하면 되는가”에 초점을 맞춘다.
다섯 가지 최적화 팁과 ‘Postgres를 사용하지 말아야 할 때’까지 다룬 부록은 이 책의 균형 감각을 잘 보여준다. Postgres를 만능으로 포장하지 않고 강점과 한계를 함께 보며 실무적인 판단을 돕는다. 관계형 데이터베이스로만 Postgres를 써왔던 개발자, 새로운 요구사항이 생길 때마다 기술 스택이 늘어나는 것이 부담스러운 팀, 그리고 현대 애플리케이션의 데이터 처리를 더 단순하고 견고하게 설계하고 싶은 DB 실무자에게 이 책은 꼭 필요한 단 한 권의 안내서가 되어줄 것이다.

주요 내용
트랜잭션 워크로드를 처리하는 RDBMS로 Postgres 활용하기
CTE, 재귀 쿼리, 윈도 함수, 다양한 인덱스로 SQL 활용도와 성능 높이기
JSON 문서를 저장/조회/수정하고 애플리케이션 데이터 모델에 적용하기
Postgres의 전문 검색 기능으로 텍스트 검색 기능 구성하기
pgvector로 벡터 유사도 검색과 RAG 흐름 만들어보기
TimescaleDB와 PostGIS로 시계열/지리 공간 데이터 다루기
LISTEN/NOTIFY와 pgmq로 메시지 큐 패턴 활용하기
Postgres에 적합한 사용 사례와 그렇지 않은 사례 판단하기

책 속에서

수년에 걸쳐 “그냥 Postgres를 쓰세요!”는 사실상 Postgres 커뮤니티의 모토가 되었으며, 데이터베이스가 이제 감당할 수 있는 사용 사례의 폭과 깊이를 함축적으로 담아내고 있습니다. / 그렇다면 Postgres가 만능 도구가 되어 모든 개발자에게 필요한 유일한 데이터베이스가 되었다는 뜻일까요? 결코 그렇지 않습니다. / “그냥 Postgres를 쓰세요!”는 수십 년간 Postgres를 구축하고 사용해 온 전문가들이 건네는 합리적인 조언으로 받아들이시기 바랍니다. 이미 Postgres를 사용하고 있거나 도입을 계획 중인데, 지리 공간·시계열·생성형 AI와 같은 새로운 사용 사례를 지원해야 하는 상황이라면, 기술 스택에 다른 데이터베이스를 추가하기 전에 먼저 Postgres로 해결할 수 있는지 확인해 보시기 바랍니다. (6쪽)

데이터베이스 역할이 애플리케이션이 허용하는 범위를 초과하는 광범위한 권한을 가지고 있다면, 그것은 이미 잠재적인 문제입니다. 애플리케이션 사용자 계정이 탈취될 경우, 공격자가 데이터베이스에 직접 접근하여 애플리케이션 로직이 의도했던 범위를 훨씬 벗어나는 작업을 수행할 위험이 있기 때문입니다. / Postgres에서 역할은 데이터베이스 수준의 접근 권한을 정의하고 관리하는 데 사용됩니다. 역할은 설정 방식에 따라 데이터베이스 사용자가 될 수도 있고, 사용자 그룹이 될 수도 있습니다. 따라서 “사용자 X를 사용해 Postgres에 접속한다”는 말은 기술적으로 “역할 X를 사용하여 데이터베이스 연결을 수행한다”는 의미와 같습니다. / 역할을 활용하면 접근 제어를 매우 세밀하게 조정할 수 있습니다. 이를 통해 애플리케이션 사용자가 필요한 만큼의 권한만 갖고 그 이상은 제한하는 최소 권한 원칙(principle of least privilege)을 데이터베이스 수준에서 보장할 수 있습니다. (70쪽)

부분 인덱스는 인덱스 생성 시 WHERE 절을 사용하여 정의합니다. / CREATE INDEX partial_index_name ON table_name(columnA) WHERE condition; / 이 예시에서 부분 인덱스는 columnA에 생성되지만, 오직 특정 조건을 만족하는 행들만 포함합니다. / 부분 인덱스는 데이터의 특정 부분 집합에 대한 쿼리를 최적화하면서 나머지 데이터는 무시하고 싶을 때 특히 유용합니다. 또한 인덱스 크기가 더 작고, 조건에 맞지 않는 행이 수정될 때는 인덱스를 업데이트할 필요가 없으므로 테이블 업데이트 속도가 빨라집니다. 예를 들어 대규모 테이블이 있지만 애플리케이션이 특정 데이터 집합만 빈번하게 조회한다면, 부분 인덱스를 통해 쿼리를 최적화하고 메모리와 디스크 같은 시스템 자원을 훨씬 효율적으로 사용할 수 있습니다. (141쪽)

pgvector 확장 기능은 코사인 거리(〈=〉), 유클리드 거리(〈-〉), 내적(〈#〉) 등 여러 거리 연산자를 제공합니다. 코사인 거리는 텍스트 데이터에서 생성된 임베딩을 비교하는 생성형 AI 애플리케이션에서 일반적으로 선택되는 방식으로, 특히 임베딩이 L2 정규화된 경우(길이가 항상 1인 경우)에 적합합니다. 이 방법은 두 벡터 임베딩 사이의 각도의 코사인을 계산합니다. (…) 예를 들어 그림 8.7은 2차원 공간에서 연관성이 높은 벡터 임베딩과 낮은 벡터 임베딩 사이의 각도 차이를 보여줍니다. “May the force be with you(포스가 함께하길)”라는 문구와 “Star Wars …” 설명 사이의 각도 a는 동일한 문구와 “Jurassic Park …” 영화 설명 사이의 각도 b보다 작습니다. 이는 해당 문구가 〈스타워즈〉에서는 자주 등장하지만 〈쥬라기 공원〉에서는 전혀 등장하지 않기 때문입니다. (263~264쪽)

BRIN은 특정 칼럼의 값이 테이블 내부 구조의 물리적 위치와 강력한 상관관계를 가질 때 매우 효과적으로 작동하도록 설계되었습니다. (…) 또한, 우리의 시계열 데이터는 항상 테이블 끝에 추가만 되고 기존 데이터가 수정되지 않기 때문에, 심박수 측정 행들은 가용 페이지를 차례대로 채워나가게 됩니다. 한 페이지에 추가되는 각 새로운 행은 이미 해당 페이지에 있는 행들의 시간과 강력한 상관관계를 가집니다. 서로 다른 기기의 측정값이 섞이더라도 시간 차이는 크게 벌어지지 않습니다. (330쪽)

다른 시나리오에서는 소비자가 큐에서 다음 메시지를 가져와 처리를 시작했다가 어떤 이유로 실패할 수 있습니다. 예를 들어 생산자가 작업을 큐에 넣고 워커들이 이를 가져와 실행하는 작업 스케줄링 시스템을 생각해 보십시오. 워커가 하나 이상의 작업을 가져온 후 장애가 발생하면, 해당 작업들은 계속 processing 상태로 남게 됩니다. / 이를 완화하기 위해, 메시지가 제한된 시간 동안만 processing 상태를 유지할 수 있도록 하는 장애 복구 메커니즘을 도입할 수 있습니다. 설정된 시간 임계값이 만료되면 메시지 상태가 다시 new로 재설정되어 다른 워커가 이를 가져가 처리할 수 있게 됩니다. 이는 데이터베이스에 주기적인 작업을 예약하는 pg_cron 확장 기능을 사용하여 자동화할 수 있으며, processing 상태에 갇힌 메시지를 체크하고 그 상태를 new로 복구하는 로직을 수행합니다. (406~407쪽)