pgBackRest 유지보수 종료 — PostgreSQL 백업 생태계의 큰 빈자리

PostgreSQL 백업의 든든한 동반자가 멈춘다

PostgreSQL을 프로덕션에서 운영해본 분이라면 pgBackRest라는 이름을 한 번쯤 들어봤을 거예요. PostgreSQL 백업 도구 중에서 "진지한 프로덕션 환경에서 정말 믿고 쓸 수 있는" 거의 유일한 오픈소스 솔루션이었거든요. 그런데 이 프로젝트가 더 이상 유지보수되지 않는다는 소식이 전해졌어요. 단순히 도구 하나가 사라지는 게 아니라, PostgreSQL 운영 생태계의 한 기둥이 흔들리는 일이라 많은 DBA들이 당혹스러워하는 상황입니다.

pgBackRest가 왜 그렇게 특별했을까

pgBackRest를 한 마디로 설명하면 "PostgreSQL을 위한 풀스택 백업 솔루션"이에요. 이게 뭐냐면, PostgreSQL 자체가 제공하는 pg_basebackup이나 pg_dump 같은 기본 도구들이 작은 데이터베이스에는 잘 동작하는데, 수 테라바이트 규모로 가면 한계가 명확해져요. 백업이 너무 오래 걸리고, 증분 백업이 안 되고, 압축이나 암호화는 따로 처리해야 하거든요.

pgBackRest는 이 모든 걸 한 번에 풀어줬어요. 병렬 처리로 백업과 복구 속도를 크게 끌어올리고, 블록 단위 증분 백업으로 변경된 부분만 저장하고, S3나 Azure Blob 같은 클라우드 스토리지를 1급 시민으로 지원하고, 압축·체크섬 검증·암호화까지 내장돼 있었거든요. PITR(Point-in-Time Recovery, 특정 시점 복구)도 견고하게 구현돼 있어서 "어제 오후 3시 17분 상태로 정확히 되돌려줘" 같은 요구도 깔끔하게 처리할 수 있었어요. 그래서 Crunchy Data 같은 PostgreSQL 전문 회사들이 자사 매니지드 서비스의 백업 백엔드로 채택할 정도였고요.

빈자리, 누가 채울 수 있을까

당장 떠오르는 대안은 Barman과 WAL-G 정도예요. Barman은 이탈리아의 2ndQuadrant(현재 EDB)에서 만든 도구로 기능 면에서는 pgBackRest와 견줄 만하지만, 성능 면에서는 한 수 아래라는 평가가 많아요. WAL-G는 Yandex에서 시작된 프로젝트로 Go로 작성돼 있고 클라우드 네이티브한 구조가 매력적인데, PostgreSQL 외에도 MySQL이나 FoundationDB 등을 함께 다루다 보니 PostgreSQL 전용으로서의 깊이는 pgBackRest만큼은 아니라는 의견도 있어요.

문제는 데이터베이스 백업 도구가 "한 번 잘못되면 회사가 통째로 흔들린다"는 무게감이 있는 영역이라, 새 도구로 갈아타는 결정이 매우 보수적일 수밖에 없다는 점이에요. 단순히 기능이 비슷하다고 옮길 수 있는 게 아니라 수년간의 검증, 엣지 케이스 대응, 장애 복구 시나리오 점검까지 같이 따라와야 하거든요.

한국 운영자에게 주는 시사점

만약 회사에서 pgBackRest를 쓰고 있다면 당장 패닉할 필요는 없어요. 코드는 그대로 남아있고, 마지막 릴리스도 한동안은 안정적으로 동작할 거예요. 다만 PostgreSQL 18, 19 같은 새 메이저 버전이 나올 때마다 호환성 문제가 생길 수 있고, 보안 취약점이 발견됐을 때 패치를 받기 어려워진다는 건 분명한 리스크입니다.

지금 해야 할 일은 두 가지예요. 첫째, 현재 백업 전략의 무엇이 pgBackRest에 의존하고 있는지 인벤토리를 만드는 것. 단순히 "백업 도구"로만 보면 대체가 쉬워 보이지만, 실제로는 모니터링 스크립트, 백업 검증 잡, 복구 런북까지 모두 pgBackRest의 명령어 체계와 출력 포맷에 단단히 묶여있을 가능성이 높거든요. 둘째, 커뮤니티 포크가 등장할지 지켜보면서 WAL-G나 Barman으로 옮겨가는 PoC를 미리 돌려보는 것. 정말 이전이 필요한 시점이 왔을 때 허둥대지 않으려면 지금부터 손에 익혀두는 게 좋아요.

마무리

오픈소스의 그림자 같은 이슈예요. 잘 만들어진 도구 하나가 인프라 깊숙이 박혀있다가, 메인테이너의 사정으로 갑자기 멈춰버릴 때 우리는 무엇을 해야 할까요. 여러분 회사의 백업 스택은 지금 어떤 상태인가요? 한 사람의 메인테이너에게 의존하고 있는 핵심 도구는 또 뭐가 있을까요?