🧩 04. Props Drilling의 비극과 State Colocation

🎯 이 섹션을 읽고 나면:

• 전역 상태 관리 라이브러리(Redux, Zustand)를 도입하기 전에 컴포넌트 설계를 먼저 의심할 수 있다.
• 상태를 최상위 컴포넌트로 끌어올렸을 때(Lifting State Up) 발생하는 렌더링 폭탄(재앙)을 이해한다.
• 상태를 "가장 필요로 하는 컴포넌트에 최대한 가깝게 배치(State Colocation)"하는 핵심 기준을 획득한다.

📋 목차

• 🤔 왜 알아야 하는가: '끌어올리기(Lifting)'의 이면
• 🏗️ 비유로 먼저 이해하기
• 🧩 State Colocation: 상태는 자기 자리에 두어라
  • ✅ 영호의 리팩토링: 상태를 나락으로 떨어뜨리기
• 💥 에러 해결 카탈로그
  • ❌ 무지성 전역 상태 관리 도구(Zustand, Redux) 남용

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분 / 핵심 파트: 8분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입): "게시글 목록 제일 끝에 있는 댓글의 '좋아요' 버튼을 새로 달았어요! 이제 App.tsx에 likes 상태를 두고 프롭스로 넘길게요."
• 영호(리드): "영철 님... 댓글 하나의 좋아요를 눌렀는데 왜 커뮤니티 전체 사이트가 버벅거리면서 새로고침(리렌더링)되는 거죠?"

🤔 왜 알아야 하는가: '끌어올리기(Lifting)'의 이면

React 공식 문서에서는 두 컴포넌트가 같은 상태를 공유해야 할 때 "상태를 공통 부모 요소로 끌어올리세요(Lifting State Up)" 라고 가르쳐. 이 원칙은 아주 훌륭하지만, 신입 개발자들은 종종 이 말을 곡해해서 대형 사고를 치고 말아.

🤔 잠깐, 먼저 생각해 봐
앱에서 쓰이는 모든 상태를 제일 꼭대기인 App 컴포넌트 하나에 다 몰아넣고 자식들에게 나눠주면 관리가 편하지 않을까?

// ❌ 영철이의 폭탄 설계 (Naive Approach)
function App() {
  const [theme, setTheme] = useState('light');
  const [currentUser, setCurrentUser] = useState(null);
  
  // 💣 이 앱의 수천 개 댓글 중 "단 하나"의 좋아요 상태가 변경될 때 쓰이는 상태
  const [commentLikes, setCommentLikes] = useState({}); 
 
  const handleLike = (commentId) => {
    setCommentLikes(prev => ({ ...prev, [commentId]: prev[commentId] + 1 }));
  };
 
  return (
    <div className={`app ${theme}`}>
      <CommunityHeader user={currentUser} />
      <Sidebar />
      {/* 💥 프롭스 드릴링의 시작 */}
      <Feed commentLikes={commentLikes} onLike={handleLike} />
    </div>
  );
}

영철이의 코드는 겉보기엔 작동해. 하지만 사용자가 피드 맨 아래에 숨겨진 댓글의 '좋아요' 버튼을 클릭하는 순간 앱 전체에 끔찍한 재앙이 시작돼.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
우리 집에 아빠, 아들, 손자가 살고 있어.
손자가 자기 장난감 로봇의 색깔을 파란색에서 빨간색으로 칠했어.
이 사실을 집안의 최고 대장(아빠) 에게 보고(App에 상태 두기)했지.
그러자 아빠는 확성기를 들고 온 집안에 소리쳤어!
"비상! 우리 집 상태가 변경되었다! 온 가족 구성원은 하던 일을 멈추고 각자의 방을 싹 다 인테리어(리렌더링) 다시 해라!"
로봇 색칠 하나 했을 뿐인데, 화장실에 있던 아빠도, 주방에 있던 삼촌도, 옆방의 누나도 불필요하게 자기 방을 허물고 다시 짓게 된 셈이야.

✅ 핵심 원리:
React의 절대 규칙: "부모 컴포넌트의 상태(State)가 변경되면, 그 컴포넌트가 품고 있는 모든 자식 컴포넌트들은 강제로 리렌더링된다."
상태를 최상단(App이나 최상위 Context)으로 무지성으로 끌어올리면, 단말 노드(리프)에서 일어난 조그마한 상호작용 하나가 앱 전체 트리를 모조리 다시 계산(Diffing)하게 만들어 성능을 완전히 박살 냅니다. 게다가 그 상태와 함수를 전달하기 위해 중간에 껴있는 수많은 컴포넌트들이 쓰지도 않을 props를 주렁주렁 달고 넘겨주게 되죠. 이를 Props Drilling이라고 합니다.

🧩 State Colocation: 상태는 자기 자리에 두어라

이 재앙을 막기 위해 5년 차 시니어들이 가장 먼저 체크하는 설계 원칙이 바로 State Colocation(상태의 적소 배치) 이야.
"상태는 그것을 필요로 하는 컴포넌트 트리의 최대한 가까운 곳(최하위 계층)에 두어라" 라는 뜻이지.

✅ 영호의 리팩토링: 상태를 나락으로 떨어뜨리기

댓글의 '좋아요' 상태는 App이나 Feed 컴포넌트가 알 필요가 전혀 없어. 오로지 그 댓글 컴포넌트 스스로만 알고 있으면 돼!

// ✅ 우아한 설계 (Pro Approach: State Colocation)
 
// 1. App은 가벼워졌다.
function App() {
  const [theme, setTheme] = useState('light');
  return (
    <div className={`app ${theme}`}>
      <CommunityHeader />
      <Sidebar />
      <Feed /> {/* props drilling이 사라짐! */}
    </div>
  );
}
 
// 2. 상태를 진짜 필요한 최말단 컴포넌트 안으로 집어넣는다.
function CommentItem({ commentData }) {
  // 🎯 이 댓글만의 독자적인(Local) 상태!
  const [likes, setLikes] = useState(commentData.initialLikes);
 
  return (
    <div className="comment">
      <p>{commentData.text}</p>
      <button onClick={() => setLikes(likes + 1)}>
        좋아요 {likes}
      </button>
    </div>
  );
}

이제 특정 댓글의 좋아요 버튼을 눌러도, 그 댓글 하나(CommentItem)만 리렌더링돼. App이나 형제 컴포넌트들은 아무런 타격을 받지 않지. 이것이 바로 아키텍처 단위의 가장 공짜고 완벽한 렌더링 최적화야.

💥 에러 해결 카탈로그

❌ 무지성 전역 상태 관리 도구(Zustand, Redux) 남용

상황: 영철이가 "아! 프롭스 드릴링이 너무 귀찮아! 모든 상태를 전부 Redux나 Zustand 전역 스토어(Global Store)에 박아두고 어디서든 가져다 쓰자!" 라고 주장한다.

원인: 상태를 컴포넌트 밖(Store)으로 빼냈다고 해서 상태가 좋아지는 게 아니야.
전역 스토어에 상태를 두는 순간, 해당 컴포넌트는 재사용성이 박살 나. 나중에 다른 프로젝트에서 이 회원가입 폼을 그대로 떼어다 쓰고 싶은데, Zustand 스토어와 결합(Coupling)되어 있어서 떼갈 수가 없어지는 유지보수 스파게티가 되어버리지.

해결책:
전역 상태는 "정말로 앱의 모든 구석에서(Header, Sidebar, Mypage 등) 동일하게 쳐다봐야 하는 데이터(예: 현재 로그인한 유저 정보, 다크 모드 테마, 언어 설정)" 에 한해서만 제한적으로 써야 해.
입력 폼의 모달 활성화 여부나, 게시글 하나의 접기/펼치기 버튼 상태는 철저하게 지역 상태(useState)로 고립(Isolate)시켜야 해.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
최대한 늦게, 최대한 낮게(방구석에) 상태를 선언하라. 그것을 필요로 하는 컴포넌트들만의 '최소 공통 부모'까지만 상태를 끌어올리는 것이 프론트엔드 아키텍처의 전부다.

🐣 영철이의 퇴근 일기

내가 짠 댓글 좋아요 버튼 때문에 커뮤니티 사이트 전체가 재렌더링되고 있었다니 부끄러워서 쥐구멍에라도 숨고 싶다. 무조건 위로 끌어올리라는 옛날 블로그 글만 믿었던 내 탓이다.

💡 "상태는 진짜 필요한 최말단 방구석에 고립(Colocation) 시키자. 불필요한 전역 상태는 유지보수 스파게티의 원흉이다!"

가족 비유를 들으니까 확 와닿는다. 아무리 Redux, Zustand가 편해도 남용하지 말아야겠다는 다짐을 해본다. 상태는 필요할 때 가장 가까운 공통 부모까지만 올리는 게 진짜 프로페셔널한 아키텍처구나. 집에 가서 내 취업용 포폴 코드 좀 까보고 불필요한 전역 상태 날려버려야지. 뿌듯한 하루다.

📝 마무리 퀴즈

Q1. 여러 개의 펼침 메뉴(Accordion)를 만들고 있습니다. 조건: "단 하나의 메뉴만 열려 있어야 하며, 다른 메뉴를 클릭하면 기존 건 닫혀야 한다." 이 경우 isOpen 상태는 최적의 State Colocation 원칙에 따라 어디에 배치해야 할까요?

• A) 각 단일 AccordionItem 컴포넌트 내부 (useState(false))
• B) 앱의 최상단 컴포넌트 App.tsx
• C) 모든 AccordionItem을 감싸고 있는 바로 위 부모 컴포넌트 (AccordionList)
• D) Redux / Zustand 스토어

✅ 정답: C

💡 상세 해설: 아주 훌륭한 딜레마입니다! 만약 "각각의 메뉴가 서로 독립적으로 열리고 닫힐 수 있다"면 정답은 A(각각의 아이템 내부)입니다. 하지만 문제의 조건은 "서로가 서로의 영향을 받아야 한다(하나가 닫혀야 하나가 열림)" 입니다. 형제 컴포넌트끼리 소통해야 하므로, 이 상태들을 동시에 컨트롤할 수 있는 최소 공통 부모인 AccordionList 로 상태를 끌어올리는(Lifting State Up) 것이 완벽한 정답입니다. 부모에 activeItemIndex 같은 상태를 둬야 하죠. (B, D는 불필요하게 너무 많이 끌어올린 오답입니다.)

Q2. 자식 컴포넌트 A, B, C를 거쳐 저 밑의 D 컴포넌트로 함수의 프롭스(Props Drilling)를 4단계나 뚫고 넘겨주고 있습니다. A, B, C는 이 프롭스를 전혀 쓰지 않습니다. 이를 방지하는 컴포넌트 합성(Composition) 전략의 핵심 문법은 무엇인가요?

• A) React.memo 사용
• B) children prop 사용 (<A><B><C><D/></C></B></A> 형태로 조립)
• C) useEffect 사용
• D) useRef 사용

✅ 정답: B

💡 상세 해설: 프롭스 드릴링을 해결하는 또 다른 강력한 무기입니다.
최상위 부모에서 구멍을 뚫어 데이터를 층층이 넘겨주는 대신, 아예 최상위에서 D 컴포넌트를 직접 조립한 뒤 샌드위치의 내용물인 children으로 꽂아 넣는 방식입니다.
중간의 A, B, C 컴포넌트는 자신이 어떤 children 컴포넌트를 받았는지 알 필요가 없으므로 프롭스를 패스할 필요도 사라집니다.
(10번 째 가이드에서 집중적으로 파헤칠 예정입니다!)

Q3. 영철이가 버튼을 누르면 즉시 앱의 언어가 '한국어'에서 '영어'로 바뀌게 만들고 싶어 합니다. 영철이는 State Colocation 원칙을 맹신하여, 언어 버튼 컴포넌트 안에만 지역 상태 const [lang, setLang] = useState('ko')를 두었습니다. 화면 전체의 글자들이 영어로 바뀌었을까요? 원리와 함께 설명해 보세요.

✅ 정답 및 주관식 해설:

절대 바뀌지 않습니다.
언어 설정(다국어) 데이터는 버튼 하나만 필요한 게 아니라, 화면에 존재하는 Header, Footer, 콘텐츠 영역 등 앱 내의 거의 모든 컴포넌트가 동시에 구독하고 공유해야 하는 철저한 '전역 상태(Global State)' 입니다.
영철이가 버튼 내부에 지역 변수로 고립시켜 버렸기 때문에, 버튼만 영어가 되었을 뿐 외부에 있는 다른 컴포넌트들은 그 데이터가 변한 사실조차 알지 못합니다
(상태를 넘겨받을 경로가 없으므로 리렌더링도 트리거되지 않음).

• 결론: 이런 성격의 테마, 언어설정, 유저 로그인 정보 등은 예외적으로 최상단(Context Provider나 전역 스토어)으로 과감하게 끌어올려야 하는 데이터 입니다. Colocation의 예외 케이스인 셈이죠.