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 브랜치 전략, 배포 버전 관리, 모니터링, 그리고 신속한 롤백 시스템을 함께 구성하는 것이 중요하다.