Express.js의 지원 종료와 단순히 대체할 수 없는 API들

주요 내용

• Express 4는 2025년 4월부터 유지보수 단계에 들어갔으며, 2026년 10월부터 제품 수명 종료(EOL)가 예정되어 있습니다.
• 주요 제품군의 최신 릴리스에만 수정 사항이 적용되므로, 고정된 4.x 소버전에는 해당되지 않습니다.
• Express 3는 2015년 7월에 지원이 종료되었으며, 그해 8월 이후로 이 버전의 어떤 문제도 수정되지 않았습니다.
• Express 5는 Node.js 18 이상이 필요하기 때문에, 프레임워크 업그레이드는 종종 런타임 마이그레이션으로 이어집니다.

Express는 별다른 노력을 들이지 않고도 명성을 얻었습니다. 최소한의 라우팅, 미들웨어 파이프라인, 그리고 팀원들이 폴더 구조를 두고 다투지 않도록 하는 데 딱 필요한 정도의 관례만 적용했을 뿐입니다. 바로 이러한 절제 덕분에, 누구도 의도적으로 결정하지 않았음에도 수많은 서비스가 Express를 사용하게 되었고, 일단 작동하기 시작하면 아무도 다시 돌아보지 않게 된 것입니다.

이것이 바로 결제 API가 의존성 스캐너가 이를 감지할 때까지 7년 동안 Express 4.17.1을 아무런 수정 없이 그대로 실행하게 되는 이유입니다. 코드 자체에는 아무런 변화가 없었습니다. 변한 것은 그 주변의 모든 것이었습니다.

이 모순은 두 가지 진술에서 비롯됩니다. Express 웹사이트에서는 4.x 계열에 대한 지원이 여전히 진행 중이라고 밝히고 있습니다. 반면, 의존성 스캐너는 해당 서비스에 취약점이 있다고 알려줍니다. 4.x 계열에 대한 지원이 과거의 모든 4.x 릴리스에 대한 지원과 같은 의미는 아니기 때문에, 두 진술은 동시에 모두 맞습니다.

이는 부주의가 아닙니다. 바로 ‘장수’입니다. 2026년 버라이즌 DBIR 보고서에 따르면, 취약점 악용이 현재 보안 침해의 가장 흔한 시작 방식으로, 초기 접근 사례의 31%를 차지하며, 이는 전년도의 20%에서 증가한 수치이자, 이 보고서가 발간된 지 19년 만에 처음으로 자격 증명 남용을 앞지른 것입니다. 같은 기간 동안 완전한 복구에 소요되는 시간의 중앙값은 32일에서 43일로 늘어났다. 취약한 시스템은 대개 제대로 작동하고 있어 아무도 그 문제에 대해 긴박감을 느끼지 않는 경향이 있다.

Express 4는 지원이 종료되었나요?

간단히 말해, 아닙니다. 2026년 8월 현재 Express 4는 EOL(지원 종료) 상태가 아니며, 4.x 계열은 여전히 새 버전이 출시되고 있습니다. 좀 더 자세히 설명하자면, 이제 시간이 흐르고 있는 상황이며, 주요 버전 번호만으로는 락파일(lockfile)에 고정된 릴리스에 수정 사항이 적용될지 여부를 알 수 없습니다.

Express는 출시 이후 대부분의 기간 동안 LTS 일정이 전혀 없었습니다. 2025년 3월, 프로젝트 측이 5.1.0을 npm 기본 버전으로 지정함과 동시에 LTS 전략을 발표하면서 상황이 바뀌었습니다. 이제 메이저 버전은 CURRENT, ACTIVE, MAINTENANCE 단계를 거치게 됩니다. Express 4는 2025년 4월 1일에 MAINTENANCE 단계에 진입했으며, 이는 보안 패치와 우선순위가 높은 버그 수정만 제공되며, 지원 종료(EOL) 시점은 2026년 10월 1일 이후가 될 예정임을 의미합니다. 프로젝트 측은 이를 ‘약속’이 아닌 ‘목표’로 규정하고, v4를 기간이 연장될 수 있는 특수한 사례로 분류하고 있지만, 그 방향성은 분명합니다.

한편, 공식 지원 페이지에는 여전히 4.x와 5.x 버전이 종료일 없이 “지속 중”으로 표시되어 있으며, 각 메이저 버전에 대한 최소 Node.js 버전과 지원 시작일도 함께 기재되어 있습니다. 두 문서의 내용이 일치하지 않기 때문에, 프레임워크의 지원이 언제 종료되는지 묻는 감사관에게 이 점을 설명하기에는 다소 난처한 상황입니다.

실제로 중요한 규칙은 해당 지원 페이지 상단에 한 줄로 적혀 있는 내용입니다. 특정 메이저 릴리스 계열 중에서는 최신 버전만 지원됩니다. 보안 업데이트 페이지에서는 릴리스별로, 버전별로 어떤 취약점이 수정되었는지 상세히 안내하고 있습니다. 이 두 내용을 종합해 보면, 버전 번호만으로는 알 수 없는 사실이 드러납니다. 즉, 지원되는 메이저 릴리스를 사용한다고 해서 반드시 지원되는 버전을 사용하는 것은 아니라는 점입니다.

바로 그 차이가 감사 결과를 종결시키거나 미결 상태로 남게 하는 요인입니다. 4.x 버전이 여전히 유지되고 있다는 사실은 4.17.1 버전에 대해 아무런 정보를 주지 않습니다. 왜냐하면 수정 사항은 2019년에 고정된 마이너 버전이 아니라 최신 4.x 버전에 적용되기 때문입니다. 락파일(lockfile)에 정확한 버전을 명시할 수 없다면, 해당 버전이 지원 대상인지 아직 알 수 없습니다. 스캐너와 논쟁을 벌이기 전에 먼저 정확한 버전을 확인해 보십시오.

미들웨어 타임캡슐

Express 자체는 작습니다. 오래된 Express 서비스가 취약한 이유는 그 위에 추가된 모든 요소들 때문입니다. 바디 파서, 세션 저장소, 인증 전략, 템플릿 엔진, 그리고 수년 전에 이미 회사를 떠난 사람들이 작성하고 아무런 문서도 남기지 않은 맞춤형 미들웨어 등이 바로 그것입니다.

Express만 업데이트한다고 해서 문제가 해결된 것처럼 착각하기 쉽습니다. 프레임워크를 업그레이드하고 최상위 수준의 보안 권고 사항이 해소된 것을 확인하더라도, 취약점이 있는 전이적 패키지가 여전히 한 단계 아래에 그대로 남아 있을 수 있습니다.

Express 4는 다음을 포함하여 대략 30개의 직접 의존성을 선언합니다. qs, body-parser, send, serve-static, path-to-regexp, proxy-addr, 그리고 forwarded, 그 아래에는 더 광범위한 의존성 구조가 자리 잡고 있습니다. 아무도 그 라이브러리들을 직접 선택하지 않았습니다. 이 라이브러리들은 Express와 함께 제공되며, 해당 라이브러리 중 하나에 취약점이 존재할 경우, 영향을 받는 코드 경로에 접근할 수 있을 때마다 해당 취약점이 여러분의 애플리케이션에도 취약점으로 이어집니다. 2024년에 보고된 네 건의 CVE 사례가 이러한 현상이 어떻게 나타나는지 보여줍니다.

어색한 점은 4.19.2가 오픈 리디렉션 문제를 해결한 릴리스임에도 불구하고, 이 버전보다 이후의 모든 버전보다 여전히 오래된 버전이라는 사실입니다. 4.19.2를 사용 중인 애플리케이션은 CVE-2024-29041은 해결되었지만, XSS 및 두 가지 path-to-regexp ReDoS 취약점은 여전히 남아 있습니다. 이는 해당 수정 사항들이 4.x 계열의 더 후속 버전에서 적용되었기 때문입니다. 또한 오픈 리디렉션 문제는 4.19.0에서 초기 수정, 4.19.1에서 회귀 현상 패치, 4.19.2에서 우회 방법이 제대로 처리되는 등 세 번의 시도를 거쳐 해결되었으므로, 4.19.2 미만의 버전에서는 해당 문제가 완전히 패치되지 않았다는 점도 주목할 만합니다.

경고: 분류를 진행하기 전에 다음 명령을 실행하십시오. npm ls path-to-regexp qs send 애플리케이션이 실제로 배포하는 종속성 트리와 대조하고, 해결된 버전을 락파일과 비교해 보세요. 다른 종속성을 통해 유입된 전이적으로 고정된 사본 때문에, Express 자체가 최신 버전이라 하더라도 보안 취약점에 노출될 수 있습니다.

한 가지 주의할 점이 있습니다. “영향을 받은” 것과 “악용된” 것은 다릅니다. 특정 발견 사항이 단순한 사고에 그칠지, 아니면 실제 문제점으로 분류될지는, 해당 애플리케이션이 취약한 코드 경로를 공격자가 제어하는 입력에 실제로 노출시켰는지 여부에 달려 있습니다.

오픈소스에 대한 벤더 패치 제공은 바로 이러한 격차를 해소하기 위한 것입니다. TuxCare의 Express 지원 범위는 최상위 수준이 아닌, 지원 대상 릴리스와 함께 제공되는 지원 대상 구성 요소 전반에 걸쳐 적용됩니다. express 패키지 자체만으로도, 이는 발견 사항을 시정하는 것과 이를 유예하는 것의 차이입니다. 연구에 따르면 엔도르 랩스 오픈소스 취약점의 약 95%는 개발자가 직접 선택한 의존성이 아니라 전이적 의존성에 존재한다고 추정되며, 레거시 환경에서는 수정 사항이 적용된 브랜치로 간단히 전환할 수 있는 선택지가 거의 없습니다. TuxCare의 CVE 추적기 버전별 패치 상태를 표시하므로, 현재 어떤 상황에 있는지 확인할 수 있습니다.

Express 5에는 Node.js가 포함되어 있습니다

“Express 5로 업그레이드”가 예산에 반영될 때 간과되는 점은, Express 5가 Node.js 18 이상을 필요로 한다는 사실입니다. 프레임워크 업그레이드는 결국 프레임워크 업그레이드가 수반된 런타임 마이그레이션으로 이어지게 됩니다.

Express 5는 또한 구버전 애플리케이션들이 암묵적으로 의존해 오던 동작들도 변경했습니다. 거부된 프로미스와 비동기 핸들러에서 발생된 오류는 이제 자동으로 오류 처리 미들웨어로 전달됩니다. 더 이상 사용되지 않는 시그니처들이 대거 제거되었으며, 여기에는 다음이 포함됩니다. res.send(body, status) 그리고 “back”이라는 매직 문자열이 res.redirect. 경로 매칭 기능이 path-to-regexp 8로 이전되었으며, 이 버전에서는 ReDoS 공격을 방지하기 위해 경로 문자열 내의 하위 표현식 정규식을 제거했으므로, 해당 패턴에 의존하는 경로는 재작성해야 합니다.

Node 14 시대의 컨테이너 이미지를 여전히 표준으로 사용하고 있는 내부 클레임 서비스를 상상해 보세요. Express 4에서 5로 업그레이드하는 것은 쉬운 부분입니다. 어려운 부분은 그 이미지를 현재 지원되는 Node.js 릴리스로 이전하는 것인데, 이 릴리스는 어차피 Express 5의 최소 요구 사항을 충족하면서도, 구형 ABI에 맞춰 컴파일된 네이티브 모듈의 호환성을 깨지 않아야 합니다.

Express의 공식 마이그레이션 가이드에서는 v4 애플리케이션이 v5에서 변경 없이 실행되지 않을 수 있음을 솔직하게 밝히고 있으며, 이러한 관점은 유용합니다. 이를 통해 이 문제를 프레임워크의 문제라기보다는 런타임 및 테스트의 문제로 규정할 수 있게 됩니다.

전문가 조언: Express를 업그레이드하기 전에, 실제로 배포할 예정인 Node.js 릴리스 버전을 대상으로 기존 테스트 스위트를 실행해 보세요. 다음과 같이 간단한 테스트라도 nvm use <target> && npm test Express와 무관한 네이티브 모듈 및 ABI 오류가 드러나게 될 것입니다.

세 가지 현실적인 방안과 각각의 비용

이 문제에 대한 정답은 따로 없으며, 오직 여러분의 의존성 그래프, 테스트 커버리지, 런타임 환경에 맞는 해결책만이 있을 뿐입니다. 세 가지 접근 방식이 대부분의 상황을 아우릅니다.

Express 5로 이동

의존성 트리가 깔끔하고 통합 테스트 결과를 신뢰할 수 있을 때 선택할 수 있는 방법입니다. 런타임을 업그레이드하고, Express를 업그레이드하며, 비동기 오류 처리와 라우트 패턴을 차례로 처리해 나가면 CI 결과가 ‘녹색’으로 바뀌는 것을 확인할 수 있습니다. 프레임워크 변경 작업은 전체 작업량 중 비교적 적은 부분을 차지할 수 있습니다.

4.x 버전을 계속 사용하면서 최신 릴리스를 확인하세요

기존 라우팅 방식과 주류 미들웨어를 고수하는 애플리케이션의 경우 여전히 타당하지만, 그 수명은 점점 짧아지고 있습니다. 최신 4.x 버전(현재 4.22.2)을 따르고, 이를 일회성 조치가 아닌 일상적인 작업으로 간주하십시오. 또한 이 역시 무료는 아닙니다. 2025년 12월 1일, Express는 CVE-2024-51999로 등록되었던 문제에 대해 두 라이브 라인 모두에 쿼리 파서 변경 사항을 배포했습니다. 이 CVE는 취약점이 아니라는 이유로 기각되었으며, 4.22.1 및 5.2.1 버전에서는 원래 패치가 배포된 지 약 4시간 뒤인 당일 저녁에 해당 변경 사항을 되돌렸습니다. 그러나 2026년 5월 출시된 4.22.2 버전에서 반복되는 쿼리 키에 대한 배열 파싱 동작을 복원해야 했기 때문에, 이 문제도 완전히 해결되지는 않았습니다. 최신 버전을 유지한다는 것은 이러한 변경 사항을 수용해야 함을 의미합니다. 지원되는 메이저 버전을 유지하는 것은 해당 라인을 계속 따라가는 동안에만 도움이 되며, 구형 4.x 버전에 고정되는 순간 4.17.1에 고정된 다른 버전들과 동일한 상황에 처하게 됩니다.

마이그레이션 일정이 확정될 때까지의 연장 지원

그러면 처음 두 가지가 다루지 않는 사례들, 즉 Node.js 런타임이 멈춘 경우, 사용자 정의 인증 미들웨어, 또는 실제로 분 단위로 실행되는 마이그레이션이 남게 됩니다. 맞춤형 인증 계층과 고정된 런타임을 갖춘 규제 대상 API의 경우, 스프린트 한두 개 이상 소요될 수 있으며, 스캐너가 빨간색으로 표시되었다는 이유만으로 서두르다 보면 서비스 중단 사고가 발생하기 마련입니다. TuxCare ELS는 3.4.8, 3.21.2, 4.17.1, 4.18.1, 4.18.2, 4.18.3, 4.19.2를 포함한 특정 Express 릴리스를 지원하며, 이는 범위 지정(scoped) 방식으로 배포됩니다. @els-js 인증된 TuxCare 레지스트리를 통해 패키지를 배포합니다.

간단히 말하자면, 깔끔한 그래프와 신뢰할 수 있는 테스트 결과는 Express 5를 선택해야 한다는 신호입니다. 반면, 기존 방식의 라우팅과 표준 미들웨어는 최신 4.x 버전을 계속 따라가는 편이 낫다는 것을 시사합니다. 런타임이 고정되었거나 여러 분기에 걸쳐 마이그레이션이 진행된다는 점은, 지원 기간이 무기한이 아닌 계획된 기간 동안 연장된다는 것을 의미하며, 4.x 버전에 목표 EOL 날짜가 지정된 현재 상황에서는 이 점이 더욱 중요합니다.

TuxCare가 지원 종료된 Express 버전을 어떻게 지원하는가

라이브러리에 대한 확장 지원은 화려하지 않은 작업이지만, 사실 그게 바로 핵심입니다. 이 작업은 지원 대상인 Express 릴리스와 함께 제공되는 지원 구성 요소 전반에 걸친 취약점 모니터링으로 시작됩니다. 새로운 취약점이 공개될 때마다 가장 먼저 확인해야 할 점은, 해당 취약점이 실제로 해당 릴리스에 영향을 미치는지, 아니면 이후에 도입된 코드 경로에만 영향을 미치는지 여부입니다.

패치가 필요한 경우, 체계적인 백포팅을 적용합니다. 업스트림 수정 사항 중에서 보안과 관련된 변경 사항만 채택하고, 함께 포함된 관련 없는 리팩토링은 제외하며, 아무도 계획하지 않았던 프레임워크 업그레이드가 끌려 들어오는 것을 방지합니다. 그 결과물은 유지보수되는 패키지로 배포되기 전에 기존 동작에 대한 회귀 테스트를 거치며, SBOM 및 VEX 데이터도 함께 공개됩니다. 이러한 기계 가독성 증거 덕분에 보안 팀은 발견 사항을 다음 분기로 미루지 않고 적절하게 문서화할 수 있습니다. 이는 업스트림을 대체하기보다는 전문화를 추구하는 것으로, 프로젝트가 이미 넘어간 브랜치를 장기적으로 유지보수하고, 어떤 것도 배포하기 전에 호환성 테스트를 수행함을 의미합니다.

준법 팀에서는 항상 대응 시기에 대해 문의하므로, 공식적으로 발표된 목표치를 안내해 드립니다. CVSS 7.0 이상인 ‘높음’ 및 ‘중대’ 수준의 취약점에 대해서는 공개된 시점부터 14일 이내, ‘중간’ 수준의 취약점은 60일 이내, ‘낮음’ 수준의 취약점은 90일 이내에 대응해야 합니다. 적용 대상 버전 및 설치 단계는 TuxCare ELS for Express 문서에 수록되어 있으며, 보다 포괄적인 내용은 라이브러리 EOL 지원 섹션에서 확인하실 수 있습니다.

OpenJS의 지속가능성이 어떤 역할을 하는지

Express는 OpenJS 재단이 주관하는 ‘임팩트 프로젝트’이며, 이는 재단이 아카이브된 버전, 지원 종료된 버전, 구버전 프로젝트에 대한 상업적 지원을 위한 공식적인 체계를 제공하기 때문에 중요합니다. 2024년 5월에 출범한 ‘OpenJS 생태계 지속 가능성 프로그램’은 상업적 제공업체와 이러한 버전을 연결해 주며, 파트너사들은 기업용 매출의 일부를 참여 프로젝트에 환원합니다.

TuxCare는 HeroDevs 및 NodeSource와 함께 ESP 파트너로 등재되어 있으며, 이 프로그램은 파트너사가 재단의 골드 또는 플래티넘 회원이어야 한다고 규정하고 있습니다. Node.js 지원 종료 페이지에도 동일한 세 업체가 명시되어 있는데, 이는 이번 조치가 즉흥적인 대응이 아니라 이미 정착된 모델임을 시사하는 분명한 신호입니다.

두 가지 제한 사항을 명확히 밝혀둘 필요가 있습니다. 이 프로그램은 배타적이지 않으며 요건을 충족하는 모든 제공업체에 개방되어 있습니다. 또한, 유지보수 담당자가 ESP 파트너가 지원하는 버전을 포함하여 어떤 버전에 대한 수정 사항도 공개적으로 발표하는 것을 막지 않습니다. 또한, Express 프로젝트의 공식 지원 페이지에는 현재 HeroDevs가 상용 옵션으로 기재되어 있으므로, 특정 버전에 대한 지원 여부는 검토 중인 제공업체에 직접 확인해야 합니다.

현실 점검: 공급업체의 백포트 패치를 통해 4.17.1 버전의 해당 취약점을 해결할 수는 있지만, 그렇다고 해서 4.17.1 버전이 업스트림에서 지원하는 릴리스가 되는 것은 아닙니다. 규정 준수 요건에 ‘업스트림 지원’이 명시되어 있다면, 공급업체의 패치는 전혀 다른 문제를 해결하는 것이므로, 어떤 요건이 요구되는지 정확히 파악하는 것이 중요합니다.

구형 Express 애플리케이션을 평가하는 방법

어떤 경로를 선택하기 전에, 현재 자신의 상황이 어떤지 정확히 파악하세요. ~에 명시된 범위 대신, 락파일(lockfile)에 명시된 정확한 Express 버전을 기준으로 시작하세요. package.json. 다음을 사용하여 직접 및 전이적 종속성을 탐색합니다. npm ls 그리고 이를 알려진 보안 권고 사항과 대조해 확인하십시오. 사용자 정의 미들웨어와 애플리케이션이 의존하고 있는 문서화되지 않은 동작을 모두 파악하십시오. 애플리케이션이 실행되는 Node.js 버전을 확인하고 해당 런타임이 여전히 지원되는지 여부를 파악해야 합니다. 이는 Express 5 도입 여부를 결정하는 핵심 요소이기 때문입니다. 그런 다음 노출 정도와 비즈니스 중요도를 고려하여 우선순위를 정하십시오. 따라서 트래픽이 적은 내부 대시보드보다 결제 API에 더 많은 관심을 기울여야 합니다.

한 가지 간과하기 쉬운 점이 있습니다. Express는 SDK, 미들웨어 패키지 및 기타 종속성을 통해 간접적으로 포함될 수도 있으므로, 아무도 설치하지 않은 버전도 그래프에 나타납니다. 라이프사이클 상태와 간접적 종속성을 고려하지 않은 평가 결과는 전체적인 그림이 아닌 단순한 목록에 불과합니다.

공개로 인해 일정이 강요된 것이 아니라, 아키텍처적 일정에 따라 업그레이드를 진행하십시오. ‘무한 수명 주기 지원 ( Endless Lifecycle Support)’은 이러한 여유를 확보하기 위해 존재하며, 테스트하고 통제할 수 있는 일정에 따라 마이그레이션이 진행되는 동안 현재 실행 중인 버전에 대한 패치를 지속적으로 제공해 줍니다.

요약

기사 이름

Express.js 지원 종료 및 지원 종료 버전 지원 | TuxCare ELS

설명

Express 4 EOL은 2026년 10월부터 적용될 예정이며, 최신 릴리스에만 수정 사항이 제공됩니다. 경로와 TuxCare ELS를 비교해 보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고