# CI/CD 파이프라인(Continuous Integration/Continuous Deployment) CI/CD 파이프라인은 소프트웨어 개발 라이프사이클에서 코드 변경을 자동으로 통합하고 빌드, 테스트, 배포까지 반복 가능한 프로세스를 말한다. 이를 통해 코드 품질을 높이고 배포 속도와 안정성을 동시에 달성하는 것을 목표로 한다. 본 문서는 CI/CD 파이프라인의 개념, 구성 요소, 구현 방법, 베스트 프랙티스, 흔히 만나는 문제점 및 해결책을 백과사전 형식으로 정리한다. 용어는 필요에 따라 영어 표기(CI, CD, pipeline, artifact 등)를 병기하여 이해를 돕는다. --- ## 1. 개요 - Continuous Integration(CI) - 개발자가 변경한 코드를 자주(일일 다수) 공유 저장소에 병합하고, 자동화된 빌드와 테스트를 통해 변경 사항이 시스템에 무해한지 신속히 검증하는 방식이다. - Continuous Delivery(또는 Continuous Deployment, CD) - CI 이후의 과정으로, 소프트웨어를 자동으로 빌드된 상태의 아티팩트로 만들어 배포 가능한 형태로 유지하는 프로세스다. Continuous Delivery는 배포를 수동 승인으로 끝내고, Continuous Deployment는 자동으로 프로덕션에 배포한다는 차이가 있다. - 파이프라인의 목표 - 코드 품질 향상: 자동화된 테스트와 품질 게이트를 통해 버그를 조기에 발견 - 배포 속도와 신뢰성 증가: 반복 가능하고 재현 가능한 배포 프로세스 - 위험 관리: 롤백, 블루/그린, 카나리 등의 배포 전략 지원 --- ## 2. 핵심 용어와 구성 요소 - 소스 코드 관리(SCM, Source Control Management) - 예: Git, 브랜칭 전략(메인/마스터, develop, feature, release 등) - 빌드(Build)와 의존성 관리 - 의존성 버전 관리, 캐시 활용, 재현 가능한 빌드 산출물 생성 - 테스트(Test) - 단위 테스트(Unit), 통합 테스트(Integration), 성능 테스트(Performance), 보안 테스트(SAST/DAST) 등 - 아티팩트 저장소(Artifact Registry) - 빌드 산출물의 저장소. 예: npm 패키지, Maven/Microservice Jar, Docker 이미지 - 배포 및 인프라 자동화(Infrastructure as Code, IaC) - 인프라 구성의 코드화: Terraform, CloudFormation, Pulumi 등 - 비밀 관리(Secrets Management) - API 키, 데이터베이스 자격증명 등의 안전한 관리 - CI/CD 실행 환경(Runners/Agents) - Jenkins Agent, GitHub Actions runners, GitLab Runners 등 - 배포 전략(Deployment Strategies) - 블루-그린(Blue/Green), 카나리(Canary), 롤링(Rolling), 핫 스태시(Hot Swap) 등 - 관찰성(Observability)과 모니터링 - 지표, 로그, 트레이싱을 통한 배포 결과 관찰 및 자동 롤백 가능성 평가 --- ## 3. 파이프라인의 단계 - Plan/Commit - 코드 변경을 로컬에서 커밋하고 원격 저장소에 푸시. 프롬프트 각 단계에서의 변경점 요약 및 이슈 연결 - Build - 소스 코드로부터 실행 가능한 아티팩트를 생성. 의존성 설치, 컴파일, 번들링, 이미지 빌드 포함 - Test - 단위 테스트, 통합 테스트, 정적 분석(SAST) 및 동적 분석(DAST) 수행. 커버리지 지표를 포함할 수 있다 - Package/Artifact Publish - 빌드 결과물을 아티팩트 저장소에 저장. 태그를 통한 버저닝 포함 - Release - 프로덕션 배포를 위한 준비 단계. 메타데이터 생성, 릴리스 노트 작성, 승인을 위한 정책 적용 - Deploy/Delivery - 배포 대상 환경에 아티팩트를 적용. 프로비저닝, 구성 관리, 컨테이너 이미지 배포 포함 - Verify/Operate - 배포 후 건강 점검, 자동 롤백 조건 확인, 가용성 지표 모니터링 - Monitor/Feedback - 운영 지표, 로그, 경고를 수집하고 파이프라인에 피드백으로 반영 --- ## 4. 브랜칭 전략과 트리거링 - 브랜칭 모델 - 메인/마스터: 안정 버전의 원천 - develop/mainline: 통합 및 테스트를 위한 주 흐름 - feature/개별-기능: 기능 단위 작업 - release/vX.Y: 릴리스 준비 - 트리거 방식 - Push 트리거: 특정 브랜치에 변경이 푸시되면 파이프라인 실행 - PR(Pull Request) 트리거: 변경 내용이 리뷰를 거쳐 병합될 때 파이프라인 실행 - 스케줄드 트리거: 정해진 일정에 따라 정기 실행 - 정책 - 자동화된 품질 게이트(테스트 커버리지, 코드 스멜, 보안 스캔 등) 통과 시에만 다음 단계 진행 - 프로덕션 배포는 승인(Manual Approval) 단계 포함 여부 결정 --- ## 5. 구현 기술 및 도구 스택 - CI/CD 서비스/도구 - Jenkins, GitHub Actions, GitLab CI/CD, CircleCI, Travis CI, Bamboo 등 - 컨테이너화 및 실행 환경 - Docker, Kubernetes, Docker Compose - IaC(Infrastructure as Code) - Terraform, AWS CloudFormation, Pulumi, Ansible - 모델링 및 파이프라인 구성 형식 - YAML, Helm 차트, Jenkinsfile - 아티팩트 저장소 및 레지스트리 - Nexus/Artifactory, GitHub Packages, Docker Hub, ECR/ACR - 테스트 및 품질 도구 - Jest, PyTest, JUnit, SonarQube, CodeClimate - 보안 도구 - SAST(정적 분석), DAST(동적 분석), SCA(종속성 관리) - 관찰성 도구 - Prometheus, Grafana, ELK/EFK 스택, OpenTelemetry --- ## 6. 배포 전략 - 블루-그린(Blue/Green) - 두 개의 동일한 환경 중 하나에만 트래킹 배포를 수행하고, 트래픽 전환으로 롤백이 빠르게 가능 - 카나리(Canary) 배포 - 작은 비율로 새 버전을 점진적으로 배포하고 지표를 모니터링한 뒤 전체 배포 여부를 결정 - 롤링(Rolling) 배포 - 점진적으로 새로운 버전으로 교체하되 서비스 중단을 최소화 - 모노리포/마이크로서비스 관점 - 각 서비스별로 독립적인 파이프라인 구성 가능 --- ## 7. 품질, 보안 및 거버넌스 - 코드 품질 - 정적 코드 분석(SAST), 코드 커버리지 목표 설정, 정적 품질 게이트 - 보안 - SCA로 의존성 취약점 관리, DAST/리퀘스트 테스트, 시크릿 관리 자동화 - 거버넌스 - 배포 승인의 이력 관리, 롤백 정책 문서화, 감사 로그 확보 - 비용 관리 - 파이프라인 실행 시간과 실행 빈도에 따른 비용 모니터링 및 최적화 --- ## 8. 모니터링, 테스팅 및 롤백 메커니즘 - 자동화된 건강 점검 - 서비스 가용성, 응답 시간, 오류율 모니터링 - 카나리 분석 - 특정 지표(에러율, 처리량, 실패율 등) 상승 시 자동 차단 또는 롤백 - 롤백 전략 - 실패 시 이전 안정 버전으로의 신속한 롤백 가능성 확보 - 로그/메트릭스 표준화 - 일관된 로깅 포맷, 구조화된 메트릭 수집, 중앙 집중식 대시보드 --- ## 9. 운영상 고려사항과 모범 사례 - 재현성 보장 - 동일한 빌드 아티팩트에서 동일한 결과를 재현 가능하도록 버전 고정 - 환경 격리 - 테스트/스테이징 환경을 프로덕션과 가능한 동일하게 구성 - 비밀 관리 - 환경별 자격증명을 자동으로 주입하고, 코드 저장소에 노출되지 않도록 관리 - 템플릿화와 표준화 - 파이프라인 템플릿 작성으로 팀 간 일관성 유지 - 피드백 루프 - 운영 팀과 개발 팀 간의 피드백 루프를 통한 지속적 개선 --- ## 10. 간단한 구현 예시 다음은 GitHub Actions를 사용하는 간단한 CI/CD 파이프라인 예시이다. 이 예시는 코드 푸시 시 빌드 및 테스트를 수행하고, main 브랜치로의 병합 시 배포를 트리거한다. ```yaml name: CI/CD Pipeline on: push: branches: - '**' pull_request: branches: - '**' jobs: build-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - name: Install dependencies run: npm ci - name: Run unit tests run: npm test - name: Build run: npm run build - name: Upload build artifact if: success() uses: actions/upload-artifact@v3 with: name: build path: dist/ deploy-prod: needs: build-test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - uses: actions/checkout@v4 - name: Download artifact uses: actions/download-artifact@v3 with: name: build - name: Deploy to production run: | echo "Deploying to production..." # 실제 배포 명령어 삽입 (예: kubectl apply, Helm upgrade, 또는 CLI 배포 스크립트) ``` 참고로 실제 환경에 맞춰 테스트 범위, 보안 스캔, 아티팩트 관리, 롤백 정책 등을 구체화해야 한다. 또한 클라우드 공급자별 특화 도구(Terraform, CloudFormation, AWS CodePipeline 등)로 확장하는 것도 일반적이다. --- ## 11. 도입 시 체크리스트 - 목표 정의 - CI/CD 도입으로 달성하고자 하는 지표(KPI) 설정 - 브랜칭 및 정책 - PR 게이트, 승인 정책, 코드 리뷰 프로세스 확립 - 도구 및 인프라 선정 - 팀 규모, 서비스 특성, 보안 요구사항 반영 - 인프라/애플리케이션 보안 - 비밀 관리, 의존성 관리 자동화, 주기적 보안 스캔 - 조직 문화 - DevOps 문화 정착, 협업 및 자동화에 대한 교육 --- ## 12. 관련 연구 및 확장 주제 - DevOps 문화와 거버넌스 - GitOps와 CI/CD의 관계 - Cloud-Native 배포 패턴 및 운영 관행 - 무중단 배포를 위한 운영 전략 --- 관련 문서: [[CI-CD 파이프라인 아키텍처]], [[CI-CD 보안과 거버넌스]]