Vue.js 미드레벨 트러블슈팅 면접

먼저 Chrome DevTools의 Performance 탭에서 프로파일링을 수행하여 어느 함수에서 시간이 오래 걸리는지 확인합니다. Long Task가 발생하는 지점을 식별하고, 해당 코드가 동기적으로 대량의 데이터를 처리하는지 확인합니다. 일반적으로 computed나 watch에서 5만 건의 배열을 필터링하거나 정렬하는 로직이 원인일 가능성이 높습니다. 해결 방법으로는 Virtual Scrolling을 적용하여 실제로 렌더링되는 항목을 제한하거나, Web Worker로 무거운 연산을 이동시키거나, requestIdleCallback을 활용하여 작업을 청크 단위로 분할하는 방법이 있습니다. 또한 shallowRef를 사용하여 불필요한 깊은 반응성을 제거하고, Object.freeze()로 읽기 전용 데이터의 반응성을 비활성화할 수 있습니다.

Detached DOM nodes가 증가하는 것은 컴포넌트가 unmount되었음에도 이벤트 리스너, 타이머, Observer 등이 정리되지 않아 DOM 참조가 유지되는 메모리 누수 상황입니다. Memory 탭의 Comparison 뷰에서 페이지 이동 전후 스냅샷을 비교하여 어떤 객체가 증가했는지 확인합니다. 주요 원인으로는 onBeforeUnmount에서 removeEventListener를 호출하지 않은 경우, setInterval이나 setTimeout을 clearInterval/clearTimeout으로 정리하지 않은 경우, IntersectionObserver나 MutationObserver를 disconnect하지 않은 경우가 있습니다. 또한 전역 이벤트 버스나 window 객체에 직접 등록한 이벤트도 원인이 될 수 있습니다. 해결을 위해서는 Composable에서 onBeforeUnmount 훅을 활용하여 모든 구독과 리스너를 명시적으로 정리하고, AbortController를 사용하여 fetch 요청을 취소하며, effectScope를 활용하여 watch와 computed를 그룹으로 관리하고 한 번에 정리할 수 있습니다.

먼저 Vue Devtools의 Pinia 탭에서 Timeline 기능을 활성화하여 모든 상태 변경을 시간순으로 추적합니다. 각 mutation의 before/after 스냅샷을 비교하여 어느 액션에서 예상치 못한 변경이 발생했는지 확인합니다. 만약 액션 외부에서 직접 state를 수정하는 코드가 있다면, Pinia의 strict mode를 활성화하여 개발 중 경고를 받을 수 있습니다. 또한 $subscribe 메서드를 사용하여 특정 스토어의 모든 변경사항을 로깅하고, storeToRefs를 사용하지 않고 직접 구조분해 할당을 하여 반응성을 잃은 경우도 확인합니다. 근본적인 해결을 위해서는 state를 직접 수정하지 않고 항상 actions를 통해서만 변경하도록 팀 컨벤션을 정립하고, TypeScript의 readonly 타입을 활용하여 컴파일 단계에서 직접 수정을 방지할 수 있습니다.

이 문제는 라우트 전환이 먼저 일어나고 새 페이지 컴포넌트가 마운트된 후에 데이터를 로드하기 때문에 발생합니다. 컴포넌트가 마운트되면서 이전 상태나 빈 상태가 잠깐 렌더링되는 것입니다. 해결 방법으로는 먼저 Navigation Guard의 beforeEnter나 beforeResolve에서 필요한 데이터를 미리 로드하고 route.meta에 저장한 후 컴포넌트에서 사용하는 방법이 있습니다. 또는 Suspense 컴포넌트와 async setup을 활용하여 데이터 로딩이 완료될 때까지 fallback UI를 표시할 수 있습니다. KeepAlive를 사용하여 이전에 방문한 페이지의 상태를 캐싱하는 방법도 있지만, 이 경우 데이터 신선도 문제를 고려해야 합니다. 로딩 상태를 명시적으로 관리하는 전역 로딩 인디케이터를 구현하여 사용자 경험을 개선할 수도 있습니다.

이 문제는 Chart.js와 같은 외부 라이브러리 인스턴스를 reactive로 감쌀 때 발생하는 전형적인 문제입니다. reactive는 객체의 모든 중첩된 속성을 Proxy로 감싸기 때문에, 복잡한 내부 구조를 가진 라이브러리 객체에 적용하면 엄청난 수의 Proxy가 생성되어 성능 저하를 일으킵니다. 또한 라이브러리 내부에서 순환 참조 구조가 있을 경우 Vue의 반응성 시스템이 무한 루프에 빠질 수 있습니다. 해결 방법으로는 markRaw를 사용하여 해당 객체를 반응성 추적에서 제외하거나, shallowRef를 사용하여 객체 참조만 추적하고 내부 속성은 추적하지 않도록 합니다. 차트 인스턴스는 ref나 shallowRef에 저장하되 markRaw로 감싸고, 차트 업데이트는 명시적으로 .value를 통해 접근하여 수행합니다. 또한 차트 데이터만 별도의 reactive 상태로 관리하고, 데이터 변경 시 watch를 통해 차트 인스턴스의 update 메서드를 호출하는 패턴이 안전합니다.

Race Condition 문제는 비동기 요청의 완료 순서가 발생 순서와 다를 때 발생합니다. 첫 번째 해결 방법은 각 요청마다 고유한 토큰이나 타임스탬프를 부여하고, 응답이 도착했을 때 가장 최신 요청인지 확인하는 것입니다. 두 번째는 AbortController를 사용하여 새 요청이 발생하면 이전 요청을 취소하는 방법입니다. watch에서 검색어가 변경될 때마다 이전 controller.abort()를 호출하고 새 AbortController를 생성합니다. 세 번째는 debounce를 적용하여 사용자가 타이핑을 멈춘 후 일정 시간이 지나야 요청을 보내도록 하여 불필요한 요청 자체를 줄이는 방법입니다. 가장 견고한 방법은 AbortController와 debounce를 함께 사용하는 것이며, VueUse의 useDebounceFn과 useAsyncState를 조합하면 쉽게 구현할 수 있습니다. 또한 요청 시퀀스 번호를 관리하여 응답이 도착했을 때 최신 시퀀스인지 확인하는 방법도 있습니다.

Hydration mismatch는 서버에서 생성한 HTML과 클라이언트에서 생성한 Virtual DOM이 일치하지 않을 때 발생합니다. 주요 원인으로는 첫째, 현재 시간이나 랜덤 값처럼 서버와 클라이언트에서 다른 값을 생성하는 경우입니다. 이는 서버에서 생성한 값을 상태로 저장하고 클라이언트에서 재사용해야 합니다. 둘째, localStorage나 document 같은 브라우저 전용 API를 서버에서 접근하려고 하는 경우로, onMounted나 ClientOnly 컴포넌트를 사용하여 클라이언트에서만 실행되도록 해야 합니다. 셋째, 외부 라이브러리가 서버와 클라이언트에서 다르게 동작하는 경우입니다. 디버깅을 위해서는 브라우저 개발자 도구의 콘솔에서 정확히 어느 엘리먼트에서 mismatch가 발생했는지 확인하고, 해당 컴포넌트의 조건부 렌더링 로직을 점검합니다. suppressHydrationWarning 속성으로 경고를 숨기는 것은 근본적인 해결책이 아니며, 반드시 원인을 찾아 수정해야 합니다. Nuxt의 경우 process.server와 process.client를 활용하여 환경별로 다른 로직을 실행할 수 있습니다.