개발자의 시간은 금이다: 깃허브 액션 캐싱으로 배포 속도 50% 단축하고 연봉 올리는 법
안녕하세요. 15년 차 백엔드 개발자이자, 여러분과 같은 고민으로 수많은 밤을 지새운 동료입니다. 개발자로서 우리가 하루 중 가장 많이 기다리는 시간이 언제일까요? 커피 머신 앞? 엘리베이터? 아닙니다. 바로
CI/CD 파이프라인이 돌아가는 그 지루한 로딩 바 앞입니다.
솔직히 고백하자면, 저도 주니어 시절에는 "배포 걸어놓고 커피 한 잔 마시는 게 국룰이지"라며 그 시간을 휴식 시간처럼 여겼습니다. 하지만 시니어, 그리고 팀을 리딩하는 위치에 오르니 그 10분, 15분이 쌓여 얼마나 거대한 생산성 손실을 만드는지 뼈저리게 느끼게 되더군요. 코드를 수정하고 결과를 확인하는 '피드백 루프(Feedback Loop)'가 느려지면, 개발자의 몰입도(Flow)는 급격히 떨어집니다. 방금 짠 로직이 기억나지 않아 다시 코드를 들여다보는 '컨텍스트 스위칭(Context Switching)' 비용, 다들 경험해보셨죠?
오늘은 깃허브 액션(GitHub Actions)을 사용할 때, 가장 큰 병목 구간인
'의존성 패키지 설치' 단계를 획기적으로 줄이는 방법에 대해 아주 깊이 있게 이야기해보려 합니다. 단순히 "이거 복사해서 쓰세요"가 아닙니다. 원리를 이해하고, 내 프로젝트에 딱 맞는 최적화 전략을 세울 수 있도록 돕겠습니다. 제 경험상 이 설정 하나만 제대로 해도 배포 시간을 절반, 아니 그 이상으로 줄일 수 있습니다. 자, 커피는 배포 기다릴 때가 아니라, 다 끝내고 여유롭게 마시는 겁니다. 시작해볼까요? 🚀
1. 왜 매번 새롭게 설치할까? CI/CD 환경의 딜레마
🔥 깨끗한 환경(Clean Slate)의 역설
CI/CD의 핵심 철학 중 하나는 '완벽하게 격리된 환경'입니다. 내 로컬 컴퓨터에서는 잘 돌아가는데 서버에서는 안 돌아가는, 그 악명 높은 "It works on my machine" 문제를 해결하기 위함이죠. 그래서 깃허브 액션은 워크플로우가 실행될 때마다 완전히 새로운 가상 머신(Runner)을 띄웁니다. 마치 공장에서 갓 포장을 뜯은 새 노트북을 켜는 것과 같습니다.
문제는 여기서 발생합니다. 텅 빈 깡통 컴퓨터이기에, 프로젝트를 실행하기 위한 모든 라이브러리(node_modules, pip packages, gradle dependencies 등)를 처음부터 다시 다운로드해야 합니다. 인터넷 속도가 아무리 빨라졌다고 해도, 수천 개의 작은 파일들을 다운로드하고, 압축을 풀고, 디스크에 쓰는 작업은 물리적인 시간을 요구합니다.
상상해보세요:
여러분이 요리를 할 때마다 마트에 가서 소금, 설탕, 간장, 식용유를 매번 새로 사와야 한다면 어떨까요? 심지어 요리가 끝나면 남은 재료를 모두 버려야 합니다. 요리하는 시간보다 장보는 시간이 더 걸릴 겁니다. 우리는 보통 양념통(Cache)에 이런 재료를 보관해두고 꺼내 씁니다. CI/CD도 마찬가지여야 합니다.
📊 데이터로 보는 낭비: 네트워크와 CPU의 비명
실제 제가 컨설팅했던 A사의 사례를 들어보겠습니다. 이 회사는 Node.js 기반의 대규모 모노레포를 운영 중이었으며, 하루에 약 50회의 배포가 일어났습니다. 캐싱 적용 전의 데이터는 처참했습니다.
- 전체 빌드 시간: 12분 30초
- npm install 소요 시간: 7분 40초 (전체의 약 61% 차지)
- 실제 테스트 및 빌드 시간: 4분 50초
- 하루 낭비되는 시간: 7분 40초 × 50회 = 약 6.4시간
놀랍지 않나요? 전체 시간의 60% 이상을 인터넷에서 파일을 다운로드하고 압축을 푸는 데 쓰고 있었습니다. 이는 단순히 시간 낭비일 뿐만 아니라, 깃허브 액션의 무료 사용량(분)을 갉아먹고, 유료 플랜을 사용하는 경우 비용 증가로 직결됩니다.
네트워크 대역폭도 문제지만, 압축된 패키지를 풀고 디스크에 쓰는 I/O 작업, 그리고 수만 개의 파일을 링크하는 과정에서 CPU 자원도 상당히 소모됩니다. 이 과정을 생략할 수 있다면 우리는 엄청난 이득을 얻을 수 있습니다.
2. 캐싱(Caching)의 마법: 원리와 메커니즘 심층 분석
💡 깃허브 액션 캐시의 작동 원리
캐싱을 적용하기 위해 우리가 사용할 도구는 주로 `actions/cache` 액션입니다. 이 녀석이 어떻게 작동하는지 원리를 깊이 이해해야 나중에 발생할 문제를 해결할 수 있습니다. 작동 방식은 크게
저장(Save)과
복원(Restore) 두 단계로 나뉩니다.
- 키(Key) 확인: 워크플로우가 시작되면 우리가 지정한 고유한 '키'를 가지고 깃허브의 내부 저장소를 뒤집니다. "이 키랑 똑같은 이름표를 가진 보따리가 있나요?"라고 묻는 과정입니다.
- 복원(Restore): 만약 일치하는 키가 있다면(Cache Hit), 그 보따리를 가져와서 지정된 경로에 풀어놓습니다. 인터넷에서 다운로드하는 것보다 디스크 복사가 훨씬 빠릅니다.
- 실행: 의존성 설치 명령어를 실행합니다. 이때 스마트한 패키지 매니저(npm, yarn, pip 등)들은 이미 파일이 존재하므로 다운로드를 건너뛰고 정합성만 체크합니다.
- 저장(Save): 워크플로우가 성공적으로 끝나면, 'Post' 단계에서 현재 의존성 폴더를 다시 압축해서 새로운 키로 저장합니다(만약 키에 해당하는 캐시가 없었다면).
여기서 가장 중요한 개념은 바로
'키(Key)'입니다. 키는 캐시 데이터의 지문과 같습니다.
🧩 해시(Hash)의 중요성: 파일이 변하면 키도 변해야 한다
초보 개발자들이 가장 많이 하는 실수가 있습니다. 키 이름을 그냥 `my-cache-v1` 처럼 고정된 문자열로 박아버리는 것입니다. 이렇게 되면 의존성 설정 파일(`package-lock.json`이나 `yarn.lock`)이 변경되어도, 깃허브 액션은 "어? 키가 똑같네? 옛날 캐시 써야지"라고 판단합니다. 결과는? 빌드 오류이거나 과거 버전 라이브러리가 설치되는 참사가 일어납니다.
그래서 우리는
파일 해시(File Hash)를 사용해야 합니다.
해시(Hash)란?
파일의 내용을 수학적 알고리즘으로 계산해 고유한 문자열로 만드는 것입니다. `package-lock.json` 파일에 공백 하나만 추가되어도 해시 값은 완전히 달라집니다. 이를 이용해 우리는 "의존성 목록이 바뀌었을 때만" 새로운 캐시를 생성하도록 만들 수 있습니다. `hashFiles('**/package-lock.json')` 함수가 바로 그 역할을 합니다.
3. 실전 적용: 단계별 설정 가이드 (코드 없이 설명하기)
이제 구체적으로 어떻게 설정하는지, 제가 옆에서 코딩을 봐드리는 것처럼 설명해드리겠습니다. 코드를 직접 보여드릴 순 없지만, 구조를 머릿속에 그려보세요. 이 설명대로 작성하면 100% 동작합니다.
📋 단계별 실행 가이드
- 1단계: 체크아웃(Checkout) 이후 위치 선정
캐시 액션은 소스 코드를 내려받는 `actions/checkout` 단계 바로 다음에 위치해야 합니다. 왜냐하면 의존성 설정 파일(`lock` 파일)이 있어야 해시 키를 계산할 수 있기 때문입니다. 순서가 바뀌면 파일이 없어서 에러가 납니다.
- 2단계: 경로(Path) 지정하기
가장 먼저 고민해야 할 것은 "무엇을 캐싱할 것인가"입니다. 언어별로 저장되는 위치가 다릅니다.
- Node.js (NPM): `~/.npm` (NPM 캐시 디렉토리) 또는 `node_modules` (직접 폴더)
- Node.js (Yarn): Yarn 캐시 폴더 (명령어로 알아내야 함)
- Python (Pip): `~/.cache/pip`
- Java (Gradle): `~/.gradle/caches`
처음에는 `node_modules` 통째로 캐싱하는 것을 시도하지만, 사실 NPM의 내부 캐시 폴더(`~/.npm`)를 캐싱하는 것이 더 안정적일 때가 많습니다. 하지만 속도는 `node_modules`를 직접 캐싱하는 게 압도적으로 빠릅니다.
- 3단계: 키(Key) 설계하기 (핵심!)
키는 보통 세 부분으로 조합합니다: [운영체제 정보] - [언어/도구 이름] - [의존성 파일의 해시값]
예를 들어, `Runner.os` 변수와 `package-lock.json` 파일의 해시값을 조합하는 식입니다. 이렇게 하면 운영체제가 바뀌거나(리눅스에서 윈도우로), 패키지가 하나라도 바뀌면 키가 달라져서 새 캐시를 생성하게 됩니다.
- 4단계: 복원 키(Restore-keys) 설정
이것은 '보험'입니다. 정확히 일치하는 키가 없을 때, 비슷항 키라도 가져올지 결정하는 것입니다. 예를 들어 의존성이 하나 바뀌어서 해시가 달라졌더라도, 완전히 쌩으로 다시 받는 것보다는 이전 버전의 캐시라도 가져와서(부분적으로 재사용하고) 나머지만 받는 게 빠르겠죠? 이때 접두사(Prefix)를 지정해줍니다.
4. 캐싱 방식 비교 분석표: 무엇을 선택해야 할까?
최근
댓글
댓글 쓰기