“개발은 끝났는데 배포가 문제야”라는 말, 들어본 적 있으신가요? 실제로 많은 팀들이 개발은 잘하고도 배포에서 삐끗합니다. 이 문제를 해결해주는 데브옵스(DevOps)의 핵심 도구인 CI/CD, 그리고 그 대표 주자인 Jenkins와 GitHub Actions. 각각 어떤 상황에서 쓰면 좋은지, 어떻게 구축해야 하는지, 직접 써본 사람처럼 자세히 알려드릴게요. 이 글을 끝까지 읽고 나면, 여러분 팀의 배포 파이프라인도 더 빠르고 튼튼해질 거예요.
- 1. Jenkins vs GitHub Actions 요약 비교 – 무엇이 더 좋은지는 ‘어디에 쓰느냐’에 달려 있어요.
- 2. Jenkins 설치부터 파이프라인 작성까지 – 직접 서버를 세팅해야 하지만, 원하는 대로 다 됩니다.
- 3. GitHub Actions, 생각보다 훨씬 간단하고 강력해요 – YAML만 잘 쓰면 자동화가 끝나요.
- 4. 민감 정보? 걱정 마세요. 시크릿 관리 팁까지 다 알려드려요
- 5. 실무자들이 자주 놓치는 CI/CD 팁 모음 – 이런 거 알고 있으면 일 진짜 잘한다는 소리 들어요.
1. Jenkins vs GitHub Actions 요약 비교
| 항목 | Jenkins | GitHub Actions |
|---|---|---|
| 설치 방식 | 직접 설치 (온프레미스/클라우드 VM) | GitHub 내장 서비스 |
| 스크립트 언어 | Groovy (Jenkinsfile) | YAML (.github/workflows) |
| 확장성 | 플러그인 1800+개, 완전 자유도 | Marketplace 액션 활용, 유연성 제한적 |
| 러너 | 직접 설정한 에이전트 | GitHub 호스티드 또는 자체 러너 |
| 강점 | 레거시 시스템, 특수 환경 배포에 강함 | 빠른 세팅, GitHub 친화적, 클라우드 배포 편리 |
| 단점 | 설정 복잡, 유지보수 필요 | GitHub 종속성, 복잡한 시나리오 한계 |
두 툴 다 좋아요. 다만, 상황에 따라 더 잘 맞는 쪽이 있죠. 예를 들어, 스타트업이 빠르게 서비스를 배포하려면 GitHub Actions가 딱이고, 복잡한 사내 배포 시스템을 갖춘 대기업은 Jenkins가 더 맞을 수 있어요.
2. Jenkins 설치부터 파이프라인 작성까지
Jenkins는 자유도가 매우 높은 오픈소스 CI 서버예요. Java 기반이라 설치 전 JDK 세팅은 필수고요. 웹 UI 기반이라 설정도 어렵지 않아요. 플러그인 설치로 Git, Docker, Slack 같은 툴들과 손쉽게 연결되죠. 실제로 저는 AWS EC2에 Jenkins를 설치해서 배포 자동화를 했는데, 리눅스 초보라도 천천히 따라 하면 충분히 가능해요.
Jenkinsfile 구조 예시
아래는 Node.js 프로젝트 기준으로 작성한 Jenkinsfile 예시예요. build → test → deploy 순으로 진행되죠.
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'npm install && npm run build'
}
}
stage('Test') {
steps {
sh 'npm test'
}
}
stage('Deploy') {
steps {
withCredentials([string(credentialsId: 'DEPLOY_KEY', variable: 'KEY')]) {
sh './deploy.sh'
}
}
}
}
}
이 파일만 리포지토리에 넣으면 Jenkins가 알아서 실행해줘요. 브랜치별로 다르게 작동시키고 싶으면 ‘멀티브랜치 파이프라인’ 잡으로 설정하면 되고요.
3. GitHub Actions, 생각보다 훨씬 간단하고 강력해요
GitHub Actions는 깃허브에 코드를 올리는 순간부터 시작되는 자동화 툴이에요. 설치할 것도 없고, 설정도 깔끔하죠. 특히 GitHub 저장소만 잘 관리하면, 다른 툴 없이도 완전한 CI/CD가 가능해요.
Node.js 워크플로우 예시
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 18
- run: npm install
- run: npm test
- run: npm run build
이렇게 .github/workflows/ci.yml 파일 하나로 CI 파이프라인이 완성돼요. 예전엔 Jenkins Groovy 문법에 진짜 진절머리 났었는데, YAML은 훨씬 간결하고 눈에 잘 들어오더라고요. 🤓
4. 시크릿 관리도 이렇게 하면 끝!
시크릿 관리는 보안에서 제일 중요한 부분인데요. Jenkins에서는 Credentials 기능을 쓰고, GitHub Actions는 secrets로 해결해요.
- Jenkins:
withCredentials()블록으로 환경변수처럼 사용 - GitHub Actions:
${{ secrets.MY_SECRET }}형식으로 사용
시크릿을 설정한 후 로그에 노출되지 않게 자동 마스킹도 되고요. GitHub Actions에서는 S3, ECS 배포도 몇 줄만 적으면 끝나고, Jenkins는 좀 더 세밀한 배포 로직도 작성 가능해요. 개인적으로는 Actions에서 빠르게 세팅하고, 실제 운영 배포는 Jenkins에서 처리하는 식의 하이브리드 구조도 추천합니다.
5. 실무에서 바로 쓰는 CI/CD 활용 팁
✔ Jenkins 실전 팁
- Shared Library로 파이프라인 코드 재활용
- 폴더별 권한 제어로 대규모 구성 대응
- Cloud Agent로 빌드 대기 시간 줄이기 (Kubernetes plugin 추천!)
✔ GitHub Actions 실전 팁
- 워크플로우 분리로 빌드/배포 관리
- workflow_call 기능으로 재사용성 향상
- self-hosted runner로 내부 시스템도 자동화 가능
실제로 제가 경험한 건데, Jenkins에서는 매번 스크립트를 복붙하다가 실수하는 경우가 많았어요. 그때 Shared Library를 적용하니까 코드가 깔끔해졌고, 팀원들도 더 쉽게 이해하더라고요. Actions에서는 실패 알림을 슬랙으로 받아보게 해놨더니, 새벽에 오류 나도 바로 대처할 수 있었고요. 진짜 회사에서 칭찬받는 포인트입니다 😎
결론: CI/CD 툴은 상황에 따라 고르는 게 진짜 핵심이에요
Jenkins와 GitHub Actions, 둘 다 잘 만든 도구예요. “뭐가 더 좋다”보다는 “우리 상황에 뭐가 맞는가”가 더 중요해요. 복잡한 환경, 자체 서버, 레거시 연동이 많다면 Jenkins가 좋고, 빠른 구축과 쉬운 관리가 필요하다면 Actions가 좋아요. 가장 이상적인 건 상황에 맞게 하이브리드로 섞어서 쓰는 것이에요. 예를 들어 GitHub Actions에서 코드를 빌드하고, Jenkins에서 QA 및 릴리즈 프로세스를 진행하는 식으로요.
기억하세요. CI/CD의 핵심은 기술이 아니라, 팀의 개발·배포 흐름을 얼마나 매끄럽게 만들 수 있는지예요. 오늘 이 글을 읽으신 여러분의 파이프라인도 더 효율적으로 바뀌길 진심으로 바래요!