이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 모바일·태블릿·데스크탑 세 화면을 지원하는 반응형 웹 페이지를 구현했습니다. 미디어 쿼리만으로 시작했다가 레이아웃 분기가 복잡해지면서 CSS Grid와 Flexbox를 조합하는 방식으로 구조를 정리했습니다. 처음에는 데스크탑 레이아웃을 먼저 만들고 모바일로 좁혀가는 방식을 썼는데, 모바일에서 의도치 않은 오버플로우가 자주 생겼습니다.
모바일 퍼스트 접근으로 바꾸고 나서 레이아웃 흐름이 훨씬 자연스러워졌습니다. viewport meta 태그 누락으로 iOS에서 레이아웃이 깨지는 문제도 겪었고, 이후 크로스 브라우저 테스트를 배포 전 루틴으로 만들었습니다. 이미지 최적화도 함께 진행해, 큰 이미지를 그대로 불러오다 생기는 모바일 로딩 속도 문제도 함께 해결했습니다. 반응형은 화면 크기 대응이 아니라 콘텐츠 우선순위 재배치라는 결을 이 프로젝트에서 얻었습니다.
반응형 웹 구현 후 Lighthouse로 성능을 측정했을 때, 모바일 점수가 데스크탑보다 30점 이상 낮게 나왔습니다. 렌더링을 막는 CSS 파일과 과도하게 큰 이미지가 주원인이었습니다. <picture> 태그와 srcset으로 뷰포트에 맞는 이미지를 선택하게 했고, 크리티컬 CSS를 인라인으로 올려 첫 렌더링이 빨라졌습니다. 수정 전후 LCP를 비교했더니 모바일에서 3.2초에서 1.8초로 단축됐습니다.
Lighthouse 점수가 절대 지표는 아니지만, 개선 전후를 비교하는 데 유용한 기준이 됐습니다. 측정 없이 최적화했다면 어느 부분이 실제로 효과 있었는지 알 수 없었을 것입니다. 반응형은 레이아웃만이 아니라 로딩 성능도 함께 고려해야 하는 결이라는 것을 수치로 확인했습니다.
반응형 구현에서 CSS Grid와 Flexbox를 어떻게 나눠 쓸지 처음에는 기준이 없어 혼란스러웠습니다. Grid는 2차원 레이아웃, Flexbox는 1차원 흐름이라는 말은 알고 있었지만 실제로 어느 컴포넌트에 어느 것을 쓸지 판단이 서지 않았습니다. 카드형 목록은 Grid로, 네비게이션 바 내부 정렬은 Flexbox로 구분했을 때 레이아웃 코드가 훨씬 단순해졌습니다.
가장 큰 배움은 두 기술을 경쟁 관계로 보지 않는 것이었습니다. 미디어 쿼리 분기를 Grid 템플릿 영역으로 관리하니 화면 크기별 구조 변화가 한눈에 들어왔습니다. 레이아웃 코드 리뷰를 하면서 팀원에게 기준을 설명하는 과정이 제 이해를 더 정확하게 만들었습니다.
코드를 선택할 때 왜 이 기술인가를 설명할 수 있어야 한다는 결이 남았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.