pgBackRest의 종료 — 13년 단독 메인테이너 시대의 끝, 그리고 Barman·CNPG로 이어지는 길

2026-05-04 업데이트 — pgBackRest, 사실상 부활 쪽으로 가닥이 잡혔다.

이 글을 올리고 며칠 지나지 않아 분위기가 뒤집혔다. 저장소 archive가 해제됐고("archived": false), 기본 브랜치가 eol로 바뀐 README 상단에 MAINTENANCE UPDATE 섹션이 새로 추가됐다. 그 안에서 David Steele(데이비드 스틸)가 직접 부활 의사를 밝혔다.

“It is clear that many pgBackRest users… would prefer the project to continue with me as the primary maintainer. … This time pgBackRest will be funded by a coalition of sponsors so that a single acquisition will no longer affect my ability to continue work on the project.”

(많은 pgBackRest 사용자가 내가 계속 메인테이너로 남아 주기를 바란다는 게 분명해졌다. … 이번에는 한 회사 매각 한 번으로 프로젝트가 흔들리지 않도록 여러 후원사가 함께 자금을 댄다.)

골자는 세 가지다 — (1) Steele의 메인테이너 복귀, (2) 단독 후원사(과거 Crunchy Data) 의존 모델을 깨고 sponsor coalition 모델로 전환, (3) 추가 메인테이너 영입 예정. README에 명시된 현재 sponsor는 Supabase다. 정식 발표는 같은 주 안에 나올 예정으로 잡혀 있다.

본문은 2026-04-27 시점의 충격과 해석을 사료로 남기기 위해 그대로 둔다. 운영자 입장에서 결론은 단순해진다 — 즉각 마이그레이션 압력은 약해졌고, 다음 PostgreSQL 메이저 업그레이드까지의 시간은 그대로다. 정식 발표가 나온 뒤 한 번 더 들여다보면 된다.

여담 한 줄. 후배가 그러더군 — “이래서 파업들을 하는 거라고.” 농담이지만 묘하게 정곡을 찌른다 — 13년 일한 사람이 손을 놓고 나서야 비로소 자본이 모였으니까.

한 사람이 13년 지킨 백업 도구

PostgreSQL 운영을 좀 해본 사람이라면 pgBackRest라는 이름은 거의 반사적으로 익숙할 것이다. 전체 / 차등 / 증분 백업, PITR, 병렬 압축·전송, S3·GCS·Azure 직결, 무결성 검증 — PostgreSQL 백업에 필요한 거의 모든 항목이 한 도구로 깔끔하게 풀리는, 사실상의 표준이었다.

그 표준이 멈췄다. 2026년 4월 27일, 단독 메인테이너 David Steele(데이비드 스틸)이 GitHub 저장소를 archive 처리하면서 다음과 같이 공식 안내했다.

“After a lot of thought, I have decided to stop working on pgBackRest. I did not come to this decision lightly.” — David Steele, pgbackrest GitHub README

13년이다. 한 사람이 13년 동안 사실상 혼자 유지해 온 도구가 멈췄다.

개인적으로는 슬프다. 동시에 “이게 그렇게 단순한 슬픔으로 정리될 일인가” 하는 생각도 든다. 이 글은 그 정리다 — 사실관계, 다른 사람들의 해석, 대안 도구 비교, CNPG에서 Barman이 어떤 자리에 있는지, 그리고 운영자 입장에서 지금 무엇을 할지.

무슨 일이 있었는가 — 타임라인

마지막 릴리스 v2.58.0은 PostgreSQL 18까지 공식 지원한다. 즉 지금 운영 중인 클러스터의 백업이 당장 멈추는 건 아니다. 다만 다음 PostgreSQL 메이저(PostgreSQL 19, 2026-09 예정) 출시 이후 호환성·보안 패치 공급원이 사라진다는 점이 분기점이다.

왜 이렇게 됐는가 — 단독 메인테이너의 구조적 함정

13년간 코드 리뷰·릴리스·이슈 트리아지 거의 전부를 한 사람이 처리한 프로젝트였다. Crunchy Data가 Steele의 인건비를 받쳐주는 동안에는 그 모델이 굴러갔다. 매각 이후 후속 직장과 독립 후원 시도가 이어졌지만, 어느 쪽도 프로젝트를 제대로 유지할 만큼은 모이지 않았다.

“The person who makes sure your data survives a disaster did not make the cut.” — Lætitia Avrot(레티시아 아브로), pgBackRest is dead. Now what?

(데이터 재해 복구를 책임지는 사람의 자리는 결국 잘려나갔다.)

이 한 문장이 사실 사건의 전부다. AI 붐을 따라 자본은 GPU와 추론 인프라로 흘러가고, “당신의 데이터가 재해 후에도 살아남게 해주는 도구"의 메인테이너 한 명을 살리는 것은 어느 회사의 우선순위에도 들어가지 못했다. Steele 본인은 절제된 톤으로 정리했다.

“Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop.”

대충 유지하면서 사용자 신뢰만 갉아먹느니 깨끗하게 멈추겠다는 결정이다. 비난할 자리는 아니다. 13년치 코드를 그렇게 마감할 수 있는 사람이 흔하지 않다.

네 시선 — 같은 사건, 네 가지 해석

며칠 사이에 정리된 PostgreSQL 생태계의 주요 입장을 표로 묶으면 다음과 같다.

각 입장이 가리키는 곳이 조금씩 다른데, 그 차이가 오히려 흥미롭다. Avrot는 “지금 평가 단계라면 굳이 archived 도구를 신규 도입할 이유가 없다"는 운영자 시점, Pettus는 *“오픈소스 인프라의 본질은 자본 문제이지 기술 문제가 아니다”*라는 한 단계 위의 진단, Bartolini는 자기 진영(Barman/CNPG)의 철학적 정당성을 곱씹으면서도 *“선순환이 끊긴 결과”*라며 더 큰 그림을 본다. Percona는 가장 보수적이다 — 자기 고객 입장에서 즉각 마이그레이션을 권하지 않는다.

네 입장이 모순되지는 않는다. 시간 축이 다를 뿐이다. *“오늘 당장의 운영”*에는 Percona, *“다음 분기의 신규 도입”*에는 Avrot, *“내년의 기술 선택”*에는 Pettus, *“5년 뒤 OSS가 어떻게 살아남을까”*에는 Bartolini가 답한다.

대안 도구 비교

운영자 입장에서 결정에 필요한 정보만 압축하면 다음과 같다.

마지막 두 행이 좀 어색해 보이는데, Avrot가 원문에서 한 번 더 짚어준 부분이라 굳이 표에 남겼다.

“pg_basebackup is a clone tool, not a backup tool. pg_dump is an export tool.”

(pg_basebackup은 클론 도구이지 백업 도구가 아니다. pg_dump는 export 도구다.)

PostgreSQL 입문자가 “PostgreSQL에 기본으로 들어 있는 거 쓰면 되지 않나” 라고 생각하기 쉬운데, WAL 관리·복구 명령·무결성 검증 중 어느 것도 자체적으로 제공하지 않는다. pg_basebackup으로 만든 base에 자체 WAL 보존·복구 스크립트를 얹는 방식은 곧 직접 만든 mini-Barman이 되며, 그러느니 진짜 Barman을 쓰는 게 낫다.

pg_basebackup + pg_combinebackup (PostgreSQL 17+) 조합은 블록 레벨 증분이 들어왔으므로 외부 도구를 도입하기 싫은 작은 클러스터에는 의미 있는 선택지다. 다만 오브젝트 스토리지 직결, 보존 정책, 병렬 복원 같은 운영 편의는 직접 짜야 한다.

선택은 대체로 둘로 좁혀진다.

• Barman — 베어메탈·VM 운영, EDB 중심 생태계, K8s 환경(CNPG)
• WAL-G — 멀티 클라우드 / 멀티 DB 엔진을 한 도구로 통일, 스트리밍 친화

CNPG와 Barman — 쿠버네티스에서는 이미 답이 나와 있다

쿠버네티스에서 PostgreSQL을 운영 중이라면 이번 일에 가장 마음 편한 쪽이다. CloudNativePG(CNPG)가 처음부터 Barman 진영에 서 있었기 때문이다.

CNPG 공식 문서는 현재 백업 메서드를 세 가지로 명시한다.

1. plugin — CNPG-I 플러그인 기반 백업. 공식 권장 경로
2. volumeSnapshot — Kubernetes CSI 볼륨 스냅샷
3. barmanObjectStore — Barman Cloud 네이티브 통합. v1.26부터 deprecated

핵심은 1번이다. 네이티브로 들어 있던 Barman Cloud 통합이 v1.26부터 deprecated 처리됐고, 공식 권장 경로는 Barman Cloud Plugin으로 옮겨갔다. 즉 코어와 백업 도구가 분리된 플러그인 구조로 진화 중이다. pgBackRest는 CNPG 공식 문서에 등장하지 않는다.

흐름을 그림으로 정리하면 다음과 같다.

flowchart LR
    subgraph K8s["Kubernetes"]
      C["CNPG Cluster
(PG primary + replicas)"]
      P["barman-cloud-plugin
(CNPG-I)"]
    end
    subgraph Cloud["Object Storage"]
      S["S3 / Azure Blob / GCS"]
    end
    C -- "WAL stream + base backup" --> P
    P -- "업로드·보존 정책·복구 오케스트레이션" --> S
    S -. "PITR 시 복구" .-> C

    classDef k8s fill:#e8f0fe,stroke:#3367d6,color:#000
    classDef plugin fill:#e6f4ea,stroke:#137333,color:#000
    classDef cloud fill:#fff4cc,stroke:#b08900,color:#000
    class C k8s
    class P plugin
    class S cloud

Bartolini의 글에 이 분리의 철학이 잘 정리돼 있다.

“Barman delegates data copy mechanisms to PostgreSQL primitives and rsync, focusing instead on orchestration, retention, and recovery management.”

(Barman은 데이터 복사 자체는 PostgreSQL의 기본 기능과 rsync에 위임하고, 자기는 오케스트레이션·보존·복구 관리에 집중한다.)

pgBackRest는 정반대 결정을 한 도구였다 — 복사 메커니즘을 자기 안에 두고 끝까지 통제한다. 둘 중 어느 쪽이 옳다고 단정하긴 어렵다. 다만 K8s 오퍼레이터의 역할 분담 모델에는 역할을 잘게 쪼개고 위임하는 Barman 쪽이 잘 맞는다는 게 결국 드러난 셈이다.

요약하면 이렇다.

• 베어메탈·VM에서 pgBackRest를 쓰고 있었다면 → 다음 메이저 업그레이드 사이클에 Barman 또는 WAL-G로 마이그레이션 평가
• K8s + CNPG 환경이라면 → 이미 Barman Cloud Plugin이 표준. 별도 의사결정이 거의 필요 없음

운영자 입장에서 지금 무엇을 할 것인가

0. 호흡 한 번. 즉각 위험은 없다.
1. 인벤토리 — 어느 클러스터가 pgBackRest를 쓰는지
2. 다음 PostgreSQL 메이저 업그레이드 일정 = 분기점
3. 신규 클러스터 / 평가 단계는 Barman 또는 WAL-G로
4. K8s라면 CNPG + Barman Cloud Plugin
5. 단독 메인테이너 의존도가 높은 도구를 식별
6. 백업이 아니라 복구 — 정기 복구 리허설

조금 풀어 쓰면.

1. 즉시 교체 필요 없음. v2.58.0은 PostgreSQL 18까지 공식 지원하고, Percona가 *“계속 쓰라”*는 공식 입장을 냈다. 패닉 마이그레이션은 추가 사고를 만든다.
2. 분기점은 다음 PostgreSQL 메이저 업그레이드 시점. PostgreSQL 19 이후 호환성·보안 이슈가 생겼을 때 아무도 책임지지 않는다. 그 시점까지 마이그레이션 계획만 잡아두면 충분하다.
3. 신규로 도입할 거라면 archived 도구를 새로 들이는 건 합리적이지 않다. Avrot의 권고대로 Barman 평가부터.
4. K8s + CNPG 환경에서는 사실상 의사결정이 끝났다. Barman Cloud Plugin으로 가면 된다.
5. 이번 사건의 일반화된 교훈. 운영 critical path에 단독 메인테이너 의존 도구가 또 어디에 있는지 한 번 훑어볼 가치가 있다. 같은 일이 다른 도구에서 다시 일어나지 말란 법이 없다.
6. 백업이 아니라 복구가 본질이다. 어느 도구로 옮기든, 옮긴 직후 복구 리허설을 한 번 돌려보지 않으면 실제로는 백업이 없는 것과 같다.

단상 — 오픈소스 인프라의 자본 문제

Bartolini는 글에서 “선순환(virtuous cycle)“이라는 표현을 썼다.

“Companies invest in engineers who build open-source software. That software creates production value. Those organizations purchase commercial support. Companies reinvest profits into engineering.”

(회사가 엔지니어에 투자해 OSS를 만든다 → OSS가 운영 가치를 만든다 → 그 운영 가치가 상용 지원으로 환원된다 → 회사가 다시 엔지니어에 재투자한다.)

이 사이클의 어느 한 고리만 끊겨도 무너진다. pgBackRest는 Crunchy Data의 후원이라는 한 고리에 매달려 있다가, 그 회사의 매각이라는 외생 변수 한 번에 끊겼다. 그 단계에서 커뮤니티 후원이 빈자리를 못 메웠다는 게 사건의 본질이다.

오픈소스가 공짜라는 건 사용자 입장에서의 이야기다. 누군가는 그 비용을 치르고 있고, 그 비용 청구서가 어디에도 도착하지 않으면 결국 한 사람이 13년을 혼자 지키다가 손을 놓게 된다. 한 사람이 13년을 지킨 코드는, 그 자체로 이미 자본 부족을 증명한다.

Pettus의 한 줄이 이 단상을 닫기에 가장 정확하다.

“This is not a problem with a technical solution. In the long run, it is the only important problem.”

(이건 기술적 해법이 있는 문제가 아니다. 장기적으로 보면, 사실 그것만이 유일하게 중요한 문제다.)

정리

pgBackRest는 죽지 않았다. 다만 누군가의 13년이 끝났을 뿐이고, 우리는 그 다음을 준비할 시간이 있다.

같은 일이 다음에 일어날 도구는 어디일까 — 그 질문이 이번 사건이 우리에게 남긴 진짜 숙제다.

참고 자료

• pgBackRest is dead. Now what? — Lætitia Avrot, MyDBA Notebook (원문)
• pgbackrest/pgbackrest — GitHub (2026-05-04 archive 해제, MAINTENANCE UPDATE 추가)
• pgBackRest Releases
• pgBackRest is no longer maintained — LWN
• pgBackRest is archived, what now? — Percona Community
• Notice of Obsolescence — Christophe Pettus, thebuild.com
• Why the cycle of open-source sustainability needs to be virtuous — Gabriele Bartolini
• Pgbackrest is no longer being maintained — Hacker News
• Barman 공식
• WAL-G — GitHub
• CloudNativePG — Backup 공식 문서
• CloudNativePG — Barman Cloud Plugin
• pg_combinebackup — PostgreSQL 17 Docs