CI/CD의 Production — 개념, 개발 단계 및 환경

CI/CD에서 Production이란?

CI/CD 맥락에서 프로덕션은 애플리케이션 라이프사이클의 최종 단계로, 빌드 및 테스트의 모든 단계를 통과한 코드가 최종 사용자에게 제공됩니다. 개발 및 스테이징 환경과 달리 프로덕션 환경은 실제 데이터와 부하로 작동하므로 안정성과 성능에 특별한 요구사항이 적용됩니다.

프로덕션 환경의 역할

프로덕션 환경은 단순한 서버가 아니라 로드 밸런서, 데이터베이스, 캐싱 계층, CDN 및 모니터링 시스템을 포함하는 전체 인프라입니다. 각 구성 요소는 내결함성과 확장성을 갖추어야 합니다. 모바일 개발에서 프로덕션에는 클라이언트 애플리케이션을 지원하는 백엔드 서비스, API 게이트웨이 및 푸시 인프라도 포함됩니다.

프로덕션 환경 요구사항

프로덕션 환경은 엄격한 기준을 충족해야 합니다: 가용성 99.9% 이상, API 응답 시간 200ms 이내, 재해 복구 지원(SLA 내 RTO 및 RPO). 모바일 애플리케이션의 경우 충돌 보고, 사용 분석 및 실험을 위한 A/B 플랫폼이 추가로 필요합니다. CI/CD 파이프라인은 각 배포 전 자동 검사를 통해 이러한 요구사항 준수를 보장합니다.

프로덕션 배포 단계

프로덕션 배포는 CI/CD 파이프라인을 통해 자동화된 다단계 프로세스입니다. 각 단계에는 결함이 있는 코드가 프로덕션에 도달하는 것을 방지하는 검사가 포함됩니다. 일반적인 모바일 애플리케이션 파이프라인 예시를 사용하여 주요 단계를 살펴보겠습니다.

프로덕션용 CI/CD 파이프라인

파이프라인은 리포지토리의 메인 브랜치에 커밋으로 시작됩니다. 푸시 후 자동 빌드 및 단위 테스트가 시작되고, 이어서 통합 테스트 및 코드 품질 검사가 수행됩니다. 모든 단계가 성공적으로 완료되면 아티팩트가 빌드 레지스트리에 게시되고 최종 확인을 위해 스테이징에 배포됩니다. 스테이징에서 확인된 후에만 파이프라인이 프로덕션 배포로 진행됩니다.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

배포 자동화

프로덕션으로의 자동화된 배포는 제로 다운타임 배포 전략(롤링 업데이트, 블루-그린 배포, 카나리 릴리스)을 사용합니다. 롤링 업데이트에서는 새 애플리케이션 인스턴스가 서비스를 중단하지 않고 점차 이전 인스턴스를 대체합니다. 블루-그린 배포는 두 개의 동일한 환경을 유지하고 트래픽을 즉시 전환하여 문제 발생 시 빠른 롤백이 가능합니다. 전략 선택은 서비스의 중요도와 허용 가능한 다운타임에 따라 달라집니다. 모바일 애플리케이션의 경우 프로덕션 배포에는 단계적 출시와 함께 앱 스토어(App Store Connect, Google Play Console)에 게시하는 것이 포함되며, 바이너리 업로드, 메타데이터 입력 및 검토 제출을 포함한 게시 프로세스를 자동화하기 위해 스토어 API와의 추가 CI/CD 통합이 필요합니다.

배포 후 검사

프로덕션에 성공적으로 배포된 후 CI/CD 파이프라인은 일련의 스모크 테스트를 시작하여 기본 서비스 기능(엔드포인트 가용성, API 응답 정확성, 정상 범위 내 응답 시간)을 확인합니다. 모바일 애플리케이션의 경우 인증 기능, 데이터 동기화 및 결제 통합의 올바른 작동이 추가로 확인됩니다. 스모크 테스트가 실패하면 파이프라인이 자동으로 이전 안정 버전으로 롤백을 시작하고 팀에 알림을 보냅니다. 배포 후 모니터링은 30-60분 동안 증가된 알림 수준으로 계속됩니다 — 이는 자동 테스트로 커버되지 않는 문제를 감지하기 위한 기간입니다.

프로덕션과 테스트 환경의 차이점

프로덕션과 덜 엄격한 환경의 주요 차이점은 실제 사용자 데이터와 부하를 처리한다는 점입니다. 스테이징 환경은 출시 전 최종 테스트를 위해 설계되었지만 합성 또는 익명화된 데이터를 사용합니다. 반면 프로덕션은 라이브 트랜잭션, 개인 데이터 및 매우 중요한 작업을 처리하므로 관리에 근본적으로 다른 접근 방식이 필요합니다.

구성 및 인프라

프로덕션 환경 구성은 다른 환경에서 엄격하게 격리되어야 합니다. 이는 환경 변수, 데이터베이스 연결 문자열, API 키 및 인증서에 적용됩니다. 프로덕션 인프라는 일반적으로 내결함성을 보장하기 위해 여러 가용 영역에 복제됩니다. 모바일 애플리케이션의 경우 프로덕션에는 테스트 빌드에는 없는 Apple App Store 및 Google Play 구성도 포함됩니다.

데이터 관리

프로덕션에서는 테스트에 실제 데이터를 사용하는 것이 엄격히 금지됩니다 — 이를 위해 스테이징 및 개발 환경이 있습니다. 데이터베이스 구조의 모든 변경은 CI/CD 파이프라인이 자동으로 적용하는 마이그레이션을 통과해야 합니다. 프로덕션 데이터 백업은 자동 무결성 검증과 함께 일정에 따라 수행됩니다. 보존 정책은 GDPR 요구사항 및 기타 규정에 따라 백업의 저장 기간을 결정합니다.

프로덕션 인프라 모니터링

프로덕션 모니터링은 메트릭, 로그 및 트레이스를 수집하고 분석하는 지속적인 프로세스입니다. 포괄적인 모니터링 없이는 SLA를 보장하고 사고를 적시에 감지하는 것이 불가능합니다. 최신 모니터링 접근 방식은 메트릭(수치 지표), 로그(구조화된 이벤트 기록) 및 트레이스(요청 추적)의 세 가지 기둥에 기반합니다.

주요 메트릭

프로덕션 환경의 주요 메트릭에는 가동 시간(서비스 가용성), 지연 시간(응답 지연), 오류율(오류 비율), 처리량(대역폭) 및 포화도(리소스 부하 수준)가 포함됩니다. 모바일 애플리케이션의 경우 시작 시간 메트릭, 충돌 없는 비율 및 데이터 동기화 시간이 중요합니다. 알림은 SLO(서비스 수준 목표)에 기반하여 구성되므로 SLA 위반 전에 팀이 알림을 받을 수 있습니다.

모니터링 도구

프로덕션 인프라 모니터링을 위해 특수 플랫폼이 사용됩니다: 메트릭 수집을 위한 Datadog, New Relic, Grafana + Prometheus, 모바일 애플리케이션 오류 추적을 위한 Sentry 및 Crashlytics. 로그는 ELK 스택(Elasticsearch, Logstash, Kibana) 또는 Splunk를 통해 중앙 집중화됩니다. 요청 추적은 Jaeger 또는 Zipkin을 사용하여 구현됩니다. 모든 도구는 새 서비스 배포 시 자동 대시보드 생성을 위해 CI/CD 파이프라인과 통합됩니다. 인시던트 대응 시스템(PagerDuty, Opsgenie)은 모든 모니터링 도구에서 알림을 수신하고 로테이션 및 에스컬레이션 규칙에 따라 온콜 담당자를 자동으로 지정합니다. 각 인시던트 유형에 대한 런북은 리포지토리에 저장되고 코드와 함께 버전 관리되어 복구 지침의 최신성을 보장합니다.

프로덕션 환경 보안

프로덕션 환경 보안은 인프라, 데이터, 액세스 및 배포 프로세스를 포괄하는 다계층 보호 시스템입니다. 각 계층은 하나의 계층이 손상되어도 전체 시스템이 손상되지 않도록 구성되어야 합니다. CI/CD 파이프라인은 각 파이프라인 단계에서 자동 검사, 취약점 스캔 및 규정 준수 관리를 통해 보안을 보장하는 데 중요한 역할을 합니다.

액세스 및 역할

프로덕션 환경에 대한 액세스는 최소 권한 원칙에 따라 엄격하게 제한됩니다. 개발자는 프로덕션 서버에 직접 액세스할 수 없습니다 — 모든 변경 사항은 승인 메커니즘을 갖춘 CI/CD 파이프라인을 통과합니다. 긴급 액세스의 경우 자동 로테이션 및 전체 작업 로깅이 포함된 임시 자격 증명이 사용됩니다. 포 아이즈 원칙(모든 작업에는 두 사람의 승인이 필요)은 프로덕션 운영의 표준입니다.

변경 감사

프로덕션의 모든 변경은 감사 시스템에 기록됩니다: 누가 배포를 시작했는지, 어떤 커밋이 배포되었는지, 어떤 검사를 통과했는지, 배포에 얼마나 걸렸는지. CI/CD와 인시던트 관리 시스템(PagerDuty, Opsgenie)의 통합을 통해 배포 실패 또는 SLO 위반 시 자동으로 티켓을 생성할 수 있습니다. 모든 프로덕션 로그는 SOC2 및 ISO 27001 요구사항에 따라 최소 90일의 보존 기간을 가진 불변 리포지토리에 저장됩니다.