이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 재사용 가능한 UI 컴포넌트 라이브러리를 직접 구축한 경험이 있습니다. 여러 페이지에서 같은 버튼과 모달이 각자 구현돼 있어 스타일이 제각각인 문제가 있었고, 공통 컴포넌트로 분리하기로 결정했습니다. 디자인 토큰을 CSS 변수로 정의해 색상, 간격, 타이포그래피를 한 곳에서 관리하도록 했고, 이후 디자인 변경 시 전체 컴포넌트에 일관되게 반영됐습니다.
Props 인터페이스 설계가 가장 많은 고민이 필요했는데, 너무 범용적으로 만들면 사용이 복잡해지고 너무 좁히면 변형이 필요할 때마다 새 컴포넌트를 만들어야 했습니다. Storybook으로 컴포넌트를 문서화하니 팀원들이 어떤 컴포넌트가 있는지 빠르게 파악하고 중복 구현이 줄었습니다. 컴포넌트 라이브러리는 설계보다 유지 기준을 팀이 합의하는 것이 더 오래 가는 결이었습니다.
UI 컴포넌트 라이브러리를 만들고 나서 실제로 효과가 있었는지 확인하고 싶었습니다. 팀원에게 신규 페이지를 만들 때 공통 컴포넌트를 썼을 때와 쓰지 않았을 때의 차이를 물어봤습니다. 공통 컴포넌트를 쓰면 레이아웃 잡는 시간이 크게 줄었다고 했고, 비슷한 페이지를 만드는 데 이전보다 절반 정도 시간이 걸린다는 이야기를 들었습니다. 또한 Storybook을 통해 중복 구현을 얼마나 줄였는지 확인했더니, 같은 컴포넌트를 다시 만들려는 PR이 리뷰에서 걸리는 경우가 이전보다 줄었습니다. 수치가 완벽하지는 않았지만, 팀이 공통 컴포넌트를 적극적으로 쓰는 방향으로 행동이 바뀐 것이 가장 큰 효과였습니다. 라이브러리는 사용됐을 때 비로소 가치가 생기는 결이라는 것을 이 경험에서 배웠습니다.
UI 컴포넌트를 재사용 가능하게 만들면서 Props 인터페이스 설계가 가장 어려웠습니다. Button 컴포넌트 하나만 해도 크기·색상·아이콘 유무·비활성화 상태 등 다양한 경우가 있었습니다. 처음에는 모든 케이스를 커버하려다 Props가 20개가 넘어가는 결이 됐습니다. 쓰는 사람 입장에서 어떤 Props가 진짜 필요한지를 기준으로 다시 정리했습니다.
실제 사용 케이스 5가지를 먼저 나열하고, 그 케이스를 커버하는 최소 인터페이스를 설계했습니다. 이 방식으로 줄이니 13개에서 7개로 줄었고, 팀원이 컴포넌트를 쓸 때 문서를 오래 읽지 않아도 바로 쓸 수 있게 됐습니다. API 설계는 만드는 사람이 아니라 쓰는 사람 기준으로 해야 하는 결이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.