# [[Continuous Integration & Continuous Deployment (CI/CD)]]

## 📌 Brief Summary
지속적 통합 및 지속적 배포(CI/CD)는 소프트웨어 코드에 변경 사항이 발생할 때마다 빌드 파이프라인을 통해 자동으로 소프트웨어를 테스트하고 배포하는 개발 관행입니다 [1]. 다수의 개발자가 동일한 코드베이스에 변경 사항을 지속적으로 푸시할 때, 자동화된 테스트를 실행하여 코드의 안정성을 검증하고 개발자에게 빠른 피드백을 제공하는 핵심 인프라 역할을 합니다 [2, 3]. 리팩토링이나 새로운 기능 개발 시 코드가 망가지지 않았는지 보장하기 위해서는 자동화된 테스트가 CI/CD 파이프라인에 완벽하게 통합되어야 합니다 [1, 4].

## 📖 Core Content
*   **CI 파이프라인의 필수 요건**: 단일 자동화 테스트를 작성하기 전에, 기능적이고 신뢰할 수 있는 CI 파이프라인이 먼저 구축되어야 합니다 [3]. 이는 모든 커밋에서 트리거되는 자동화된 빌드, 일관된 빌드 환경, 그리고 코드 변경으로 인한 오류 발생 여부를 수 분 내에 개발자에게 알려주는 명확한 피드백 루프를 포함합니다 [3].
*   **테스트 속도와 파이프라인 단계 구성**: CI/CD 배포 파이프라인의 가장 기본적인 가치는 '빠른 피드백(Fast Feedback)'에 있습니다 [1]. 따라서 실행 시간이 짧고 범위가 좁은 단위 테스트 및 통합 테스트는 파이프라인의 초기 단계에 배치하여 10~15분 내에 신속한 피드백을 받아야 하며, 실행 시간이 긴 테스트는 후반 단계에 배치하여 빠른 피드백의 지연을 막아야 합니다 [5, 6].
*   **대규모 환경(SAFe)에서의 CI/CD 적용**: 규모가 큰 엔터프라이즈 환경에서 지속적 배포 파이프라인은 전체 애자일 릴리스 트레인(ART)에 걸쳐 확장됩니다 [7]. 개별 팀들은 자체적인 CI 프로세스를 유지하며, 통합을 담당하는 시스템 팀은 '코드형 인프라(Infrastructure as Code)'를 통해 수동 구성이 아닌 일관성 있고 반복 가능한 테스트 환경을 프로비저닝합니다 [7].
*   **리팩토링과의 유기적 통합**: 리팩토링 과정에서 작은 구조적 변경을 수행한 직후에는 항상 CI 환경에서 테스트를 실행하여 버그 유입 위험을 차단해야 합니다 [4]. 마틴 파울러가 제시한 리팩토링 방법론 역시 현대의 DevOps 및 CI/CD 파이프라인에 널리 채택되어 안전한 시스템 구조 개선에 기여하고 있습니다 [8].

## ⚖️ Trade-offs & Caveats
*   **테스트 비대화 및 피드백 지연**: CI 파이프라인 내에서 무겁고 실행 속도가 느린 엔드투엔드(End-to-End) 테스트나 UI 테스트에 과도하게 의존(역 테스트 피라미드 안티 패턴)하게 되면, 빌드 빈도가 급락하고 파이프라인 실행에 수 시간이 소요되는 부작용이 발생합니다 [9]. 커버리지(Coverage) 지표에만 집착하여 실행 속도를 희생하는 것은 잘못된 최적화이며, 적용 범위와 속도, 신뢰성 간의 시스템적 균형을 맞춰야 합니다 [10].
*   **테스트 환경 공유로 인한 거짓 실패(False Failures)**: 여러 팀이 동일한 CI 테스트 환경을 동시에 공유하여 테스트를 실행할 경우, 연쇄적인 실패가 발생하여 정확히 어떤 코드 변경이 문제를 일으켰는지 판별하기 불가능해지는 치명적인 제약이 따를 수 있습니다 [11].
*   **불완전한 인프라로 인한 투자 낭비**: 안정적인 CI 파이프라인 인프라가 사전에 마련되지 않는다면, 개발 팀이 아무리 훌륭한 자동화 테스트를 작성하더라도 이를 실행할 공간과 피드백을 전달할 메커니즘이 존재하지 않아 테스트의 가치가 상실되는 문제가 발생합니다 [3].

---
*Last updated: 2026-05-03*