이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
상용 서비스 프론트엔드 개발에서 가장 큰 문제는 사용자 규모가 늘면서 초기 로딩 시간이 길어진 것이었습니다. 기능을 추가할수록 번들 크기가 커졌고, 처음 화면이 뜨기까지의 시간이 사용자 이탈에 영향을 줬습니다. 코드 스플리팅을 적용해 현재 화면에 필요한 코드만 로드하도록 바꿨고, 라우트 단위로 청크를 나누자 초기 번들 크기가 크게 줄었습니다.
이미지 최적화도 진행했는데, 고해상도 이미지를 그대로 올리던 것을 WebP 포맷과 적절한 해상도로 변환하자 로딩 속도가 개선됐습니다. Lighthouse 점수를 기준으로 개선 전후를 비교하면서, 어떤 변경이 실제로 효과가 있는지를 측정해가면서 작업했습니다. 한계는 서드파티 스크립트가 많아질수록 통제가 어렵다는 점이었는데, 필수적이지 않은 스크립트는 지연 로드하는 방식으로 우선순위를 낮췄습니다. 프론트엔드 성능은 측정하고 원인을 좁혀야 실제 개선이 된다는 결을 배웠습니다.
상용 서비스에서 또 다른 큰 문제는 특정 브라우저에서만 UI가 깨지는 현상이 보고됐을 때였습니다. 팀 내에서는 Chrome 기준으로만 테스트를 해왔는데, 사용자 피드백으로 Safari에서 레이아웃이 틀어진다는 것을 처음 알게 됐습니다. `flexbox` 속성 중 일부가 Safari에서 다르게 동작한다는 것을 확인하는 데 시간이 걸렸는데, Can I Use를 이용해서 문제가 되는 속성의 브라우저 지원 현황을 정리하는 습관이 생겼습니다.
이후에는 새 CSS 속성을 쓸 때마다 지원 범위를 먼저 확인하게 됐고, 폴백 처리를 함께 넣는 방식을 팀 가이드로 잡았습니다. 브라우저 호환성은 처음부터 고려하지 않으면 예상치 못한 지점에서 사용자에게 노출된다는 것을 이 경험으로 배웠습니다.
성능 말고 또 하나의 큰 문제는 여러 컴포넌트가 같은 데이터를 제각각 가져오면서 상태가 엉키는 것이었습니다. 초기에는 각 컴포넌트에서 API를 직접 호출하는 방식을 썼는데, 기능이 늘면서 같은 데이터를 세 군데에서 따로 패칭하고 각각 다른 상태를 들고 있는 문제가 생겼습니다. 장바구니 수량이 헤더와 페이지에서 다르게 표시되는 버그가 사용자에게 노출됐고, 이 버그를 재현하는 것부터가 어려웠습니다. 전역 상태 관리로 정리하면서 API 호출 지점을 단일 출처로 모으고, 같은 데이터는 항상 같은 출처에서 읽도록 구조를 바꿨습니다. 상태 분산은 기능이 늘면서 서서히 일어나기 때문에 초기에 출처를 명확히 잡아두지 않으면 나중에 정리 비용이 크다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.