Skip to content
VDS · 데이터베이스

PostgreSQL: 설치와 첫 데이터베이스

VDS에 PostgreSQL을 설치하고, 역할과 첫 데이터베이스를 만들고, pg_hba.conf의 인증 방식, 연결 오류 해결 방법을 알아봐요.

업데이트 2026년 8월 23일

PostgreSQL은 Python, Node.js, Go 애플리케이션에서 기본으로 선택하는 데이터베이스예요. MySQL보다 데이터를 더 엄격하게 다루고 복잡한 쿼리를 더 잘 처리해요.

설치

apt update && apt install -y postgresql postgresql-contrib   # Debian, Ubuntu
systemctl enable --now postgresql

AlmaLinux와 CentOS Stream에서는 클러스터를 직접 만들어야 해요:

dnf install -y postgresql-server postgresql-contrib
postgresql-setup --initdb
systemctl enable --now postgresql

버전과 상태를 확인해요:

sudo -u postgres psql -c "SELECT version();"

역할과 데이터베이스

PostgreSQL에서 사용자를 역할이라고 불러요. 프로젝트마다 별도의 역할을 만들어요:

sudo -u postgres psql
CREATE ROLE shop WITH LOGIN PASSWORD 'long-random-password';
CREATE DATABASE shop OWNER shop ENCODING 'UTF8';
REVOKE ALL ON DATABASE shop FROM PUBLIC;

애플리케이션용 연결 문자열은 다음과 같아요:

postgresql://shop:password@127.0.0.1:5432/shop

시스템 사용자에서 확인해요:

psql "postgresql://shop:password@127.0.0.1:5432/shop" -c "\dt"

인증

누가 어디서 로그인할 수 있는지는 두 파일이 결정해요.

/etc/postgresql/17/main/postgresql.conf:

listen_addresses = 'localhost'
port = 5432

/etc/postgresql/17/main/pg_hba.conf — 규칙은 위에서 아래로 읽고, 처음 일치하는 규칙이 적용돼요:

local   all   postgres            peer
local   all   all                 scram-sha-256
host    all   all   127.0.0.1/32  scram-sha-256

peer 방식은 "시스템 사용자가 역할과 일치한다"는 뜻이에요 — 그래서 sudo -u postgres psql은 비밀번호 없이 작동하지만, 다른 사용자가 같은 명령을 실행하면 작동하지 않아요.

수정한 뒤에는 systemctl reload postgresql을 실행해요. trust 방식은 절대 사용하지 마세요 — 비밀번호 없이 누구나 접속할 수 있게 해줘요.

외부 접속은 원격 접속을 참고하세요: 주소로 제한하지 않고 포트를 외부에 열어두면 안 돼요.

자주 발생하는 오류

증상원인
role "..." does not exist역할이 없는 시스템 사용자로 접속하고 있어요
password authentication failedpg_hba.conf의 규칙이 다른 방식을 요구하거나, 비밀번호가 설정되지 않았어요
could not connect to server: No such file or directory서비스가 실행 중이 아니거나, 다른 포트를 사용하고 있어요
permission denied for schema public15+ 버전에서는 public에 대한 권한을 명시적으로 부여해야 해요: GRANT ALL ON SCHEMA public TO shop;
FATAL: sorry, too many clientsmax_connections가 소진됐어요 — 애플리케이션 쪽에 풀을 구성하세요

로그: /var/log/postgresql/ 또는 journalctl -u postgresql.

다음 단계

애플리케이션에 슈퍼유저 역할을 주지 마세요. 일반 데이터베이스 소유자 역할은 필요한 모든 것을 할 수 있지만, 마이그레이션이 잘못돼도 옆 데이터베이스를 삭제할 수는 없어요.