GitHub Self-Hosted Runner를 활용한 실무 CI/CD 세팅하기

들어가며

최근 사내 프로젝트를 진행하면서 GitHub Actions 기반 CI/CD 환경을 구축하게 되었다.

프로젝트는 다음과 같이 구성되어 있었고, 모두 Docker 기반으로 운영 중이었다.

• Backend — Spring Boot
• Web — Vite
• Admin — React

단순히 Git Push 후 배포되는 수준을 넘어, 다음과 같은 요구사항을 기획했다.

• 개발 서버 자동 배포
• 운영 서버 배포 자동화
• 배포 결과에 따른 Slack 알림
• Health Check 기반 검증과 실패 시 자동 롤백
• 수동 롤백 지원
• 배포 이력 관리

이 글에서는 GitHub Self-Hosted Runner를 선택한 이유와 실제 운영 과정에서 적용한 사례를 정리해 보려고 한다.

시리즈 목차

읽기 쉽도록 파트별로 나누어 설명한다.

1. Runner란 무엇인가?
2. 왜 Self-Hosted Runner를 선택했는가?
3. GitHub Self-Hosted Runner 실무 적용기
4. CI/CD Slack 채널 연동
5. 트러블 슈팅

마치며

이번 CI/CD 구축의 목표는 단순한 자동 배포가 아니었다. 실패를 빠르게 감지하고, 문제가 생겼을 때 자동으로 복구할 수 있는 배포 환경을 만드는 것이 핵심이었다.

GitHub Self-Hosted Runner를 활용하면서 Docker 제어, 백업 관리, Health Check 검증, 자동 롤백까지 하나의 파이프라인으로 통합할 수 있었고, 운영 효율도 크게 높아졌다.

앞으로는 SonarQube, 테스트 자동화, Kubernetes 기반 배포까지 확장해 볼 계획이다.