이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
디자인 시스템 구축 프로젝트를 처음 맡았을 때, 컴포넌트 명명 규칙을 팀 내에서 통일하지 못해 개발자가 다른 이름의 버튼을 세 가지 버전으로 구현하는 상황이 발생했습니다. 그때 '구조부터 잡아야겠다'는 것을 느끼고, Figma에 토큰 레이어를 먼저 정의하고 컴포넌트 명세 문서를 만들었습니다. 소통 방식도 슬랙 채널을 별도로 개설하여 변경 사항이 생기면 즉시 공유하였습니다. 중간에 디자인 토큰을 개발 코드에 동기화하는 과정에서 충돌이 발생했는데, 직접 개발자와 페어 세션을 잡아 함께 수정하면서 해결하였습니다. 그 경험 덕분에 디자인 시스템은 '문서'가 아니라 '협업 도구'라는 것을 배웠습니다. 지금도 그 구조를 기반으로 다음 프로젝트를 시작하고 있습니다.
팀 프로젝트에서 디자인 시스템을 운영하며 가장 힘들었던 건 '누가 이걸 쓸 것인가'에 대한 합의가 없었던 때예요. 제가 만든 버튼 컴포넌트를 팀원이 쓰지 않고 직접 스타일을 입혀 따로 만들었는데, 이유를 들어보니 '어디 있는지 몰랐다'는 거였어요. 그때부터 Notion에 컴포넌트 인덱스 페이지를 만들고, 신규 팀원 온보딩 때 디자인 시스템 소개를 15분씩 넣었습니다. 처음엔 부담스럽다는 반응도 있었지만, 한 달 뒤 '찾기 쉬워졌다'는 피드백을 받았어요. 직접 쓰는 사람이 늘었을 때 시스템이 살아있다는 느낌이 들었고, 그 이후 팀 내 중복 작업이 눈에 띄게 줄었습니다. 그 과정에서 온보딩 문서 작성이 얼마나 중요한지도 함께 배웠습니다.
디자인 시스템 설계를 처음 시도했을 때 지나치게 많은 컴포넌트를 한꺼번에 정의하려다 팀원들이 따라오지 못하는 상황이 생겼어요. 피드백 없이 혼자 앞서가다 보니 실제 서비스에 맞지 않는 컴포넌트가 늘어났고요. 이후엔 실제 화면 하나를 기준으로 쪼개는 방식으로 바꾸고, 매주 짧은 리뷰 시간을 팀원들과 가졌습니다. 속도는 느려졌지만 '이 컴포넌트가 왜 필요한지'를 모두가 이해하는 구조가 됐어요. 그 경험 이후로 디자인 시스템은 공감대부터라는 걸 더 중요하게 생각하게 됐고, 지금은 설계 전에 팀원과 먼저 스코프를 맞추는 시간을 꼭 갖습니다.
컴포넌트 공감대가 먼저 생기면 속도는 자연스럽게 따라온다고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.