이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 웹 서비스 UI를 만들 때 데스크탑 기준으로만 개발했다가 모바일에서 레이아웃이 전부 깨지는 상황이 QA 직전에 발견됐습니다. 급하게 수정하느라 이틀을 추가로 썼습니다.
그 이후로 모바일 → 태블릿 → 데스크탑 순서로 먼저 작은 화면을 기준으로 설계하는 방식으로 바꿨습니다. CSS 브레이크포인트를 3단계로 나누고, 공통 컴포넌트는 크기에 독립적으로 동작하도록 %와 flex 기반으로 작성했습니다.
처음엔 작은 화면 기준으로 짜면 데스크탑이 이상해 보일 것 같았는데, 실제로 해보니 반대 방향보다 훨씬 일관성 있게 됐습니다. UI 일관성은 큰 화면을 줄이는 게 아니라 작은 화면을 확장하는 방향으로 설계해야 한다는 걸 그때 배웠습니다.
사이드 프로젝트에서 크로스플랫폼 앱을 만들 때, iOS에서 잘 됐던 날짜 포맷 처리가 안드로이드에서는 오류가 났습니다. 플랫폼마다 날짜 파싱 기본 동작이 달랐습니다.
날짜 처리를 공통 유틸 함수로 래핑하고, 플랫폼별 동작을 각 구현체에서 처리하도록 추상화했습니다. 이후 같은 유형의 문제가 생겨도 유틸만 수정하면 됐습니다. 처음엔 '빨리 고쳐야 하니 분기문으로 처리하자'는 유혹이 있었는데, 그렇게 하면 같은 문제가 10군데서 생긴다는 걸 알고 참았습니다.
다양한 환경 대응에서 분기 처리보다 공통 추상화가 장기적으로 덜 고통스럽다는 걸 그때 배웠습니다. 코드량이 처음엔 늘어 보여도 나중에 유지보수 비용이 확연히 달라진다는 것이 지금도 제 기준입니다.
인턴 때 모바일 앱 내 버튼, 인풋, 다이얼로그가 화면마다 조금씩 다른 스타일을 갖고 있었습니다. 디자이너와 논의하며 공통 컴포넌트 라이브러리를 만드는 작업을 맡았습니다.
기본 컴포넌트 12개를 props 기반으로 설계해 색상, 크기, 상태를 외부에서 주입하도록 만들었습니다. 처음엔 너무 일반화하려다가 컴포넌트가 50개가 넘는 props를 받게 되어 오히려 쓰기 어려워지는 문제가 생겼습니다. 자주 쓰는 조합을 preset으로 정의하고 나머지는 확장하는 방식으로 정리했습니다.
이후 신규 화면을 개발할 때 공통 컴포넌트를 쓰면 디자인 리뷰 피드백이 30% 줄었습니다. 일관성은 규칙이 아니라 공통 도구를 쓰기 쉽게 만드는 것에서 나온다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.