행을 삭제해도 데이터베이스 크기가 줄어들지 않는 이유
PostgreSQLQL의 다중 버전 동시성 제어(MVCC) 아키텍처는 동시 데이터베이스 작업의 근간이지만, 테이블 비대화(bloat)라는 본질적인 비용을 수반합니다. 행이 업데이트될 때 PostgreSQLQL은 그 행을 제자리에서 수정하지 않고, 완전히 새로운 복사본을 기록한 뒤 이전 버전을 "dead"로 표시합니다. 이 메커니즘 덕분에 트랜잭션은 항상 일관된 데이터 스냅샷을 보게 되지만, 쓸모없어진 데이터가 계속 남게 됩니다.
결국 VACUUM 프로세스가 이러한 dead 행을 정리하여, 그 공간을 같은 테이블 내에서 새 데이터에 사용할 수 있게 합니다. 중요한 점은 일반적인 VACUUM 작업이 이렇게 회수한 공간을 운영체제로 반환하지 않는다는 것입니다. 테이블의 절반을 삭제해도 디스크의 파일 크기는 그대로인 경우가 많으며, 이는 DBA들이 흔히 겪는 불편 사항입니다.
과거에는 테이블을 물리적으로 축소하고 공간을 OS에 반환하는 유일한 기본 제공 방법이 VACUUM FULL이었습니다. 이 명령은 테이블 전체를 다시 써서 새 디스크 페이지에 압축합니다. 그러나 VACUUM FULL은 ACCESS EXCLUSIVE 락을 획득하여 작업이 끝날 때까지 테이블에 대한 모든 읽기와 쓰기를 차단합니다. 그 영향이 매우 심각하여 PostgreSQLQL 자체 문서에서도 프로덕션 환경에서의 사용을 권장하지 않습니다. 이 때문에 DBA들은 온라인 테이블 압축을 위해 pg_repack 같은 서드파티 확장 기능에 의존해야 했습니다.
REPACK은 무거운 작업을 핵심 경로에서 분리합니다
PostgreSQLQL 19는 마침내 테이블 비대화에 대한 기본 제공 온라인 해결책인 REPACK CONCURRENTLY를 DBA에게 제공합니다. 이 명령은 원본 테이블에 대한 동시 읽기와 쓰기를 허용하면서 테이블의 새롭고 간결한 버전을 만들어, 차단을 일으키는 VACUUM FULL을 우회합니다. 다운타임 없이 성능을 유지하는 데 판도를 바꿀 기능입니다.
그 메커니즘은 영리합니다. REPACK은 먼저 모든 live 행을 새로운 임시 테이블로 복사합니다. 이어서 WAL 기반 논리적 디코딩(WAL-based logical decoding)을 사용하여, 이 복사 단계 동안 원본 테이블에서 발생한 변경 사항(삽입, 업데이트, 삭제)을 캡처합니다. 캡처된 변경 사항은 새 테이블에 재생되어, 대체될 테이블이 완전히 최신 상태가 되도록 보장합니다.
마지막으로 REPACK은 짧은 배타적 락(exclusive lock)을 걸어 이전 테이블 파일을 새롭고 간결한 파일로 원자적으로 교체합니다. 이로써 테이블을 사용할 수 없는 핵심 구간이 최소화됩니다. Better Stack의 테스트에서는 493 MB 테이블이 10초 이내에 228 MB로 줄어들었고, 마지막의 순간적인 전환 전까지 계속 접근할 수 있었습니다. 이는 보편적인 벤치마크는 아니지만, REPACK이 제공하는 뛰어난 디스크 절감 효과와 운영 효율성을 보여 줍니다.
작은 락 하나가 큰 트래픽 정체를 일으킬 수 있습니다
REPACK CONCURRENTLY는 마법을 부리는 것이 아니라 무거운 작업을 다른 곳으로 옮길 뿐입니다. 테이블 복사의 대부분은 온라인으로 진행되지만, 이전 테이블 파일을 새롭게 압축된 버전으로 교체하는 마지막 핵심 단계에서는 배타적 락이 필요합니다. 이 ACCESS EXCLUSIVE 락은 읽기든 쓰기든 해당 테이블에 대한 모든 동시 작업을 막습니다. 매우 짧고 원자적인 구간이지만, 그 테이블을 사용하는 모든 활성 트랜잭션이 끝날 때까지 기다려야 합니다.
이 병목은 상당한 운영 위험을 야기합니다. Better Stack의 테스트가 이를 잘 보여 주었습니다. 전환 시점에 실행 중이던 20초짜리 분석 보고서가 최종 교체를 지연시켰고, 그 결과 해당 테이블을 대상으로 하는 이후의 모든 쿼리가 18초 동안 대기열에 쌓였습니다. 사실상 head-of-line blocking 상황이 발생한 것입니다. 장시간 실행되는 쿼리 하나가 동시 작업을 방해할 수 있다면, 온라인 repack의 장점은 줄어듭니다.
이를 완화하려면 최종 전환을 중요한 이벤트로 취급해야 합니다. 장시간 실행되는 보고서나 배치 작업이 테이블을 두고 경합할 가능성이 낮은 비피크 시간대에 REPACK CONCURRENTLY를 예약하십시오. 명령을 시작하기 전에 대상 테이블의 활성 세션을 미리 확인하거나, 테이블 유지 관리에 대한 자세한 내용은 PostgreSQLQL Documentation: Routine Vacuuming 같은 자료를 참고하십시오. 목표는 메타데이터 교체가 예상치 못한 지연 없이 이루어지도록 하여, 영리한 요령을 신뢰할 수 있는 운영 도구로 만드는 것입니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
기본 제공 도구이지만 계획을 생략해도 된다는 뜻은 아닙니다
PostgreSQLQL 19의 기본 제공 REPACK CONCURRENTLY는 10년 넘게 커뮤니티에서 널리 쓰여 온 pg_repack 같은 서드파티 도구에 대한 매력적인 대안입니다. 기본 지원은 확장 기능 관리를 간소화하고, 호환성 문제를 피할 수 있게 하며, 핵심 데이터베이스 작업과의 통합도 개선할 수 있습니다. 이러한 변화는 핵심적인 DBA 기능을 내재화하는 증가하는 추세를 반영합니다.
그러나 "기본 제공"이 "마법"을 의미하지는 않습니다. Better Stack 영상에서는 PostgreSQLQL 19의 목표 릴리스 날짜를 November 19로 언급하지만, 사용자는 마이그레이션을 계획하기 전에 현재 릴리스 상태와 제공업체의 지원 여부를 확인해야 합니다. 특히 관리형 서비스는 기능 도입이 늦어지거나 새 명령에 제한을 둘 수 있으므로, 사용 중인 벤더에 반드시 지원 기능을 확인하십시오.
영상에서 언급했듯이 PostgreSQLQL 19의 개발 과정은 "순탄치 않았으며", 안정성을 위해 기능이 발표되었다가 취소되거나 축소되기도 했습니다. 이러한 신중한 접근은 PostgreSQLQL Global Development Group의 특징입니다. 따라서 프로덕션 워크로드에서 REPACK CONCURRENTLY를 사용하기 전에, 공식 PostgreSQLQL 19 문서에서 정확한 동작과 운영상의 유의 사항을 확인하십시오.
결국 REPACK CONCURRENTLY는 DBA의 화살통에 더해진 강력한 새 화살일 뿐, 만능 해결책은 아닙니다. 짧지만 중요한 배타적 락이 있으므로 전략적인 계획은 여전히 필수입니다. 활동이 적은 시간대나 장시간 실행되는 쿼리가 없을 때 실행하면 이점을 극대화하고, Better Stack의 테스트에서 관찰된 18초 대기열 같은 상황을 방지할 수 있습니다.
자주 묻는 질문
PostgreSQL 19에서 REPACK은 어떤 역할을 하나요?
REPACK은 테이블을 더 간결한 물리적 구조로 재구성하여 사용하지 않는 디스크 공간을 회수하며, 그동안에도 일반적인 데이터베이스 작업을 계속 수행할 수 있습니다.
REPACK은 VACUUM FULL과 어떻게 다른가요?
VACUUM FULL은 작업이 진행되는 동안 차단 락(blocking lock)을 유지한 채 테이블을 다시 씁니다. REPACK CONCURRENTLY는 대부분의 작업을 테이블에 계속 접근할 수 있는 상태에서 수행하며, 파일을 전환할 때 짧은 배타적 락만 필요합니다.
REPACK CONCURRENTLY도 애플리케이션 트래픽에 영향을 줄 수 있나요?
예. 최종 교체 단계는 해당 테이블을 사용하는 쿼리가 끝날 때까지 기다려야 하며, 새로운 요청은 락 뒤에서 대기열에 쌓일 수 있습니다.
PostgreSQL 19로 인해 pg_repack은 더 이상 필요 없어지나요?
경우에 따라 pg_repack의 필요성이 줄어들 수는 있지만, 팀은 기본 제공 기능의 사용 가능 여부와 운영 적합성을 기존 도구와 비교해 보아야 합니다.