GitHub Actions 캐싱 전략 완벽 가이드

GitHub Actions에서 빌드 시간을 획기적으로 단축시키는 캐싱 전략을 알아봅니다. npm, yarn, pnpm, pip 등 다양한 패키지 매니저별 캐싱 설정법과 효과적인 캐시 키 전략까지 초급 개발자도 쉽게 따라할 수 있도록 설명합니다.

---

목차

1. 캐싱이_필요한_이유
2. actions/cache_기본_사용법
3. npm/yarn_캐싱_설정
4. pnpm_캐싱_설정
5. Python_pip_캐싱
6. 캐시_키_전략

---

1. 캐싱이 필요한 이유

김개발 씨는 오늘도 Pull Request를 올리고 CI 파이프라인이 완료되기를 기다리고 있습니다. 5분, 10분, 15분...

커피 한 잔을 다 마셔도 아직 빌드가 진행 중입니다. "도대체 왜 이렇게 오래 걸리는 거지?" 하는 생각이 문득 스쳐 지나갑니다.

CI/CD 캐싱은 한마디로 반복되는 작업의 결과물을 저장해두고 재사용하는 것입니다. 마치 도서관에서 자주 빌리는 책을 별도 서가에 따로 모아두는 것과 같습니다.

매번 창고에서 책을 찾아올 필요 없이 빠르게 꺼내 쓸 수 있듯이, 캐싱을 활용하면 빌드 시간을 획기적으로 단축할 수 있습니다.

다음 코드를 살펴봅시다.

# 캐싱 없이 매번 의존성을 설치하는 워크플로우
name: Build Without Cache
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 매번 모든 패키지를 새로 다운로드합니다
      - name: Install dependencies
        run: npm install  # 수백 개의 패키지를 매번 다운로드

      # 빌드 실행
      - name: Build
        run: npm run build

김개발 씨는 입사 2개월 차 주니어 개발자입니다. 열심히 기능을 개발하고 Pull Request를 올리면, GitHub Actions가 자동으로 테스트와 빌드를 실행해줍니다.

문제는 이 과정이 너무 오래 걸린다는 것이었습니다. "PR 하나 올리는데 매번 15분씩 기다리니까 업무 효율이 너무 떨어져요." 김개발 씨가 팀 회의에서 불만을 토로했습니다.

선배 개발자 박시니어 씨가 웃으며 대답했습니다. "CI 파이프라인에 캐싱을 적용하면 그 시간을 절반 이하로 줄일 수 있어요." 그렇다면 캐싱이란 정확히 무엇일까요?

쉽게 비유하자면, 캐싱은 마치 냉장고와 같습니다. 매번 마트에 가서 재료를 사오는 대신, 자주 쓰는 재료를 냉장고에 미리 보관해두면 요리할 때 시간을 절약할 수 있습니다.

CI/CD 파이프라인에서도 마찬가지입니다. npm install 명령어가 실행될 때마다 수백 개의 패키지를 인터넷에서 다운로드하는 대신, 한번 다운로드한 패키지를 캐시에 저장해두고 재사용하는 것입니다.

캐싱이 없던 시절에는 어땠을까요? 개발자가 코드를 한 줄만 수정해도, CI 파이프라인은 처음부터 모든 작업을 다시 수행해야 했습니다.

node_modules 폴더에 들어가는 수천 개의 파일을 매번 새로 다운로드하고 압축을 풀어야 했습니다. 프로젝트가 커질수록 의존성도 늘어나고, 빌드 시간은 기하급수적으로 증가했습니다.

더 큰 문제는 비용이었습니다. GitHub Actions는 실행 시간에 따라 비용이 청구됩니다.

매번 불필요한 다운로드를 반복하면 그만큼 사용량이 늘어나고, 월말 청구서를 받아들 때 깜짝 놀라는 일이 생길 수 있습니다. 바로 이런 문제를 해결하기 위해 GitHub Actions의 캐싱 기능이 등장했습니다.

캐싱을 사용하면 첫 번째 빌드에서 다운로드한 의존성을 GitHub의 캐시 저장소에 보관해둡니다. 두 번째 빌드부터는 캐시에서 의존성을 불러오기 때문에 다운로드 시간이 거의 사라집니다.

보통 npm install에 3-5분 걸리던 작업이 10-20초로 단축됩니다. 위의 코드를 살펴보면, 캐싱이 없는 기본적인 워크플로우 구조를 볼 수 있습니다.

checkout으로 코드를 가져온 후, npm install로 의존성을 설치하고, 빌드를 실행합니다. 이 구조에서는 매번 모든 패키지를 새로 다운로드해야 합니다.

실제 현업에서 캐싱의 효과는 극적입니다. 대규모 프로젝트에서는 빌드 시간이 20분에서 5분으로 줄어드는 경우도 흔합니다.

개발팀 전체가 하루에 수십 번 PR을 올린다면, 캐싱으로 절약되는 시간은 엄청납니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝였습니다. "그럼 어떻게 설정하면 되나요?" 다음 장에서 본격적으로 캐싱 설정 방법을 알아보겠습니다.

실전 팁

💡 - 캐싱으로 빌드 시간을 50-80% 단축할 수 있습니다

• GitHub Actions 무료 계정은 캐시 저장소 10GB까지 사용 가능합니다

---

2. actions/cache 기본 사용법

박시니어 씨가 화면을 공유하며 설명을 시작했습니다. "캐싱의 핵심은 actions/cache라는 공식 액션이에요.

이걸 제대로 이해하면 어떤 종류의 파일이든 캐싱할 수 있습니다." 김개발 씨는 노트를 꺼내 열심히 메모를 시작했습니다.

actions/cache는 GitHub에서 공식으로 제공하는 캐싱 액션입니다. 워크플로우 실행 중 생성되는 파일이나 폴더를 저장해두었다가 다음 실행 때 복원해주는 역할을 합니다.

key와 path라는 두 가지 핵심 개념만 이해하면 자유자재로 활용할 수 있습니다.

다음 코드를 살펴봅시다.

name: Build With Cache
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 캐시를 복원하거나 새로 저장합니다
      - name: Cache node modules
        uses: actions/cache@v4
        with:
          # 캐싱할 폴더 경로
          path: node_modules
          # 캐시를 구분하는 고유 키
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}

      - name: Install dependencies
        run: npm install

김개발 씨가 질문했습니다. "캐시가 저장되고 복원되는 원리가 정확히 어떻게 되는 건가요?" 박시니어 씨가 천천히 설명을 이어갔습니다.

"사물함을 생각해보세요. 사물함마다 번호가 있고, 그 안에 물건을 넣어두죠.

actions/cache도 똑같아요." path는 사물함 안에 넣을 물건입니다. 어떤 폴더나 파일을 캐시에 저장할지 지정합니다.

대부분의 경우 node_modules처럼 의존성이 설치되는 폴더를 지정합니다. key는 사물함 번호입니다.

이 키가 같으면 같은 캐시를 사용하고, 다르면 새로운 캐시를 만듭니다. 위 코드에서는 package-lock.json 파일의 해시값을 키에 포함시켰습니다.

왜 해시값을 사용할까요? 의존성 목록이 변경되면 package-lock.json 파일도 변경됩니다.

파일이 변경되면 해시값도 달라지므로, 자동으로 새로운 캐시가 생성됩니다. 의존성이 그대로라면 해시값도 같으므로 기존 캐시를 재사용합니다.

워크플로우가 실행되면 actions/cache는 먼저 저장된 캐시 중에서 key와 일치하는 것을 찾습니다. 일치하는 캐시가 있으면 path에 지정된 경로로 복원합니다.

없으면 워크플로우가 끝날 때 해당 경로의 내용을 새 캐시로 저장합니다. 주의할 점이 있습니다.

캐시가 복원되더라도 npm install 명령어는 여전히 실행됩니다. 하지만 이미 node_modules가 있으므로 npm은 변경된 패키지만 확인하고 빠르게 종료됩니다.

완전히 새로 설치하는 것보다 훨씬 빠릅니다. 캐시가 hit되었는지 miss되었는지는 워크플로우 로그에서 확인할 수 있습니다.

"Cache restored from key..."라는 메시지가 나오면 캐시가 성공적으로 복원된 것입니다. runner.os를 키에 포함시킨 이유도 중요합니다.

Ubuntu와 macOS, Windows는 서로 다른 바이너리를 사용합니다. 운영체제가 다르면 캐시도 분리해야 호환성 문제를 피할 수 있습니다.

김개발 씨가 고개를 끄덕였습니다. "아, 그래서 키 설계가 중요하군요.

너무 넓으면 오래된 캐시를 쓰게 되고, 너무 좁으면 캐시 히트율이 낮아지겠네요." 박시니어 씨가 감탄했습니다. "정확해요!

그래서 restore-keys라는 옵션도 있어요. 정확히 일치하는 키가 없을 때 부분적으로 일치하는 캐시를 사용할 수 있게 해주죠.

이건 나중에 더 자세히 알아보겠습니다."

실전 팁

💡 - key에 반드시 lock 파일의 해시값을 포함시켜 의존성 변경을 감지하세요

• runner.os를 포함시켜 운영체제별로 캐시를 분리하세요

---

3. npm/yarn 캐싱 설정

"그럼 이제 실제로 npm 프로젝트에 캐싱을 적용해볼까요?" 박시니어 씨가 말했습니다. 김개발 씨의 프로젝트는 npm을 사용하고 있었습니다.

팀의 다른 프로젝트 중에는 yarn을 사용하는 것도 있어서, 둘 다 알아두면 좋을 것 같았습니다.

npm과 yarn은 Node.js 생태계에서 가장 널리 사용되는 패키지 매니저입니다. 각각 캐시 디렉토리 위치가 다르고, lock 파일 이름도 다릅니다.

npm은 package-lock.json을, yarn은 yarn.lock을 사용합니다. 최근에는 setup-node 액션에 캐싱 기능이 내장되어 더 간단하게 설정할 수 있습니다.

다음 코드를 살펴봅시다.

name: Node.js CI with Cache
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # setup-node의 내장 캐싱 사용 (권장)
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'  # 또는 'yarn'

      # 캐시가 있으면 빠르게 완료됩니다
      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

김개발 씨가 코드를 유심히 살펴봤습니다. "어?

아까 봤던 actions/cache가 없는데요?" 박시니어 씨가 웃으며 대답했습니다. "좋은 관찰이에요.

사실 actions/setup-node 버전 4부터는 캐싱 기능이 내장되어 있어요. cache 옵션에 npm이나 yarn을 지정하면 알아서 처리해줍니다." 내부적으로 setup-node는 npm의 글로벌 캐시 디렉토리를 찾아서 캐싱합니다.

npm의 경우 ~/.npm 디렉토리가, yarn의 경우 캐시 폴더가 자동으로 캐싱됩니다. 개발자가 경로를 직접 지정할 필요가 없어 실수할 여지가 줄어듭니다.

코드에서 npm install 대신 npm ci를 사용한 것도 주목해야 합니다. ci는 Continuous Integration의 약자로, CI 환경에 최적화된 설치 명령어입니다.

npm install과 npm ci의 차이점은 무엇일까요? npm install은 package.json을 기준으로 의존성을 설치하고, package-lock.json을 업데이트할 수도 있습니다.

반면 npm ci는 package-lock.json을 기준으로 정확히 명시된 버전만 설치하며, 기존 node_modules를 완전히 삭제한 후 새로 설치합니다. CI 환경에서는 npm ci가 더 적합합니다.

재현 가능한 빌드를 보장하고, 예상치 못한 버전 차이로 인한 문제를 방지할 수 있습니다. yarn을 사용하는 프로젝트라면 cache 옵션만 yarn으로 바꾸면 됩니다.

yarn의 경우 yarn install --frozen-lockfile 옵션이 npm ci와 비슷한 역할을 합니다. lock 파일과 맞지 않는 의존성이 있으면 에러를 발생시킵니다.

더 세밀한 제어가 필요하다면 actions/cache를 직접 사용할 수도 있습니다. 여러 폴더를 동시에 캐싱하거나, restore-keys를 활용한 부분 매칭이 필요할 때 유용합니다.

김개발 씨가 바로 자신의 프로젝트에 적용해봤습니다. 첫 번째 실행에서는 캐시가 없어 3분 30초가 걸렸지만, 두 번째 실행부터는 45초 만에 완료되었습니다.

"와, 진짜 빨라졌어요!" 박시니어 씨가 덧붙였습니다. "이 정도면 기본이에요.

더 최적화하려면 pnpm을 사용하는 방법도 있어요."

실전 팁

💡 - setup-node의 내장 캐싱이 가장 간단하고 안정적입니다

• CI 환경에서는 npm ci를 사용해 재현 가능한 빌드를 보장하세요

---

4. pnpm 캐싱 설정

"pnpm이요? npm이랑 뭐가 다른 건가요?" 김개발 씨가 물었습니다.

박시니어 씨가 설명했습니다. "pnpm은 Performant npm의 약자예요.

디스크 공간도 절약하고, 설치 속도도 빨라요. 우리 팀 신규 프로젝트들은 대부분 pnpm을 사용하고 있죠."

pnpm은 효율적인 패키지 관리를 위해 설계된 패키지 매니저입니다. 하드 링크와 심볼릭 링크를 활용해 디스크 공간을 절약하고, 병렬 설치로 속도도 빠릅니다.

GitHub Actions에서는 pnpm/action-setup 액션을 사용해 pnpm을 설치하고, setup-node와 함께 캐싱을 설정합니다.

다음 코드를 살펴봅시다.

name: pnpm CI with Cache
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # pnpm 설치
      - name: Install pnpm
        uses: pnpm/action-setup@v4
        with:
          version: 9

      # Node.js 설정과 pnpm 캐싱
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'

      # pnpm은 기본적으로 frozen lockfile을 사용합니다
      - name: Install dependencies
        run: pnpm install

      - name: Build
        run: pnpm build

김개발 씨는 pnpm이라는 이름을 처음 들어봤습니다. "npm, yarn도 있는데 왜 또 다른 패키지 매니저가 필요한 거예요?" 박시니어 씨가 비유를 들어 설명했습니다.

"도서관을 생각해보세요. npm은 책을 빌릴 때마다 복사본을 만들어줘요.

yarn은 조금 더 효율적이지만 여전히 각 프로젝트마다 같은 책의 복사본이 생깁니다." "pnpm은 다릅니다. 컴퓨터에 책의 원본 한 권만 보관하고, 각 프로젝트에서는 그 원본을 가리키는 링크만 만들어요.

같은 버전의 lodash를 10개 프로젝트에서 사용해도 실제 파일은 하나만 존재하는 거죠." 이런 구조 덕분에 pnpm은 디스크 공간을 크게 절약합니다. 대규모 모노레포에서는 그 차이가 극적입니다.

수십 개의 패키지가 공통 의존성을 공유하면 npm 대비 절반 이하의 공간만 사용할 수 있습니다. 설치 속도도 빠릅니다.

pnpm은 글로벌 저장소에서 패키지를 가져와 링크만 생성하면 되므로, 파일 복사가 필요한 npm보다 훨씬 빠릅니다. GitHub Actions에서 pnpm을 사용하려면 먼저 pnpm/action-setup 액션으로 pnpm을 설치해야 합니다.

그 후 setup-node에서 cache 옵션을 pnpm으로 지정하면 캐싱이 설정됩니다. 코드의 순서가 중요합니다.

pnpm/action-setup이 setup-node보다 먼저 실행되어야 합니다. setup-node가 pnpm의 캐시 디렉토리 위치를 알아내려면 pnpm이 먼저 설치되어 있어야 하기 때문입니다.

pnpm install 명령어는 기본적으로 CI 환경을 감지하면 frozen lockfile 모드로 동작합니다. pnpm-lock.yaml 파일과 맞지 않는 의존성이 있으면 설치가 실패하므로, 재현 가능한 빌드가 보장됩니다.

김개발 씨가 pnpm을 적용한 프로젝트의 빌드 시간을 확인해봤습니다. 캐시 히트 시 npm은 45초, pnpm은 25초였습니다.

"캐시가 있어도 이렇게 차이가 나네요!" 박시니어 씨가 고개를 끄덕였습니다. "새 프로젝트를 시작한다면 pnpm을 추천해요.

처음엔 낯설 수 있지만, 익숙해지면 돌아가기 어려울 거예요."

실전 팁

💡 - pnpm/action-setup은 반드시 setup-node보다 먼저 실행하세요

• 모노레포 프로젝트라면 pnpm의 장점이 더욱 극대화됩니다

---

5. Python pip 캐싱

다음 날, 김개발 씨는 데이터 분석팀의 이분석 씨에게서 도움 요청을 받았습니다. "저희 팀 Python 프로젝트 CI가 너무 느린데, 어제 캐싱으로 시간을 줄였다면서요?

저희 프로젝트에도 적용할 수 있을까요?"

Python pip 캐싱은 Node.js와 비슷한 원리지만 설정 방식이 조금 다릅니다. setup-python 액션에 내장된 캐싱 기능을 사용하거나, actions/cache로 직접 pip 캐시 디렉토리를 지정할 수 있습니다.

requirements.txt나 pyproject.toml 파일의 해시값을 키로 사용하는 것이 일반적입니다.

다음 코드를 살펴봅시다.

name: Python CI with Cache
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # setup-python의 내장 캐싱 사용
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
          cache: 'pip'
          # 의존성 파일 위치 지정
          cache-dependency-path: 'requirements.txt'

      # 캐시가 있어도 pip install은 실행해야 합니다
      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

김개발 씨가 이분석 씨의 프로젝트를 살펴봤습니다. 데이터 분석 프로젝트답게 pandas, numpy, scikit-learn 등 무거운 패키지들이 requirements.txt에 가득했습니다.

"이 패키지들 설치하는 데만 5분은 걸리겠네요." 김개발 씨가 말했습니다. actions/setup-python 액션도 setup-node처럼 캐싱 기능이 내장되어 있습니다.

cache 옵션에 pip을 지정하면 pip의 캐시 디렉토리를 자동으로 캐싱해줍니다. Python의 pip 캐시는 다운로드한 패키지 파일들을 저장해두는 공간입니다.

캐시가 있으면 인터넷에서 다시 다운로드할 필요 없이 로컬 캐시에서 바로 설치할 수 있습니다. cache-dependency-path 옵션은 어떤 파일을 기준으로 캐시 키를 생성할지 지정합니다.

대부분의 Python 프로젝트는 requirements.txt에 의존성을 명시하므로, 이 파일의 해시값이 캐시 키에 포함됩니다. requirements.txt가 변경되면 새로운 캐시가 생성됩니다.

pyproject.toml을 사용하는 프로젝트라면 cache-dependency-path를 pyproject.toml로 지정하면 됩니다. Poetry나 PDM 같은 도구를 사용한다면 해당 lock 파일을 지정할 수도 있습니다.

Node.js와 다른 점이 하나 있습니다. pip 캐싱은 패키지 파일만 캐싱하고, 설치된 결과물은 캐싱하지 않습니다.

따라서 pip install 명령어는 항상 실행되어야 합니다. 하지만 다운로드 단계가 생략되므로 시간은 크게 절약됩니다.

numpy나 pandas처럼 컴파일이 필요한 패키지는 효과가 더 큽니다. 이런 패키지들은 바이너리 wheel 파일을 다운로드하는데, 파일 크기가 수십 MB에 달하기도 합니다.

캐싱으로 다운로드를 생략하면 체감 속도 향상이 큽니다. 이분석 씨의 프로젝트에 캐싱을 적용한 결과, 의존성 설치 시간이 4분 30초에서 50초로 줄어들었습니다.

"와, 이렇게 간단한 설정으로 이렇게 빨라지다니!" 이분석 씨가 감탄했습니다. 김개발 씨가 뿌듯해하며 말했습니다.

"저도 어제 배운 거예요. 함께 성장하는 거죠."

실전 팁

💡 - Poetry 사용 시 cache: pip 대신 cache-dependency-path에 poetry.lock을 지정하세요

• virtualenv 전체를 캐싱하려면 actions/cache를 직접 사용하세요

---

6. 캐시 키 전략

일주일 후, 김개발 씨는 이상한 버그 리포트를 받았습니다. "CI에서 테스트가 실패하는데, 로컬에서는 잘 돌아가요." 조사해보니 오래된 캐시가 원인이었습니다.

박시니어 씨가 말했습니다. "캐시 키 전략을 잘못 세우면 이런 문제가 생겨요.

이번 기회에 제대로 배워봅시다."

캐시 키 전략은 언제 캐시를 갱신하고 언제 재사용할지를 결정하는 규칙입니다. 너무 넓은 키는 오래된 캐시를 계속 사용하게 만들고, 너무 좁은 키는 캐시 히트율을 떨어뜨립니다.

restore-keys를 활용한 폴백 전략과 주기적인 캐시 무효화가 핵심입니다.

다음 코드를 살펴봅시다.

name: Smart Cache Strategy
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Cache with fallback strategy
        uses: actions/cache@v4
        with:
          path: node_modules
          # 정확한 매칭을 위한 기본 키
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
          # 폴백을 위한 restore-keys
          restore-keys: |
            ${{ runner.os }}-node-

      # 주간 캐시 갱신이 필요한 경우
      - name: Weekly cache refresh
        uses: actions/cache@v4
        with:
          path: ~/.cache/heavy-deps
          # 주 단위로 캐시 갱신
          key: ${{ runner.os }}-weekly-${{ hashFiles('deps.lock') }}-week-${{ github.run_id }}
          restore-keys: |
            ${{ runner.os }}-weekly-${{ hashFiles('deps.lock') }}-
            ${{ runner.os }}-weekly-

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "캐시 키 전략은 마치 주소 체계와 같아요." 정확한 주소가 있으면 바로 찾아갈 수 있습니다.

"서울시 강남구 테헤란로 123번지 4층 502호"처럼요. 하지만 정확한 주소를 모르면 어떻게 할까요?

일단 "서울시 강남구 테헤란로"까지 가서 찾아볼 수 있습니다. restore-keys가 바로 이런 폴백 역할을 합니다.

key로 지정한 정확한 캐시가 없으면, restore-keys에 나열된 접두사로 시작하는 캐시 중 가장 최근 것을 사용합니다. 위 코드에서 key는 운영체제와 package-lock.json 해시값으로 구성됩니다.

package-lock.json이 변경되면 새로운 키가 생성되어 캐시 미스가 발생합니다. 하지만 restore-keys 덕분에 완전히 처음부터 시작하지 않아도 됩니다.

이전 버전의 node_modules를 복원한 후, npm install이 변경된 부분만 업데이트합니다. 완전히 새로 설치하는 것보다 훨씬 빠릅니다.

키 설계 시 주의할 점이 있습니다. 첫째, 너무 넓은 키는 위험합니다.

예를 들어 key: node-cache처럼 고정된 문자열만 사용하면 의존성이 변경되어도 계속 같은 캐시를 사용합니다. 오래된 버전의 패키지가 남아있어 예상치 못한 버그가 발생할 수 있습니다.

둘째, 너무 좁은 키도 문제입니다. key에 커밋 해시까지 포함시키면 거의 모든 빌드에서 캐시 미스가 발생합니다.

캐싱의 의미가 없어지는 것이죠. 시간 기반 캐시 갱신이 필요한 경우도 있습니다.

보안 패치가 자주 나오는 의존성이라면 주기적으로 캐시를 갱신하는 것이 좋습니다. 두 번째 캐시 설정에서 github.run_id를 사용한 것은 매번 새 키를 생성하지만, restore-keys로 이전 캐시를 활용하는 전략입니다.

캐시 저장 공간에도 한계가 있습니다. GitHub Actions는 저장소당 10GB의 캐시 공간을 제공합니다.

공간이 부족해지면 오래된 캐시부터 자동으로 삭제됩니다. 따라서 불필요하게 큰 폴더를 캐싱하지 않도록 주의해야 합니다.

김개발 씨가 문제의 원인을 찾았습니다. 한 달 전에 삭제된 패키지가 캐시에 남아있어서 로컬과 CI 환경이 달랐던 것입니다.

restore-keys 전략을 적용하고, 의심스러운 캐시는 GitHub UI에서 수동으로 삭제하니 문제가 해결되었습니다. "캐싱은 양날의 검이군요.

잘 쓰면 시간을 절약하지만, 잘못 쓰면 디버깅 지옥에 빠질 수 있겠어요." 김개발 씨의 말에 박시니어 씨가 웃으며 대답했습니다. "그래서 전략이 중요한 거예요."

실전 팁

💡 - restore-keys는 항상 구체적인 것에서 일반적인 순서로 나열하세요

• 디버깅이 어려운 캐시 문제는 GitHub Actions UI에서 캐시를 삭제하고 다시 시작하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!