🥔CI (Continuous Integration, 지속적 통합)
무엇인가
- CI는 개발자가 작성한 코드를 자주(main 브랜치에) 병합하고
병합 시점마다 자동으로 빌드와 테스트를 실행하는 방식이다.
왜 필요한가
- 개인 환경에서만 정상 동작하는 문제를 방지한다.
- 충돌을 초기에 발견한다.
- 코드 품질을 지속적으로 유지한다.
CI에서 하는 일
- 코드 체크아웃을 수행한다.
- 빌드를 수행한다.
- 유닛 테스트를 실행한다.
- 정적 분석을 수행한다.
- 결과 리포트를 생성한다.
예시 흐름
Commit / MR
↓
자동 빌드
↓
자동 테스트
↓
성공 / 실패 피드백🥔CD (Continuous Delivery / Continuous Deployment)
두 가지 의미
- CD는 두 가지 개념으로 사용된다.
Continuous Delivery
- 배포 가능한 상태까지 자동화한다.
- 실제 배포는 사람이 직접 수행한다.
Continuous Deployment
- 테스트를 통과하면 자동으로 즉시 배포한다.
CD에서 하는 일
- 패키징을 수행한다.
- 배포 환경을 구성한다.
- 서버 또는 클라우드에 배포한다.
- 롤백을 대비한 절차를 준비한다.
🥔CI/CD 파이프라인
파이프라인이란
- 파이프라인은 자동화된 작업들의 흐름이다.
전형적인 단계
- Checkout
- Build
- Test
- Package
- Deploy
🥔CI/CD를 사용하는 핵심 이유
| 문제 | CI/CD의 역할 |
|---|---|
| 수동 빌드 | 자동화한다 |
| 배포 실수 | 표준화한다 |
| 느린 피드백 | 즉시 확인한다 |
| 품질 저하 | 테스트를 강제한다 |
| 릴리즈 스트레스 | 지속 배포로 완화한다 |
🥔대표적인 CI/CD 도구
CI/CD 도구
- Jenkins
- GitLab CI/CD
- GitHub Actions
- TeamCity
- CircleCI
배포 및 연동 도구
- Docker
- Kubernetes
- AWS / GCP / Azure
- Argo CD
🥔CI/CD 예시 개념 (GitLab CI)
stages:
- build
- test
- deploy
build:
script: make build
test:
script: make test
deploy:
script: ./deploy.sh🥔게임 개발 관점에서 CI/CD
일반 서비스와의 차이
- 빌드 시간이 길다.
- 플랫폼별 빌드가 필요하다. (PC / Console / Mobile)
- 대용량 에셋을 다룬다.
게임 CI/CD에서 수행하는 작업
- 자동 빌드를 수행한다.
- 자동 패키징을 수행한다.
- 에셋 검증을 수행한다.
- QA용 빌드를 배포한다.
🥔CI/CD 도입의 현실적인 단계
1단계
- 자동 빌드만 적용한다.
2단계
- 자동 테스트를 추가한다.
3단계
-
자동 배포를 적용한다.
-
처음부터 모든 것을 자동화하려 하지 않는다.
🥔CI/CD에 대한 흔한 오해
- CI/CD는 특정 툴을 의미하지 않는다.
- CI/CD는 문화와 프로세스를 의미한다.
- 모든 작업을 자동화할 필요는 없다.
- 중요한 작업부터 자동화한다.
🥔한 문장 정리
- CI/CD는 사람이 반복하던 작업을 신뢰 가능한 자동화로 대체하는 방식이다.
🥔GitLab과 Jenkins를 함께 사용하는 이유
한 줄 요약
- GitLab은 관리와 협업의 중심 역할을 한다.
- Jenkins는 자동화 실행 엔진 역할을 한다.
🥔역할 분담 관점
GitLab의 역할
- 소스 코드 저장소(SCM)를 담당한다.
- Merge Request와 코드 리뷰를 담당한다.
- 권한 관리와 이슈 관리를 담당한다.
- 변경 이벤트를 Webhook으로 전달한다.
- 개발 흐름의 중심 역할을 수행한다.
Jenkins의 역할
- 복잡한 빌드와 배포 파이프라인을 처리한다.
- 다양한 플러그인과 연동한다.
- 레거시 시스템을 지원한다.
- 장시간, 대용량 작업을 처리한다.
- 자동화 실행기 역할을 수행한다.
함께 사용하는 흐름
개발자
↓
GitLab (Push / MR)
↓ Webhook
Jenkins (Build / Test / Deploy)
↓
결과를 GitLab에 리포트🥔역사적 배경
- Jenkins는 CI/CD 1세대 도구다.
- 많은 조직이 이미 Jenkins 인프라를 보유하고 있다.
- GitLab CI는 상대적으로 늦게 등장했다.
- 기존 Jenkins를 완전히 대체하기 어렵다.
- Jenkins를 유지하며 GitLab과 병행 사용한다.
🥔복잡한 파이프라인 관점
GitLab CI의 특성
- 단순하고 표준적인 파이프라인에 적합하다.
- 플러그인 생태계가 제한적이다.
- 특수 환경 연동이 불편하다.
Jenkins의 특성
- 커스터마이징 자유도가 높다.
- 다양한 환경을 유연하게 지원한다.
- 게임 빌드처럼 복잡한 작업에 강하다.
🥔보안 및 네트워크 구조
- GitLab은 외부 접근이 가능하다.
- Jenkins는 내부망에 격리해 운영한다.
외부 (GitLab)
↓
내부망 (Jenkins Agents)- 보안 정책을 만족시키기 쉽다.
🥔대규모 조직 운영 관점
GitLab 단독 사용 시
- CI Runner 관리 부담이 커진다.
- 빌드 서버 확장이 어렵다.
Jenkins 병행 사용 시
- Agent를 자유롭게 추가한다.
- OS와 플랫폼별로 분리 운영한다.
- 리소스 관리가 수월하다.
🥔왜 Jenkins를 계속 사용하는가
| 이유 | 설명 |
|---|---|
| 기존 자산 | Jenkins 인프라를 이미 보유 |
| 복잡성 | Jenkins의 유연성이 더 높음 |
| 플러그인 | Jenkins 생태계가 압도적 |
| 보안 | 네트워크 분리가 용이 |
| 게임 특성 | 빌드가 무겁고 특수함 |
🥔GitLab CI만으로 충분한 경우
- 웹 서비스 또는 백엔드 서비스다.
- 빌드 구조가 단순하다.
- 클라우드 중심 환경이다.
- 신규 프로젝트다.
🥔실무에서 자주 쓰는 구조
패턴 A
- GitLab은 SCM과 MR을 담당한다.
- Jenkins는 CI/CD를 담당한다.
패턴 B
- GitLab CI는 기본 CI를 담당한다.
- Jenkins는 무거운 빌드 전용으로 사용한다.
🥔한 문장 결론
- GitLab과 Jenkins 조합은 관리와 실행을 분리한 현실적인 선택이다.
말하는 감자🥔