PostgreSQL 14 지원 종료까지 두 달: 업그레이드보다 먼저 복구를 연습하기
데이터베이스 버전을 올리는 일정은 잡았는데 실패했을 때 돌아가는 시간은 모르는 팀이 있습니다. PostgreSQL 14를 운영하고 있다면 지금 필요한 산출물은 새 버전 이름 하나보다, 복구가 가능한 전환 계획입니다. 2026년 9월 14일 기준 공식 지원 종료일까지 약 두 달이 남았습니다.
확인된 사실: 커뮤니티 지원과 호스팅 계약은 다릅니다
PostgreSQL 공식 버전 정책은 메이저 버전을 5년간 지원하며, 14의 최종 릴리스 날짜를 2026년 11월 12일로 안내합니다. 이는 커뮤니티 지원 일정입니다. 관리형 서비스의 업그레이드 창, 별도 연장 지원, 요금은 해당 사업자 문서와 계약에서 따로 확인해야 합니다.
같은 메이저 버전의 마이너 업데이트와 메이저 업그레이드도 구분해야 합니다. 14의 최신 수정 버전을 적용하는 일은 15 이상으로 옮기는 일을 대체하지 않습니다. 반대로 메이저 전환 계획이 있다는 이유로 현재 버전의 필요한 수정 적용을 계속 미루는 것도 적절하지 않습니다.
첫 산출물: 데이터 크기보다 의존성 목록
여기부터는 공식 지원 정책 자체가 아닌 실무 운영 제안입니다. 먼저 서비스별 DB 버전, 확장 모듈과 버전, 연결 드라이버, 배치 작업, 백업 보관 위치, 복제 구성을 한 장에 적습니다. 대상 버전은 최신이라는 이유만으로 정하지 말고 실제 호스팅 환경과 확장 모듈의 지원 범위를 함께 확인합니다.
작은 DB라서 빠를 것이라는 가정은 충분하지 않습니다. 로그인 이후 첫 조회, 결제 상태 갱신처럼 사업상 중요한 경로에 사용되는 확장이나 쿼리가 달라지면 데이터 복사가 짧아도 전환은 실패할 수 있습니다. 책임자가 없는 의존성을 찾는 것이 이 목록의 목적입니다.
두 번째 산출물: 백업 성공 메시지 대신 복원 결과
격리된 환경에 최근 백업을 복원하고 애플리케이션의 대표 읽기·쓰기 흐름을 실행합니다. 이 연습에서는 운영 DB에 쓰기를 보내지 않도록 연결 대상을 먼저 확인해야 합니다. 실제 데이터가 포함된 복원본은 기존 접근 통제 범위 안에서 다룹니다.
백업 시작 시각, 복원 완료 시각, 검증 완료 시각을 분리하면 파일을 가져오는 시간과 서비스가 다시 쓸 수 있는 시간을 혼동하지 않습니다. 인위적으로 빠른 작은 샘플만 통과시키기보다 운영 크기에 가까운 복원본으로 시간을 측정하고, 비용과 공간 제약도 기록합니다.
pg_upgrade 점검 통과가 서비스 검증을 대신하지 않습니다
공식 pg_upgrade 문서는 --check로 실제 업그레이드 전에 호환성 점검을 수행할 수 있다고 설명합니다. 외부 모듈의 호환성은 별도로 살펴야 하며, 새 서버에 맞는 공유 라이브러리도 필요합니다. 점검 명령의 성공만으로 애플리케이션 쿼리와 성능이 모두 검증됐다고 해석하지 마세요.
특히 --link 방식은 새 클러스터를 시작한 뒤 기존 클러스터를 그대로 사용할 수 없다는 제약이 있습니다. 속도만 보고 방식을 선택하면 예상했던 되돌리기 경로가 사라질 수 있습니다. 실제 전환 방식과 동일한 조건으로 리허설하고, 복원 기반 복귀가 필요한 시점을 명시해야 합니다.
쓰기 재개 전에 결정할 기준
전환 당일 즉석에서 합의하지 않도록 성공 기준을 미리 적습니다. 예를 들어 핵심 API의 읽기·쓰기 완료, 중복 처리 없이 배치 재개, 주요 테이블의 업무상 집계 일치, 복제 상태 확인을 담당자와 연결할 수 있습니다. 이는 모든 서비스에 동일한 기준값을 강요하는 예제가 아닙니다.
새 DB에서 쓰기를 시작한 뒤 이전 백업으로 돌아가면 그 사이의 변경을 어떻게 보존할지도 문제가 됩니다. 단순히 이전 서버를 켜는 절차와 데이터 손실 없이 되돌리는 절차를 같은 것으로 취급하지 않습니다. 허용 가능한 손실과 중단 범위는 서비스 책임자가 합의해야 합니다.
이번 주 할 일과 반론
한 번에 모든 DB를 옮기기 어렵다면 가장 의존성이 적은 서비스 하나로 복원·검증·복귀 시간을 측정하고 결과를 다른 서비스 계획의 입력으로 사용하세요. 담당자와 전환 후보일, 검증 실패 시 중단 기준을 한 문서에 모으면 일정만 있는 프로젝트에서 실행 가능한 작업으로 바뀝니다.
당장 제품 개발이 더 급하다는 반론은 이해할 수 있습니다. 다만 마감 직전까지 복구 방법을 모르는 상태를 유지하면 선택 가능한 점검 시간이 줄어듭니다. 이 글은 특정 버전의 성능 향상이나 커뮤니티 전체의 의견을 주장하지 않습니다. 최신 기능을 도입하는 속도보다 전환 실패를 처리할 준비에 초점을 둔 운영 제안입니다.