Express.js 지원 종료: 연장된 지원으로 보안을 유지하세요

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

의존성은 취약점의 범위를 확대합니다. Express.js는 약 30개의 직접적인 의존성을 포함하고 있으며, 각 의존성마다 자체적인 전이적 의존성 체인이 존재합니다. 즉, Express.js의 지원 종료(EOL)로 인한 취약점은 프레임워크 자체보다 훨씬 더 광범위하게 영향을 미칩니다.
공황 상태에 휩싸여 서둘러 진행한 마이그레이션은 미들웨어 체인의 단절, 라우팅 문제, 시스템 불안정, 그리고 연장 지원 비용을 훨씬 초과하는 예산 초과로 이어집니다.
확장 지원 옵션을 이용하면, 일정이 아닌 자체 계획에 따라 업그레이드를 진행하는 동안에도 Express.js 단종(EOL) 버전에 대한 지속적인 보안 지원을 받을 수 있습니다.

프로덕션 환경에서 Express.js를 운영 중이라면—통계적으로 볼 때 그럴 가능성이 매우 높습니다—아마도 그런 순간을 한 번쯤 겪어보셨을 겁니다. 의존성 점검을 하던 중일 수도 있고, GitHub 이슈 스레드 깊숙이 묻혀 있던 댓글일 수도 있으며, 혹은 “주의하세요…”로 시작하는 제목의 기사를 동료가 보내온 경우일 수도 있습니다.

Express.js는 인터넷 백엔드 인프라의 막대한 부분을 담당하고 있습니다. 이 프레임워크는 한 세대의 개발자들에게 REST API 구축 방법을 가르쳐 주었으며, 지금도 규모를 불문하고 수많은 기업에서 중요한 서비스를 조용히 뒷받침하고 있습니다. 보안 보고서에서 Express.js의 지원 종료 경고가 나타나기 시작하면, 마치 발밑의 땅이 흔들리는 듯한 불안감을 느끼기 쉽습니다.

사실 중요한 점은, 반드시 위기가 닥쳐야만 하는 것은 아니라는 것입니다. 생각보다 더 많은 선택지가 있습니다. Express.js의 지원 종료가 실제 운영 환경에 어떤 영향을 미치는지, 그리고 무엇보다도 엔지니어링 로드맵을 무너뜨리지 않으면서 현실적으로 어떤 조치를 취할 수 있는지 함께 살펴보겠습니다.

Express.js 릴리스의 실제 작동 방식

“자, 그럼 실제로 무엇을 해야 할까”라는 부분으로 넘어가기 전에, Express.js가 버전 관리 주기를 어떻게 처리하는지 이해해 두면 도움이 됩니다. 왜냐하면, 일정이 엄격하고 예측 가능한 일부 프로젝트와 달리, Express는 역사적으로 이 부분에 대해 다소… 유연한 편이었기 때문입니다.

Express는 소위 ‘메이저 버전 지원 모델’을 따릅니다. 기본 원칙은 간단합니다. 새로운 메이저 버전이 출시되면, 이전 메이저 버전은 ‘지원은 되지만 기능이 완전히 제공되지 않는’ 상태로 전환되며, 최종적으로 사용 중단될 때까지 보안 업데이트와 중대한 버그 수정만 제공받게 됩니다.

각 Express 버전에 따라 다음과 같이 적용됩니다:

Express v3.x v4로 대체된 후 2015년 7월에 지원이 종료되었습니다. 그 이후로 업데이트가 제공되지 않고 있습니다.
Express v4.x 2014년 4월에 출시되었으며, 현재까지도 공식적으로 지원되고 있어 자바스크립트 생태계에서 가장 오랫동안 유지되고 있는 주요 버전 중 하나입니다.
Express v5.x 2024년 10월에 공식 출시되었으며, Node.js v18 미만의 버전에 대한 지원을 중단하고 라우팅, Promise 처리 및 더 이상 사용되지 않는 API에 대한 중대한 변경 사항을 적용했습니다.

여기서 문제는 라이프사이클 정책 자체가 아니라, Express가 수년 동안 개발 속도가 더뎠다는 점입니다. 버전 5는 공식 출시되기까지 10년 넘게 개발되었습니다. 이처럼 긴 개발 기간 탓에 많은 팀이 v4를 기반으로 시스템을 깊이 있게 구축해 왔으며, 이제 최신 버전을 따라잡기 위해 상당한 노력을 요하는 마이그레이션을 진행해야 하는 상황에 처해 있습니다.

혹시 더 오래된 버전을 사용하고 계신가요? Express.js의 지원 종료는 이미 미래의 문제가 아니라 현재 진행 중인 문제입니다.

Express.js의 지원 종료가 실제 운영 환경의 API에 미치는 영향

좋아요, 어떤 버전이 지원 종료(EOL)되었습니다. API는 여전히 정상적으로 작동하고 있습니다. 엔드포인트도 응답하고 있고요. 모든 게 괜찮아 보입니다. 그렇다면 도대체 문제가 뭘까요?

Express.js의 지원 종료와 관련해 직시하기 불편한 진실은 이렇습니다. 지원이 중단된다고 해서 취약점이 더 이상 발견되지 않는 것은 아닙니다. 공격자들은 익스플로잇을 찾기 전에 지원 종료 일정을 확인하지 않습니다. 또한 연구 커뮤니티는 널리 배포된 지원 종료 소프트웨어에서 계속해서 문제를 발견하고 있는데, 바로 그곳이 가장 매력적인 표적이기 때문입니다.

Express에는 이 문제가 왜 중요한지 명확히 보여주는, 잘 기록된 CVE 이력이 있습니다. 다음은 최근 큰 주목을 받은 사례들입니다:

CVE-2024-29041 (CVSS 6.1): 4.19.0 이전 버전의 Express 4.x에 영향을 미치는 오픈 리디렉션 취약점입니다. 공격자는 res.location() 및 res.redirect() 메서드를 우회하여 사용자를 임의의 외부 사이트로 리디렉션할 수 있습니다. 이 취약점으로 인해 IBM은 IBM Watson Assistant 및 IBM MQ Appliance를 포함한 여러 엔터프라이즈 제품에 대한 보안 공지를 발표했습니다.
CVE-2024-45296 (CVSS 7.5, 고위험): Express에서 사용하는 핵심 라우팅 의존성인 path-to-regexp의 정규 표현식 서비스 거부(ReDoS) 취약점. 악의적인 공격자는 경로 일치 정규 표현식의 역추적(backtracking)을 악용하여 Node.js의 이벤트 루프를 완전히 차단하고 서버를 다운시킬 수 있습니다. 이 공격은 인증이나 사용자 상호작용이 필요하지 않으며, 단 하나의 조작된 HTTP 요청만으로도 충분합니다. 이 취약점은 취약한 버전의 path-to-regexp를 사용하는 모든 Express 4.x 설치 환경에 영향을 미쳤으며, IBM Safer Payments를 포함한 여러 IBM 엔터프라이즈 제품에 대한 보안 공지를 유발했습니다.

하지만 여기서 중요한 점은, 지원 종료된 Express.js 버전에서는 이러한 취약점에 대한 패치가 제공되지 않는다는 것입니다. Express 팀은 v3.x 버전의 문제에 대해 수정 패치를 제공하지 않을 것입니다. 단호히 말입니다. 여전히 v3을 사용 중인 팀들(그 수가 적지 않습니다)에게 있어, 새로 발견되는 모든 취약점은 마이그레이션을 완료할 때까지 영구적인 보안 위협으로 남게 됩니다.

v4를 사용하는 팀들의 경우, 현재 상황은 다르지만(v4는 여전히 업데이트를 받고 있음), 향후 흐름은 분명합니다. Express v5가 이미 출시되었으며, v4도 결국 v3와 마찬가지로 지원 종료 단계로 접어들게 될 것입니다. “잘 작동하니까 건드리지 말자”는 식의 안일한 태도는 결국 나중에 긴급 마이그레이션을 초래하는 원인이 됩니다.

당면한 보안 위험을 넘어, 규정 준수 프레임워크들은 지원 종료된 소프트웨어에 대해 점점 더 명확한 기준을 제시하고 있습니다. PCI DSS는 중대한 취약점에 대한 패치를 30일 이내에 적용할 것을 요구합니다. SOC 2 감사관들은 운영 환경에서 지원이 중단된 소프트웨어에 대해 구체적인 질문을 던집니다. 지원이 종료된 Express.js 버전을 계속 사용하는 것은 더 이상 단순한 기술적 위험에 그치지 않습니다. 이는 문서상 기록과 관련된 문제이기도 합니다.

숨겨진 위험: 전체 의존성 체인

대부분의 팀이 Express.js의 보안을 생각할 때, Express 자체를 떠올립니다. 라우트, 미들웨어, req/res 처리 등이죠. 이것이 바로 가장 눈에 띄는 계층입니다.

하지만 Express는 단독으로 작동하지 않습니다. Express는 body-parser, cookie-parser, serve-static, send, path-to-regexp, qs 등과 같이 내부적으로 핵심 기능을 처리하는 일련의 직접 의존성 패키지들을 불러옵니다. 이러한 패키지들은 각각 고유한 의존성 구조를 가지고 있으며, 각 의존성은 잠재적인 취약점의 원인이 될 수 있습니다.

일반적인 Express 4.x 설치 환경에는 약 30개의 직접 의존성이 포함되며, 전체 현황을 확인하기 위해 `npm list` 명령어를 실행하면 패키지 총 수는 훨씬 더 많아집니다. 취약점이 공개될 때마다 이러한 패키지 하나하나에 패치를 적용해야 하지만, 지원이 종료된 Express.js 버전의 경우 상당수 패키지에 패치가 제공되지 않을 것입니다.

CVE 기록을 살펴보면 이 점이 명확해집니다. CVE-2024-43799는 send 패키지(Express의 종속성)에 영향을 미쳤고, CVE-2024-43800은 serve-static에 영향을 미쳤으며, 두 취약점 모두 2024년 9월 보안 업데이트를 통해 공개되었습니다. 이는 단순히 하나의 패키지에 존재하는 단일 취약점을 다루는 문제가 아니었습니다. 종속성 트리 전반에 걸쳐 관련된 여러 취약점이 동시에 발생했던 것입니다.

이 때문에 Express.js의 지원 종료가 정말로 복잡한 문제가 됩니다. 애플리케이션 코드를 철저히 관리하고 있다 하더라도, 지원이 종료된 패키지의 경우 권장할 만한 패치가 없기 때문에 npm audit으로도 파악할 수 없는 방식으로 의존성 체인이 악용될 여지가 여전히 존재합니다.

Express.js의 지원 종료 시 선택할 수 있는 대안

좋아요, Express.js 버전이 이미 지원 종료(EOL)되었거나 곧 그렇게 될 예정이군요. 현실적으로 어떤 대안이 있을까요?

이 중 두 가지는 상당한 복잡성과 비용, 위험을 수반합니다. 세 번째 옵션인 ‘지원 기간 연장’은 업무에 차질을 빚지 않으면서도 문제를 실제로 해결해 주는 방안이며, 대부분의 팀이 더 일찍 이 방법을 알았더라면 좋았을 것이라고 생각하는 선택지입니다.

옵션 1: Express 5로 업그레이드

이것이 “공식” 답변입니다. Express v5로 마이그레이션하고, 최신 보안 패치를 적용하며, 개선된 기능을 활용하면 모두가 만족할 것입니다.

분명히 말씀드리자면, Express 5는 확실히 더 나아졌습니다. 이제 async/await 오류가 오류 처리 미들웨어로 자동 전달되므로, 더 이상 모든 비동기 경로를 수동으로 try/catch 블록으로 감쌀 필요가 없습니다. path-to-regexp 라이브러리가 v8.x로 업그레이드되어, 이전 버전의 라우팅에 영향을 미쳤던 특정 유형의 ReDoS 취약점이 해결되었습니다. 또한 Brotli 압축 기능이 내장되었습니다. 10년에 걸친 점진적인 개선 작업을 통해 코드베이스의 전반적인 품질이 크게 향상되었습니다.

하지만 v4 기반으로 구축된 운영 환경의 애플리케이션에 있어 “Express 5로 업그레이드”가 실제로 의미하는 바는 다음과 같습니다:

Node.js 18 이상: 이전 버전의 Node.js를 사용 중인 경우, 먼저 런타임을 업그레이드해야 하며, 이 과정에서 호환성 문제가 발생할 수 있습니다.
경로 구문 변경 사항: 와일드카드 경로가 app.get(‘*’) 에서 명시적인 명명된 패턴으로 변경되었습니다. 포괄적인 라우트가 수십 개 있다면 모두 업데이트해야 합니다.
사용 중단된 메서드 제거: app.del() 는 제거되었습니다 (대신 app.delete()를 사용하십시오). req.param() 는 더 이상 사용되지 않습니다. res.send(body, status) 서명이 사라졌습니다. 이 중 어느 하나만으로는 치명적이지 않지만, 모두 찾아서 수정해야 합니다.
body-parser 동작 변경 사항: The 확장 옵션의 기본값이 false 로 설정됩니다. req.body 를 통해 중첩된 객체를 파싱하는 애플리케이션의 동작이 달라질 수 있습니다.
비동기 미들웨어의 동작: 이전에는 아무런 오류 메시지 없이 값을 반환하던 라우트 핸들러가 이제 Express의 오류 처리 과정에 참여하게 됩니다. 이로 인해 기존 미들웨어의 동작이 미묘하게 달라질 수 있습니다.

Express 팀은 이러한 변경 사항 중 일부를 자동화하는 코드모드를 공개했는데, 이는 확실히 유용합니다. 테스트 커버리지가 잘 갖춰진 소규모 프로젝트라면 단기간에 끝낼 수 있을지도 모릅니다. 하지만 수백 개의 라우트와 복잡한 미들웨어 체인, 수년에 걸쳐 축적된 패턴을 가진 대규모 API의 경우라면 어떨까요? 신중한 계획과 철저한 테스트가 필요할 뿐만 아니라, 실제 운영 환경의 부하가 가해져야만 드러나는 미묘한 회귀 현상의 위험도 감수해야 합니다.

옵션 2: 대체 프레임워크로의 마이그레이션

일부 팀은 Express.js의 지원 종료(EOL) 소식을 접하고는 “이거야말로 우리에게 찾아온 기회일지도 몰라”라고 생각합니다.

대규모 애플리케이션을 위한 Fastify, Koa, Hapi, NestJS는 물론, 프레임워크 없이 순수 Node.js HTTP를 사용하는 경우까지, 각각의 선택지마다 설득력 있는 장점을 지닌 실질적인 대안들이 존재합니다. 특히 Fastify는 뛰어난 성능과 내장된 스키마 유효성 검사 기능으로 큰 주목을 받고 있습니다. 확고한 구조를 바탕으로 TypeScript 중심의 개발을 추진하려는 경우라면 NestJS를 고려해 볼 만합니다.

하지만 프레임워크 마이그레이션이 실제로 무엇을 수반하는지 과소평가해서는 안 됩니다. 단순히 의존성을 교체하는 것이 아닙니다. 새로운 프레임워크의 API를 사용하여 모든 라우트와 미들웨어를 다시 작성하고, 프레임워크마다 크게 다른 오류 처리 방식을 리팩토링하며, 새로운 규칙과 문서에 대해 팀을 재교육하고, Express 전용 헬퍼가 내장되어 있을 가능성이 높은 테스트 스택을 업데이트하고, 의존하고 있는 모든 타사 미들웨어에 해당 프레임워크와 호환되는 대체품이 있는지 또는 새 프레임워크에서 제대로 작동하는지 확인해야 합니다.

적절한 상황에서는 이러한 작업이 제공하는 유연성과 장기적인 이점이 충분히 그 가치를 입증할 수 있습니다. 하지만 일정과 비용은 대개 초기 예상치를 훨씬 초과하는 경향이 있으며, 대체 시스템을 구축하는 동안 기존 시스템을 유지 관리하는 것 자체만으로도 별도의 관리 부담이 발생합니다.

Fastify로 마이그레이션을 고려 중이라면, Fastify의 지원 종료(EOL )에 관한 당사의 종합 가이드를 읽어보시면 라이프사이클 일정과 관련 위험 요소를 파악하실 수 있습니다.

옵션 3: 타사 연장 지원

많은 팀이 그 존재조차 모르는 해결책이 바로 이것입니다. 바로 이 문제를 전문으로 다루는 기업들이 제공하는 확장 보안 지원 서비스입니다.

TuxCare는 Express.js의 지원 종료(EOL) 버전에 대해 ‘무제한 라이프사이클 지원’을 제공합니다. 준비가 되지 않은 상태에서 강제로 마이그레이션을 진행하거나, 마이그레이션을 계획하는 동안 API가 노출되는 상황을 피할 수 있으며, 현재 사용 중인 Express.js 버전을 계속 운영하면서도 지속적인 보안 패치 지원을 받을 수 있습니다.

이 아이디어는 간단합니다. 바로 시간과 주도권을 확보하는 것입니다. 자신의 조건에 맞춰 적절한 마이그레이션을 계획할 시간을 확보하는 것이죠. 보안 감사 마감일이나 CVE 공개로 인해 어쩔 수 없이 대응해야 하는 상황이 아니라, 업그레이드 일정을 스스로 주도할 수 있게 되는 것입니다.

Express.js 지원 종료(EOL) 업그레이드를 서두를 때 발생하는 진정한 비용

보안 대시보드에서 Express.js의 EOL(지원 종료) 경고가 마침내 임계점에 달하자, 팀들이 생산 환경 API를 서둘러 마이그레이션할 때 실제로 어떤 일이 벌어지는지 살펴보겠습니다.

규제 당국의 압박이 거세지면서 그 업그레이드 일정이 비현실적으로 단축되면, 예상대로 문제가 발생하기 마련입니다:

지원 업무량 증가: 테스트 단계에서는 드러나지 않았던 사소한 버그들이 실제 운영 환경에서 나타나기 시작합니다. 미들웨어 동작의 변화로 인해 간헐적인 장애가 발생합니다. 지원 팀은 티켓 처리로 인해 업무에 매몰되는데, 그중 절반은 마이그레이션과 관련이 있습니다.
시스템 불안정성: 경로 매칭 동작이 변경되어 다운스트림 서비스와의 연동이 깨질 수도 있습니다. 바디 파서(body-parser)의 기본값이 변경되어 특정 엔드포인트가 이전에는 유효했던 페이로드를 아무런 경고 없이 거부할 수도 있습니다. 이러한 문제들이 새벽 3시의 경보를 유발하고 SLA를 심각하게 저해하는 원인이 됩니다.
기술 부채의 누적: 규정 준수를 서두르다 보니 팀들은 편법을 쓰기 시작합니다. “나중에 제대로 리팩토링하자”는 말이 영구적인 임시방편이 되어버립니다. 마이그레이션 6개월 후, 기술적으로는 Express 5를 기반으로 하지만 호환성 쉘과 미뤄둔 정리 작업으로 가득 찬 코드베이스를 마주하게 됩니다.
예산 초과: 초기 예상 기간은 3주였습니다. 8주가 지났지만, 여전히 회귀 문제를 해결하느라 분주합니다. 마이그레이션을 위해 고용한 그 계약업체는 여전히 시간당 비용을 청구하고 있습니다. 기능 추가 일정은 연기되었습니다. 기회 비용은 실재하며 그 규모도 상당합니다.

업그레이드를 하지 말라는 말이 아닙니다. 업그레이드는 장기적으로 볼 때 분명 올바른 해결책입니다. 다만, 규정 준수 압박 때문에 서둘러 진행하는 업그레이드는 명백하고 예측 가능한 실패 요인이 될 수 있으며, 다른 대안이 있는 상황에서 “지금 당장 해야 한다”는 주장은 실제로는 거의 사실이 아니라는 점을 말씀드리고 싶은 것입니다.

간편한 해결책: 지원 종료된 Express.js 버전에 대한 지속적인 라이프사이클 지원

TuxCare는 지난 10년 넘게 지원이 종료된 운영 체제, 런타임, 라이브러리, 그리고 이제는 애플리케이션 프레임워크를 위한 보안 패치를 제공해 왔습니다. 이들은 오픈소스 생태계 전반에 걸쳐 22만 개 이상의 보안 패치를 배포했습니다. 지원이 종료된 소프트웨어를 기업 규모로 안전하게 유지하는 방법을 알고 있다고 말할 때, 이는 단순한 이론적 능력을 말하는 것이 아닙니다. 그들은 실제로 이를 실현해 냈습니다.

TuxCare의 접근 방식이 다른 점은 무엇인가요?

완벽한 종속성 트리 지원: TuxCare는 단순히 Express 자체에만 패치를 적용하는 것이 아닙니다. 직접적인 종속성뿐만 아니라 그 아래에 있는 전이적 종속성까지 모두 추가 비용 없이 지원합니다. body-parser, serve-static, send, path-to-regexp 등 끝없이 이어지는 종속성 체인을 기억하시나요? TuxCare가 이를 모두 해결해 드립니다. 단순히 프레임워크만 보호하는 것이 아니라, Express.js의 전체 종속성 영역을 안전하게 보호하는 것입니다.

정교하고 자동화된 패치 적용 프로세스: TuxCare의 프로세스는 강력한 자동화와 전문가의 검증을 결합합니다. TuxCare는 NVD, 벤더 보안 권고, GitHub 보안 피드, 그리고 Express.js EOL 취약점이 공개되는 모든 곳을 모니터링합니다. CVE가 등록되면 알고리즘 도구와 AI 기반 자동화를 활용해 보안 수정 사항을 백포트하고, 보안 전문가들이 패치를 배포하기 전에 하나하나 검증합니다. 모든 업데이트는 리포지토리에 반영되기 전에 무결성, 기능성 및 회귀 테스트를 거칩니다. 이 과정이 정확히 어떻게 진행되는지 확인해 보시겠습니까? TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를 확인해 보세요를 확인해 보세요.

원활한 통합: TuxCare의 패치는 기존 npm 워크플로우에 바로 적용됩니다. npm이나 Yarn을 사용 중이라면 ELS 패키지를 바로 사용할 수 있습니다. CI/CD 파이프라인을 전면 개편하거나 팀을 재교육할 필요가 없습니다. 이미 구축해 둔 환경을 그대로 계속 사용할 수 있습니다.

SLA로 보장되는 신속 대응: 새로운 Express.js EOL(지원 종료) 취약점이 공개될 경우, TuxCare는 실제 서비스 수준 계약(SLA)에 기반하여 보장된 일정 내에 패치를 제공합니다. 누군가가 언젠가 수정 패치를 역포트해 주기를 바라며 손가락을 꼬고 기다릴 필요가 없습니다. 계획 수립이 가능한, 즉시 생산 환경에 적용할 수 있는 보안 업데이트를 제공받게 됩니다.

비용 효율성: 연장 지원 서비스에 대해 대부분의 팀이 놀라워하는 점은 바로 이 부분입니다. 대체 방안보다 일반적으로 훨씬 저렴하다는 사실입니다. 실제 시간당 요율로 계산한 엔지니어링 비용, 테스트 주기, 외주 비용, 잠재적인 가동 중단 시간, 기능 출시 지연, 그리고 기회 비용을 솔직하게 모두 합산해 보면, ELS 비용은 그 총액의 극히 일부에 불과합니다. 게다가 고강도 마이그레이션 작업으로 팀원들이 지치게 만들 필요도 없습니다.

규정 준수 및 투명성: 모든 TuxCare 릴리스에는 어떤 패치가 적용되었는지, 어떤 CVE가 해결되었는지, 어떤 구성 요소가 수정되었는지, 그리고 소프트웨어 BOM(SBOM) 내의 모든 내용을 어떻게 검증할 수 있는지에 대한 완전한 가시성이 포함됩니다. 이는 EOL(제품 수명 주기 종료) 소프트웨어에 대해 구체적인 질문을 제기하는 PCI DSS 감사, SOC 2 검토 및 기타 모든 규정 준수 프레임워크에 꼭 필요한 사항입니다.

시작하는 방법

Express.js의 지원 종료(EOL) 버전을 사용 중이며 어떤 보안 패치가 제공되는지 확인하고 싶다면, TuxCare에서 운영하는 실시간 CVE 추적기를 통해 정확히 어떤 취약점이 패치되었는지 확인할 수 있습니다. Express의 실시간 취약점 및 수정 사항 확인.

지원되는 버전, 가격 및 구현에 대한 자세한 정보를 원하시나요? 다음을 방문해 주세요 TuxCare의 Express용 Endless Lifecycle Support 를 방문하여 자세한 내용을 확인해 보세요.

방치하지 마세요 Express.js의 지원 종료로 인해 API가 위험에 처하지 않도록 하세요

Express.js는 놀라운 성과를 거두었습니다. 이 프레임워크는 백엔드 자바스크립트 개발을 대중화했으며, 전 세계 API의 상당 부분을 뒷받침하고 있으며, 여전히 활발히 유지보수되고 있어 v5로 계속 발전하고 있습니다. 이는 결코 작은 성과가 아닙니다.

하지만 프로덕션 환경에서 Express.js의 지원 종료(EOL) 버전을 사용 중이라면, 2015년부터 지원이 종료된 v3이든, 조만간 사용 중단될 예정인 v4 설치 환경이든, “아직 작동한다”는 것이 “아직 안전하다”는 뜻은 아닙니다.

실제로 알아두셔야 할 점은 다음과 같습니다. Express.js의 지원 종료(EOL)가 반드시 당황스러운 상황을 의미하는 것은 아닙니다. 여러분에게는 선택지가 있습니다. 팀과 코드베이스에 진정으로 적합하다고 판단될 때 Express 5로 신중하게 업그레이드할 계획을 세울 수 있습니다. 아키텍처상 전환해야 할 실질적인 이유가 있다면 다른 프레임워크를 검토해 볼 수도 있습니다. 또는 확장 지원(Extended Support)을 활용하여 보안 및 규정 준수 상태를 유지하면서, 보안 감사 일정에 쫓기지 않고 본인의 일정에 맞춰 결정을 내릴 수도 있습니다.

Express.js의 지원 종료(EOL) 상황을 잘 대처하는 팀은 반드시 예산이 가장 많거나 코드베이스가 가장 최신인 팀은 아닙니다. 오히려 위험을 조기에 파악하고, 실제로 어떤 대안이 있는지 이해하며, 사후 대응이 아닌 신중한 선택을 내리는 팀들이 바로 그들입니다.

현재 Express.js의 지원 종료(EOL)를 염두에 두고 계신다면, TuxCare가 제공하는 서비스를 확인해 보시는 것이 좋습니다. 서둘러 준비되지 않은 마이그레이션을 진행하는 것보다, 실제로 원하는 업그레이드 계획을 세우는 동안 기존 시스템을 안정적으로 유지하는 것이 더 현명한 다음 단계라는 사실을 알게 되실 수도 있습니다.

TuxCare의 오픈소스 소프트웨어 ‘무한 라이프사이클 지원’을 확인해 보세요 확장된 지원이 필요한 기간 동안 전체 오픈소스 스택을 어떻게 보호할 수 있는지 확인해 보세요.

요약