PostgreSQL wal_level 설정 기준 정리

PostgreSQL wal_level 설정 기준 정리

PostgreSQL에서 wal_level은 WAL(Write-Ahead Log)에 어느 정도 정보를 남길지 정하는 설정이다. 이 값은 단순 성능 옵션이 아니라, 장애 복구, 베이스 백업 이후의 WAL 재생, 스트리밍 복제, 논리 복제 가능 여부를 함께 바꾼다.

2026년 5월 23일 기준 PostgreSQL 공식 문서에서는 wal_level의 유효값을 minimal, replica, logical로 설명한다. 대부분의 서비스에서는 기본값인 replica가 무난하고, logical은 논리 복제가 필요할 때, minimal은 복제와 PITR이 전혀 필요 없는 제한된 작업에만 검토하는 편이 맞다.

먼저 결론부터 보면 무엇이 다를까?

값	주요 용도	가능한 것	주의할 점
minimal	복제와 아카이빙이 전혀 없는 제한적 환경	충돌 복구(crash recovery)	PITR, 연속 아카이빙, 스트리밍 복제용 WAL 정보가 부족하다
replica	일반적인 운영 기본값	WAL 아카이빙, WAL sender, 스트리밍 복제	논리 복제 정보는 남기지 않는다
logical	논리 복제가 필요한 환경	복제 슬롯 기반 논리 복제와 디코딩	replica보다 더 많은 WAL 정보가 필요하다

핵심 판단 기준은 세 가지다. 복제할 것인지, WAL 아카이빙이나 PITR을 쓸 것인지, 논리 복제가 필요한지다. 이 셋 중 하나라도 필요하면 minimal은 보통 제외된다.

wal_level은 왜 중요한가?

PostgreSQL은 변경 내용을 먼저 WAL에 기록한 뒤 데이터를 반영한다. 그래서 WAL에 어느 정도 정보를 남기느냐는 장애 이후 복구 범위와 복제 기능 범위를 직접 바꾼다.

공식 문서 기준으로 minimal은 가장 적은 정보를 남기고, replica는 아카이빙과 복제에 필요한 수준까지 남기며, logical은 여기에 논리 디코딩용 정보까지 추가한다. 즉 값이 올라갈수록 기능 범위는 넓어지지만, 남겨야 하는 WAL 정보도 늘어난다.

minimal은 언제 써도 될까?

minimal은 서버 충돌 복구에는 필요한 WAL을 남기지만, 베이스 백업에서 시작하는 PITR이나 stand-by 복제를 위한 정보는 충분히 남기지 않는다. PostgreSQL 문서도 이 값을 쓰면 바로 이전 베이스 백업과 WAL 아카이브를 사용할 수 없다고 설명한다.

따라서 다음 조건이 모두 맞을 때만 검토하는 편이 안전하다.

• 스트리밍 복제나 WAL 아카이빙이 전혀 없다.
• 장애 복구 전략이 PITR이 아니라 새 백업 재생성이나 별도 재구성에 가깝다.
• 논리 복제도 전혀 필요 없다.

또 PostgreSQL 문서는 wal_level=minimal에서는 일부 대량 작업이 WAL을 덜 남길 수 있다고 설명한다. 대표적으로 같은 트랜잭션 안에서 생성하거나 TRUNCATE한 테이블에 대한 CREATE TABLE AS, CREATE INDEX, REINDEX, CLUSTER, COPY FROM 같은 작업이 여기에 해당한다.

다만 이 이점만 보고 운영 기본값으로 내리면 곤란하다. 복제나 PITR 계획이 조금이라도 있으면 나중에 복구 전략 자체가 막힐 수 있기 때문이다.

대부분은 왜 replica가 기본값일까?

replica는 PostgreSQL current 문서 기준 기본값이다. 이 값은 WAL 아카이빙과 WAL sender 프로세스, 스트리밍 복제를 지원하는 수준의 정보를 남긴다.

즉 다음과 같은 일반적인 운영 요구를 가장 무난하게 만족한다.

• 향후 standby 서버를 붙일 가능성이 있다.
• 백업 후 WAL 재생 기반 복구 전략을 고려한다.
• 지금은 단일 노드여도 복제 가능성을 닫아 두고 싶지 않다.

논리 복제가 필요하지 않다면 보통 replica에서 멈추는 편이 맞다. 굳이 더 높은 WAL 수준을 유지할 이유가 없고, 운영 문서와 설정 일관성도 지키기 쉽기 때문이다.

logical은 언제 필요할까?

logical은 논리 복제 슬롯, publication/subscription 기반 복제, 논리 디코딩이 필요한 경우에 선택한다. PostgreSQL 문서도 논리 복제를 사용하려면 wal_level을 logical로 맞춰야 한다고 명시한다.

대표적인 사용 사례는 다음과 같다.

• 일부 테이블만 다른 서버로 복제하고 싶다.
• 메이저 버전 업그레이드나 데이터 마이그레이션 과정에서 논리 복제를 활용한다.
• 변경 이벤트를 외부 시스템으로 흘리는 logical decoding 기반 파이프라인이 있다.

반대로 물리 복제만 필요하다면 logical까지 올릴 이유는 크지 않다. 기능 요구가 명확할 때만 쓰는 편이 설정 설명과 운영 비용 측면에서 더 단순하다.

실무에서는 어떻게 고르면 될까?

상황	우선 검토할 값	이유
일반 서비스, 단일 노드 또는 물리 복제 가능성 있음	replica	기본값이고 PITR, 아카이빙, 스트리밍 복제 준비를 함께 가져간다
publication/subscription, logical decoding이 필요함	logical	논리 복제에 필요한 WAL 정보가 있어야 한다
복제와 PITR이 전혀 없고 대량 작업 최적화만 중요함	minimal	일부 작업에서 WAL 양을 줄일 수 있다

운영 기본값을 정할 때는 성능보다 복구 요구를 먼저 보는 편이 맞다. 백업 정책, standby 계획, 마이그레이션 방식이 바뀔 수 있다면 replica를 유지하는 편이 보수적이다.

설정 변경 시 같이 확인할 것은?

wal_level은 서버 시작 시 결정되는 설정이다. PostgreSQL 공식 문서에서는 이 값을 바꾸려면 서버를 재시작해야 한다고 설명한다.

또 max_wal_senders, archive_mode, 복제 슬롯, publication/subscription 같은 주변 설정도 목적에 따라 함께 봐야 한다. 예를 들어 logical만 켠다고 자동으로 논리 복제가 동작하는 것은 아니고, 반대로 논리 복제가 필요하면 replica로는 부족하다.

자주 나오는 질문

Q. 단일 서버인데도 replica를 유지해도 될까?

그렇다. PostgreSQL current 문서 기준 기본값 자체가 replica다. 지금 당장 standby가 없더라도 WAL 아카이빙이나 이후 복제 계획을 열어 두려면 무난한 선택이다.

Q. minimal이 항상 더 빠를까?

항상 그렇다고 보면 곤란하다. PostgreSQL 문서는 특정 대량 작업에서 WAL을 덜 남길 수 있다고 설명하지만, 그 대가로 PITR과 복제 가능성을 포기한다. 그래서 운영 기본값이 아니라 제한된 작업 조건에서만 의미를 따지는 편이 맞다.

Q. 논리 복제가 필요할 수도 있으면 미리 logical로 두는 편이 나을까?

가능은 하지만, 실제로 논리 복제나 logical decoding 계획이 있는지부터 분명히 하는 편이 좋다. 요구가 없다면 기본값 replica가 더 단순하고 설명 가능성이 높다.

정리

wal_level은 PostgreSQL이 얼마나 많은 WAL 정보를 남길지를 정하는 핵심 설정이다. 대부분의 운영 환경에서는 기본값인 replica가 무난하고, 논리 복제가 필요할 때만 logical, 복제와 PITR이 완전히 불필요한 제한적 환경에서만 minimal을 검토하는 편이 맞다.

즉 선택 기준은 성능 추정보다 먼저 복구 전략과 복제 요구다. standby, WAL 아카이빙, PITR, 논리 복제 중 하나라도 계획에 있다면 replica 이하로 내리는 결정은 보수적으로 다루는 편이 안전하다.

참고 자료

• PostgreSQL Documentation: Write Ahead Log
• PostgreSQL Documentation: Continuous Archiving and Point-in-Time Recovery (PITR)
• PostgreSQL Documentation: Logical Replication Configuration