기술 지원
문서
로그인
문의하기
이 블로그 글의 AI 요약으로 바로 가기 
주요 내용
- Node.js 20은 2026년 4월 30일에 지원 종료(EOL)에 도달했으며, Node.js 18 및 그 이전 모든 버전과 마찬가지로 해당 프로젝트로부터 더 이상 보안 패치를 제공받지 않게 되었습니다.
- Node.js 버전이 EOL(지원 종료) 상태라는 것은, 이미 공개된 CVE에 대한 패치가 제공되지 않으며, 이후에 발견되는 문제에 대해서도 수정 사항이 제공되지 않음을 의미합니다.
- 모든 공식 Node.js 바이너리에는 약 25개의 구성 요소가 포함되어 있습니다. OpenSSL, zlib, ICU와 같은 일부 구성 요소는 OS가 다른 곳에서 패치하는 시스템 라이브러리 형태로도 존재하지만, Node.js 내부에는 포함되지 않습니다. 반면 V8이나 undici와 같은 다른 구성 요소는 시스템 패키지가 아예 없기 때문에, 업스트림의 수정 사항은 새로운 Node.js 빌드를 통해서만 사용자에게 전달됩니다. 번들된 모든 구성 요소는 지원 종료(EOL) 시점에 더 이상 업데이트되지 않습니다.
- 선택지는 지원되는 LTS 버전으로 업그레이드하거나, Node.js에서 다른 플랫폼으로 마이그레이션하거나, 확장 지원 서비스를 이용하여 자체 일정에 따라 이전 계획을 세우는 동안 패치를 계속 적용받는 것입니다.
스택의 일부에서 여전히 Node.js 18이나 20을 사용 중이라면, 같은 처지에 있는 곳이 많습니다. 짝수 버전의 LTS 라인은 실제 운영 환경에서 널리 사용되고 있으며, 지원이 종료된다고 해서 바로 작동이 중단되는 것은 아닙니다. 단지 버그 수정이 중단될 뿐입니다. Node.js 20은 2026년 4월 30일에 그 시점을 넘겼으며, 그 이전의 모든 릴리스는 이미 그 시점을 넘긴 상태였습니다.
이 게시물에서는 지원 종료된 Node.js 버전이 무엇인지, 이를 기반으로 구축된 애플리케이션의 보안 및 규정 준수 상태에 어떤 영향을 미치는지, 그리고 향후 취할 수 있는 세 가지 현실적인 방안, 즉 업그레이드, 마이그레이션, 또는 결정할 때까지 패치를 계속 받아볼 수 있는 Node.js 확장 지원 활용에 대해 다룹니다.
어떤 Node.js 버전이 지원 종료되었나요?
2026년 7월 현재, Node.js 프로젝트로부터 업데이트를 계속 받고 있는 릴리스 라인은 26.x(현재), 24.x(활성 LTS), 22.x(유지보수 LTS)의 세 가지뿐입니다. Node.js 20 및 그 이전 버전은 지원이 종료되었으며, LTS에 진입하지 못한 홀수 버전 라인도 마찬가지로 지원이 종료되었습니다.
| 버전 (코드명) | 상태 | 지원 종료 |
| 26.x | 현재; 2026년 10월에 LTS 단계에 진입합니다. | 4월 30, 2029 |
| 24.x (크립톤) | 활성 LTS | 4월 30, 2028 |
| 22.x (Jod) | LTS 유지보수 | 4월 30, 2027 |
| 25.x, 23.x, 21.x, 19.x | 지원 종료; LTS 버전에 포함되지 않음 | 2026년 6월 및 그 이전 |
| 20.x (철) | Lifecycle 종료 | 4월 30, 2026 |
| 18.x (Hydrogen) | Lifecycle 종료 | 4월 30, 2025 |
| 17.x 및 그 이전 버전 | Lifecycle 종료 | 2023년 또는 그 이전 |
Node.js는 역사적으로 매년 두 개의 주요 버전을 출시해 왔으며, 짝수 버전은 장기 지원(LTS) 버전으로 지정됩니다. 약 6개월 동안은 ‘Current’ 버전으로 유지되고, 이후 12개월 동안은 버그 및 보안 수정 사항이 적용되는 ‘Active LTS’ 버전으로 유지되며, 그 후에는 중대한 수정 사항만 적용되는 ‘유지보수’ 단계로 넘어갑니다. 즉, LTS 기간은 약 30개월이며, 최초 출시부터 지원 종료까지의 기간은 대략 36개월입니다.
이러한 모델이 바뀌고 있습니다. Node.js 27부터 이 프로젝트는 연 1회 메이저 릴리스로 전환되며, 모든 릴리스가 LTS가 되고, 버전 번호는 양력 연도와 일치하게 됩니다. 즉, 2027년에는 27.0.0, 2028년에는 28.0.0이 됩니다. 2026년 10월에는 새로운 알파 채널이 개설되어, 이전에는 홀수 버전 계열이 담당하던 초기 테스트 역할을 이어받게 되며, Node.js 26은 기존 모델 하에서 출시되는 마지막 버전입니다. 전체 지원 기간은 기존과 동일하게, 첫 번째 Current 릴리스부터 지원 종료까지 약 36개월로 유지됩니다. 일정은 더 예측 가능해졌지만, 최종 시점은 동일합니다. 즉, 모든 라인에는 패치 제공이 중단되는 날짜가 여전히 존재합니다.
또한 전용 가이드에서 Node.js 18의 지원 종료(EOL ) 일정 및 영향에 대한 상세한 분석을 확인해 보실 수 있습니다.
Node.js의 EOL이 애플리케이션에 미치는 영향
Node.js 프로젝트는 이 점에 대해 유난히 직설적입니다. 해당 프로젝트의 지원 종료(End-of-Life) 페이지 에서는 네 가지 결과를 경고하고 있습니다. 바로 취약점 수정 중단, 툴체인 호환성 문제, 인기 패키지가 구형 런타임에 대한 지원을 중단함에 따른 생태계 변화, 그리고 “많은 업계 감사에서 유지보수가 중단된 런타임 사용을 금지하고 있기” 때문에 발생하는 규정 준수 문제입니다.
여러분이 이미 알고 있는 패치되지 않은 CVE들
Node.js는 정기적인 주기로 보안 업데이트를 배포하며, 각 업데이트에서는 지원 종료(EOL)된 버전에 대한 수정 사항을 완전히 제외하고 있습니다. 2026년 7월 30일 현재, 프로젝트의 EOL 페이지에는 Node.js 20에 대한 고위험 취약점이 27건, Node.js 18에 대한 취약점이 15건으로 기재되어 있으며, 이 수치는 계속 증가하고 있습니다.
이러한 패턴이 바로 이 문제를 위험하게 만드는 원인입니다. 2026년 7월 29일 보안 릴리스는 은 26.x, 24.x, 22.x 계열에만 적용되었습니다. 이 릴리스는 11개의 문제를 수정했는데, 그중 3개는 심각도가 높은 문제였으며, 여기에는 번들된 nghttp2의 HTTP/2 재진입(re-entrancy) 버그로 인해 프로세스에 힙 use-after-free 취약점이 발생하는 문제도 포함되었습니다. Node.js 20과 18은 아무런 수정도 받지 못했으며, 보안 권고문은 패치를 받지 못한 모든 버전에서 공격자가 정확히 어디를 노려야 하는지까지 상세히 알려주었습니다. 공개 권고문, 공개 패치, 공개 diff. 발견 작업의 대부분은 이미 완료된 상태입니다.
얼마나 심각한 문제인지 감을 잡으려면 HTTP/2 Rapid Reset(CVE-2023-44487) 사례를 살펴보세요. 이 취약점은 제로데이 공격으로 악용되어 당시 기록상 최대 규모의 DDoS 공격을 일으켰으며, HTTP/2가 활성화된 모든 Node.js 서버에 영향을 미쳤습니다. Node.js 18과 20은 며칠 내에 패치가 적용되었습니다. 만약 같은 취약점이 오늘날 발견되었다면, 두 버전 모두 Node.js 프로젝트 측에서 수정 패치를 받을 수 없었을 것입니다.
결코 패치되지 않을 CVE들
Node.js 보안 팀은 지원 종료(EOL)된 버전의 취약점을 평가하거나 수정하지 않습니다. 2025년 1월, 프로젝트 팀은 취약점 스캐너가 이를 명확히 파악할 수 있도록 다음과 같은 CVE를 등록했습니다. CVE-2025-23087를 발행하여 Node.js 17 및 그 이전 모든 버전을 포괄하는 포괄적 CVE를 지정하고, Node.js 19 및 21에 대한 별도의 CVE를 함께 부여함으로써 취약점 스캐너가 이를 명확히 인식할 수 있도록 했습니다. 그러나 CVE 프로그램은 이 세 가지 CVE를 모두 거부했습니다. 새로운 정책은 더 광범위합니다. 이제 모든 새로운 Node.js CVE는 기본적으로 EOL 릴리스 라인을 포함하며, 프로젝트 측에서 특정 버전에 적용되지 않는다는 구체적인 정보를 제시하는 경우를 제외하고는 예외가 없습니다.
따라서 Node.js 18과 20은 포괄적인 지원 종료(EOL) 공지에서 명시적으로 언급되지는 않지만, 이후 발표되는 모든 공지의 영향을 받는 것으로 간주됩니다. 프로젝트 측이 밝힌 이유는 자원 부족 때문입니다. 20개가 넘는 지원 종료 버전이 존재하며, 각 버전은 서로 다른 종속성과 빌드 프로세스를 가지고 있고, OpenSSL과 같은 구성 요소에 따라 취약점이 다르게 나타나는 상황에서 포괄적인 평가를 수행하는 것은 불가능합니다. 따라서 해당 버전에서 발견된 취약점은 평가되지도 수정되지도 않은 채로 남게 됩니다.
규정 준수 관련 위험 신호
감사관들은 다른 경로를 통해 동일한 결론에 도달합니다. PCI DSS 4.x 요구사항 6.3.3은 자체 위험 등급 평가 절차를 통해 식별된 중대한 취약점에 대한 패치를 출시 후 1개월 이내에 설치할 것을 요구하지만, 패치가 존재하지 않는 상황에서는 어떤 절차로도 이를 충족할 수 없습니다. SOC 2의 보안 기준은 정상적으로 작동하는 취약점 관리 프로세스가가 정상적으로 작동하고 있음을 전제로 하며, 패치 소스가 없는 소프트웨어의 경우 이를 입증하기 어렵습니다. 연방 정부 및 규제 대상 워크로드의 경우, 유지보수가 이루어지지 않는 런타임 환경은 누군가 구체적인 CVE에 대해 묻기도 전에 그 자체로 문제점으로 지적될 수 있습니다.
숨겨진 위험: Node.js의 번들링된 종속성 트리
경험이 풍부한 팀조차도 놀라게 하는 점은 바로 이것입니다. Node.js는 단순히 Node.js 그 자체만이 아닙니다. 이 프로젝트의 의존성 문서 에는 소스 트리 내에 30개의 구성 요소가 나열되어 있으며, 그중 약 25개가 모든 공식 Node.js 바이너리에 포함되어 있습니다. 여기에는 V8 자바스크립트 엔진, libuv 이벤트 루프, llhttp HTTP 파서, undici HTTP 클라이언트, nghttp2, nghttp3, HTTP/2 및 HTTP/3용 ngtcp2, c-ares DNS 리졸버, 압축을 위한 zlib, brotli, zstd, ICU, SQLite, npm 자체, 그리고 Node가 자체적으로 포함하고 있는 OpenSSL이 포함됩니다. (정확한 구성은 주요 버전에 따라 다릅니다. 예를 들어, Node.js 18과 20은 SQLite와 zstd가 번들로 포함되기 이전의 버전입니다.)
이러한 구성 요소들은 두 가지 그룹으로 나뉘며, 둘 다 EOL 이후에는 문제가 됩니다. 대략 절반은 시스템 라이브러리 형태로도 존재합니다: OpenSSL, zlib, SQLite, ICU, nghttp2, c-ares, libuv. 운영 체제는 시스템의 다른 부분에서 이러한 구성 요소에 대한 패치를 적용하지만, 공식 Node.js 바이너리(nodejs.org에서 제공하는 것, nvm과 같은 버전 관리 도구를 통해 설치된 것, 표준 Docker 이미지 등)는 자체 복사본으로 컴파일되므로 운영 체제 업데이트가 절대 적용되지 않습니다. (일부 리눅스 배포판 패키지는 대신 몇 가지 시스템 라이브러리를 링크하기도 하지만, 이는 예외적인 경우입니다.) V8, llhttp, undici, npm 등을 포함한 나머지 절반은 업스트림에서 유지 관리되지만, 사용자의 시스템 어디에도 시스템 패키지가 존재하지 않으므로, 업스트림 프로젝트의 수정 사항은 새로운 Node.js 빌드가 이를 포함할 때만 사용자에게 전달됩니다. 어느 쪽이든 결론은 동일합니다. 수정 사항은 새로운 Node.js 빌드를 통해서만 전달되거나 아예 전달되지 않으며, 릴리스 라인이 EOL(지원 종료)에 이르면 전체 소스 트리가 함께 동결됩니다.
이는 이론상의 취약점이 아닙니다. ‘Rapid Reset’은 HTTP/2 프로토콜 수준의 취약점으로, Node.js 팀은 직접 작성한 코드가 아닌 번들된 nghttp2를 통해 이를 해결했습니다. 2026년 7월 보안 릴리스에는 Node 자체 수정 사항과 함께 undici 및 llhttp 업데이트가 포함되었습니다. 지원되는 버전에서는 이러한 업데이트가 자동으로 적용됩니다. 지원 종료(EOL) 버전에서는 각 구성 요소가 해당 구성 요소에 적용되는 업스트림 CVE를 조용히 누적해 가지만, 수정 사항을 전달할 경로는 없습니다.
진정한 의미의 장기 지원 옵션이라면 이 모든 영역을 포괄해야 합니다. 바로 이 때문에 TuxCare의 ‘Endless Lifecycle Support(ELS)’는 Node.js 코어뿐만 아니라 번들된 종속성 트리까지 패치합니다.
Node.js 지원 종료(EOL) 이후의 선택지
세 가지 실제적인 길이 있으며, 어떤 길이 올바른지는 현재 여러분이 얼마나 많은 이주 관련 위험을 감당할 수 있는지에 달려 있습니다:
- 이번 분기에는 업그레이드할 수 없지만 최신 패치를 계속 적용해야 하나요? 연장 지원 서비스를 이용하세요.
- 엔지니어링 리소스와 호환되는 종속성 체인이 확보되어 있나요? 지원되는 LTS 버전으로 업그레이드하세요.
- Node.js가 스택에서 차지하는 비중이 작거나 점점 줄어들고 있나요? 그렇다면 이 기회에 Node.js에서 벗어나는 것을 고려해 보세요.
Node.js용 ‘Endless Lifecycle Support’를 활용하세요
코드베이스를 건드리지 않고 당면한 위험을 즉시 제거할 수 있는 가장 빠른 방법은 공급업체가 지원하는 패치 적용입니다. TuxCare의 Node.js용 ELS 는 Node.js 12, 14, 16, 18 및 20에 대한 지속적인 보안 수정 사항을 제공합니다. 패치는 업스트림에서 백포트되어 무결성 및 회귀 테스트를 거친 후 서명되며, SLA가 보장되고 사용자가 이미 사용하고 있는 패키지 관리자를 통해 제공됩니다. TuxCare는 OpenJS 재단의 생태계 지속 가능성 프로그램의 파트너로서 이 서비스를 제공하며, Node.js 프로젝트의 공식 EOL 페이지에 상업용 지원 제공업체로 등재되어 있습니다.
이 서비스에는 OpenSSL부터 undici에 이르기까지 앞서 설명한 번들 종속성 트리가 추가 비용 없이 포함됩니다. Node.js의 최신 취약점 및 수정 내역은 TuxCare CVE 트래커 에서 Node.js의 실시간 취약점 및 수정 내역을 확인하여 정확히 어떤 부분이 패치되고 있는지 파악할 수 있습니다.
이것이 어떤 역할을 하는지 명확히 하자면, 이는 ‘도착지’가 아니라 ‘다리’와 같습니다. ELS는 EOL이 빼앗아 가는 것을 되찾아 줍니다. 즉, 규정 위반이나 감사 압박에 시달리지 않고, 여러분이 원하는 조건에 따라 업그레이드를 계획할 수 있는 시간을 확보해 주는 것입니다.
지원되는 LTS 버전으로 업그레이드
깔끔한 장기적 해결책입니다. Node.js 24는 수년간의 성능 개선 작업 결과물과 최신 V8 기능을 제공하며, 2028년 4월 30일까지 지원됩니다. Node.js 22도 여전히 지원되지만, 지원 기간이 2027년 4월 30일까지로 제한되어 있어 최종 목적지라기보다는 중간 경유지에 가깝습니다. 의존성 구조가 건전하고 테스트 커버리지가 적정 수준이라면, 메이저 버전 하나를 건너뛰는 업데이트도 대개 무리 없이 진행할 수 있습니다.
하지만 이 작업에 드는 노력은 거리와 코드베이스의 복잡성에 비례합니다. 각 메이저 버전에는 호환성을 깨는 변경 사항이 포함되며, 네이티브 애드온은 새로운 ABI에 맞춰 재빌드해야 하고, 수년 전에 고정된 패키지에는 호환되는 릴리스가 없을 수도 있습니다. 18에서 24로 넘어가는 것은 단순한 한 번의 마이그레이션이 아니라, 세 번의 마이그레이션이 겹쳐진 것입니다.
다른 기술로 전환하기
어차피 서비스를 재구현해야 할 시점이라면, EOL은 조직이 현재 전략적이라고 판단하는 방향으로 통합하는 계기가 될 수 있습니다. 그것이 Deno나 Bun과 같은 다른 런타임이든, 아니면 완전히 다른 언어이든 상관없습니다. 이러한 유연성은 분명하지만, 그에 따른 비용도 만만치 않습니다. 마이그레이션은 서비스의 기능 대부분을 재구현해야 함을 의미하며, 이에 따른 철저한 테스트 부담도 수반됩니다. EOL 자체만을 이유로 이를 선택하는 것은 거의 합리적이지 않습니다.
서둘러 업그레이드를 진행할 때의 위험성
Node.js의 메이저 버전 업그레이드는 단순한 의존성 버전 업데이트가 아닌 하나의 프로젝트입니다. 이는 호환성을 깨는 API 변경 사항에 맞춰 코드를 수정하고, 전체 락 파일 전반에 걸친 호환성을 검증하며, 네이티브 모듈을 재컴파일하고, CI 이미지, Dockerfile 및 빌드 툴체인을 업데이트하며, 런타임과 관련된 모든 요소에 대해 회귀 테스트를 수행해야 함을 의미합니다.
대개 감사나 공개된 CVE로 인해 어쩔 수 없이 해당 작업을 긴급 상황으로 몰아가는 팀들은, 그 대가를 나중에 치르게 되는 경향이 있습니다. 테스트가 충분히 이루어지지 않은 경로로 인한 운영 불안정, 지원 업무량의 급증, 임시 방편으로 도입되었다가 기술적 부채로 굳어버리는 해결책, 그리고 예산에 전혀 반영되지 않았던 예상치 못한 비용 등이 바로 그것입니다. 이러한 패턴은 매우 빈번하게 나타나기 때문에, 강제 업그레이드 상황을 피하는 것 자체가 하나의 보안 전략이 됩니다. 마감 기한의 압박과 신중한 엔지니어링은 양립할 수 없습니다.
TuxCare를 통해 EOL 이후에도 Node.js 보안 유지하기
TuxCare는 10년 넘게 엔터프라이즈급 취약점 패치 분야의 전문성을 구축해 왔으며, 현재 금융 서비스, 통신, 의료, 정부 기관 등 2,300여 곳의 기업 고객에게 백포트된 수정 프로그램을 제공하고 있습니다. 이 이 패치 프로세스는 는 자동화된 취약점 모니터링, 패치 평가, 백포팅 과정을 전문가의 검증과 결합하며, 모든 릴리스는 검증된 소스 코드를 기반으로 빌드되고 서명되며, 의존성에 대한 보증서가 함께 제공됩니다.
Node.js의 경우, 이는 애플리케이션이 실제로 실행되는 버전에 대한 지속적인 보안 패치, 안정성 및 감사 증거로 이어집니다. 즉, 번들된 종속성 지원, 기존 패키지 관리자를 통해 제공되는 수정 사항, 그리고 계획되지 않은 마이그레이션 비용의 극히 일부에 불과한 가격을 의미합니다. 자세히 알아보기 Node.js용 ELS를 살펴보거나, CVE 트래커 를 통해 Node.js의 실시간 취약점 및 수정 사항을 확인해 보세요.
