Node.js 2027 연간 LTS 전환과 런타임 업그레이드 운영

짝수·홀수 트랙이 남긴 운영 부담

Node.js 프로젝트는 2027년부터 10년 이상 유지해 온 짝수·홀수 버전 이중 릴리스 트랙을 종료하고, 매년 하나의 메이저 버전을 내는 방식으로 전환한다. Node.js Release Working Group이 발표한 이 변경은 런타임 생태계의 단편화를 줄이고 기업의 업그레이드 계획을 더 예측 가능하게 만드는 데 초점이 있다.

기존 정책에서 짝수 버전은 LTS 후보였다. Active LTS 18개월과 Maintenance LTS 12개월을 합쳐 총 30개월 지원됐다. 반면 홀수 버전은 Current 트랙으로 6개월만 유지되며 실험적 기능을 제공했다. 메이저 버전은 매년 10월에 나왔고, 동시에 활성화된 릴리스 라인은 최대 4~5개에 달했다.

이 구조에서 홀수 버전은 실제 채택률이 극히 낮은 채 EOL에 도달하는 경우가 많았다. 신규 사용자와 기업 팀은 어떤 버전을 선택해야 하는지 판단해야 했고, 유지보수 팀은 보안 패치와 버그 수정을 4~5개 라인에 백포팅해야 했다. 홀수 버전을 관리하는 데 쓰이는 리소스 역시 짝수 LTS의 품질 개선에 집중하기 어려웠다.

⤢✕

Node 27부터 적용되는 연간 릴리스 일정

새 정책은 매년 메이저 버전 하나만 릴리스한다. Node.js 27을 기준으로 한 일정은 다음과 같다.

단계	시점	설명
Alpha	2026년 10월 ~ 2027년 3월	사전 테스트, semver-major 변경 허용
Current	2027년 4월	안정 릴리스, 프로덕션 사용 가능
LTS 승격	2027년 10월	모든 메이저 버전이 LTS로 전환
Maintenance	2029년 4월	Active LTS 종료, Maintenance 전환
EOL	2030년 4월	지원 완전 종료

이제 짝수·홀수 구분 없이 모든 메이저 릴리스가 LTS 대상이 된다. Current는 매년 4월에 출시되고 같은 해 10월 LTS로 승격된다. Node 27은 2027년, Node 28은 2028년, Node 29는 2029년 릴리스와 연결돼 버전 번호만으로도 대략적인 시점을 파악할 수 있다.

구분	구 체계	신 체계
Active LTS	18개월	18개월
Maintenance LTS	12개월	12개월
총 지원 기간	30개월	36개월 (Current 포함)
LTS 대상	짝수 버전만	모든 버전
동시 LTS 라인 수	최대 5개	최대 2~3개

총 지원 기간은 구 체계의 30개월에서 신 체계의 36개월로 늘어난다. 기업은 메이저 업그레이드를 연간 단위로 계획하고 최대 3년의 지원 창을 활용할 수 있다.

Alpha 채널을 생태계 준비 기간으로 쓰는 방식

홀수 버전이 맡았던 실험과 조기 검증 역할은 Alpha 채널로 분리된다. Alpha는 27.0.0-alpha.1, 27.0.0-alpha.2 같은 semver 프리릴리스 형식으로 제공되며, 전년도 10월부터 릴리스 연도 3월까지 약 6개월 운영된다.

이 기간에는 Breaking Change를 포함한 semver-major 변경이 허용된다. 배포 빈도는 Release Team이 변경량과 프로젝트 요구에 따라 정하며, 대상은 프로덕션 사용자보다 라이브러리 작성자와 CI 파이프라인이다. 프로덕션 환경에는 권장되지 않는다.

구분	홀수 버전 (Old)	Alpha 채널 (New)
목적	실험적 기능 배포	사전 호환성 테스트
안정성	준안정 (semi-stable)	불안정 (pre-release)
타깃 사용자	얼리어답터 개발자	라이브러리·도구 관리자
Breaking Change	제한적 허용	명시적 허용
이후 경로	EOL (LTS로 미전환)	Current → LTS 전환

라이브러리 관리자는 Alpha 기간에 다음 메이저 버전과의 호환성을 확인할 수 있다. 정식 출시 전에 생태계가 준비할 수 있는 기간이 생기고, 안정 릴리스와 실험 단계도 분명하게 나뉜다.

지원 라인을 줄여 단편화를 다루는 구조

단일 연간 릴리스는 npm 패키지 관리자에게 지원해야 할 Node.js 버전 범위를 예측하기 쉽게 만든다. CI/CD 테스트 매트릭스에서는 홀수 버전이 빠져 파이프라인 복잡도가 줄고, 유지보수 팀은 2~3개 라인에 보안 패치와 버그 수정을 집중할 수 있다.

분산됐던 이슈와 PR 처리 역량도 활성 LTS 라인으로 모인다. 핵심은 단순히 버전 수를 줄이는 데 있지 않다. 실험 기능 검증은 Alpha로 분리하고, 정식 메이저 버전은 모두 LTS로 이어지도록 해 각 단계의 목적을 구분하는 방식이다.

기업이 잡을 수 있는 업그레이드 리듬

기업은 매년 4월 Current 출시부터 10월 LTS 승격까지를 업그레이드 평가 기간으로 정할 수 있다. 연간 하나의 버전만 나오므로 2개 버전을 건너뛰더라도 총 36개월 안에 EOL 도달을 피할 수 있다.

Alpha가 공개되는 10월부터 6개월은 의존성 호환성을 감사하는 기간으로 쓸 수 있다. 개발 환경, 스테이징, 프로덕션 순으로 단계적 롤아웃을 진행하면 전환 위험도 분산할 수 있다.

Node 25에서 Node 27로 이동하는 경우의 일정은 다음과 같다.

시점	활동
2026년 10월	Node 27 Alpha 공개 → 의존성 호환성 스캔 시작
2026년 11월~2027년 3월	Alpha 빌드로 CI 테스트, Breaking Change 목록 파악
2027년 4월	Node 27 Current 릴리스 → 개발·스테이징 환경 전환
2027년 6~9월	프로덕션 점진적 롤아웃, 모니터링 강화
2027년 10월	Node 27 LTS 승격 확인 → 전사 프로덕션 표준 버전 지정

OpenJS Foundation의 Node.js LTS Upgrade and Modernization Program은 이 전환을 지원받을 수 있는 공식 채널이다. 경험 있는 Node.js 서비스 프로바이더와 연결해 의존성 평가, 단계적 업그레이드, 임시 보안 지원을 제공한다.

Breaking Change를 릴리스 전에 소화하기

Node.js는 SemVer(Semantic Versioning) 원칙에 따라 메이저 버전인 X.Y.Z의 X를 올릴 때만 Breaking Change를 도입한다. 메이저 버전 업이 연 1회로 고정되면 변경 도입 시점도 예측할 수 있다.

변경은 Alpha 릴리스에서 다룬다. Deprecation 경고를 2~3 Alpha 릴리스에 걸쳐 누적 노출하고, Current 릴리스 시점에는 공식 마이그레이션 문서를 제공한다. 자동 코드 변환을 위한 Codemod를 제공해 수동 수정 부담을 줄이고, 가능한 경우 기존 API를 Deprecated 상태로 일정 기간 유지한다. 프로덕션 배포 전에는 롤백 절차를 문서화하고 테스트한다.

기업 팀은 Alpha 공개 시점에 CHANGELOG와 Breaking Changes 목록을 검토해야 한다. 사용 중인 npm 패키지의 새 버전 지원 여부는 npm outdated, npm audit로 확인하고, 내부 코드베이스의 Deprecated API 사용 현황도 자동 스캔 대상에 포함한다. E2E 테스트 커버리지를 확인한 뒤, 스테이징 환경에서 최소 4주 이상 새 버전을 운용하고 프로덕션 전환을 결정한다.

LTS 정책이 갖춰야 할 운영 조건

런타임의 LTS 정책은 유지보수 팀이 실제로 감당할 수 있는 활성 릴리스 라인 수에서 시작한다. 보안 패치 백포팅 경로를 줄이고 핵심 라인에 에너지를 집중해야 패치 품질을 유지할 수 있다.

릴리스 시점과 EOL 일정을 고정된 캘린더에 맞추면 기업은 계획을 세울 수 있다. 버전 번호를 캘린더와 연결하면 운영자와 개발자가 버전의 시점을 직관적으로 이해할 수 있다.

생태계에는 Current 이전의 사전 테스트 기간도 필요하다. Alpha 채널은 라이브러리와 도구 관리자가 Breaking Change에 대응할 lead time을 확보하고, CI/CD 환경에서 다음 버전을 테스트할 공식 경로가 된다. 실제 채택 패턴을 반영해 사용되지 않는 릴리스 라인을 없애고, 통상 1~2년인 기업 업그레이드 주기와 LTS 지원 기간을 맞추는 일도 같은 맥락에 있다.

Node.js의 전환은 연간 메이저 릴리스, 모든 버전의 LTS 승격, 6개월 Alpha 채널을 결합해 릴리스 관리 복잡성을 다루는 사례다. 런타임이 성장하면서 늘어난 버전 관리와 생태계 호환성 부담을 어떻게 구조적으로 줄일지 보여준다.