Vue.js 미드레벨 CS 기초 기술면접
새 면접Q. Vue 애플리케이션에서 API 요청 시 CORS 에러가 발생했습니다. CORS의 동작 원리와 Preflight Request가 발생하는 조건, 그리고 개발 환경에서 프록시 설정을 통해 해결하는 방법과 프로덕션 환경에서의 해결 방안을 설명해주세요.
CORS는 브라우저의 Same-Origin Policy를 우회하기 위한 메커니즘으로, 서버가 Access-Control-Allow-Origin 헤더를 통해 특정 출처의 요청을 허용합니다. Preflight Request는 PUT, DELETE 등의 메서드나 커스텀 헤더를 사용할 때 OPTIONS 메서드로 사전 검증을 수행합니다. 개발 환경에서는 vue.config.js의 devServer.proxy 설정으로 동일 출처처럼 요청하고, 프로덕션에서는 백엔드에서 적절한 CORS 헤더를 설정하거나 Nginx 등의 리버스 프록시를 활용합니다. 인증 정보를 포함할 때는 withCredentials와 Access-Control-Allow-Credentials를 함께 설정해야 합니다.
- • Same-Origin Policy와 CORS의 관계 이해
- • Preflight Request 발생 조건 (Simple Request가 아닌 경우)
- • 개발/프로덕션 환경별 해결 방안 차이
- • 인증 정보 포함 시 추가 설정 필요
Simple Request의 조건은 무엇이며, Content-Type이 application/json일 때 왜 Preflight가 발생하는지 설명해주세요.
Q. Vue 애플리케이션에서 대량의 사용자 데이터를 ID로 빠르게 조회하고, 최근 접속 순으로 정렬된 목록도 유지해야 합니다. 이 요구사항을 효율적으로 구현하기 위해 어떤 자료구조 조합을 사용하시겠으며, 각 자료구조의 시간 복잡도와 선택 이유를 설명해주세요.
ID 기반 조회를 위해 Map 또는 객체를 사용하여 O(1) 조회 성능을 확보하고, 정렬된 목록 유지를 위해 배열을 함께 사용합니다. 사용자 데이터 추가/수정 시 Map에 저장하고, 배열에서 해당 항목을 찾아 제거 후 맨 앞에 추가하는 방식으로 최근 접속 순을 유지합니다. 더 효율적인 방법으로는 Map과 이중 연결 리스트를 조합하여 LRU 캐시 구조를 구현할 수 있으며, 이 경우 삽입/삭제/조회 모두 O(1)에 처리 가능합니다. Vue의 반응성 시스템과 통합 시 reactive Map을 사용하거나 배열 변경 시 적절한 불변성 처리가 필요합니다.
- • Map을 이용한 O(1) ID 조회
- • 배열 또는 연결 리스트를 통한 순서 유지
- • LRU 캐시 패턴의 시간 복잡도 이점
- • Vue 반응성 시스템과의 통합 고려
만약 데이터가 수만 건 이상으로 증가할 경우 메모리 효율을 위해 어떤 전략을 추가하시겠습니까?
Q. Vue 애플리케이션에서 게시글 목록을 페이지네이션으로 표시하는데, OFFSET 기반 페이징과 커서 기반 페이징의 차이점과 각각의 장단점을 설명하고, 무한 스크롤 기능 구현 시 어느 방식이 더 적합한지 설명해주세요.
OFFSET 기반 페이징은 LIMIT/OFFSET을 사용해 특정 페이지로 직접 이동 가능하지만, OFFSET이 클수록 데이터베이스가 건너뛴 행을 모두 스캔해야 하므로 성능이 저하됩니다. 커서 기반 페이징은 마지막 조회 항목의 ID나 타임스탬프를 기준으로 WHERE 조건을 사용해 다음 데이터를 가져오므로 일정한 성능을 유지하지만, 특정 페이지로 직접 이동이 어렵습니다. 무한 스크롤은 순차적으로 다음 데이터만 로드하므로 커서 기반 페이징이 더 적합하며, 인덱스를 활용한 빠른 조회가 가능합니다. 실시간으로 데이터가 추가/삭제되는 경우 OFFSET 방식은 중복이나 누락이 발생할 수 있어 커서 방식이 더 안정적입니다.
- • OFFSET 방식의 성능 저하 원인 (스캔 비용 증가)
- • 커서 방식의 일정한 성능과 인덱스 활용
- • 무한 스크롤에는 커서 기반이 적합
- • 실시간 데이터 변경 시 일관성 문제
커서 기반 페이징에서 정렬 순서가 변경될 때 발생할 수 있는 문제와 해결 방법을 설명해주세요.
Q. Vue 컴포넌트에서 트리 형태의 댓글 구조를 렌더링하는데, 각 댓글의 깊이를 계산하고 전체 댓글 수를 세는 로직이 필요합니다. 재귀적 접근과 반복적 접근(스택 활용)의 차이점, 각각의 시간/공간 복잡도, 그리고 깊이가 매우 깊은 경우 어떤 방식이 더 안전한지 설명해주세요.
재귀적 접근은 코드가 직관적이고 트리 구조를 자연스럽게 표현하지만, 콜 스택을 사용하므로 깊이가 깊으면 스택 오버플로우가 발생할 수 있습니다. 반복적 접근은 명시적 스택 자료구조를 사용해 깊이 우선 탐색이나 너비 우선 탐색을 구현하며, 스택 크기를 제어할 수 있어 더 안전합니다. 시간 복잡도는 모든 노드를 방문하므로 둘 다 O(n)이지만, 공간 복잡도는 재귀가 O(h) (h는 트리 높이), 반복도 스택 사용 시 O(h)입니다. 실무에서는 깊이 제한이 있는 경우 재귀를 사용하고, 사용자 생성 데이터로 깊이를 예측할 수 없다면 반복적 방식이나 깊이 제한을 두는 것이 안전합니다.
- • 재귀의 콜 스택 제한과 스택 오버플로우 위험
- • 반복적 접근의 명시적 스택 제어
- • 시간 복잡도 O(n), 공간 복잡도 O(h)
- • 실무에서는 깊이 제한 또는 반복 방식 선호
꼬리 재귀 최적화(Tail Call Optimization)가 JavaScript에서 어떻게 지원되며, 이를 활용한 안전한 재귀 구현이 가능한지 설명해주세요.
Q. Vue 애플리케이션에서 Web Worker를 사용하여 무거운 데이터 처리를 백그라운드로 이동시키려고 합니다. JavaScript의 싱글 스레드 모델과 이벤트 루프의 동작 원리, Web Worker의 메시지 전달 방식, 그리고 메인 스레드와 Worker 간 데이터 공유 시 주의사항을 설명해주세요.
JavaScript는 싱글 스레드로 동작하며 Call Stack, Task Queue, Microtask Queue를 통한 이벤트 루프로 비동기 작업을 처리합니다. Web Worker는 별도 스레드에서 실행되어 메인 스레드를 블로킹하지 않고, postMessage로 메시지를 전달하고 onmessage로 수신합니다. 데이터 전달 시 기본적으로 구조화된 복제(Structured Clone) 알고리즘을 사용해 깊은 복사가 일어나므로 큰 데이터는 성능 영향이 있고, 함수나 DOM 객체는 전달할 수 없습니다. Transferable Objects를 사용하면 소유권을 이전하여 복사 비용 없이 ArrayBuffer 등을 전달할 수 있으며, SharedArrayBuffer로 메모리를 공유할 수도 있지만 동기화 문제에 주의해야 합니다.
- • 이벤트 루프와 Task Queue, Microtask Queue
- • Web Worker의 별도 스레드 실행과 메시지 전달
- • 구조화된 복제의 성능 영향과 제약사항
- • Transferable Objects와 SharedArrayBuffer 활용
Service Worker와 Web Worker의 차이점과 각각의 사용 사례를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!