PHP 시니어 배포·운영 기술면접

Build 단계에서는 Composer 의존성 설치, 환경별 .env 파일 생성, 프론트엔드 에셋 빌드를 수행하고 Docker 멀티 스테이지 빌드로 개발 의존성을 제외한 경량 이미지를 생성합니다. Test 단계에서는 PHPUnit 단위 테스트, PHPStan 정적 분석, PHP-CS-Fixer 코드 스타일 검사를 병렬로 실행하고 코드 커버리지를 측정합니다. Deploy 단계에서는 Blue-Green 배포를 위해 새 컨테이너를 Green 환경에 배포한 후 헬스체크 엔드포인트로 Smoke Test를 실행하고, 성공 시 로드밸런서 트래픽을 전환합니다. Docker 멀티 스테이지 빌드에서는 첫 번째 스테이지에서 Composer install --no-dev로 프로덕션 의존성만 설치하고, 두 번째 스테이지에서 필요한 파일만 복사하여 이미지 크기를 최소화합니다. Smoke Test는 critical path API 엔드포인트 호출, 데이터베이스 연결 확인, 캐시 서버 응답 검증을 포함하며, 실패 시 자동으로 이전 버전으로 롤백됩니다.

Deployment에서는 replicas를 최소 3개로 설정하고 RollingUpdate 전략으로 maxSurge 1, maxUnavailable 0을 지정하여 항상 최소 replica 수를 유지합니다. Service는 ClusterIP 타입으로 Pod selector를 통해 트래픽을 분산하고, Ingress에서 TLS 종료와 도메인 라우팅을 처리합니다. ConfigMap에는 php.ini, php-fpm.conf 설정을 저장하고, Secret에는 데이터베이스 자격증명과 API 키를 암호화하여 저장한 후 환경변수로 주입합니다. HPA는 CPU 사용률 70%, 메모리 사용률 80%를 임계값으로 설정하고 minReplicas 3, maxReplicas 10으로 지정하여 트래픽에 따라 자동 확장합니다. readinessProbe는 HTTP GET /health로 애플리케이션이 트래픽을 받을 준비가 되었는지 확인하며 initialDelaySeconds 10, periodSeconds 5로 설정하고, livenessProbe는 애플리케이션 응답 불능 상태를 감지하여 Pod를 재시작하며 initialDelaySeconds 30, periodSeconds 10으로 설정합니다. Rolling Update 시 새 Pod의 readinessProbe가 성공해야만 Service 엔드포인트에 추가되고 이전 Pod가 제거되어 무중단 배포가 보장됩니다.

컬럼 추가 시에는 1단계에서 NULL 허용 컬럼을 추가하고, 2단계에서 신규 컬럼을 사용하는 애플리케이션 코드를 배포하며, 3단계에서 기존 데이터를 마이그레이션한 후 4단계에서 NOT NULL 제약조건을 추가합니다. 컬럼 삭제 시에는 1단계에서 애플리케이션 코드에서 해당 컬럼 사용을 제거하고, 2단계에서 충분한 시간이 지난 후 실제 컬럼을 DROP하여 구버전 코드가 모두 종료된 것을 보장합니다. 컬럼 타입 변경 시에는 1단계에서 새 타입의 임시 컬럼을 추가하고, 2단계에서 양쪽 컬럼을 모두 읽고 쓰는 Dual Write 로직을 배포하며, 3단계에서 기존 데이터를 마이그레이션하고, 4단계에서 기존 컬럼 읽기를 중단한 후, 5단계에서 기존 컬럼을 삭제하고 새 컬럼 이름을 변경합니다. 각 단계 사이에는 모든 인스턴스가 새 코드로 교체될 충분한 시간을 두고, 롤백 가능성을 고려하여 데이터 손실이 없도록 설계합니다. Feature Flag를 활용하면 코드는 배포하되 기능은 점진적으로 활성화할 수 있어 더 안전합니다.

APM에서는 응답 시간(p50, p95, p99), 처리량(throughput), 에러율, 데이터베이스 쿼리 성능, 외부 API 호출 시간을 추적하고 트랜잭션별 분산 추적(distributed tracing)으로 병목 지점을 식별합니다. Infrastructure Monitoring에서는 Prometheus와 Grafana로 CPU, 메모리, 디스크 I/O, 네트워크 트래픽을 수집하고 PHP-FPM 프로세스 수, OPcache 히트율을 모니터링합니다. Log Aggregation은 ELK Stack이나 Loki로 애플리케이션 로그, 웹 서버 액세스 로그, 에러 로그를 중앙 집중화하고 구조화된 로그 형식(JSON)으로 검색과 분석을 용이하게 합니다. 알림 임계값은 p95 응답 시간 1초 초과, 에러율 1% 초과, CPU 사용률 80% 지속 5분 등으로 설정하고 PagerDuty나 Slack으로 즉시 통보합니다. 대시보드는 비즈니스 메트릭(주문 수, 결제 성공률)을 상단에 배치하고 애플리케이션 메트릭, 인프라 메트릭 순으로 구성하여 장애 영향도를 먼저 파악한 후 원인을 드릴다운할 수 있게 합니다. 각 계층의 메트릭을 correlation ID로 연결하여 특정 요청의 전체 흐름을 추적할 수 있어 MTTD와 MTTR을 크게 단축할 수 있습니다.

애플리케이션 코드 롤백은 Kubernetes에서 kubectl rollout undo 명령이나 이전 Docker 이미지 태그로 즉시 전환할 수 있지만, 데이터베이스 마이그레이션은 신중하게 처리해야 합니다. Forward-only Migration 전략에서는 마이그레이션을 절대 롤백하지 않고 새로운 마이그레이션으로 문제를 수정하며, 이는 데이터 손실 위험이 없고 여러 환경에서 일관성을 유지할 수 있지만 즉시 롤백이 불가능합니다. Rollback Migration 전략은 down() 메서드로 스키마 변경을 되돌릴 수 있지만 데이터 손실 가능성과 복잡한 마이그레이션에서 완벽한 롤백이 어렵다는 단점이 있습니다. 실무에서는 Feature Flag로 새 기능을 코드에는 배포하되 비활성화 상태로 유지하고, 문제 발생 시 Kill Switch로 즉시 기능을 끌 수 있어 코드 롤백 없이 대응할 수 있습니다. Database Migration Versioning은 마이그레이션 파일에 타임스탬프를 포함하고 migrations 테이블로 실행 이력을 추적하며, 각 마이그레이션이 멱등성을 보장하도록 설계합니다. 데이터 변경이 포함된 경우 별도의 데이터 마이그레이션 스크립트를 작성하고 dry-run 모드로 충분히 테스트한 후 단계적으로 실행하며, 백업을 선행하여 최악의 경우 Point-in-Time Recovery로 복구합니다.