TL;DR
- GitHub Actions 호스티드 러너가 비싸고 느려서 CI 러너를 옮기기 시작했습니다.
- 1차로 GCP self-hosted runner로 갔더니 비용은 줄었지만 운영 부담(러너 오토스케일·패치·관리)이 컸습니다.
- 2차로 관리형인 Blacksmith로 옮기니,
runs-on한 줄 수준의 전환으로 운영 부담 없이 빨라졌습니다.- 핵심 교훈: self-hosted의 '싼 값'에는 운영이라는 숨은 비용이 붙습니다.
시작은 비싸고 느린 CI였습니다
문제는 명확했습니다. GitHub Actions의 기본 호스티드 러너가 비싸고 느렸습니다.
빌드·테스트 시간이 길어지면 PR마다 기다리는 시간이 쌓이고, 그만큼 분(minute) 과금도 늘어납니다. 호스티드 러너는 편하지만, 일반적인 서버용 CPU 위에서 돌기 때문에 단일코어 성능이 빠르지 않고, 캐시도 네트워크 너머에 있어 복원이 더딥니다. "편한 대신 느리고 비싸다"가 출발점이었습니다.
그래서 러너를 직접 통제해 보기로 했습니다.
1차 이관: GCP self-hosted runner — 싸졌지만 손이 많이 갔습니다
첫 선택은 GCP 위에 self-hosted runner를 올리는 것이었습니다. 우리가 가진 클라우드 자원 위에서 러너를 돌리니, 호스티드 분 과금을 피해 비용은 분명히 줄었습니다.
문제는 그 다음이었습니다. self-hosted runner는 "내가 인프라를 책임진다"는 뜻이고, CI 부하는 시간대별로 들쭉날쭉합니다. 결국 오토스케일링이 필요한데, 이게 만만치 않습니다.
- 제대로 하려면 Actions Runner Controller(ARC) 를 쿠버네티스 위에 올려야 합니다. 즉 K8s 클러스터·Helm·cert-manager를 깔고 유지해야 합니다.
- 또는 Managed Instance Group 오토스케일로 가도, VM 이미지·러너 등록·패치·정리(ephemeral)를 직접 관리해야 합니다.
# self-hosted로 가는 순간, workflow는 한 줄이지만… jobs: build: runs-on: self-hosted # 이 한 줄 뒤에 ARC/K8s·오토스케일·패치 운영이 따라온다
정리하면, 비용은 내려갔지만 운영이라는 비용이 새로 생겼습니다. 러너가 떠 있는지, 잡이 큐에 밀리지 않는지, 이미지가 최신인지를 계속 신경 써야 했습니다. CI를 빠르게 만들려다 인프라 운영에 시간을 쓰는, 약간 본말이 전도된 상황이었습니다.
2차 이관: Blacksmith — 운영 부담 없이 빨라졌습니다
그래서 관리형 러너인 Blacksmith로 옮겼습니다. self-hosted의 비용·성능 이점은 취하되, 운영은 떠넘기자는 판단이었습니다.
전환은 놀랄 만큼 단순했습니다. Blacksmith는 GitHub 러너의 드롭인 대체라, 사실상 runs-on 태그만 바꾸면 됩니다.
# Before jobs: build: runs-on: ubuntu-latest # After — 한 줄 교체 jobs: build: runs-on: blacksmith-2vcpu-ubuntu-2404
Blacksmith는 GitHub과 같은 이미지로 부팅하고 같은 사전 설치 의존성을 갖추고 있어서, 워크플로는 그대로 돌아가되 더 빨라집니다. 빨라지는 이유는 인프라에 있습니다.
- 베어메탈 게이밍 CPU 위에서 돌아, 자사 설명 기준 단일코어 성능이 GitHub 서버 하드웨어의 약 2배입니다.
- 캐시가 러너와 같은 위치(co-located) 에 있어 복원이 빠르고, 도커 레이어가 NVMe에 영속화돼 빌드 캐시가 잘 먹습니다.
결과적으로, VM을 관리하지 않으면서 속도와 비용 이점을 가져갔습니다. self-hosted에서 우리를 괴롭히던 운영 부담이 사라졌고, 체감상 CI가 확연히 빨라졌습니다. 빠르고, 운영도 편해진 겁니다.
무엇이 달라졌나
세 단계를 거치며 트레이드오프가 이렇게 움직였습니다.
| 단계 | 비용 | 속도 | 운영 부담 |
|---|---|---|---|
| GitHub Actions 호스티드 | 높음 | 느림 | 없음 |
| GCP self-hosted | 낮음 | 보통~개선 | 높음 |
| Blacksmith(관리형) | 낮음 | 빠름 | 낮음 |
self-hosted는 "비용↓"을 줬지만 "운영↑"이라는 청구서를 같이 줬고, 관리형은 그 운영 비용을 없애면서 속도까지 챙겨줬습니다.
수치는 일부러 적지 않았습니다. 환경마다 빌드 구성이 달라 우리 체감("확연히 빨라졌다")을 일반화된 숫자로 포장하고 싶지 않았습니다. 도입 전후를 본인 레포에서 직접 측정하시길 권합니다.
고려할 점
다 좋았다고만 쓰면 정직하지 않겠죠. 옮기기 전에 알아두면 좋을 점입니다.
- 벤더 종속성: 관리형 러너는 외부 벤더에 CI를 맡기는 선택입니다. 편한 만큼 종속이 생깁니다.
- 비용 구조 이해: 분 단가뿐 아니라 동시성·캐시 정책에 따라 총비용이 달라집니다. 단가만 보지 말고 워크로드로 계산하세요.
- 2026년 self-hosted 과금 변화: GitHub이 2026년 3월부터 private 레포의 self-hosted 러너에도 분당 플랫폼 과금($0.002/min)을 도입했습니다. "self-hosted = 공짜"라는 전제가 예전만큼 성립하지 않으니, 비용 비교 시 최신 정책을 확인하세요.
독자를 위한 TIP
- self-hosted를 고민한다면 '운영 비용'을 먼저 계산하세요. ARC/K8s·오토스케일·패치까지 포함한 총비용이 진짜 비용입니다.
- 빠른 효과를 원하면 관리형 드롭인부터 시도하세요.
runs-on한 줄 교체로 검증하고, 효과가 있으면 확대하는 게 리스크가 작습니다. - 무엇을 바꾸든 도입 전후를 직접 측정하세요. 남의 벤치마크가 아니라 내 레포의 빌드 시간이 기준입니다.
참고
- Blacksmith — https://www.blacksmith.sh/
- GitHub Actions self-hosted runners on Google Cloud — https://github.blog/news-insights/product-news/github-actions-self-hosted-runners-on-google-cloud/
- Actions Runner Controller(ARC) — https://github.com/actions/actions-runner-controller