배포 (Deployment)

구성 요소	역할	대표적인 도구
소스 코드 관리 (SCM)	코드의 버전을 관리하고 변경 이력을 추적하며, 협업의 중심점 역할.	Git, GitHub, GitLab, Bitbucket
빌드 서버 (CI 서버)	SCM의 코드 변경을 감지하여 자동으로 코드를 빌드하고 테스트를 실행.	Jenkins, GitLab CI, GitHub Actions, CircleCI
아티팩트 저장소	빌드 결과물(Artifact)인 실행 파일, 컨테이너 이미지 등을 저장하고 관리.	Docker Hub, Nexus, JFrog Artifactory, AWS ECR
배포 대상 (Target)	애플리케이션이 최종적으로 실행될 환경.	물리 서버, 가상 머신(VM), 컨테이너(Kubernetes), 서버리스(AWS Lambda)
구성 관리 / IaC	배포 대상 환경의 인프라 구성을 코드로 정의하고 관리.	Ansible, Terraform, AWS CloudFormation
모니터링 & 로깅	배포된 애플리케이션의 상태, 성능, 오류 등을 실시간으로 추적.	Prometheus, Grafana, Datadog, ELK Stack

전략 (Strategy)	설명	장점	단점
롤링 배포 (Rolling Deployment)	여러 대의 서버 중 일부 서버부터 순차적으로 새 버전을 배포하는 방식. 구버전과 신버전이 동시에 공존한다.	서비스 중단 없이 배포 가능 (무중단 배포). 문제가 발생해도 일부 서버에만 영향을 미친다.	배포 중 일시적으로 버전 불일치 상태가 존재. 롤백이 복잡할 수 있다.
블루-그린 배포 (Blue-Green Deployment)	현재 운영 중인 환경(블루)과 동일한 구성의 신규 환경(그린)을 미리 준비한 후, 트래픽을 한 번에 그린으로 전환하는 방식.	즉각적인 전환과 롤백이 가능. 배포 중 서비스에 영향이 전혀 없다.	서버 자원이 2배로 필요하여 비용이 많이 든다.
카나리 배포 (Canary Deployment)	전체 사용자 중 극히 일부(예: 1%)에게만 신규 버전을 먼저 공개하여 위험을 감지하는 방식. ‘탄광의 카나리아’처럼 위험을 미리 감지한다는 의미.	위험을 최소화하며 신규 버전을 테스트할 수 있다. A/B 테스트로 활용 가능하다.	구현이 복잡하고, 특정 사용자만 겪는 문제를 파악하기 어려울 수 있다.

시스매