이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프론트엔드 프로젝트에서 다양한 필드 타입이 혼합된 동적 폼을 구현하는 것이 가장 복잡했습니다. 필드 타입마다 별도의 컴포넌트를 만들다 보니 코드가 중복되고 유지보수가 어려워졌습니다. 스키마 기반 폼 렌더링 방식을 도입하여 필드 설정을 JSON으로 정의하면 컴포넌트가 자동으로 그에 맞게 렌더링하도록 추상화하였습니다.
처음에는 추상화 수준을 어떻게 정할지 판단하기 어려웠으나, 필드 타입이 추가될 때마다 코드 변경 없이 JSON만 바꿔도 되는 수준을 목표로 설정하였습니다. 추상화는 유연성과 복잡도의 균형을 잡는 과정이라는 것을 그 프로젝트에서 배웠습니다. 과도하게 추상화하면 오히려 이해하기 어려워진다는 것도 알게 되었습니다.
팀 프로젝트에서 유사한 레이아웃 컴포넌트가 각 페이지마다 중복으로 만들어져 있었어요. 디자인 변경이 생길 때마다 여러 곳을 동시에 고쳐야 했고, 누락이 반복됐습니다. 공통 레이아웃 컴포넌트로 추상화하고 props로 차이를 주입하는 방식으로 정리했어요.
리팩토링 초반엔 기존 코드를 건드리는 부분이 많아서 조심스러웠는데, 단계별로 나눠서 진행했습니다. 변경 이후 같은 영역의 수정이 한 곳에서만 이루어지게 됐어요. 중복이 있을 때 추상화 기회를 먼저 보는 습관이 그 경험에서 생겼습니다. DRY 원칙이 원칙이 아니라 실용적인 이유가 있다는 걸 체감했고, 중복이 늘어날수록 변경 비용이 기하급수적으로 커진다는 것도 그때 처음 실감했습니다.
개인 프로젝트에서 서버 데이터 요청·로딩·에러 상태를 각 컴포넌트마다 따로 관리하다 보니 코드가 비슷한 패턴으로 반복됐어요. useFetch라는 커스텀 훅을 만들어서 요청 로직, 로딩 상태, 에러 처리를 한 곳에서 관리하도록 했습니다. 처음엔 훅이 너무 많은 것을 담으려고 해서 오히려 복잡해졌어요. 범위를 좁혀서 '네트워크 요청과 상태 관리'만 담당하게 제한했더니 재사용성이 높아졌습니다.
추상화는 범위를 명확히 하는 것이 핵심이라는 걸 배웠어요. 너무 많은 것을 담으면 추상화가 아니라 복잡도가 돼요. 이 경험 이후로 훅을 만들 때 단일 책임을 먼저 생각하게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.