주요 내용

•   PostgreSQL 12는 2024년 11월 14일에 지원 종료되었으며, 일주일 후 커뮤니티의 마지막 릴리스인 12.22가 출시되었습니다. 이제 커뮤니티 측에서는 더 이상 보안 패치나 버그 수정 사항을 제공하지 않습니다.
•   데이터베이스는 지원 종료(EOL) 이후에도 계속 가동되는데, 바로 이것이 문제입니다. 패치가 적용되지 않은 CVE 취약점들이 조용히 쌓이다가, 규정 준수 감사나 악용 사례가 발생해야 비로소 시급한 문제가 되는 것입니다.
•   현실적인 대안으로는 지원되는 릴리스(18, 17, 16 또는 15)로 업그레이드하거나, 마이그레이션을 계획하는 동안 패치를 계속 적용받기 위해 공급업체 지원 또는 클라우드 제공업체의 확장 지원을 이용하는 방법이 있습니다.
•   PostgreSQL의 주요 업그레이드에는 실질적인 테스트 시간이 필요합니다. 확장 기능 및 드라이버와 관련된 호환성 문제는 대개 전환 작업 자체보다 더 많은 작업을 야기합니다.

2024년 11월 15일, 귀하의 PostgreSQL 12 인스턴스는 다운되지 않았습니다. 아마 잠시라도 멈춘 적조차 없었을 것입니다. 바로 그게 함정입니다.

PostgreSQL 12는 2024년 11월 14일에 지원 종료(EOL)되었습니다. 커뮤니티는 마지막 비정기 릴리스인 12.22를 출시하여 회귀 현상을 수정했고, 이후 해당 브랜치를 영구적으로 폐쇄했습니다. 소프트웨어 자체는 여전히 작동하지만, 보안 및 버그 수정 지원은 중단되었습니다. 대부분의 팀은 이를 생산 환경에 그대로 둔 채 더 시급한 업무로 넘어갑니다. 그러다 몇 달 뒤, 새로 공개된 취약점이 12.x 계열에 영향을 미치는 것으로 드러나고, 커뮤니티에서 패치를 제공하지 않자, “잘 작동하던” 시스템이 갑자기 알려진, 수정 불가능한 결함을 안고 있게 됩니다.

이 가이드에서는 해당 지원 종료(EOL) 날짜에 실제로 어떤 변화가 있었는지, 실제 상황에서 어떤 위험이 도사리고 있는지, 그리고 패치가 적용된 상태로 되돌리기 위한 선택지에는 어떤 것들이 있는지 다룹니다. 또한 각 경로를 따라갈 때 어떤 부분에서 어려움이 발생할 수 있는지에 대한 솔직한 설명도 포함되어 있습니다.

PostgreSQL 12의 지원 종료는 무엇을 의미할까요?

지원 종료(EOL)란 PostgreSQL 글로벌 개발 그룹이 12.x 버전의 최종 릴리스를 출시하고 해당 브랜치를 폐쇄했음을 의미합니다. 보안 패치도, 버그 수정도 더 이상 제공되지 않습니다. 새로 공개된 취약점이 PostgreSQL 12에 영향을 미치는 경우, 커뮤니티 차원에서는 영구적으로 패치되지 않은 상태로 남게 됩니다. 규제 대상 데이터를 처리하거나 인터넷에 노출된 애플리케이션을 지원하는 EOL 데이터베이스는, 해당 브랜치에 새로운 결함이 발견될 때마다 커뮤니티 차원의 수정 사항이 제공되지 않기 때문에 점점 더 큰 위험 요소가 됩니다.

유의해야 할 중요한 PostgreSQL 지원 종료(EOL) 날짜

PostgreSQL 프로젝트는 각 메이저 버전을 초기 출시 후 5년 동안 지원한 뒤 최종 마이너 릴리스를 하나 출시한 후 지원을 종료합니다. Node.js LTS와 같이 별도의 “활성” 및 “유지보수” 단계는 없습니다. 5년이라는 단일 기간이 지나면 해당 브랜치는 폐기됩니다.

버전	출시됨	수명 종료	상태
18	2025년 9월	2030년 11월	지원됨 (최신 버전)
17	2024년 9월	2029년 11월	지원됨
16	2023년 9월	2028년 11월	지원됨
15	2022년 10월	2027년 11월	지원됨
14	2021년 9월	2026년 11월	지원 중 (곧 종료됩니다)
13	2020년 9월	2025년 11월	EOL
12	2019년 10월	2024년 11월	EOL
11	2018년 10월	2023년 11월	EOL

12 버전을 사용 중이라면, 지원되는 가장 오래된 브랜치보다 두 개의 메이저 버전 뒤처져 있는 것입니다. 13 버전을 사용 중이라면, 2025년 11월에 EOL(지원 종료) 클럽에 합류하게 됩니다 . 14버전은 서류상으로는 안전해 보이지만, 지원 종료일은 2026년 11월 12일로, 생각보다 있습니다.

PostgreSQL 버전이 단종되는 이유

메이저 버전을 단종시키는 것은 커뮤니티가 고집을 부리는 것이 아닙니다. 이는 프로젝트의 건전성을 유지하기 위한 신중한 타협입니다. 이를 이끄는 몇 가지 요인이 있습니다.

5년이라는 기간은 설계상 고정되어 있습니다

PostgreSQL은 초기 릴리스 시점부터 계산하여 각 메이저 버전당 5년간의 지원을 보장합니다. 이러한 예측 가능성은 정말 유용합니다. 어떤 버전이든 살펴보기만 하면 수년 전에 그 지원 종료일을 미리 알 수 있기 때문입니다.

문제는 시계가 여러분의 마이그레이션 미처리 작업량을 전혀 신경 쓰지 않는다는 점입니다. PostgreSQL 12는 2019년 10월에 출시되었으므로, 2024년 11월의 지원 종료(EOL) 시점은 사실상 출시 첫날부터 정해져 있었던 셈입니다. 그 날짜를 “언젠가” 정도로만 여겼던 팀들은, 날짜라는 게 대개 그렇듯, 그 날이 예정대로 다가오는 것을 목격하게 되었습니다.

오래된 지점을 유지하는 데는 비용이 많이 듭니다

지원되는 모든 주요 버전은 별도의 브랜치로 구성되어 있으며, 유지보수 담당자들은 각 브랜치에 패치를 적용하고, 테스트를 수행하며, 릴리스를 진행해야 합니다. 단 하나의 보안 수정 사항을 5~6개의 활성 브랜치에 역이식하는 작업은 상당한 공학적 노력이 필요한 일로, 프로젝트 기여자들과 이를 후원하는 기업들이 담당하고 있습니다.

어느 시점이 되면 오래된 브랜치를 유지하는 데 드는 비용이 그로 인한 이점을 상회하게 됩니다. 코드 경로는 갈라지고, 테스트 인프라는 노후화됩니다. 현재 브랜치에서는 간단하게 해결할 수 있는 문제라도, 5년 전 코드베이스에서는 번거로운 수정이 필요할 수 있습니다. 가장 오래된 브랜치를 폐기하면 프로젝트 팀은 그 에너지를 대다수의 사용자가 실제로 실행하는 버전에 집중할 수 있습니다.

보안 백포트의 유효 기간이 있습니다

일부 취약점은 오래된 코드에서 패치하기 쉽습니다. 반면, 일부는 최신 버전에서 변경된 아키텍처에 의존하는 경우가 있는데, 이러한 수정 사항을 훨씬 오래된 브랜치로 역이식하는 작업은 번거로울 뿐만 아니라 실제로 위험할 수도 있습니다. 역이식 과정 자체가 수년 동안 아무도 실행해 본 적 없는 코드 경로에서 회귀 현상을 유발할 수도 있습니다.

버전이 EOL(지원 종료) 상태가 되면, 그 백포트 작업의 부담은 여러분에게, 혹은 그 작업을 처리하도록 비용을 지불하는 대상에게 넘어가게 됩니다.

지원 종료(EOL)된 PostgreSQL 버전을 사용할 때의 위험

PostgreSQL 12를 계속 사용하는 데 따르는 위험은 단순히 가상의 문제가 아닙니다. 기다릴수록 이러한 위험은 더욱 커집니다.

패치되지 않은 보안 취약점

PostgreSQL 12의 지원 종료(EOL) 이후 공개된 모든 취약점은 커뮤니티 차원에서 계속 미해결 상태로 남게 됩니다. 2024년 11월 21일에 출시된 비정기 릴리스인 12.22는 12 버전이 받을 수 있는 마지막 패치 버전입니다. 이 버전은 지원 기간을 연장하기 위한 것이 아니라, 12.21 버전의 회귀 현상을 수정하기 위해 출시된 것입니다. 그 이후에 공개된 취약점은 12 버전에 영향을 미치지 않거나, 영향을 미치더라도 커뮤니티 차원의 수정 패치를 절대 받을 수 없습니다.

이러한 전반적인 추세가 상황을 더욱 악화시키고 있습니다. 취약점 추적 기관들은 는 2026년 상반기에 16건의 PostgreSQL CVE를 기록했는데, 이는 이미 2025년 전체 기록보다 많은 수치이며, 평균 심각도 점수는 7을 상회했습니다. 커뮤니티의 2026년 5월 보안 릴리스 만 해도 지원되는 모든 브랜치에 걸쳐 심각도 점수가 8.8에 달하는 11건의 취약점에 대한 패치가 제공되었습니다. 이 중 일부는 버전 12에 영향을 미치지 않습니다. 우려되는 점은 새로 공개된 문제가 버전 12에 영향을 미칠 경우, 커뮤니티가 더 이상 이에 대한 수정 패치를 제공하지 않을 수 있다는 것입니다.

패치가 적용되지 않아 발생할 수 있는 위험으로부터 환경을 보호하는 방법에 대한 자세한 내용은 당사의 상세 가이드에서 PostgreSQL 보안 모범 사례를 확인해 보시기 바랍니다. 또한 당사의 심층 가이드를 통해 PostgreSQL 취약점과 이로 인해 발생할 수 있는 보안 위험에 대해 자세히 알아보실 수 있습니다.

바로 이러한 공백을 메우기 위해 공급업체 지원 연장 서비스가 마련된 것입니다. 이에 대한 자세한 내용은 아래의 옵션 섹션에서 확인하실 수 있습니다.

규정 준수 및 감사 실패

PCI DSS 는 알려진 취약점에 대한 패치 적용과 적용 대상 내 수명 종료 기술의 추적을 명시적으로 요구합니다. HIPAA 및 SOC 2 는 EOL 소프트웨어를 명시적으로 언급하지는 않지만, 평가자들은 더 이상 보안 패치를 받을 수 없는 데이터베이스를 잠재적 문제점으로 간주합니다. 어느 쪽이든, “공급업체가 더 이상 패치를 제공하지 않는다”는 주장은 나머지 시스템이 아무리 철저히 보안이 강화되어 있더라도 방어하기 어려운 입장입니다.

감사관은 설문조사, 취약점 스캔, 자산 현황 조사를 통해 버전 지원 상태를 직접 확인합니다. 2024년 11월에 지원 종료(EOL)일이 지났는데도 “현재 업그레이드 작업 중입니다”라는 답변은 설득력이 없습니다. 감사 결과로 인해 거래 실패, 시정 조치 기한 준수, 규제 대상 분야의 경우 과태료 부과 등 실질적인 비용이 발생합니다.

생태계의 변화

보안 문제가 주목을 받지만, 더 서서히 진행되는 문제는 데이터베이스와 관련된 모든 요소가 버전 12에서 멀어져 가고 있다는 점입니다. 확장 기능 유지 관리자들은 해당 버전에 대한 테스트를 중단하고, 클라이언트 드라이버는 지원을 중단합니다. 관리형 제공업체들은 연장 지원 추가 요금을 부과하거나, 새로운 배포를 차단하거나, 강제 업그레이드를 실시하기도 합니다.

이것들 중 어느 하나만으로는 치명적인 문제는 아니지만, 문제가 쌓여갑니다. 결국 라이브러리 유지보수자가 PostgreSQL 14 이상의 동작 방식을 전제로 한 릴리스를 출시하거나, 모니터링 통합 솔루션에서 12.x 버전에 대한 지원을 중단하게 될 것입니다. 그 결과, 안전하게 수정할 수도 없고 쉽게 버릴 수도 없는 데이터베이스를 떠안게 됩니다.

PostgreSQL 12 지원 종료 이후의 대안

실질적으로 네 가지 선택지가 있습니다. 올바른 선택은 위험 감수 능력에 달려 있습니다. 지금 당장 업그레이드로 인한 혼란을 감당할 수 있는지, 아니면 안정적인 마이그레이션 경로를 마련하는 동안 패치를 적용한 상태로 규정 준수를 유지해야 하는지 고려해야 합니다.

1. 공급업체가 지원하는 연장 지원

즉시 마이그레이션할 수는 없지만, 패치가 적용되지 않은 소프트웨어를 계속 사용할 수도 없는 경우, 연장 지원이 그 가교 역할을 합니다. 일부 공급업체에서 이러한 서비스를 제공하고 있습니다. TuxCare의 ‘Endless Lifecycle Support’ 는 현재 PostgreSQL 13을 지원하며, 이 회사는 EOL(지원 종료)일 이전에 14 버전을 추가할 계획을 발표했습니다.

확장 지원의 목적은 영원히 업그레이드를 피하기 위한 것이 아닙니다. 이는 엄격한 마감 기한을 계획된 프로젝트로 전환하기 위함입니다. 기능 개발 작업 사이의 스프린트 기간에 급하게 진행해야 하는 긴급 마이그레이션 대신, 패치가 적용된 인스턴스를 확보함으로써 CVE나 감사 기관의 압박으로 어쩔 수 없이 마이그레이션을 진행해야 하는 상황이 아니라, 준비가 되었을 때 여유 있게 마이그레이션을 진행할 수 있게 됩니다.

이 옵션은 규제 대상 환경에 있는 팀, 고도로 맞춤화된 환경을 운영하는 팀, 또는 실제 마이그레이션 시기가 몇 달 뒤인 모든 사용자에게 적합합니다. 또한 실제 업그레이드가 진행 중인 동안 감사관에게 제시할 수 있는 문서화된 패치 적용 경로를 제공합니다.

2. PostgreSQL 18로 업그레이드

PostgreSQL 18은 현재 출시된 버전으로, 2030년 11월까지 지원됩니다. 바로 이 버전으로 전환하면 다음 번에 이 작업을 다시 수행하기 전까지 가장 긴 기간을 확보할 수 있을 뿐만 아니라, 최신 성능 및 기능 개선 사항도 활용할 수 있습니다.

대가는 바로 버전 간 거리입니다. 12에서 18로 넘어가려면 6개의 메이저 버전 단계를 건너뛰어야 하는데, 이는 플래너의 차이, 더 이상 사용되지 않는 설정, 전반적인 확장 기능 호환성 등 한 번에 확인해야 할 동작상의 변경 사항이 더 많아진다는 것을 의미합니다. 전체 덤프 및 복원 대신 pg_upgrade를 사용하되(새 버전의 바이너리를 기존 버전과 병렬로 설치한 상태에서), 충분한 스테이징 시간을 확보해야 합니다:

pg_upgrade \

  –old-datadir /var/lib/postgresql/12/main \

  –new-datadir /var/lib/postgresql/18/main \

  –old-bindir /usr/lib/postgresql/12/bin \

  –new-bindir /usr/lib/postgresql/18/bin \

  –확인

표시된 경로는 데비안/우분투의 기본값이므로, 사용 중인 배포판에 맞게 조정하십시오. 다음 명령어로 실행하십시오. –check 옵션을 먼저 실행해 보세요. 이 명령은 어떤 작업을 확정하기 전에 많은 차단 요인을 찾아내지만, 모든 애플리케이션 수준이나 성능 문제를 잡아내지는 못합니다.

3. PostgreSQL 17, 16 또는 15로 업그레이드하기 (여전히 지원됨)

18버전으로의 전환이 너무 큰 도약처럼 느껴진다면, PostgreSQL 17(지원 종료: 2029년 11월), 16(지원 종료: 2028년 11월), 15(지원 종료: 2027년 11월) 버전은 모두 여전히 커뮤니티에서 지원받고 있으며, 12버전의 동작 방식에 더 가깝습니다. 많은 팀이 의도적으로 중간 단계로 이 중 하나를 선택합니다. 지원 기간이 충분히 길어 실용적이며, 최신 릴리스보다 예기치 못한 문제가 적기 때문입니다.

하지만 일정을 염두에 두셔야 합니다. 2026년에 15를 선택하면 EOL(지원 종료) 계획을 다시 세워야 할 때까지 겨우 1년 반 정도밖에 남지 않습니다. 반면 17이나 16을 선택하면 중간 단계 전략을 실행할 실질적인 여유를 확보할 수 있습니다. 확장 기능이 최신 버전에 대해 아직 인증을 받지 못했거나, 운영 실적이 더 긴 릴리스를 선호하는 경우, 18 대신 이 중 하나를 선택하는 것이 합리적입니다.

전문가 팁: 다음 명령어를 실행하세요 SELECT * FROM pg_extension; 명령어를 실행한 후, 각 확장 기능을 대상 버전과 대조하여 확인하십시오. 프로젝트 도중 업그레이드가 중단되는 원인은 대개 PostgreSQL 핵심이 아니라 확장 기능 때문입니다.

4. 관리형 클라우드 확장 지원

Amazon RDS, Google Cloud SQL 또는 지원 대상인 Azure Database for PostgreSQL 배포 환경을 사용하는 경우, 해당 서비스 제공업체에서 특정 EOL(지원 종료) 버전에 대해 유료 확장 지원을 제공할 수 있습니다. 이용 가능 여부 및 등록 규칙은 서비스와 버전에 따라 다릅니다. Amazon RDS는 2025년 2월 28일에 표준 지원 기간이 종료된 PostgreSQL 12를 RDS 확장 지원 대상으로 전환했으며, vCPU당 추가 요금이 부과됩니다. Google Cloud SQL은 2025년 5월 1일부터 EOL 주요 버전에 대해 확장 지원 요금을 부과하기 시작했습니다. Azure는 이제 지원이 종료된 버전을 실행하는 서버를 자동으로 확장 지원에 등록하며 , 2026년 8월 1일부터 버전 13에 대한 요금이 청구됩니다.

이를 통해 자체적으로 PostgreSQL 백포트를 관리할 필요 없이 서비스 제공업체가 관리하는 보안 업데이트를 이용할 수 있어 정말 유용합니다. 다만 추가 요금은 시간이 지남에 따라 점차 증가합니다(AWS 요금은 처음 2년이 지나면 인상됩니다). 따라서 이를 장기적인 전략이 아닌, 일정 기간 동안만 허용되는 유예 기간으로 간주해야 합니다. 이 옵션이 저렴한 선택이라고 단정 짓기 전에 인스턴스별 요금제를 꼼꼼히 확인해 보시기 바랍니다.

다음은 해당 결정을 한눈에 볼 수 있는 내용입니다:

만약 여러분의 상황이…	최고의 수
당장 마이그레이션할 수는 없지만, 패치를 꾸준히 적용하고 규정 준수 상태를 유지해야 합니다.	공급업체가 지원하는 연장 지원 (예: TuxCare의 ‘Endless Lifecycle Support’)
마이그레이션할 준비가 되었으며, 가능한 한 오랫동안 지원을 받고 싶습니다.	PostgreSQL 18로 업그레이드
마이그레이션 준비가 되었으며, 예상치 못한 문제를 최소화하고 싶습니다	17 또는 16으로 업그레이드하세요
관리형 클라우드에서 단기적인 숨 고르기 시간 확보	공급업체의 연장 지원

시급해지기 전에 마이그레이션 계획 수립하기

EOL을 잘 관리하는 팀들은 이를 다른 예정된 프로젝트와 마찬가지로 취급합니다. 반면 어려움을 겪는 팀들은 EOL 날짜가 되어서야 비로소 이에 대해 고민하기 시작하는 경향이 있는데, 이는 대략 1년 정도 늦은 시점입니다.

실행 가능한 이주 계획에는 대개 다음 사항이 포함됩니다:

•   인벤토리. 잊혀진 복제본과 누구도 관리하지 않는 분석 서버를 포함한 모든 12.x 인스턴스.
•   의존성 감사. 확장 기능, 클라이언트 드라이버, ORM 및 복제 도구 등을 각각 대상 버전에 맞춰 점검합니다.
•   대상 버전 결정. 직감에 의존한 것이 아니라, 확장 기능 호환성과 향후 지원 기간을 고려하여 선정되었습니다.
•   검증된 업그레이드 경로. pg_upgrade 또는 가동 중단 시간을 거의 제로에 가깝게 줄여주는 논리적 복제를 통해, 실제 운영 환경에 적용하기 전에 스테이징 환경에서 미리 테스트해 볼 수 있습니다.
•   과도기적 해결책. 지금부터 마이그레이션 당일까지 보안을 유지하는 방법. 이는 대개 공급업체나 클라우드의 연장 지원을 의미하며, 문서화된 보완 통제 조치는 그보다 덜 확실한 대안입니다.
•   복구 계획. 예기치 못한 일이 발생할 수 있기 때문에, “어젯밤 백업에서 복원”이 아닌 다른 해결책을 마련해 두어야 합니다.

현실 점검: 벤더들은 대규모 업그레이드를 “번거롭지 않다”고 표현하는 것을 좋아합니다. 하지만 실제로는 그렇지 않습니다. pg_upgrade를 문제없이 실행하더라도 확장 기능을 다시 검증하고, 설정을 재조정하며, 쿼리 실행 계획의 변화를 지켜봐야 합니다. 상호 의존성이 복잡한 운영 환경의 경우, 단순한 유지보수 시간대뿐만 아니라 수 주간에 걸친 테스트 일정을 미리 계획해야 합니다.

PostgreSQL 12를 여전히 운영 환경에서 사용 중이라면 어떻게 해야 할까요?

PostgreSQL 12는 갑자기 작동이 중단되지는 않을 것입니다. 바로 그 때문에 CVE가 발견되거나 감사를 통해 시급한 문제가 되기 전까지는 이 문제를 쉽게 간과하기 쉽습니다. 솔직히 말해, 명확한 결정을 내려야 합니다. 이전이 가능하다면 지원되는 릴리스로 업그레이드하십시오. 만약 불가능하다면, 패치 적용 체계를 마련하여 “아직은 아니야”라는 태도가 “1년 동안 취약점에 노출된 상태”로 이어지지 않도록 해야 합니다.

확장 지원 측면에서는, TuxCare는 는 현재 버전 13에 대한 지원을 제공하고 있으므로, 업그레이드를 계획하는 동안 상용 패치 옵션이 필요한 경우 이를 활용할 수 있으며, 버전 14에 대한 지원도 EOL(지원 종료) 전에 발표될 예정입니다. 연장 지원을 과도기적 해결책으로 삼기 전에, 해당 공급업체에 정확한 지원 대상 버전을 반드시 확인하시기 바랍니다.

먼저 12.x 버전의 구성 현황을 파악해 보세요. 인스턴스 수가 몇 개인지, 어떤 확장 기능이 있는지, 그리고 어떤 요소들이 이에 의존하고 있는지 확인해야 합니다. 이러한 현황 파악만으로도 대개 어떤 방향이 타당한지 명확해집니다. 최악의 결과는 아예 선택을 하지 않는 경우입니다.

자주 묻는 질문