Fastify 지원 종료(EOL): 버전, 날짜, 위험 요소 및 대안 (2026)

주요 내용

• Fastify v3는 2023년 6월 30일을 기해 지원 종료되었으며, v4도 2025년 6월 30일에 지원이 종료되었습니다.
• 현재 Fastify 팀으로부터 수정 사항을 계속 받고 있는 것은 v5 계열뿐이며, v6은 이미 알파 단계에 접어들었습니다.
• Fastify v5는 Node.js 20 이상이 필요하며, Node 20은 2026년 4월에 지원 종료(EOL)될 예정입니다. 따라서 프레임워크를 업그레이드하면 런타임도 함께 업그레이드해야 합니다.
• TuxCare의 무제한 라이프사이클 지원 이 서비스는 Fastify 3.29.5 및 4.29.1 버전을 지원하며, 귀사가 마이그레이션을 계획하는 동안 지속적인 CVE 패치를 제공합니다.

대규모 Node.js 환경 전반에 걸쳐 현황 조사를 수행해 보면, 대개 2023년 6월에 LTS 지원이 종료된 Fastify v3을 여전히 사용 중인 서비스를 발견하게 됩니다. 이는 현재 프로덕션 환경에 그대로 남아 있는 코드에 대해 3년 넘게 프레임워크 차원의 보안 패치가 제공되지 않았음을 의미합니다.

Fastify v4 역시 2025년 6월 30일에 LTS 지원 기간이 종료되었으므로 더 이상 지원되지 않습니다. 따라서 2024년 9월에 출시된 v5만이 핵심 팀이 여전히 버그 수정을 진행하는 유일한 버전입니다. 이 버전으로 전환한다는 것은 여전히 지원되는 Node.js 릴리스로 전환하는 것을 의미하기도 합니다. Node 20은 이제 EOL(지원 종료) 상태이며, Node 22는 이미 유지보수 단계로 넘어갔기 때문입니다.

아래에서는 Fastify EOL이 실제로 무엇을 의미하는지, 각 라인별로 어떤 위험이 실제적이고 어떤 위험이 이론적인지, 마이그레이션 티켓이 계속 다음 분기로 미뤄질 때 v3 플릿의 모습은 어떤지, 그리고 현실적으로 고려할 수 있는 세 가지 선택지는 무엇인지 알아보실 수 있습니다.

Fastify란 무엇인가요?

Fastify는 요청당 오버헤드를 최소화하기 위해 설계된 Node.js 웹 프레임워크로, 플러그인 아키텍처를 통해 각 요소를 캡슐화하여 한 경로의 데코레이터가 다른 경로로 유출되지 않도록 합니다. 이 프레임워크는 JSON 스키마를 통해 유효성 검사와 직렬화를 수행하며, pino를 통해 로깅을 수행합니다. v5가 출시되었을 때, OpenJS 재단은 월간 다운로드 수를 780만 건로 집계했으며, 생태계 내에는 296개의 공식 인증 플러그인이 존재했습니다. npm-stat에 따르면 2026년 7월 기준, 이 수치는 월간 다운로드 수 4,300만 건을 넘어섰습니다.

 

여러분이 이미 사용해 보셨을 법한 프레임워크들과 비교해 보면, Express 는 더 오래되었고 훨씬 규모가 큰 프레임워크로, 내장된 유효성 검사 기능이 거의 없음에도 불구하고 Fastify의 월간 npm 다운로드 수의 약 12배를 기록하며, 팀들이 가장 흔히 이전해 오는 프레임워크이기도 합니다. Hapi는 더 많은 설정을 요구하지만, 기본적으로 더 많은 기능을 제공합니다. Koa는 간결한 미들웨어 코어이며, 그 외 거의 모든 요소는 사용자가 별도로 결정해야 합니다. NestJS는 Express나 Fastify 어댑터 위에서 실행되는 애플리케이션 프레임워크이므로, 엄밀히 말해 경쟁 상대라고 할 수는 없습니다.

서비스가 Fastify 어댑터를 실행하는 NestJS 앱이라면, 팀의 자산 목록에서 이를 Fastify 앱이라고 부르든 그렇지 않든 상관없이 Fastify는 의존성 트리에 포함되어 있습니다. 다음의 경우도 마찬가지입니다. 그 밑에 있는 도 마찬가지입니다. 이 버전은 이미 조용히 지원이 종료되었지만, 두 팀과 한 번의 조직 개편 전 누군가가 선택한 프레임워크에 의해 여전히 고정되어 있습니다.

전문가 팁: 다음 명령어를 실행하세요 npm ls fastify –all 를 실행하세요. Fastify를 사용한다고 생각되는 리포지토리뿐만 아니라 모든 서비스 리포지토리에서 실행해야 합니다. 어댑터, 제너레이터 및 내부 SDK는 Fastify를 전달 의존성로 Fastify를 끌어오는데, 이러한 복사본의 소유자가 명확하지 않은 경우가 많습니다. 대개 이런 식으로 v3 버전이 의도치 않게 설치되는 경우가 발생합니다.

Fastify는 지원 종료 단계에 접어들었나요?

Fastify v1, v2, v3, v4는 모두 LTS 지원 종료일을 지났습니다. 현재 코어 팀으로부터 적극적인 수정 지원을 받고 있는 버전은 v5뿐이며, 공식 일정표에 기재된 v5의 상태는 여전히 ‘미정(TBD)’으로 되어 있습니다. 하지만 이 상태가 영원히 지속되지는 않을 것입니다. Fastify 6.0.0-alpha.1은 2026년 8월에 출시되었으며, 동일한 정책에 따라 v6이 출시되면 v5는 6개월 동안 보안 업데이트만 제공받게 됩니다.

겉으로 보기에는 임의적으로 정해진 것처럼 보일지 몰라도, 일정은 결코 임의적으로 정해진 것이 아닙니다. Fastify의 LTS 정책에 따르면 각 메이저 릴리스에 대해 최소 6개월간의 적극적인 지원을 제공하며, 다음 메이저 릴리스가 출시된 후에는 추가로 6개월간 보안 업데이트만 제공합니다. 이러한 계산에 따라 v4의 LTS 종료일은 2025년 6월 30일로 정해졌습니다.

해당 기간이 종료된 후에도, 정책에 따르면 유지보수 담당자들은 계속해서 보안 수정 사항을 검토하고 배포할 예정이지만, 이는 커뮤니티에서 수정 사항을 제공해 줄 때에만 가능하며, 최소 지원 Node.js 버전과 같은 다른 제약 사항에 부딪히지 않을 때에만 해당됩니다. 이는 유지보수가 이루어지는 정식 릴리스 라인이라기보다는 조건부이며 커뮤니티 주도의 지원에 가깝습니다. 현재 v4에서 심각한 버그가 발견된다면, 커뮤니티에서 패치를 제공하거나, 업그레이드를 권고하는 정중한 안내가 게시되거나, 아니면 단순히 GitHub 이슈로 남아 있을 수도 있습니다.

이 세 가지 결과 중 어떤 것이 나타날지 예측하며 프로덕션 API를 사용하는 것이 바로 팀들이 큰 타격을 입는 지점입니다. 이것이 바로 확장 보안 지원이 애초에 존재하는 이유이기도 합니다.

Fastify 버전 수명 주기 및 주요 EOL 날짜

이 날짜들은 Fastify가 공개한 LTS 일정에 기반한 것입니다. Node.js 열에는 각 메이저 버전에 대해 해당 일정에 나열된 릴리스 라인이 그대로 반영되어 있으므로, LTS 라인과 함께 9나 11과 같이 수명이 짧은 ‘Current’ 릴리스도 포함되어 있습니다.

Fastify 버전	출시일	LTS 종료	현재 현황	나열된 Node.js 코드 줄
1.0.0	3월 6, 2018	9월 1, 2019	EOL	6, 8, 9, 10, 11
2.0.0	2월 25, 2019	1월 31, 2021	EOL	6, 8, 10, 12, 14
3.0.0	7월 7, 2020	6월 30, 2023	EOL	10, 12, 14, 16, 18
4.0.0	6월 8, 2022	6월 30, 2025	EOL	14, 16, 18, 20, 22
5.0.0	9월 17, 2024	미발표	활성	20, 22

v5 행에 대해 한 가지 주의할 점이 있습니다. 이 행은 v5 출시 당시 테스트된 내용을 기록한 것이며, 현재 Fastify의 main 브랜치 CI는 Node 24 및 26을 대상으로 단위 테스트를 실행하고 있습니다. 해당 행에 Node 20도 표시되어 있지만, 이 버전은 2026년 4월 30일에 지원 종료(EOL)되었으므로, 실제 배포에 사용할 런타임이 아니라 호환성 하한선으로 간주하시기 바랍니다.

이제 오늘 날짜 옆의 v3 행을 살펴보세요. LTS 종료 시점에서 3년이 지났고, Node.js 버전 범위(10부터 18까지) 자체가 완전히 지원 종료(EOL) 상태이며, v4도 더 이상 지원되지 않기 때문에 중간 단계로 넘어갈 수 있는 선택지가 남아 있지 않습니다. 그렇기 때문에 v3 환경을 운영하는 경우, “그냥 업그레이드하라”는 말이 v4 환경을 운영하는 경우보다 훨씬 더 큰 부담이 되는 것입니다.

프로덕션 환경에서 지원 종료(EOL)된 Fastify를 실행할 때의 보안 위험

위험은 특정 CVE가 여러분의 node_modules 에 특정 CVE가 현재 존재한다는 데 있는 것이 아닙니다. 문제는 해당 버전이 EOL(지원 종료)이 되는 날부터 시작되어 그 이후 매년 누적되는 불균형에 있습니다. Fastify에 대한 보안 연구는 계속해서 전속력으로 진행되고 있으며, 이를 통해 생성된 수정 사항은 지원되는 v5 계열을 위해 개발됩니다. v4 환경의 경우 이미 1년 이상의 보안 공백이 누적된 상태입니다. v3 환경의 경우 3년이나 됩니다.

프레임워크 CVE가 귀하의 버전에 더 이상 적용되지 않습니다

콘텐츠 유형 유효성 검사 계열은 이것이 실제로 어떤 대가를 치르게 되는지를 명확하게 보여주는 사례입니다. 2025년 4월, CVE-2025-32442 는 콘텐츠 유형별 유효성 검사를 정의한 애플리케이션에서, Content-Type 헤더를 약간만 변경하여 전송하는 것만으로 해당 검사가 완전히 우회될 수 있는 결함을 기록했습니다. 이 보안 권고문에는 Fastify 5.0.0부터 5.3.1까지 및 4.29.0 버전이 영향을 받는 것으로 명시되어 있으며, 5.3.2 및 4.29.1 버전에서 수정되었습니다. v4는 여전히 지원 기간 내에 있었기 때문에 패치된 버전이 출시되었으며, v3는 영향을 받는 버전으로 한 번도 언급된 적이 없습니다. 1년 후, 동일한 계열의 취약점으로 인해 CVE-2026-33806이라는 고중요도 취약점을 유발했는데, 이는 헤더의 선행 공백이라는 그다지 특이하지 않은 방법을 이용해 해당 수정 사항을 우회하는 것으로, 5.8.5 버전에서만 패치되었습니다.

OpenJS OpenJS 재단의 2026년 1분기 보안 업데이트 에 따르면, 해당 분기 CNA 운영을 통해 공개된 생태계 CVE는 총 18건이며, 그중 3건은 Fastify 생태계에서 발생했습니다. 이 중 2건은 Fastify 자체에서 발견되었습니다. CVE-2026-3419 는 5.7.2부터 5.8.0까지의 버전에 영향을 미치는 잘못된 형식의 Content-Type 유효성 검사 문제였으며, 5.8.1에서 수정되었습니다. 따라서 이는 백포트 누락이 아닌 v5 전용 회귀 오류에 해당합니다. CVE-2026-3635 는 특히 주목할 만한 취약점입니다: trustProxy 헤더 스푸핑 결함으로, 관련 권고문은 5.8.2까지의 모든 Fastify 릴리스를 포함하지만, 수정 사항은 5.8.3에서야 제공되었습니다. 모든 v3 및 v4 설치 환경이 해당 취약점 범위에 속하지만, 이들 중 어느 것도 패치된 릴리스를 받지 못했습니다.

세 번째, CVE-2026-2880는 선택적 모듈인 @fastify/middie 플러그인에서 발견된 고위험 권한 우회 취약점으로, 플러그인이 라우터와 다르게 요청 경로를 정규화하여 경로 범위 미들웨어가 건너뛸 수 있었습니다. 이 취약점에 대한 수정 사항은 middie 9.2.0에 포함되어 있으며, 9.x 계열은 Fastify v5를 기반으로 개발되고 있습니다. v4 애플리케이션이 실행되는 8.x 계열은 2024년 9월 8.3.3 버전에서 개발이 중단되어 이 수정 사항을 적용받지 못했습니다.

이 모든 흐름은 여전히 거세게 이어지고 있습니다. OpenJS는 2026년 2분기 업데이트 에서 자사의 CNA가 2025년 하반기에 3건, 2026년 상반기에 49건의 CVE를 공개했으며, 약 10건이 더 공개를 기다리고 있다고 밝혔다. 이러한 급증의 대부분은 새로운 버그가 갑자기 쏟아진 것이 아니라, 더 철저한 분류 작업과 AI 지원 스캔 때문이지만, EOL(지원 종료) 제품 라인에 미치는 영향은 어느 쪽이든 마찬가지다. 공개 건수가 늘어나고 있지만, 그중 어느 것도 여러분의 버전에는 해당되지 않는다.

내부에 있는 런타임은 자체 시계를 가지고 있다

Fastify v3는 Node.js 10부터 18까지에 대해 검증되었으며, 이 버전들은 현재 모두 지원 종료(EOL) 상태입니다. 팀들은 업그레이드에 드는 비용이 많이 들기 때문에 구버전 Fastify를 계속 사용하고 있으며, 구버전을 고수하게 만드는 바로 그 예산 압박 때문에 대개 구버전 Node.js도 계속 사용하게 됩니다. v3 서비스의 경우, 이미 수년 전에 지원이 종료된 두 가지 버전을 동시에 사용하는 경우가 흔하며, 런타임은 TLS 및 HTTP 파싱부터 네트워킹, 애플리케이션 코드 아래에 위치한 모든 요소에 이르기까지 더 광범위한 공격 표면을 노출시키는 주체입니다.

이것이 바로 팀이 진전을 이루지 못하는 진짜 이유이며, 프레임워크 탓인 경우는 거의 없습니다. 아무도 “웹 프레임워크 업그레이드”를 런타임 마이그레이션과 베이스 이미지 변경, 네이티브 모듈 재빌드를 모두 포함하는 작업으로 범위를 설정하지 않습니다. 그러다 누군가가 그렇게 설정하면, 예상 소요 시간이 세 배로 늘어나고, 해당 티켓은 다음 분기로 미뤄지게 됩니다.

의존성 제약 조건이 발목을 잡는 경우

Fastify 자체의 소스 트리는 정말로 간결하며, 이 점에 대해 솔직히 인정할 필요가 있습니다. Fastify 5.12.0 기준, v5를 설치하면 15개의 직접적인 런타임 종속성이 함께 설치됩니다: avvio, find-my-way, fast-json-stringify, light-my-request, pino, secure-json-parse, semver, rfdc, toad-cache, process-warning, abstract-logging, 그리고 네 개의 @fastify/* 패키지입니다. 웹 프레임워크로서는 정말로 적은 직접 의존성 세트입니다.

EOL에 도달한다고 해서 해당 트리가 저절로 고정되는 것은 아니며, 실제로 어떤 일이 일어나는지 정확히 파악해 둘 필요가 있습니다. Fastify는 semver 범위를 선언하며, npm은 해당 범위를 여전히 충족하는 최신 버전으로 의존성을 업데이트하므로, Fastify를 직접 수정하지 않아도 상류에서 많은 보안 수정 사항이 반영됩니다. 문제는 소스 트리가 고정되는 것보다 더 국소적이면서도 더 성가신 데 있습니다. 수정된 릴리스 중 유일하게 사용 가능한 버전이 Fastify가 허용하는 범위 밖에 있을 경우, 이를 적용하려면 오버라이드, 직접적인 의존성 변경, 또는 해당 버전에 대해 테스트된 적이 없는 프레임워크 업그레이드를 수행해야 합니다.

스캐너가 전이성 권고 사항을 표시했는데, 이를 해결하는 깔끔한 방법이 “Fastify 업그레이드”로 밝혀졌는데, 이는 바로 여러분이 피하려고 했던 바로 그 조치입니다. v3 앱의 경우, 이는 대개 패치 릴리스가 아닌 Node.js 업그레이드와 스키마 및 API 변경을 의미합니다. 바로 이러한 격차 때문에, 원래는 깔끔하게 끝날 수 있었던 감사 작업이 ‘용인 가능한 위험’과 ‘오탐’을 두고 보안 팀과 한 분기 내내 논쟁을 벌이는 상황으로 번지게 됩니다.

Fastify 지원 종료 후의 선택지

세 가지 옵션이 있는데, 어떤 것이 옳은지는 엔지니어링적 취향보다는 실제로 어떤 버전을 실행 중인지, 그리고 이번 분기에 팀이 얼마나 많은 시간을 할애할 수 있는지에 더 달려 있습니다.

만약 이 내용이 여러분에게 해당된다면	이렇게 해보세요
규제 대상 환경에서 v3 또는 v4를 운영 중이며, 이번 분기에는 런타임 및 프레임워크 마이그레이션을 진행할 여력이 없습니다.	현재 버전에 대한 지원 기간을 연장한 후, 본인의 일정에 맞춰 마이그레이션하세요
이미 지원되는 Node.js 릴리스를 사용 중이며, 사용 중단된 API가 거의 없고, 플러그인이 꾸준히 유지보수되고 있습니다.	지금 v5로 업그레이드하세요
EOL 문제를 제외하더라도 이 프레임워크는 적합하지 않습니다.	그것을 교체하고 예산을 적절히 책정하세요

 TuxCare의 무제한 라이프사이클 지원

TuxCare의 Endless Lifecycle Support(ELS) 는 지원 종료(EOL)된 오픈소스 런타임, 라이브러리 및 프레임워크를 지원합니다. 이 서비스는 업스트림 프로젝트에서 더 이상 유지보수하지 않는 버전에 대해 백포트된 보안 패치를 표준 패키지 관리 시스템을 통해 제공하므로, 배포 파이프라인에 대한 변경 사항을 최소화할 수 있습니다. 특히 Fastify의 경우, 지원 대상 버전은 v3 및 v4 계열의 마지막 릴리스인 3.29.5와 4.29.1입니다. 수정 사항은 npm을 통해 제공되며, TuxCare의 CVE 트래커에서 공개적으로 추적되므로, 보안 팀은 승인을 진행하기 전에 정확히 어떤 내용이 지원되는지 확인할 수 있습니다.

LTS(장기 지원) 기간이 1년 지난 v4 환경이든, 3년 지난 v3 환경이든, EOL(지원 종료) 단계에 접어든 Fastify 라인에 묶여 있는 팀의 경우, v5로 강제 전환하여 여러 버전의 Node.js 업그레이드를 동반하는 대신, 이미 운영 중인 버전에 대한 지속적인 보안 패치를 확보할 수 있습니다. 또한 SOC 2 또는 PCI DSS 심사에 제출할 수 있는 패치 문서를 확보할 수 있을 뿐만 아니라, 공개 일정이나 감사인의 지적 사항에 의해 강요된 마이그레이션 일정이 아닌, 스스로 정한 일정에 따라 마이그레이션을 진행할 수 있습니다.

이 상황에 처한 팀들은 결코 게으른 것이 아닙니다. 이들은 플랫폼 호환성의 한계, 이미 할당된 엔지니어링 리소스, 수십 개에 달하는 서비스 전반에 걸친 테스트의 복잡성, 또는 계획되지 않은 프레임워크 업그레이드를 기술적 문제가 아닌 변경 관리 문제로 만들어 버리는 규제 규정 등 실질적인 제약 조건에 직면해 있습니다. v3 시대의 서비스에 있어, 이는 단순한 버전 업보다는 사실상 완전한 플랫폼 재구축에 더 가까운 경우가 많습니다.

이 과정에서 TuxCare의 역할은 가교 역할을 수행하여, 업스트림의 일정이 아닌 귀사의 일정에 따라 마이그레이션이 진행되는 동안 지원 대상인 Fastify 버전에 대한 패치를 지속적으로 제공하는 것입니다.

Fastify v5로 업그레이드하기

경제적 여유가 있다면 이는 올바른 선택이며, v4 버전의 경우 대부분의 주요 버전 업그레이드보다 변경 폭이 작습니다. Fastify의 자체 마이그레이션 가이드 는 정말 간결합니다. v3 플릿의 경우, 플랫폼 전환에 가까운 예산을 책정해야 합니다. 두 번의 메이저 버전 분량에 해당하는 사용 중단된 API를 처리해야 할 뿐만 아니라, 서비스가 현재 사용 중인 EOL(지원 종료) Node 라인에서 현재 지원되는 버전으로 런타임 환경을 업그레이드해야 하기 때문입니다.

이 추정치를 결정하는 요인은 네 가지입니다. 첫 번째는 런타임입니다. v5는 Node.js 20 이상을 요구하며, 이 부분은 타협의 여지가 없기 때문입니다. Node 20 자체는 2026년 4월을 기점으로 지원 종료(EOL)될 예정이므로, 새로운 마이그레이션은 현재 지원 중인 LTS 릴리스로 진행되어야 합니다. 즉, 2026년 말 시점에서는 20에서 멈추는 대신 Node 24를 채택해야 합니다.

두 번째는 완전한 JSON 스키마입니다. jsonShorthand 옵션은 사라졌으며, 기본 유효성 검사기를 사용할 때 쿼리 문자열, params, body, response 스키마는 모두 type 속성을 포함한 완전한 스키마 객체여야 합니다.

세 번째는 제거된 API입니다. Fastify v5에서는 v4 라이프사이클 전반에 걸쳐 사용 중단이 선언된 API들이 제거되었으므로, 로그에서 계속 넘겨보던 사용 중단 경고들이 작업 목록을 작성하는 데 좋은 출발점이 될 것입니다. v3에서 업그레이드하는 경우, 처리해야 할 사용 중단 주기가 한 번이 아니라 두 번이라는 뜻입니다.

네 번째는 플러그인 호환성입니다. 모든 @fastify/* 및 커뮤니티 플러그인은 모두 v5와 호환되는 릴리스가 필요하며, 대개 이 부분에서 일정이 실제로 지연됩니다. 특히 2022년 이후로 아무도 손대지 않은 오래된 플러그인 세트의 경우 일정이 가장 크게 지연됩니다.

사용 중인 플러그인 세트가 모두 자체 개발된 것이며 활발히 유지보수되고 있고, v4에서 업그레이드하는 경우라면 작업 범위는 비교적 제한적일 수 있습니다. 반면 v3에서 업그레이드하는 경우이거나, 수년 전부터 활동이 뜸해진 커뮤니티 플러그인을 사용하고 있다면, 먼저 대체 작업의 범위를 파악해야 합니다. 바로 이 부분이 제한적인 업그레이드를 훨씬 더 큰 규모의 마이그레이션 프로젝트로 바꿔버릴 수 있는 요소입니다.

Fastify 대체하기

EOL(지원 종료) 문제를 해결하기 위해 프레임워크를 교체하는 것은 거의 항상 업그레이드하는 것보다 비용이 더 많이 듭니다. 특히 v3의 경우, 어느 쪽을 선택하더라도 이미 대규모 재작성이 불가피하기 때문에 비용은 두 배로 늘어납니다. Express 5, Hapi, Hono는 모두 합리적인 프레임워크이지만, 이들 중 어느 것으로 전환하더라도 라우트 등록, 훅 및 미들웨어, 유효성 검사, 플러그인, 그리고 프레임워크별 애플리케이션 코드에 걸쳐 상당한 재작업이 필요할 수 있습니다. 이는 업그레이드라는 탈을 쓴 재작성이나 다름없습니다. Fastify가 정말로 여러분의 환경에 맞지 않는 경우에만 전환을 고려해야 하며, 단순히 버전이 EOL이 되었다는 이유만으로 전환해서는 안 됩니다.

TuxCare를 통해 EOL 이후에도 Fastify의 보안을 유지하세요

Fastify v3는 2023년 6월에 LTS 기간이 종료되었으며, v4도 2025년 6월에 LTS 기간이 종료되었습니다. 이 두 날짜 중 어느 것도 그 자체로 위험 요소가 되지는 않았습니다. 진정한 위험은 귀사의 차량 군에 적용되는 날짜부터 지원되는 플랫폼에서 마지막 EOL 서비스가 출시되는 날까지 이어지는 공백 기간이며, 많은 팀의 경우 이 공백 기간은 기껏해야 분기 단위, 최악의 경우 연 단위로 측정됩니다.

두 가지 방법 중 하나로 해결하세요. 지금 바로 v5로 전환하고 그에 수반되는 런타임 업그레이드 비용을 감수하거나, 3.29.5와 4.29.1을 포함해 현재 실행 중인 버전에 계속 패치를 적용하면서, 스스로 통제할 수 있는 일정에 따라 마이그레이션을 진행하는 것입니다. 두 가지 모두 타당한 입장입니다. 하지만 지원 종료(EOL)된 버전을 계속 사용하면서 운에 맡기는 것은 타당하지 않습니다.

만약 여러분이 후자에 속한다면, TuxCare의 ‘Endless Lifecycle Support’는 는 Fastify 3.29.5 및 4.29.1을 포함한 EOL(제품 수명 주기 종료) 프레임워크와 런타임을, 비즈니스에서 필요로 하는 한 계속해서 패치 적용 및 감사 준비를 완료한 상태로 지원해 드립니다.

자주 묻는 질문