이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
디자인 시스템을 구축할 때 컴포넌트 추상화 수준을 정하는 것이 가장 중요한 첫 결정이라고 생각합니다. 너무 세분화하면 관리 비용이 커지고, 너무 뭉뚱그리면 재사용이 어려워집니다. 베이스 컴포넌트를 먼저 확정하고 그 위에 변형을 쌓는 방식으로 접근하면 확장이 수월했습니다.
명명 규칙을 팀 전체가 따르도록 초기에 합의하는 것도 중요한데, 이름이 통일돼야 컴포넌트 찾는 시간이 줄어듭니다. 예시 중심 문서화가 이론 설명보다 훨씬 빠르게 팀에 정착되는 걸 경험했고, 실제로 어떻게 쓰이는지를 먼저 보여주는 방식이 효과적이었습니다. 디자인 시스템은 만들어두면 끝이 아니라 팀이 계속 사용하고 기여할 수 있는 구조를 갖춰야 살아있는 시스템이 된다는 걸 배웠습니다.
디자인 시스템을 구축하면서 직접 주도한 결정 중 가장 영향이 컸던 것은 디자인 토큰 구조를 시맨틱 계층으로 분리한 것이었습니다. 색상을 원시 값으로 쓰던 방식에서 `color.primary.default`처럼 역할 기반으로 이름을 붙이는 시맨틱 토큰 계층으로 전환하면서, 테마를 바꿀 때 컴포넌트를 건드리지 않아도 됐습니다.
Storybook을 설정하고 각 컴포넌트에 사용 예시와 금지 케이스를 직접 작성했는데, 이 문서가 생긴 뒤로 팀원들이 컴포넌트 사용 방법을 따로 묻는 빈도가 줄었습니다. 컴포넌트를 추가할 때 누가 리뷰하고 어떻게 릴리즈하는지 기여 프로세스(Governance)를 문서화한 것도 직접 했습니다. 구조를 짜는 것보다 팀이 시스템을 계속 사용하고 기여하게 만드는 것이 더 어렵다는 걸 그때 배웠습니다. 시스템은 쓰이지 않으면 유지되지 않습니다.
디자인 시스템이 실제로 효과가 있는지를 수치로 확인하지 않으면 지속적인 투자를 설득하기 어렵다는 것을 배웠습니다. 시스템 도입 이후 디자인-개발 핸드오프 단계에서 스타일 재확인 질문이 현저히 줄어드는 것을 체감했고, 릴리즈 후 UI 관련 버그 수도 이전 스프린트 대비 줄었습니다.
정확한 수치를 기록하지 않아 공식 리포트로 만들기는 어려웠지만, 속도 향상이 체감될 만큼 명확했습니다. 설계-구현 1:1 대응 — 컴포넌트 Variant·Size·State를 설계 단계에서 정의해두면 개발자가 자체 판단으로 처리하는 케이스가 줄었습니다.
디자인 시스템의 ROI를 핸드오프 절감·버그 감소·팀 속도 향상으로 정의하고 측정 기준을 미리 정해두는 것이 다음에 또 한다면 처음부터 하고 싶은 것입니다. 시스템은 비용보다 절감이 큰지를 보여줄 수 있어야 살아남습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 PTKOREA UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.