React 생태계 변화를 맥락으로 읽기

리액트 생태계는 왜 이렇게 변했나

— 2016~2022, 유행이 아니라 ‘문제 해결의 연쇄’로 읽기

---

서론: 기술 선택을 맥락 없이 하면 항상 늦는다

Next.js, TanStack Query, TypeScript는 “요즘 쓰는 도구”가 아니다.
이들은 React가 해결하지 못했던 반복적 문제들에 대한 집단적 답이다.

이 글의 목표는 연표 암기가 아니다.
어떤 문제가 있었고 → 어떤 선택이 나왔고 → 그 선택의 비용은 무엇이었는지를 통해
지금의 기술 스택을 의사결정 프레임으로 이해하게 만드는 것이다.

---

1) import React가 사라진 이유: 문법 변화가 아니라 인식 변화

핵심 문제

JSX를 쓰기 위해 매 파일마다 import React가 필요했다.
이는 런타임 의존과 문법 의존을 혼동한 결과였다.

전환의 의미

• JSX는 React 객체를 직접 쓰는 문법이 아니다
• 컴파일 타임 변환으로 충분하다는 합의가 생겼다
• React는 “필수 글로벌”이 아니라 선택적 런타임으로 내려왔다

실무 체크리스트

• JSX가 무엇으로 변환되는지 설명할 수 있는가
• 번들러/컴파일러 책임과 런타임 책임을 구분하는가
• 프레임워크 의존을 “자동으로 필요한 것”으로 오해하지 않는가
• 설정이 줄어든 이유를 생산성 관점에서 이해하는가
• 최신 문법을 쓸 때 하위 호환 비용을 고려하는가
• 코드에 남아 있는 관성적 import를 점검하는가

---

2) 디렉터리 구조는 취향이 아니라 비용 구조다

핵심 문제

프로젝트가 커질수록 “파일을 어디서 고쳐야 하는지”가 불명확해졌다.

전환의 의미

• 구조는 가독성 문제가 아니라 변경 비용 문제
• 레이어 기준은 이해는 쉽지만 변경에 약하다
• 도메인/기능 기준은 초기 비용이 있지만 확장에 강하다

실무 체크리스트

• 변경 요청이 왔을 때 수정 파일이 즉시 떠오르는가
• 폴더 구조가 역할/도메인을 드러내는가
• 공통 폴더가 무분별하게 커지고 있지 않은가
• 구조 변경이 리팩터링을 방해하지 않는가
• 팀 합의 없는 구조 확장이 일어나지 않는가
• “작을 때 좋은 구조”를 그대로 유지하고 있지 않은가

---

3) SPA 새로고침의 본질: 기술 문제가 아니라 상태 모델 문제

핵심 문제

SPA에서 새로고침 시:

• 인증이 풀린다
• 상태가 날아간다
• 화면이 깨진다

이는 버그가 아니라 설계 전제의 붕괴다.

전환의 의미

• 새로고침은 “비정상 상황”이 아니다
• 모든 상태는 초기화 가능해야 한다
• 서버/클라이언트 경계를 명확히 나눠야 한다

실무 체크리스트

• 새로고침 시 반드시 유지돼야 할 상태는 무엇인가
• 그 상태의 소스는 서버/스토리지 중 어디인가
• 클라이언트 상태를 과신하고 있지 않은가
• 인증/권한은 초기 진입 시 재검증되는가
• URL이 화면 상태를 충분히 설명하는가
• “SPA라서”를 핑계로 상태 복구를 미루지 않는가

---

4) Primitive UI: 디자인 시스템의 출발점 재정의

핵심 문제

컴포넌트를 재사용했지만:

• 변형이 어렵고
• 케이스가 늘어날수록 깨진다

전환의 의미

• 재사용의 단위는 “완성 UI”가 아니라 Primitive
• 스타일이 아니라 행동/접근성/상태를 재사용
• Button, Input은 결과가 아니라 출발점

실무 체크리스트

• UI 재사용이 스타일 복사에 그치지 않는가
• 상태/접근성 규칙이 컴포넌트에 캡슐화돼 있는가
• 변형은 props가 아니라 구조로 해결되는가
• Composite 이전에 Primitive가 정의돼 있는가
• 디자인 시스템이 코드 사용을 강제하는가
• UI 변경 비용이 점점 줄고 있는가

---

5) 2016~2022: 변곡점으로 읽는 리액트 생태계

① 데이터 축

• 문제: 전역 상태/비동기 혼재
• 해결: Redux → Query 계열
• 교훈: 서버 상태와 클라이언트 상태는 다르다

② 렌더링 축

• 문제: SEO/초기 로딩
• 해결: Next.js, SSR/SSG
• 교훈: 렌더링 전략은 앱 성격의 문제다

③ 타입 축

• 문제: 규모 커질수록 런타임 오류
• 해결: TypeScript 표준화
• 교훈: 타입은 생산성 도구다

④ UI 축

• 문제: 스타일/상태/조직 확장
• 해결: CSS-in-JS 논쟁, 디자인 시스템
• 교훈: UI는 기술보다 팀 문제다

실무 체크리스트

• 상태를 서버/클라이언트로 구분하고 있는가
• 렌더링 전략을 “기본값”으로 선택하지 않는가
• 타입 도입을 학습 비용이 아닌 유지비 절감으로 보는가
• UI 문제를 라이브러리로만 해결하려 하지 않는가
• 각 선택의 부작용을 인지하고 있는가
• “왜 이 도구를 쓰는지” 설명 가능한가

---

결론: 지금 초보자가 가져가야 할 것

도구를 더 배우기 전에, 판단 기준부터 가져가라.

1. 상태는 성격별로 분리한다 (서버 vs 클라이언트)
2. 구조는 변경 비용으로 판단한다
3. 새로고침을 정상 시나리오로 설계한다
4. UI는 Primitive부터 쌓는다
5. 기술은 문제의 답으로 선택한다

React 생태계는 빠르다.
하지만 맥락 없이 따라가면 항상 뒤처진다.
이제는 “무엇을 쓰는가”보다
“왜 그 선택이 나왔는가”를 설명할 수 있어야 한다.

---

• 참고: 클린코드 리액트(React)