이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
포트폴리오 프로젝트에서 리액트 쿼리를 처음 사용해 보았습니다. 그 전에는 useEffect 안에 fetch를 직접 사용하고 loading/error 상태를 useState로 하나씩 관리했는데, 화면이 10개가 넘어가면서 비슷한 패턴의 코드가 반복되는 것이 매우 불편했습니다. 리액트 쿼리를 도입하니 캐시 덕분에 같은 API를 여러 컴포넌트에서 호출해도 요청이 중복되지 않았습니다. 처음에는 staleTime과 cacheTime 차이를 몰라서 데이터가 너무 자주 새로 고침되는 문제가 있었는데, 공식 문서를 읽고 3분/5분으로 설정한 후에 해결되었습니다. 이 경험을 통해 비동기 상태 관리를 직접 구현하는 것과 라이브러리를 사용하는 트레이드오프를 느꼈고, 작은 프로젝트라도 코드 반복이 보이기 시작하면 도구 도입을 고민해야 한다는 것을 배웠습니다.
처음 자바스크립트를 배울 때 비동기 처리를 이해하는 데 3주가 걸렸어요. 콜백 → Promise → async/await 순서로 배웠는데, await 없이 비동기 함수를 호출해서 undefined가 나오는 실수를 프로젝트에서 두 번 했어요. 에러 로그 없이 데이터가 안 나오는 상황이라 원인 파악에 하루씩 걸렸어요. 그 이후로 비동기 함수에는 try/catch를 붙이는 습관이 생겼고, 에러 메시지를 console에만 찍지 않고 사용자에게 보이는 에러 UI도 같이 만드는 습관도 생겼어요. Axios를 인터셉터로 설정해서 공통 에러 처리를 했을 때 코드가 훨씬 깔끔해졌던 경험도 있어요. 비동기 처리는 이론보다 직접 버그를 만나봐야 이해가 된다고 느꼈어요.
학교 프로젝트에서 대시보드 화면을 만들 때 세 개의 API를 순서대로 호출하다가 로딩이 3초가 넘어서 느렸어요. 알고 보니 의존 관계가 없는데 순차적으로 호출하고 있었던 거예요. Promise.all을 써서 병렬 처리했더니 1.2초로 줄었어요. 하지만 하나라도 실패하면 전체가 실패하는 걸 처음 몰랐다가 API 중 하나가 간헐적으로 오류가 나면서 화면 전체가 깨지는 버그를 경험했어요. 그때 Promise.allSettled로 바꿔서 일부 실패해도 나머지는 보여주도록 수정했어요. 비동기 처리에서 성공 케이스만 생각하지 말고 실패 케이스를 같이 설계해야 한다는 걸 이 경험에서 배웠어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.