React 리드·아키텍트 배포·운영 기술면접

먼저 각 마이크로프론트엔드를 독립적인 저장소와 파이프라인으로 분리하고, semantic versioning을 통해 명확한 버전 관리를 수행합니다. 호스트 애플리케이션은 리모트 모듈의 특정 버전 범위를 참조하도록 설정하며, 리모트 모듈이 먼저 배포된 후 호스트가 배포되는 순서를 유지합니다. 통합 테스트는 별도의 E2E 파이프라인에서 최신 버전 조합을 테스트하고, 호환성 매트릭스를 관리합니다. 롤백 시에는 호스트의 manifest 파일을 이전 버전으로 되돌려 리모트 모듈의 참조를 변경하며, 각 리모트 모듈은 최소 2개 이상의 이전 버전을 유지합니다. Canary 배포를 통해 일부 사용자에게만 새 버전을 노출하고, 메트릭 기반으로 자동 롤백을 수행하는 것이 안전합니다.

Multi-stage build를 활용하여 빌드 단계와 런타임 단계를 분리합니다. 첫 번째 스테이지에서는 node 이미지로 의존성 설치와 빌드를 수행하되, package.json과 package-lock.json을 먼저 복사하여 의존성 레이어를 캐싱합니다. 두 번째 스테이지에서는 nginx alpine 같은 경량 이미지를 사용하여 빌드된 정적 파일만 복사합니다. 보안을 위해 비root 사용자로 실행하고, Trivy나 Snyk를 CI 파이프라인에 통합하여 취약점 스캔을 자동화합니다. 정적 자산은 컨테이너에 포함시키지 않고 빌드 시 S3나 CDN에 직접 업로드하며, 컨테이너는 HTML 쉘과 라우팅만 담당하도록 분리합니다. 이를 통해 이미지 크기를 50MB 이하로 유지하고 배포 속도를 크게 개선할 수 있습니다.

먼저 webpack이나 vite의 output filename에 contenthash를 포함시켜 각 배포마다 고유한 chunk 파일명을 생성합니다. CDN이나 스토리지에 최소 2-3개 버전의 chunk 파일을 유지하는 정책을 설정하여, 이전 버전 사용자가 lazy loading 시 chunk를 찾을 수 있도록 합니다. ChunkLoadError를 전역으로 감지하여 새 버전이 배포되었음을 인지하고, 사용자에게 새로고침을 권유하는 UI를 표시합니다. Blue-Green 배포는 즉시 전환이 가능하지만 리소스가 2배 필요하고, Rolling 배포는 리소스 효율적이지만 두 버전이 공존하는 시간이 깁니다. 대규모 트래픽 서비스에서는 Canary 배포로 5-10-50-100% 식으로 점진적 전환하며, 에러율과 성능 메트릭을 실시간 모니터링하여 자동 롤백 조건을 설정합니다.

먼저 Sentry나 Datadog RUM을 통합하여 JavaScript 에러, 네트워크 실패, 그리고 unhandled rejection을 자동으로 수집하고, 소스맵을 업로드하여 minified 코드를 원본으로 추적합니다. Core Web Vitals(LCP, FID, CLS)를 PerformanceObserver API로 측정하고, 각 페이지별 P95 값이 기준치를 초과하면 알림을 발송합니다. LogRocket이나 FullStory로 에러 발생 시 사용자 세션을 재현할 수 있도록 설정하되, 민감 정보는 마스킹 처리합니다. 알림 임계값은 에러율 1% 초과, LCP 2.5초 초과, 또는 특정 critical path에서 연속 실패 시 즉시 온콜 엔지니어에게 전달되도록 설정합니다. 대시보드는 비즈니스 메트릭과 기술 메트릭을 함께 표시하여 영향도를 파악하고, 주간 리뷰에서 trend 분석을 통해 점진적 성능 저하를 조기에 발견합니다.

먼저 nginx나 CloudFront 같은 프록시 레이어에서 URL 패턴 기반으로 트래픽을 레거시와 신규 시스템으로 분기합니다. 초기에는 비critical한 페이지부터 신규 시스템으로 전환하고, LaunchDarkly나 자체 feature flag 시스템으로 사용자 세그먼트별로 점진적 노출을 제어합니다. 양쪽 시스템이 공유하는 API는 버전 관리를 통해 호환성을 유지하고, 신규 시스템에서 발생하는 에러율과 성능을 실시간 모니터링하여 임계값 초과 시 자동으로 레거시로 폴백합니다. 롤백은 프록시 설정 변경만으로 즉시 가능하도록 설계하며, 각 페이지의 전환 완료는 신규 시스템 트래픽 100% 유지 2주 동안 에러율 0.1% 이하 기준을 충족할 때 판단합니다. 전체 전환 완료 후 최소 1개월은 레거시 시스템을 standby 상태로 유지하여 예상치 못한 문제에 대비합니다.