PostgreSQL synchronous_commit은 언제 꺼도 될까? off, local, remote_write 차이 정리

PostgreSQL synchronous_commit은 언제 꺼도 될까? off, local, remote_write 차이 정리

PostgreSQL에서 synchronous_commit은 커밋 성공을 언제 클라이언트에 돌려줄지 결정하는 설정이다. 2026년 5월 19일 기준 PostgreSQL 공식 문서를 보면, 이 값은 단순히 빠르다 또는 안전하다는 정도가 아니라 로컬 디스크 flush, standby 반영 대기, 최근 트랜잭션 손실 가능 범위를 직접 바꾼다.

실무에서는 off만 따로 보는 경우가 많지만, 실제 선택 기준은 off, local, on, remote_write, remote_apply를 함께 봐야 분명해진다. 이 글은 PostgreSQL 공식 문서 기준으로 각 모드의 의미와 언제 어떤 값을 고르는 편이 맞는지 정리한다.

먼저 결론부터 보면 어떤 차이일까?

값	로컬 WAL flush 대기	standby 대기	주요 의미
off	아니오	아니오	가장 빠르지만 최근 커밋 일부가 서버 크래시 때 사라질 수 있음
local	예	아니오	로컬 내구성만 보장하고 synchronous replication 대기는 생략
on	예	환경에 따라 예	기본값, standby가 없으면 로컬 flush까지만 대기
remote_write	예	standby OS write까지 대기	standby PostgreSQL 크래시에는 강하지만 standby OS 크래시까지는 아님
remote_apply	예	standby replay까지 대기	standby 조회 일관성까지 요구할 때 사용

PostgreSQL 문서의 표를 그대로 요약하면, off를 제외한 모든 모드는 로컬 WAL flush를 기다린다. 또한 synchronous_standby_names가 비어 있으면 remote_apply, remote_write, local은 로컬 수준에서 on과 같은 의미만 가진다.

synchronous_commit=off는 정확히 무엇을 포기할까?

off는 비동기 커밋이다. PostgreSQL은 트랜잭션이 논리적으로 끝나면 즉시 성공을 반환하고, WAL을 디스크에 내리는 일은 뒤로 미룬다. 공식 문서에 따르면 이때 서버가 크래시하면 방금 성공했다고 응답한 최근 트랜잭션 일부가 사라질 수 있다.

중요한 점은 이것이 fsync=off와 다르다는 것이다. PostgreSQL 문서는 synchronous_commit=off는 최근 커밋 손실 위험만 늘릴 뿐 데이터베이스 불일치를 만들지 않는다고 설명한다. 반면 fsync=off는 데이터 손상 가능성까지 만든다.

손실 가능 시간은 얼마나 될까?

PostgreSQL 문서상 위험 구간은 WAL writer가 아직 flush하지 않은 시간이며, 최대치는 3 * wal_writer_delay다. 즉 off를 켜더라도 무한히 오래 유실되는 것은 아니지만, 아주 최근의 커밋은 서버 장애 시 잃을 수 있다고 보는 편이 맞다.

off가 맞을 수 있는 경우

• 일부 로그성 적재처럼 최근 수 초 내 재처리가 가능한 쓰기 작업
• 대량 배치 중에서도 실패 시 다시 만들 수 있는 파생 데이터
• 응답 지연을 줄이는 편익이 최근 커밋 일부 손실보다 더 중요한 경우

off를 피하는 편이 안전한 경우

• 결제, 주문, 계정 상태 변경처럼 커밋 손실을 그대로 비즈니스 오류로 보는 경우
• 장애 후 재구성이 어렵거나 외부 시스템과 이미 상태가 맞물리는 쓰기
• 성능 병목이 WAL flush가 아니라 쿼리 구조나 락 경합에 있는 경우

local과 on은 무엇이 다를까?

synchronous_standby_names를 비워 둔 일반 단일 노드 환경에서는 둘 다 로컬 WAL flush까지 기다린다. 그래서 이 환경에서는 사실상 차이가 없다.

차이는 synchronous replication을 구성했을 때 드러난다. PostgreSQL 문서에 따르면 on은 현재 동기 standby의 확인 응답까지 기다리지만, local은 replication 대기를 생략하고 로컬 디스크 flush까지만 기다린다. 즉 primary만 확실하면 되고 standby 지연은 감수하겠다는 선택에 가깝다.

remote_write는 어디까지 보장할까?

remote_write는 동기 standby가 커밋 레코드를 받아 자신의 운영체제까지 write한 것을 확인할 때까지 기다린다. 다만 PostgreSQL 공식 문서는 standby의 디스크에 durable storage로 flush된 것까지는 보장하지 않는다고 설명한다.

따라서 이 값은 on보다 항상 강한 것이 아니라, 대기 지점을 조금 앞당겨 응답 시간을 줄이되 standby PostgreSQL 프로세스 크래시에는 대비하고 싶은 경우의 절충안으로 보는 편이 맞다. 문서도 standby OS 크래시에서는 데이터가 사라질 수 있다고 분명히 적고 있다.

remote_apply는 언제 필요할까?

remote_apply는 standby가 WAL을 실제로 replay해 조회 가능한 상태가 될 때까지 기다린다. PostgreSQL 문서는 단순 내구성보다 standby query consistency, 즉 primary에서 커밋한 직후 standby 읽기에서도 그 변경을 봐야 하는 경우에 의미가 있다고 설명한다.

예를 들어 읽기 부하를 standby로 보내면서, 어떤 요청은 쓰기 직후 같은 세션 흐름에서 곧바로 standby를 조회할 수 있다면 remote_apply가 설계상 더 맞을 수 있다. 반대로 이런 요구가 없다면 대기 시간이 불필요하게 늘 수 있다.

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

상황	우선 검토할 값	이유
일반 단일 노드 서비스	on	기본값이며 로컬 내구성을 바로 확보함
재처리 가능한 로그성 대량 적재	off	최근 일부 커밋 손실을 받아들여 지연을 줄일 수 있음
동기 standby는 두되 primary 응답 지연을 더 줄이고 싶음	remote_write 또는 local	복제 보장 수준과 지연 사이에서 절충 가능
standby 읽기에서도 즉시 같은 결과가 보여야 함	remote_apply	replay 완료까지 기다려 읽기 일관성 요구를 만족시킴

핵심은 성능 때문에 무조건 off로 가는 것이 아니라, 장애 시 잃어도 되는 마지막 몇 개 커밋이 무엇인지 먼저 구분하는 것이다. PostgreSQL은 트랜잭션 단위로도 SET LOCAL synchronous_commit TO OFF를 줄 수 있으므로, 모든 쓰기를 같은 기준으로 묶지 않는 편이 더 실용적이다.

자주 나오는 질문

Q. synchronous_commit=off면 데이터가 깨질 수 있을까?

PostgreSQL 공식 문서 기준으로 그렇지는 않다. 최근 커밋 일부가 사라질 수는 있지만, 데이터베이스 상태 자체가 손상되는 위험을 만드는 설정은 아니다. 그 위험은 fsync=off와 구분해서 봐야 한다.

Q. standby를 쓰지 않는데 remote_write나 remote_apply를 주면 더 안전할까?

아니다. 공식 문서에 따르면 synchronous_standby_names가 비어 있으면 이런 값들은 로컬 수준에서 on과 같은 의미만 가진다. standby가 없으면 기다릴 원격 대상도 없다.

Q. 성능 문제가 있으면 먼저 off부터 켜야 할까?

바로 그렇게 보는 것은 위험하다. 실제 병목이 쿼리 계획, 인덱스, 락 대기, 네트워크 왕복, 동기 standby 지연일 수도 있기 때문이다. synchronous_commit은 내구성 보장 시점을 바꾸는 설정이므로, 손실 허용 범위가 먼저 정리된 뒤에 적용하는 편이 맞다.

정리

synchronous_commit은 빠름과 느림의 문제가 아니라 커밋 성공 응답과 내구성 보장을 어디서 끊을지 정하는 스위치다. 단일 노드에서는 대부분 on이 무난하고, 일부 재처리 가능한 쓰기만 off로 낮추는 방식이 보수적이다.

synchronous replication을 쓰는 환경이라면 local, remote_write, remote_apply의 차이는 standby에서 어디까지 확인할지를 뜻한다. 따라서 운영 기준은 성능보다 먼저, 마지막 몇 개 커밋을 잃어도 되는지와 standby 읽기 일관성이 필요한지로 잡는 편이 정확하다.

참고 자료

• PostgreSQL Documentation: Write Ahead Log
• PostgreSQL Documentation: Asynchronous Commit
• PostgreSQL Documentation: Synchronous Replication