Why Library?

이 문서는 전환 가이드를 읽기 전에 먼저 보는 입문 맵입니다. 목표는 라이브러리의 문법을 다 알려주기보다, 어떤 문제를 해결하려고 쓰이는지 먼저 잡고 다음 문서로 넘어가는 것입니다.

이 문서의 역할

• 개별 라이브러리를 문제 해결 맵 중심으로 정리
• 복잡한 API 상세는 각 트랙/주제 문서에서 다루기
• 새 기능을 시작할 때 “무슨 문제를 먼저 해결할지”를 빠르게 정렬하기

현재 다루는 6개 트랙

1) 스타일 트랙: Tailwind CSS

• 해결 포인트: 브라우저 렌더에서 클래스 충돌·우선순위 충돌·스코프 오염이 생겨 UI 예측성이 낮아지는 문제
• 핵심 질문: “스타일 적용 경로를 CSS 파일, css-in-JS, util 클래스 중 어디에 두느냐에 따라 렌더/디버깅 비용이 어떻게 달라지는가?”
• 연계 가이드: web 트랙에서 렌더링/번들링/스타일 적용 단계를 함께 보면, Tailwind를 포함한 접근 방식(css-in-css, css-in-js 대비)의 장단점이 분명해짐

2) 렌더 트랙: React

• 해결 포인트: 상태 변경과 렌더 반영 시점의 불일치, 이벤트 경로에서의 오래된 상태 반영
• 핵심 질문: “왜 데이터는 바뀌었는데 UI는 늦게 또는 엉뚱하게 바뀌는가?”
• 연계 가이드: react 트랙에서 렌더/상태 흐름을 잡으면, 상태·데이터·폼 이슈를 어디서 끊어야 할지 기준이 선명해짐

3) 데이터 트랙: TanStack Query

• 해결 포인트: API 호출 상태 분기, 캐시, stale 데이터, 동시 요청 관리
• 핵심 질문: “동일한 요청이 겹치거나, 응답 타이밍이 UI와 어긋나는 문제가 생기는가?”
• 연계 가이드: TanStack Query 트랙과 react 트랙을 같이 보면, 요청 캐시/동시성/무효화의 실제 경계를 함께 정리할 수 있음

4) 상태 트랙: Zustand, React Context

• 해결 포인트: props drilling, 상태 공유, 잦은 리렌더
• 핵심 질문: “어디에서 상태가 필요한지 불분명해 추적이 어려운 문제가 생기는가?”
• 연계 가이드: 상태 트랙 - Zustand, React Context와 react 트랙에서 렌더/상태 전이 구조를 같이 보면, 상태 공유 구역을 나눠서 문제 지점을 먼저 잡기 쉬움

5) 프레임워크 트랙: Next.js

• 해결 포인트: SSR/CSR 경계에서 생기는 초기 렌더 미스매치, 라우트 전환 시 상태/데이터 초기화 불일치
• 핵심 질문: “이 화면은 언제 렌더되어야 하고, 누가 어떤 시점에 데이터를 주입해야 하는가?”
• 연계 가이드: Next.js 트랙에서 먼저 큰그림을 잡고, web 트랙에서 라우팅/진입점 세부를 이어서 확인하면 전체가 선명해집니다.

6) 런타임 검증 트랙: Zod

• 해결 포인트: 정적 타입은 커버하지 못한 외부 경계(응답/요청) 검증
• 핵심 질문: “컴파일 이전/이후 경계에서 계약 위반이 누구의 책임으로 남는가?”
• 연계 가이드: 런타임 검증 트랙으로 타입 트랙의 합/곱 분해를 런타임 계약에 연결하면, 타입 추적과 오류 경계가 한 번에 정리됩니다.

한 줄 규칙

라이브러리는 기능보다 문제 해결 도구로 사용한다. 이 라이브러리가 어떤 문제를 대신 해결하는지 먼저 적고 시작한다.