ChatGPT 로 React 상태 관리 공부해보기

동료분이 공유주신 XL8 배휘동님의 세미나 공유용 PPT 를 보고, 상태 관리 관련해서 내가 어느 정도 알고 있는지 모르는 건 없는지 보고 싶은마음에 ChatGPT 를 이용해서 공부를 해봤다. 우선 아래는 4개의 이미지를 붙여넣고 예시 코드를 달라고 해서 정리한 내용.

 

정리한 내용

useState 수련생

• useState 사용해 상태 업데이트
• props 전달 위주로 구성
• 간단한 이벤트 처리

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

 

의사결정 포인트

• "이건 상태로 관리해야 해?"
• "그냥 변수여도 되는 거 아닌가?"

자주 겪는 문제

• 불필요한 상태 선언
• 동기/비동기 상태 업데이트 개념 부족
• props vs state 혼동

 

Props & 상태 탐색가

• 상태 끌어올리기 (lifting state)
• 컴포넌트 간 상태 공유 고민
• 복잡한 이벤트 조합 처리

function Parent() {
  const [name, setName] = useState("");

  return (
    <div>
      <Input name={name} onChange={setName} />
      <Preview name={name} />
    </div>
  );
}

function Input({ name, onChange }: { name: string; onChange: (v: string) => void }) {
  return <input value={name} onChange={(e) => onChange(e.target.value)} />;
}

function Preview({ name }: { name: string }) {
  return <p>Preview: {name}</p>;
}

 

의사결정 포인트

• "이 상태는 어디에 있어야 할까?"
• "Props로 줄까, Context로 공유할까?"

자주 겪는 문제

• 과도한 props drilling
• 리렌더링 병목 발생
• 컴포넌트 간 경계 불분명

 

상태 흐름 설계자

• Context, useReducer 사용 시작
• 상태 흐름 구조화
• memo, useMemo, useCallback 시작

const CounterContext = React.createContext(null);

function CounterProvider({ children }) {
  const [count, dispatch] = useReducer((state, action) => {
    switch (action.type) {
      case 'INC':
        return state + 1;
      default:
        return state;
    }
  }, 0);

  return (
    <CounterContext.Provider value={{ count, dispatch }}>
      {children}
    </CounterContext.Provider>
  );
}

function Child() {
  const { count, dispatch } = useContext(CounterContext);
  return (
    <button onClick={() => dispatch({ type: 'INC' })}>
      {count}
    </button>
  );
}

 

의사결정 포인트

• "Prop drilling이 너무 심해. Context로 풀까?"
• "이건 복잡한 로직이니 useReducer 써야 할까?"

자주 겪는 문제

• 성급한 성능 최적화 (memo 남용)
• Context 남용 (전역처럼 사용)
• 로컬로 충분한 상태도 전역화

 

기본기 마스터

• 모든 상태 관리 도구 숙련 (useState, useReducer, Context, Recoil, Zustand 등)
• 목적에 맞는 도구 선택
• 성능 최적화, 리팩토링 설계 능력

// 상태를 slice별로 쪼개서 useContext, useMemo, useReducer 조합
// 또는 필요에 따라 Zustand 등의 외부 상태 라이브러리 활용

// ex: Zustand
import { create } from 'zustand';

const useStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
}));

function Profile() {
  const user = useStore((state) => state.user);
  const setUser = useStore((state) => state.setUser);

  return (
    <div>
      <p>{user?.name}</p>
      <button onClick={() => setUser({ name: '렛시' })}>Set User</button>
    </div>
  );
}

 

의사결정 포인트

• "어떤 접근 방식이 이 시나리오에 가장 적절한가?"
• "지금 memoization은 실질적인 이득이 있는가?"
• "유지보수성과 성능 사이에서 최적 구조는?"

자주 겪는 문제

• 오버엔지니어링
• 상태 구조/결정 문서화 부족

---

이제 이 내용을 바탕으로 문제를 내달라고 부탁했다.

🧩 문제: 유저 대시보드 앱

너는 대시보드 화면을 개발 중이야. 구조는 아래와 같아:

<Dashboard>
├── <UserProfile />         // 유저 이름, 프로필 이미지
├── <UserStats />           // 유저 포인트, 활동 통계 등
└── <UserPosts />           // 유저가 작성한 게시글 리스트
       └── <PostItem />     // 각각의 게시글 (좋아요, 댓글 등 포함)

 

📍 조건

1. 페이지에 진입하면 /api/me 에서 유저 정보(id, name, profileImage)를 fetch해서 사용함.
2. /api/posts?userId=xxx 에서 해당 유저의 게시글 목록을 fetch.
3. UserProfile, UserStats, UserPosts는 각각 별도 파일로 분리된 컴포넌트.
4. PostItem에서 유저 이름을 표시할 일이 있다. (작성자: 렛시 이런 느낌)

❓질문: 상태를 어떻게 관리하는 게 가장 효율적일까?

• 유저 정보 상태와 게시글 상태를 어디서 관리할래?
• 어떤 상태 관리 도구를 쓸래? (useState, Context, 외부 라이브러리 등 중 선택)
• 어떤 방식이 성능, 유지보수, 재사용 측면에서 효율적이라고 생각해?

📥 네가 답할 때 참고하면 좋은 포인트

• "User 정보는 자주 바뀌지 않아" → 어떤 상태 관리 전략이 적합할까?
• "PostItem까지 유저 이름이 필요해" → props로 넘길지, 전역 상태로 둘지?
• "컴포넌트가 서로 다른 파일에 흩어져 있어" → 정보 공유는 어떻게?

---

이 문제를 보고 적어본 나의 답변

1. 유저 정보 상태와 게시글 상태를 어디서 관리할래?

게시물 리스트에서 api 호출 시 userId 가 필요하기 때문에, 유저 정보는 Dashboard 컴포넌트에서 UserContextProvider 를 만들어서 사용하면 좋을 것 같아. 유저 정보를 받아오는 건 인증이 필요해서 쿠키에 담긴 인증정보를 사용할 것으로 예상되는데, ServerSide Rendering 을 통해서 들어오는 요청의 브라우저 req.headers 를 참조해서 미리 유저 정보를 받아둘 수 있으면 다른 api 들을 호출하거나 ui 를 구성하는데에 걸리는 요소가 없을거야. 유저 정보는 유저의 인터랙션에 의해 쉽게 변하는 정보도 아니기 때문에 상위 컴포넌트의 Context 로 구성해도 크게 문제 되지 않을 것 같아.

게시글 상태는 UserPosts 에서 다룰 것 같아. 다른 컴포넌트와는 상관이 없어서. 각각의 게시글을 나타내는 PostItem 이 props 로 게시글 관련 정보를 내려받는 구조가 될 거 같아. depth 가 한번 타고들어가는거라 props driling도 심하지 않아. 다만, PostItem 에서 좋아요, 댓글 을 눌러서 게시글의 정보를 업데이트 해야 할 때, api 를 요청하고 시간이 걸리니까 낙관적 업데이트를 하는게 좋을 것 같아서 게시글 각각에서 내려받은 좋아요나 댓글 정보를 state 의 initial 값으로 받아서 표시하고, 인터랙션 후에는 즉시 state 를 업데이트하고 api 를 요청하는 식으로 구현할거야. api 의 응답이 오면 이 state 를 유지할 지 / 오류를 표시할 지 결정해야 할 것 같아. 만약 react-query 같은 도구를 사용하고 있으면, 낙관적 업데이트로 하지 않고 게시글 리스트를 불러오는 api 를 호출하는 곳에서 사용하는 key 를 가지고 좋아요나 댓글 상태를 특정 id 의 게시글에서 업데이트 하는 방식을 적용할 수도 있을 것 같아. 뭐가 좋을지 고민이네.

 

2. 어떤 상태 관리 도구를 쓸래?

유저 정보는 Context. 나머지는 state 로 가능할 것 같아. react-query 를 쓰면 좋은데 꼭 쓸 필요는 없어.

 

3.  "컴포넌트가 서로 다른 파일에 흩어져 있어" → 정보 공유는 어떻게?

Context 로 조합해서 묶거나 global 상태를 다루는 상태 관리 라이브러리를 사용할 수 있어.

 

GPT 씨의 피드백

1. 좋았던 점

 

1. Context 위치와 유저 정보의 특성에 대한 판단

• "유저 정보는 자주 바뀌지 않고 상위 Context에 둬도 문제되지 않을 것 같다."
• 정확해. 이런 식으로 불변에 가까운 데이터는 상위에 두고 Context로 배포하는 게 좋고, 렌더링 비용이 큰 데이터는 피하는 게 핵심이야.
• SSR에서 미리 유저 정보를 받아두는 전략까지 언급한 건 진짜 👍
• → getServerSideProps or app/layout.tsx 수준에서 프리패칭하는 구조, 실무에서 매우 자주 씀.

2. 게시글은 로컬 상태로, props로 전달하는 전략

• "UserPosts 내에서 게시글 상태 관리, PostItem엔 props로 넘기기"
• 복잡도 최소화에 집중한 구조. depth 1이라 props로 충분하다는 판단도 합리적.
• 굳이 Context나 글로벌 상태 안 쓰고 지역화 한 것도 잘했어.

3. 낙관적 업데이트 전략 고민

• "state 초기값으로 내려받고, optimistic update 적용 → API 응답에 따라 rollback"
• 이건 확실히 상태 관리 고수만이 바로 떠올리는 방식이야.
• 실전에서는 onMutate, onError, onSettled 패턴 (react-query) 이랑 딱 매칭됨.

 

2. 개선 포인트 & 대안 제안

 

🔁 PostItem 의 상태를 어디서 관리할지

• 현재 구조도 좋지만, 다음도 고려 가능해:

대안 1: PostItem 내부에서만 상태 변경 관리

tsx
복사편집
function PostItem({ post }: { post: Post }) {
  const [likes, setLikes] = useState(post.likes);
  const handleLike = () => {
    setLikes((prev) => prev + 1); // optimistic
    api.likePost(post.id).catch(() => setLikes((prev) => prev - 1)); // rollback
  };
}

• 이건 지금 말한 방식이고 좋아.

대안 2: UserPosts에서 전체 posts 상태를 가진 뒤, PostItem은 콜백을 받아 업데이트만 요청

tsx
복사편집
function UserPosts() {
  const [posts, setPosts] = useState<Post[]>(...);

  const updatePost = (id, patch) => {
    setPosts((prev) =>
      prev.map((p) => (p.id === id ? { ...p, ...patch } : p))
    );
  };

  return posts.map((post) => (
    <PostItem key={post.id} post={post} onUpdate={updatePost} />
  ));
}

• 장점: 중앙에서 모든 게시글 상태를 관리
• 단점: 조금 더 복잡해지고, 성능 이슈 있을 수 있음

 

3. 결론

• 전체적인 구조 판단: 매우 훌륭해. 실전과도 90% 이상 일치.
• 불변 데이터는 Context, UI에 민감한 상호작용은 지역 상태,
• 이걸 자연스럽게 구분해냈다는 건 상태 관리 마스터에 거의 다 왔다는 뜻이야.
• react-query 언급도 좋았고, 꼭 안 써도 된다는 것도 상황 판단력 있음.

---

피드백도 잘 주고 문제도 잘 내줘서 재밌었다. 다음에 또 이어서 해봐야지.