> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/6-3.-devops-and-ci-cd.md).

# 6-3. DevOps & CI/CD

Devops와 CI/CD에 대하여

### DevOps와 CI/CD의 등장 배경

* 전통적인 구조의 문제점과 DevOps의 정의 기존의 Monolithic 아키텍처나 점진적 개발 환경에서는 1Phase 기반의 일괄적 반영이 이루어져 발빠른 요구사항 대응에 한계가 존재한다. 전통적인 구조에서는 개발팀은 기능 개발을 담당하며 코드가 잘 작동한다고 주장하고, 운영팀은 배포 및 운영을 담당하며 운영 환경에서는 정상 작동하지 않는다고 대립하여 서로 책임을 미루는 현상이 발생한다. 이에 따라 배포가 느려지고 장애 대응도 늦어진다. 이러한 장벽을 깨고 개발과 운영의 경계를 허물어 유연하게 통합한 환경을 제공하기 위해 DevOps가 등장한다.
* MSA, Cloud Native와 CI/CD의 연동 발빠른 대응과 대처를 위해 시스템 체계를 유연화하고자 MSA와 Cloud Native 패러다임이 발생한다. 그리고 각 분류된 개별적 서비스의 빠른 통합 및 배포, 런타임 적용을 위해 CI/CD가 수반된다. CI(Continuous Integration)는 Git, Gradle 등을 활용한 빌드 및 패키징(Build/Packaging) 단계를 의미하며, CD(Continuous Deployment)는 Ansible, Terraform 등을 활용한 배포(Deployment) 단계를 뜻한다. 이 전체 과정을 Jenkins와 같은 도구를 통해 파이프라인으로 연결하여 한 번에 유연하게 진행한다.
* DevOps와 Agile의 관계 Agile이 방법론적 측면에서 소통과 유연한 피드백을 강조한다면, DevOps는 이를 기술적, 인프라적으로 뒷받침하여 실제 소스 코드가 통합되고 배포되는 전 과정을 자동화 체계로 관장한다.

### CI/CD 파이프라인 흐름 (CI/CD Flow)

* 전체 빌드 및 배포 파이프라인 메커니즘 개발자가 코드를 작성하여 Git에 push하면, Jenkins나 Travis CI 등의 도구가 pull 또는 웹훅(web hook)을 통해 코드를 가져온다. 이후 Gradle 빌드 및 소나큐브(SonarQube) 등을 통한 정적 코드 분석과 테스트 과정을 거치며 빌드 결과물(Artifact/Jar)을 생성한다. 이 결과물은 Docker를 통해 이미지화되어 Docker Registry(Hub)로 push된다. 배포 단계에서는 Ansible, Terraform 등을 사용하여 서버 인프라를 프로비저닝하고 제어하며, 최종적으로 해당 Docker 이미지를 타겟 서버 환경에 컨테이너로 실행(run)하여 런타임 적용을 완료한다.

### 분산 환경의 배포 전략 (카나리 배포 vs 블루그린 배포)

#### 카나리(Canary) 배포 

* 전체 서버 중 아주 일부분의 인스턴스(예: 10%)에만 신규 버전(V2)을 우선 배포하여 운영하는 방식이다. 라우터를 통해 트래픽의 일부만 V2로 유도하고, 대부분의 트래픽은 기존 버전(V1)으로 유지한다. 이 상태에서 실시간으로 에러와 로그를 모니터링하며, 이상이 없을 시 신규 버전의 인스턴스 비율을 점진적으로 늘려가며 배포를 완료한다. 버그나 장애 발생 시 트래픽 라우팅만 원래대로 돌리면 되므로 장애 전파 리스크를 최소화할 수 있는 안전한 전략이다.

#### 블루그린(Blue-Green) 배포 

* 현재 운영 중인 구버전 환경(Blue)과 완전히 동일한 스펙의 신규 버전 환경(Green)을 별도로 동시에 구축해 두는 방식이다. Green 환경에 신규 버전을 미리 배포하여 완벽하게 테스트를 진행한 후, 준비가 완료되면 로드밸런서의 라우팅 설정을 변경하여 트래픽을 Green으로 한 번에 전환한다. 
* 구버전과 신버전이 동시에 떠 있으므로 전환 속도가 매우 빠르고 예기치 못한 문제 발생 시 로드밸런서를 다시 Blue로 돌리기만 하면 되므로 즉각적인 롤백이 가능하다. 다만 동일한 규모의 인프라 환경이 2배로 필요하므로 자원 비용이 많이 들고 데이터베이스 마이그레이션 비용 및 트래픽 전환에 대한 위험도가 존재한다.

### 부가적인 패턴 및 배포 방식

#### 사이드카 패턴 (Sidecar Pattern)

*  부가적인 공통 관심사 로직을 별도로 분리하여 메인 컨테이너(Application) 옆에 추가적인 컨테이너(Additional Container)로 구성하는 방식이다. 메인 컨테이너는 오직 핵심 비즈니스 로직에만 집중하고, 로깅, 모니터링, 프록시 통신(인프라/보안/제어 등)과 같은 공통 관심사는 사이드카 컨테이너가 전담하여 처리하도록 역할을 분리한다.

#### 롤링 업데이트 (Rolling Updates) 

* 로드밸런서를 기반으로 신규 환경을 적용할 때, 전체 인스턴스를 한 번에 교체하지 않고 순차적으로 적용하는 방식이다. 하나의 인스턴스를 로드밸런서 목록에서 삭제(제외)한 후 신규 버전을 적용하여 다시 목록에 추가하는 과정을 반복한다. 적용된 인스턴스의 점진적 적용과 배포를 수반하여 서비스 중단 없이 무중단 배포를 달성할 수 있다.

### 서버리스 (Serverless)

* 서버가 완전히 존재하지 않는다는 의미가 아니라, 개발자가 별도의 서버 관리, 보안, 확장(Auto Scaling) 등을 신경 쓰지 않도록 클라우드 제공사 측에서 인프라를 전적으로 관리해 주는 개념이다. 서버를 이용하는 사용자는 오직 코드가 수행되는 동작과 사용에만 관심이 있고, 서버 관리 비용 및 인프라 제어는 클라우드 측에 위임한다.
* BaaS(Backend as a Service) 환경을 활용하거나, 특정 이벤트 기반의 함수 실행 방식(FaaS) 혹은 구성된 프로젝트 단위로 구축한다.
* 대표적으로 AWS Lambda 등이 존재하며, 특정 엔드포인트(예: `/hello`) 호출 시 이에 대한 처리 함수를 조각화하여 FaaS에 구성하고 호출된 만큼만 비용을 지불하는 방식으로 동작한다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://leehyokyun.gitbook.io/openbook/6-3.-devops-and-ci-cd.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.