GitHub Actions가 느린 이유: 작업마다 반복되는 준비 없애기
느린 GitHub Actions 작업은 대부분의 시간을 첫 테스트가 돌기 전에 써요. Node를 설정하고, 의존성을 받고, Docker 이미지를 빌드해요. 푸시할 때마다 같은 시간이 들고, 그동안 팀의 누군가는 초록색 체크를 기다려요. 분 단위 청구라면 그 시간에도 돈을 내요.
Skipbox는 작업 사이에도 머신을 유지하는 GitHub Actions 실행기라서, 한 작업이 설치한 것이 다음 작업을 위해 디스크에 그대로 있어요. runs-on: skipbox 한 줄만 바꾸면, 작업이 내 전용 머신에서 월 $39 정액에 실행 시간 무제한으로 돌아요.
모든 작업이 빈 VM에서 시작해요
GitHub 호스팅 실행기는 작업마다 새 가상 머신이에요. 지난 작업이 받거나 빌드한 것이 하나도 없으므로, 작업마다 같은 상태를 다시 만들어요.
| 단계 | GitHub 호스팅 실행기 | Skipbox |
|---|---|---|
| Node, Python, Java 설정 | 툴체인을 받아요 | 지난 작업의 도구 캐시에서 찾아요 |
| 의존성 설치 | 캐시 아카이브를 받아서 풀어요. 캐시가 없으면 레지스트리에서 전부 받아요 | 디스크에 있는 패키지 관리자 캐시를 읽어요 |
| Docker 이미지 빌드 | 레이어 없이 시작해 모든 단계를 다시 빌드해요 | 지난 빌드의 레이어를 다시 써요 |
| 테스트 실행 | 프라이빗 리포지토리의 ubuntu-latest는 CPU 2개 | 4 vCPU 이상 |
위의 세 줄은 새로운 것을 하나도 만들지 않아요. 머신을 어제 상태로 되돌릴 뿐이에요.
GitHub의 캐시는 이 문제를 줄여 줄 뿐, 없애지는 못해요. 리포지토리당 10 GB까지 담고, 7일 동안 어떤 작업도 읽지 않은 항목은 지우고, 새 기능 브랜치는 다른 기능 브랜치의 캐시를 읽지 못해요. 캐시가 맞아도 실행마다 아카이브를 받고 풀어요.
기다리는 동안 드는 비용
작업마다 준비에 3분이 걸리고, 팀이 하루에 작업을 100개 돌린다고 해 봐요. 하루 300분의 실행기 시간을 머신을 되돌리는 데 쓰는 셈이고, 풀 리퀘스트마다 그 몫만큼 기다려요. 리뷰가 늦게 시작되고, 병합이 늦어지고, 엔지니어는 기다리는 동안 다른 일로 넘어가요.
분 단위 청구라면 그 시간이 청구서에 올라가요. 4 vCPU 실행기를 월 실행 시간별로 보면:
| 월 실행 시간(4 vCPU) | GitHub | Skipbox S | 매달 아끼는 금액 |
|---|---|---|---|
| 10,000분 | $102 | $39 | $63 |
| 20,000분 | $222 | $39 | $183 |
| 30,000분 | $342 | $39 | $303 |
GitHub 금액은 GitHub Team에 포함된 사용량을 뺀 청구액이에요. 내 실행 시간은 홈페이지의 계산기에 넣어 보세요. 로그인은 필요 없어요.
게다가 실행 횟수는 늘기만 해요.
- AI 코딩 에이전트. 에이전트가 푸시할 때마다 CI가 시작돼요. 기다림과 청구액은 인원이 아니라 푸시 수를 따라 늘어요.
- 늘어나는 테스트. E2E 테스트나 행렬은 더해지는 작업마다 준비를 되풀이해요.
- 예산. GitHub 예산으로 청구액을 막으면, 월 중간에 작업이 시작되지 않고 병합도 멈춰요.
직접 빠르게 만드는 건 하나의 프로젝트예요
GitHub 호스팅 실행기를 그대로 쓰면서 빠르게 하려면 이런 일을 떠안아야 해요.
- 락파일 해시로 캐시 키를 만들고, 캐시가 맞을 때까지
restore-keys를 손보기 - buildx를 넣고
cache-to로 Docker 캐시를 내보내기. 그것도 같은 10 GB 안에서 - 테스트 샤딩. 샤드마다 준비를 되풀이하므로 청구되는 실행 시간이 늘어나요
- 아니면 자체 호스팅 실행기를 직접 운영하기. 머신 준비, OS 업데이트, 작업 사이 정리, 멈추면 고치기까지
모두 매번 모든 것을 잊는 머신을 우회하는 방법이에요. Skipbox는 머신을 유지하므로, 이 중 어느 것도 필요 없어요.
Skipbox에서 달라지는 것
준비한 것이 디스크에 남아요. 작업은 내 계정 전용 머신에서 돌고, 그 머신은 작업 사이에도 남아 있어요. Docker 이미지, 레이어, 빌드 캐시, npm·pip·Gradle 등의 패키지 캐시, setup-node 같은 액션이 설치한 도구가 남아요. 캐시 용량은 GitHub의 7배 이상이고, 7일 만료도 브랜치 규칙도 없어요.
정액으로 더 큰 머신. 컴파일러와 테스트 실행기는 코어마다 워커를 하나씩 띄우므로, 코어가 많을수록 CPU를 많이 쓰는 단계가 짧아져요.
| 요금제 | 머신 | 가격 |
|---|---|---|
| S | 4 vCPU · 16 GB | 월 $39 |
| M | 8 vCPU · 16 GB | 월 $79 |
| L | 16 vCPU · 32 GB | 월 $149 |
모든 요금제에서 실행 시간은 무제한이에요. Skipbox의 작업은 GitHub 실행 시간을 쓰지 않으므로, GitHub 예산 때문에 멈추는 일이 없어요.
돌볼 머신이 없어요. Skipbox가 머신을 준비하고, OS와 도구를 업데이트하고, 작업이 끝날 때마다 정리하고, 상태를 점검해 통과하지 못한 머신은 다시 만들어요.
옮기는 건 한 줄이에요
jobs:
build:
runs-on: skipbox # was ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
- GitHub로 Skipbox에 로그인하세요.
- Skipbox GitHub App을 설치하고 리포지토리를 고르세요.
runs-on을 바꾸고 푸시하세요.
첫 작업이 설치한 것은 두 번째 작업을 위해 디스크에 남아요.
보안
- 머신은 내 계정만 써요. 다른 회사의 작업은 이 머신에서 돌지 않아요.
- 작업이 끝날 때마다 실행기의 자격 증명, 프로세스, 컨테이너를 지워요. 2026년 11월 13일부터는 체크아웃과 빌드 결과(Cargo의
target/)가 다음 작업을 위해 내 머신에 남아요. ‘작업마다 새 VM’을 켜면 작업마다 새 머신에서 돌아요. - 쓰기 권한이 없는 사람의 코드(포크에서 온 풀 리퀘스트 등)는 한 번 쓰고 버리는 새 머신에서 돌아요.
자세한 내용은 작업을 격리하는 방법에 있어요.
가장 느린 작업으로 체험해 보세요
무료 체험은 7일 또는 작업 시간 3,000분 중 먼저 끝나는 쪽까지이고, 카드가 필요 없어요. 가장 느린 작업을 runs-on: skipbox로 옮겨 두 번 연달아 돌리고, 단계별 시간을 GitHub와 나란히 놓고 비교해 보세요.
자주 묻는 질문
GitHub Actions는 왜 이렇게 느린가요?
GitHub 호스팅 실행기의 작업은 지난 실행의 흔적이 하나도 없는 새 VM에서 시작해요. 그래서 테스트가 시작되기 전에 도구를 받고, 의존성을 다시 설치하고, Docker 이미지를 다시 빌드해요. Skipbox는 작업을 내 계정 전용 머신에서 돌리고 그 상태를 디스크에 남겨 두므로, 다음 작업은 지난 작업이 끝난 자리에서 시작해요.
actions/cache를 넣었는데 왜 워크플로가 여전히 느린가요?
VM이 매번 새것이라서, 캐시가 맞아도 작업마다 아카이브를 받고 풀어야 해요. 게다가 GitHub의 캐시는 리포지토리당 10 GB까지이고, 7일 동안 쓰지 않은 항목은 지우고, 다른 브랜치의 캐시는 읽지 못해요. Skipbox에서는 패키지 캐시와 Docker 레이어가 이미 머신의 디스크에 있고, 관리할 키도 없어요.
GitHub Actions에서 Docker 빌드를 빠르게 하려면 어떻게 하나요?
빌드에 지난 빌드의 레이어를 넘겨 주세요. GitHub 호스팅 실행기에서는 buildx로 캐시를 내보내고 실행마다 가져와야 하고, 같은 10 GB 한도 안에서 해야 해요. Skipbox에서는 Docker 이미지와 빌드 캐시가 작업 사이에도 머신에 남으므로, docker build가 알아서 레이어를 다시 써요.
Skipbox를 쓰려면 워크플로를 다시 써야 하나요?
아니요. Linux 작업은 runs-on을 skipbox 레이블로 바꾸면 돼요. 머신은 Docker, Node.js, Python이 설치된 Ubuntu 24.04 환경이라, 단계와 액션은 그대로 돌아요.
느린 작업으로 무료로 체험할 수 있나요?
네. 무료 체험은 7일 또는 작업 시간 3,000분 중 먼저 끝나는 쪽까지이고, 카드가 필요 없어요. 가장 느린 작업을 runs-on: skipbox 레이블로 옮기고 두 번 연달아 돌린 뒤, 단계별 시간을 GitHub와 비교해 보세요.
2026년 11월 11일 업데이트