개발자가 코드를 수정해서 GitLab 또는 GitHub에 올리면, 단순히 저장만 되는 것이 아니라 아래 같은 작업을 자동으로 수행하고 싶어집니다.
- 코드 문법 검사
- 테스트 실행
- Docker 이미지 빌드
- 서버 자동 배포
- Kubernetes 반영
- 보안 스캔
- 취약점 검사
- Slack 알림
- 운영 서버 재시작이 작업을 자동으로 수행하는 구조가 바로
CI/CD (Continuous Integration / Continuous Deployment)입니다.
그리고 실제로 작업을 대신 수행하는 실행기를:
Runner / Agent / Worker라고 부릅니다.
GitLab CI -> GitLab Runner 가 작업 수행
GitHub Actions -> GitHub Runner 가 작업 수행예전에는 개발자가 직접 했습니다.
1. 서버 접속
2. git pull
3. docker build
4. docker restart
5. 설정 수정
6. 로그 확인하지만 문제는
- 사람마다 방식이 다름
- 실수 발생
- 누가 배포했는지 추적 어려움
- 야간 장애 증가
- 보안 점검 누락
- 서버별 버전 차이같은 문제가 발생합니다.
그래서
"코드가 올라오면 자동으로 검증하고 자동으로 배포하자"라는 개념이 등장했고, 이것이 CI/CD 입니다.
전체 구조 이해
예를 들어 GitLab 기준
개발자
↓
Git Push
↓
GitLab CI Pipeline 생성
↓
GitLab Runner 가 작업 수신
↓
Docker Build
↓
테스트
↓
운영 서버 배포GitHub도 거의 동일합니다.
GitHub Push
↓
GitHub Actions Workflow
↓
GitHub Runner
↓
빌드 / 테스트 / 배포GitLab Runner란?
GitLab에서 내려주는 작업을 실제 수행하는 프로그램입니다.
예시
build:
script:
- docker build -t myapp .위 작업은 GitLab 서버가 직접 수행하지 않습니다.
실제로는
GitLab Runner가 받아서 실행합니다.
GitHub Actions Runner란?
GitHub Actions의 작업을 실제 수행하는 실행기입니다.
jobs:
build:
runs-on: self-hosted이 작업을 실제 서버에서 수행하는 것이
GitHub Actions Runner입니다.
Runner를 Docker로 운영하는 이유
원래는 서버에 직접 설치할 수도 있습니다.
하지만 Docker를 쓰면
- 설치 간단
- 삭제 쉬움
- 버전 관리 쉬움
- 장애 복구 쉬움
- 여러 Runner 분리 가능
- 운영 표준화 가능해집니다.
그래서 실무에서는 Docker 기반 운영이 많습니다.
GitLab Runner 특징
GitLab
↓
Runner 등록
↓
작업 수신Runner가 GitLab 서버에 등록되어 있어야 합니다.
Docker Build 자동화
script:
- docker buildKubernetes 배포
script:
- kubectl apply -f deploy.yaml보안 스캔
script:
- trivy image myapp서버 자동 배포
script:
- ansible-playbook deploy.ymlGitHub Actions Runner 특징
GitHub Actions는
Marketplace생태계가 매우 강력합니다.
예
- uses: actions/checkout@v4
- uses: docker/build-push-action처럼 다양한 모듈을 쉽게 사용 가능합니다.
둘의 차이
| 항목 | GitLab Runner | GitHub Runner |
|---|---|---|
| 플랫폼 | GitLab | GitHub |
| 설정파일 | .gitlab-ci.yml | workflow.yml |
| 생태계 | DevOps 중심 | 오픈소스/Marketplace 강함 |
| Kubernetes 연동 | 매우 강력 | 강력 |
| 기업 내부 운영 | 많이 사용 | 점점 증가 |
| Self-hosted 운영 | 매우 일반적 | 일반적 |
| 보안 통제 | 세밀함 | 상대적으로 단순 |
| Enterprise 기능 | 강함 | 강함 |
실제 운영 목적
1. 자동 배포
가장 대표적입니다.
코드 수정
→ Push
→ 자동 빌드
→ 자동 배포2. 보안 점검 자동화
보안 관점에서는 매우 중요합니다.
예
- 취약한 라이브러리 탐지
- SAST
- Secret 탐지
- Docker 이미지 스캔
- IaC 스캔3. 표준화
개발자마다 다른 방식 제거.
"항상 동일한 절차"로 배포 가능.
4. 감사 및 추적
누가
언제
무엇을
배포했는가추적 가능.
보안 관점에서 중요한 이유
보안에서는 Runner를:
"자동화된 privileged 작업 서버"로 봐야 합니다.
왜냐하면
- 운영 서버 접근
- Kubernetes 접근
- Docker 제어
- Secret 접근권한을 가지기 때문입니다.
docker.sock 마운트
많이 사용하는 방식
- /var/run/docker.sock:/var/run/docker.sock하지만 이것은 사실상
호스트 Docker root 권한 제공과 유사합니다.
악성 Pipeline이 실행되면
- 호스트 파일 접근
- 컨테이너 탈출
- 내부망 접근가능할 수 있습니다.
보안 권장사항
1. Public 저장소와 분리
절대
외부 PR 처리 Runner와
운영 배포 Runner를 같이 쓰면 안 됩니다.
2. Runner 분리
예
- build-runner
- deploy-runner
- security-scan-runner3. 최소 권한
- Kubernetes RBAC 제한
- Docker 권한 최소화
- Secret 최소 제공4. 네트워크 분리
운영 배포 Runner는
- 내부망 전용
- VPN 내부
- 접근 제한권장.
실제 실무 구조 예시
개발
Git Push
→ 테스트 Runner스테이징
테스트 성공
→ Staging 자동 배포운영
승인 후
→ Production Runner 배포Docker 기반 GitLab Runner 방식
Docker Compose
↓
gitlab-runner 컨테이너 실행
↓
GitLab 등록
↓
Pipeline 작업 수행Docker 기반 GitHub Runner 방식
Docker Compose
↓
github-runner 컨테이너
↓
GitHub 등록
↓
Actions 작업 수행장점
엄청난 자동화
수작업 제거빠른 배포
몇 초~몇 분 내 반영재현성
항상 동일 환경운영 안정성
휴먼 에러 감소단점
잘못 구성 시 대형 사고 가능
예
자동 운영 배포 실수Runner 해킹 위험
특히 self-hosted runner.
Secret 관리 어려움
AWS KEY
SSH KEY
K8S TOKEN노출 위험.
보안 추천 운영 모델
실무적으로 추천되는 방식
[외부용]
- 테스트 전용 Runner
[내부용]
- 운영 배포 Runner
[보안]
- Security Scan Runner분리 운영.
보안 자동화 예시
Docker 이미지 스캔
script:
- trivy image myappSecret 탐지
script:
- gitleaks detectIaC 스캔
script:
- checkov -d .어떤 걸 선택해야 하나?
GitLab Runner 추천
- 내부 기업 환경
- 자체 DevOps
- Kubernetes 중심
- 세밀한 통제 필요GitHub Actions 추천
- 오픈소스
- 빠른 시작
- Marketplace 활용
- 외부 SaaS 연동결론
Runner는 단순 자동화 도구가 아니라
"개발 + 운영 + 보안 자동화를 수행하는 핵심 실행 인프라"입니다.
특히 보안 관점에서는
- 권한
- Secret
- 네트워크
- 배포 승인
- 감사 로그관점까지 포함해 관리해야 합니다.
그리고 Docker 기반 Runner는 매우 편하지만
docker.sock
privileged
self-hosted 권한등으로 인해 사실상
"강력한 자동화 서버"처럼 취급하고 보호해야 합니다.
댓글