CI/CD 파이프라인은 왜 필요하며, 어떻게 구성해야 할까?

[paiwhy]

📆 일자: 26년 8월 8일(목)

CI/CD 파이프라인은 코드 변경 사항을 사용자에게 안정적으로 전달하기 위한 자동화된 과정입니다. 개발자가 작성한 코드는 테스트와 빌드를 거쳐 배포 가능한 형태로 검증되며, 문제가 발생했을 때는 빠르게 이전 상태로 되돌릴 수 있어야 합니다. 이러한 과정이 자동화되지 않으면 배포마다 많은 수작업과 확인이 필요하고, 휴먼 에러나 장애 발생 가능성도 커집니다. 이에 따라 이번 스터디에서는 CI/CD가 필요한 이유를 이해하고, 실제 서비스 환경에서 안정적인 배포 파이프라인을 어떻게 구성할 수 있는지 알아보고자 합니다.

🤔오늘의 질문

1. CI/CD 파이프라인은 왜 필요하며, 안정적인 서비스 배포를 위해 어떤 단계로 구성해야 하나요?
2. CI와 CD는 각각 무엇을 의미하며, 자동화된 테스트와 빌드는 배포 과정의 어떤 문제를 해결하나요?
3. 배포 중 장애가 발생했을 때 롤백은 어떻게 설계해야 하며, Git 브랜치 전략은 CI/CD 파이프라인에 어떤 영향을 주나요?

[9ga0]

1. CI/CD 파이프라인은 왜 필요하며, 안정적인 서비스 배포를 위해 어떤 단계로 구성해야 하나요?

CI/CD 파이프라인은 코드를 자주, 자동으로, 안전하게 배포하기 위해 사용됩니다. 사람이 직접 테스트, 빌드, 서버 배포까지 수행하게 되면 실수가 발생할 가능성이 커집니다. 따라서 CI/CD를 사용하면 코드 변경이 들어올 때마다 테스트, 빌드, 검증, 배포가 정해진 절차대로 자동 실행되기 때문에 문제를 빨리 발견하고, 배포 품질을 일정하게 유지할 수 있다는 이점이 있습니다.

안정적인 배포 파이프라인

단계	목적
1. 코드 변경	개발자가 Pull Request 또는 Merge Request 생성
2. 정적 분석	코드 스타일, 린트, 보안 취약점, 타입 오류 검사
3. 자동 테스트	단위 테스트, 통합 테스트, API 테스트 실행
4. 빌드	실행 가능한 애플리케이션 또는 Docker 이미지 생성
5. 아티팩트 저장	빌드 결과물을 레지스트리나 저장소에 버전과 함께 저장
6. 스테이징 배포	운영과 비슷한 환경에 먼저 배포
7. 검증	E2E 테스트, 헬스 체크, 성능/모니터링 확인
8. 운영 배포	Blue-Green, Canary, Rolling 방식 등으로 배포
9. 모니터링	에러율, 응답 시간, CPU/메모리, 로그 확인
10. 롤백	장애 발생 시 이전 정상 버전으로 빠르게 복구

2. CI와 CD는 각각 무엇을 의미하며, 자동화된 테스트와 빌드는 배포 과정의 어떤 문제를 해결하나요?

CI란 Continuous Integration(지속적 통합)의 줄임말로, 개발자가 올린 코드를 자주 병합하고 자동 테스트/빌드로 문제를 빠르게 찾는 과정에 해당합니다. CD는 Continuous Deployment를 의미하며 검증된 코드를 운영 환경에 배포 가능한 상태로 만들거나, 자동으로 배포하는 과정을 의미합니다. 여기서 CD는 '실제 배포는 사람이 하냐'아니면 '자동으로 하냐'에 따라 Continuous Delivery와 Continuous Deployment 두가지로 나뉩니다.

자동화된 테스트는 변경된 코드가 기존 기능을 망가뜨렸는지 빠르게 확인하며, 회귀버그를 조기에 발견합니다. 자동화된 빌드는 컴퓨터와 서버의 동작 결과가 다른 문제를 줄여, 배포 결과물이 예측 가능하게 해줍니다.

자동화 항목	해결하는 문제
단위 테스트	함수/모듈 단위 버그 조기 발견
통합 테스트	DB, API, 외부 시스템 연동 문제 발견
E2E 테스트	실제 사용자 흐름이 깨졌는지 확인
정적 분석	스타일, 타입, 잠재 오류, 취약점 발견
자동 빌드	환경 차이, 수동 빌드 실수, 누락 파일 문제 방지

3. 배포 중 장애가 발생했을 때 롤백은 어떻게 설계해야 하며,

롤백은 문제가 생기면 빠르게 이전 정상 상태로 돌아가는 구조로 설계해야합니다. 즉 배포파일, 설정, DB변경을 모두 버전 관리를 하면 좋습니다. 특히 DB변경은 단순히 코드만 롤백한다고 해결되지 않을 수 있기 때문에 보통 하위 호환 방식으로 나누어 배포하는 것이 좋습니다.

하위 호환(Backward Compatibility): 새로운 버전으로 변경하더라도 이전 버전의 프로그램이 계속 정상적으로 동작할 수 있도록 만드는 것

좋은 롤백설계에 필요한 것

항목	설명
버전된 아티팩트	이전 Docker 이미지나 빌드 파일을 즉시 재배포할 수 있어야 함
헬스 체크	새 버전이 정상인지 자동으로 판단
Blue-Green 배포	새 환경에 배포 후 트래픽만 전환, 문제 시 기존 환경으로 즉시 복귀
Canary 배포	일부 사용자에게만 먼저 배포하고 지표가 나쁘면 중단
DB 마이그레이션 전략	되돌릴 수 있거나, 구버전/신버전 앱이 함께 동작 가능해야 함
설정 관리	환경 변수와 설정도 버전과 이력을 추적
모니터링 기준	에러율, 응답 시간, 장애 알림 기준을 명확히 설정

Git 브랜치 전략은 CI/CD 파이프라인에 어떤 영향을 주나요?

Git 브랜치 전략은 언제, 어떤 코드가 CI를 타고, 어떤 브랜치가 배포되는지를 결정합니다. 브랜치가 복잡할수록 파이프라인도 복잡해지고, 병합 충돌과 배포 지연이 늘어날 수 있습니다.

전략	특징	CI/CD 영향
Git Flow	main, develop, feature, release, hotfix 사용	절차는 명확하지만 브랜치가 많아 파이프라인이 복잡
GitHub Flow	main + feature branch 중심	단순하고 빠른 CI/CD에 적합
Trunk-Based Development	짧은 feature branch 후 main에 자주 병합	CI/CD 자동화와 지속 배포에 가장 잘 맞음

일반적으로 빠른 배포와 자동화를 원한다면 GitHub Flow나 Trunk-Based Dvelopment가 잘 맞지만, main 브랜치 품질을 지키기위해 PR테스트, 코드 리뷰, feature flag, 자동 롤백 등 추가 과정이 중요합니다.

요약

주제	한 줄 요약
CI/CD 필요성	배포를 자동화해 실수와 장애를 줄이고 빠르게 릴리스하기 위해
CI	코드를 자주 통합하고 자동 검증하는 과정
CD	검증된 코드를 배포 가능한 상태로 만들거나 자동 배포하는 과정
테스트/빌드 자동화	버그, 환경 차이, 수동 실수를 배포 전에 잡기 위해
롤백	이전 정상 버전으로 빠르게 돌아갈 수 있게 버전/트래픽/DB를 설계
브랜치 전략	코드 병합 주기와 배포 자동화 수준을 결정함

[k9425mino]

1. CI/CD 파이프라인은 왜 필요하며, 안정적인 서비스 배포를 위해 어떤 단계로 구성해야 하나요?

CI/CD 파이프라인은 소프트웨어의 코드 변경부터 테스트, 빌드, 배포까지의 과정을 자동화하기 위해 필요하다. 개발자가 코드를 수정할 때마다 수작업으로 테스트하고 배포하면 시간이 오래 걸리고, 사람의 실수로 인해 잘못된 코드가 운영 서버에 배포될 가능성이 있다. CI/CD를 사용하면 이러한 과정을 자동화하여 개발 속도와 서비스의 안정성을 높일 수 있다.

안정적인 서비스 배포를 위한 일반적인 CI/CD 파이프라인은 다음과 같이 구성할 수 있다.

1. 코드 작성 및 Git 저장소에 Push
   • 개발자가 코드를 작성하고 GitHub와 같은 저장소에 코드를 업로드한다.
2. 코드 검사 및 자동화된 테스트
   • 코드의 문법 오류나 정적 분석을 수행하고 단위 테스트, 통합 테스트 등을 자동으로 실행한다.
   • 문제가 발견되면 이후 단계로 진행하지 않는다.
3. 빌드(Build)
   • 테스트를 통과한 코드를 실행 가능한 프로그램이나 배포 가능한 Docker 이미지 등의 형태로 빌드한다.
4. 스테이징 환경 배포
   • 실제 운영 환경과 비슷한 테스트 환경에 배포하여 추가적인 검증을 진행한다.
5. 운영 환경 배포
   • 모든 검증을 통과하면 실제 사용자들이 사용하는 운영 서버에 배포한다.
   • 필요에 따라 블루-그린 배포, 카나리 배포 등의 방식을 사용할 수 있다.
6. 모니터링 및 롤백
   • 배포 후 서버 상태, 오류율, 응답 시간 등을 모니터링한다.
   • 문제가 발생하면 정상적으로 동작하던 버전으로 롤백한다.

따라서 CI/CD 파이프라인은 코드 변경 → 테스트 → 빌드 → 검증 → 배포 → 모니터링 → 롤백의 흐름으로 구성하여 배포 과정의 안정성을 확보할 수 있다.

---

2. CI와 CD는 각각 무엇을 의미하며, 자동화된 테스트와 빌드는 배포 과정의 어떤 문제를 해결하나요?

CI(Continuous Integration) 는 지속적 통합을 의미한다. 여러 개발자가 작성한 코드를 하나의 저장소에 자주 통합하고, 코드가 통합될 때마다 자동으로 테스트와 빌드를 수행하는 방식이다. CI를 사용하면 개발자가 작성한 코드가 기존 코드와 충돌하거나 새로운 기능으로 인해 기존 기능이 정상적으로 동작하지 않는 문제를 빠르게 발견할 수 있다.

CD(Continuous Delivery 또는 Continuous Deployment) 는 지속적 배포 또는 지속적 제공을 의미한다. CI를 통해 테스트와 빌드가 완료된 코드를 실제 배포 환경까지 자동으로 전달하는 과정이다. Continuous Delivery는 최종 배포 전에 승인을 거칠 수 있는 방식이고, Continuous Deployment는 검증을 통과하면 운영 환경까지 자동으로 배포하는 방식이다.

자동화된 테스트와 빌드는 배포 과정에서 다음과 같은 문제를 해결한다.

• 자동화된 테스트
  • 개발자가 직접 모든 기능을 확인해야 하는 수작업을 줄일 수 있다.
  • 새로운 코드가 기존 기능을 망가뜨리는 문제를 빠르게 발견할 수 있다.
  • 테스트 결과를 일관된 기준으로 확인할 수 있다.
  • 문제가 있는 코드가 운영 환경에 배포되는 것을 방지할 수 있다.
• 자동화된 빌드
  • 개발자가 직접 프로그램을 빌드하면서 발생할 수 있는 실수를 줄일 수 있다.
  • 개발자마다 다른 빌드 환경으로 인해 결과물이 달라지는 문제를 줄일 수 있다.
  • 항상 동일한 절차를 통해 배포 가능한 결과물을 생성할 수 있다.

결과적으로 CI는 코드의 품질과 통합 과정에서 발생하는 문제를 빠르게 발견하는 역할을 하고, CD는 검증된 코드를 안정적으로 배포하는 역할을 한다.

---

3. 배포 중 장애가 발생했을 때 롤백은 어떻게 설계해야 하며, Git 브랜치 전략은 CI/CD 파이프라인에 어떤 영향을 주나요?

롤백(Rollback) 은 새로운 버전을 배포한 이후 장애가 발생했을 때 이전에 정상적으로 동작하던 버전으로 되돌리는 작업이다. 안정적인 서비스를 위해서는 배포 전에 이전 버전으로 쉽게 돌아갈 수 있도록 설계해야 한다.

롤백을 설계할 때는 다음과 같은 방법을 사용할 수 있다.

1. 배포 버전 관리
   • 각각의 배포 결과물에 버전이나 Git Commit ID를 부여한다.
   • 문제가 발생하면 특정 이전 버전을 다시 배포할 수 있도록 한다.
2. 이전 버전의 배포 파일 보관
   • Docker 이미지나 빌드 결과물을 저장소에 보관하여 필요할 때 이전 버전을 다시 배포할 수 있도록 한다.
3. 자동 롤백
   • 배포 이후 오류율이나 서버 상태를 자동으로 확인하고 문제가 일정 수준 이상 발생하면 이전 버전으로 자동 복구하도록 구성할 수 있다.
4. 블루-그린 또는 카나리 배포 활용
   • 블루-그린 배포는 기존 버전을 유지한 상태에서 새로운 버전을 별도의 환경에 배포한 후 문제가 없을 때 트래픽을 전환하는 방식이다.
   • 카나리 배포는 일부 사용자에게만 새로운 버전을 먼저 제공하여 문제 여부를 확인한 후 점진적으로 전체 사용자에게 배포하는 방식이다.
   • 이러한 방식은 장애 발생 시 빠르게 기존 버전으로 트래픽을 돌릴 수 있다는 장점이 있다.

또한 Git 브랜치 전략은 CI/CD 파이프라인의 구성과 배포 방식에 직접적인 영향을 준다.

예를 들어 다음과 같은 브랜치 구조를 사용할 수 있다.

• main 브랜치: 실제 운영 환경에 배포되는 안정적인 코드
• develop 브랜치: 여러 기능을 통합하고 테스트하는 코드
• feature 브랜치: 개별 기능을 개발하는 브랜치

개발자는 feature 브랜치에서 작업한 후 Pull Request를 생성하고, CI에서 자동 테스트와 빌드를 수행한다. 테스트를 통과하면 develop 브랜치에 통합하고, 최종적으로 안정성이 검증되면 main 브랜치에 병합하여 운영 환경에 배포할 수 있다.

따라서 Git 브랜치 전략을 적절하게 구성하면 개발 코드와 운영 코드를 분리하고, Pull Request 단계에서 자동 테스트를 수행하며, 운영 환경에는 검증된 코드만 배포할 수 있다.

결론적으로 안정적인 CI/CD 환경을 구축하기 위해서는 자동화된 테스트와 빌드, 명확한 Git 브랜치 전략, 배포 버전 관리, 모니터링, 그리고 신속한 롤백 시스템을 함께 구성하는 것이 중요하다.

[JM-220]

1. CI/CD 파이프라인은 왜 필요하며, 안정적인 서비스 배포를 위해 어떤 단계로 구성해야 하나요?

왜 필요한가

수동 배포를 생각해보면 답이 나온다. 로컬에서 빌드하고, 파일 서버에 올리고, ssh 로 들어가서 프로세스 재시작하고... 이 과정에 문제가 몇 개 있다.

• 사람이 하니까 틀린다. 빌드를 깜빡하거나, 브랜치를 잘못 잡거나, 설정 파일만 안 올리거나. 그리고 이런 실수는 꼭 급할 때 난다.
• 재현이 안 된다. "내 로컬에서는 되는데" 문제. 배포하는 사람의 자바 버전이 다르면 결과물이 달라진다.
• 배포가 무서워지면 배포를 안 하게 된다. 그래서 변경을 몰아서 한 번에 올리게 되고, 그러면 터졌을 때 원인 찾기가 더 어려워진다. 악순환이다.
• 통합이 늦어진다. 각자 브랜치에서 2주씩 작업하다가 합치면 충돌이 지옥이 된다. 자주 합쳐야 하는데, 자주 합치려면 자주 검증할 수 있어야 하고, 그러려면 자동화가 필요하다.

단계

코드 push
  ↓ 정적 검사 (lint, 포맷, 컴파일)
  ↓ 테스트 (단위 → 통합)
  ↓ 빌드 (jar / 도커 이미지)
  ↓ 아티팩트 저장 (레지스트리에 태그 붙여서)
  ↓ 스테이징 배포 + 스모크 테스트
  ↓ 프로덕션 배포 (수동 승인)
  ↓ 헬스체크 / 모니터링

여기서 중요한 건 순서인 것 같다. 싸고 빠르게 실패하는 것을 앞에 둔다. 컴파일도 안 되는 코드를 굳이 도커 이미지까지 만들어보고 실패할 이유가 없다.

그리고 한 번 빌드한 아티팩트를 그대로 스테이징과 프로덕션에 올리는 것도 중요하다고 한다. 환경마다 다시 빌드하면 스테이징에서 통과한 그 바이너리와 프로덕션에 올라가는 바이너리가 다른 것이라, 스테이징 검증의 의미가 없어진다.

2. CI와 CD는 각각 무엇을 의미하며, 자동화된 테스트와 빌드는 배포 과정의 어떤 문제를 해결하나요?

CI (Continuous Integration, 지속적 통합)

작업한 코드를 자주(하루 한 번 이상) 메인 브랜치에 통합하고, 통합할 때마다 자동으로 빌드와 테스트를 돌려서 깨졌는지 바로 확인하는 것. 핵심은 "자동화" 보다 "자주" 쪽에 있는 것 같다. 자동화는 자주 하기 위한 수단이다.

CD 는 두 가지로 갈린다.

• Continuous Delivery (지속적 제공) : 언제든 배포 가능한 상태까지 자동으로 만들어두고, 실제 프로덕션 반영은 사람이 버튼을 누른다.
• Continuous Deployment (지속적 배포) : 테스트를 다 통과하면 사람 개입 없이 프로덕션까지 자동으로 나간다.

둘의 차이는 딱 "수동 승인 단계가 있느냐" 이다. 대부분의 회사는 Delivery 쪽인 것 같다.

자동화된 테스트와 빌드가 해결하는 것

• 회귀 버그를 조기에 잡는다. 내가 고친 코드가 다른 기능을 깼는지를 사람이 매번 다 확인할 수는 없다. 이걸 push 할 때마다 기계가 대신 확인해준다.
• 피드백이 빨라진다. 2주 뒤에 QA 에서 발견되는 것과 push 하고 5분 뒤에 알림 오는 것은 고치는 비용이 완전히 다르다. 5분 뒤면 내가 뭘 건드렸는지 아직 기억하고 있다.
• 환경 차이를 없앤다. 빌드가 늘 같은 CI 러너(같은 컨테이너 이미지)에서 돌아가니까 "내 로컬에서는 되는데" 가 사라진다.
• 리뷰의 부담을 줄인다. 리뷰어가 컴파일 되는지, 테스트 통과하는지를 볼 필요가 없어져서 설계나 로직에 집중할 수 있다.
• 배포를 사소한 일로 만든다. 결국 이게 제일 큰 것 같다. 배포가 버튼 하나면 자주 하게 되고, 자주 하면 한 번에 나가는 변경이 작아지고, 변경이 작으면 터졌을 때 원인이 명확하다.

3. 배포 중 장애가 발생했을 때 롤백은 어떻게 설계해야 하며, Git 브랜치 전략은 CI/CD 파이프라인에 어떤 영향을 주나요?

롤백

기본 원칙은 고치려 하지 말고 일단 되돌린다 인 것 같다. 장애 중에 원인 찾아서 핫픽스를 짜는 건 시간도 오래 걸리고 그 와중에 또 실수가 나온다.

• 이전 아티팩트를 버려두지 않는다. 버전 태그를 붙여서 레지스트리에 남겨두면, 롤백은 그냥 이전 태그로 다시 배포하는 것이 된다. 소스에서 다시 빌드하면 그것도 시간이 걸리고 결과가 같다는 보장도 없다.
• 배포 방식 자체를 되돌리기 쉽게 만든다.
  • 블루/그린 : 구버전(블루)을 그대로 띄워둔 채 신버전(그린)을 따로 올리고, 라우팅만 바꾼다. 롤백은 라우팅을 되돌리는 것이라 거의 즉시 된다. 대신 서버가 두 배로 필요하다.
  • 카나리 : 트래픽의 5% 만 신버전으로 보내보고, 에러율을 보면서 점진적으로 늘린다. 문제가 있어도 5% 만 영향받는다.
• 자동 롤백 조건을 미리 정해둔다. 헬스체크 실패, 에러율 임계치 초과 같은 조건을 걸어두고 자동으로 되돌리게 한다. 사람이 판단하면 그 사이에 시간이 간다.

여기서 제일 까다로운 건 DB 마이그레이션이다. 애플리케이션은 이전 이미지로 되돌리면 되는데, 이미 컬럼을 DROP 해버렸으면 데이터가 없어서 되돌릴 수가 없다. 그래서

• 파괴적인 변경(컬럼 삭제, 이름 변경)을 배포와 같이 하지 않는다.
• 컬럼 추가 → 코드 배포 → (안정화 확인) → 옛 컬럼 삭제 처럼 여러 번에 나눠서 나간다. 신구 버전이 동시에 떠 있어도 둘 다 동작하는 스키마를 유지하는 것이 핵심인 듯하다.

브랜치 전략의 영향

• Git Flow (main / develop / feature / release / hotfix) : 브랜치가 많고 릴리즈 주기가 길다. 통합이 늦게 일어나서 CI 의 장점을 살리기 어렵고, 파이프라인도 브랜치별로 나눠야 해서 복잡해진다. 정해진 버전 단위로 배포하는 제품(앱, 설치형)에 맞다.
• GitHub Flow (main + feature) : main 이 항상 배포 가능한 상태이고, feature 브랜치를 짧게 가져가서 PR 로 합친다. 파이프라인이 단순해진다. PR 이면 테스트, main 에 머지되면 배포. 웹 서비스 대부분이 이걸 쓴다.
• Trunk Based : 브랜치를 거의 안 만들고 main 에 바로 자주 커밋한다. CI 의 원래 취지에 제일 가깝다. 대신 미완성 기능이 main 에 들어가게 되므로 피처 플래그로 코드는 나가되 기능은 꺼두는 방식이 전제된다. 테스트 자동화 수준이 높지 않으면 위험하다.

정리하면 브랜치가 오래 살아있을수록 통합이 늦어지고, 통합이 늦어질수록 CI 가 무의미해진다. 그래서 CI/CD 를 제대로 하려면 브랜치를 짧게 가져가는 쪽이 유리하고, 짧게 가져가려면 테스트가 믿을 만해야 한다. 서로 물려 있는 것 같다.

---

파이프라인을 직접 구성해본 경험이 없어서 3번은 자신이 없다. 특히 카나리 배포에서 에러율 임계치를 실제로 어떻게 잡는지, DB 마이그레이션을 여러 단계로 나누는 걸 실무에서 정말 그렇게 하는지는 더 알아봐야겠다. 일단 개인 프로젝트에 GitHub Actions 로 테스트 + 빌드까지라도 붙여보는 게 다음 할 일인 듯.

[dnnals]

기본 질문

1. CI/CD 파이프라인은 왜 필요하며, 안정적인 서비스 배포를 위해 어떤 단계로 구성해야 하나요?

CI/CD는 개발자가 작성한 코드를 자동으로 검사하고, 빌드하여, 사용자에게 제공하는 서버에 올리는 소프트웨어 배포 자동화 프로세스입니다. 필요한 이유는 버그 조기 발견, 배포 리스크 감소, 생산성 향상이 있습니다. 코드 수정을 저장소에 올릴 때마다 자동으로 테스트가 실행되어 수동 검사가 놓치기 쉬운 오류를 바로 찾아냅니다. 또 한 번에 많은 변경을 배포하는 대신 작고 빈번한 단위로 배포하여 문제가 생겨도 영향 범위를 최소화합니다. 서버 접속, 빌드, 파일 전송, 서버 재시작 등 반복적인 수동 배포 작업 시간을 대폭 단축합니다. 이렇게 안정적인 서비스 배포를 위해 개발 단계, CI 단계, CD 단계로 나누고 좀 더 세분화해서 보면 먼저 작업 브랜치를 생성하고 코드를 작성하고 커밋 앤 푸시합니다. 이후 작업이 완성되면 PR을 생성하고 PR이 생성되면 자동으로 CI가 실행됩니다. 그러면 코드를 리뷰하고 머지합니다. 최종적으로 배포 브랜치에 머지가 된다면 CD 파이프라인이 실행되어 테스트 서버나 운영 서버에 자동으로 배포됩니다.

2. CI와 CD는 각각 무엇을 의미하며, 자동화된 테스트와 빌드는 배포 과정의 어떤 문제를 해결하나요?

CI(Continuous Integration)는 지속적 통합을 의미하는 말로 여러 개발자가 작업한 코드를 자주, 자동으로 합치고 테스트하는 과정입니다. 이는 코드가 병합될때마다 자동으로 오류가 있는지 없는지 검증합니다. CD(Continuous Delivery/Deployment)는 지속적 제공/배포를 의미하는 말로 CI를 거친 검증된 코드를 실제 운영 서버에 자동으로 전달하고 배포하는 과정입니다. 자동화된 테스트와 빌드는 배포 과정에서 사람의 실수, 예측 불가능성, 시간 지연 등의 문제를 해결합니다. 자동화된 테스트와 빌드는 이미 환경에 맞게 전부 설정된 상태이기 때문에 사람이 직접 빌드 명령어를 치고, 파일 압축을 풀고, 서버에 옮기다 특정 파일을 누락하거나 잘못된 환경 변수를 적용하는 등의 휴먼 에러를 없애주고, 수동 테스트와 빌드는 휴먼 에러 없이 원활히 하려면 오래 걸리게 되고 휴먼 에러의 걱정과 호흡이 긴 과정으로 인해 배포 과정에 대한 거부감까지 해결해줍니다.

3. 배포 중 장애가 발생했을 때 롤백은 어떻게 설계해야 하며, Git 브랜치 전략은 CI/CD 파이프라인에 어떤 영향을 주나요?

배포 중 장애 발생 시의 롤백의 핵심원칙은 ‘문제가 생긴 코드만 수정해서 새로 배포한다’가 아닌 ‘가장 최근에 정상 동작했던 버전으로 즉시 원복한다’입니다. 또 롤백 전략은 어떤 방식으로 배포했느냐에 따라 달라집니다. 서버를 한 대씩 순차적으로 새 버전으로 교체하며 배포하는 방식의 롤링 배포는 장애 발생 시 순차적으로 새 버전으로 교체하던 것을 즉시 중단하고 이때까지 교체되었던 모든 서버를 다시 이전 버전으로 되돌리는 대응을 하고, 신 버전, 구 버전을 동시에 띄워두고 라우터, 로드밸런서의 트래픽 스위치만 변경해서 배포하는 방식의 블루-그린 배포는 장애 발생 시 트래픽을 다시 구버전으로 되돌려서 대응합니다. 그리고 전체 트래픽의 5~10%에게만 신버전을 보내 점진적으로 검증하며 배포하는 방식의 카나리 배포는 소수 유저에게 할당된 트래픽의 모니터링 지표가 악화되면 신버전으로 가던 트래픽을 차단하고 다시 구버전으로 되돌리며 대응합니다. Git 브랜치 전략은 실제 CI/CD 파이프라인의 전체 구조, 배포 주기, 자동화 수준을 결정하는 설계도 역할을 합니다. 가장 전통적인 브랜치 전략 Git-flow로 설명해보면 Git-flow 브랜치 전략은 release, main, develop, feature 등 역할별로 브랜치를 나누고 develop 브랜치로 PR을 생성해서 CI 파이프라인을 따르고 release 브랜치로 머지하며 검증 서버로 CI/CD 파이프라인을 따르고 main으로 머지하며 실제 운영 서버로의 CI/CD 파이프라인을 따릅니다.