이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
처음 반응형 웹을 만들 때 데스크탑에서는 잘 되었지만 모바일에서 레이아웃이 깨지는 것을 나중에 발견하였습니다. 처음부터 모바일을 고려하지 않고 만든 결과였습니다.
그 이후로는 모바일 퍼스트 방식으로 작은 화면 기준으로 먼저 설계하고 미디어 쿼리로 큰 화면을 추가하는 순서로 바꾸었습니다. 터치 인터랙션도 데스크탑의 호버 효과와 달리 처리해야 한다는 것을 배웠습니다. hover 효과만 있던 메뉴가 모바일에서 아무 반응도 하지 않았던 경험이 기억에 남습니다.
모바일과 데스크탑은 입력 방식부터 다르기 때문에 스타일뿐만 아니라 인터랙션 전체를 다르게 생각해야 한다는 것을 그 경험에서 배웠습니다. 화면 크기만 조절하는 것이 반응형이 아니라는 것도요. 그 경험 덕분에 한 단계 성장할 수 있었습니다.
팀 프로젝트에서 웹 버전으로 먼저 만든 대시보드를 모바일에서도 보기 좋게 해달라는 요청을 받았어요. 그냥 화면만 줄였더니 텍스트가 너무 작고 버튼이 손으로 누르기 어려웠습니다.
모바일용으로 다시 설계할 때 터치 타겟 크기를 최소 44px 이상으로 잡고, 한 화면에 보여주는 정보량을 데스크탑의 절반 수준으로 줄였어요. 데스크탑에서는 사이드바로 보이던 필터가 모바일에서는 바텀 시트로 바뀌었고요. 처음엔 같은 기능인데 UI가 너무 다르다는 생각이 들었는데, 사용 맥락이 다르면 UI도 달라야 한다는 걸 이해했습니다.
플랫폼에 맞는 스타일이 따로 있고, 하나를 다른 것에 맞추려 하면 둘 다 어색해진다는 걸 그 경험에서 배웠어요. 그 경험이 플랫폼별로 다르게 생각하는 습관을 만들어줬어요.
리액트 네이티브로 앱을 처음 만들어봤을 때 CSS 대신 StyleSheet를 쓰는 방식이 낯설었어요. 웹에서 쓰던 display: flex는 작동했지만 margin: auto나 percentage 단위는 다르게 동작해서 처음엔 헷갈렸습니다.
웹은 브라우저가 레이아웃 계산을 해주지만 네이티브 앱은 플랫폼 렌더링 엔진이 다르다는 걸 이해하면서 차이가 납득됐어요. 모바일 앱에서는 픽셀 단위보다 Dimensions 기반의 비율 계산을 더 많이 쓰고, 폰트 크기도 화면 DPI에 따라 다르게 적용됩니다.
처음 실수를 여러 번 겪고 나서 이해한 거라 더 기억에 남아요.
두 환경의 차이를 알면 같은 시각 결과를 내더라도 접근 방식이 달라야 한다는 걸 알게 됐어요. 웹 스타일 지식이 완전히 새로 시작하는 것보다 빠르지만, 차이점을 모르면 오히려 실수가 더 생긴다는 것도요. 그 경험이 플랫폼 차이를 먼저 확인하는 습관을 만들어줬어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.