이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사용성을 높이는 가장 효과적인 접근은 사용자가 어디서 멈추는지 찾는 것이라고 생각합니다. 화면을 개발할 때 Hotjar 히트맵으로 클릭 패턴을 분석했더니 CTA 버튼 위 여백이 넓어서 버튼이 아닌 영역을 클릭하는 패턴이 보였습니다. 레이아웃 조정만으로 전환율이 7% 높아진 경험이 있습니다.
Lighthouse 접근성 검사를 배포 전 기준으로 잡아 스크린리더 지원, 색 대비, 키보드 네비게이션을 확인했습니다. 로딩이 오래 걸리는 화면에는 스켈레톤 UI를 넣으니 이탈이 줄었습니다. 사용성은 코드 품질과 별개로, 실제 사용자 행동 데이터 없이는 개선 방향을 잡기 어렵다고 생각합니다.
사용성을 높이는 작업에서 접근성을 나중에 생각해도 된다고 여기다 고치는 비용이 커진 경험이 있습니다. 기능 개발이 끝난 뒤 Lighthouse 접근성 검사를 처음 돌렸는데, 점수가 62점이었고 스크린리더가 버튼 텍스트를 읽지 못하는 문제가 여러 곳에 있었습니다. 혼자서 고칠 수 있는 항목부터 시작했습니다.
`aria-label` 추가, 색 대비 수정, 이미지 alt 텍스트 보완을 이틀 만에 처리했습니다. 폼 입력 필드의 에러 메시지도 시각적으로만 표시돼 있어서 role="alert" 속성을 추가했습니다. 이 작업만으로 Lighthouse 접근성 점수가 62에서 91로 올랐고, 팀에서도 이후 기능 개발 시 접근성을 처음부터 고려하기 시작했습니다.
사용성 개선에서 로딩 속도가 기능만큼 중요하다는 걸 데이터로 확인한 적이 있습니다. 사이드 프로젝트 첫 페이지 로딩이 3.2초였는데, 사용자 테스트에서 절반 가까이 첫 화면이 뜨기 전에 뒤로 가는 패턴이 보였습니다. Lighthouse로 원인을 분석하니 자바스크립트 번들이 한꺼번에 로드되고 있었습니다. 라우트별 코드 스플리팅을 적용하고, 이미지에 lazy loading을 붙이고 WebP 포맷으로 바꿨습니다.
변경 후 첫 페이지 로딩이 3.2초에서 1.4초로 줄었습니다. 사용자 테스트에서 이탈 패턴이 눈에 띄게 줄었고, 사용성 개선이 디자인보다 성능에서 먼저 온다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.