Node.js 26 LTS와 27 Alpha: 업그레이드 달력과 CI를 나누는 법

하루 차이로 나온 두 버전은 서로 다른 일을 맡는다

2026년 10월 28일 Node.js 26.13.0이 Lithium이라는 이름으로 LTS에 진입했다. LTS는 장기 지원 단계다. 다음 날에는 27.0.0-alpha.0.0.0이 공개됐다. 숫자만 보면 27이 다음 운영 대상처럼 보이지만, 두 발표가 독자에게 요구하는 행동은 다르다. 26은 서비스 이전 후보로 검증할 대상이고, 27 Alpha는 다음 변경에 대비해 호환성을 살펴볼 대상이다. 26.13.0 릴리스, 27 첫 Alpha 릴리스

특히 26.13.0에는 LTS 상태를 반영하는 메타데이터 외에 26.12.1 대비 추가 변경이 없다. 따라서 “LTS가 되면서 새 엔진으로 크게 바뀌었다”는 설명은 맞지 않는다. 이미 26.12.1을 시험하던 팀과 22에서 26으로 건너오는 팀의 검증량도 같지 않다. 후자는 그 사이의 주요 버전 변경과 의존성 지원을 확인해야 한다. 26의 승격 범위

이 글은 11월 1일 확인한 공식 자료를 바탕으로 한 이전 계획 분석이다. Node 26·27을 설치하거나 실제 CI·서비스를 실행한 결과는 아니다. 아래 일정 계산은 공식 날짜와 명시한 가정으로 수행했으며, 사례의 팀 구성과 소요 기간은 가상이다.

이제 “홀수는 건너뛴다”는 규칙을 바꿔야 한다

Node.js는 27 계열부터 연간 주요 릴리스 하나로 전환하고, 각 계열을 LTS로 승격할 계획이다. 27은 2026년 가을 Alpha, 2027년 봄 Current, 가을 LTS 순서다. Current는 정식 주요 릴리스가 나온 뒤의 단계이며 Alpha와 구분된다. 기존의 “짝수만 장기 지원”이라는 기억을 자동화 조건으로 남겨 두면, 앞으로 LTS가 될 27을 계속 배제하게 된다. 릴리스 일정 개편

Alpha에서는 호환성을 깨는 변경이 들어올 수 있다. 프로젝트는 서명·태그·CITGM 생태계 시험을 거치는 Alpha를 자동 Nightly와 구분하지만, 운영 사용 대상으로 안내하지 않는다. 라이브러리 개발자가 일찍 시험해 문제를 알리도록 마련한 단계다. “시험을 거쳤다”와 “내 서비스가 사용할 안정된 API 계약이다”는 다른 판단이다. Alpha의 대상과 변경 범위

정책이 바뀌는 경계도 중요하다. 26까지는 Active LTS 뒤에 Maintenance가 이어지는 기존 일정을 따른다. 27부터는 30개월 LTS 기간을 Active LTS로 유지하며 별도 Maintenance 단계로 넘어가지 않는 정책이다. 26의 지원표를 복사해 27의 유지보수 시작일을 임의로 채우면 안 된다. 고정 커밋의 지원 단계 설명

이 변화가 매년 무조건 서비스를 갈아타라는 뜻은 아니다. 지원되는 계열 사이의 겹치는 기간은 남는다. 다만 팀의 업그레이드 기준을 버전의 홀짝에서 지원 종료일·의존성 호환성·검증 여유로 바꿀 필요가 있다. 이는 공식 일정에서 도출한 운영 제안이다.

Node 22 팀이 27 LTS를 기다릴 수 없는 이유

다음 표는 11월 1일 확인한 Release 저장소의 일정이다. 미래 날짜는 현재 계획이며 변경될 수 있다. Alpha 일정 시작일인 10월 28일과 첫 Alpha 릴리스 공지의 10월 29일도 구분했다. 일정 원본 JSON

계열	2026-11-01의 단계	다음 주요 시점	지원 종료 예정
22	Maintenance LTS	지원 종료 전 이전 필요	2027-04-30
24	Maintenance LTS	의존성·검증 일정에 따라 이전 계획	2028-04-30
26	Active LTS	Maintenance 시작 2027-10-20	2029-04-30
27	Alpha	Current 2027-04-22, LTS 2027-10-20	2030-04-30

22의 지원 종료일과 27의 LTS 예정일 사이에는 달력 날짜 차이로 173일이 있다. 따라서 “지금은 기다렸다가 다음 LTS인 27로 한 번에 가자”는 계획은, 그 기간의 공백을 별도 대책 없이 받아들이는 계획이 된다. 27 Current를 사용하는 선택도 가능하지만, 그것은 LTS를 기다린다는 원래 정책과 다른 선택이다. 날짜 차이는 지원 종료 시각을 시간 단위로 측정한 값이 아니다.

공식 일정과 날짜 계산으로 직접 만든 설명도다. 미래 일정은 변경 가능하며, 실제 팀의 이전 진행 상태를 보여주는 그림은 아니다.

가상의 주문 API 팀이 22를 쓰고 있다고 하자. 팀은 지원 종료 2주 전인 2027년 4월 16일을 내부 완료일로 정하고, 호환성 검증·점진 배포에 8주를 배정한다. 이 가정에서 시작일은 2월 19일이다. 여기서 8주와 2주는 Node 프로젝트가 정한 의무 기간이 아니라 팀의 계획 입력이다. 검증에 12주가 필요하면 시작일도 더 앞당겨야 한다.

이 팀의 첫 선택지는 의존성들이 지원하는 26을 시험하는 것이다. 핵심 패키지가 26을 지원하지 않지만 24에서는 검증할 수 있다면, 24를 중간 경로로 삼는 선택도 남는다. 다만 24의 종료일은 26보다 앞서므로 두 번째 이전 비용까지 계획해야 한다. 반대로 이미 24를 안정적으로 운영하는 팀은 “26이 나왔다”는 사실 하나만으로 당일 전환할 필요가 없다. 지원 종료 전에 검증할 달력이 있는지를 먼저 확인한다.

운영팀과 라이브러리팀은 CI의 답을 다르게 읽는다

CI는 변경마다 반복하는 자동 검사의 집합이다. 이 글의 제안은 현재 지원을 약속한 환경의 필수 검사와 다음 계열을 미리 보는 탐색 검사를 분리하는 것이다. 공식 인증 구성이나 실행한 workflow가 아니라 팀별로 조정할 설계안이다.

담당 대상	필수로 통과시킬 환경	미리 살펴볼 환경	실패했을 때의 다음 행동
현재 24로 운영하는 주문 API	실제 운영과 맞춘 24 및 이전 승인 대상 26	필요한 경우 27 Alpha 별도 작업	26에서 실패하면 이전을 멈추고 원인 수정. Alpha 실패는 담당자·재확인일 지정
22·24·26 지원을 선언한 공용 패키지	선언한 세 계열과 실제 지원 OS/아키텍처	정확한 버전을 기록한 27 Alpha	기존 지원 계열 회귀는 릴리스 차단. Alpha만 실패하면 최소 재현으로 다음 변경 추적
네이티브 애드온을 포함한 CLI	지원 플랫폼의 설치와 실제 애드온 호출	차기 런타임의 빌드·로드·핵심 호출	바이너리 부재, ABI 문제, 업무 결과 차이를 따로 분류

탐색 검사라고 결과를 무시해서는 안 된다. 예를 들어 27에서만 패키지 import가 실패했다면, 실패한 정확한 Alpha 버전과 최소 입력을 기록하고 다음 시험의 담당자를 정한다. 반대로 운영 필수 검사가 실패했는데 “Alpha니까 괜찮다”는 조건이 전체 작업에 적용되면 현재 지원 약속까지 느슨해진다. 두 결과를 같은 초록색 성공으로 합치지 않는 것이 핵심이다.

작은 내부 서비스가 모든 OS와 모든 버전을 시험할 필요는 없다. 실제 운영 환경 한 가지와 목표 환경 한 가지부터 시작해도 된다. 반면 여러 프로젝트가 가져다 쓰는 라이브러리는 개발자의 노트북 환경만으로 지원 범위를 증명할 수 없다. 시험 조합은 버전 숫자가 아니라 사용자에게 약속한 지원 범위에서 정한다.

탐색용 Alpha 버전을 고정하면 실패를 다시 비교하기 쉬워진다. 동시에 다음 Alpha로 갱신할 날짜를 정해야 오래된 시험 결과만 쌓이는 일을 피할 수 있다. 운영 경로에도 고정된 배포 입력과 정기적인 패치 갱신 절차가 함께 필요하다. 고정은 비교를 위한 수단이며 무기한 업데이트 중단의 이유가 아니다.

설치 성공 다음에 확인할 세 가지

Linux 이미지가 시작되는가

26 LTS 공지는 이전 LTS에서 이동하는 독자에게, Node 25부터 공식 Linux 바이너리가 libatomic에 연결된다는 점을 알린다. 배포판에 따라 별도 설치가 필요할 수 있다. 개발 컴퓨터의 실행 성공만으로 최소 컨테이너 이미지에서도 시작된다고 가정할 수 없는 구체적인 이유다. 공식 Linux 바이너리 조건

가상 주문 API 팀이라면 실제 배포 이미지와 같은 기반에서 프로세스 시작, 정상 요청 하나, 종료를 먼저 확인한다. 시작부터 실패하면 애플리케이션 로직을 고치기 전에 필요한 공유 라이브러리와 이미지 구성부터 확인한다. 이 글은 특정 배포판의 설치 명령을 실행하거나 그 의존성을 검증한 안내가 아니다.

네이티브 애드온이 실제 일을 하는가

네이티브 애드온은 JavaScript에서 C·C++ 등의 바이너리 코드를 호출하는 확장이다. Node-API는 ABI, 즉 바이너리 인터페이스의 안정성을 제공하지만, Node의 모든 C++ API나 V8·libuv API까지 같은 보장을 제공하지 않는다. 애드온이 쓰는 외부 라이브러리에도 별도 조건이 있다. Node 26.13.0의 ABI 안정성 범위

따라서 “Node-API를 사용한다”는 설명만 보고 모든 운영체제·CPU·외부 라이브러리 조합을 승인할 수 없다. 이미지 처리 CLI라면 의존성 설치, 애드온 로드, 작은 이미지 한 장의 실제 변환을 나눠 확인할 수 있다. 설치가 성공했는데 첫 변환에서 실패하는 경우와, 대상 플랫폼 바이너리가 없어 설치부터 실패하는 경우는 수정할 곳이 다르다. 이 예시는 시험 설계이며 특정 패키지의 호환 결과가 아니다.

새 버전이 만든 결과를 구버전도 읽어야 하는가

27 첫 Alpha 릴리스는 v8.serialize() 등의 직렬화 형식 변경을 알리며, 이전 Node 릴리스가 새 형식을 읽지 못한다고 설명한다. Alpha의 현재 변경 사항이므로 이후 릴리스에서 다시 확인해야 한다. 이 사실을 일반 JSON 데이터나 모든 애플리케이션 저장 형식의 변경으로 확대하면 안 된다. 27 Alpha의 직렬화 변경

이 자료로부터 설계할 수 있는 가상 시험은 캐시를 공유하는 신·구 프로세스의 조합이다. 앱이 실제로 V8 직렬화 결과를 파일에 저장한다면 다음 네 경로를 구분한다.

생성자 → 소비자	확인하려는 것
구버전 → 구버전	현재 동작의 기준
구버전 → 새 버전	이전 데이터의 전진 호환
새 버전 → 새 버전	새 환경 자체의 정상 동작
새 버전 → 구버전	혼합 배포와 롤백 때 남는 역방향 호환

마지막 경로가 실패하면 실행 파일만 구버전으로 되돌려도 캐시 문제는 남을 수 있다. 재생성 가능한 캐시라면 버전별 저장 위치를 나누고 새 프로세스가 옛 캐시를 덮지 않도록 하는 설계를 검토할 수 있다. 캐시처럼 보이는 파일이 실제로 유일한 업무 원본이라면 삭제·재생성을 대안으로 삼으면 안 된다. 이 시험은 여기서 실행하지 않았으며, 27 Alpha의 설명을 26 LTS의 신규 변경으로 옮겨 적어서도 안 된다.

다음 회의에서 정할 것은 버전 하나보다 이전 조건이다

팀별로 다음 기록을 한 줄씩 채우면 결정이 구체화된다. 빈 이전 계획표를 내려받아 사용할 수도 있다. 계획표는 상태를 자동 판정하거나 런타임을 변경하는 프로그램이 아니다.

대상 서비스 또는 패키지 / 담당자:
현재 지원 계열 / 확인한 종료일 / 일정 출처·확인일:
운영 이전 후보 / 의존성이 허용하는 범위:
내부 완료일 / 검증 소요 가정 / 역산한 시작일:
필수 CI: 지원 버전·OS·CPU / 실제 업무 입력·기대 결과
탐색 CI: 정확한 Alpha 버전 / 실패 담당자 / 다음 갱신일
설치·시작 / 애드온 실제 호출 / 신·구 데이터 양방향 확인:
혼합 배포와 롤백 때 보존해야 할 데이터:
남은 미확인 항목 / 이전 승인 또는 보류 조건:

22 운영팀은 종료일 전에 가능한 경로를 확보하는 일이 우선이다. 24 운영팀은 26 검증을 언제 시작할지 정할 수 있다. 공용 라이브러리팀은 현재 지원 범위를 지키면서 27 Alpha의 실패를 일찍 발견할 기회를 얻는다. 이렇게 역할을 나누면 새 릴리스가 나올 때마다 전부 갈아타거나, LTS가 될 때까지 아무것도 확인하지 않는 양자택일을 피할 수 있다.

데이터 형식까지 바뀌는 이전의 구체적인 사례는 Python UTF-8 기본값과 한글 CSV 이전, Node 서비스에서 느린 소비자와 메모리 증가를 확인하는 방법은 백프레셔와 버퍼 제어에서 이어 읽을 수 있다. 계획표를 저장해 다음 지원 일정 확인 때 다시 대조하거나 소프트웨어 주제 모음과 RSS에서 후속 글을 찾을 수 있다.