Vue 3의 Composition API를 사용해본 경험이 있다면, 어떤 프로젝트에서 어떤 기능을 구현했는지 설명해 주세요. | incross 프론트엔드 면접 질문

Q: 본인이 가장 깊이 본 결은 어디였나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 구현 결을 어떻게 잡으셨나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 결과를 어떤 결로 측정하시나요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

iincross프론트엔드경험·이력2026년 출제

답변 미리보기

졸업 프로젝트에서 Vue 2로 시작했다가 팀원의 제안으로 Vue 3로 마이그레이션하였습니다. Options API로 작성된 컴포넌트가 기능이 추가될수록

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

본인 손에 잡은 결이 또렷한가?

구성·상태·재사용 결 중 본인이 직접 한 자리가 답에 보입니다. 일반론으로만 답하면 깊이가 옅은 자리입니다.

구현 결을 또렷이 짚는가?

Composable·상태·합의 결로 본인이 가른 흔적이 답에서 드러나는 결이 통합니다. 매끈하게만 끝나는 답은 외워 온 결로 들립니다.

본인 사례로 닫는가?

추상 다짐이 아니라 본인이 실제로 한 결을 짚는 답이 자주 등장합니다. 매끈하게만 끝나는 답은 외워 온 결로 들립니다.

측정 가능한 결과로 닫는가?

재사용·결함·시간 결로 본인이 결과를 본 흔적이 답에 보입니다. 수치 없이 좋아진다는 답은 검증이 옅은 결입니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

incross 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

Options API에서 Composition API 마이그레이션약 88초 Composable 함수로 로직 분리약 85초 Composition API 학습 후 실전 적용약 90초

예시 답변 1

약 88초

Options API에서 Composition API 마이그레이션

졸업 프로젝트에서 Vue 2로 시작했다가 팀원의 제안으로 Vue 3로 마이그레이션하였습니다. Options API로 작성된 컴포넌트가 기능이 추가될수록 data, methods, computed가 뒤섞여서 읽기 어려워졌습니다. Composition API로 바꾸면서 같은 기능끼리 setup() 안에 묶을 수 있다는 점이 좋았습니다. 처음에는 ref와 reactive의 차이를 헷갈려서 객체를 ref로 감쌌다가 .value.속성으로 접근해야 해서 불편했습니다. 이후 원시값에는 ref, 객체에는 reactive를 기준으로 사용하게 되었습니다. 검색 필터와 페이지네이션을 하나의 useFilter 훅으로 추출하였고, 다른 페이지에서 재사용할 수 있어서 코드가 200줄 줄어들었습니다.

이 결의 특징

Options API의 뒤섞임 문제를 Composition API로 전환하며 useFilter 훅으로 재사용해 코드를 줄인 흔적이 있습니다.

이 결이 통하는 자리

ref와 reactive의 차이를 헷갈렸던 실패에서 원시값과 객체 기준을 얻은 관점이 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 자리를 자주 봅니다.

예시 답변 2

약 85초

Composable 함수로 로직 분리

사이드 프로젝트에서 여러 페이지가 로그인 상태 확인, API 호출, 에러 처리를 각자 중복으로 갖고 있었어요. Vue 3 Composition API의 Composable 개념을 배우고 나서 useAuth와 useApi로 로직을 분리했습니다. useAuth는 토큰 유효성 검사와 리프레시 로직을 담았고, useApi는 axios 인스턴스와 에러 핸들링을 묶었어요. 처음엔 provide/inject와 Composable의 차이를 몰라서 전역 상태를 Composable 안에 넣었다가 컴포넌트마다 상태가 독립적으로 생기는 문제가 있었어요. 이후 전역은 Pinia로 분리하고, Composable은 로컬 로직만 담도록 역할을 나눴습니다.

이 결의 특징

전역 상태를 Composable에 넣었다가 독립 상태 문제를 겪고 Pinia로 역할을 분리한 흔적이 있습니다.

이 결이 통하는 자리

Composable은 로컬 로직만 담당하도록 역할을 나눈 구체적 개선이 담긴 답에서 통합니다.

예시 답변 3

약 90초

Composition API 학습 후 실전 적용

Vue 3 Composition API를 처음 배운 건 유튜브 강의였는데, 강의 예제가 너무 단순해서 실제로 어떻게 쓰는지 감이 안 왔어요. 직접 써본 건 할 일 관리 앱에서였는데, 필터링·정렬·검색 세 기능을 setup() 안에 다 넣었다가 200줄이 넘어갔습니다. 그때서야 기능 단위로 Composable을 쪼개야 한다는 걸 이해했어요.

useTodoFilter, useTodoSort로 나누고 나니 각 파일이 40줄 이하로 읽기 편해졌습니다. watchEffect와 watch의 차이도 이때 직접 실험해봤는데, 의존성을 자동 추적하는 watchEffect가 편리하지만 언제 실행되는지 명확하지 않아서 부수효과가 있을 때는 watch로 명시하게 됐어요.

이 결의 특징

모든 기능을 setup 안에 넣어 200줄이 넘어간 실패에서 기능 단위 분리로 개선한 흔적이 있습니다.

이 결이 통하는 자리

watchEffect와 watch의 차이를 직접 실험해 명시적 사용 기준을 얻은 관점이 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 결이 보입니다.

위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹본인이 가장 깊이 본 결은 어디였나요?

貳구현 결을 어떻게 잡으셨나요?

參결과를 어떤 결로 측정하시나요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. incross 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히

개인정보처리방침 이용약관 문의

iincross프론트엔드경험·이력2026년 출제

답변 미리보기

졸업 프로젝트에서 Vue 2로 시작했다가 팀원의 제안으로 Vue 3로 마이그레이션하였습니다. Options API로 작성된 컴포넌트가 기능이 추가될수록

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

본인 손에 잡은 결이 또렷한가?

구성·상태·재사용 결 중 본인이 직접 한 자리가 답에 보입니다. 일반론으로만 답하면 깊이가 옅은 자리입니다.

구현 결을 또렷이 짚는가?

Composable·상태·합의 결로 본인이 가른 흔적이 답에서 드러나는 결이 통합니다. 매끈하게만 끝나는 답은 외워 온 결로 들립니다.

본인 사례로 닫는가?

추상 다짐이 아니라 본인이 실제로 한 결을 짚는 답이 자주 등장합니다. 매끈하게만 끝나는 답은 외워 온 결로 들립니다.

측정 가능한 결과로 닫는가?

재사용·결함·시간 결로 본인이 결과를 본 흔적이 답에 보입니다. 수치 없이 좋아진다는 답은 검증이 옅은 결입니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

incross 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

Options API에서 Composition API 마이그레이션약 88초 Composable 함수로 로직 분리약 85초 Composition API 학습 후 실전 적용약 90초

예시 답변 1

약 88초

Options API에서 Composition API 마이그레이션

이 결의 특징

Options API의 뒤섞임 문제를 Composition API로 전환하며 useFilter 훅으로 재사용해 코드를 줄인 흔적이 있습니다.

이 결이 통하는 자리

ref와 reactive의 차이를 헷갈렸던 실패에서 원시값과 객체 기준을 얻은 관점이 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 자리를 자주 봅니다.

예시 답변 2

약 85초

Composable 함수로 로직 분리

이 결의 특징

전역 상태를 Composable에 넣었다가 독립 상태 문제를 겪고 Pinia로 역할을 분리한 흔적이 있습니다.

이 결이 통하는 자리

Composable은 로컬 로직만 담당하도록 역할을 나눈 구체적 개선이 담긴 답에서 통합니다.

예시 답변 3

약 90초

Composition API 학습 후 실전 적용

이 결의 특징

모든 기능을 setup 안에 넣어 200줄이 넘어간 실패에서 기능 단위 분리로 개선한 흔적이 있습니다.

이 결이 통하는 자리

watchEffect와 watch의 차이를 직접 실험해 명시적 사용 기준을 얻은 관점이 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 결이 보입니다.

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹본인이 가장 깊이 본 결은 어디였나요?

貳구현 결을 어떻게 잡으셨나요?

參결과를 어떤 결로 측정하시나요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. incross 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

개인정보처리방침 이용약관 문의