React 주니어 배포·운영 기술면접
새 면접Q. React 애플리케이션을 배포할 때 CI/CD가 무엇인지 설명하고, CI(Continuous Integration)와 CD(Continuous Deployment/Delivery)의 차이점을 말씀해주세요. 또한 이를 통해 얻을 수 있는 이점을 설명해주세요.
CI는 코드 통합과 테스트 자동화에, CD는 배포 자동화에 초점을 맞춰 생각해보세요.
CI는 개발자들이 작성한 코드를 주기적으로 통합하고 자동으로 빌드 및 테스트를 수행하는 프로세스입니다. CD는 테스트를 통과한 코드를 자동으로 프로덕션 환경에 배포하는 프로세스를 의미합니다. CI/CD를 도입하면 수동 배포로 인한 휴먼 에러를 방지하고, 배포 시간을 단축하며, 빠른 피드백을 통해 버그를 조기에 발견할 수 있습니다. React 프로젝트에서는 GitHub Actions, Jenkins, GitLab CI 등의 도구를 활용하여 코드 푸시 시 자동으로 빌드, 테스트, 배포가 이루어지도록 구성할 수 있습니다.
- • CI는 코드 통합과 자동 테스트
- • CD는 자동 배포 프로세스
- • 휴먼 에러 방지 및 배포 시간 단축
- • GitHub Actions, Jenkins 등의 도구 활용
코드를 main 브랜치에 머지하면 자동으로 빌드, 테스트, 배포가 진행되어 수동 작업 없이 프로덕션에 반영됩니다.
실제로 GitHub Actions를 사용하여 React 프로젝트의 CI/CD 파이프라인을 구성해본 경험이 있나요? 어떤 단계들로 구성했는지 설명해주세요.
Q. React 애플리케이션을 프로덕션 환경에 배포하기 전에 npm run build 명령어를 실행합니다. 이 과정에서 어떤 최적화 작업들이 수행되는지 설명하고, 개발 모드와 프로덕션 빌드의 주요 차이점을 말씀해주세요.
번들링, 압축, 난독화 등 프로덕션 최적화 과정을 생각해보세요.
npm run build는 React 애플리케이션을 프로덕션 환경에 최적화된 형태로 빌드합니다. 이 과정에서 여러 JavaScript 파일을 하나 또는 여러 개의 번들로 합치고, 코드 압축(minification)과 난독화(uglification)를 수행하여 파일 크기를 줄입니다. 또한 사용하지 않는 코드를 제거하는 Tree Shaking, 환경 변수 설정, 소스맵 생성 등이 이루어집니다. 개발 모드는 디버깅을 위한 경고 메시지와 상세한 에러 정보를 포함하지만, 프로덕션 빌드는 이러한 개발용 코드를 제거하고 성능에 최적화된 코드만 포함합니다. 프로덕션 빌드는 일반적으로 개발 모드보다 파일 크기가 훨씬 작고 실행 속도가 빠릅니다.
- • 번들링, 압축, 난독화를 통한 최적화
- • Tree Shaking으로 미사용 코드 제거
- • 개발용 경고 메시지 제거
- • 파일 크기 감소 및 성능 향상
프로덕션 배포 시 빌드 최적화를 통해 번들 크기를 줄여 사용자의 페이지 로딩 속도를 개선합니다.
빌드 결과물의 크기가 너무 커서 초기 로딩 시간이 길어지는 문제가 발생했을 때 어떤 최적화 방법을 사용할 수 있나요?
Q. React 애플리케이션을 배포한 후 실시간으로 에러를 추적하고 모니터링하기 위해 Sentry와 같은 에러 추적 도구를 사용합니다. 이러한 도구를 사용하는 이유와, 프로덕션 환경에서 발생하는 에러를 효과적으로 관리하기 위해 어떤 정보들을 수집해야 하는지 설명해주세요.
사용자 환경에서 발생하는 에러를 개발자가 어떻게 파악하고 재현할 수 있을지 생각해보세요.
Sentry와 같은 에러 추적 도구는 프로덕션 환경에서 발생하는 에러를 실시간으로 수집하고 개발자에게 알림을 보내줍니다. 사용자의 브라우저에서 발생한 에러 스택 트레이스, 에러 발생 시점, 사용자의 브라우저 정보, OS, 에러가 발생한 URL 등을 자동으로 수집합니다. 또한 에러 발생 전 사용자의 행동 패턴(breadcrumbs)을 기록하여 에러 재현에 필요한 컨텍스트를 제공합니다. 이를 통해 개발 환경에서 발견하지 못한 버그를 빠르게 파악하고, 어떤 사용자 환경에서 문제가 발생하는지 분석하여 우선순위를 정할 수 있습니다. 소스맵을 함께 업로드하면 압축된 프로덕션 코드에서도 원본 코드의 정확한 위치를 파악할 수 있습니다.
- • 실시간 에러 수집 및 알림
- • 에러 스택 트레이스와 사용자 환경 정보 수집
- • 사용자 행동 패턴(breadcrumbs) 기록
- • 소스맵을 통한 원본 코드 위치 파악
사용자가 결제 페이지에서 에러를 겪었을 때 Sentry 알림을 통해 즉시 파악하고 빠르게 수정할 수 있습니다.
프로덕션 환경에서 특정 에러가 급증할 때 어떤 기준으로 우선순위를 정하고 대응하시겠습니까?
Q. React 애플리케이션을 운영 중인 서비스에 배포할 때 사용자가 서비스를 이용하는 도중 배포로 인해 페이지가 중단되거나 에러가 발생하지 않도록 하는 무중단 배포 전략을 설명해주세요. 특히 정적 파일을 서빙하는 React 앱의 특성을 고려하여 설명해주세요.
새 버전 배포 시 기존 버전과 새 버전이 공존하는 방식과, 캐시 문제를 함께 고려해보세요.
React 애플리케이션의 무중단 배포는 주로 Blue-Green 배포나 Rolling 배포 방식을 사용합니다. Blue-Green 배포는 기존 환경(Blue)과 새 환경(Green)을 동시에 운영하다가 새 버전 테스트 완료 후 트래픽을 한 번에 전환하는 방식입니다. CDN이나 로드밸런서를 사용하는 경우, 새 버전의 정적 파일을 다른 경로에 배포한 후 전환합니다. 특히 React 앱은 빌드 시 파일명에 해시값을 포함시켜 캐시 문제를 방지합니다. 또한 index.html은 캐시하지 않도록 설정하고, JS/CSS 번들 파일은 긴 캐시 시간을 설정하여 성능과 안정성을 모두 확보합니다. 배포 후 헬스체크를 통해 새 버전이 정상 동작하는지 확인한 후 트래픽을 전환하며, 문제 발생 시 즉시 이전 버전으로 롤백할 수 있도록 준비합니다.
- • Blue-Green 또는 Rolling 배포 방식
- • 파일명에 해시값 포함으로 캐시 문제 해결
- • index.html은 no-cache, 번들 파일은 장기 캐시
- • 헬스체크 후 트래픽 전환 및 롤백 준비
점심시간 트래픽이 많을 때도 무중단 배포를 통해 사용자에게 영향 없이 새 기능을 배포할 수 있습니다.
배포 후 새 버전에 치명적인 버그가 발견되었을 때 어떤 과정을 거쳐 이전 버전으로 롤백하시겠습니까?
Q. React 애플리케이션에서 개발, 스테이징, 프로덕션 환경마다 다른 API 엔드포인트나 설정값을 사용해야 할 때 환경 변수를 어떻게 관리하는지 설명해주세요. 특히 .env 파일의 역할과 보안상 주의해야 할 점을 포함하여 설명해주세요.
클라이언트 사이드에서 접근 가능한 환경 변수의 특성과 민감한 정보 관리를 생각해보세요.
React 애플리케이션에서는 .env 파일을 사용하여 환경별로 다른 설정값을 관리합니다. Create React App 기준으로 REACT_APP_ 접두사가 붙은 환경 변수만 빌드 시 번들에 포함됩니다. 개발 환경에는 .env.development, 프로덕션에는 .env.production 파일을 사용하여 각각 다른 API URL이나 설정을 지정합니다. 중요한 점은 React는 클라이언트 사이드 애플리케이션이므로 환경 변수가 빌드된 번들에 그대로 노출된다는 것입니다. 따라서 API 키, 비밀번호 같은 민감한 정보는 절대 .env 파일에 넣으면 안 되며, 백엔드 서버에서 관리해야 합니다. .env 파일은 .gitignore에 추가하여 Git에 커밋되지 않도록 하고, CI/CD 파이프라인에서 환경 변수를 주입하는 방식으로 관리합니다.
- • 환경별 .env 파일로 설정 분리
- • REACT_APP_ 접두사 필요
- • 민감한 정보는 클라이언트에 노출되므로 백엔드에서 관리
- • .env 파일은 Git에 커밋하지 않음
개발 환경에서는 로컬 API를, 프로덕션에서는 실제 서버 API를 환경 변수로 분리하여 관리합니다.
프로덕션 배포 시 환경 변수를 안전하게 주입하는 방법으로 어떤 것들이 있나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!