2026 PostgreSQL 14 지원 종료 전, 확장 호환성은 어떻게 확인할까?

판단 먼저: 확장 검증 전에는 생산 전환을 보류하세요

PostgreSQL 공식 지원 일정에 따르면 PostgreSQL 14는 2026년 11월 12일에 지원이 종료됩니다. 공식 버전 지원 페이지에서 일정을 확인할 수 있습니다. 따라서 PostgreSQL 14 확장 호환성 검사는 확장 이름만 대조하지 말고, 대상 환경에 맞는 파일과 버전 갱신 경로까지 확인한 다음 격리 환경에서 실제 애플리케이션 기능을 검증해야 합니다. 지원 종료가 가까워도 검증과 복구 연습을 마치지 않았다면 시험하지 않은 업그레이드를 생산 환경에 바로 적용하지 마세요.

적합: PostgreSQL 14 자체 구축 환경에서 확장 기능을 쓰며 이전을 계획하는 팀입니다.
부적합: 확장 의존성이 없고 이미 검증된 업그레이드 절차가 있어, 확장 호환성 점검 자체가 필요하지 않은 팀입니다.

이 글은 대상 PostgreSQL 버전을 선택하거나 전체 이전 절차를 설명하지 않습니다. 확장 호환성에서 발생할 수 있는 차단 요소를 찾아내고, 다음 작업을 진행해도 되는지 판단하는 데 초점을 둡니다.

PostgreSQL 14를 관리하는 DBA는 설치 확장과 갱신 경로를 확인해야 합니다.
백엔드 엔지니어는 애플리케이션이 실제 호출하는 확장 기능을 검증해야 합니다.
SaaS 기술 책임자는 지원 종료 전에 격리 테스트와 생산 전환을 마칠 수 있는지 판단해야 합니다.

마지막 업데이트: 2026년 10월 28일. 지원 종료 일정은 PostgreSQL 공식 지원 페이지와 PostgreSQL 14.24 공개 안내를 기준으로 확인했습니다. 게시 전에는 두 공식 자료의 최신 내용을 다시 확인하세요.

설치 목록과 실제 의존성의 차이

PostgreSQL 14 업그레이드 전에 설치 확장을 어떻게 확인하나요?

pg_extension은 현재 데이터베이스에 설치된 확장을 보여주는 시스템 목록입니다. 공식 시스템 카탈로그 설명을 참고해 각 데이터베이스에 접속해서 실행하세요.

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

이 결과는 접속한 데이터베이스의 설치 상태이지, 클러스터 전체나 애플리케이션의 모든 의존성을 보증하는 목록은 아닙니다. 데이터베이스마다 같은 쿼리를 수행하고 결과를 모아야 합니다. 이어서 배포 스크립트, 스키마 변경 스크립트, 데이터베이스 객체, 애플리케이션 코드에서 확장 함수나 형식을 쓰는지 확인하세요.

pg_available_extensions는 현재 접속한 서버에서 사용할 수 있는 확장 정보를 나타냅니다. 공식 뷰 문서의 설명에 따라 확인하되, 원본 서버의 목록을 대상 서버의 지원 목록으로 오해하지 마세요.

대상 서버의 파일과 갱신 경로

PostgreSQL 확장은 새 버전에서도 사용할 수 있나요?

확장 이름이 같다는 사실만으로 대상 버전에서 사용할 수 있다고 판단할 수 없습니다. 대상 PostgreSQL 설치에 해당 확장의 파일이 있어야 하고, 그 파일과 확장 버전이 대상 메이저 버전과 호환되어야 합니다. PostgreSQL 확장은 제어 파일과 설치 스크립트 등을 통해 설치·갱신되므로, 공식 확장 문서를 바탕으로 대상 환경을 따로 확인하세요.

대상 서버에서 아래처럼 목록을 확인하면, 그 서버가 제공하는 항목과 설치 상태를 살펴볼 수 있습니다.

SELECT name, default_version, installed_version
FROM pg_available_extensions
ORDER BY name;

설치 버전과 대상 서버의 기본 버전이 다르면, 확장별 갱신 경로도 확인하세요. 지원되는 경우 다음과 같이 경로 정보를 조회할 수 있습니다.

SELECT source, target, path
FROM pg_extension_update_paths('확장 이름');

출력에 경로가 있다고 해서 업무 기능까지 검증된 것은 아닙니다. 변경 절차는 공식 ALTER EXTENSION 문서를 확인하고, 확장 개발자가 제공하는 대상 버전별 안내와 함께 검토하세요. 확장마다 호환 여부가 다르므로 다른 팀의 경험을 전체 확장에 적용하지 마세요.

pg_upgrade 사전 검사와 실패 분류

pg_upgrade로 확장 호환 문제를 어떻게 확인하나요?

pg_upgrade의 검사 모드는 업그레이드 실행 전에 설치 간 호환성을 살피는 데 쓸 수 있습니다. 단, 검사 통과는 애플리케이션 기능 검증을 대신하지 않습니다. 실제 명령은 선택한 대상 버전 문서와 설치 경로에 맞춰 구성하세요. PostgreSQL 17의 pg_upgrade 문서와 PostgreSQL 18의 pg_upgrade 문서에 사전 검사와 실행 방식이 설명되어 있습니다.

pg_upgrade --check \
  -b <기존_실행파일_경로> \
  -B <대상_실행파일_경로> \
  -d <기존_데이터_디렉터리> \
  -D <대상_데이터_디렉터리>

검사 결과와 서버 로그를 함께 보고, 실패 원인을 다음처럼 구분하세요.

확장을 제거하거나 객체를 정리하는 방식으로 오류를 피하려면 먼저 그 확장이 제공하는 형식, 함수, 인덱스와 업무 의존성을 확인하세요. 테스트 환경에서 변경한 뒤 결과를 검증하지 않고 생산 환경에서 삭제하지 마세요.

애플리케이션 검증과 확장 갱신

업그레이드 뒤 확장도 따로 올려야 하나요?

확장 설치 여부와 확장 버전 갱신은 별개의 확인 항목입니다. pg_upgrade 이후 확장 버전 갱신이 필요한지는 설치된 버전, 대상 파일과 확장별 지원 경로에 따라 달라집니다. 확장 이름이 유지되더라도 필요한 갱신 절차가 있을 수 있으므로, 대상 환경에서 설치 버전을 다시 조회하고 해당 확장의 공식 안내를 확인하세요.

격리 환경에서는 애플리케이션이 실제 사용하는 기능을 기준으로 테스트 범위를 정합니다.

• 핵심 질의와 확장 함수 호출이 예상 결과를 내는지 확인합니다.
• 확장 관련 형식이나 인덱스가 있는 경우 생성, 조회, 갱신 동작을 점검합니다.
• 데이터베이스 객체와 배포·마이그레이션 스크립트가 대상 버전에서 작동하는지 확인합니다.
• 연결 프로그램과 ORM, 백업·복구 도구가 대상 버전과 함께 동작하는지 시험합니다.
• 결과에 설치 버전, 실행 절차, 실패 현상, 복구 또는 되돌림 방법을 기록합니다.

테스트 기록은 확장별로 남기세요. 한 확장의 성공을 다른 확장의 호환 근거로 삼지 마세요. 성능 시험을 하지 않았다면 성능 향상이나 성공률을 단정하지 말고, 검증한 기능과 조건만 기록합니다.

지원 종료 전환을 결정하는 조건

아래 조건에 따라 진행 여부를 정하세요.

• 대상 파일, 버전 갱신 경로, 애플리케이션 기능 검증이 모두 끝났고 복구 가능한 백업을 확인했다면: 생산 전환 일정을 확정하고, 시험에서 사용한 절차와 되돌림 계획을 그대로 적용합니다.
• 대상 파일은 있지만 갱신 경로나 객체 의존성이 불분명하다면: 생산 전환을 보류하고 격리 환경에서 확장별 경로와 의존성을 재현합니다.
• 필요한 확장 파일을 준비할 수 없거나 기능 검증에 실패했다면: 확장 대체 가능성을 확인하거나 별도의 이전 계획을 세웁니다. 미검증 상태로 생산 전환하지 않습니다.
• 백업 복구를 시험하지 않았거나 기계 장애 시 복구 계획이 없다면: 업그레이드보다 복구 검증을 먼저 완료합니다.

데이터 디렉터리를 업그레이드하는 절차와 되돌림 계획은 백업 전략과 함께 설계해야 합니다. 백업은 서버 밖에도 보관하고, 실제 복구가 가능한지 시험하세요. PostgreSQL 백업·복구 문서는 선택할 수 있는 백업 방식과 복구 관련 내용을 안내합니다. 독립 서버를 사용하더라도 데이터가 자동으로 중복 저장되거나 손실되지 않는 것은 아닙니다.

자체 구축 서버의 환경 확인

격리 환경과 생산 환경의 차이가 크면 확장 검증 결과를 그대로 적용하기 어렵습니다. 운영체제, 메모리, 저장 장치 배치, 접속 방식을 실제 배포 계획과 맞추세요. 메모리와 디스크 구성을 함께 검토할 때는 서버 메모리·디스크 안내를 참고할 수 있습니다. 원격 셸 접속 조건은 SSH 접속 안내에서 확인하세요.

OSFP Cloud 제품표 기준으로 자체 구축 대상 환경을 검토한다면, EPYC 7543P 기반 구성과 128GB 또는 256GB ECC 메모리, 직결 NVMe 구성을 실제 작업 부하에 맞춰 확인할 수 있습니다. 기본 저장 장치는 2 × 1TB NVMe이며 하드웨어 RAID는 제공되지 않습니다. 따라서 디스크 장애에 대비하려면 소프트웨어 미러링이나 복제, 기계 밖 백업을 별도로 계획해야 합니다. 설치 가능한 운영체제와 접속 방식도 배포 전에 제품표에서 확인하세요. 이 내용은 서버 자원 점검을 위한 것이며, 확장 설치나 데이터베이스 이전 지원을 뜻하지 않습니다.

공유 클라우드 인스턴스는 임시 작업이나 부하가 가벼운 서비스에 적합할 수 있지만, 이웃 작업과 자원 경합 가능성, 요금제별 저장 장치 성능 조건, 직접 구성할 수 있는 디스크 배치의 제약을 검토해야 합니다. 반대로 짧은 시간만 쓰거나 부하가 매우 낮다면 독립 서버 임대가 필요하지 않을 수 있습니다. 확장 의존성이 많은 데이터베이스를 장기간 운영하고 자원과 디스크 배치를 직접 관리하려는 경우라면, 공유 인스턴스의 조건과 OSFP Cloud의 독립 AMD 물리 서버 구성을 실제 운영 요건에 맞춰 비교해 보세요. 생산 전환 전에 목표 자원과 복구 계획부터 확인하려면 OSFP Cloud 안내를 참고할 수 있습니다.