GitHub Actions lockfile이란?｜사이트 자동 배포 버전 고정과 보안 점검 차이

GitHub Actions lockfile은 자동 작업에서 사용할 action의 정확한 코드 버전을 기록하는 잠금파일입니다. 워크플로에 읽기 쉬운 버전 이름을 남기면서 실제 실행은 기록된 커밋을 사용하도록 돕습니다. 다만 버전을 고정하는 기능이므로, 그 코드가 안전한지까지 자동으로 보증하지는 않습니다.

확인 기준: 2026-11-02｜GitHub의 2026년 10월 28일 정식 제공 발표와 공식 문서 기준입니다. 이 글은 도입 판단을 위한 개념 안내이며, 특정 저장소에 적용하거나 배포 성공을 시험한 기록은 아닙니다.

조회 전 핵심 3가지

• 무엇을 고정하나요? 적용한 워크플로가 사용하는 action의 실행 커밋을 기록합니다.
• 누가 살펴봐야 하나요? GitHub Actions로 사이트 빌드·배포 등 자동 작업을 운영하는 사람입니다.
• 안전까지 보장하나요? 아닙니다. 의존성 검토와 업데이트 관리는 계속 필요합니다.

목차

1. 내 블로그·사이트에도 필요한가?
2. 워크플로·action·태그·SHA 뜻
3. actions.lock의 역할과 범위
4. 버전 고정과 보안 점검의 차이
5. 도입 전 확인할 순서
6. 자주 묻는 질문

티스토리 운영자도 GitHub Actions lockfile을 만들어야 하나요?

티스토리 편집기에서 글을 작성한다는 이유만으로 필요한 기능은 아닙니다. 먼저 자신의 사이트 운영 과정에 GitHub Actions가 포함돼 있는지 확인해야 합니다.

예를 들어 GitHub에 원고나 코드를 올리면 사이트 파일을 만들고 서버에 보내는 자동 작업을 구성한 경우라면 관련이 있습니다. 반면 글 작성·이미지 업로드·발행을 블로그 관리자 화면에서만 처리한다면, 이 파일을 티스토리 HTML 본문에 넣을 이유는 없습니다.

도입 판단 질문: “내 저장소에서 GitHub Actions가 실행되는가?”부터 확인하세요. 저장소를 사용한다는 사실과 Actions로 자동 배포한다는 사실은 서로 다릅니다.

워크플로·action·태그·커밋 SHA를 쉽게 구분하기

잠금파일을 이해하려면 자동 작업의 순서와 그 안에서 가져다 쓰는 도구를 나눠 보면 됩니다. 아래 비유는 용어를 이해하기 위한 설명입니다.

GitHub Actions 잠금파일 관련 용어

용어	뜻	쉬운 비유
워크플로	자동으로 수행할 작업의 구성	사이트를 만드는 작업 순서표
action	워크플로에서 사용하는 재사용 가능한 작업 단위	순서표에서 불러 쓰는 도구
태그·브랜치	코드의 특정 지점을 가리키는 이름. 가리키는 커밋이 바뀔 수 있음	이름은 같아도 붙어 있는 대상이 바뀔 수 있는 표지
커밋 SHA	특정 커밋을 식별하는 값	검토한 코드 시점을 특정하는 식별번호
lockfile	실행할 action의 커밋 등을 기록한 파일	사용할 도구의 정확한 버전을 적은 목록

핵심은 버전 이름을 적어 둔 것과 실행할 커밋을 고정한 것이 같지 않다는 점입니다. 잠금파일은 읽기 쉬운 참조와 실제 실행할 코드의 연결을 관리하는 역할을 합니다.

actions.lock은 어디에 있고 무엇을 고정하나요?

공식 문서가 안내하는 파일 위치는 .github/workflows/actions.lock입니다. GitHub CLI 확장인 gh actions-lock으로 생성하며, 손으로 내용을 편집하는 파일로 안내되지 않습니다.

적용 대상에는 직접 사용하는 action뿐 아니라, 그 action이 다시 사용하는 action 의존성도 포함됩니다. 다만 다른 재사용 워크플로를 호출하는 것까지 호출한 쪽 잠금파일로 모두 고정하는 것은 아닙니다. 재사용 워크플로 호출은 전체 커밋 SHA로 고정하고, 그 내부 action 의존성은 해당 워크플로가 정의된 저장소의 잠금파일 범위로 확인해야 합니다.

또한 이 파일이 통제하는 것은 해당 action 코드입니다. 입력값·비밀키·러너 이미지 등 다른 실행 조건까지 고정하지 않으므로, 잠금파일이 있다는 이유만으로 사이트 빌드 결과가 모든 환경에서 완전히 같아진다고 보장할 수는 없습니다.

버전 고정과 보안 점검은 어떻게 다른가요?

버전 고정은 “어떤 코드를 실행할지”를 정하고, 보안 점검은 “그 코드를 사용해도 괜찮은지”를 검토합니다. 검토하지 않은 코드를 고정하면, 검토하지 않은 바로 그 코드가 계속 사용될 수 있습니다.

GitHub도 잠금파일이 예상치 못한 의존성 변경을 방지하는 데 도움이 되지만 의존성의 안전성을 판정하지는 않는다고 설명합니다. 따라서 파일을 만든 뒤에도 업데이트 내용을 읽고, 사용 중인 버전과 저장소의 변경을 확인하는 과정이 필요합니다.

운영 관점에서는 예상하지 않은 변경을 줄이는 일과 필요한 업데이트를 받아들이는 일을 함께 관리해야 합니다. 잠갔으니 영구히 업데이트하지 않아도 된다는 해석은 적절하지 않습니다.

초보 운영자가 도입 전 확인할 순서

GitHub는 2026년 10월 28일 잠금파일 기능의 정식 제공을 발표했습니다. 발표에는 Free·Team·Enterprise Cloud와 데이터 레지던시 지원 Enterprise Cloud가 포함됩니다. 다만 설치·정책을 변경하기 전에는 자신의 서비스 환경과 최신 공식 안내를 확인하세요. 이를 모든 GitHub 제품·서버 버전의 지원으로 확대해서는 안 됩니다.

1. 현재 작업 파악: 어떤 워크플로가 사이트를 만들고 배포하는지 확인합니다.
2. 참조 검토: 사용 중인 action의 출처와 버전이 적절한지 먼저 살펴봅니다.
3. 생성 범위 결정: 공식 도구는 워크플로 하나부터 적용하는 방식도 지원합니다.
4. 전체 변경 비교: 잠금파일뿐 아니라 워크플로에서 변경된 내용도 검토합니다.
5. 운영 전 검증: 변경 검토와 실행 결과 확인을 거쳐 운영 배포에 반영합니다.

공식 설치 안내는 도구가 잠금파일 외의 워크플로 참조도 변경할 수 있다고 설명합니다. 조직에서 허용된 action만 실행하게 설정했다면 정책과의 호환성도 확인해야 합니다. 이 글에서는 실제 저장소를 수정하거나 실행하지 않았으므로 생성·배포 성공을 전제하지 않습니다.

업데이트 관리에는 Dependabot도 관련됩니다. GitHub 안내에 따르면 이미 잠금파일을 적용한 워크플로의 action 버전 업데이트 PR에서 해당 잠금 항목을 함께 갱신할 수 있습니다. 변경 제안이 생성되는 것과 그 변경을 검토·승인하는 일은 구분해야 합니다.

GitHub 공식 잠금파일 생성·적용 절차 확인하기

GitHub Actions lockfile 자주 묻는 질문

Q. actions.lock을 티스토리 HTML에 붙여 넣나요?

아닙니다. GitHub 저장소의 워크플로 의존성을 관리하는 파일입니다. 블로그 본문에 넣는 코드나 검색 최적화 메타 태그가 아닙니다.

Q. 파일 이름만 맞춰 만들면 적용되나요?

파일 이름만 만드는 것으로 적용을 확인할 수 없습니다. 공식 생성 도구와 워크플로 적용 절차를 따르고, 생성된 변경 사항을 검토해야 합니다.

Q. 잠금파일이 있으면 자동 배포 오류를 모두 막을 수 있나요?

그렇지 않습니다. 코드 버전 외에도 권한·비밀키·실행환경·사이트 설정 등이 작업에 영향을 줄 수 있습니다. 실패 원인은 실행 로그와 해당 환경을 함께 확인해야 합니다.

Q. 기존 SHA 고정을 모두 지워야 하나요?

일괄 삭제부터 할 필요는 없습니다. 잠금파일의 적용 범위와 기존 참조를 확인하고 공식 도구가 만든 변경을 검토하세요. 특히 재사용 워크플로 호출은 action과 적용 범위가 다릅니다.

공식 자료로 확인하기

• GitHub 잠금파일 정식 제공 발표 — 발표일·지원 플랜·안전성 한계
• Workflow dependency lockfiles 개념 — action 의존성·SHA·적용 범위
• 잠금파일 생성·유지 절차 — 변경 검토·워크플로 적용·업데이트
• 공식 gh-actions-lock 저장소 — 도구 안내·최신 사용법