라이브러리 책임과 교체 비용

문제 정의

디자인 시스템, HTTP 재시도, 날짜대, 폼 검증처럼 해결하려는 문제를 먼저 좁힙니다.

need

라이브러리가 제공하는 범위가 필요한 만큼인지, 반대로 애플리케이션 구조를 과하게 바꾸는지 봅니다.

범위

유지보수 빈도, 타입 지원, 보안 이슈 대응, SSR 호환성, 번들 크기를 실제 환경에서 확인합니다.

risk

앱 전역으로 직접 퍼질 API인지, 작은 adapter 뒤에 숨길 수 있는지에 따라 교체 비용이 달라집니다.

경계

UI 라이브러리

컴포넌트 품질과 접근성이 핵심 디자인 커스터마이징, keyboard navigation, theme 시스템을 함께 검토합니다.

HTTP 클라이언트

요청 인터셉터, 취소, 오류 표준화가 필요한지 확인 단순 요청이면 fetch wrapper로도 충분할 수 있습니다.

network

날짜 라이브러리

timezone, locale, formatting 범위를 먼저 봄 Date 객체만으로 해결하기 어려운 달력 규칙이 있으면 도입 근거가 분명해집니다.

time

사용 지점 라이브러리 API가 퍼질 위치를 예상해 교체 가능한 경계를 둡니다.

번들 영향 도입 전후 bundle analyzer나 coverage로 실제 비용을 확인합니다.

접근성 UI 컴포넌트는 보기보다 키보드와 스크린리더 동작이 품질을 가릅니다.

도입 전 확인:
- 지금 직접 구현하면 어떤 위험이 있는가
- 라이브러리가 그 위험을 실제로 줄이는가
- 1년 뒤 교체 비용은 어디에서 생기는가