Q1. state(제어)를 어느 컴포넌트에서 관리해야 할까?

이 영역은 정답 PR을 찾는 곳이 아닙니다. 지금 우리 페어가 어디까지 state를 올렸는지, 그 결정 때문에 어떤 비용을 감수하고 있는지를 선배 PR의 대화로 비춰보는 자리입니다. 코드를 먼저 훑기보다, 리뷰어가 멈춰 세운 질문과 작성자의 답변을 먼저 읽어보세요.

PR #439 데이지 — App으로 끌어올렸을 때 생기는 질문

PR #439 데이지(@kimyou1102)  · 인라인 리뷰 모음 →  — 8기 직전 기수의 PR입니다.

먼저 볼 자리: src/App.tsx:27 인라인 스레드 → 리뷰어가 “CVC 관련 상태는 App이 몰라도 될 것 같습니다. 오히려 알고 있을 때 어떤 단점이 있을까요?” 라고 묻는 지점에서 시작하면 좋습니다.

읽는 관점

• 이 state를 App이 알아야 하는 기능상 이유가 있었는가? 프리뷰, 제출, 에러 표시처럼 두 영역이 동시에 필요한 정보인지 확인합니다.
• App으로 올린 뒤 props가 어디까지 퍼졌는가? 자식 컴포넌트가 단순해진 대신 부모가 무엇을 더 많이 알게 됐는지 봅니다.
• CVC처럼 특정 입력 영역 안에서 끝날 수 있는 state라면, App이 아니라 새 컴포넌트 경계를 만드는 선택지도 있었는지 살핍니다.

페어 대화 포인트

• 우리 코드에서 “일단 App에 둔 state”를 세어봅니다.
• 각 state 옆에 누가 읽는가, 누가 바꾸는가, 같이 바뀌어야 하는 컴포넌트가 둘 이상인가를 적어봅니다.
• “3개 이상 컴포넌트를 지나가니까 전역 상태나 Context가 필요하다”고 판단한 순간이 있었다면, 정말 필요한 공유인지 다시 이야기해봅니다.

PR #361 제이드 — custom hook을 먼저 만들었을 때 생기는 질문

PR #361 제이드(@skiende74)  · 인라인 리뷰 모음 →  — custom hook 추출을 고민 중이라면 특히 참고하기 좋은 PR입니다.

먼저 볼 자리: src/hooks/useInput.tsx 인라인 → 그리고 src/hooks/useInputs.tsx 인라인 →. 리뷰어가 useInput의 존재 이유와 useInputs로 다시 합친 구조를 질문하는 흐름을 따라가면 됩니다.

읽는 관점

• hook이 실제 중복을 줄이는가, 아니면 state와 handler를 다른 파일로 옮겼을 뿐인가?
• useInput처럼 넓은 이름보다 useCardNumber처럼 도메인 의미가 남는 이름이 더 읽기 쉬운가?
• hook으로 합치기보다 카드번호 컴포넌트, 유효기간 컴포넌트처럼 화면의 의미 단위로 나누는 편이 더 자연스러운가?

페어 대화 포인트

• “훅으로 빼자”는 말이 나왔을 때, 같은 로직이 두 번 이상 반복되고 있는지 먼저 확인합니다.
• 훅 이름만 보고 그 훅의 책임을 설명할 수 있는지 서로 물어봅니다.
• 2단계에서 카드사 선택, 별칭, 비동기 저장 같은 요구사항이 늘어나면 이 hook이 바뀔지, 컴포넌트만 바뀔지 예상해봅니다.

비교하며 읽기

• 데이지 PR은 필요해서 끌어올렸지만 비용을 다시 확인한 사례입니다.
• 제이드 PR은 미리 추출했지만 추상화의 기준을 다시 세운 사례입니다.
• 우리 코드는 둘 중 어디에 가까운지 표시해보세요. 이미 너무 많이 끌어올렸는지, 아직 반복을 보기도 전에 훅을 만들고 있는지 구분하는 것만으로도 다음 리팩터링 방향이 또렷해집니다.

자기 가설이 자식이 state를 자체 보유하는 방향이라면 연관 PR 더 보기에서 state 위치만 매핑된 PR(예: #88  코이, #73  앨버, #195  루루)을 골라, 왜 그 구조가 유지되거나 바뀌었는지 비교해보세요.

이 주제와 이어지는 외부 글입니다.

Kent C. Dodds — Application State Management with React

• 원문: kentcdodds.com/blog/application-state-management-with-react 
• 한 줄 요약: Kent는 “React 자체가 상태 관리 라이브러리” 라는 입장에서 순서를 제안한다 — Local → Lifting → Composition(children prop) → Context → 외부 라이브러리. 공유가 필요하면 먼저 state를 필요한 공통 부모로 올리고, prop drilling이 부담될 때는 컴포넌트 합성을 먼저 검토한 뒤 Context를 고려하라는 흐름이다. 지오·코브 페어의 “3단계 이상 props는 전역?” 질문에는 “단계 수만 보지 말고 필요한 공유 범위부터 확인하라” 는 기준으로 읽는 편이 정확하다.

Dan Abramov — Writing Resilient Components

• 원문: overreacted.io/writing-resilient-components 
• 한 줄 요약: 컴포넌트가 부모의 변경에 잘 견디려면 어떤 원칙을 따라야 하는가. 끌어올린 state가 자식의 가정과 어긋날 때의 비용. PR #439 데이지가 App에 끌어올린 뒤 인식한 비용과 이어진다.

Kent C. Dodds — AHA Programming

• 원문: kentcdodds.com/blog/aha-programming 
• 한 줄 요약: Avoid Hasty Abstractions — 성급한 추상화를 피하라. 페이먼츠 2단계 프로그래밍 요구사항의 *“처음부터 훅 구조를 설계하지 않는다”*는 이 원칙과 같은 방향으로 읽을 수 있다. PR #361 제이드가 useInput을 처음부터 만들었다가 구조를 다시 생각하게 된 사례와 이어진다.

자기 가설에 가까운 PR을 골라 추가로 비교해보세요.

195개 전체 인덱스(다른 주제 포함)는 부록에서 확인할 수 있습니다.