CI/CD (지속적 통합 / 지속적 배포)

지속적 통합은 모든 개발자가 장기간 분리된 브랜치에서 작업하는 대신 공유되는 메인 브랜치에 코드를 자주(이상적으로는 하루에 여러 번) 커밋하는 것을 의미합니다. 각 커밋은 코드를 컴파일하고, 전체 단위 및 통합 테스트 스위트를 실행하며, 정적 분석 및 린팅을 수행하고, 배포 가능한 아티팩트를 빌드하며, 몇 분 내에 성공 또는 실패를 보고하는 자동화된 파이프라인을 트리거합니다. CI의 중요한 문화적 규칙: 빌드 실패는 팀이 가장 우선적으로 해결해야 할 문제입니다. 실패한 메인 브랜치는 모든 사람을 막고 팀의 배포 준비 상태를 즉시 보고합니다. CI는 개발자들이 몇 주 동안 고립된 브랜치에서 작업한 다음 모든 변경 사항을 동시에 병합해야 할 때 발생하는 '통합 지옥'을 방지하여, 며칠이 걸리는 충돌과 버그를 줄입니다. Product Ops는 엔지니어가 자동화된 테스트로 변환할 수 있는 명확하고 테스트 가능한 기준을 제품 사양에 포함하도록 보장함으로써 CI를 지원합니다.

둘 다 CI 통과 후 릴리스 아티팩트의 자동화된 준비를 포함하지만, 마지막 단계에서 차이가 있습니다. 지속적 배포는 소프트웨어가 항상 배포 가능한 상태(모든 자동화된 검사를 통과하고, 패키징되어 배송 준비 완료)임을 의미하지만, 사람이 프로덕션에 배포할지 여부를 명시적으로 결정합니다. 배포는 비즈니스가 준비되었을 때 수행되는 원클릭 작업입니다. 지속적 배포는 한 단계 더 나아가 CI 파이프라인을 통과한 모든 커밋이 사람의 개입 없이 자동으로 프로덕션에 배포됩니다. 대부분의 SaaS 기업은 제어된 롤아웃을 위해 기능 플래그와 결합된 지속적 배포(사람이 트리거하는 배포)를 사용합니다. 지속적 배포는 매우 성숙한 테스트 인프라와 모니터링을 갖춘 팀에서 채택됩니다. Product Ops는 배포 결정 주기에 영향을 미치며, GTM 준비가 프로덕션 변경 사항과 함께 이루어지도록 배포 시기를 릴리스 캘린더와 조율합니다.

프로덕션 등급 CI/CD 파이프라인(GitHub Actions, CircleCI, GitLab CI 또는 Jenkins에서 구현)에는 다음과 같은 단계가 포함됩니다: 트리거(모든 pull request 및 메인 브랜치 병합 시); 빌드(소스 코드 컴파일, 종속성 해결, Docker 이미지 생성); 단위 테스트(개별 함수 및 구성 요소를 다루는 빠른 테스트, 목표 런타임 < 5분); 통합 테스트(구성 요소 간 상호 작용 테스트, 일부 외부 서비스 모의, 목표 < 15분); End-to-End 테스트(스테이징 환경에 대한 중요한 사용자 흐름을 테스트하는 브라우저 자동화 테스트, 목표 < 30분); 보안 스캔(취약한 종속성 및 코드 수준 보안 문제를 스캔하는 SAST 도구); 아티팩트 빌드 및 푸시(컨테이너 레지스트리에 프로덕션 준비 아티팩트 푸시); 스테이징 배포(인간 QA 검증을 위한 스테이징 환경으로 자동 배포); 및 프로덕션 배포(수동 트리거 또는 완전 자동화, 롤아웃 제어로서 기능 플래그 활성화). Product Ops는 엔지니어링 속도 지표로서 파이프라인 상태 지표(빌드 성공률, 파이프라인 기간 추세)를 모니터링합니다.