이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 할인 규칙이 10가지가 넘는 주문 시스템의 프론트엔드를 맡았습니다. 조건문을 컴포넌트 안에 직접 뒀더니 규칙이 하나 바뀔 때마다 여러 컴포넌트를 찾아 수정해야 했고, 코드 리뷰에서도 파악이 어렵다는 피드백이 반복됐습니다. 비즈니스 규칙 레이어를 별도 모듈로 분리하고, 각 규칙을 함수 단위로 단독 테스트할 수 있게 구조를 바꿨습니다. 이후 규칙 변경이 생겼을 때 수정이 1곳으로 줄었고, 관련 버그 발생 횟수도 월 6건에서 1건으로 감소했습니다. UI와 로직을 분리해두면 요구사항 변경에 컴포넌트가 흔들리지 않는다는 것을 이 프로젝트에서 직접 확인했습니다.
프론트엔드 비즈니스 로직에서 서버 상태와 UI 상태를 구분하지 않아서 발생하는 문제를 경험했습니다. 서버에서 가져온 데이터를 로컬 상태에 그대로 복사해서 관리했는데, 데이터가 바뀌면 여러 곳의 상태를 함께 갱신해야 하는 부담이 생겼습니다. React Query를 도입해 서버 상태를 별도 계층으로 분리하니, 데이터 패칭·캐싱·동기화를 직접 구현하던 코드가 사라졌습니다.
낙관적 업데이트가 필요한 부분도 onMutate 옵션으로 처리해서 컴포넌트에서 UI 상태만 다루는 구조가 됐습니다. 서버 상태와 클라이언트 상태를 분리하면 비즈니스 로직이 어디에 있는지 찾기 쉬워진다는 것을 이 경험으로 배웠습니다.
프론트엔드 비즈니스 로직에서 React 컴포넌트 안에 규칙이 있으면 테스트하기 어렵다는 것을 경험했습니다. 할인 계산 로직이 컴포넌트에 묻혀 있어서 테스트를 작성하려면 렌더링 환경이 필요했는데, 환경 설정 비용이 높아서 테스트를 미루게 되는 구조였습니다. 규칙들을 프레임워크에 의존하지 않는 순수 함수로 추출하니, React 없이도 입력과 출력만으로 테스트가 가능해졌습니다.
함수 단위로 테스트가 쌓이면서, 규칙이 바뀔 때 어디가 깨지는지 빠르게 찾을 수 있었습니다. 비즈니스 로직을 프레임워크와 분리하면 테스트 가능성과 재사용성이 동시에 올라간다는 것을 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.