이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프론트엔드는 주로 React로 개발했습니다. 처음엔 클래스 컴포넌트를 썼는데, 훅 도입 이후 상태와 사이드 이펙트를 분리하는 방식이 훨씬 명확해졌습니다. 비동기 데이터 패칭을 직접 관리하다가 캐시 만료, 로딩 상태, 에러 처리가 컴포넌트마다 중복되는 문제를 겪었고, React Query 도입 이후 그 코드가 크게 줄었습니다. 인턴십에서는 Blazor를 이용한 C# 기반 웹 컴포넌트도 잠깐 다뤘는데, .NET 생태계와 잘 맞는 인트라넷 환경에서는 배포가 단순하다는 인상을 받았습니다. React는 생태계 폭이 넓은 만큼 선택지가 많아서 팀 컨벤션이 없으면 코드 스타일이 빠르게 갈라지는 경험도 했습니다.
React로 프론트엔드를 개발하면서 팀 내에 컴포넌트 구조나 상태 관리 방식에 대한 합의가 없었을 때 코드가 빠르게 갈라지는 것을 경험했습니다. 같은 기능을 구현하는 데 팀원마다 다른 방식을 사용했는데, 시간이 지날수록 서로의 코드를 이해하는 데 드는 시간이 늘어났습니다. 문서로 컨벤션을 정리하는 것보다 코드 리뷰에서 반복적으로 같은 기준을 적용하면서 팀 전체가 같은 방향으로 맞춰지는 방식이 더 효과적이었습니다. ESLint 규칙을 추가해서 자동으로 잡히는 부분은 리뷰 부담을 줄였는데, 도구로 잡을 수 없는 설계 결정은 여전히 사람이 리뷰하는 것이 필요했습니다. React는 선택지가 많다는 것이 강점이지만, 팀 단위에서는 그 선택지 중 무엇을 쓸지 합의하는 비용이 프레임워크 자체를 익히는 것만큼 실제로 드는 비용이라는 것을 이 경험에서 배웠습니다.
인턴십에서 C# Blazor를 이용한 내부 도구를 개발하면서 .NET 생태계에 익숙한 팀이 웹 프론트엔드를 어떤 방식으로 다루는지 관찰할 수 있었습니다. 백엔드 개발자들이 C# 문법과 .NET 라이브러리를 그대로 사용하면서 웹 인터페이스를 만들 수 있다는 것이 팀 입장에서는 새로운 기술을 배우는 부담 없이 생산성을 유지하는 방식이었습니다. React와 비교했을 때 JavaScript 생태계의 방대한 UI 라이브러리를 활용하기 어렵다는 점과, 브라우저에서 실행되는 웹어셈블리 기반 방식이 초기 로딩에 영향을 준다는 점을 관찰했습니다. 어떤 기술이 더 좋다는 것이 아니라, 팀이 이미 가진 기술 스택과 맥락에 따라 적합한 선택이 다를 수 있다는 것을 이 경험에서 이해하게 됐습니다. 프론트엔드 기술 선택은 성능이나 기능만이 아니라 팀의 기존 역량과 생태계 연계성도 함께 고려해야 한다는 것을 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.