배포 코드는 그대로인데 실행 내용이 바뀐다면? GitHub Actions에 잠금 파일이 생겼습니다

배포 설정을 수정하지 않았는데도 외부 액션의 실행 내용은 달라질 수 있습니다. v3나 main 같은 이름이 가리키는 코드가 바뀔 수 있기 때문입니다. GitHub Actions의 workflow lockfile은 읽기 쉬운 버전 표기는 유지하면서, 실제로 실행할 액션의 커밋을 고정하는 장치입니다.

GitHub는 2026년 10월 28일 이 기능의 정식 제공을 발표했습니다. Free·Team·GitHub Enterprise Cloud에서 이용할 수 있으며, 데이터 레지던시를 사용하는 Enterprise Cloud도 포함됩니다. 공식 발표

버전 이름과 실행할 코드를 분리합니다

웹사이트를 배포하는 workflow에 외부 액션을 연결했다고 가정해 보겠습니다. 설정에는 같은 버전 이름이 남아 있어도 그 이름이 다른 커밋을 가리키면 다음 실행 내용이 달라질 수 있습니다. 변경 원인을 찾을 때 내 저장소의 수정 이력만 살펴봐서는 부족한 이유입니다.

잠금 파일은 검토한 코드의 식별자를 별도로 보관합니다. 잠금을 적용한 workflow에서는 직접 사용하는 액션뿐 아니라 액션이 다시 사용하는 의존성도 기록된 커밋으로 실행합니다. 버전 이름만 비교하는 대신 실제 실행 코드가 어디로 바뀌는지 검토할 수 있는 구조입니다. 작동 방식

커밋과 배포의 차이가 낯설다면 Git·GitHub·Vercel의 역할을 정리한 글을 먼저 읽어보셔도 좋습니다. 이번 기능은 그중 자동화 과정에서 불러오는 외부 코드의 변경을 관리하는 문제에 가깝습니다.

파일을 만드는 것보다 적용과 검토가 중요합니다

잠금 파일은 GitHub CLI 확장 도구인 gh actions-lock으로 생성하며, 경로는 .github/workflows/actions.lock입니다. 공식 문서는 직접 편집하지 말고 도구로 관리하도록 안내합니다. 파일을 두는 것만으로 끝나는 것도 아닙니다. 잠금을 사용할 workflow를 적용 대상으로 등록해야 하며, 이후에는 해당 workflow의 액션 의존성이 모두 잠금 파일에 있어야 합니다. 설정 원리

workflow별로 순차 적용할 수 있습니다. 적용된 workflow에서 Dependabot이 액션 버전 업데이트 PR을 열면 관련 잠금 항목도 함께 갱신합니다. 정식 제공 범위

도입할 때는 영향이 작은 workflow 하나부터 확인하는 편이 좋습니다. 직접 쓰는 액션과 그 액션이 다시 호출하는 의존성을 살피고, 생성된 변경을 검토한 뒤 시험 실행 결과를 비교해 볼 수 있습니다. 운영 배포를 한꺼번에 바꾸기보다 적용 범위를 나누면 문제가 생겼을 때 원인을 좁히기 쉽습니다.

이때 판단 기준은 잠금 파일의 유무만이 아닙니다. 필요한 업데이트를 누가 검토하고 승인할지, 시험 결과를 어디에 남길지도 함께 정해야 합니다. 오래된 코드를 계속 고정하는 것과 안전하게 운영하는 것은 같은 일이 아닙니다.

잠금 파일이 배포 전체를 보호하지는 않습니다

현재 공식 문서는 재사용 workflow 호출을 잠금 대상에서 제외합니다. 이런 호출은 별도로 전체 커밋 SHA를 지정해야 합니다. 호출된 workflow 내부의 액션 의존성은 그 workflow를 정의한 저장소의 잠금 파일이 담당합니다. 입력값·비밀정보·러너 이미지도 이 기능의 통제 범위가 아닙니다. 보호 범위와 한계

GitHub 공식 문서의 실제 화면. 액션 의존성과 잠금 대상 밖의 범위를 구분합니다. 문서 본문만 잘라 수록했으며 내용은 변경하지 않았습니다. 출처: GitHub Docs, CC BY 4.0. 2026년 10월 29일 한국시간 확인.

잠근 커밋에도 조건이 있습니다. 원본 액션 저장소의 기록된 태그나 브랜치에서 도달할 수 있어야 합니다. 다른 포크에만 있거나 그 연결이 끊긴 커밋은 실행 시 거부됩니다. 잠금 파일이 있으니 상위 저장소가 어떻게 바뀌어도 계속 실행된다고 생각하면 안 됩니다. 커밋 검증 조건

무엇보다 잠금 파일은 의존성 자체가 안전한지 판단하지 않습니다. 검토하지 않은 코드의 커밋을 고정했다고 그 코드가 안전해지는 것은 아닙니다. GitHub의 주의사항

이번 변화는 보안을 한 번에 해결하기보다, 배포 설정에 적힌 이름과 실제 실행할 코드를 연결해 검토할 수 있게 만드는 데 의미가 있습니다. 지금 확인할 것은 현재 workflow의 외부 액션, 재사용 workflow 호출, 그리고 업데이트 승인 절차입니다. 이 세 가지를 구분해두면 어디에 잠금을 적용하고 무엇을 별도로 관리해야 할지 판단할 수 있습니다.