이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 대시보드의 차트가 모바일에서 잘려 보이는 문제가 있었습니다. PC에서만 테스트하다가 모바일 확인 직전에 발견했습니다. 차트 라이브러리 설정에서 너비를 고정값이 아니라 부모 컨테이너 기준 퍼센트로 변경하였습니다. 모바일에서는 범례를 차트 아래로 이동시키고, 툴팁을 손가락 터치 영역에 맞게 키웠습니다. 처음에는 반응형 처리를 나중에 해도 된다고 생각했지만, 이미 컴포넌트가 완성된 뒤에 바꾸는 것이 더 오래 걸렸습니다. 이후로는 차트 설계 시작부터 두 화면 크기를 동시에 고려하는 습관이 생겼습니다. 반응형 처리를 마지막에 미루면 처음부터 다시 설계하는 것보다 더 많은 시간이 걸리는 것을 경험하였습니다.
데이터 시각화 수업 과제에서 30개 항목 막대그래프를 모바일에 그대로 표시하려다 항목이 너무 작아 읽히지 않는 문제가 생겼어요. PC에서는 충분히 보였는데 모바일에서는 텍스트가 겹쳤습니다. 모바일에서는 상위 10개만 보여주고 더 보기 버튼으로 전체를 펼치는 방식으로 설계를 바꿨어요.
데이터 양이 같아도 화면에 맞게 보여주는 양을 다르게해야 한다는 걸 배웠습니다. PC와 모바일은 같은 데이터를 다른 방식으로 소화해야 한다는 걸 이 경험에서 알게 됐어요. PC와 모바일은 같은 데이터를 다른 방식으로 소화해야 한다는 걸 이 경험에서 알게 됐어요. 데이터 양보다 사용자가 한 화면에서 소화할 수 있는 양을 기준으로 설계하는 습관이 생겼습니다.
사이드 프로젝트에서 주가 차트를 모바일에서도 볼 수 있게 설계했어요. PC에서는 마우스 호버로 상세 데이터를 보여줬는데, 모바일에서는 호버 이벤트가 없어서 작동이 안 됐습니다. 터치 시 해당 날짜 데이터를 화면 상단에 고정 표시하는 방식으로 바꿨어요. 핀치 줌 기능도 추가했는데, 기본 브라우저 줌과 충돌해서 처음엔 오동작했습니다.
touch-action: none 설정으로 해결했어요. 인터랙션 방식이 디바이스마다 다르다는 걸 알고 각각에 맞게 다시 설계해야 한다는 걸 배웠습니다. 인터랙션 방식이 디바이스마다 다르다는 걸 알고 각각에 맞게 다시 설계해야 한다는 걸 배웠습니다. 모바일 차트는 기능을 옮기는 게 아니라 새로 설계하는 것이라는 생각이 생겼어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.