본문 바로가기
TIL

CI/CD에서 Runner란?

by 정말반가워요 2025. 2. 18.

CI/CD에 대해서 잘 몰랐을 때도 강의를 보고 따라하는 식으로 적용한 적이 있다.

그 때 모르고 넘어갔었던 것이 Self-hosted Runner라는 프로세스였다.

 

이번에 CI/CD를 공부하며 좀 더 자세히 알게 되었으니 정리해 보려 한다.

 

인프라 구성 요소 중 이해가 잘 가지 않는 것이 있을 때 문제상황을 정리하기 위해 

내가 종종 하는 생각이 있는데, 다음과 같다.

'그 프로세스가 작동하려면 컴퓨터가 필요할텐데, 그 프로세스는 어떤 컴퓨터에서 도는 거지?' 이다.

 

Runner란 무엇이고, 어디에서 도는가?

 

CI가 작동하기 위해서는 Git 원격 저장소의 commit과 같은 이벤트를 누군가가 감지하고, 지정된 스크립트를 실행해야 한다.

즉 어떤 신호를 대기하고 있다가, 지정된 스크립트를 실행하는 주체가 'Runner'인 것이다.

 

또한 '감지한다' 라는 말은 '24시간 대기한다' 혹은 '적어도 이벤트가 발생할 시점에는 깨어있어야 한다'라는 말이 된다.

Runner를 돌릴 서버가 필요하다는 뜻이다.

 

그래서 CI를 제공해주는 서비스에서는 Self-hosted Runner라는 것을 제공한다.

사용자에 서버 컴퓨터에 직접 설치해서, '네가 직접 Runner를 호스팅해라'라는 것이다.

사용자는 OS에 맞는 Runner를 설치하게 된다.

 

내가 관리하는 컴퓨터에서 직접 실행되기 때문에, Runner 관리의 책임은 생기지만 사용은 조금 더 편하다.

그런데 Runner를 할당할 서버 컴퓨팅 자원이 내게 없다면?

CI 플랫폼에서 호스팅하는 Runner를 쓸 수 있다.

 

그렇다는 것은 그 플랫폼에서 관리하는 호스트 컴퓨터들이 가지고 있는

프로세스 하나를 내게 제공해준다는 뜻이 된다.

당연히 사용 규모, 플랫폼에 따라서 유료 서비스가 될 수도, 무료로 사용할 수도 있다.

 

Runner 호스팅 서비스를 사용한다면 매우 간단한 작업이나 테스트에는 적합하겠지만

빌드와 테스트를 자동화하려면 플랫폼에서 호스팅하는 Runner에서 결국 내 서버로 SSH 연결을 해야 할 것이다.

그래서 개인 프로젝트를 진행할 땐 self-hosted Runner를 사용하게 될 것 같다.

 

이 내용은 플랫폼마다 크게 다르지 않을 것이다.

Gitlab, Github, Jenkins 등 어떤 플랫폼을 사용하든 이 내용을 기억해 두자.

 

'TIL' 카테고리의 다른 글

대기중인 스레드가 많으면 왜 좋지 않을까?  (0) 2025.03.30
사람을 낚는 AI  (0) 2025.03.03
gitlab과 SSH - private key를 왜 못 찾니  (0) 2025.02.18