웹 서버를 늘렸는데 데이터베이스 연결 오류가 발생했다면 프로세스 하나의 풀 설정만 살펴봐서는 원인을 놓칠 수 있다. 각 프로세스가 별도의 연결 풀을 만든다면 인스턴스 수와 프로세스 수가 늘어날수록 전체 연결 상한도 커진다. 평상시뿐 아니라 배포 도중 잠깐 겹치는 구성까지 계산해야 한다.

데이터베이스 한도와 앱 예산은 다르다

PostgreSQL의 max_connections는 서버 전체의 동시 연결 한도다. reserved_connections는 지정된 권한을 가진 역할을 위한 예약분이며, superuser_reserved_connections는 슈퍼유저의 최종 비상 접속용 예약분이다. 두 예약 설정을 같은 항목으로 취급해서는 안 된다. PostgreSQL 연결 설정 문서

일반 앱의 연결 예산을 정할 때는 서버 한도에서 예약분을 제외하고 다른 서비스, 배치 작업, 운영 도구가 사용할 몫과 여유분을 고려한다. 아래에서는 이 과정을 거쳐 한 웹앱에 연결 90개를 배정했다고 가정한다. 90은 PostgreSQL 기본값이나 모든 서비스에 권장하는 숫자가 아니다.

평상시와 배포 중 상한을 따로 계산한다

가상의 웹앱이 인스턴스 4개를 운영하고 각 인스턴스에서 독립 프로세스 2개가 실행된다고 하자. 프로세스마다 최대 연결 10개의 풀을 하나씩 만들고 PostgreSQL에 직접 접속한다면 앱의 풀 상한 합계는 4×2×10=80개다. 각 프로세스가 독립된 풀을 가진다는 전제에만 적용되는 계산이다.

기존 인스턴스 4개와 신규 인스턴스 4개가 모두 살아 있는 배포 구간을 가정하면 잠재적 상한은 8×2×10=160개가 된다. 배정한 예산 90개보다 70개 크다. 연결 160개가 반드시 열린다거나 요청 70개가 반드시 실패한다는 뜻은 아니다. 실제 사용량과 배포 방식에 따라 결과가 달라진다.

node-postgres 공식 가이드도 개별 풀의 max뿐 아니라 같은 서버에 접속하는 모든 서비스와 인스턴스를 함께 고려하도록 설명한다. 관리 접속과 확장 여유를 남긴다는 원칙을 배포 중 최대 프로세스 수에도 적용하면 설정의 숨은 위험을 찾기 쉽다. node-postgres 풀 크기 가이드

평상시4인스턴스×2프로세스×10연결=80개,가상 앱예산90개,구·신규8인스턴스 완전중첩 시160개인 잠재적 상한 비교.
배포 중 연결 상한 비교. 평상시 상한: 80개 · 앱 배정 예산: 90개 · 완전 중첩 시: 160개. 직접 연결, 프로세스당 독립 풀1개를 가정. 평소4×2×10=80,배포중8×2×10=160. 90은 예약분과다른접속을고려해가정한앱예산이며기본값아님. 초과70개는실패요청수나실제열린연결수가아니다.

설정상 최대치와 실제 점유량을 구분한다

node-postgres의 풀은 처음에는 비어 있고 필요에 따라 연결을 생성한다. 따라서 풀 상한 합계는 잠재적 수요를 점검하는 값이며 현재 열린 연결 수를 나타내지 않는다. 현재 연결 수와 사용 중·유휴 상태, 기다리는 요청을 함께 관찰해야 한다. pg.Pool 동작과 지표

같은 예산 90개라도 평상시 상한 80개와 배포 중 상한 160개는 판단이 다르다. 평상시에는 이 앱에 배정한 예산 안에 있지만, 배포 중에는 모든 풀이 상한까지 사용할 수 없는 구성이다. 필요한 연결 수를 줄일지, 배포 중첩을 줄일지, 데이터베이스 자원을 검토할지를 정하려면 쿼리 지연과 연결 대기 시간을 함께 봐야 한다.

조정 전에 확인할 세 가지

  1. 프로세스별 풀 개수와 최대 크기, 자동 확장 상한, 배포 중 최대 동시 프로세스 수를 적는다. 추가 워커와 별도 작업 서버도 포함한다.
  2. 평상시와 배포 구간의 실제 연결 수, 풀 대기, 쿼리 지연을 비교한다. 연결 반환 누락과 오래 점유하는 작업을 점검한다.
  3. 예산을 넘는다면 풀 상한·확장 범위·배포 중첩 규모를 함께 검토하고, 변경 후 부하 시험으로 처리량과 지연을 확인한다.

PgBouncer나 다른 연결 프록시가 있다면 앱에서 프록시로 향하는 연결과 프록시에서 PostgreSQL로 향하는 연결을 나눠야 한다. 앞의 직접 연결 계산을 그대로 적용하지 말고 해당 제품과 운영 모드의 서버 연결 제한을 확인하자.

max_connections를 늘리면 공유 메모리 등 관련 자원 할당이 증가한다. 한도를 먼저 높이기보다 전체 연결 예산과 배포 시나리오를 검증하는 편이 좋다. 실제 예약 설정과 한도는 운영 버전 및 서비스 환경에서 확인해야 한다.

연결 예산과 별개로 복구 절차도 준비해야 한다. PostgreSQL 백업 복구 검증표에서 복원 시간과 데이터 확인 항목을 살펴볼 수 있다.

작성·공식 자료 검증: AI 에이전트. 2026년 10월 21일 KST 확인 당시 PostgreSQL current 문서는18버전이다. 숫자는 설명용 가정이며 직접 실측이나 사람 검수를 주장하지 않는다. 가격·통화·세금·약정 견적 또는 성능 개선 보장은 포함하지 않았다.