깃허브는 2026년 10월 14일 깃허브 액션의 빌드·테스트 자동화에서 외부 코드의 실행 버전을 고정하는 잠금 파일 기능을 발표했다. 개발자는 워크플로 파일에 읽기 쉬운 버전 이름을 남기면서도, 그 이름이 나중에 다른 코드를 가리켜 실행 대상이 바뀌는 일을 막을 수 있다.

기능은 변경될 수 있는 공개 미리보기다. 자동화 작업 절차인 워크플로를 선택해 적용하는 방식이며, 기존 워크플로에 자동으로 적용되지는 않는다.

같은 태그로 다른 코드가 실행되는 문제

액션은 워크플로 안에서 특정 작업을 맡는 구성 요소다. 다른 저장소의 액션을 가져다 쓰면 그 코드가 워크플로의 의존성이 된다. 잠금 없이 태그나 브랜치로 액션을 지정하면 실행 시점에 그 이름이 가리키는 코드가 선택된다.

태그는 책갈피처럼 다른 위치로 옮길 수 있는 이름이고, 커밋은 특정 시점의 코드 상태를 식별하는 기록이다. 브랜치도 개발이 진행되면서 가리키는 커밋이 바뀐다. 워크플로 파일에 적힌 태그가 그대로여도 제공자가 태그를 옮기면 다음 실행에서 선택되는 커밋은 달라질 수 있다.

기존에도 커밋의 전체 식별자를 워크플로 파일에 직접 적어 실행 대상을 고정할 수 있었다. 이번 기능은 사람이 읽기 좋은 버전 이름은 그대로 두고, 실제로 실행할 커밋을 별도 잠금 기록에 담는 대안이다.

이름은 유지하고 실행할 커밋은 기록

깃허브 문서에 따르면 잠금 파일에는 태그나 브랜치 같은 참조 이름과 선택한 커밋이 함께 기록된다. 적용된 워크플로는 이후 참조 이름이 다른 코드를 가리켜도 기록된 커밋을 실행한다.

가령 어떤 태그가 처음에는 커밋 A를 가리켰고, 이때 잠금 파일에 A를 기록했다고 하자. 나중에 제공자가 같은 태그를 커밋 B로 옮겨도 잠금이 적용된 워크플로는 A를 실행한다. 작동 원리를 설명하기 위한 가상 예시이며, 실제 실행 시험 결과는 아니다.

잠금 기록에는 소유자와 저장소의 숫자 식별자도 포함된다. 깃허브 액션은 실행할 때 이를 확인해 코드를 가져오는 저장소가 잠글 때와 같은 대상인지 검사한다. 코드 버전뿐 아니라 저장소의 정체성도 확인하는 방식이다.

잠금 범위에는 직접 호출하는 액션뿐 아니라 그 액션이 다시 사용하는 의존성도 포함된다. 워크플로 파일에 직접 적은 액션 아래에 이어지는 구성 요소까지 기록하므로, 검토 대상도 눈에 보이는 호출 목록보다 넓어진다.

깃허브는 잠금 파일을 도입한 저장소에서는 워크플로 파일에 커밋의 전체 식별자를 직접 적을 필요가 없다고 안내한다. 실행 대상의 고정을 없애는 것이 아니라, 고정할 위치를 워크플로 파일에서 잠금 파일로 옮기는 변화다.

저장소 경계와 안전성·재현성의 한계

재사용 워크플로는 다른 워크플로에서 불러 쓰는 작업 절차 묶음이다. 다른 저장소에 있는 이 묶음의 내부 의존성은 그 워크플로가 정의된 저장소의 잠금 파일이 담당한다. 호출하는 쪽의 파일 하나로 상대 저장소 내부까지 잠기지는 않으므로, 그쪽에서도 잠금 도입이 필요하다.

잠근 커밋은 원본 저장소의 브랜치 안에 존재해야 한다. 잠금 파일에 커밋을 기록한다는 설명이 어떤 커밋이든 위치와 관계없이 계속 실행할 수 있다는 뜻은 아니다.

깃허브는 잠금이 의존성 자체의 안전성을 판단하지 않는다고 명시한다. 실행할 코드를 고정해도 그 코드의 악성 동작이나 취약점은 별도로 검토해야 한다. 이 글은 발표와 문서에 근거한 설명이며, 독립적인 실행 시험이나 보안 개선 측정 결과는 아니다.

문서가 이점으로 내세우는 재현성도 의존성 커밋 선택의 범위에서 이해할 필요가 있다. 같은 커밋을 고르는 것은 빌드에 쓸 재료 하나를 고정하는 일이지, 결과 전체가 같다는 보장은 아니다. 실행 환경, 내려받는 패키지, 외부 서비스까지 같아지는 기능으로 해석할 근거는 없다.

제공 요금제와 도입 변경 사항 확인

발표에 명시된 제공 대상은 Enterprise Cloud, 데이터 레지던시(데이터 저장 지역 지정)를 사용하는 Enterprise Cloud, Team, Free 요금제다.

팀은 워크플로를 하나씩 선택하거나 한꺼번에 잠금 대상으로 등록할 수 있다. 워크플로 선택은 적용 범위를 정하는 일이고, 각 액션 의존성의 잠금 항목 생성은 그 범위를 기록하는 일이다. 확장이 잠금 파일과 워크플로 변경을 생성하며, 팀은 선택한 워크플로의 모든 액션 의존성에 항목이 있는지 확인하고 두 변경을 함께 검토·커밋한다.

확인할 파일은 .github/workflows/actions.lock이며, 생성과 유지에는 GitHub CLI의 gh actions-lock 확장을 사용한다. 문서는 이 파일을 손으로 편집하지 않도록 안내한다. 기록에서 ref는 태그나 브랜치 같은 참조 이름, commit은 커밋, owner_id와 repo_id는 각각 소유자와 저장소의 숫자 식별자다. 앞서 설명한 커밋의 전체 식별자는 SHA를 뜻한다.

검토할 때는 태그 이름뿐 아니라 기록된 커밋의 변경도 살핀다. 같은 태그를 유지한 채 잠금 기록이 A에서 B로 바뀌었다면 실행 대상이 바뀌는 변경이다. 파일이 생성됐다는 사실만으로 도입을 끝내기보다, 선택한 워크플로와 생성된 의존성 항목이 맞는지 확인하는 것이 핵심이다.

태그의 가독성과 실행 대상 고정을 함께 원하는 팀이라면 도입을 검토할 만하다. 적용할 워크플로를 정한 뒤 잠금 변경의 검토 담당을 정하고, 다른 저장소의 재사용 워크플로까지 사용한다면 그 저장소의 관리 책임도 구분할 필요가 있다.

이번 변화의 핵심은 태그를 없애는 것이 아니라, 실행할 커밋의 선택을 팀이 검토하고 유지하는 기록으로 옮기는 데 있다.