이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 Vue 2로 시작했다가 팀원의 제안으로 Vue 3로 마이그레이션하였습니다. Options API로 작성된 컴포넌트가 기능이 추가될수록 data, methods, computed가 뒤섞여서 읽기 어려워졌습니다. Composition API로 바꾸면서 같은 기능끼리 setup() 안에 묶을 수 있다는 점이 좋았습니다. 처음에는 ref와 reactive의 차이를 헷갈려서 객체를 ref로 감쌌다가 .value.속성으로 접근해야 해서 불편했습니다. 이후 원시값에는 ref, 객체에는 reactive를 기준으로 사용하게 되었습니다. 검색 필터와 페이지네이션을 하나의 useFilter 훅으로 추출하였고, 다른 페이지에서 재사용할 수 있어서 코드가 200줄 줄어들었습니다.
사이드 프로젝트에서 여러 페이지가 로그인 상태 확인, API 호출, 에러 처리를 각자 중복으로 갖고 있었어요. Vue 3 Composition API의 Composable 개념을 배우고 나서 useAuth와 useApi로 로직을 분리했습니다. useAuth는 토큰 유효성 검사와 리프레시 로직을 담았고, useApi는 axios 인스턴스와 에러 핸들링을 묶었어요. 처음엔 provide/inject와 Composable의 차이를 몰라서 전역 상태를 Composable 안에 넣었다가 컴포넌트마다 상태가 독립적으로 생기는 문제가 있었어요. 이후 전역은 Pinia로 분리하고, Composable은 로컬 로직만 담도록 역할을 나눴습니다.
Vue 3 Composition API를 처음 배운 건 유튜브 강의였는데, 강의 예제가 너무 단순해서 실제로 어떻게 쓰는지 감이 안 왔어요. 직접 써본 건 할 일 관리 앱에서였는데, 필터링·정렬·검색 세 기능을 setup() 안에 다 넣었다가 200줄이 넘어갔습니다. 그때서야 기능 단위로 Composable을 쪼개야 한다는 걸 이해했어요.
useTodoFilter, useTodoSort로 나누고 나니 각 파일이 40줄 이하로 읽기 편해졌습니다. watchEffect와 watch의 차이도 이때 직접 실험해봤는데, 의존성을 자동 추적하는 watchEffect가 편리하지만 언제 실행되는지 명확하지 않아서 부수효과가 있을 때는 watch로 명시하게 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 incross 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.