PostgreSQL 고가용성 & 모니터링 + AI 운영 자동화 (시리즈 완결)
테스트 환경: PostgreSQL 17, Rocky Linux 9 / Oracle 19c
드디어 이 시리즈의 마지막 편입니다. 15편에 걸쳐 Oracle DBA 관점에서 PostgreSQL을 정리해왔는데, 그 대미를 장식할 주제는 고가용성(HA), 모니터링, 그리고 AI를 활용한 운영 자동화입니다.
운영의 궁극적 목표는 하나입니다. "서비스가 멈추지 않게 하는 것." Oracle에서 Data Guard, RAC로 이걸 달성했다면, PostgreSQL은 스트리밍 복제를 기반으로 합니다. 이번 편에서 그 방법과, 15년 경험에 AI를 더하는 법까지 정리합니다.
이번 편은 운영 시리즈의 마지막이자 PostgreSQL 시리즈 전체의 완결편입니다.
- 스트리밍 복제 (고가용성의 기반)
- RPO/RTO로 HA 전략 선택
- 모니터링 필수 뷰와 지표
- ★ Claude로 PostgreSQL 운영 자동화
- 시리즈 전체 마무리
스트리밍 복제 - 고가용성의 기반
PostgreSQL의 모든 HA는 스트리밍 복제에서 출발합니다. Oracle의 Data Guard에 해당한다고 보시면 됩니다.
기본 개념
Primary (읽기+쓰기): 모든 변경이 여기서 발생
↓ WAL을 실시간 전송
Standby (읽기 전용): Primary의 복제본, 장애 시 승격
14편에서 배운 WAL이 여기서 다시 등장합니다. Primary의 WAL을 Standby로 계속 흘려보내서(streaming) 두 서버를 동기화하는 거죠.
3가지 용도
1. 고가용성(HA): Primary가 죽으면 Standby로 전환
2. 읽기 분산: SELECT 부하를 Standby로 분산
3. 재해복구(DR): 다른 지역에 복제본 유지
기본 설정 (Primary)
# postgresql.conf
wal_level = replica
max_wal_senders = 10
-- 복제 전용 유저 (REPLICATION 권한, 9편 참고)
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'secret';
-- 복제 슬롯 생성 (WAL 유실 방지)
SELECT pg_create_physical_replication_slot('standby1_slot');
Standby 구성
# Primary에서 베이스 백업을 받아 Standby 생성
pg_basebackup -h primary_host -U replicator \
-D /var/lib/pgsql/17/data -R -X stream -S standby1_slot
-R 옵션이 복제 설정을 자동으로 만들어줍니다. 이후 Standby를 기동하면 복제가 시작됩니다.
★ HA 전략 선택 - RPO와 RTO로 결정
"어떤 HA를 써야 하나?"의 답은 RPO와 RTO에 달려 있습니다. 이 두 지표가 모든 결정의 기준입니다.
두 가지 핵심 지표
RPO (Recovery Point Objective): 데이터 손실 허용치
"몇 분치 데이터까지 잃어도 되나?"
→ 0이면 동기 복제 필요
RTO (Recovery Time Objective): 복구 시간 목표
"얼마나 빨리 다시 살려야 하나?"
→ 짧을수록 자동화 필요
동기 vs 비동기 복제
비동기 복제 (기본):
Primary가 커밋하고 바로 응답 (빠름)
Standby 전송은 뒤따라감
→ 장애 시 약간의 데이터 손실 가능 (RPO > 0)
동기 복제:
Standby가 받았다고 확인해야 커밋 완료
→ 데이터 손실 0 (RPO = 0), 대신 약간 느림
# 동기 복제 설정 (Primary)
synchronous_standby_names = 'standby1'
자동 Failover 도구
수동 전환은 RTO가 깁니다(5~30분). 자동화하려면 전용 도구를 씁니다.
Patroni: 가장 널리 쓰임, RTO 10~30초, 자동 failover
repmgr: 복제 관리 + failover
pg_auto_failover: 설정 간단
중요한 구분: "우리는 나이트 백업만 있어요"라면 그건 HA가 아니라 재해복구(DR) 입니다. 개발/스테이징엔 괜찮지만, 운영 트래픽엔 부족합니다.
★ 모니터링 - 무엇을 봐야 하나
HA를 구성해도 모니터링이 없으면 무용지물입니다. 복제가 끊겨도 모르면 소용없죠. 필수 뷰와 지표를 정리합니다.
복제 모니터링
-- Primary에서: 복제 상태와 지연 확인
SELECT application_name, client_addr, state,
sync_state,
pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes
FROM pg_stat_replication;
-- Standby에서: WAL 수신 상태
SELECT status, received_lsn, latency
FROM pg_stat_wal_receiver;
-- 복제 슬롯 상태 (WAL 쌓임 감시)
SELECT slot_name, active,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
FROM pg_replication_slots;
복제 지연(lag) 이 계속 커지면 네트워크 문제, Standby I/O 부족, Primary 과부하를 의심하세요.
종합 모니터링 지표
이 시리즈에서 배운 지표들을 한 번에 정리합니다.
복제 지연(lag) → pg_stat_replication (이번 편)
연결 수 → pg_stat_activity (12편)
느린 쿼리 → pg_stat_statements (10편)
dead tuple → pg_stat_user_tables (11편)
XID 나이 (wraparound) → pg_database (11편)
디스크 사용량 → pg_database_size (12편)
추천: Prometheus + Grafana로 이 지표들을 시각화하면 추세까지 한눈에 볼 수 있습니다. 알림(alert)을 걸어두면 문제를 미리 잡을 수 있고요. 새벽 3시 전화(12편)를 줄이는 최선의 방법입니다.
★ Claude로 PostgreSQL 운영 자동화
이제 이 시리즈를 관통해온 주제, AI 활용의 완결입니다. 15년 경험에 AI를 더하면 운영이 한 단계 올라갑니다.
1. 진단 자동화
프롬프트:
"PostgreSQL 17 운영 중인데 복제 지연이 커지고 있어.
pg_stat_replication 결과:
[결과 붙여넣기]
원인과 해결책을 Oracle DBA가 이해하기 쉽게,
우선순위 순으로 알려줘."
2. 쿼리 튜닝 (10편)
"이 EXPLAIN ANALYZE 결과를 분석하고
인덱스를 추천해줘: [결과]"
3. 스크립트 생성 (13, 14편)
"백업+모니터링+알림을 포함한
운영 자동화 스크립트를 만들어줘. cron 설정까지."
4. MCP로 직접 연결
Claude 시리즈 11편(MCP)에서 다룬 것처럼, PostgreSQL MCP 서버를 연결하면 Claude가 직접 DB를 조회하고 분석합니다.
"운영 DB에서 지금 복제 지연이 얼마인지 확인하고,
문제가 있으면 원인을 분석해줘"
→ Claude가 직접 pg_stat_replication 조회 + 진단
★ 반드시 지킬 원칙
1. AI 제안은 스테이징에서 먼저 검증
2. 운영 DB 직접 변경은 신중히
3. 위험 명령(DROP, ALTER)은 영향 범위 확인 후
4. 백업/복제 설정은 특히 실제 테스트 필수
AI는 강력한 조수지만, 최종 판단과 책임은 DBA의 몫입니다. 이 원칙은 이 시리즈 내내 강조해온 것이기도 합니다.
Oracle DBA를 위한 HA 매핑
Oracle 경험을 PostgreSQL로 옮기는 마지막 매핑입니다.
Oracle PostgreSQL
──────────────────────────────────────────
Data Guard → 스트리밍 복제
Active Data Guard → Hot Standby (읽기 가능)
RAC → (직접 대응 없음, 복제+풀러로 유사 구성)
Fast-Start Failover → Patroni / pg_auto_failover
Standby Redo Log → WAL 스트리밍
Data Guard Broker → Patroni
RAC 같은 공유 스토리지 클러스터는 PostgreSQL에 직접 대응이 없지만, 스트리밍 복제 + 연결 풀러(PgBouncer/Pgpool) + 자동 failover로 유사한 고가용성을 구성할 수 있습니다.
★ PostgreSQL 시리즈 완주!
이 글로 PostgreSQL 15편 시리즈가 완결되었습니다. 전체 여정을 돌아봅니다.
입문 (1~4편): "Oracle과 뭐가 다른가"를 이해
아키텍처 · 자료형/DDL · MVCC · psql/AI
실무 (5~9편): "PostgreSQL로 실제 개발"
SQL함수 · 인덱스 · PL/pgSQL · 강력기능 · 권한
운영 (10~15편): "PostgreSQL을 운영"
EXPLAIN · VACUUM · 운영문제 · 백업복구 · 고가용성
시리즈에서 다룬 핵심
Oracle DBA가 PostgreSQL로 넘어올 때 가장 중요했던 개념들입니다.
1. UNDO → MVCC (3편) + VACUUM 관리 (11편)
2. exp/imp/RMAN → pg_dump + pg_basebackup (13,14편)
3. Data Guard → 스트리밍 복제 (15편)
4. 다양한 인덱스 (GIN/BRIN, 6편)
5. JSONB 등 PostgreSQL 강점 (8편)
Oracle 경험은 결코 헛되지 않습니다. 트랜잭션, 인덱스, 백업, 복제 같은 핵심 개념은 그대로 통하고, 문법과 운영 방식의 차이만 익히면 됩니다. 거기에 15년의 실무 감각을 더하면, PostgreSQL DBA로서도 강력한 경쟁력을 갖게 됩니다.
마무리
PostgreSQL 고가용성과 운영의 핵심입니다.
- 스트리밍 복제 — 모든 HA의 기반 (= Data Guard)
- RPO/RTO로 전략 결정 — 동기/비동기, 자동/수동
- 모니터링 필수 — 복제 지연, 연결, dead tuple, XID
- AI 운영 자동화 — 진단/튜닝/스크립트/MCP
- 최종 판단은 DBA — AI는 강력한 조수일 뿐
긴 시리즈를 여기까지 함께해 주셔서 감사합니다. 이 시리즈 자체가 15년차 Oracle DBA가 PostgreSQL로 넘어가며 정리한 실전 노트였습니다. 저 역시 이 글들을 쓰면서 많이 배웠고, AI(Claude)를 활용해 학습과 정리를 가속했습니다.
기술은 계속 바뀝니다. PostgreSQL도 18, 19로 발전하고 있고요. 하지만 "새로운 걸 배우되, 기존 경험을 자산으로 삼는다"는 원칙은 변하지 않습니다. 여러분의 PostgreSQL 여정에 이 시리즈가 작은 지도가 되었기를 바랍니다.
PostgreSQL을 운영하며 겪은 경험이나, 이 시리즈에서 다뤄줬으면 하는 추가 주제가 있다면 댓글로 남겨주세요. 앞으로도 실무에 도움 되는 내용으로 찾아뵙겠습니다.
그동안 감사했습니다. 여러분의 DB가 오늘도 무장애로 안녕하시길 바랍니다. 🙏