유지보수 담당자 제임스 스넬이 설명하는 Node.js 지원 종료

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

주요 내용

Node.js 버전이 지원 종료(EOL)에 도달하면, 업스트림에서는 해당 버전에 새로운 취약점이 영향을 미치는지 여부를 더 이상 확인하지 않습니다.
Node.js 27부터 이 프로젝트는 1년에 한 번씩 주요 버전을 출시하며, 모든 릴리스 라인이 LTS가 됩니다.
AI 도구가 실제 Node.js 버그를 찾아내고 있지만, 중복 보고가 쏟아지면서 버그 분류 작업을 담당하는 자원봉사자들이 업무에 파묻히고 있다.
일정에 맞춰 업그레이드할 수 없는 팀은, 아무런 정보가 유출되지 않기를 바라는 대신 패치된 런타임이 필요합니다.

Node.js 애플리케이션은 버전의 지원 종료 시점이 되어도 실행이 중단되지 않습니다. 단지 업스트림 프로젝트 측에서 더 이상 해당 버전을 관리하지 않을 뿐입니다. Node.js 기술 운영 위원회(Technical Steering Committee) 위원인 제임스 스넬(James Snell)이 최근 TuxCare와의 파이어사이드 채팅에서 설명했듯이, 이 차이는 겉으로 보이는 것보다 훨씬 큽니다.

“이전 버전으로의 적용도, 수정도 없다”고 그는 말했다. 새로운 취약점 보고가 접수되면, 팀은 해당 취약점이 지원 종료(EOL)된 제품 라인에 영향을 미치는지조차 테스트하지 않는다. 프로덕션 환경에서는 서비스가 완벽하게 정상적으로 작동하는 것처럼 보일 수 있지만, 업스트림에서 진행 중인 보안 작업은 해당 서비스를 제외하고 조용히 다음 단계로 넘어간 상태일 수 있다.

이는 스넬이 TuxCare의 수석 개발자 옹호자 크리스 드마르스와 대담을 나눈 “Keepers of the Runtime”에서 나온 여러 솔직한 순간 중 하나였습니다. 슬라이드도, 제품 시연도 없었습니다. 두 사람은 Node.js가 왜 연간 1회 주요 릴리스로 전환하고 있는지, AI가 생성한 보안 보고서가 자원봉사 보안 팀에 어떤 영향을 미치고 있는지, 그리고 겉보기에는 평범해 보이는 보안 업데이트 뒤에 얼마나 많은 사람의 노력이 숨어 있는지 등에 대해 논의했습니다. Node.js를 프로덕션 환경에서 운영 중이라면 다음 내용이 가장 중요하지만, 30분 정도 시간을 내어 전체 영상을 시청해 볼 가치가 있습니다.

Node.js의 지원 종료는 업스트림 보안 작업의 종말을 의미한다

스넬은 지원 종료에 대해 직설적으로 설명했다. 주요 버전의 지원이 종료되면, 그 버전에는 더 이상 어떤 업데이트도 제공되지 않는다. 보안 패치도, 일반적인 버그 수정도, 최신 브랜치에서 가져온 백포트도 없다. 그는 새로운 보고 사항에 대해 구버전을 테스트하는 것에 대해 “다른 사람들은 그럴지 모르겠지만, 우리는 하지 않을 것”이라고 말했다. “지원 종료가 되면, 우리는 더 이상 신경 쓰지 않는다.”

이 프로젝트의 EOL(지원 종료) 취약점에 대한 자체 지침도 같은 기준을 제시합니다. 오래된 릴리스가 유지 관리 중인 버전에서 공개된 취약점의 영향을 받을 가능성은 충분히 있지만, 업스트림 측은 일반적으로 오래된 브랜치를 조사하여 영향을 확인하지 않으며, 수정 패치를 제작하는 것은 더더욱 없습니다.

이것이 여러분의 스캐너에 어떤 의미인지 생각해 보세요. 2025년부터 새로운 Node.js CVE 목록에서는 프로젝트 측에서 별도로 확인되지 않는 한, EOL 라인이 기본적으로 영향을 받는 것으로 표시됩니다. 이로 인해 경고는 계속 표시되지만, 업스트림 측에서는 여러분의 버전에 해당 결함이 있는지 확인한 사람이 없으며, 수정 패치를 개발 중인 사람도 없습니다.

EOL 런타임도 고립되어 존재하는 것은 아닙니다. Node.js는 V8이나 OpenSSL과 같은 구성 요소를 번들로 포함하고 있으며, 스넬은 V8의 제로데이 취약점이 샌드박스 탈출을 포함해 끊임없이 발견되고 있다고 지적했습니다. 모든 브라우저 측 V8 결함이 Node.js에 영향을 미치는 것은 아니지만, 어떤 결함이 영향을 미치는지 파악해야 할 누군가가 필요하며, EOL 상태의 제품 라인에서는 그 역할을 상류 개발자가 맡지 않습니다. 한편, 라이브러리와 툴링은 구형 Node.js 버전에 대한 지원을 계속 중단하고 있으므로, 업그레이드를 미룰수록 매달 상황이 더 어려워집니다.

그렇다고 해서 모든 EOL 배포 환경이 자동으로 악용될 수 있는 것은 아닙니다. 취약성에 대한 노출 여부는 구체적인 취약점, 구성, 그리고 실행 가능한 코드 경로에 따라 달라집니다. EOL에 도달하면 상류 개발팀의 지원과 패치 제공이 중단되며, 이로 인해 선택의 폭이 좁아지는 바로 그 시점에서 팀이 수행해야 할 조사 작업이 더 많아지게 됩니다.

‘업스트림’이 이전 버전을 더 오래 유지하지 않는 이유

사람들은 상류 프로젝트 측에 구버전을 조금 더 오래 유지해 달라고 요청하기도 합니다. 이에 대한 답은 결국 사람과 기계의 문제로 귀결됩니다. Node.js는 주로 자원봉사자들에 의해 유지 관리되고 있습니다. 소수의 기여자들은 후원을 받고 있지만, 스넬의 설명에 따르면 릴리스, 백포트, 기여를 하는 거의 모든 사람이 개인 시간을 할애해 이를 수행하고 있습니다. “우리는 모든 것을 영원히 무조건 지원할 수는 없습니다.”라고 스넬은 말했습니다. “그럴 수 없어요. 불가능한 일이니까요.”

그리고 CI도 있습니다. 스넬에 따르면, 전체 CI 실행은 약 55개의 플랫폼, 아키텍처, OS 조합을 다루며, 각 조합당 약 7,800건의 테스트가 수행되고, 한 번의 실행에 최대 1시간이 소요될 수 있습니다. 기업들은 이러한 인프라를 기증하며, 그 용량은 고정되어 있습니다. 이 수치를 모든 구버전 릴리스 라인에 곱해 보면, 계산이 금세 맞지 않게 됩니다. 스넬이 말한 대로, “지원 종료가 지원 종료인 이유는, 물리적으로 이를 유지 관리할 자원을 할당할 수 없기 때문입니다.”

그건 타당한 입장입니다. 반박하기 어렵죠. 하지만 그로 인해 공백이 생기게 되는데, 그 공백은 여전히 구버전을 사용하는 사람들에게 돌아갑니다.

Node.js가 왜 1년에 한 번의 주요 릴리스로 전환하고 있는가

이러한 용량 문제가 바로 새로운 릴리스 일정의 배경이 됩니다. 기존 일정은 io.js 재통합 과정에서 타협의 산물이었습니다. 즉, 라이브러리 및 프레임워크 개발자들이 향후 계획을 파악할 수 있도록 약 8개월 정도만 지원되는 단기적인 홀수 버전 릴리스와, 기업을 위한 LTS(장기 지원) 버전이 되는 짝수 버전 릴리스로 구성되어 있었습니다.

10년간의 다운로드 데이터는 사뭇 다른 사실을 보여주었다. “사실 단기 릴리스 버전을 사용하는 사람은 아무도 없었다”고 스넬은 말했다. 기업들은 이미 1년에 한 번 정도, 그마저도 간신히 업그레이드하고 있는 실정이었다. 한편, 유지보수 담당자들은 때때로 4~5개의 활성 릴리스 라인을 동시에 관리해야 했으며, 모든 보안 수정 사항은 각기 다른 방향으로 분기된 브랜치를 통해 추적해야 했다.

공식 Node.js 릴리스 계획에 따르면, Node.js 27은 새로운 모델의 첫 번째 릴리스 라인입니다. 매년 4월에 한 번의 주요 릴리스가 이루어지며, 그해 10월에 LTS로 승격되므로 모든 릴리스 라인은 결국 LTS가 됩니다. 알파 채널이 과거 홀수 릴리스가 담당하던 초기 테스트 역할을 대신하게 되며, 알파 단계에서 6개월이 지난 후 각 라인은 첫 번째 'Current' 릴리스부터 지원 종료 시점까지 36개월 동안 지원을 받게 됩니다. 스넬이 제시한 이점의 요지는 간단했습니다. 관리해야 할 라인 수가 훨씬 줄어들어, 한 번에 약 세 개 정도만 진행 중으로 남게 된다는 것입니다.

출시 라인	알파 시작	첫 출시	LTS로 전환	Lifecycle 종료
Node.js 26 (구 버전의 마지막 버전)	해당 없음	5월 2026	10월 2026	4월 2029
Node.js 27	10월 2026	4월 2027	10월 2027	4월 2030
Node.js 28	10월 2027	4월 2028	10월 2028	4월 2031

팀에서 이미 LTS 릴리스만 배포하고 있다면, 버전 번호 외에는 별다른 변화가 없습니다. Node.js로 제품을 개발하는 경우, 스넬은 4월이 되어서야 무엇이 고장 났는지 확인하려고 기다리지 말라고 조언했습니다. 주요 변경 사항과 사용 중단 예정 기능은 main 지속적으로. 병합을 방해하지 않으면서 곧 출시될 알파 빌드를 대상으로 실행되는 스모크 테스트 작업을 CI에 추가하고, 누군가가 그 결과를 실제로 검토하도록 하세요. 알파 빌드는本番 환경에 사용하기 위한 것이 아니지만, 3~4개월 앞서 문제를 발견하는 것이 마이그레이션 기간 중에 문제를 발견하는 것보다 훨씬 비용이 적게 듭니다.

Node.js 보안 보고서가 발표된 후 수정 사항이 적용되기까지의 과정

Node.js는 HackerOne을 통해 취약점 제보를 접수합니다. 트라이어저는 먼저 해당 현상이 실제 발생하는지 확인한 뒤, 프로젝트의 위협 모델에 정의된 보안 경계를 위반하는지 여부를 판단합니다.

두 번째 판단 기준은 간과하기 쉽습니다. Node의 신뢰 모델은 매우 단순합니다. 코드가 실행된다면 신뢰할 수 있는 것입니다. 로컬에서 직접 코드를 실행해야만 유발할 수 있는 세그폴트는 대개 일반적인 버그이며, 공개적으로 수정됩니다. 반면, 원격 코드 실행이나 원격 서비스 거부 공격처럼 신뢰할 수 없는 원격 입력을 통해 접근 가능한 것은 취약점으로 간주됩니다.

이러한 수정 사항은 Node의 비공개 포크에서 개발, 검토 및 적용되며, 보안 릴리스는 이곳에서 생성됩니다. 해당 릴리스가 배포된 후에야 변경 사항이 공개 저장소로 이동합니다. 이를 통해 지원 대상 라인의 경우 취약점 공개와 패치 제공 사이의 시간 차이를 거의 제로에 가깝게 유지할 수 있지만, 동시에 보안 권고문이 공개되는 순간부터 사용자에게는 이미 시간이 촉박해지기 시작한다는 의미이기도 합니다. 2026년 10월 21일 릴리스가 좋은 예입니다. 22.x, 24.x, 26.x 계열에 걸쳐 10개의 CVE가 발견되었으며, 그중 4개는 ‘High’ 등급으로 평가되었습니다. TuxCare의 “10개의 Node.js CVE, Brotli RCE, 그리고 사용 중인 버전이 EOL인 경우의 대처법”은 EOL(지원 종료) 계열을 사용하는 모든 사용자에게 이것이 무엇을 의미하는지 상세히 설명합니다. 다음 보안 업데이트도 이미 예정되어 있습니다. Node.js는 2026년 11월 11일 또는 그 직후에 또 다른 보안 업데이트를 발표할 예정이며, 이번에도 22.x, 24.x, 26.x 버전을 대상으로 하며 가장 심각한 취약점은 ‘High’ 등급으로 평가되었습니다. 해당 보안 권고문은 보안 업데이트가 발생할 때마다 EOL 버전이 항상 영향을 받는다고 명시하고 있습니다.

AI가 실제 버그를 찾아내며 트라이아지 대기열을 넘쳐나게 하고 있다

스넬이 가장 열정적으로 이야기한 부분이 바로 이 대목이었다. AI 기반 스캔 기술은 효과가 있다. “이 기술은 확실히 실제 버그를 찾아내고 있습니다”라고 그는 말했다. 정확도는 주요 문제가 아니다. 문제는 처리량이다.

비슷한 도구를 사용하는 연구자들은 대개 같은 시점에 같은 버그를 발견하고, 서로 독립적으로 이를 제보하는 경향이 있습니다. 스넬은 한 가지 문제에 대해 10건에서 20건의 보고를 받았으며, 수정 작업이 진행되는 동안에도 계속해서 보고가 들어왔고, 공개 후에도 오랫동안 소량씩 보고가 이어졌다고 설명했습니다. 최근 한 차례의 분류 작업 기간 동안 그는 “보고된 내용 10건 중 9건은 중복이었을 것”이라고 추정했는데, 이는 측정된 비율이 아니라 당시 업무량을 바탕으로 한 추정치입니다.

OpenJS 재단의 2026년 2분기 보안 업데이트는 이러한 추세를 뒷받침합니다. Node.js는 해당 분기 이전 2년 동안 HackerOne을 통해 352건의 보고를 받았습니다. 그러다 2026년 2월, AI 기반 스캔 도구가 등장한 후 보고 건수가 4.6배로 급증했으며, 3월 한 달 동안만 65건이 접수되었다. 스넬은 대화가 오갈 당시 Node.js가 2026년에 이미 50개 이상의 취약점에 대한 수정 패치를 출시했으며, 이는 사상 최대 기록이라고 밝혔다.

연구자들에게 그가 건넨 조언은 실용적이었습니다. 프로젝트의 보안 정책과 위협 모델을 꼼꼼히 읽어보라는 것이었습니다. HackerOne에 공개된 보고서를 검색하여 해당 문제가 이미 처리되었는지 확인하라는 조언도 있었습니다. 또한, 에이전트가 20건의 후보를 찾아냈다고 해도 한꺼번에 20건의 보고서를 제출해서는 안 됩니다. 우선순위를 매겨 가장 중요한 것부터 먼저 제출해야 합니다.

릴리스 노트에 나타나지 않는 작업

스넬은 어떤 거창한 계획을 세운 끝에 Node.js에 발을 들인 것은 아니었다. 2013년, IBM에 재직 중이던 그는 Node가 뒤틀린 HTTP 메서드를 마치 P?T 이를 거부하기보다는 실질적인 해결책으로 받아들였습니다. 당시 보안 보고 절차가 마련되어 있지 않았기 때문에, 그는 공개 이슈를 등록했다가 이런 종류의 소프트웨어가 어떻게 작동하는지 이해하지 못한다는 말을 듣고는 직접 문제를 해결한 뒤 그 자리를 떠났습니다. 이후 IBM이 Node 관련 전반을 총괄할 기술 책임자가 필요해지자 io.js 포크 프로젝트가 그를 다시 불러들였고, 그는 2015년 3월경 TSC에 합류했습니다.

일상의 업무는 직함만큼 화려하지 않습니다. 아침은 1시간 이상 GitHub 알림을 확인하는 것으로 시작하는데, 하루에 800~900건씩 들어오기도 합니다. 코드 검토에는 더 많은 시간이 소요됩니다. “저는 모든 PR의 모든 줄을 읽습니다. 규모가 큰 PR도 예외는 아니죠.”라고 그는 말했습니다. 10줄이든 2만 줄이든 상관없이, 종종 두세 번에 걸쳐 꼼꼼히 검토합니다. 이제 AI가 테스트의 대부분을 작성해 주지만, 여전히 판단력을 대체할 수는 없습니다.

스넬은 또한 Node.js에 제품 로드맵이 있다는 주장에 반박했다. “제품 관리자는 없습니다. 프로젝트 관리자조차 없습니다.” 누구도 Node에 기능을 유료로 구매할 수는 없습니다. CI를 통과하면, 반대하는 사람이 없는 한 최소 48시간 후에 두 번의 승인을 거쳐 풀 리퀘스트가 반영되거나, 일주일 후에 한 번의 승인을 거쳐 반영될 수 있습니다. 따라서 Node에 어떤 기능을 추가하고 싶다면, 자원봉사자들에게 무료로 만들어 달라고 요구하지 말고 직접 풀 리퀘스트를 열어 직접 구현하라는 것이 그의 조언입니다.

여전히 구버전 Node.js를 사용 중인 팀들에게 이것이 의미하는 바

실제로 배포된 상태에서 시작하세요. 현재 Dockerfile에 명시된 내용이나 마이그레이션 티켓에 기재된 내용이 아니라, 한동안 아무도 손대지 않은 서비스를 포함해 프로덕션 환경에서 실행 중인 Node.js 버전을 기준으로 삼으세요. 이를 Node.js 릴리스 일정에 대조하여 이미 지원 종료(EOL)가 지난 버전을 표시하고, 각 버전에 담당자를 지정하세요. Node.js 20은 2026년 4월 30일에 지원이 종료되었으며, Node.js 22는 2027년 4월에 이어 지원이 종료될 예정이므로, 이는 구형 버전을 사용하는 팀만의 문제가 아닙니다.

지금 업그레이드할 수 있다면 바로 진행하세요. 지원되는 LTS 버전을 사용하는 것이 가장 깔끔한 해결책이며, 정기적인 런타임 업그레이드는 몇 년에 한 번씩 발생하는 긴급 상황을 예방하는 데 더 낫습니다.

일부 애플리케이션은 이러한 일정에 맞춰 진행할 수 없습니다. 예를 들어, 최신 V8에서 네이티브 애드온이 작동하지 않아 Node.js 18에 묶여 있는 결제 서비스를 상상해 보세요. 이 경우 마이그레이션은 2분기 뒤에나 공급업체가 코드를 재작성할 때까지 기다려야 합니다. 이와 같은 상황에서, 기존 런타임에 여전히 수정 패치를 적용할 방법이 없다면 “나중에 업그레이드하겠다”는 식의 접근은 보안 대책이 될 수 없습니다.

이것이 바로 TuxCare의 Node.js용 Endless Lifecycle Support(ELS)가 메우는 공백입니다. ‘ELS for Runtimes’의 일부인 이 서비스는 SLA에 따라 지원 대상인 EOL(지원 종료) Node.js 버전에 보안 수정 사항을 역포트하여 패키지 업데이트 형태로 제공하므로, 사용자는 자신의 일정에 맞춰 마이그레이션을 완료하는 동안에도 애플리케이션이 원래 구축된 런타임에서 계속 실행될 수 있습니다. 업데이트 후 영향을 받는 Node.js 프로세스를 재시작하기만 하면 패치된 런타임을 적용할 수 있습니다. 지원 범위는 Enterprise Linux의 Node.js 10까지 거슬러 올라가며, Ubuntu, Debian, Alpine Linux도 포함됩니다. 지원되는 버전은 OS에 따라 다르므로 문서의 버전 매트릭스를 확인하시기 바랍니다. 이는 향후 업그레이드가 필요 없다는 것을 의미하지는 않습니다. 이 서비스는 업스트림에서 특정 버전에 대한 수정 지원을 중단하는 날부터 해당 버전을 안전하게 폐기할 수 있는 날까지의 기간을 커버합니다.

영업 담당자의 연락을 기다릴 필요도 없습니다. 온라인에서 Runtimes용 ELS를 구매하고 설치하기만 하면, 지원 종료(EOL)된 Node.js 버전을 다시 패치 스트림에 포함시킬 수 있습니다.

자주 묻는 질문

Node.js 버전의 지원 종료 시에는 어떤 일이 발생하나요?

업스트림은 보안 수정 사항을 포함해 해당 라인에 대한 모든 커밋을 중단하며, 새로 보고된 취약점이 해당 라인에 영향을 미치는지 여부를 확인하지 않습니다. 그 시점부터는 해당 라인을 운영하는 팀이 위험을 감수해야 합니다.

Node.js 27은 언제 출시되나요?

Node.js 27 알파 버전은 2026년 10월에 출시되었습니다. 첫 번째 ‘Current’ 릴리스는 2027년 4월로 예정되어 있으며, 2027년 10월에 LTS로 승격되고 2030년 4월에 지원이 종료될 예정입니다.

지원 종료 후에도 Node.js 18이나 Node.js 20을 계속 사용할 수 있나요?

네. TuxCare의 Node.js용 ‘Endless Lifecycle Support’와 같은 상용 지원 서비스는, 사용자가 업그레이드를 계획하는 동안에도 해당 서비스가 지원하는 EOL(지원 종료) 버전에 대한 보안 수정 사항을 지속적으로 제공하며, 사용자는 해당 업데이트를 설치하고 영향을 받는 프로세스를 재시작하기만 하면 됩니다.

'파이어사이드 챗' 전체 영상 보기

이 재방송에는 이 게시물에서 다루지 않은 내용과 중복 신고 및 자원봉사자 유지에 관한 실시간 질의응답이 포함되어 있습니다. 제임스 스넬과 크리스 드마스가 출연하는 “Keepers of the Runtime”을 시청해 보세요.

만약 스택의 일부가 업스트림에서 더 이상 패치를 제공하지 않는 Node.js 버전을 여전히 사용하고 있다면, 다음 보안 권고문이 나오기를 기다리며 결정을 미루지 마십시오. ‘ELS for Runtimes’를 도입하여, 본인의 일정에 맞춰 업그레이드하는 동안 지원 대상 버전에 대한 보안 패치를 계속 받아보세요.

요약