백엔드 데이터 인프라 42편 — 운영 설치 바이너리·Docker·관리 서비스

이 글은 백엔드 데이터 인프라 시리즈 70편 중 42편이에요. Part 3 운영의 시작. 2편 로컬 설치 가 "개발 PC" 였다면, 이번 42편은 운영 환경 PG 설치 옵션 비교.

운영 PG 4가지 선택

소규모 = 관리 서비스 (RDS), 중규모 = 관리 서비스 또는 Docker, 대규모 = 직접 바이너리 + 전담 DBA. 한국 회사 대부분 = 관리 서비스.

직접 바이너리 — apt·yum

# Ubuntu·Debian
sudo apt install postgresql-18 postgresql-contrib

# RHEL·CentOS
sudo dnf install postgresql-server postgresql-contrib

# 초기화·시동
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

완전한 제어가 장점이지만 OS 설치·튜닝·복구·HA(고가용성)까지 전부 본인 손에 달렸다.

Docker — 운영용 설정

# docker-compose.yml
services:
  postgres:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./postgresql.conf:/etc/postgresql/postgresql.conf
      - ./pg_hba.conf:/etc/postgresql/pg_hba.conf
    command:
      - postgres
      - -c
      - config_file=/etc/postgresql/postgresql.conf
    secrets:
      - db_password
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 10s
    ports:
      - "5432:5432"

secrets:
  db_password:
    file: ./secrets/db_password.txt

volumes:
  pgdata:

운영 Docker = secrets·healthcheck·volume·외부 설정 4가지.

AWS RDS — 가장 흔함

[Spring App] → [Application Load Balancer] → [RDS PostgreSQL Primary]
                                                ├→ Read Replica 1
                                                └→ Read Replica 2

장점이 많다. 자동 백업·복구가 기본으로 따라오고 Multi-AZ(다중 가용영역) 자동 페일오버도 클릭 한 번이다. Read Replica 추가는 쉽고 패치·업그레이드는 자동이며 모니터링은 CloudWatch·RDS Performance Insights로 통합된다.

단점도 분명하다. 슈퍼유저 권한이 없어서 PG 확장 일부가 제한되고 비용도 작은 인스턴스조차 월 $50 이상.

설정 핵심은 세 줄. db.t4g.medium 작게 시작해서 트래픽 따라 스케일 업, Multi-AZ는 운영이면 무조건 켠다, 자동 백업은 7~30일.

AWS Aurora PostgreSQL — 더 강력

Aurora = AWS 의 "PG 호환 분산 스토리지".

큰 트래픽·금융·중요 시스템 = Aurora. 일반 = RDS.

Google Cloud SQL·Azure DB

비슷한 관리 서비스. 클라우드 전체 스택에 맞춰 선택. Spring 백엔드 = AWS RDS 가 한국에서 가장 흔함.

서버리스 — Neon·Supabase

[Spring App] → [Neon HTTP API] → [Neon Storage]

서버리스의 매력은 네 가지로 정리된다. 항상 켜진 RDS와 달리 사용량만큼 과금되고 자동으로 sleep·wake가 일어난다. Git 처럼 DB 브랜치를 따는 Branching도 가능하고 학습이나 작은 사이드 프로젝트에 잘 맞는다.

대규모 운영엔 아직 RDS·Aurora 우세.

옵션 선택 룰

99% 한국 회사 = AWS RDS 또는 Aurora.

환경 분리 — dev·staging·prod

[로컬 개발] → Docker (개발자 PC)
[CI 테스트] → Testcontainers (자바 백엔드 입문 54편)
[Dev]       → 작은 RDS 인스턴스
[Staging]   → 운영과 동일 구성 (작은 사이즈)
[Prod]      → RDS Multi-AZ + Read Replica

각 환경의 PG 버전·확장·설정 일치가 운영 안전의 토대. CI(지속 통합) 단계에서 Testcontainers 로 실제 PG 띄워 테스트하는 게 표준.

버전 선택

• 새 프로젝트 = PG 18 (또는 LTS(장기지원) 16)
• 운영 중 = 기존 버전 유지, 1~2년 후 major 업그레이드

PG 메이저 버전 = 1년에 한 번. 최신 버전 즉시 채택은 위험 — 1~2년 안정화 후 채택이 운영 표준.

함정 5가지

(1) 작은 인스턴스 + 큰 트래픽

운영 시작 시 너무 작은 인스턴스 → 갑작스러운 트래픽에 폭주. 모니터링 + 스케일링 정책.

(2) Multi-AZ 안 켬

운영 = Multi-AZ 무조건. 단일 인스턴스 = 장애 시 다운타임.

(3) 자동 백업 잘못 설정

RDS 자동 백업 = 7~30일 보존. 너무 짧으면 — 한 달 전 데이터 복구 불가.

(4) Aurora·RDS 혼동

비슷해 보이지만 — 가격·성능·확장성 모두 다름. 큰 결정.

(5) 직접 바이너리 + 작은 팀

DBA 없는 5인 팀이 직접 PG 운영 = 위험. 관리 서비스가 훨씬 안전.

한 줄 정리 — 운영 PG 4옵션 = 직접·Docker·RDS·서버리스. 한국 99% = AWS RDS Multi-AZ. 큰 트래픽 = Aurora. PG 18 신규, 운영은 LTS. dev·staging·prod 환경 일치. Multi-AZ + 자동 백업 + Read Replica 표준.

시험 직전 한 번 더 — 운영 설치 입문자가 매번 헷갈리는 것

• 운영 옵션 4 = 직접·Docker·관리 서비스·서버리스
• 한국 99% = AWS RDS
• 큰 트래픽 = AWS Aurora
• Aurora = 분산 스토리지·빠른 페일오버·1.5~2배 비용
• 관리 서비스 = 슈퍼유저 X (확장 일부 제한)
• Multi-AZ = 운영 무조건
• Read Replica = 읽기 부하 분산
• 자동 백업 7~30일
• PITR = Point-In-Time Recovery
• 작은 인스턴스 시작 + 스케일링
• dev·staging·prod 환경 일치
• Testcontainers (CI) = JPA 입문 54편
• 버전 = LTS 안정화 후 채택
• Docker 운영 = secrets·healthcheck·volume
• pg_isready = 헬스 체크
• Neon·Supabase = 서버리스 (사이드 프로젝트)
• Cloud SQL·Azure DB = 비슷
• 직접 바이너리 = 전담 DBA 필요
• 학습 = Docker 로컬
• PG 18 = 2025 신버전
• RDS 비용 = 작은 t4g.medium 월 $50+
• 모니터링 = CloudWatch + Performance Insights

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 37편 — MVCC 소개
• 38편 — MVCC 격리 수준과 동시성 함정
• 39편 — 전문 검색 to_tsvector to_tsquery
• 40편 — EXPLAIN 쿼리 계획 읽기
• 41편 — 성능 팁 종합

다음 글:

• 43편 — postgresql.conf 핵심 설정
• 44편 — 사용자·역할 관리 CREATE ROLE GRANT
• 45편 — 데이터베이스 관리 생성·복제·드롭
• 46편 — 백업과 복구 pg_dump·PITR
• 47편 — Redis란 + PostgreSQL과의 역할 분담