React는 어려운 부분이 아니라, 변화를 위한 설계가 어렵다

Source: Dev.to

Introduction

대부분의 React 튜토리얼은 훅을 어떻게 사용하는지 가르칩니다. React 안에서 사고하는 방법을 가르치는 경우는 드뭅니다.
실제 프로젝트에서 React 애플리케이션을 만들고 유지보수하면서 가장 어려운 부분은 컴포넌트를 작성하는 것이 아니라, 6개월 뒤에 여러분을 방해하지 않는 시스템을 설계하는 것이라는 것을 깨달았습니다.
이 글은 문법에 관한 것이 아니라, 마인드셋에 관한 이야기입니다.

Components Are Contracts, Not Just UI

컴포넌트를 설계할 때 저는 그것을 계약이라고 생각합니다:

• 무엇을 약속하나요?
• 무엇을 의도적으로 하지 않나요?
• 오용하기가 얼마나 어려운가요?

복합 컴포넌트와 같은 패턴은 사용을 자연스럽게 안내해 주기 때문에 존재합니다.

// Example placeholder for a compound component pattern

이것은 영리한 트릭이 아니라 방어적인 설계입니다. 오용을 제한하면서도 유연성을 유지합니다.

State Is a Liability

상태(state) 하나마다 비용이 듭니다:

• 더 많은 재렌더링
• 더 많은 엣지 케이스
• 더 많은 버그

경험 법칙: 상태를 유도할 수 있다면 저장하지 마세요.

useEffect를 바로 쓰기 전에 스스로에게 물어보세요:

• 이것을 계산할 수 있나요?
• 사용되는 곳에 더 가깝게 둘 수 있나요?
• 훅으로 옮길 수 있나요?

Custom Hooks Are How You Tell a Story

훅은 재사용을 위한 도구일 뿐만 아니라 의미를 전달하는 수단입니다.

// Low‑level
useEffect(() => { /* ... */ }, []);

// High‑level
useUserSession();

두 번째 예는 미래의 개발자에게 왜 존재하는지, 단순히 어떻게 동작하는지가 아니라 이유를 알려줍니다. 좋은 훅은 문장처럼 읽혀야 합니다.

Hook Best Practices

• 조기에 useMemo를 사용하지 마세요.
• 더 단순한 컴포넌트 경계를 선호하세요.
• 컴포넌트를 작게 유지하고, 명확한 책임과 적은 props를 가집니다.
• 설계가 개선되면 성능 문제는 대부분 사라집니다.

useEffect가 영리하게 느껴진다면, 아마도 잘못된 것입니다. 효과는 다음과 같아야 합니다:

• 작고
• 예측 가능하며
• 삭제하기 쉬운

복잡한 로직은 훅이나 서비스 레이어에 두어야 합니다.

Folder Structure Reflects System Thinking

기술적인 관점이 아니라 기능(feature) 단위로 조직하면 코드베이스가 더 유연해집니다.

features/
  auth/
  billing/
  dashboard/

기능은 함께 변하기 때문에, 같은 폴더에 함께 두어야 합니다.

Goal

내 목표는 “고급 React” 코드를 쓰는 것이 아닙니다. 목표는 다음을 만족하는 코드를 쓰는 것입니다:

• 스스로를 설명한다
• 변화에 견딘다
• 다음 기능을 더 쉽게 만든다 (어렵게 만들지 않는다)

React는 도구를 제공합니다. 설계가 그 도구들을 제대로 작동하게 합니다.