GitHub Actions 캐시 키, AI 코드보다 여기서 시간이 더 줄더라

빌드 느리면 AI 도구 붙여도 답답하다

요즘은 코드 생성이나 리뷰 자동화 얘기가 워낙 많아서 시선이 그쪽으로 쏠린다. 근데 실제 작업 흐름에서 답답함을 만드는 건 의외로 빌드 시간인 경우가 많다. 나도 한동안 PR 만들 때마다 테스트 기다리는 시간이 제일 아까웠다. AI가 코드 몇 줄 빨리 써줘도, CI가 매번 7분씩 잡아먹으면 체감 이득이 확 줄어든다.

그래서 GitHub Actions에서 다시 보게 된 게 캐시 키였다. 너무 기본 기능처럼 보여서 대충 넣고 지나가기 쉬운데, 이걸 제대로 잡아두면 생각보다 많이 줄어든다. 특히 npm, pnpm, Gradle, pip처럼 의존성 내려받는 시간이 긴 프로젝트는 차이가 바로 난다.

중요한 건 캐시를 켜는 게 아니라 키를 잘 나누는 거다

예전엔 운영체제랑 lock 파일 정도만 넣고 끝냈다. 그런데 실제로는 브랜치 전략, 패키지 매니저, 빌드 산출물 성격에 따라 키를 좀 더 나눠야 했다. 너무 넓게 잡으면 깨진 캐시를 오래 끌고 가고, 너무 촘촘하면 캐시 적중률이 떨어진다. 써봤는데 정답은 하나가 아니었다. 프로젝트마다 타협점이 달랐다.

예를 들어 의존성 캐시와 프레임워크 빌드 캐시는 분리하는 편이 훨씬 다루기 쉬웠다. lock 파일이 바뀌지 않았는데도 빌드 캐시까지 같이 날아가면 체감 손해가 컸다. 복원 키를 적당히 두는 것도 중요했다. 이런 건 화려하지 않은데, 팀 전체 시간엔 꽤 직접적으로 영향을 준다.

AI 시대일수록 CI 기본기가 더 티 난다

좀 웃긴 얘기지만, AI 코딩 도구를 쓰기 시작한 뒤 오히려 CI 병목이 더 두드러졌다. 코드가 빨리 나오니까 검증 단계가 상대적으로 더 느리게 느껴진다. 결국 개발 속도를 결정하는 건 생성만이 아니라 피드백 루프다. 테스트, 린트, 빌드, 배포 미리보기까지 얼마나 빨리 도느냐가 진짜 중요해졌다.

물론 캐시도 만능은 아니다. 네이티브 모듈이 섞여 있거나 환경 차이가 큰 프로젝트는 캐시 때문에 더 꼬일 때도 있다. 그래서 나는 캐시 히트율이 낮거나 오류가 잦은 경로는 과감히 빼는 편이다. 다 캐시하겠다는 욕심은 대체로 오래 못 간다.

요즘은 워크플로우에서 가장 먼저 기다림을 본다

새 도구를 붙일 때도 결국 기준은 비슷하다. 팀이 어디서 기다리고 있는지 보는 것. GitHub Actions 캐시 키는 엄청 새롭진 않지만, 의외로 아직도 손댈 여지가 많다. 솔직히 AI 기능보다 덜 멋있다. 그래도 하루에 여러 번 돌리는 파이프라인이면, 여기서 줄어든 1분이 훨씬 크게 남는다.

---

📎 참고 자료

• GitHub Docs: caching dependencies to speed up workflows
• actions/cache
• GitHub Docs: variables in workflows