이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 비슷한 UI가 여러 페이지에 반복되는데 각각 따로 만들다 보니 같은 변경을 세 군데서 해야 하는 상황이 발생했습니다.
공통 컴포넌트를 분리하여 버튼, 모달, 폼 입력 등 반복되는 요소를 한 곳에서 관리하는 구조로 변경하였습니다. 처음에는 컴포넌트를 너무 세분화하여 오히려 props 전달이 복잡해지는 실수를 하였지만, '이 컴포넌트를 다른 곳에서도 사용할 것인가'를 기준으로 쪼개는 단위를 조절하였습니다.
구조를 변경한 후에는 디자인 변경이 생겨도 한 파일만 수정하면 되었습니다. 프론트엔드 서비스가 성장할수록 처음에 설정한 구조가 속도를 결정한다는 것을 그 경험에서 배웠습니다. 그 경험이 컴포넌트 설계를 먼저 고민하는 습관을 만들어주었습니다.
서비스를 배포하고 나서 모바일에서 페이지 로딩이 느리다는 피드백이 들어왔어요. 어디가 느린지 모르는 상태에서 무작정 코드를 바꾸기 시작했는데 별로 나아지지 않았습니다.
Lighthouse 점수를 처음 써봤어요. 무엇이 느린지 측정부터 하니까 이미지 용량이 가장 큰 문제라는 게 보였어요. 이미지를 WebP로 변환하고 레이지 로딩을 적용했더니 로딩 시간이 절반으로 줄었습니다. 측정 없이 바꾸던 때보다 훨씬 빠르게 효과가 났어요.
프론트엔드 성능 개선은 직관이 아니라 측정으로 시작해야 한다는 걸 그때 배웠어요. 측정 지표가 없으면 어디에 노력을 써야 하는지 알 수 없습니다. 그 경험이 성능 작업을 시작할 때 항상 먼저 측정하는 습관을 만들어줬어요.
팀 프로젝트를 발표하면서 키보드만으로 서비스를 사용할 수 있는지 테스트해봤는데, 모달을 닫을 방법이 키보드로는 없었어요. 마우스 없이는 불편한 부분이 여럿 발견됐습니다.
모달에 포커스 트랩을 추가하고 ESC 키로 닫히게 수정했어요. 폼 요소에 label을 연결하고, 색상만으로 구분되는 상태 표시에 아이콘을 추가했습니다. 수정이 생각보다 간단했는데, 처음부터 신경 쓰지 않았다는 게 아쉬웠어요.
접근성이 특별한 기능이 아니라 기본 마크업을 올바르게 쓰는 것에서 대부분 해결된다는 걸 그때 알았어요. 더 많은 사람이 서비스를 쓸 수 있게 만드는 것이 프론트엔드 기여의 한 방향이라고 생각합니다. 그 경험이 접근성을 기본으로 고려하는 계기가 됐어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.