2026-05-19, Percona가 주도하는 6사 컨소시엄(AWS, Percona, Supabase, pgEdge, Tiger Data, Eon)이 pgBackRest의 후원을 공식화했고, David Steele(데이비드 스틸)은 메인테이너로 복귀해요.

한 사람이 13년 짊어진 모델이 22일 만에 여러 사람이 함께 짊어지는 모델로 바뀌었습니다. 그게 이번 사건의 진짜 줄거리입니다.

DBA 입장에서 결론은 짧습니다. 즉각 마이그레이션 압력은 사라졌고, PostgreSQL 19(2026-09 예정) 호환성도 컨소시엄이 책임집니다. 지난달 종료 발표 시점에 썼던 글의 결말이 한 달 만에 바뀌었습니다.

22일짜리 정세 변동

시점사건
2026-04-27David Steele이 GitHub 저장소를 archive 처리, “no longer maintained” 공식 선언
2026-04-28Percona 공식 입장 — 계속 사용 권장
2026-04-30본 블로그에서 종료 글 발행
2026-05-04저장소 archive 해제, README에 MAINTENANCE UPDATE 추가. Steele이 sponsor coalition 모색 의사 공식화. Supabase가 첫 명시 후원사
2026-05-19Percona가 주도하는 6사 컨소시엄 정식 발표 — AWS, Percona, Supabase, pgEdge, Tiger Data, Eon

22일입니다. 종료 발표를 알아채고 분노했다가 분석으로 넘어가는 사이클을 한 바퀴 다 돌 시간도 안 됐습니다. 그동안 PostgreSQL DBA 커뮤니티 안에서는 “진짜 멈추면 어떻게 되나"의 시뮬레이션이 활발했고, Barman으로의 마이그레이션과 CNPG의 plugin-barman-cloud, WAL-G 회의론 등이 한곳에서 다시 정리됐습니다. 결과적으로 그 압박이 후원사들의 의사 결정 속도를 끌어올린 그림입니다.

6사가 모인 계산

발표문은 회사 이름 외에 각자 동기를 길게 풀지 않았지만, 각 회사의 PG 사업 위치를 보면 그림은 그려집니다.

후원사PG 사업 위치pgBackRest 의존도
PerconaPG/MySQL 운영 컨설팅/매니지드 서비스표준 권장 백업 도구. 마이그레이션 시 가장 큰 운영 부담을 떠안는 위치
AWSRDS for PostgreSQL/Aurora PostgreSQL자체 백업 인프라가 있지만, 셀프매니지드 PG 고객의 백업 도구 생태계 일관성이 자사 마이그레이션 경로에 직결
Supabase매니지드 PostgreSQL BaaS백엔드 전체가 PostgreSQL 위에 있습니다. 백업 도구가 흔들리면 Free-tier 자동 백업/복원 SLA가 바로 흔들립니다
pgEdge분산 PostgreSQL멀티 리전 백업/PITR 표준이 그대로 pgBackRest입니다. 대체 비용이 가장 큽니다
Tiger DataTimescaleDB(시계열 PG 익스텐션)TimescaleDB 운영 매뉴얼이 pgBackRest를 기본 가정으로 합니다
EonPG 백업/DR SaaS제품 자체가 pgBackRest 위에 얹혀 있습니다

요약하면 pgBackRest를 잃었을 때 가장 비싸게 무는 회사들이 모였습니다. 단독 후원사 모델은 시장 한 곳에서 손해를 보는 회사가 비용을 다 짊어지는 구조였고, 컨소시엄 모델은 시장 전체에서 손해를 보는 회사들이 N분의 1로 나누는 구조입니다. Crunchy Data가 한 명을 13년 받쳐 줬다면, 이제는 6사가 함께 받칩니다.

Percona CEO **Peter Farkas(피터 파카스)**의 발표문 한 줄이 이를 그대로 짚습니다.

“pgBackRest has been our recommended backup solution/tool for years… coordinating with other companies to keep it healthy was a straightforward decision.”

(pgBackRest는 우리가 수년 동안 권장해 온 백업 도구다. 이 도구를 건강하게 유지하기 위해 다른 회사들과 손을 잡는 결정은 어려운 결정이 아니었다.)

Percona에서 PostgreSQL P&E를 이끄는 **Kai Wagner(카이 바그너)**는 여기에 한마디 더 보탰습니다.

“Open source stays open. That’s not a slogan. It’s how we make decisions when situations like this come up.”

(“오픈소스는 열려 있다"는 슬로건이 아니다. 이런 상황이 닥쳤을 때 우리가 결정을 내리는 방식이다.)

읽는 사람에 따라 마케팅으로 받아칠 수도 있습니다. 다만 22일 만에 6사가 실제로 모였다는 사실이 그 슬로건을 한 번은 받쳐 줬다는 점은 분명합니다.

단독 메인테이너에서 다중 메인테이너로

이번 컨소시엄 발표에는 자금만큼 중요한 두 번째 줄기가 있습니다. Percona가 새 메인테이너 onboarding을 명시적으로 책임진다는 점입니다.

“Percona engineering involvement to onboard a new maintainer.”

13년 동안 코드 리뷰, 릴리스, 이슈 트리아지를 거의 한 사람이 처리한 프로젝트였습니다. 지난달 종료 글에서 정리한 구조적 함정이 정확히 그 지점입니다. 자금이 모여도 한 사람이 다시 떠안는 구조라면 같은 위기가 5년 뒤 그대로 반복됩니다.

이번 발표에서 공식화된 변화는 셋입니다. 첫째, Steele이 메인테이너로 복귀합니다. 후원 자금으로 dedicated time을 확보했습니다. 둘째, 단일 후원사 의존 모델을 해체하고 컨소시엄 모델로 전환합니다. 한 회사의 매각이나 예산 삭감 한 번으로 프로젝트가 흔들리지 않게 됩니다. 셋째, 추가 메인테이너를 영입합니다. Percona가 엔지니어링 리소스를 들여 후속 메인테이너를 onboarding합니다.

세 번째 항목이 가장 묵직합니다. 단독 메인테이너가 후원만 받는다고 지속가능성 문제가 사라지지 않는다는 인식을, DBA 커뮤니티 바깥에서도 받아들인 결과이기 때문입니다. 메인테이너가 한 명에서 둘, 둘에서 셋으로 늘어나는 구간을 실제로 통과해야 위기 반복이 끊깁니다.

flowchart TD
    OLD["기존 모델
(2013~2024)"] OLD_SUB["Crunchy Data 단독 후원
+ Steele 단독 메인테이너"] CRISIS["매각·이탈"] EOL["2026-04 종료 선언"] NEW["신 모델
(2026-05~)"] NEW_SUB["6사 컨소시엄 후원
+ 다중 메인테이너 영입"] RESILIENT["한 회사 이탈로
흔들리지 않는다"] OLD --> OLD_SUB OLD_SUB --> CRISIS CRISIS --> EOL EOL --> NEW NEW --> NEW_SUB NEW_SUB --> RESILIENT

오픈소스 지속가능성 모델로서의 의미

pgBackRest 한 건의 부활로 보면 작은 사건이지만, 비슷한 구조의 위기는 곳곳에 있습니다. Linux 커널의 일부 파일시스템 메인테이너, Curl의 Daniel Stenberg, SQLite의 D. Richard Hipp, 그리고 PostgreSQL 안의 Barman 자체도 결국 한 회사(EDB) 한 줄로 묶여 있습니다.

이번 사건이 보여준 흐름은 셋입니다.

  • 단일 회사 후원 + 단일 메인테이너 모델은 매각 한 번으로 무너집니다. Crunchy Data 매각 이후 Steele의 후속 정착이 안정될 때까지 시간이 충분히 주어지지 않았습니다.
  • DBA 커뮤니티의 압박이 후원사 의사 결정 속도를 끌어올립니다. 종료 발표 직후 “진짜 멈추면 어떻게 되나"의 시뮬레이션이 빠르게 돌면서, 후원하지 않을 때의 운영 비용이 후원할 때의 자금 부담보다 크다는 계산이 빠르게 섰습니다.
  • 컨소시엄 모델 + 다중 메인테이너 영입이 새 표준이 될 수 있습니다. Eclipse Foundation/CNCF처럼 형식화된 거버넌스까지 가지 않더라도, 비공식 컨소시엄으로 출발해 단계적으로 자리를 잡아가는 그림이 자연스럽습니다.

순서를 보면 씁쓸한 구석이 있어요. 한 사람이 손을 놓고 22일이 지나서야 6사가 모였지만, 그가 13년 일하는 동안에는 한 회사만 받쳐 줬고, 컨소시엄 모델이 정말 새 표준이 되려면 위기가 터진 다음이 아니라 터지기 전에 모이는 회의가 필요해요.

DBA 입장에서 결정을 다시 풀어 봅니다

지난달 종료 글의 DBA 가이드는 다음 PostgreSQL 메이저까지 여유를 두고 점진적으로 Barman/CNPG plugin-barman-cloud로 마이그레이션을 검토하라고 권했습니다. 이제 그 결정이 풀립니다.

시나리오4/27 종료 발표 시점 권고5/19 컨소시엄 발표 이후 권고
pgBackRest 운영 중, 안정적PG 19 출시까지는 그대로 두고, 그 사이 대안 도구 PoC를 진행합니다그대로 유지합니다. 컨소시엄 발표로 보안/호환성 공급이 보장됐습니다
Barman 마이그레이션 진행 중계속 진행합니다진행 중인 마이그레이션은 마무리합니다. 굳이 되돌릴 이유는 없습니다
신규 클러스터 백업 도구 선정신규는 Barman 또는 plugin-barman-cloud를 권장합니다pgBackRest도 다시 선택지에 올립니다. 신규 도입 시 두 도구를 동급으로 비교합니다
CNPG 사용자plugin-barman-cloud를 유지합니다plugin-barman-cloud를 유지합니다(CNPG는 처음부터 Barman 라인업입니다)

신규 도입 시점에 가장 큰 차이가 생깁니다. 종료 발표 시점에는 “한 사람만 만지는 도구를 신규로 쓰겠다고 결정하기는 어렵다“가 권고였습니다. 컨소시엄 발표 이후에는 “6사가 함께 받치는 도구“로 그 결론이 갈렸습니다.

다음 분기점은 PostgreSQL 19

진짜 검증은 다음 메이저 출시입니다.

  • PostgreSQL 19(2026-09 예정)이 컨소시엄 체제의 첫 메이저 대응입니다. v2.59 또는 그 후속 릴리스에서 PG 19 공식 지원이 들어와야 합니다. 이게 제때 풀리면 컨소시엄 모델은 DBA 신뢰를 한 번 얻습니다.
  • 새 메인테이너 영입 시점도 관건입니다. Percona가 명시적으로 책임진 onboarding이 1~2년 안에 가시화돼야 합니다. 단순히 Steele 한 명 복귀로 끝나면 5년 뒤 같은 위기가 반복됩니다.
  • 추가 후원사 합류가 남습니다. 6사가 중심이지만 지속 가능성 차원에서는 더 두꺼워질 필요가 있습니다. EDB, Crunchy Data, Cloud Native(EnterpriseDB Postgres) 같은 큰 회사들이 어떻게 움직일지가 관전 포인트입니다.

정리

4월 27일 종료 발표 때 archive였던 저장소는 다시 active로 돌아왔고, 없던 메인테이너 자리는 Steele 복귀에 더해 신규 영입까지 예고됐습니다. 후원은 6사 컨소시엄이 떠안았고, 불확실하던 PostgreSQL 19 호환성도 컨소시엄이 책임집니다. 종료 발표 직후 점진 마이그레이션을 검토하라던 DBA 권고는, 이제 그대로 유지하되 신규 도입에서도 다시 후보에 올리는 쪽으로 바뀌었습니다.

13년 단독 시대가 22일 만에 6사 컨소시엄 시대로 넘어갔어요. 정세는 풀렸지만 컨소시엄 모델이 정말 지속 가능한지는 첫 번째 PostgreSQL 메이저 대응과 새 메인테이너 영입 시점이 결정하며, 그동안 DBA는 마이그레이션 압력 없이 한 분기 정도 더 호흡할 수 있어요.

참고