---
title: "pg_background: PostgreSQL 안에서 비동기 SQL 실행을 가능하게 하는 확장"
published: 2026-02-17T22:40:11.000Z
canonical: https://jeff.news/article/942
---
# pg_background: PostgreSQL 안에서 비동기 SQL 실행을 가능하게 하는 확장

pg_background는 PostgreSQL 백그라운드 워커에서 SQL을 비동기 실행하는 확장으로, 클라이언트 커넥션 점유 없이 장시간 쿼리나 자율 트랜잭션을 처리할 수 있음. v1.6~v1.8을 거치며 v2 API, 보안 강화, 운영 제어 GUC 등이 추가되어 프로덕션 레벨로 성숙함.

## pg_background: PostgreSQL 안에서 비동기 SQL 실행을 가능하게 하는 확장

- pg_background는 PostgreSQL 내부의 백그라운드 워커 프로세스에서 SQL을 비동기로 실행할 수 있게 해주는 확장임
- 클라이언트 세션을 점유하지 않고 무거운 쿼리를 실행할 수 있어서, 별도의 외부 잡 시스템 없이도 Postgres 네이티브하게 비동기 처리가 가능함

## 핵심 기능

- 장시간 실행 쿼리를 클라이언트 커넥션 점유 없이 실행 가능
- 호출자의 트랜잭션과 독립적으로 commit/rollback하는 "자율 트랜잭션(autonomous transaction)" 스타일 지원
- 워커를 모니터링, 대기, 분리(detach), 취소(cancel)할 수 있는 명시적 제어 제공
- 스케줄러나 큐잉 플랫폼이 아님 — "이 SQL을 저쪽에서 실행해라"에 집중하는 날카로운 도구임

## v2 API — 운영 환경에서는 필수

- (pid, cookie) 핸들 기반으로 PID 재사용 문제를 방지함 — 장기 운영 시스템에서 실제로 발생하는 문제임
- cookie 기반 신원 확인, 명시적 취소 vs 분리 구분, 동기 대기, 리스트 함수를 통한 모니터링 지원
- 신규 배포라면 v2 API 사용이 강력히 권장됨

## 릴리스 히스토리 (v1.6 ~ v1.8)

### v1.6 (2026년 2월 5일)
- 프로덕션 안정화 릴리스로 v2 API가 공식 권장 API로 등장
- PostgreSQL 12~18 호환
- DSM 라이프사이클 처리 개선, NULL 안전성, 레이스 컨디션 수정, 메모리 컨텍스트 누수 수정 포함

### v1.7 (2026년 2월 13일)
- 보안 강화: cookie 생성에 `pg_strong_random()` 사용 (암호학적으로 안전)
- 전용 `WorkerInfoMemoryContext` 도입으로 장기 세션의 메모리 비대화 방지
- wait/cancel 루프에 지수 백오프(exponential backoff) 폴링 적용으로 CPU 부하 감소

### v1.8 (2026년 2월 13일)
- PostgreSQL 14+가 최소 지원 버전으로 변경됨
- 새 GUC 설정 추가: `pg_background.max_workers`, `worker_timeout`, `default_queue_size`
- `pg_background_stats_v2()`, `pg_background_progress()` 등 통계/진행률 함수 추가
- Docker 기반 CI 리팩토링 및 패키징 개선

## 실전 활용 사례

- **백그라운드 VACUUM / ANALYZE / REINDEX**: DBA 작업을 세션 블로킹 없이 실행
- **비동기 백필/데이터 보정**: 대량 데이터 작업을 백그라운드로 위임
- **Fire-and-forget 감사 로그/Outbox 기록**: 트랜잭션 결과와 무관하게 사이드 이펙트 기록
- **"비싼 작업은 나중에" 패턴**: OLTP 중심 앱에서 무거운 처리를 분리

## 운영 시 반드시 알아야 할 점

- 백그라운드 워커는 `max_worker_processes`를 소비함 — 용량 버짓으로 관리해야 함
- **detach는 cancel이 아님**: detach는 "추적 중단"이지 "실행 중단"이 아님. 이 구분이 핵심임
- 결과는 한 번만 소비 가능 — 재사용이 필요하면 별도 저장해야 함
- v1.8의 max_workers, timeout, queue_size GUC로 세션당 워커 수와 리소스를 제한하는 것이 권장됨

## 정리

- 외부 잡 큐(Celery, Sidekiq 등)를 도입하기 전에, PostgreSQL 자체의 비동기 실행이 충분한지 먼저 검토해볼 만한 도구임
- 특히 "커넥션 풀 고갈 없이 무거운 쿼리를 돌리고 싶다"는 요구사항에 정확히 부합함
- v1.6~v1.8의 빠른 릴리스 사이클을 보면 프로덕션 환경에서의 실전 피드백이 적극 반영되고 있음이 느껴짐

[원문 링크](https://vibhorkumar.wordpress.com/2026/02/16/pg_background-make-postgres-do-the-long-work-while-your-session-stays-light/)

## 핵심 포인트

- 클라이언트 세션 블로킹 없이 PostgreSQL 내부에서 비동기 SQL 실행 가능
- v2 API는 (pid, cookie) 핸들로 PID 재사용 문제 방지
- v1.8에서 max_workers, worker_timeout 등 운영 제어용 GUC 추가
- detach와 cancel의 의미 차이가 운영상 핵심 — detach는 추적 중단이지 실행 중단이 아님

## 인사이트

외부 잡 큐를 도입하기 전에 PostgreSQL 자체의 비동기 실행 능력을 먼저 검토해볼 만한 실용적 도구. 커넥션 풀 고갈 문제를 서버 내부에서 해결하는 접근이 인상적임.