[개발·배포] GitHub Actions Node.js 20 경고 해결법

🚨 오늘 기준으로 GitHub Actions의 Node.js 20 제거가 하루 앞으로 다가왔습니다. GitHub는 2026년 9월 23일 Runner에서 Node.js 20 런타임을 제거할 예정이며, 지난 6월부터 JavaScript Action의 기본 실행 런타임은 이미 Node.js 24로 전환했습니다.

Workflow에 Node.js 20 actions are deprecated 경고가 남아 있거나 오래된 actions/checkout·setup-*·서드파티 Action을 고정해 두었다면, 내일부터는 임시 우회보다 Action 자체를 Node.js 24 호환 버전으로 올리는 쪽이 안전합니다.

👋 Network History 독자 여러분, 안녕하세요. YH입니다.

오늘은 이 경고가

내 애플리케이션의 Node.js 버전 문제인지, Action 내부 런타임 문제인지 구분

하고, 영향을 받는 Workflow 찾기 → 공식 Action 업데이트 → 서드파티·Custom Action 점검 → self-hosted runner 확인 → 정상화까지 순서대로 정리합니다.

📅 9월 23일

GitHub Runner에서 Node.js 20 런타임 제거가 예정돼 있습니다.

⚠️ 대표 경고

Node.js 20 actions are deprecated가 보이면 사용 중인 Action 버전을 점검해야 합니다.

🧩 가장 흔한 오해

프로젝트의 node-version: 20과 Action 자체가 쓰는 Node 런타임은 서로 다른 문제입니다.

✅ 해결 방향

Node.js 24를 지원하는 최신 Action으로 올리고 Custom Action은 runs.using을 점검합니다.

핵심 한 줄

Node.js 20 경고의 핵심은 애플리케이션 Runtime이 아니라 “GitHub Action 자체를 실행하는 내장 Runtime”인 경우가 많습니다.

---

Node.js 20 경고는 내 프로젝트 Node 버전과 다릅니다

GitHub Actions 안에는 서로 다른 두 종류의 Node.js가 존재할 수 있습니다.

구분	역할	어디서 정하나
프로젝트 Node.js	내 애플리케이션의 빌드·테스트 실행	setup-node의 node-version
Action Runtime	checkout, setup-node 같은 JavaScript Action 자체 실행	각 Action의 action.yml 안 runs.using

예를 들어 Workflow가 애플리케이션 테스트용으로 Node.js 20을 설치한다고 해서 바로 이번 제거 일정과 같은 문제는 아닙니다. 반대로 프로젝트는 Node.js 24를 쓰더라도, 오래된 Action이 내부적으로 runs.using: node20을 선언하고 있으면 경고가 나타날 수 있습니다.

Workflow → JavaScript Action → Action Runtime → Build / Test → Project Runtime

Node.js 20 애플리케이션 지원 여부와 이번 Action Runtime 제거는 분리해서 보세요.

이번 GitHub 일정은 Runner가 JavaScript Action을 실행할 때 사용하는 Node.js 20 내장 런타임 제거가 핵심입니다. 프로젝트 자체의 지원 Node 버전은 별도의 제품·보안 정책으로 판단해야 합니다.

---

어떤 Workflow가 영향을 받는지 먼저 찾으세요

가장 먼저 할 일은 모든 Workflow에서 어떤 Action 버전을 쓰는지 목록을 만드는 것입니다.

Workflow의 uses 항목 찾기

grep -R -n "uses:" .github/workflows

여기서 오래된 Major Version과 Commit SHA로 고정한 Action을 우선 확인합니다. GitHub가 제공한 경고 Annotation이 있다면 거기에 실제로 Node.js 20을 사용하는 Action 이름이 직접 표시되므로 가장 빠른 단서가 됩니다.

패턴	확인 방법
actions/* 공식 Action	공식 Repository의 현재 Release와 Node.js 24 전환 버전 확인
서드파티 Action	Release Notes와 action.yml의 runs.using 확인
Commit SHA Pin	보안상 Pin은 유지하되 Node.js 24 지원 Release의 새 SHA로 교체
Local Custom Action	Repository 안 action.yml·action.yaml 직접 검사

Custom Action을 함께 운영한다면 다음처럼 metadata의 runtime 선언을 찾을 수 있습니다.

grep -R -n "using:.*node20" . \
  --include="action.yml" \
  --include="action.yaml"

Action 이름만 보고 안전하다고 판단하지 마세요.

같은 Action이라도 Major Version에 따라 내부 런타임이 다를 수 있습니다. 최신 README·Release Notes 또는 해당 Tag의 action.yml을 확인하는 것이 정확합니다.

---

공식 Action은 Node.js 24 지원 버전으로 올리세요

GitHub 공식 Action도 세대별로 내부 Runtime이 달라집니다. 현재 공식 문서를 보면 대표적인 Action들은 이미 Node.js 24 기반 버전을 제공하고 있습니다.

Action	Node.js 24 전환 기준	현재 확인 포인트
actions/checkout	v5에서 Node.js 24로 전환	현재 Marketplace의 최신 Major를 확인한 뒤 입력값 변경 여부 검토
actions/setup-node	v5에서 Node.js 24로 전환	현재 최신 Major의 Cache·인증 관련 Breaking Change 확인
actions/setup-python	v6에서 Node.js 24로 전환	Runner 최소버전과 최신 Major Release Notes 확인

중요한 점은 단순히 숫자만 가장 크게 올리는 것이 아닙니다. Node.js 24를 지원하는 Major Version을 찾은 뒤, 그 버전의 Breaking Change를 읽고 업데이트해야 합니다.

1

경고에 표시된 Action 이름 확인
Run Summary 또는 Annotation에서 Node.js 20 사용 Action을 식별합니다.

2

공식 Release Notes 확인
Node.js 24로 전환된 Major Version과 입력값 변경을 확인합니다.

3

Workflow의 uses 갱신
Major Tag 또는 검증한 Commit SHA로 교체합니다.

4

PR에서 Test Run
Build·Cache·Artifact·Authentication 동작을 확인한 뒤 Main에 반영합니다.

특히 보안 때문에 Commit SHA를 Pin한 조직은 “Pin을 해제”하는 것이 아니라 Node.js 24 호환 Release의 새 SHA로 다시 Pin하는 방식이 적절합니다.

---

Custom JavaScript Action은 runs.using을 바꿔야 합니다

직접 만든 JavaScript Action을 운영한다면 사용자 Workflow만 고쳐서는 해결되지 않습니다. GitHub 공식 Metadata 문서에서 JavaScript Action은 action.yml의 runs.using으로 실행 Runtime을 지정합니다.

runs:
  using: 'node24'
  main: 'dist/index.js'

단순히 node20을 node24로 글자만 바꾸는 것으로 끝내지 말고, Action 코드가 Node.js 24에서 정상 동작하는지 Test하고 Build Output도 다시 생성해야 합니다.

1

action.yml 확인
runs.using: node20 선언이 있는지 찾습니다.

2

Dependency 업데이트
오래된 @actions/* Package와 Runtime 호환성을 확인합니다.

3

Node.js 24에서 Build/Test
Action의 Unit Test와 실제 Workflow Integration Test를 수행합니다.

4

dist 재빌드
Bundled JavaScript Action이라면 배포용 dist를 새 Runtime 기준으로 다시 생성합니다.

5

새 Release Tag 발행
기존 사용자가 안전하게 Major/Minor Version을 갱신할 수 있게 Release합니다.

서드파티 Action이 아직 Node.js 20만 지원한다면 무작정 Fork 코드를 신뢰하지 마세요.

공식 Maintainer의 업데이트 여부와 Issue·Release를 먼저 확인하고, 대체 Action 또는 내부 검증된 Fork를 선택합니다. Supply Chain 관점에서 출처가 불명확한 수정본은 또 다른 위험이 될 수 있습니다.

---

Self-hosted runner는 Node.js 24 지원 버전인지 확인하세요

GitHub-hosted runner만 쓰는 경우에는 플랫폼이 Runner Runtime을 관리하지만, self-hosted runner는 운영자가 Runner 버전과 OS·Architecture 호환성을 같이 책임져야 합니다.

GitHub의 공식 Action 문서에서 Node.js 24 기반 checkout, setup-node, setup-python 등은 Actions Runner v2.327.1 이상이 필요하다고 안내합니다. 따라서 Action을 올렸는데 self-hosted runner에서만 깨진다면 runner 자체가 오래됐는지도 함께 확인해야 합니다.

환경	확인할 것
GitHub-hosted	Workflow의 Action 버전과 Breaking Change
Self-hosted	Action 버전 + Runner 버전 + OS/Architecture
macOS 구형 환경	Node.js 24가 macOS 13.4 이하를 지원하지 않는 점 확인
ARM32 Runner	Node.js 24 공식 지원 부재로 기존 운영구조 재검토

임시 환경변수에 의존하는 시간은 끝나갑니다.

ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true로 Node.js 20을 잠시 허용하는 우회는 공식 안내상 Node.js 20이 Runner에서 제거되는 9월 23일까지로 제한됩니다. 장기 해결책으로 쓰면 안 됩니다.

Self-hosted runner를 Golden Image나 Container로 배포한다면, 실행 중인 Instance 하나만 고치지 말고 Runner Base Image 자체를 최신 버전으로 갱신해야 다음 Scale-out 때 다시 구버전이 생기지 않습니다.

---

업데이트 후에는 경고가 사라졌는지 끝까지 확인하세요

1

새 PR에서 Workflow 실행
Production Branch에 바로 반영하기보다 수정 PR에서 전체 Job을 실행합니다.

2

Run Annotation 확인
Node.js 20 actions are deprecated 경고가 더 이상 나타나지 않는지 확인합니다.

3

Cache·Artifact 확인
Major Upgrade 과정에서 Cache Key·Artifact 동작·인증 방식이 바뀌지 않았는지 확인합니다.

4

Self-hosted Fleet 검증
모든 Runner Group에서 최신 Action이 실행되는지 확인합니다.

5

오래된 Action Inventory 제거
다른 Workflow·Reusable Workflow·Composite Action에 남은 구버전을 다시 검색합니다.

정상화 기준

Node.js 20 경고 없음 → 전체 Job 성공 → Cache·Artifact·인증 정상 → Self-hosted에서도 동일 결과

조직 단위 Repository가 많다면 Dependabot 또는 Renovate 같은 자동화로 GitHub Action Version Update를 정기화하고, 중요한 Action은 검증된 Major Version·Commit SHA 기준선을 관리하는 편이 좋습니다.

---

다음 Runtime 교체에도 덜 흔들리는 운영법

운영 항목	권장 방식
Action Version	주기적으로 Release 확인, 중요 Action은 검증 후 갱신
Commit SHA Pin	Pin은 유지하되 지원 Release의 새 SHA로 교체
Custom Action	runs.using과 Runtime EOL을 자산목록에 포함
Self-hosted Runner	Runner Release와 Base Image를 함께 갱신
Workflow Inventory	Reusable·Composite Workflow까지 포함해 uses: 목록 관리
Pre-migration Test	새 Runtime 강제 환경변수가 제공되면 사전에 Canary Test

GitHub Actions에서 Runtime 교체는 앞으로도 반복될 수 있습니다. 특정 경고를 한 번 없애는 것보다 Action Runtime과 프로젝트 Runtime을 분리해서 Inventory하고, Runner·Action·Custom Action의 지원주기를 함께 관리하는 것이 재발방지의 핵심입니다.

---

마무리

GitHub Actions의 Node.js 20 경고가 보일 때 가장 먼저 기억할 것은 “내 프로젝트가 Node 20이라서”라고 단정하지 않는 것입니다. 많은 경우 문제는 Workflow가 사용하는 JavaScript Action 자체의 실행 Runtime입니다.

2026년 9월 23일 Node.js 20 Runner 제거를 앞둔 지금은 경고에 표시된 Action 식별 → Node.js 24 지원 Release 확인 → Workflow 업데이트 → Custom Action metadata 점검 → self-hosted runner 업데이트 → 재실행 검증 순서로 처리하면 됩니다.

✅ 오늘 바로 Repository에서 grep -R -n "uses:" .github/workflows와 using: node20 검색을 한 번 돌려보세요.

내일 제거 이후 문제가 될 수 있는 오래된 Action을 가장 빠르게 찾는 출발점

입니다. 🔧

Network History의 YH였습니다.

※ 이 글은 2026년 9월 22일 기준 GitHub 공식 Changelog, Actions Metadata 문서, actions/checkout·setup-node·setup-python 공식 Repository를 기준으로 작성했습니다. Action의 최신 Major Version과 Runner 최소버전은 이후 변경될 수 있으므로 실제 수정 전 각 Action의 최신 Release Notes를 다시 확인하세요.

---

🔗 공식 출처

🚨 Node.js 20 Deprecation 일정 ⚙️ Action Metadata Syntax 📦 actions/checkout 🟢 actions/setup-node 🐍 actions/setup-python 🛠️ Actions Runner Releases