Vue.js 리드·아키텍트 기술면접
새 면접Q. Vue 애플리케이션에서 XSS, CSRF, 클릭재킹 등 주요 웹 보안 위협에 대한 방어 전략을 설계해야 합니다. Vue의 템플릿 시스템에서 v-html 사용 시 위험성, CSP(Content Security Policy) 설정 전략, 인증 토큰의 저장 위치(localStorage vs httpOnly cookie), 그리고 서드파티 라이브러리 보안 감사를 어떻게 수행하시겠습니까?
각 공격 벡터별로 Vue 레벨과 인프라 레벨에서의 방어 계층을 나누어 생각해보세요.
v-html은 신뢰할 수 있는 소스에만 사용하고, 사용자 입력은 DOMPurify 같은 라이브러리로 sanitize합니다. CSP는 script-src, style-src를 제한하되 Vite의 nonce 기반 인라인 스크립트를 허용하도록 설정합니다. 인증 토큰은 httpOnly, Secure, SameSite 속성을 가진 쿠키에 저장하여 XSS로부터 보호하고, CSRF 토큰은 별도로 관리합니다. 서드파티 라이브러리는 npm audit, Snyk, Dependabot으로 지속적으로 취약점을 모니터링하고, SRI(Subresource Integrity)를 CDN 리소스에 적용합니다. 프레임 임베딩 방지를 위해 X-Frame-Options 헤더를 설정하고, Vue Router의 navigation guard에서 권한 검증 로직을 구현합니다.
- • v-html 사용 최소화 및 DOMPurify 적용
- • httpOnly 쿠키를 통한 토큰 저장 및 CSRF 토큰 분리
- • CSP 정책 수립 및 nonce 기반 스크립트 허용
- • 의존성 취약점 자동 스캔 및 SRI 적용
금융권이나 개인정보를 다루는 서비스에서 보안 감사를 통과하고 컴플라이언스를 충족하기 위한 필수 설계입니다.
SSR 환경(Nuxt)에서 CSP nonce를 어떻게 구현하고, hydration 과정에서 보안을 유지하시겠습니까?
Q. 대규모 Vue 조직에서 컴포넌트 라이브러리와 비즈니스 로직의 테스트 전략을 수립해야 합니다. 단위 테스트(Vitest), 컴포넌트 테스트(Vue Test Utils), E2E 테스트(Playwright)의 적절한 비율과 범위를 어떻게 정하시겠습니까? 또한 Composition API의 composable 함수들을 효과적으로 테스트하는 방법과, 테스트 커버리지 목표 설정 및 CI/CD 파이프라인 통합 전략을 설명해주세요.
테스트 피라미드 원칙과 각 레이어에서 검증해야 할 관심사를 분리하여 생각해보세요.
테스트 피라미드에 따라 단위 테스트 70%, 컴포넌트 테스트 20%, E2E 테스트 10% 비율을 목표로 합니다. Composable 함수는 Vue 컨텍스트 없이 순수 함수처럼 Vitest로 테스트하고, 복잡한 reactivity는 createApp으로 최소 환경을 구성해 검증합니다. 컴포넌트 테스트는 사용자 인터랙션과 props/emit 계약을 중심으로 작성하고, 내부 구현보다는 공개 API를 테스트합니다. E2E는 critical user journey만 선별하여 Playwright로 작성하고, 병렬 실행과 재시도 로직으로 안정성을 확보합니다. 커버리지는 비즈니스 로직 90%, UI 컴포넌트 80%를 목표로 하되, 단순 타입 정의나 상수는 제외합니다. CI에서는 PR마다 단위/컴포넌트 테스트를 실행하고, main 브랜치 머지 시 E2E를 실행하며, 커버리지 저하 시 빌드를 실패시킵니다.
- • 테스트 피라미드 기반 70-20-10 비율 설정
- • Composable 함수의 독립적 단위 테스트
- • 컴포넌트 공개 API 중심 테스트 작성
- • Critical path E2E 테스트 및 CI 단계별 실행 전략
여러 팀이 협업하는 환경에서 코드 품질을 일관되게 유지하고, 리팩토링 시 회귀 버그를 방지하기 위한 핵심 인프라입니다.
Pinia 스토어를 테스트할 때 실제 API 호출을 어떻게 모킹하고, 비동기 액션의 부작용을 검증하시겠습니까?
Q. Vue 어드민 대시보드에서 수백만 건의 로그 데이터를 조회하고 필터링하는 기능을 구현합니다. 프론트엔드에서 페이지네이션(offset vs cursor), 정렬, 다중 필터 조건을 효율적으로 처리하기 위한 API 설계와, 백엔드 DB 인덱스 전략을 어떻게 수립하시겠습니까? 또한 실시간 데이터 업데이트가 필요한 경우 폴링, 웹소켓, SSE 중 어떤 방식을 선택하시겠습니까?
대용량 데이터에서 offset 기반 페이지네이션의 성능 문제와 복합 인덱스 설계를 고려해보세요.
Cursor 기반 페이지네이션을 채택하여 대용량 데이터에서도 일정한 조회 성능을 보장합니다. API는 필터 조건을 query parameter로 받되, 복잡한 조건은 POST body로 전달하고, 정렬 필드와 방향을 명시적으로 지정합니다. DB에는 자주 사용되는 필터 조건(timestamp, status, user_id)에 대한 복합 인덱스를 생성하고, 쿼리 실행 계획을 분석하여 인덱스 효율을 검증합니다. Vue 컴포넌트에서는 가상 스크롤(vue-virtual-scroller)로 대량 데이터 렌더링을 최적화합니다. 실시간 업데이트는 업데이트 빈도가 낮으면 폴링(30초), 빈도가 높으면 웹소켓을 사용하되, 단방향 푸시만 필요하면 SSE를 선택합니다. 웹소켓 사용 시 reconnection 로직과 메시지 큐잉을 구현하여 연결 안정성을 확보합니다.
- • Cursor 기반 페이지네이션으로 성능 보장
- • 자주 사용되는 필터 조건에 대한 복합 인덱스 생성
- • 가상 스크롤을 통한 렌더링 최적화
- • 업데이트 빈도에 따른 실시간 통신 방식 선택
로그 분석, 거래 내역 조회, 모니터링 대시보드 등 대용량 데이터를 다루는 어드민 시스템에서 필수적인 설계입니다.
필터 조건이 동적으로 변경될 때 기존 인덱스를 활용하지 못하는 경우, 어떻게 쿼리 성능을 개선하시겠습니까?
Q. Vue SPA를 서비스하는 환경에서 새 버전 배포 시 이미 페이지를 열어둔 사용자들이 오래된 청크 파일을 요청하여 404 에러가 발생하는 문제가 있습니다. 무중단 배포 전략, 버전 불일치 감지 및 사용자 알림, 그레이스풀 업데이트 방식, 그리고 CDN 캐시 무효화 전략을 종합적으로 설계해주세요. 또한 롤백이 필요한 경우의 대응 절차도 포함해주세요.
배포 시점의 에셋 파일 유지 전략과 클라이언트의 버전 감지 메커니즘을 함께 고려해야 합니다.
배포 시 이전 버전의 청크 파일을 일정 기간(24시간) 유지하는 블루-그린 배포 전략을 사용합니다. Vite 빌드 시 manifest.json을 생성하고, 앱 초기화 시 서버의 현재 버전과 클라이언트 버전을 비교합니다. 버전 불일치 감지 시 사용자에게 '새 버전이 있습니다' 배너를 표시하고, 중요 작업 중이 아니면 자동 리로드, 작업 중이면 완료 후 리로드하도록 유도합니다. API 요청 시 버전 헤더를 포함시켜 서버에서도 버전 불일치를 감지하고, 청크 로딩 실패 시 자동으로 페이지를 리로드하는 에러 핸들러를 구현합니다. CDN은 immutable 에셋은 1년 캐시, index.html은 no-cache로 설정하고, 배포 후 CDN purge API로 index.html만 무효화합니다. 롤백 시에는 이전 버전 디렉토리로 심볼릭 링크를 변경하고, 모니터링 대시보드에서 에러율이 임계치를 넘으면 자동 롤백을 트리거합니다.
- • 이전 버전 청크 파일 유지 및 블루-그린 배포
- • 클라이언트-서버 버전 비교 및 그레이스풀 업데이트 알림
- • 청크 로딩 실패 시 자동 리로드 메커니즘
- • CDN 캐시 전략 및 자동 롤백 시스템
24시간 운영되는 서비스에서 사용자 경험을 해치지 않으면서 안전하게 배포하기 위한 필수 전략입니다.
Micro Frontend 환경에서 각 앱의 버전이 다를 때, 호스트와 리모트 앱 간의 버전 호환성을 어떻게 관리하시겠습니까?
Q. 기술 부채가 심각하게 쌓인 Vue 2 레거시 프로젝트를 맡게 되었고, 경영진은 새 기능 개발을 우선시하는 반면 팀은 리팩토링이 시급하다고 주장하는 상황입니다. 리드 개발자로서 이런 이해관계 충돌을 어떻게 조율하고, 비즈니스 가치와 기술 개선을 균형있게 추진한 경험을 STAR 방식으로 말씀해주세요.
기술 부채를 비즈니스 언어로 번역하고, 점진적 개선 전략을 제시한 경험을 구조화하여 설명하세요.
답변은 Situation(레거시 코드로 인한 개발 속도 저하 및 장애 빈도 증가), Task(비즈니스 요구와 기술 개선의 균형점 찾기), Action(기술 부채를 개발 속도 저하율과 장애 비용으로 정량화하여 경영진에게 제시, Strangler Fig 패턴으로 새 기능 개발 시 해당 영역만 Vue 3로 점진적 마이그레이션, 주 2일은 기능 개발, 1일은 리팩토링으로 스프린트 구성, 성능 개선과 장애 감소 지표를 주간 리포트로 공유), Result(3개월 후 배포 시간 40% 단축, 프로덕션 버그 60% 감소, 팀 만족도 향상 및 경영진의 기술 투자 승인) 순서로 구성합니다. 핵심은 기술 이슈를 비즈니스 임팩트로 번역하고, 점진적 개선으로 리스크를 최소화하며, 정량적 성과로 신뢰를 구축한 점입니다.
- • 기술 부채의 비즈니스 임팩트 정량화
- • Strangler Fig 패턴을 통한 점진적 개선
- • 스프린트 내 기능 개발과 리팩토링 시간 배분
- • 정량적 성과 측정 및 이해관계자 커뮤니케이션
리드급 개발자는 기술적 의사결정뿐 아니라 비즈니스와 팀 사이의 중재자 역할을 수행해야 합니다.
팀원 중 일부가 레거시 유지보수만 하고 싶어하지 않을 때, 어떻게 동기부여하고 역할을 분배하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!