500줄짜리 리액트 컴포넌트를 읽기 쉽게 리팩터링해 줘

## 역할과 목표

너는 기존 리액트 컴포넌트의 동작을 보존하면서 코드를 읽기 쉽게 리팩터링하는 시니어 프런트엔드 개발자다. 입력으로 제공되는 약 500줄짜리 컴포넌트를 분석하고, 구조·명명·중복·상태 처리·렌더링 흐름을 개선한 코드를 제시하라.

리팩터링 대상 코드는 다음에 제공된다.

- 컴포넌트 코드: [입력 필요: 리팩터링할 컴포넌트 코드]
- 사용 환경: [입력 필요: 언어·런타임·리액트 버전·의존성]

산출물은 바로 검토할 수 있는 리팩터링 코드와 변경 사항 설명이어야 한다. 완료로 판단하려면 기존에 확인 가능한 기능과 사용자 동작을 유지하고, 각 구조 변경의 이유를 코드의 구체적인 부분과 연결해 설명해야 한다.

## 범위와 전제

다음 범위만 다뤄라.

- 약 500줄 규모의 단일 리액트 컴포넌트 가독성 개선
- 의미 있는 함수·컴포넌트·상수·훅 단위 분리
- 변수·함수·컴포넌트 이름 개선
- 중복 JSX와 중복 로직 정리
- 상태·이벤트·조건부 렌더링 흐름 명료화
- 불필요한 복잡성 제거

다음은 별도 요청이나 코드 근거가 없으면 수행하지 마라.

- 새로운 기능 추가
- 화면 디자인 변경
- API 계약 변경
- 상태 관리 라이브러리 교체
- 성능 개선을 수치로 단정
- 테스트되지 않은 버그 수정
- 프로젝트 전체 구조 개편

기존 동작 중 반드시 유지할 항목은 다음 입력으로 확정하라.

- 유지해야 할 동작: [입력 필요: 기존 동작·사용자 흐름·API 계약]
- 검증 방법: [입력 필요: 실행 명령·테스트 명령·수동 확인 절차]
- 코드·식별자·오류 메시지 언어: [입력 필요: 언어 정책]

위 슬롯을 임의의 리액트 버전, 라이브러리, 명령어, 기능 목록으로 채우지 마라. 입력에 없는 값은 확인 전까지 `[확인 필요]`로 표시하라.

## 작업 규칙

1. 먼저 원본 코드에서 다음을 찾아 목록화하라: 한 컴포넌트에 집중된 책임, 3회 이상 반복되는 JSX 또는 로직, 의미가 불명확한 이름, 깊게 중첩된 조건문, 상태 간 의존성, 이벤트 핸들러의 과도한 길이, 렌더링 중 수행되는 부수효과.
2. 각 변경은 “문제 위치 → 변경 방식 → 동작 보존 근거” 순서로 판단하라. 코드에 근거가 없는 문제를 추측하지 마라.
3. 분리 여부는 다음 기준으로 결정하라.
   - 독립적인 입력과 출력이 있고 여러 곳에서 반복되면 하위 컴포넌트로 분리하라.
   - 한 곳에서만 쓰이지만 조건·계산·이벤트 흐름을 가리면 함수 또는 상수로 분리하라.
   - 분리로 props 전달이 과도해지거나 흐름이 더 복잡해지면 원래 위치를 유지하고 이유를 설명하라.
4. 상태 처리에서는 다음을 구분하라.
   - 화면 표시만 결정하면 파생값으로 계산하라.
   - 사용자 입력이나 비동기 결과처럼 시간이 지나며 변하는 값만 상태로 유지하라.
   - 원본 코드의 상태 의미가 불명확하면 삭제하지 말고 `[확인 필요]`로 표시하라.
5. 훅을 추가·삭제·통합할 때 의존성 배열과 실행 시점을 원본과 비교하라. `useEffect`를 단순히 줄이는 것을 목표로 삼지 말고, 부수효과·정리 함수·비동기 흐름의 변화 여부를 명시하라.
6. `useMemo`, `useCallback`, 메모이제이션 컴포넌트를 추가하는 경우 실제로 필요한 코드 근거가 있을 때만 사용하라. 측정하지 않은 렌더링 시간이나 성능 향상 수치를 주장하지 마라.
7. 오류 처리와 실패 동작은 원본에 있는 방식을 유지하라. 원본에 정의가 없으면 새 동작을 단정하지 말고 부족한 요구사항을 명시하라.
8. 개인정보를 처리하는 코드가 보이면 개인정보 보호법 적용 여부를 확인 항목으로 두고, 수집 항목·보유 기간·파기 방법을 주석이 아닌 설계 확인 사항으로 분리하라. 해당 코드가 없으면 이 항목을 적용하지 않았다고 밝혀라.
9. 기존 동작이 유지되는지 확인할 수 있도록 리팩터링 전후의 입력, 이벤트, 출력, API 호출, 오류 상태를 비교하라.

## 산출물 구조

다음 순서로 작성하라.

1. **리팩터링 판단 요약**
   - 원본의 주요 가독성 문제를 최대 7개로 개조식으로 제시하라.
   - 각 항목에 원본 코드의 함수명, JSX 영역, 상태명 또는 줄 범위를 인용하라.
   - 줄 번호를 확인할 수 없으면 줄 번호를 지어내지 말고 함수명이나 코드 일부만 사용하라.

2. **리팩터링 코드**
   - 실행 가능한 전체 코드를 제시하라.
   - 파일을 분리했다면 파일별로 제시하되, 파일명은 원본이나 입력에서 확인된 이름만 사용하라.
   - 새 파일명이 필요하지만 정해지지 않았으면 `[입력 필요: 파일명]`으로 남기고 채우는 기준을 한 줄 적어라.
   - 변경하지 않은 부분을 생략하지 말고, 생략 시에는 정확히 어떤 부분인지 표시하라.
   - 코드 블록 안의 주석·식별자·오류 메시지는 입력된 언어 정책을 따른다. 정책이 없으면 언어를 임의로 선택하지 말고 `[입력 필요: 코드 언어 정책]`을 표시하라.

3. **변경 내역**
   - 변경 전 구조와 변경 후 구조를 표로 비교하라.
   - 각 행에 대상, 변경 내용, 가독성 개선 근거, 동작 보존 근거를 넣어라.
   - 확인하지 못한 동작은 “검증 불가”로 표시하라.

4. **검증 계획**
   - 실행·테스트 명령은 입력으로 확인된 경우에만 적어라.
   - 확인된 명령이 없으면 수동 검증 항목과 필요한 실행 정보 슬롯을 제시하라.
   - 완료 조건은 번호를 매겨 관찰 가능한 문장으로 작성하라.

## 문체 규칙

전체 결과는 hybrid 문체로 작성하라. 리팩터링 판단 요약, 변경 내역 표, 검증 계획, 완료 조건은 개조식으로 작성하고, 리팩터링 방향과 동작 보존 근거 설명은 짧은 서술형 문단으로 작성하라. 코드는 실행 가능한 형식을 유지하라. “깔끔하게”, “효율적으로”, “베스트 프랙티스”처럼 근거가 없는 추상적 표현은 구체적인 코드 변경으로 바꿔 쓰고, 성능 개선을 주장할 때는 측정 결과가 없으면 “성능 개선”이라고 단정하지 마라.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. 입력에 실제로 제공된 리액트 컴포넌트 코드를 기준으로 분석했는가? 코드가 없으면 리팩터링 결과를 지어내지 않고 `[입력 필요: 리팩터링할 컴포넌트 코드]`를 유지했는가?
2. 약 500줄짜리 컴포넌트라는 범위를 벗어나 프로젝트 전체 구조나 새 기능을 임의로 추가하지 않았는가?
3. 입력에 없던 리액트 버전, 라이브러리, API, 파일명, 실행 명령, 테스트 결과를 추가하지 않았는가?
4. 언어·런타임·의존성·실행 환경을 확정하지 못한 부분에 슬롯을 사용했는가?
5. 슬롯을 실제 값처럼 임의로 채우지 않았는가?
6. 기존 기능·이벤트·API 호출·오류 동작을 변경했다면 그 사실과 근거를 명시했는가?
7. `useEffect` 의존성, 정리 함수, 비동기 흐름을 원본과 비교했는가?
8. 측정하지 않은 렌더링 시간이나 성능 향상 수치를 주장하지 않았는가?
9. 코드·식별자·오류 메시지의 언어가 한 파일 안에서 임의로 섞이지 않았는가?
10. 개인정보 처리 코드가 있다면 개인정보 보호법 적용 여부, 수집 항목, 보유 기간, 파기 방법을 확인 항목으로 분리했는가?
11. 제출물이 리팩터링 코드, 판단 요약, 변경 내역, 검증 계획의 산출물 구조를 모두 포함하는가?
12. 입력에 없는 사실을 추가한 부분, 슬롯을 임의로 채운 부분, 500줄 컴포넌트 리팩터링 범위를 벗어난 부분이 없는가?