라이브러리는 기능, 런타임, 타입, 유지 비용을 함께 통과해야 도입한다
기능이 좋아도 서버 컴포넌트와 맞지 않거나 번들을 크게 늘리면 비용이 커진다. 설치 전 확인 기준을 고정한다.
| 점검 축 | 확인 질문 | 좋은 신호 | 위험 신호 |
|---|---|---|---|
| 기능 적합성 | 현재 문제를 직접 줄이는가 | 보일러플레이트와 오류 처리가 줄어듦 | 단순 편의 함수 때문에 큰 의존성 추가 |
| 런타임 경계 | 서버/클라이언트/Edge 중 어디서 동작하는가 | Next.js App Router 사용 예시가 명확함 | 브라우저 API가 서버 코드에 섞임 |
| 타입·검증 | TypeScript와 런타임 검증을 지원하는가 | 타입 추론과 schema 공유가 가능함 | any 기반 adapter가 많음 |
| 번들 영향 | 클라이언트 JS가 얼마나 늘어나는가 | tree-shaking, dynamic import 가능 | 모든 페이지에 무거운 provider 강제 |
| 유지보수 | 업데이트와 생태계가 살아 있는가 | 최근 release, 문서, issue 대응 | Next.js 최신 버전 호환 이슈 방치 |