개발/백엔드

🟩 Node.js 26 LTS 10월 28일 · 22는 2027년 4월 종료

개발만빼고다잘함 2026. 10. 25. 09:54
반응형

Node.js 26이 2026-10-28에 LTS로 올라갈 예정이다. 공식 일정표에는 같은 날이 27 Alpha 시작일로 적혀 있다. 지금 22나 24로 돌아가는 서비스는 언제까지 버틸 수 있을까. 27부터 바뀌는 일정은 무엇이 다를까.

버전별 지원 상태

Active LTS니 Maintenance니 하는 말만 보면 당최 언제 올려야 하는지 감이 안 온다. 공식 schedule.json 날짜로 2026-10-25 기준 상태를 정리하면 이렇다.

버전지금 상태Maintenance 시작지원 종료(EOL)판단
버전 지금 상태 Maintenance 시작 지원 종료(EOL) 판단
20 (Iron) 종료 2024-10-22 2026-04-30 바로 올린다
22 (Jod) Maintenance 2025-10-21 2027-04-30 2027년 4월 전에 옮긴다
24 (Krypton) Maintenance 2026-10-20 2028-04-30 급하지 않다
26 Current → 10-28 LTS 2027-10-20 2029-04-30 새 프로젝트 기본값

25는 LTS 없이 2026-06-01에 끝났다. Maintenance 단계는 원칙적으로 심각한 버그 수정과 보안 업데이트만 받는다. 단종된 차의 부품 공급 기간이라고 보면 된다. 고장은 고쳐 주지만 새 옵션은 거의 안 나온다.

README 표의 상태 칸은 24.x를 아직 Active LTS로 적고 있다. 같은 줄의 Maintenance 시작일과 schedule.json은 둘 다 2026-10-20이다. 날짜 쪽을 믿으면 된다. 26의 코드네임 칸이 비어 있는 것도 원문 그대로다.

22를 쓰고 있다면 지금부터 계획을 잡자. 24에서 26으로는 서두를 이유가 없다.

27부터 달라지는 일정

공식 블로그가 2026-03-10에 새 일정을 발표했다. 26은 옛 방식의 마지막 라인이다.

  • 메이저 릴리스 : 1년에 두 번에서 한 번(4월)으로. LTS 승격은 10월
  • 홀짝 구분 : 없어진다. 27도 LTS가 된다
  • Alpha 채널 : 10월~3월 6개월. semver-major 변경 허용. 운영용이 아니다
  • 버전 번호 : 첫 Current가 나온 해에 맞춘다. 27.0.0은 2027년, 28.0.0은 2028년
  • 지원 기간 : LTS 30개월. 첫 Current부터 EOL까지 36개월
  • Maintenance 단계 : 27부터 없다. 30개월 내내 Active LTS로 남는다

schedule.json의 27 일정은 Alpha 2026-10-28, Current 2027-04-22, LTS 2027-10-20, EOL 2030-04-30이다. 블로그는 이 일정이 확정이 아니라고 밝힌다.

LTS만 골라 올리던 팀은 버전 번호 말고는 바뀌는 게 거의 없다. 라이브러리를 만든다면 Alpha를 CI에 일찍 넣으라는 게 블로그의 당부다.

26에서 사라진 API

v26.0.0 릴리스 노트에서 코드를 손봐야 하는 항목만 추렸다.

  • http.Server.prototype.writeHeader() : 제거. writeHead()로 바꾼다
  • _stream_wrap 등 _stream_* 모듈 6개 : 제거
  • module.register() : 런타임 경고(deprecated)
  • --experimental-transform-types : 제거

같은 릴리스에서 Temporal API가 기본으로 켜졌다. V8은 14.6, Undici는 8.0.2로 올랐다.

올리기 전에 저장소를 한 번 훑어보자.

# 26에서 제거된 API를 쓰는 곳 찾기
grep -rnE "writeHeader\(|_stream_(wrap|readable|writable|duplex|transform|passthrough)" src/

# 런타임 경고가 붙은 API
grep -rn "module.register(" src/

버전을 고정해 두는 자리

.nvmrc에 버전을 적어 두면 nvm use와 nvm install이 그 버전을 쓴다. lts/*는 그때의 최신 LTS를 가리키니 메이저 숫자를 적는 편이 안전하다.

# 프로젝트 루트에 메이저 숫자만 적는다
echo "26" > .nvmrc

engines는 engine-strict 설정이 없으면 의존성으로 설치될 때 경고만 띄운다. 막는 장치가 아니라 안내문이다.

{
  "engines": {
    "node": ">=24"
  }
}

도커 공식 이미지는 2026-10-25 기준 lts 태그가 24.22.1이다. latest는 26.12.1이다. lts 태그가 언제 26으로 넘어가는지는 확인되지 않았다. 메이저를 숫자로 박아 두자.

# lts 대신 메이저 숫자로 고정
FROM node:26-slim
WORKDIR /app

빌드 인자에 토큰을 넘기면 이미지 기록에 남는 문제는 Dockerfile ARG 글에 따로 적어 뒀다.

CI에서 26 먼저 돌려보기

setup-node 문서는 node-version을 비우면 PATH에 있는 node를 쓴다고 적는다. 항상 지정하라고 권한다. 22·24·26을 매트릭스로 돌리면 어디서 깨지는지 한 번에 보인다.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [22, 24, 26]   # 26이 통과하면 기본값을 옮긴다
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test

26 줄이 초록색이면 .nvmrc와 Dockerfile 숫자를 바꾸고 22 줄은 2027-04-30 전에 지우면 된다.

참고

반응형