Vue.js 주니어 배포·운영 기술면접

dist 폴더에는 HTML 진입점, 번들링된 JavaScript 파일, CSS 파일, 정적 자산이 생성됩니다. 빌드 과정에서는 첫째, 코드 압축(Minification)을 통해 불필요한 공백과 주석을 제거하여 파일 크기를 줄입니다. 둘째, Tree Shaking을 통해 사용하지 않는 코드를 제거합니다. 셋째, 코드 스플리팅을 통해 번들을 여러 청크로 나누어 초기 로딩 속도를 개선합니다. 넷째, 환경 변수를 프로덕션 모드로 설정하여 개발용 경고 메시지와 디버깅 코드를 제거합니다.

Vue CLI 프로젝트에서는 .env.development, .env.staging, .env.production 파일을 각각 생성하여 환경별 설정을 관리합니다. 환경 변수명은 반드시 VUE_APP_ 접두사로 시작해야 하며, 예를 들어 VUE_APP_API_URL=https://api.example.com 형식으로 작성합니다. 코드에서는 process.env.VUE_APP_API_URL로 참조할 수 있습니다. npm run serve는 .env.development를, npm run build는 .env.production을 자동으로 로드합니다. 민감한 정보는 .env 파일에 저장하되 .gitignore에 추가하여 버전 관리에서 제외해야 합니다.

SPA는 클라이언트 사이드 라우팅을 사용하기 때문에 /about 같은 경로는 실제 서버에 존재하지 않습니다. 사용자가 직접 URL을 입력하거나 새로고침하면 서버가 해당 경로의 파일을 찾으려 하고, 존재하지 않아 404 에러를 반환합니다. 이를 해결하려면 Nginx 설정에서 try_files $uri $uri/ /index.html; 구문을 추가하여 모든 요청을 index.html로 폴백하도록 설정해야 합니다. 이렇게 하면 Vue Router가 클라이언트에서 적절한 컴포넌트를 렌더링할 수 있습니다.

CI/CD 파이프라인은 다음 단계로 구성됩니다. 첫째, 코드 체크아웃 단계에서 actions/checkout을 사용해 저장소 코드를 가져옵니다. 둘째, Node.js 환경을 설정하고 npm install로 의존성을 설치합니다. 셋째, npm run lint로 코드 품질을 검사하고 npm run test로 유닛 테스트를 실행합니다. 넷째, 테스트 통과 시 npm run build로 프로덕션 빌드를 생성합니다. 다섯째, 빌드된 dist 폴더를 S3, Netlify, Vercel 등의 호스팅 서비스에 배포합니다. 각 단계가 실패하면 파이프라인이 중단되어 문제가 있는 코드가 배포되는 것을 방지합니다.

멀티 스테이지 빌드는 Dockerfile을 여러 단계로 나누어 최종 이미지 크기를 최적화하는 기법입니다. 첫 번째 스테이지에서는 Node.js 이미지를 사용해 의존성을 설치하고 npm run build를 실행하여 프로덕션 빌드를 생성합니다. 두 번째 스테이지에서는 경량 Nginx 이미지를 사용하고, 첫 번째 스테이지에서 생성된 dist 폴더만 복사하여 정적 파일을 서빙합니다. 이렇게 하면 Node.js와 개발 의존성이 최종 이미지에 포함되지 않아 이미지 크기가 수백 MB에서 수십 MB로 줄어듭니다. 작은 이미지는 배포 속도가 빠르고 보안 취약점도 적습니다.

블루-그린 배포는 두 개의 동일한 프로덕션 환경(블루와 그린)을 준비하는 전략입니다. 현재 블루 환경에서 서비스가 운영 중일 때, 새 버전을 그린 환경에 배포하고 테스트합니다. 테스트가 완료되면 로드 밸런서나 라우터 설정을 변경하여 트래픽을 그린으로 전환합니다. 장점은 무중단 배포가 가능하고, 문제 발생 시 즉시 블루로 트래픽을 되돌려 빠른 롤백이 가능하다는 점입니다. 단점은 두 배의 인프라 리소스가 필요하고 데이터베이스 스키마 변경 시 양쪽 호환성을 고려해야 한다는 점입니다.

Vue CLI는 빌드 시 JavaScript와 CSS 파일명에 콘텐츠 기반 해시값을 자동으로 추가합니다(예: app.a1b2c3d4.js). 파일 내용이 변경되면 해시값도 변경되어 새로운 파일명이 생성됩니다. 이러한 정적 자산에는 Cache-Control: max-age=31536000 같은 긴 캐시 기간을 설정하여 브라우저가 파일을 오래 캐싱하도록 합니다. 반면 index.html은 Cache-Control: no-cache로 설정하여 항상 최신 버전을 확인하도록 합니다. 새 배포 시 index.html이 새로운 해시값을 가진 파일을 참조하므로 자동으로 캐시가 무효화됩니다. 이 방식으로 캐싱의 성능 이점과 즉각적인 업데이트를 모두 달성할 수 있습니다.

Vue 3에서는 app.config.errorHandler를 사용하여 전역 에러 핸들러를 설정할 수 있습니다. 이 핸들러는 컴포넌트 렌더링, 이벤트 핸들러, 라이프사이클 훅 등에서 발생하는 모든 에러를 캡처합니다. Sentry를 초기화할 때는 Vue 통합 플러그인을 사용하며, 에러 발생 시 스택 트레이스, 사용자 정보, 브라우저 정보, 에러 발생 컴포넌트, 현재 라우트, Vuex 상태 등을 함께 전송합니다. 또한 소스맵을 업로드하여 압축된 프로덕션 코드의 에러를 원본 소스 위치로 추적할 수 있도록 설정해야 합니다. 에러 발생 빈도와 영향받는 사용자 수를 모니터링하여 우선순위를 정할 수 있습니다.

Core Web Vitals는 세 가지 주요 지표로 구성됩니다. 첫째, LCP(Largest Contentful Paint)는 가장 큰 콘텐츠 요소가 렌더링되는 시간으로, 2.5초 이하가 목표입니다. 이미지 최적화, 코드 스플리팅, CDN 사용으로 개선할 수 있습니다. 둘째, FID(First Input Delay)는 사용자 첫 상호작용에 대한 응답 시간으로, 100ms 이하가 목표입니다. 메인 스레드를 블로킹하는 긴 작업을 분리하고 Web Worker를 활용하여 개선합니다. 셋째, CLS(Cumulative Layout Shift)는 예상치 못한 레이아웃 이동을 측정하며, 0.1 이하가 목표입니다. 이미지와 광고 영역에 명시적 크기를 지정하여 개선할 수 있습니다. 이러한 지표는 Google Analytics나 Lighthouse를 통해 측정할 수 있습니다.

롤백 절차는 다음과 같습니다. 첫째, Git에서 git revert 또는 git reset을 사용해 이전 커밋으로 돌아갑니다. revert는 새로운 커밋을 생성하여 히스토리를 보존하므로 협업 환경에서 안전합니다. 둘째, CI/CD 파이프라인을 통해 이전 버전을 재배포하거나, 블루-그린 배포 환경이라면 트래픽을 이전 환경으로 즉시 전환합니다. 셋째, 배포 후 주요 기능이 정상 작동하는지 smoke test를 수행하고, 에러 모니터링 도구로 새로운 에러가 발생하지 않는지 확인합니다. 롤백이 어려운 경우는 데이터베이스 스키마가 변경되었거나, 새 버전에서 생성된 데이터가 이전 버전과 호환되지 않을 때입니다. 이런 경우를 대비해 데이터베이스 마이그레이션은 항상 하위 호환성을 유지하도록 설계해야 합니다.