Node.js 18 지원 종료 및 마이그레이션 옵션

주요 내용

• Node.js 18은 2025년 4월 30일에 지원 종료되었으며, 더 이상 Node.js 프로젝트 측에서 보안 업데이트나 버그 수정 패치를 제공받지 않습니다.
• 이 프로젝트는 보안 업데이트가 출시될 때마다 지원 종료된 모든 릴리스 라인을 영향을 받는 것으로 간주하므로, Node.js 18의 패치되지 않은 취약점 수는 사용자의 일정이 아닌 프로젝트의 일정에 따라 점차 늘어납니다.
• 현재 Node.js 24가 유일하게 활성 LTS 버전입니다. Node.js 22는 이미 유지보수 LTS 단계에 있으며, 2027년 4월 30일에 지원이 종료되므로 마이그레이션 대상으로는 적합하지 않습니다.
• TuxCare의 ‘Endless Lifecycle Support’ Node.js 18에 알려진 취약점에 대한 패치를 지속적으로 적용해 주며, 팀은 현실적인 속도로 마이그레이션을 계획하고 테스트할 수 있습니다.

지원 종료된 런타임을 의도적으로 선택하는 사람은 거의 없습니다. 팀들이 결국 그런 상황에 처하게 되는 이유는, 업그레이드 요청이 출시 작업에 계속 밀려나고, 겉보기에는 아무런 문제가 없어 보이기 때문입니다. Node.js 18은 2025년 4월 30일—1년 이상 전—에 지원이 종료되었으며, 그 이후로 Node.js 프로젝트 측으로부터 보안 패치, 버그 수정 또는 공식 지원을 전혀 받지 못하고 있습니다.

팀들을 곤란하게 만드는 부분은 바로 이 계산 문제입니다. Node.js 프로젝트 측의 입장은, 누군가가 재테스트를 하든 안 하든 상관없이 보안 업데이트가 출시될 때마다 지원 종료된 제품군도 영향을 받는다는 것입니다. 따라서 프로젝트 측이 여러분이 통제할 수 없는 주기로 보안 권고문을 발표할 때마다, 패치가 적용되지 않은 취약점의 범위는 점점 더 넓어지게 됩니다.

이 가이드에서는 Node.js 18의 지원 종료(EOL) 일정을 다루며, 2026년에 실제로 어떤 버전을 목표로 삼아야 하는지(아마도 뻔한 선택지는 아닐 것입니다)와, 이번 분기 내에 마이그레이션을 완료하지 못할 경우 어떻게 패치를 계속 적용받을 수 있는지에 대해 설명합니다.

Node.js 18 지원 종료 이해하기

Node.js 릴리스 실무 그룹이 실제로 지원을 어떻게 구성하는지 알아두면 도움이 됩니다. 지원 단계는 세 가지가 있으며, 지원 종료는 릴리스 라인이 이 세 단계를 모두 마친 후 도달하는 상태입니다.

현재: 새로운 메이저 릴리스는 약 6개월 동안 'Current' 라인에 유지되며, 이 기간 동안 라이브러리 개발자들은 해당 릴리스에 대한 지원을 추가할 시간을 갖게 됩니다. 프로젝트의 지침에 따르면, 실제 운영 환경의 애플리케이션은 Active LTS 또는 Maintenance LTS 릴리스만 사용해야 합니다.

활성 LTS: 약 6개월이 지나면 짝수 버전 릴리스는 약 12개월 동안 '활성 LTS'로 승격됩니다. 이 단계는 긴급 수정 사항뿐만 아니라, 릴리스 팀이 검토하여 해당 라인에 적합하고 안정적이라고 판단한 새로운 기능, 버그 수정 및 업데이트까지 포함합니다. 홀수 버전 라인은 절대 승격되지 않기 때문에, 23과 25 버전은 LTS 단계를 거치지 않고 '현재' 상태에서 바로 지원 종료로 넘어갔습니다.

유지보수: LTS 기간이 종료된 후에는 약 18개월간의 유지보수 기간이 이어지며, 이 기간에는 중대한 버그 수정 및 보안 업데이트만 제공됩니다. 새로운 기능은 극히 드물게 추가되며, 일반적으로 후속 버전으로의 마이그레이션을 돕는 경우에만 제공됩니다.

즉, 최초 출시부터 지원 종료까지 약 36개월이 소요되며, 이 중 약 30개월은 LTS 지원 기간에 해당합니다.

사전에 대비해 두어야 할 변경 사항이 하나 있습니다. 바로 이 홀수/짝수 모델이 Node.js 26까지만 적용된다는 점입니다. Node.js 27부터는 연간 단일 메이저 릴리스 체제로 전환되며, 모든 메이저 릴리스는 ‘Current’ 단계가 끝난 후 LTS로 승격됩니다. 현재 목표 버전을 선정하고 있다면, 버전 번호보다 단계가 더 중요합니다. 이미 ‘Maintenance’ 단계에 있는 버전은 아무리 최신처럼 보여도 곧 지원이 종료될 예정이기 때문입니다.

Node.js 18 지원 종료: 주요 일정

Node.js 18(코드명 Hydrogen)은 2022년 4월 19일에 출시되었습니다. 이 버전은 2022년 10월 25일에 ‘Active LTS’ 단계에 진입했고, 2023년 10월 18일에 ‘유지보수’ 단계로 전환되었으며, 2025년 4월 30일에 지원 종료 시점에 도달합니다.

 

어디서부터 시작해야 할까요: 무엇을 계획하기 전에 실제로 어떤 버전이 실행 중인지 확인하세요. 대부분의 환경에서는 단일 버전이 사용되지 않기 때문입니다. 각 호스트에서 `node -v` 명령어를 실행한 후, Dockerfile, CI 이미지, 그리고 Lambda, App Runner 또는 사용 중인 플랫폼의 관리형 런타임 설정을 모두 확인하세요.

Node.js 18의 지원 종료 후 발생할 수 있는 위험

Node.js 18의 지원 종료 이후에도 바로 다음 날부터 운영에 차질이 생기는 것은 아니기 때문에, 시스템들이 그대로 유지되는 것입니다. 모든 것이 계속 실행되고, API도 여전히 응답하며, 누구에게도 알림이 전송되지 않습니다.

변화된 점은 취약점이 계속 발견되고 있음에도 수정 패치가 더 이상 제공되지 않게 되었다는 것입니다. 아래에 언급된 위험 요소들은 누적되며, 이 모든 위험 요소는 사고 발생 시보다 계획된 업그레이드 기간에 처리하는 것이 비용이 훨씬 적게 듭니다. Node.js 18은 지원 기간 동안 다른 유지 관리 중인 버전들과 마찬가지로 보안 패치를 제공받았습니다. 이러한 릴리스는 2025년 4월에 중단되었으며, Node.js 프로젝트는 이에 대한 추가 수정 패치를 더 이상 제공하지 않을 예정입니다.

CVE 노출 증가

이 프로젝트의 공식 입장은 내부적으로 해당 작업을 정당화해야 할 때 유용한 근거가 됩니다. 보안 패치가 출시될 때마다 지원 종료(EOL) 버전은 항상 영향을 받기 때문입니다. Node.js는 EOL 버전에 대해 재테스트를 진행하지 않기 때문에, 보안 권고 사항에는 지원되는 버전만 나열되어 있습니다. 하지만 취약점이 있는 코드 경로는 여전히 18 버전에 남아 있으며, 이에 대한 공식 패치는 제공되지 않을 예정입니다.

2026년 1월 13일자 보안 업데이트가 이를 잘 보여줍니다. 이 업데이트는 지원 대상 제품군 전반에 걸쳐 8건의 취약점을 수정했으며, 그중에는 다음 4건이 포함됩니다:

• CVE-2025-55131 (높음) – 타임아웃에 기반한 경합 조건으로 인해 Buffer.alloc 및 타입화된 배열이 0으로 채워지지 않아 초기화되지 않은 메모리가 노출됩니다. 실행 타임아웃이 발생하는 vm 모듈을 통해 접근 가능하며, 이는 반신뢰 코드(semi-trusted code)가 실행되는 환경에서 가장 큰 문제가 됩니다.
• CVE-2025-59465 (높음) – 유효하지 않은 HPACK 데이터를 포함하는 잘못된 형식의 HTTP/2 HEADERS 프레임이 처리되지 않은 TLS 소켓 오류를 유발하여 프로세스를 중단시킵니다.
• CVE-2025-59466 (중간) – async_hooks가 활성화된 상태에서 “최대 호출 스택 크기 초과” 오류가 process.on(‘uncaughtException’)을 우회하여 처리되지 않게 됩니다. 이 문제의 영향 범위는 처음 보이는 것보다 더 광범위합니다. AsyncLocalStorage는 async_hooks를 기반으로 구축되었기 때문에 Next.js, React Server Components 및 대부분의 APM 에이전트가 이 문제의 영향을 받습니다.
• CVE-2026-21637 (중간) – TLS PSK 또는 ALPN 콜백에서 발생된 예외가 오류 처리기를 우회하여 서비스 거부 및 파일 디스크립터 누수를 유발합니다.

해당 수정 사항은 20.20.0, 22.22.0, 24.13.0 및 25.3.0 버전에 포함되었습니다. 18.x 버전에는 이에 상응하는 수정 사항이 없으며, 앞으로도 추가되지 않을 예정입니다.

도구 관련 참고 사항: Node.js 프로젝트에서는 설치된 버전을 Node.js 보안 데이터베이스와 비교하는 is-my-node-vulnerable 패키지를 관리하고 있습니다. npx is-my-node-vulnerable 명령어를 실행해 보세요. 단, 지원 종료(EOL) 런타임 환경에서는 동작 방식이 다르다는 점을 유의하십시오. 개별 CVE를 나열하는 대신, 해당 버전이 지원 종료 상태임을 보고하며, 지원 종료된 버전은 최신 보안 릴리스와 연동되어 추적되지 않기 때문에 기본적으로 취약한 것으로 간주합니다. TuxCare가 지원하는 버전에 대한 CVE별 세부 정보 및 패치 상태를 확인하려면 CVE 트래커를 사용하십시오.

 

규정 준수 실패

EOL 런타임이 그 자체만으로 감사에서 불합격 판정을 받는 경우는 거의 없습니다. EOL 런타임이 하는 역할은 PCI DSS, HIPAA, GDPR, 그리고 ISO 27001은 일반적으로 알려진 취약점을 파악하고 정해진 기한 내에 이를 시정할 것을 요구합니다.

PCI DSS는 시한에 대해 가장 구체적으로 규정하고 있습니다. 요구사항 6.3.3은 중요한 보안 패치를 출시 후 1개월 이내에 설치할 것을 요구합니다. 상위 프로젝트에서 해당 런타임에 대한 패치 제공을 중단한 경우, 패치를 통해 이 요구사항을 충족할 수 없으므로 대신 보완 통제 조치를 입증해야 합니다.

또한 사람들을 놀라게 하는 스캐너 관련 문제도 있습니다. Node.js 프로젝트는 이제 지원이 종료된 버전에 대해 직접 CVE를 발행하고 있으며, 이는 CWE-1104(유지보수되지 않는 타사 구성 요소 사용) 항목 하에 ‘지원되지 않음’으로 분류되어 등록됩니다. 따라서 Node.js 18은 개별 버그와는 별개로, 단순히 지원 종료(EOL) 상태라는 이유만으로 npm audit이나 Snyk와 같은 도구에서 문제점으로 표시될 수 있습니다.

감사 대상에 해당되는 경우: 지금 바로 방향을 정하십시오 – 시스템 업그레이드, 상용 패치 적용, 또는 문서화된 보완 통제 조치 중 하나를 선택하십시오. 이 세 가지 모두는 타당한 근거가 됩니다. 그러나 현장 조사 중에 이 중 어느 것도 갖추지 못한 사실이 드러난다면, 이는 타당하지 않습니다.

의존성 및 생태계 파손

현대적인 Node.js 애플리케이션은 방대한 의존성 구조에 의존하고 있으며, 이 구조는 예고 없이 변화합니다. 패키지, 프레임워크, 클라우드 서비스는 각자의 일정에 따라 구형 런타임을 지원 중단합니다. 예를 들어, AWS는 2025년 11월 30일 AWS Cloud Development Kit(CDK)를 통해 Node.js 18.x에 대한 지원을 종료했으며, 에서 Node.js 18.x에 대한 지원을 종료했으며, 여기에는 CDK CLI, construct 라이브러리, 그리고 JSII, Projen, CDK8s와 같은 관련 프로젝트가 포함됩니다.

이러한 패턴은 예상 가능한 일입니다. 새로운 패키지 버전이 출시되면 구버전 Node.js에 대한 지원이 중단되므로, 팀들은 시스템을 계속 가동하기 위해 버전을 고정하게 되고, 이렇게 고정된 버전도 결국 지원 대상에서 제외됩니다. 이 상태를 오래 유지할수록 기술적 부채가 쌓이게 되며, 결국 일상적인 업데이트를 수행하기 위해서도 먼저 런타임 업그레이드가 필요하게 됩니다.

예시: Node.js 18 API를 운영하는 팀이 로깅 라이브러리의 취약점을 패치해야 합니다. 수정된 릴리스는 Node.js 20 이상이 필요합니다. 런타임 업그레이드 일정이 잡혀 있지 않아, 팀은 취약점이 있는 버전을 계속 사용 중입니다. 패치는 존재하지만, 여전히 적용할 수 없는 상황입니다.

이것이 바로 EOL 리스크의 진정한 모습입니다. EOL 리스크는 대개 런타임 자체보다는 의존성 트리를 통해 발생합니다.

운영 리스크와 더 까다로워진 디버깅

지원 종료 후, Node.js 프로젝트는 해당 버전에 대한 버그 수정 및 기술 지원을 중단하며, 커뮤니티의 관심은 지원 대상 릴리스로 이동합니다.

이로 인해 사고 대응 방식에 특정한 변화가 생깁니다. 즉, 업스트림의 도움 없이 디버깅을 해야 한다는 것입니다. 실제 런타임 버그에 직면했을 때, 백포트된 수정 패치를 기다릴 수도 없고, 유지보수자의 우선순위 평가도 받을 수 없으며, 더 이상 거의 아무도 사용하지 않는 버전에 대한 커뮤니티 논의도 점차 줄어들기 때문입니다. 프로파일러, 디버거, APM 에이전트 역시 오래된 런타임을 지원하지 않기 때문에, 평소 사용하던 도구를 연결할 수 없을 수도 있습니다.

사전에 대비하세요: 당분간 18 버전을 계속 사용 중이라면, 런타임 수준의 모든 문제에 대해 해결까지 걸리는 시간이 더 길어질 것으로 예상하고, 사고 발생 중에 환경을 구축하는 번거로움을 피하기 위해 재현 가능한 18.x 디버그 환경을 미리 준비해 두십시오.

Node.js 18의 지원 종료에 따른 향후 선택지

Node.js 프로젝트에서 Node.js 18에 대한 지원을 중단함에 따라, 이제 각 팀이 스스로 결정을 내려야 합니다. 현 상태를 유지하는 것도 가능한 선택지 중 하나이지만, 이런 결정은 대개 어디에도 문서화되지 않는 경향이 있어 결과적으로 암묵적인 기본 선택으로 자리 잡게 됩니다.

	아무것도 하지 마라	지원되는 LTS 버전으로 업그레이드	확장 지원
사전 준비	낮음	높음	낮음
반복적인 노력	모니터링, 위험 승인, 감사 증거	전환 후에는 없음	낮음
보안 패치 적용	없음	공식적이고 현재 진행 중인	해당 취약점에 대해서는 지속적으로 진행 중입니다.
보안 위험	매번 업데이트될 때마다 발전합니다	최저	할인
기술적 부채	자라다	처리됨	여전히 자라고 있다
다음과 같은 경우에 가장 좋습니다	고립되어 있으며, 곧 폐쇄될 예정	이번 분기에는 여유가 있습니다	업그레이드는 2분기 이상 뒤처져 있다

아무것도 하지 마라

현 상태를 유지하는 것이 이번 분기에는 가장 저렴한 선택지이지만, 장기적인 관점에서 보면 가장 비용이 많이 드는 선택지입니다. 시스템이 안정적이고 문제가 없는 상황에서는 그대로 두려는 유혹이 강합니다.

반드시 잘못된 결정이라고만 볼 수는 없습니다. 진정으로 격리되어 있고, 규제 대상 데이터를 처리하지 않으며, 1~2분기 내에 자금이 확보된 폐쇄 일정이 정해진 서비스라면, 아예 마이그레이션할 가치가 없을 수도 있습니다.

이 결정이 잘못된 이유는 이를 ‘무료’라고 여기는 데 있습니다. 아무 조치도 취하지 않는다고 해도 취약점 모니터링, 위험 수용 승인, 감사 문서 작성 등의 비용이 발생하며, 문제가 실제로 발생했을 때 대응력이 약해집니다. 이러한 작업에 소요되는 시간은 실제로 존재하며, 반복적으로 발생합니다.

결정 사항: 해당 서비스가 인터넷에 노출되어 있거나 감사 대상인 경우, 이 옵션은 고려 대상에서 제외됩니다. 서비스가 격리되어 있고 폐기 예정인 경우, 위험 수용을 공식적으로 문서화한 후 더 유용한 업무로 넘어가십시오.

지원되는 LTS 버전으로 업그레이드

업그레이드는 문제를 단순히 관리하는 것이 아니라 근본적으로 해결할 수 있는 유일한 방법입니다. 2026년 8월 현재, 다음과 같은 옵션 중에서 선택하실 수 있습니다:

• Node.js 24 (Krypton) – 현재 LTS 버전이며, 2028년 4월 30일에 지원이 종료됩니다. 대부분의 팀이 주로 사용하는 기본 버전입니다.
• Node.js 22 (Jod) – 2025년 10월 21일부터 LTS 유지보수 단계에 있으며, 2027년 4월 30일에 지원이 종료됩니다. 중대한 버그 수정 및 보안 업데이트만 제공됩니다.
• Node.js 26 – 현재 Current 라인에 속해 있으며, 2026년 10월에 Active LTS로 승격될 예정이고, 지원 종료일은 2029년 4월 30일로 계획되어 있습니다.

 

이 목록에 숨겨진 함정을 주의하세요. Node.js 22는 보수적인 선택처럼 보이지만, 이미 Active LTS 기간이 끝났고 지원 기간이 1년도 채 남지 않았기 때문에, 18에서 22로 마이그레이션하면 2027년 4월 이전에 또다시 같은 작업을 반복해야 합니다. 의존성 트리에서 24로의 업그레이드를 구체적으로 막는 요소가 없는 한, 22로 가는 것은 그만한 노력을 들일 가치가 없습니다.

업그레이드를 수행하면 공식 보안 지원이 복원되고, 더 넓은 생태계가 여전히 지원하는 런타임 환경으로 돌아갈 수 있습니다. 다만, 이 작업이 단 하루 만에 끝날 수는 없습니다. 18에서 24로 업그레이드하는 과정에는 두 개의 LTS 라인과 여러 V8 주요 버전이 포함됩니다. 네이티브 모듈은 새로운 ABI에 맞춰 재컴파일해야 하고, node-gyp 빌드 및 사전 컴파일된 바이너리를 확인해야 하며, 공식 Linux 빌드에는 Node.js 18 빌드보다 최신 버전의 glibc가 필요합니다. 이는 베이스 이미지를 변경하지 않는 한 구형 배포판을 사용할 수 없게 만드는 충분한 이유입니다. CI에서 단순히 버전을 올리는 것보다는 스테이징 환경에서 전체 테스트 주기를 진행할 수 있도록 예산을 책정하십시오.

전문가 팁: Node.js 20은 건너뛰세요. 2026년 4월 30일에 지원 종료(EOL)가 예정되어 있으므로, 이 버전으로 전환하는 것은 지원이 중단된 또 다른 런타임으로의 측면 이동에 불과합니다. 2026년 10월 Node.js 26이 LTS(장기 지원) 단계에 진입한 후에 마이그레이션을 완료한다면, 26 버전이 계획된 지원 기간이 가장 길 것입니다. 이를 24 버전의 더 긴 운영 실적과 더 폭넓은 의존성 지원과 비교해 신중히 고려하십시오. 어느 쪽을 선택하든, 프로젝트 측에서 밝힌 일정은 변경될 수 있다는 점을 명심하십시오.

TuxCare의 끝없는 라이프사이클 지원

모든 시스템을 프로젝트 일정대로 업그레이드할 수 있는 것은 아닙니다. 긴 검증 주기, 변경 승인 절차, 인증된 스택, 그리고 공급업체가 제공하는 애플리케이션 등으로 인해 현실적인 완료 시점은 몇 주가 아니라 분기 단위로 미뤄지게 됩니다.

TuxCare의 TuxCare의 ‘Endless Lifecycle Support’를 통해 Node.js 18은 공식 지원 종료 후에도 지원 대상 취약점에 대한 보안 패치를 계속 받을 수 있습니다. 패치는 애플리케이션 코드 변경 없이 제공되므로, 당장 애플리케이션을 재인증할 수 없는 팀에게도 이 접근 방식이 실용적입니다. TuxCare는 Node.js 12, 14, 16, 18 및 20을 지원합니다.

이것을 최종 목표가 아닌 하나의 중간 단계로 여기세요. 이는 문제의 패치 및 취약점 관리 측면을 해결해 줍니다. 하지만 의존성 트리가 점점 더 복잡해지는 것을 막아주지도, 기술적 부채가 늘어나는 것을 막아주지도 않으며, 결국에는 업그레이드를 해야만 합니다.

결정 사항: 이번 분기 내에 현실적으로 업그레이드 버전을 출시할 수 있다면, 업그레이드를 진행하고 브리지 단계를 건너뛰십시오. 출시일이 2분기 이상 남았거나, 감사 대상에 포함되어 패치를 적용할 수 없는 경우에는 브리지 단계를 거쳐 마이그레이션 예산을 확보해 두십시오.

TuxCare로 Node.js 18 워크로드를 안전하게 보호하세요

Node.js 18 자체는 변하지 않았습니다. 다만 지원 상태가 달라졌을 뿐입니다. 2025년 4월까지만 해도 유지보수 대상이었던 동일한 바이너리가 이제는 애플리케이션의 기반이 되는 가장 오래된 비유지보수 구성 요소가 되었으며, 프로젝트에서 보안 업데이트를 배포할 때마다 패치되지 않은 새로운 취약점을 그대로 떠안게 됩니다.

어색한 점은, 명백해 보이는 해결책에 잘못된 답이 내재되어 있다는 것입니다. Node.js 22는 18에서 직관적으로 업그레이드할 수 있는 버전이며, 시간을 가장 적게 절약해 주는 버전입니다. Node.js 24는 대부분의 팀에게 적합한 목표 버전이지만, 마이그레이션에 더 많은 노력이 필요한 버전이기도 합니다. 쉬운 답과 올바른 답 사이의 바로 그 간극이, 바로 확장 지원이 그 가치를 발휘하는 지점입니다.

즉시 도입할 수 없는 조직의 경우, Node.js를 위한 무제한 라이프사이클 지원 는 애플리케이션 코드를 변경할 필요 없이, 마이그레이션을 적절히 계획하고 테스트하는 동안 Node.js 18 워크로드에 대한 알려진 취약점에 대한 패치를 지속적으로 제공합니다.

아직 Node.js 18을 사용 중이라면, 이번 분기 내에 업그레이드, 브리지, 또는 문서화된 위험 수용 중 하나를 선택하십시오. 미루면 미룰수록 비용이 더 많이 드는 유일한 선택지는 ‘아무것도 선택하지 않는 것’입니다.

Node.js 18 지원 종료에 관한 자주 묻는 질문