`runs-on` 한 줄로 GitHub CI를 GPU 서버로 — Hugging Face Jobs 마이그레이션 해부

GitHub Actions의 기본 러너는 편리하지만 한계가 분명하다. 속도가 느리고, 정기 점검 때 멈추고, GPU는 없다. ML 라이브러리를 개발하는 팀에게 이 세 번째 제약이 가장 뼈아프다. 실제 CUDA 하드웨어에서 돌아야 하는 테스트를 CI에 넣으려면 비싼 always-on 러너를 직접 운영해야 했다. 대부분의 오픈소스 프로젝트는 그 비용을 감당하지 못해 GPU 테스트 자체를 포기해왔다. Hugging Face가 공개한 jobs-actions는 이 구조를 뒤집는다. GitHub Actions 자체를 버리는 게 아니라, CI 오케스트레이션은 GitHub에 남겨두고 실제 실행 환경만 HF Jobs 인프라로 교체한다. 핵심은 dispatcher라는 Docker Space다. GitHub이 `workflow_job.queued` webhook을 보내면, dispatcher가 이를 받아 short-lived runner registration token을 발급하고 요청된 하드웨어 플레이버로 HF Job을 실행한다. 그 Job이 ephemeral self-hosted 러너로 GitHub에 등록되고, 잡이 끝나면 러너는 자동 소멸한다. GitHub 입장에서는 self-hosted 러너가 잠깐 나타났다 사라진 것이고, HF 입장에서는 컨테이너 잡 하나가 돌고 끝난 것이다. Trackio(gradio-app/trackio)에 실제 적용한 결과, CPU CI가 30% 빨라졌고 기존에 불가능했던 CUDA 테스트 스위트를 새로 구축했다. 워크플로 파일에서 실제로 바꾼 것은 `runs-on: ubuntu-latest`를 `runs-on: hf-jobs-cpu-upgrade`나 `runs-on: hf-jobs-t4-small`로 교체한 것뿐이다. hf-jobs-a10g-small, hf-jobs-h200 같은 레이블도 동일한 방식으로 지원된다. 설정은 5단계인데, 가장 공수가 드는 부분은 dispatcher Space 복제와 GitHub App 생성이다. 한 가지 놓치기 쉬운 포인트가 있다. dispatcher Space의 하드웨어를 반드시 cpu-upgrade로 선택해야 한다는 것이다. cpu-basic은 idle 후 슬립할 수 있어서, 슬립 중에 도착한 GitHub webhook을 놓치면 잡이 영원히 큐에 남는다. 일회용 러너 구조는 보안 면에서도 상시 self-hosted 러너보다 깔끔하다. 토큰이 한 번 쓰이고 사라지기 때문에 장기 자격증명 유출 위험이 없다. 오픈소스 ML 프로젝트가 자체 GPU 서버 없이 실제 하드웨어에서 테스트를 돌릴 수 있게 됐다는 점에서, 이 아키텍처는 단순한 CI 속도 개선을 넘어 ML 라이브러리 개발 방식 자체를 바꾸는 시도에 가깝다.