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 파이프라인을 따릅니다.

[paiwhy]

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

CI/CD 파이프라인은 코드 변경부터 테스트, 빌드, 배포까지의 과정을 자동화한 흐름입니다.

코드를 수정할 때마다 사람이 직접 테스트하고 배포하면 시간이 오래 걸리고 작업 과정에서 실수가 발생할 가능성도 높아집니다. CI/CD를 사용하면 반복적인 작업을 자동화하고 코드 변경사항을 빠르고 안정적으로 배포할 수 있습니다. 서비스 배포를 위한 단계로는

1. 코드 변경 및 저장소에 반영: 개발자가 코드를 작성하고 Git 저장소에 커밋하거나 PR을 생성합니다.
2. Lint: 코드의 문법이나 스타일 규칙 위반 등을 검사합니다.
3. Test: 코드가 의도한 대로 동작하는지 자동 테스트를 수행합니다.
4. Build: 소스 코드를 실행하거나 배포할 수 있는 형태로 변환합니다.
5. Deploy: 빌드된 결과물을 서버나 클라우드 환경에 배포합니다.
6. 모니터링: 배포 이후 서비스의 오류율이나 응답시간 등을 확인합니다.

핵심은 코드 변경사항을 빠르게 검증하고, 문제가 있는 코드가 운영 환경에 배포되는 것을 방지하는 것입니다.

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

• CI(지속적 통합): 작성한 코드를 공용 저장소에 자주 통합하고 통합할 때마다 자동으로 빌드와 테스트를 수행하는 방식입니다.
• CD(지속적 전달/배포): 검증된 코드를 배포 가능한 상태로 유지하거나 운영 환경까지 자동으로 배포하는 방식입니다.

CD는 문맥에 따라 지속적 전달과 지속적 배포로 의미가 나누어 집니다. 지속적 전달은 배포 준비까지 자동화하고 최종 배포는 사람이 승인할 수 있으며 지속적 배포는 검증을 통과한 변경사항을 운영 환경에 자동으로 배포합니다.
코드 변경으로 기존 기능이 깨지는 회귀 오류를 빠르게 발견하고, 요구사항대로 동작하는지 확인 함 으로써 자동화 테스트의 문제를 해결 할 수있습니다 또한 개발자마다 다른 환경에서 발생할 수 있는 빌드 문제를 줄이고 일관된 배포 결과물을 생성합니다
직접 수행하면서 발생할 수 있는 반복 작업의 실수와 배포 시간을 줄입니다.

CI는 코드 변경사항을 검증하는 것에 중점을 둘수있고 CD는 검증된 코드를 안정적으로 전달하거나 배포하는것에 중점을 둡니다.

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

배포 중 장애가 발생했을 때 빠르게 이전의 정상 버전으로 되돌릴 수 있도록 롤백 절차를 미리 설계해야 합니다.

배포된 버전과 이전의 정상 버전을 구분해 보관하고 배포 후 오류율이나 응답시간 등 주요 지표를 확인합니다 또한 오류율이 일정 수준을 넘거나 서비스가 정상적으로 동작하지 않을 경우 롤백하도록 기준을 정합니다. 장애가 발생하면 이전 버전으로 트래픽을 전환하거나 이전 빌드 결과물을 다시 배포합니다.
어플리케이션만 이전 버전으로 되돌려도 데이터베이스 구조가 맞지 않으면 문제가 발생할 수 있으므로 DB 변경은 이전 버전과도 호환되도록 단계적으로 적용해야 합니다.

Git 브랜치 전략은 코드가 언제 통합되고 어떤 조건에서 테스트와 배포가 실행되는지에 영향을 줍니다.

기능 개발, 개발 통합, 운영 배포를 위한 브랜치를 구분합니다. 단계별 관리가 명확하지만 브랜치가 많아지고 통합 과정이 복잡해질 수 있습니다. main 브랜치를 중심으로 기능 브랜치에서 작업한 뒤 PR을 통해 검토하고 병합합니다. 구조가 단순해 CI/CD를 구성하기 쉽고, 작은 변경사항을 자주 배포하는 방식에 적합합니다.
짧은 수명의 브랜치를 사용하고 변경사항을 자주 메인 브랜치에 통합합니다. 통합 충돌을 줄이고 지속적 통합에 유리하지만, 자동화된 테스트와 기능 플래그 등의 관리가 중요합니다.

브랜치 전략은 팀의 개발 방식과 배포 빈도에 맞게 선택해야 하고 브랜치에 코드가 반영되는 시점과 PR 승인 여부 등에 따라 CI/CD 파이프라인의 실행 조건을 구성하는 것이 중요합니다

[eunji719]

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

수동으로 코드를 빌드하고 서버에 올리면 사람이 실수하기 쉽고, 팀원마다 배포 방식이 달라, 문제가 생겼을 때 원인을 찾기 어렵다. CI/CD파이프라인은 이 과정을 코드로 정의하여 매번 똑같은 절차로, 자동으로 실행되게 만드는 장치이다. 그 결과 배포 속도가 빨라지고,실수가 줄고, 문제가 생겨도 어느 단계에서 뭐가 잘못됐는지 추적하기 쉬워진다.

안정적인 배포를 위한 파이프라인 단계는 아래 순서로 구성된다.

1. 코드 커밋/PR - 코드를 올리고 병합을 요청한다. 이 시점에 코드 스타일을 검사하는 과정인 Lint를 먼저 돌리기도 한다.
2. 빌드(CI) - 소스 코드를 컴파일하고 실행 가능한 패키지(컨테이너,바이너리)로 만드는 단계
3. 자동화 테스트(CI)- 단위 테스트, 통합 테스트를 자동으로 실행해서 새 코드가 기존 기능을 깨뜨리지 않았는지를 검증한다.
4. 스테이징 배포(CD)- 운영 환경과 거의 동일한 환경에 먼저 배포하여 실제 환경에서 문제가 없는지 확인한다.
5. 운영 배포(CD) - 검증이 끝난 코드를 실제 사용자에게 내보내고, 블루-그린 방식이나 카나리 방식처럼 한번에 전체 트래픽을 옮기지 않고, 점진적으로 전환하면 문제 발생 시 영향 범위를 최소화 가능하다.
6. 모니터링/알림- 배포 후 에러율, 응답 시간 같은 지표를 지속적으로 확인해서 이상 징후를 빠르게 감지한다.

이 단계들은 전 단계가 통과되지 못하면 다음 단계로 넘어가지 않는 구조이다.

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

CI는 지속적 통합으로 개발자들이 작성한 코드를 자주 하나의 저장소에 합치는 것을 말한다. 코드를 합칠 때 마다 자동으로 빌드하고 테스트를 돌려서, 합쳐진 코드가 정상적으로 동작하는가를 즉시 확인한다. CD는 지속적 전달/배포로 CI를 통과한 코드를 실제 서버에 자동으로 내보내는 것을 말한다. 전달은 언제든 배포할 수 있는 상태로 준비 까지, 배포는 사람 승인 없이 자동으로 운영 서버까지 반영 하는 것 까지 포함한다는 차이가 있다.

수동 배포에서 흔히 생기는 문제들을 자동화가 어떻게 막아줄까? 빌드 환경으로 코드로 고정하여 누가 실행해도 같은 결과가 나올 수 있도록 해준다. 또한 코드를 합칠 때마다 즉시 테스트 하므로 수동 배포와는 다르게 문제를 초기에 발견한다. 자동화된 배포는 정해진 스크립트대로만 실행되므로 사람이 단계를 빼먹을 일이 없고, 자동 테스트가 매번 전체 기능도 검증해준다.

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

배포 중 장애가 발생하면 분석하기보다 먼저 빠르게 안전한 상태로 되돌리는 것이 우선이다. 그러기 위해서는 이전 버전을 항상 보관해둬야 한다. 직전에 정상적으로 운영되던 빌드 산출물을 지우지 않고 남겨두면, 문제가 생겼을 때 새로 빌드할 필요 없이 즉시 그 버전으로 재배포할 수 있다. 또한 배포 방식 자체를 롤백하기 쉽게 설계한다거나, (블루 그린 배포/카나리 배포 —가영이 디스커션~~ ) 에러율이나 응답 지연 같은 지표가 미리 정한 임계치를 넘으면, 자동으로 이전 버전으로 롤백하도록 트리거를 구성해야 하고, 애플리케이션 코드는 롤백해도 DB스키마는 이미 바꼈을 수 있으니, 마이그레이션은 새 스키마에서도 이전 코드가 정상 동작하도록 하위 호환성을 갖추고 단계적으로 적용하는 것이 안전하다.

Git브랜치 전략이란, main/develop/feature/release/hotfix로 브랜치를 세분화하여 배포 주기가 길고 신중한 검증이 필요한 조직에 적합하다. 이 전략은 브랜치 별로 다른 트리거를 두는데, 예를 들어 develop브랜치는 스테이징 환경에 자동 배포, main브랜치는 운영 환경에 배포하는 식으로 분기 처리가 많아진다. hotfix브랜치를 위한 긴급 배포 경로를 별도로 만들어야 하는 경우도 많다. 이렇게 브랜치 전략이 복잡하면, 파이프라인도 브랜치마다 다른 배포 경로를 갖춰야해서 설정이 복잡해진다.