좋은 UX 패턴은 좋은 컴포넌트 API로 이어진다

먼저 던질 질문

재사용 가능한 컴포넌트는 UX 상태를 어떻게 품어야 할까

핵심 관점

컴포넌트 API는 팀이 반복해서 내릴 UX 결정을 미리 담아두는 계약이다. 좋은 API는 올바른 사용을 쉽게 만들고 위험한 사용을 어렵게 만든다.

구현 품질로 이어지는 장면

Button 컴포넌트가 loading, disabled, icon, aria-label을 일관되게 다룬다.

Alert 컴포넌트가 severity와 action을 구분하고 적절한 role을 제공한다.

운영에서 깨지는 흐름

하나의 Card 컴포넌트에 너무 많은 optional props를 넣어 의도를 알기 어렵다.

이 경우 사용자는 화면의 의도를 스스로 추측해야 한다. UX가 나빠지는 순간은 대개 사용자가 다음 행동을 알 수 없을 때다.

접근성 속성을 매번 사용하는 쪽에서 직접 넣게 한다.

구현 사례와 근거

컴포넌트 API는 좋은 사용 방식을 유도해야 한다

좋은 컴포넌트는 스타일 재사용에서 끝나지 않는다. 올바른 라벨, 오류 연결, 포커스 처리, 비활성 상태, 로딩 상태를 자연스럽게 쓰게 해야 한다.

GOV.UK Design System의 컴포넌트 문서는 언제 쓰는지, 어떤 문구를 쓰는지, 어떤 옵션이 필요한지를 함께 제공한다. 이는 컴포넌트 API가 디자인 의사결정까지 담을 수 있다는 사례다.

실무 해석

FormField가 label, hint, error를 연결하지 않거나 Dialog가 포커스 복귀를 기본 제공하지 않으면 같은 접근성 버그가 제품 곳곳에서 반복된다. 좋은 API는 좋은 UX를 선택하기 쉽게 만든다.

구현 판단 기준

• 필수 접근성 정보를 props에서 빠뜨리지 않는다
• variant가 시각 차이인지 의미 차이인지 구분한다
• 상태별 예시를 문서에 포함한다

자주 빠지는 함정

너무 범용적인 컴포넌트는 재사용성이 높아 보이지만 의미가 흐려진다. 모든 것을 받을 수 있는 API는 올바른 사용법을 알려주지 못한다.

추가로 비교할 구현 사례

• Button, FormField, Alert, Dialog 컴포넌트 API를 비교한다
• 너무 범용적인 Card 컴포넌트의 문제를 찾는다
• 접근성 기본값이 있는 컴포넌트 라이브러리 사례를 모은다

구현 품질 질문

• props가 사용자의 상태를 제대로 표현하는가
• 접근성 요구가 opt-in이 아니라 기본값인가

출처

• GOV.UK Design System, Button: https://design-system.service.gov.uk/components/button/
• GOV.UK Design System, Error message: https://design-system.service.gov.uk/components/error-message/
• WAI-ARIA APG, Dialog Modal Pattern: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• W3C, Web Content Accessibility Guidelines WCAG 2.2: https://www.w3.org/TR/WCAG22/
• Microsoft Fluent 2 Design System: https://fluent2.microsoft.design/