GitHub Actions 셀프 호스티드 Runner: 프라이빗 환경 배포 완벽 가이드

2026년 3월, GitHub가 눈에 잘 띄지 않는 공지를 하나 발표했습니다. 프라이빗 저장소의 셀프 호스티드 Runner에 분당 $0.002의 요금이 부과되기 시작한 것입니다. 별로 많지 않아 보이나요? 계산해 보면 시간당 $0.12이고, 한 달에 100시간을 실행하면 $12입니다.

이 소식에 많은 사람이 당황했습니다. 셀프 호스티드 Runner는 계속 무료 아니었나요? 왜 갑자기 요금을 받기 시작한 걸까요? 동시에 GitHub-hosted runners의 요금은 오히려 약 40% 인하되었습니다. 많은 팀이 셀프 호스팅과 GitHub 호스팅 가운데 무엇을 선택해야 할지 다시 계산하기 시작한 이유입니다.

요금 변경은 한 가지 측면일 뿐입니다. 코드가 사내 데이터베이스에 접근해야 하거나 빌드 환경에 32GB 메모리가 필요하다면 GitHub-hosted로는 요구 사항을 충족할 수 없습니다. 이런 경우 셀프 호스티드 Runner는 선택 문제가 아니라 필수 답안입니다.

이 글에서는 세 가지 배포 방식인 전통적인 서버, Docker, Kubernetes를 비교하고 보안 강화 과정에서 흔히 빠지는 함정을 살펴봅니다. 또한 꽤 유용한 오픈 소스 관리 도구인 Runner Fleet도 소개합니다. 비용 절감, 보안, 빌드 환경 제어 중 무엇이 목적이든 필요한 답을 찾을 수 있을 것입니다.

셀프 호스티드 Runner가 필요한 이유

셀프 호스티드 Runner란?

간단히 말해 셀프 호스티드 Runner는 GitHub Actions 빌드 작업을 실행하는 자체 머신입니다. 물리 서버나 가상 머신은 물론 Raspberry Pi도 사용할 수 있습니다. GitHub-hosted runner는 GitHub가 클라우드에 마련한 환경으로 작업이 끝나면 폐기되지만, 셀프 호스티드 환경은 직접 구축하므로 원하는 방식으로 운영할 수 있습니다.

Runner 자체는 오픈 소스 프로젝트입니다. GitHub는 코드를 actions/runner 저장소에 공개해 누구나 다운로드할 수 있게 했습니다. 자신의 머신에 설치하고 저장소나 조직에 등록하면 GitHub에서 작업을 가져와 실행하고 결과를 다시 전송합니다.

GitHub-hosted와의 핵심 차이

두 방식의 차이는 단순히 ‘누가 서버를 제공하느냐’에 그치지 않습니다.

GitHub-hosted runner는 빌드할 때마다 새로운 환경을 만들고 작업이 끝나면 폐기합니다. 깨끗하고 안전하다는 장점이 있지만 콜드 스타트가 느리고 설치할 수 있는 소프트웨어가 제한됩니다. 흔하지 않은 컴파일러를 쓰고 싶어도 어렵고, 테스트 과정에서 사내 테스트 데이터베이스에 연결해야 해도 접근할 수 없습니다.

셀프 호스티드 Runner는 정반대입니다. 직접 환경을 구성하므로 무엇이든 미리 설치할 수 있습니다. 빌드 후 환경을 폐기할 필요가 없고 로컬 캐시도 그대로 남아 다음 실행이 매우 빠릅니다. 다만 운영과 문제 해결을 모두 직접 책임져야 합니다.

구분	GitHub-hosted	셀프 호스티드
환경	실행마다 새로 생성	지속적으로 사용 가능
콜드 스타트	1~2분	수초
사용자 지정	제한적	완전히 자유로움
보안	깨끗하게 격리됨	직접 강화해야 함
비용	분 단위 과금	머신 비용 + 운영 비용

2026년 요금 변경 분석

이 부분은 자세히 살펴볼 필요가 있습니다.

2026년 3월 전까지 프라이빗 저장소의 셀프 호스티드 Runner는 무료였습니다. 자체 머신과 전기료를 사용하니 GitHub는 별도로 요금을 받지 않았습니다. 하지만 3월 이후 GitHub는 프라이빗 저장소의 셀프 호스티드 Runner에 분당 $0.002를 부과하기 시작했습니다.

별로 많지 않아 보이나요? 계산해 보겠습니다. 팀이 하루에 CI를 50회 실행하고 평균 10분이 걸린다면 한 달에 15,000분으로 약 $30입니다. 1년이면 $360로, 제법 괜찮은 VPS 한 대를 살 수 있는 금액입니다.

흥미롭게도 같은 시기에 GitHub-hosted runners의 요금은 약 40% 인하되었습니다. 사용자를 클라우드로 유도하려는 걸까요?

성급하게 결론을 내릴 필요는 없습니다. 퍼블릭 저장소의 셀프 호스티드 Runner는 여전히 무료입니다. 오픈 소스 프로젝트라면 이 문제를 걱정하지 않아도 됩니다.

언제 셀프 호스팅이 필요한가?

그렇다면 어떤 상황에서 셀프 호스팅을 고려해야 할까요? 대표적인 사례를 정리하면 다음과 같습니다.

사례 1: 사내 서비스에 접근해야 할 때

CI 과정에서 사내 데이터베이스, API 또는 프라이빗 이미지 저장소에 연결해야 할 수 있습니다. GitHub-hosted 머신은 퍼블릭 네트워크에 있으므로 사내 네트워크에 접근할 수 없습니다.

사례 2: 특수 하드웨어가 필요할 때

모델 학습에 GPU가 필요하거나 대규모 프로젝트 컴파일에 128GB 메모리가 필요할 수 있습니다. GitHub-hosted 표준 사양은 메모리 7GB와 CPU 2코어뿐이어서 요구 사항을 충족하지 못합니다.

사례 3: 비용에 민감하고 빌드가 많을 때

팀이 하루에 CI를 수백 번 실행한다면 GitHub-hosted의 분당 요금이 쌓여 큰 비용이 됩니다. Runner 몇 대를 직접 구축하는 편이 더 저렴할 수 있습니다.

사례 4: 규정 준수와 데이터 주권이 중요할 때

금융과 의료 같은 산업은 데이터가 외부로 나가는 일을 엄격히 제한합니다. 빌드 과정이 반드시 사내 네트워크에서 완료되어야 하고 코드가 자체 데이터 센터를 벗어나서는 안 됩니다.

소규모 팀이고 빌드가 많지 않다면 GitHub-hosted가 꽤 매력적입니다. 신경 쓸 일이 적고 사용하기 편하며 요금도 인하되었습니다. 그러나 위와 같은 상황을 마주한다면 셀프 호스팅을 본격적으로 검토할 때입니다.

세 가지 배포 방식 비교

방식 1: 전통적인 서버 배포

가장 단순하고 직접적인 방식입니다. Linux 서버 한 대에서 Runner 패키지를 다운로드하고 압축을 푼 다음 구성해서 실행합니다.

저도 셀프 호스티드 Runner를 처음 배포할 때 이 방식을 사용했습니다. CentOS 7 머신에 SSH로 접속해 GitHub 문서를 보며 명령을 하나씩 입력했습니다. 30분 만에 설정을 마쳤고 GitHub 페이지에서 Runner가 ‘온라인’으로 표시되는 모습을 보니 꽤 뿌듯했습니다.

장점: 배포가 간단하고 Docker나 Kubernetes를 알 필요가 없습니다. 환경이 안정적이며 하나의 Runner를 오랫동안 실행할 수 있습니다.

단점: 유지 관리가 번거롭습니다. Runner가 중단되면 수동으로 재시작해야 하고, 머신에 문제가 생기면 사람이 직접 조사해야 합니다. 용량을 늘리려면 새 머신을 구입해 다시 구성해야 합니다.

적합한 상황: 소규모 팀, Runner 1~2개, 제한된 예산, 컨테이너화를 원하지 않는 경우.

방식 2: Docker 컨테이너

Runner를 Docker 컨테이너에 설치하고 각 빌드 작업이 끝나면 컨테이너를 폐기한 뒤 다음 작업에는 깨끗한 컨테이너를 새로 만듭니다. 전통적인 방식보다 훨씬 안전합니다. 악성 스크립트가 컨테이너를 망가뜨려도 삭제하고 다시 만들면 됩니다.

Docker 방식에는 단일 컨테이너 모드와 Docker-in-Docker(DinD)라는 두 가지 접근법이 있습니다.

단일 컨테이너 모드: Runner와 빌드가 모두 컨테이너 안에서 실행됩니다. 대부분의 상황에 적합합니다.

DinD 모드: Runner 컨테이너 안에서 또 하나의 Docker daemon을 실행합니다. 이미지를 빌드하거나 다중 컨테이너 테스트를 실행할 수 있지만, DinD는 보안 위험이 적지 않아 공식 문서에서도 신중한 사용을 권고합니다.

장점: 환경 격리가 뛰어나고 정리가 편하며 Docker Compose로 여러 Runner를 일괄 관리할 수 있습니다.

단점: DinD의 보안 위험이 있고 컨테이너 오케스트레이션에 여전히 사람의 개입이 필요하며 자동 확장과 축소 기능이 제한적입니다.

적합한 상황: 중간 규모, 보안 격리를 중시하고 Docker 경험이 있는 팀.

방식 3: Kubernetes + Actions Runner Controller(ARC)

GitHub가 공식적으로 권장하는 대규모 배포 방식입니다. Actions Runner Controller, 줄여서 ARC는 Runner의 수명 주기를 자동으로 관리하는 Kubernetes Operator입니다.

ARC는 지능적으로 동작합니다. 필요한 Runner 수를 정의하면 Pod를 자동으로 생성하고, 빌드 작업이 들어오면 Pod가 실행하며, 작업이 끝나면 Pod를 폐기합니다. 대기열이 쌓일 때는 자동으로 확장하고 유휴 상태에서는 자동으로 축소할 수도 있습니다.

AWS는 2025년 1월 공식 블로그에서 이 방식을 자세히 소개하며 AWS에서 대규모로 사용하는 기업에 권장했습니다.

장점: 자동 확장과 축소가 가능해 운영 비용이 가장 낮고 Kubernetes 생태계의 도구를 모두 활용할 수 있으며 대규모 배포에 적합합니다.

단점: 진입 장벽이 높습니다. Kubernetes, Helm, CRD를 알아야 하며 배포 복잡도가 앞의 두 방식보다 훨씬 높습니다.

적합한 상황: 대규모 팀, 수십~수백 개의 Runner, Kubernetes 인프라를 갖추고 자동화된 운영을 원하는 경우.

방식 비교와 선택 가이드

다음 표를 보면 어떤 방식이 적합한지 빠르게 판단할 수 있습니다.

구분	전통적인 서버	Docker	Kubernetes ARC
배포 난이도	낮음	중간	높음
환경 격리	낮음	좋음	매우 좋음
자동 확장과 축소	없음	제한적	완전히 지원
운영 비용	높음	중간	낮음(자동화 이후)
학습 난이도	낮음	중간	높음
적합한 규모	Runner 1~5개	5~20개	20개 이상

제안은 다음과 같습니다.

소규모 팀(1~5명)이고 빌드가 많지 않다면 전통적인 서버로 충분합니다. 굳이 컨테이너화까지 할 필요는 없습니다.

중간 규모(10~30명)이고 하루에 수십 번 빌드한다면 Docker 컨테이너화와 Runner Fleet 같은 관리 도구를 함께 사용하세요.

대규모 팀(30명 이상)이고 CI/CD 실행 시간이 수천 분에 달한다면 Kubernetes ARC가 적합합니다. 학습에 시간을 투자하는 대신 운영을 자동화할 수 있습니다.

솔직히 말해 ‘최적’의 방식은 없고 ‘가장 적합한’ 방식만 있습니다. 팀 규모, 기술 스택, 운영 역량을 살펴보고 유행만 좇아 새로운 기술을 선택하지 마세요.

보안 모범 사례

퍼블릭 저장소: 절대 사용 금지

GitHub가 공식적으로 명확히 경고한 내용이므로 가장 먼저 짚어야 합니다.

“셀프 호스티드 Runner는 퍼블릭 저장소에서 거의 사용해서는 안 됩니다.” — GitHub Docs

왜 그럴까요? 퍼블릭 저장소에서는 누구나 PR을 제출해 Workflow를 트리거할 수 있습니다. 이 Runner가 사내 네트워크의 머신에서 실행된다면 악성 PR이 그 환경에서 임의의 명령을 실행할 수 있습니다. 민감한 파일을 읽고 Token을 훔치거나 다른 사내 서비스까지 횡적으로 공격할 수 있습니다.

2026년 1월 Sysdig의 보안 분석 글은 이 문제를 집중적으로 다뤘습니다. 공격자가 셀프 호스티드 Runner를 백도어로 이용해 기업 내부망에 침투한 사례입니다. 이는 이론적인 위험이 아니라 실제로 발생한 일입니다.

따라서 퍼블릭 저장소에서는 GitHub-hosted runner를 사용하거나 CI를 사용하지 않아야 합니다. 셀프 호스팅을 사용하고 싶다면 먼저 저장소를 프라이빗으로 전환하세요.

Runner Groups 격리 전략

프라이빗 저장소라고 해서 완전히 안전한 것은 아닙니다. 프로젝트와 팀마다 신뢰 수준이 다르므로 핵심 비즈니스 코드용 Runner를 실험 프로젝트의 Runner와 섞어서는 안 됩니다.

Runner Groups는 이 문제를 해결하는 기능입니다. 조직 수준에서 여러 Runner Group을 만들고 프로젝트, 팀, 신뢰 수준에 따라 분류할 수 있습니다. 각 Group에는 사용할 수 있는 저장소와 사용할 수 없는 저장소 등 접근 범위를 설정할 수 있습니다.

대표적인 구성 예시는 다음과 같습니다.

• critical-prod Group: 핵심 저장소만 사용할 수 있고 머신은 사내 격리 구역에 배치
• dev-team Group: 개발팀 저장소에서 사용할 수 있고 머신은 일반 사내 네트워크에 배치
• sandbox Group: 실험 프로젝트용이며 머신은 격리된 샌드박스 환경에 배치

이렇게 구성하면 특정 저장소가 침해되더라도 공격자는 해당 Group의 Runner에만 접근할 수 있고 핵심 시스템에는 영향을 주지 못합니다.

환경 강화 조치

Runner 자체의 보안을 강화할 때는 몇 가지 기본 원칙을 따라야 합니다.

최소 권한 원칙: Runner 프로세스는 전용 사용자로 실행하고 root를 사용하지 마세요. 필요한 소프트웨어만 설치해 공격 표면을 줄이세요.

네트워크 격리: Runner 머신을 퍼블릭 네트워크에 직접 노출하지 마세요. GitHub의 webhook을 통해 작업을 받으므로 퍼블릭 네트워크의 인바운드 연결이 필요하지 않습니다.

Token 관리: Runner 등록용 Token에는 유효 기간이 있습니다. 만료되면 다시 생성해야 합니다. Token을 스크립트에 하드 코딩하지 말고 Secrets로 관리하세요.

로그 감사: Runner 실행 로그를 보관해야 비정상적인 동작을 추적할 수 있습니다.

Wiz는 2026년 4월 보안 가이드에서 많은 기업의 Runner 환경이 지나치게 느슨해 공격자에게 너무 많은 기회를 제공한다고 지적했습니다. 보안 강화는 일회성 작업이 아니라 지속적으로 점검해야 하는 일입니다.

권장 보안 도구

GitHub는 Workflow에서 직접 사용할 수 있는 Harden-Runner라는 보안 도구를 제공합니다.

steps:
  - uses: step-security/harden-runner@v2
    with:
      egress-policy: audit

이 Action은 Runner의 아웃바운드 네트워크 연결을 모니터링하고 비정상적인 동작을 보고합니다. Audit 모드와 Block 모드가 있으며, Block 모드는 승인되지 않은 아웃바운드 연결을 직접 차단합니다.

Block 모드는 셀프 호스티드 Runner에서 특히 유용합니다. 악성 스크립트가 데이터를 훔쳐 외부로 전송하려 하면 즉시 막을 수 있습니다.

보안은 절대 가볍게 봐서는 안 됩니다. Runner를 설치한 뒤 방치하고 권한을 무분별하게 열어 두거나 Token을 구성 파일에 하드 코딩한 팀을 적지 않게 봤습니다. 실제 사고가 발생한 뒤에는 후회해도 늦습니다.

오픈 소스 관리 도구 Runner Fleet

Runner Fleet란?

앞에서 Docker 컨테이너 배포를 설명했지만 여러 Runner 컨테이너를 관리하는 일은 여전히 번거롭습니다. 각 컨테이너의 상태, Token, 로그가 여러 곳에 흩어져 있어 수동으로 확인해야 합니다.

Runner Fleet는 이 문제를 해결하기 위한 오픈 소스 프로젝트입니다. 개발자 soulteary가 Tencent Cloud 개발자 커뮤니티에 프로젝트의 탄생 배경과 기능을 소개하는 자세한 실습 글을 게시했습니다.

간단히 말해 Runner Fleet는 모든 Runner 컨테이너를 중앙에서 관리하는 웹 UI를 제공합니다. 상태 모니터링, 일괄 작업, Token 통합 관리, 장애 자동 복구를 지원합니다. 컨테이너마다 SSH로 접속할 필요 없이 웹페이지를 열면 전체 상황을 한눈에 볼 수 있습니다.

핵심 기능 소개

Runner Fleet에는 특히 마음에 드는 기능이 몇 가지 있습니다.

통합 상태 모니터링: 모든 Runner의 온라인 상태, 현재 작업, 과거 실행 기록을 한눈에 볼 수 있습니다. 컨테이너 로그를 하나씩 확인할 필요가 없습니다.

Token 통합 관리: Runner 등록용 Token을 웹 UI에서 구성할 수 있어 머신마다 수동으로 설정할 필요가 없습니다. Token이 변경되어도 클릭 한 번으로 동기화할 수 있습니다.

자동 복구 점검: Runner 컨테이너가 중단되면 시스템이 자동으로 감지해 재시작합니다. 배포 과정에서 Runner 연결이 간혹 끊겨 그때마다 직접 조사해야 했던 경험이 있습니다. 자동 복구 기능을 사용하면 수고를 크게 덜 수 있습니다.

컨테이너 모드와 호스트 모드: 완전히 컨테이너에서 실행하거나 Runner는 호스트에서 실행하되 컨테이너로 관리하는 방식을 선택할 수 있습니다. 두 모드에는 각기 장점이 있으므로 필요에 맞게 선택하면 됩니다.

일괄 작업: 모든 Runner를 한 번에 시작, 중지, 재시작할 수 있습니다. 확장할 때도 Runner를 하나씩 구성하지 않고 여러 개를 일괄 생성할 수 있습니다.

빠른 배포 가이드

Runner Fleet 자체는 Docker로 배포하며 몇 줄의 명령만으로 실행할 수 있습니다.

# 이미지 가져오기
docker pull soulteary/runner-fleet

# 서비스 시작(간소화 버전)
docker run -d \
  --name runner-fleet \
  -p 8080:8080 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  soulteary/runner-fleet

실행 후 http://你的机器IP:8080에 접속하면 관리 화면이 표시됩니다.

화면에서 GitHub Token을 구성하고 Runner 수와 환경 매개변수를 설정한 뒤 몇 번 클릭하면 Runner를 일괄 생성할 수 있습니다. 하나씩 직접 다운로드하고 압축을 풀어 구성하는 것보다 훨씬 시간을 절약할 수 있습니다.

팀에서 Docker를 사용하지만 Kubernetes까지 배우고 싶지는 않다면 Runner Fleet는 비용 대비 효율이 높은 선택입니다. 컨테이너 격리의 장점은 누리면서 복잡한 수동 운영을 걱정할 필요가 없습니다.

배포 실습 단계

Linux 배포 5단계

전통적인 서버 방식으로 배포하려면 다음 절차를 따르면 됩니다. Ubuntu 20.04 서버 한 대가 있다고 가정하겠습니다.

1단계: 전용 사용자 생성

# runner 사용자 생성, Runner를 root로 실행하지 않음
sudo useradd -m runner
sudo passwd runner  # 비밀번호 설정

왜 전용 사용자가 필요할까요? Runner 프로세스는 GitHub Token에 접근할 권한이 있습니다. root로 실행하다 침해되면 공격자가 root 권한까지 얻게 됩니다. 전용 사용자를 사용하면 최소한 하나의 격리 계층을 확보할 수 있습니다.

2단계: Runner 패키지 다운로드

GitHub의 Runner 릴리스 페이지에서 최신 버전의 다운로드 링크를 찾습니다.

# runner 사용자로 전환
sudo su - runner

# 다운로드(버전 번호 교체)
cd ~
curl -o actions-runner-linux-x64-2.321.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.321.0/actions-runner-linux-x64-2.321.0.tar.gz

# 압축 풀기
tar xzf actions-runner-linux-x64-2.321.0.tar.gz

3단계: 등록 Token 가져오기

GitHub 저장소나 조직의 Settings 페이지에서 Actions -> Runners -> New self-hosted runner로 이동하면 Registration Token이 표시됩니다. 이 Token은 한 번만 사용할 수 있으며 등록을 마치면 무효가 됩니다.

4단계: 구성 및 등록

# Runner 구성
./config.sh --url https://github.com/YOUR_ORG \
  --token YOUR_REGISTRATION_TOKEN \
  --name my-runner-01 \
  --labels linux,ubuntu

--labels로 Runner에 레이블을 지정할 수 있습니다. 이후 Workflow에서 runs-on: [self-hosted, linux]를 사용하면 해당 Runner를 선택할 수 있습니다.

5단계: systemd 서비스 설치

# 시스템 서비스로 설치(root 권한 필요)
sudo ./svc.sh install runner
sudo ./svc.sh start

이제 Runner는 시스템과 함께 시작되며 중단되면 systemd가 자동으로 재시작합니다.

Workflow에서 Runner 지정하기

Runner를 설치한 뒤에는 Workflow의 runs-on으로 지정합니다.

jobs:
  build:
    runs-on: self-hosted  # 아무 셀프 호스티드 Runner 사용
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm run build

특정 레이블을 지정할 수도 있습니다.

jobs:
  test:
    runs-on: [self-hosted, linux, ubuntu]
    steps:
      - uses: actions/checkout@v4
      - name: Test
        run: npm test

여러 Runner가 같은 레이블을 사용하면 GitHub가 작업을 자동으로 할당합니다. 레이블을 구체적으로 지정할수록 더 정확하게 할당됩니다.

배포를 마치면 GitHub 페이지에서 Runner 상태를 확인하세요. ‘Offline’으로 표시되면 네트워크 문제나 Token 구성 오류일 수 있습니다.

결론

그렇다면 어떤 방식을 선택해야 할까요?

소규모 팀, 적은 빌드량: GitHub-hosted를 바로 사용하세요. 요금 인하 후 비용 대비 효율이 좋고 관리도 편합니다. 특별한 요구 사항이 생길 때 셀프 호스팅을 고려하면 됩니다.

중간 규모, 하루 수십 번의 빌드: Docker 컨테이너화와 Runner Fleet를 함께 사용하세요. 환경 격리와 중앙 관리를 모두 구현하면서 운영 비용을 통제할 수 있습니다.

대규모 팀, 많은 Runner: Kubernetes + ARC가 적합합니다. 학습에 투자하면 장기적으로 자동화된 운영 역량을 얻을 수 있습니다.

보안에 민감한 환경: 프라이빗 저장소 + Runner Groups 격리 + Harden-Runner 모니터링 조합을 사용하세요. 퍼블릭 저장소에서는 셀프 호스팅을 절대 사용하지 마세요. 이는 단순한 권고가 아니라 경고입니다.

2026년의 요금 변경으로 비용 계산 방식이 달라진 것은 사실이지만, 셀프 호스팅의 가치는 비용 절감에만 있지 않습니다. 사내 네트워크 접근, 하드웨어 사용자 지정, 데이터 규정 준수는 GitHub-hosted가 충족할 수 없는 요구 사항입니다. 자신의 필요를 정확히 계산하고 가장 적합한 방식을 선택하세요. 유행을 좇을 필요도, 지나치게 망설일 필요도 없습니다.

다음 단계는 무엇일까요? 팀이 사내 네트워크 접근, 비용 부담, 규정 준수 같은 문제를 겪고 있다면 먼저 Docker + Runner Fleet 조합을 시도해 보세요. 배포 비용이 낮고 효과를 빠르게 확인할 수 있습니다. 실제로 대규모 요구 사항이 생기면 그때 Kubernetes 방식으로 마이그레이션해도 늦지 않습니다.