이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 공통 UI 컴포넌트를 정리하는 작업을 맡았습니다. 팀원 4명이 같은 버튼, 같은 입력 폼을 제각각 구현하면서 스타일이 흩어지는 문제가 있었습니다. 저는 먼저 사용 빈도가 높은 컴포넌트 10개를 추려 재사용 가능한 형태로 분리했고, Props 인터페이스를 문서화해 팀원들이 바로 가져다 쓸 수 있게 했습니다. 이 과정에서 가장 신경 쓴 것은 컴포넌트가 너무 범용적이면 쓰기 불편하고, 너무 좁으면 재사용이 안 된다는 균형이었습니다. 실제로 초기 버전은 너무 많은 옵션을 노출해서 팀원들이 헷갈렸고, 주요 케이스 3개로 줄이고 나머지는 확장 방식으로 남기는 방향으로 수정했습니다. 이후 팀원들이 새 화면을 만들 때 컴포넌트를 조합해서 쓰는 비중이 높아졌고, 전체 UI 일관성이 개선됐다는 피드백을 받았습니다. 이 경험에서 좋은 설계는 쓰는 사람이 고민을 덜 하게 만드는 것이라는 기준이 생겼습니다.
디자인 시스템에서 색상, 간격, 타이포그래피를 디자인 토큰으로 정의한 경험이 있습니다. 팀마다 같은 색상을 다른 값으로 쓰는 문제가 있었고, 코드에서 #3a7bd5처럼 하드코딩된 값이 흩어져 있었습니다. 패턴 정의로는 의미 기반 토큰 이름(예: `color.primary.default`)을 정의하고, 코드와 디자인 도구 양쪽에 동일하게 반영하는 방식을 도입했습니다. 색상 값이 바뀔 때 토큰 하나만 수정하면 전체에 반영되는 구조입니다. 디자인 시스템 활용으로는 Figma의 Variables와 코드의 CSS 커스텀 프로퍼티를 동기화하는 방식으로 디자이너와 개발자가 같은 언어를 쓸 수 있게 했습니다. 프로젝트 결과로는 테마 전환 기능을 구현할 때 토큰 구조 덕분에 라이트/다크 모드를 추가할 때 컴포넌트 코드를 거의 수정하지 않아도 됐습니다. 협업으로는 디자이너가 Figma에서 토큰 이름을 맞춰주면, 개발자는 그 이름을 그대로 변수로 사용하는 방식으로 커뮤니케이션 비용이 줄었습니다.
토큰 설계는 컴포넌트보다 더 근본적인 디자인 시스템의 기반입니다.
팀 프로젝트에서 Storybook을 도입해 공통 컴포넌트를 시각적으로 공유하는 환경을 만든 경험이 있습니다. 컴포넌트가 코드에만 있으면 팀원이 무엇이 있는지 알기 어렵고, 직접 코드를 열어봐야 합니다. 재사용 패턴 정의로는 Button, Input, Modal 등 기본 컴포넌트를 Storybook에 등록하고, 각 컴포넌트의 사용 예시와 Props 설명을 함께 작성했습니다. 새 팀원이 Storybook만 보면 어떤 컴포넌트가 있는지 파악할 수 있도록 했습니다. 디자인 시스템 활용으로는 각 컴포넌트의 변형(variant)을 Storybook에서 시각적으로 비교할 수 있게 했습니다. 버튼의 Primary, Secondary, Disabled 상태를 한눈에 볼 수 있으면 잘못 쓰는 경우가 줄어듭니다. 프로젝트 결과로는 새 화면을 추가할 때 컴포넌트를 새로 만드는 경우가 줄고, Storybook에서 가져다 쓰는 비중이 높아졌습니다. UI 일관성이 자연스럽게 유지됐습니다. 협업으로는 디자이너가 Figma에서 만든 컴포넌트와 Storybook의 구현을 비교하면서 차이가 있는 부분을 피드백하는 방식으로 협업 사이클이 만들어졌습니다.
디자인 시스템은 문서가 아니라 팀이 실제로 쓰는 공유 언어입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.