이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 공통 UI 컴포넌트 라이브러리를 처음 만들었습니다. 버튼과 입력창을 여러 페이지에서 각자 만들다 보니 스타일이 제각각이어서 디자인 시스템 도입을 결정했습니다. 디자인 토큰을 CSS 변수로 먼저 정의하고 색상·간격·폰트 크기를 하나의 파일에 집중시켰습니다. 컴포넌트는 size와 variant props로 변형을 제어하도록 만들어서 새로운 디자인이 생겨도 코드 수정 없이 값만 바꾸면 되게 했습니다. 문서화는 Storybook으로 구성했고, 각 컴포넌트의 케이스를 눈으로 확인할 수 있어 디자이너와 협의하는 데 실질적으로 도움됐습니다. 버전 관리는 패키지로 분리해 semver 규칙을 따랐는데, 어디까지를 breaking change로 볼지 기준을 팀이 미리 정해두는 게 중요하다는 걸 배웠습니다.
컴포넌트 라이브러리를 만들고 나서 아무도 적극적으로 쓰지 않는 상황이 생겼습니다. 존재는 알지만 어떻게 기여하고 어떤 props를 쓰면 되는지 팀원들이 물어보는 경우가 많았습니다. Storybook에 컴포넌트가 올라가 있었지만 'props를 어떻게 조합하면 되는지'가 빠져 있었습니다.
기여 가이드 문서를 만들어서 ① 새 컴포넌트 추가 기준 ② props 명명 규칙 ③ 변경 시 버전 올리는 방법을 한 페이지로 정리했습니다. 그 이후 팀원이 컴포넌트를 추가하거나 수정할 때 저에게 먼저 물어보지 않고 문서를 보고 PR을 올리는 경우가 생겼습니다.
라이브러리는 만드는 것보다 팀이 쓰게 만드는 것이 더 어렵다는 것을 이 경험에서 배웠습니다. 확산이 없으면 공통 컴포넌트는 유지보수자만 아는 코드가 됩니다.
컴포넌트 라이브러리를 처음 만들 때 접근성을 나중에 추가하면 된다고 생각했습니다. 색상 토큰을 먼저 정하고 컴포넌트를 만들었는데, 나중에 명도 비율 기준인 WCAG AA를 확인해보니 기본 회색 계열 버튼이 기준을 통과하지 못했습니다. 토큰 값 하나를 바꾸면 이를 참조하는 컴포넌트 전체에 영향이 가서 전체 컴포넌트를 다시 확인해야 하는 상황이 생겼습니다. 이후에는 색상 토큰을 정의할 때 명도 비율을 함께 기록하고, ARIA 속성도 컴포넌트 기본값으로 포함시키는 방식을 택했습니다.
접근성은 나중에 추가하는 것이 아니라 토큰 설계 단계에서 기준을 박아두어야 수정 비용이 낮다는 걸 이 경험에서 배웠습니다. 재사용 컴포넌트는 처음 설계가 이후 모든 화면의 기준이 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.