GitLab Runner VPS에는 전용 vCPU가 몇 개 필요한가요?

VPS 하나로 CI job을 동시에 몇 개까지 실행할 수 있나요?

CI job 하나에는 전용 vCPU 2개와 그에 딸린 RAM이 필요하며, runner의 concurrent 설정이 이 job이 VPS를 몇 개까지 나눠 쓰는지 정합니다. config.toml에서 concurrent는 등록된 모든 runner에 걸쳐 job 수를 제한하고, limit는 등록된 runner 하나에 대해 제한합니다(기본값인 0는 제한 없음을 뜻합니다). GitLab의 요구 사항 페이지는 크기를 정할 때 볼 세 가지 입력을 제시합니다: job의 CPU 부하, job의 메모리 사용량, 동시에 실행되는 job 수입니다.

GitLab의 호스팅 runner 크기는 VPS와 어떻게 비교되나요?

GitLab의 호스팅 Linux runner는 vCPU당 4 GB RAM을 주고, Cobaltfell 요금제는 vCPU당 2 GB를 줍니다. vCPU 수는 하나씩 그대로 맞아떨어지므로, 이미 GitLab.com에서 돌리는 파이프라인의 크기를 고르는 데 이 표가 바로 쓰입니다. 현재 머신의 메모리를 대부분 쓰는 job이라면 Cobaltfell 요금제를 한 단계 위로 고르거나 동시에 돌리는 job 수를 줄여야 합니다.

2026년 11월 2일 Cobaltfell의 조사에 따르면, 2022년 이후 프로세서의 전용 vCPU 하나는 신분 확인 없이 암호화폐를 받는 호스트에서 월 중앙값 $8.20이었으므로, 2 vCPU짜리 병렬 CI job 하나는 그 두 배 정도입니다.

그 중앙값 뒤에 있는 모든 호스트와 가격은 2026년 11월 전용 CPU VPS의 코어당 비용에 있습니다.

CI와 컴파일 job에 전용 코어가 왜 중요한가요?

빌드는 몇 분씩 CPU를 풀부하로 잡는데, 바로 이 패턴이 공유 VPS 요금제가 제한하려는 대상입니다. 같은 조사의 호스트 두 곳이 이를 약관에 명시합니다: Spartan Host의 약관은 할당된 코어의 50%를 한 시간 넘게 쓰는 것을 금지하고, Advin Servers의 공정 사용 정책은 CPU 사용을 75%로 제한합니다.

공유 vCPU에서는 그 비용이 steal time으로도 나타납니다. 한산한 밤에는 빠른 파이프라인도 피크 시간대에 늘어지고, 코드와 무관한 이유로 job 타임아웃이 발생합니다. CPU steal time이란 무엇이고 VPS에서 확인하는 방법에서 읽는 법을 확인할 수 있습니다.

Cobaltfell에서는: 작업에 필요한 만큼 얼마든지 풀 부하를 허용합니다. CPU 크레딧도, 버스트 시간도, 100%에서 몇 분이 지난 뒤의 스로틀링도 없습니다. vCPU 하나는 호스트 프로세서의 하드웨어 스레드 하나입니다. 고객님의 vCPU는 VPS에 1대1로 고정되며 다른 고객에게 절대 빌려주지 않고, 물리 코어의 두 스레드는 함께 유지되므로 2 vCPU마다 이웃이 공유하지 않는 온전한 코어 하나가 됩니다. 스레드에 이웃이 없으므로 캐시가 데워진 파이프라인은 매 실행마다 거의 같은 시간이 걸리니, 느린 job은 코드를 가리킵니다. vCPU와 코어의 규칙이 어떻게 동작하는지는 전용 vCPU는 코어인가 스레드인가에 설명되어 있습니다.

병렬 빌드가 같은 vCPU를 두고 다투지 않게 하려면?

각 job에 VPS의 고정 몫을 주고, 같은 숫자를 빌드 도구에도 넘기세요. 빌드 도구마다 기본값이 다릅니다. GNU make는 -j을 주지 않으면 한 번에 recipe 하나만 실행합니다. Cargo는 논리 CPU 수만큼 job을 돌립니다. Ninja는 따로 요청하지 않아도 CPU 수를 기준으로 병렬 실행합니다. Fell 8에서 그런 빌드 네 개가 돌면 각각 컴파일러 8개를 띄웁니다: 8개 스레드와 16 GB RAM에 프로세스 32개입니다.

Docker executor에서는 각 job이 자체 컨테이너에서 실행되며, [runners.docker]는 해당 컨테이너에 cpus 및 memory 제한을 겁니다. 둘 다 설정한 다음, job 내부의 병렬 처리와 맞추세요:

concurrent = 4            # jobs at once, all runners together
check_interval = 3

[[runners]]
  name = "fell-8-docker"
  url = "https://gitlab.com"
  token = "REPLACE_WITH_YOUR_RUNNER_TOKEN"
  executor = "docker"
  limit = 4
  [runners.docker]
    image = "debian:13"
    cpus = "2"             # CPUs for each job container
    memory = "3g"          # leaves room for the system and Docker

variables:
  MAKEFLAGS: "-j2"          # GNU make
  CARGO_BUILD_JOBS: "2"     # cargo (build.jobs)

build:
  script:
    - make
    - cargo build --release
    - ninja -C build -j 2

Rust나 C++ 컴파일에는 VPS에서 무엇이 필요한가요?

컴파일에는 스레드와 메모리가 함께 필요합니다: 병렬 컴파일 프로세스와 링크 단계는 각자 RAM을 나눠 씁니다. 큰 C++ 변환 단위와 제네릭이 많은 Rust 크레이트가 흔한 메모리 피크이며, 큰 바이너리의 마지막 링크는 어떤 단일 컴파일보다 더 많은 메모리를 필요로 할 수 있습니다.

메모리 부족으로 죽는 빌드에는 vCPU를 더 줄 게 아니라 -j 또는 CARGO_BUILD_JOBS을 낮춰야 합니다. vCPU를 늘리면 끝나는 job은 줄고 죽는 job은 늘어납니다. 빌드 캐시는 VPS 자체 디스크(모든 플랜에 NVMe 스토리지)에 두고 docker image prune로 오래된 이미지를 정리하세요. 바쁜 runner는 파이프라인이 보여주는 것보다 디스크를 더 빨리 채웁니다.

빌드 하나에 수십 GB RAM이 필요한 모노레포는 베어메탈 영역이며, Cobaltfell은 이를 판매하지 않습니다. 데이터베이스를 쓰는 테스트 스위트에는 자체 크기 산정 규칙이 있는데, 이는 VPS에서 PostgreSQL에 필요한 CPU와 RAM에 다뤄져 있습니다.

VPS의 runner에는 어떤 executor를 써야 하나요?

Docker executor가 올바른 기본값입니다: GitLab의 executor 가이드는 이것이 각 빌드에 깨끗하고 격리된 환경을 준다고 하며, Shell executor는 빌드마다 깨끗한 환경도, runner 파일 시스템 보호도 제공하지 않는다고 합니다. Shell, SSH, VirtualBox executor는 유지 관리 모드입니다.

누가 job을 시작할 수 있는지도 그만큼 중요합니다: 포크에서 온 머지 리퀘스트는 VPS에서 그 코드를 실행합니다. GitHub의 보안 가이드는 self-hosted runner를 공개 리포지토리에 거의 쓰지 말라고 하며, 신뢰할 수 없는 pull request를 실행하는 모든 CI 시스템에 같은 논리가 적용됩니다.

Forgejo, Woodpecker, Jenkins, GitHub Actions 에이전트도 같은 방식으로 크기를 정합니다: 겹치는 job 수를 세고, 각 job에 고정된 스레드와 메모리를 줍니다. 각 크기의 요금제 가격은 전용 코어 VPS의 비용에 나와 있습니다.