이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
여행 도메인 프론트엔드에서 가장 중요하게 생각하는 것은 검색과 예약 흐름의 안정성입니다. 여행 상품은 가격과 재고가 실시간으로 바뀌는 경우가 많아, 사용자가 선택한 상품이 결제 직전에 품절되거나 가격이 변경되는 상황을 처리하는 방식이 UX에 직접 영향을 줍니다.
재고 변경 알림을 명확하게 보여주는 것이 중요한데, 사용자가 혼란 없이 다른 선택을 할 수 있도록 안내하는 흐름이 필요합니다. 필터와 정렬 기능도 여행 서비스에서는 핵심인데, 날짜·가격·인원 조합에 따라 결과가 크게 달라지므로 필터 상태가 URL에 반영돼야 공유와 뒤로 가기가 자연스럽습니다.
B2B와 B2C는 주요 흐름이 다르다는 것도 중요한데, B2B는 대량 예약과 정산 관리가 있어 화면 설계 자체가 달라집니다. 여행 프론트엔드는 재고와 가격이 변하는 실시간 특성을 UI 설계에 반영하는 것이 결임을 배웠습니다.
학부 프로젝트에서 여행 상품 검색 결과 목록을 처음 구현했을 때, 조건을 바꿀 때마다 화면이 1.5초 이상 멈추는 문제가 있었습니다. 테스트 데이터가 적을 때는 몰랐는데, 실제 상품 200개 이상이 들어오자 전체 목록이 다시 렌더링되면서 느려지는 게 원인이었습니다. 검색 조건이 바뀔 때마다 전체 컴포넌트가 다시 그려지는 구조를 가상 스크롤과 메모이제이션으로 개선했습니다. 화면에 보이는 항목만 렌더링하고, 조건이 바뀌지 않은 항목은 캐시를 쓰도록 바꿨더니 응답이 0.3초 이내로 줄었습니다. 프론트엔드에서 사용자 경험은 기능 완성도 못지않게 반응 속도가 중요하다는 걸 이 경험으로 처음 실감했습니다.
인턴 프로젝트에서 어드민(B2B)과 사용자 앱(B2C)이 같은 상품 조회 API를 공유하는 구조로 처음 설계했습니다. 처음에는 중복을 줄인다고 생각했는데, 어드민에서는 숨긴 상품도 봐야 하고 앱에서는 공개 상품만 보여야 하는 요구사항이 달랐습니다. API에 isAdmin 파라미터를 추가했더니 로직이 점점 복잡해졌고, 나중에는 같은 함수 안에 조건 분기가 7개가 생겼습니다. 결국 어드민용과 앱용 API를 분리하는 리팩토링을 했는데, 처음부터 나눴다면 훨씬 간단했을 거라는 걸 돌아봤습니다. B2B와 B2C는 사용자 컨텍스트가 달라 공통 API로 묶으면 복잡성이 증가한다는 걸 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.