pgBackRest가 죽었다. 이제 무엇을 해야 하나?

• pgBackRest의 단독 유지보수자 David Steele이 프로젝트 GitHub 페이지에서 모든 작업 중단을 밝히며 유지보수, 버그 수정, PR 리뷰, 신규 기능 개발이 멈추게 됨
• pgBackRest는 PostgreSQL 백업, 복원, PITR까지 다루던 신뢰성 높은 인프라였지만, David가 13년간 맡아 온 지속적인 유지 작업을 보수 없이 계속할 수 없는 상태가 됨
• pg_basebackup은 백업 카탈로그, WAL 보존 관리, 복원 명령, PostgreSQL 13 이전의 내장 무결성 검증이 없고, pg_dump는 PITR이 없어 복구 전략으로 보기 어려움
• 새 백업 도구를 평가하는 조직에는 활발히 유지보수되고 WAL 아카이빙, 백업 카탈로그, 보존 관리, 복원을 제공하는 Barman이 가장 진지한 대안으로 꼽힘
• 운영 환경의 pgBackRest 사용자가 즉각적인 위험에 처한 것은 아니지만, 새 PostgreSQL 릴리스와 패치되지 않은 버그가 쌓일수록 대응 시간이 줄어들며 포크도 아직 신뢰를 새로 쌓아야 함

---

pgBackRest 유지보수 중단의 배경

• pgBackRest의 단독 유지보수자인 David Steele이 프로젝트 GitHub 페이지에서 모든 작업을 중단한다고 밝히며, 유지보수, 버그 수정, PR 리뷰, 신규 기능 개발이 더 이상 이뤄지지 않게 됨
• pgBackRest는 PostgreSQL 백업 도구로 오랫동안 추천될 만큼 완성도가 높았고, Université Lyon I 학생들이 사전 지식 없이 4시간 안에 백업, 복원, PITR을 수행할 수 있을 정도로 사용성이 좋았음
• David는 13년 동안 pgBackRest를 유지해 왔으며, Stephen Frost와 Stefan Fercot도 프로젝트의 핵심 기여자로 꼽힘
• Crunchy Data가 pgBackRest를 상당 기간 후원했고 David를 고용했지만, 회사가 매각된 뒤 David는 프로젝트를 계속할 수 있는 일자리와 독립 후원을 몇 달 동안 찾았으나 실패함
• pgBackRest에는 지속적인 유지 노력이 필요하지만, David가 보수 없이 계속 제공할 수 없는 상태가 됨

오픈소스 인프라의 지속 가능성 문제

• pgBackRest는 PostgreSQL 생태계에서 가장 신뢰할 수 있는 인프라 중 하나로 13년간 만들어졌지만, David가 같은 일을 계속할 수 있도록 고용하려는 회사는 없었음
• 기업들은 RAM과 GPU를 사들이고 AI 제품에 투자하는 반면, 재해 상황에서 데이터를 살리는 사람에게 비용을 지불하는 일은 우선순위에서 밀려남
• 많은 대기업이 pgBackRest 위에서 큰 수익을 만들었고, PostgreSQL 생태계에 직접 기반한 수익성 높은 데이터베이스 서비스에도 운영 환경으로 배포되어 있음
• 프로젝트 README에는 후원 링크가 있었지만, David가 중단을 발표한 시점의 활성 후원자는 1곳뿐이었음
• 오픈소스 모델은 가치를 소비하는 쪽이 유지에도 기여할 때 작동하며, 모두가 다른 누군가가 유지비를 낼 것이라고 가정하면 깨지게 됨

pgBackRest가 제공하던 가치와 대안의 한계

• pgBackRest가 사라지면서 단순 백업 실행 도구가 아니라 복구 전략 전체를 다루는 PostgreSQL 인프라가 약해짐
• pg_basebackup은 실행 중인 클러스터 디렉터리를 복제하도록 설계된 도구이며, 백업 카탈로그, WAL 보존 관리, 복원 명령, PostgreSQL 13 이전의 내장 무결성 검증이 없음
• pg_basebackup을 만든 PostgreSQL 코어 팀 멤버 Magnus Hagander는 Twitter 대화에서 “pg_basebackup은 백업을 생각하지만 사람들에게는 복구를 생각하는 도구가 필요하며, 백업은 과정 중간의 한 단계일 뿐 끝이 아니다”라는 표현에 동의함
• pg_basebackup은 스탠바이 구성을 위한 훌륭한 도구지만, 복구 전략은 아님
• pg_dump는 PITR이 없기 때문에 덤프가 시작된 시점과 복원이 필요한 시점 사이의 트랜잭션을 영구히 잃게 되며, 큰 덤프의 복원 시간은 장애 상황에서 감당하기 어려움
• pg_dump는 백업 도구라기보다 내보내기 도구에 가깝고, 이를 백업 도구라고 부르면 실제 데이터 손실을 일으키는 잘못된 안정감을 만들 수 있음
• Barman은 현재 활발히 유지보수되고 크게 개선된 도구이며, 지금 대안이 필요한 조직에 가장 진지한 선택지로 꼽힘
• Barman은 pg_basebackup의 한계 위에 만들어진 아키텍처적 부담이 있지만, WAL 아카이빙, 백업 카탈로그, 보존 관리, 복원을 포함해 핵심 공백을 메움

pgBackRest 사용자에게 필요한 대응

• David는 pgBackRest가 결국 포크될 것으로 예상했고, 견고한 C 코드베이스와 올바른 아키텍처 덕분에 PostgreSQL 생태계의 기술력 있는 회사들이 맡을 수 있는 기반이 있음
• 아직 포크는 나오지 않았고, 포크가 생기더라도 커뮤니티 신뢰를 처음부터 다시 쌓아야 함
• 지금 백업 도구를 평가하는 조직에는 Barman 사용이 권장됨
• 운영 환경에서 pgBackRest를 쓰고 있는 조직이 즉각적인 위험에 처한 것은 아니지만, 새 PostgreSQL 릴리스가 나오고 패치되지 않은 버그가 쌓일수록 대응 가능한 시간이 줄어듦
• 중간에 pgBackRest의 치명적인 버그를 발견하면 Data Egret과 Cybertec 같은 PostgreSQL 전문성을 가진 회사가 문제 해결을 도울 수 있음
• 전문 업체의 지원은 장기 해법이 아니라, 커뮤니티가 다음 단계를 찾는 동안 시간을 벌어주는 선택지에 가까움

PostgreSQL 생태계에 남는 경고

• pgBackRest는 기술 실패나 커뮤니티 갈등 때문에 멈춘 것이 아니라, 신뢰성 높은 인프라를 만드는 사람에게 산업이 충분히 비용을 지불하지 않았기 때문에 이 지점에 도달함
• PostgreSQL 생태계에는 중요한 일을 하는 뛰어난 사람들이 많지만, 그 작업은 취약하거나 존재하지 않는 자금 구조 위에서 이뤄지는 경우가 많음
• pgBackRest가 이런 상황에 놓인 마지막 프로젝트는 아닐 수 있음
• 기업들이 오픈소스 인프라를 의무 없는 무료 자원처럼 다루기 전에 다시 생각하게 만드는 계기가 될 필요가 있음
• David가 만든 pgBackRest는 이 순간을 넘어 남을 만한 결과물이며, 이제 커뮤니티가 그 수준에 맞게 대응해야 함

[ndrgrd]

항상 하는 생각이지만 오픈소스 라이선스는 개발자를 위한 것이 아니라 사용자를 위한 것입니다. 오픈소스를 채택할 것이라면 이걸 잘 생각해봐야 합니다.

[GN⁺]

Lobste.rs 의견들

• 이 글이 올라온 뒤 PGX가 pgxbackup으로 포크했다는 점은 짚고 넘어갈 만함

  • 결국 사람들이 관리자에게 자금을 대는 대신 포크하기로 한 건가? 정말로? 우리가 이렇게 배은망덕한 쪽으로 퇴화한 건가 싶음
    생각해보면 관리자가 손 떼기로 한 건 옳은 선택이었음
  • 그리고 곧바로 대충 만들어진 느낌이라 사양함

• 모든 걸 공짜로 내주고, 그다음 수백만·수십억 달러짜리 회사들에게 초라한 선택적 기부를 구걸하고 기대하는 흔한 오픈소스 모델이 점점 싫고 원망스러워졌음
  다른 라이선스 구조라면 순수한 자선에만 기대지 않고도 생태계를 건강하게 유지할 수 있는 공정한 균형을 만들 수 있음
  이 모델은 90년대처럼 공간이 지금처럼 과도하게 상업화되지 않았을 때는 나름 매력이 있었지만, 2026년에는 더 이상 정당화하기 어렵고 "커뮤니티"에 대한 "공산주의적" 공상론에도 관심 없음

  • PolyForm 라이선스 중 일부, 예를 들면 소규모 사업자 라이선스에 관심이 갈 수도 있음

• 이후 진전이 있었음. 현재 프로젝트 README에는 이렇게 나옴:
  “이제 상황이 바뀌었고, 프로젝트를 계속할 만큼 충분한 자금을 확보할 가능성이 거의 확실해 보입니다. 이번에는 pgBackRest가 후원자 연합의 지원을 받게 되어, 단일 인수 건이 더 이상 제가 프로젝트 작업을 계속할 수 있는 능력에 영향을 주지 않게 됩니다. 작업 부담을 나누고 향후 연속성을 제공할 다른 관리자도 합류시킬 수 있을 것입니다”