PostgreSQL 하나로 문서·검색·벡터·큐까지 대체하는 현실적인 방법

핵심 메시지

• 전형적인 아키텍처는 DB·문서 저장소·검색·벡터 DB·큐 등 다섯 개의 별도 시스템으로 나뉘지만, 상당수는 PostgreSQL 하나로 합칠 수 있다.
• PostgreSQL은 1980년대 버클리 연구 프로젝트에서 출발했고, 개발자 설문에서 해마다 가장 많이 쓰이고 계속 쓰고 싶은 DB로 꼽힌다.
• JSONB(문서), 전문 검색, pgvector(벡터), PostGIS(공간), LISTEN/NOTIFY와 SKIP LOCKED(큐) 등으로 별도 서버 없이 기능을 흡수한다.
• MVCC, 쓰기 전 로그(WAL), VACUUM 같은 내부 구조 덕분에 읽기와 쓰기가 서로를 기다리지 않고, 장애에도 데이터 일관성을 유지한다.
• 캐시(Redis), 대규모 쓰기 분산, 수십억 행 분석 등 극단적 영역에서는 전용 도구가 더 낫다는 점도 솔직히 인정해야 한다.

쉽게 이해하기

영상은 흔히 보는 ‘진짜처럼 보이는’ 아키텍처 그림으로 시작한다. 주 데이터용 관계형 DB, 별도의 문서 저장소, 검색 서비스, AI 기능을 위한 벡터 DB, 그리고 큐까지 다섯 개의 독립된 시스템이다. 문제는 이 각각을 직접 운영하고, 감시하고, 비용을 내야 한다는 점이다. 발표자는 이 중 상당수가 사실 별도 시스템이 필요 없다고 말한다.

그 해법이 PostgreSQL이다. 새로 유행하는 기술이 아니라 1980년대 버클리에서 시작된 오래된 프로젝트지만, 대형 개발자 설문에서 가장 많이 쓰이면서 동시에 계속 쓰고 싶다는 응답이 가장 많은 DB로 꼽힌다. 핵심은 PostgreSQL이 ‘확장 가능하도록’ 설계됐다는 점이다. 새로운 데이터 타입, 새로운 인덱스, 새로운 기능을 코어 엔진에 끼워 넣는 정식 방식이 존재한다.

구체적으로는 JSONB 타입으로 스키마 없는 JSON 문서를 저장·조회하고, 내장 전문 검색으로 단어 단위 매칭과 관련도 순위, 어간 처리까지 처리한다. pgvector 확장을 켜면 임베딩을 한 컬럼에 담아 의미 검색과 RAG를 위한 최근접 탐색을 할 수 있고, PostGIS는 거리·도형·영역 계산이 필요한 강력한 공간 엔진이 된다. LISTEN/NOTIFY는 발행-구독을, SELECT FOR UPDATE SKIP LOCKED는 여러 워커가 동시에 꺼내 쓰는 안전한 작업 큐를 만들어 준다.

영상은 자주 절반만 쓰는 SQL 기능도 짚는다. 윈도 함수로 애플리케이션 루프 없이 누적 합계·순위·이동 평균을 구하고, CTE(WITH)로 쿼리를 단계별로 읽기 쉽게 나누거나 재귀로 트리를 한 번에 순회한다. INSERT ... ON CONFLICT DO UPDATE는 경쟁 상태 없이 한 문장으로 삽입 또는 갱신을 처리하고, RETURNING은 방금 바꾼 행을 곧바로 돌려준다.

성능 면에서는 EXPLAIN ANALYZE로 실제 실행 계획과 시간을 확인하고, 순차 스캔이 문제일 때 적절한 인덱스(B-tree, JSONB·전문 검색용 GIN, 공간용 GiST, 대용량 정렬 데이터용 BRIN)를 더한다. 다만 인덱스는 읽기를 빠르게 하는 대신 쓰기를 느리게 만드는 거래이므로, 정말 읽기가 아픈 곳에만 추가해야 한다.

주요 인사이트

• PostgreSQL은 ‘로고만 다른 MySQL’이 아니라, 옆에 따로 세웠을 도구들을 흡수하며 자라는 플랫폼에 가깝다. CREATE EXTENSION 한 줄로 엔진에 새 능력이 생긴다.
• MVCC는 업데이트 시 행을 제자리에서 바꾸지 않고 새 버전을 쓰고 옛 버전을 남겨, 먼저 시작한 트랜잭션은 일관된 스냅샷을 계속 읽는다. 그래서 읽는 쪽은 쓰는 쪽을, 쓰는 쪽은 읽는 쪽을 기다리지 않는다.
• 옛 버전이 계속 쌓이지 않도록 VACUUM과 자동 VACUUM이 죽은 행을 정리한다. ‘PostgreSQL은 튜닝할 필요가 없다’는 생각이 언젠가 발목을 잡는 이유가 바로 이 보이지 않는 정리 작업이 한계에 닿는 날이다.
• WAL(쓰기 전 로그)은 변경을 실제 데이터 파일에 적용하기 전에 먼저 디스크에 기록해 장애 시 재생으로 일관성을 복구하고(ACID의 내구성), 같은 로그를 다른 서버로 흘려보내면 실시간 복제본이 된다.
• 확장성에서 읽기는 복제본으로 쉽게 늘리지만 쓰기는 한 대의 프라이머리가 모두 받는 구조라 어렵다. 서버리스 함수가 제각기 연결을 열면 서버가 무너지므로 PgBouncer 같은 연결 풀러를 일찍 도입하는 것이 좋다.

자주 묻는 질문

관련 AI 소식