Actions lockfile 정식 출시: 초록색 검증에도 서로 다른 의미가 있어요

개발
조회 3

PR에서 uses의 버전은 그대로인데 실행할 코드가 바뀐다면 리뷰가 난감해져요. 태그가 가리키는 커밋은 움직일 수 있기 때문이에요. GitHub는 10월 28일 Actions workflow lockfile을 정식 출시했어요. 10월 중순 미리보기에서 다룬 고정 원리는 이어지지만, 이제 도입을 결정할 때는 어느 검사가 무엇을 확인하는지까지 살펴볼 만해요.

워크플로에는 읽기 좋은 이름, 실행에는 고정한 커밋

.github/workflows/actions.lock은 워크플로의 액션 참조와 실제 커밋을 연결해요. Free·Team·GitHub Enterprise Cloud 및 데이터 레지던시 환경에 제공되고, gh actions-lock으로 만들어요. 워크플로별로 도입할 수 있으므로 저장소의 모든 CI를 한 번에 바꿀 필요는 없어요. 수작업으로 파일을 조립하기보다 생성 결과와 워크플로 변경을 함께 리뷰하는 흐름이에요.

이해를 위한 가상 예로, workflow의 demo/build@v1이 처음에는 커밋 A를 가리키다가 B로 옮겨졌다고 해 볼게요. 참조만 쓰면 다음 실행에서 다른 코드로 해석될 수 있지만, lockfile은 기록한 커밋을 실행 대상으로 삼아요. 아래 그림은 이 참조 관계를 직접 그린 예시이며 실제 저장소 실행 기록은 아니에요. 고정한 A가 기록된 태그나 브랜치에서 더는 도달 가능하지 않다면 실행 시 거부될 수 있다는 조건도 함께 기억해야 해요.

직접 제작한 가상 참조 예시예요. v1의 이동과 lockfile의 고정을 비교하며, 실제 Actions 실행 화면은 아니에요.
직접 제작한 가상 참조 예시예요. v1의 이동과 lockfile의 고정을 비교하며, 실제 Actions 실행 화면은 아니에요.

오프라인에서 통과한 것은 어디까지일까요

공식 CLI는 gh actions-lock --verify-local과 gh actions-lock --verify를 구분해요. 전자는 네트워크를 쓰지 않고 uses마다 항목이 있는지 보는 coverage 검사예요. 빠른 커밋 전 확인에 어울리지만 원본 저장소와 커밋의 출처까지 확인했다는 뜻은 아니에요. 후자는 온라인으로 provenance를 확인하며, 러너도 작업 시작 때 다시 확인해요. 두 검사가 초록색으로 보이더라도 읽어야 할 의미가 달라요.

예를 들어 다른 PR에서 액션 참조를 추가했는데 lockfile을 갱신하지 않았다면 로컬 coverage 검사가 빠진 항목을 알려줄 수 있어요. 반대로 항목이 모두 있다는 사실만으로 기록한 커밋의 출처나 코드 안전성이 입증되지는 않아요. 아래 비교는 공식 문서의 검사 범위를 정리한 것이고 이 실행에서 CLI를 설치하거나 실제 검사를 돌린 결과는 아니에요.

공식 CLI 문서로 직접 정리한 검사 범위예요. --verify-local은 오프라인 coverage, --verify는 온라인 provenance 확인이며 실제 실행 결과 화면은 아니에요.
공식 CLI 문서로 직접 정리한 검사 범위예요. --verify-local은 오프라인 coverage, --verify는 온라인 provenance 확인이며 실제 실행 결과 화면은 아니에요.

재사용 워크플로를 부르는 순간 저장소 경계가 생겨요

액션이 내부에서 쓰는 액션, 즉 전이 의존성도 대상에 포함돼요. 그러나 jobs.<job_id>.uses로 부르는 재사용 워크플로 자체는 lockfile로 고정되지 않아요. 그 호출은 전체 커밋 SHA로 지정해야 해요. 불러온 워크플로 안의 액션은 호출한 쪽이 아니라 그 워크플로가 정의된 저장소의 lockfile을 따라요. 중앙 배포 워크플로를 여러 저장소가 공유할 때 특히 중요한 차이예요.

가령 앱 저장소가 플랫폼 저장소의 배포 워크플로를 호출한다고 해 볼게요. 앱의 actions.lock만 리뷰해서는 플랫폼 쪽 액션이 무엇으로 고정됐는지까지 알 수 없어요. 호출 SHA와 플랫폼 저장소의 의존성 변경을 함께 보면 연결이 드러나요. 또 runner 이미지·입력값·secret은 액션 코드 고정과 별개의 입력이에요. 같은 액션 커밋만으로 전체 빌드 환경까지 같아지는 것은 아니에요.

자동 갱신 PR에서 눈여겨볼 것은 파일 두 개예요

Dependabot이 도입된 워크플로의 액션 버전 업데이트를 열면 관련 lockfile 항목도 같은 PR에서 재생성해요. 리뷰 화면에서 읽기 좋은 버전 변경과 실제 커밋 변경을 함께 볼 수 있다는 점이 유용해요. 태그를 최신 상태로 따라가려는 --relock은 파일을 바꾸므로 읽기 전용 검증과 용도가 달라요. 바뀐 코드가 기대한 변경인지 판단하는 일은 리뷰에 남아요.

Require lockfile 정책으로 도입을 강제할 수 있지만, 정책부터 켜는 것만으로 재사용 워크플로의 경계가 사라지지는 않아요. 우선 한 워크플로에서 생성·리뷰·온라인 검증 흐름을 이해하면 확장할 때 무엇을 요구하는지도 분명해져요. 정식 출시의 가치는 고정을 쉽게 관리하게 해 준다는 데 있어요. 다음 PR에서 초록 표시를 볼 때는 항목 존재, 출처 확인, 코드 검토 중 어떤 근거가 확보됐는지 읽어보면 좋아요.

출처와 더 읽을거리

GitHub Changelog · 2026-10-28

GitHub Docs · Workflow dependency lockfiles

GitHub · gh-actions-lock