React Refactoring Skill

사용자가 제시하는 문제점을 무조건 수용하지 않는다. 각 문제점에 대해 비판적으로 검토하고, 정말 문제인지, 제시된 방향이 최선인지 분석한 후 리팩토링을 수행한다.

핵심 원칙: 수정하기 좋은 코드

모든 판단의 기준은 **"수정하기 좋은 코드인가?"**이다. 평가 기준 상세는 references/evaluation-criteria.md 참조.

사용자가 제시한 각 문제점마다 아래 단계를 수행한다. mcp__sequential-thinking__sequentialthinking 도구를 사용하여 사고 과정을 기록한다.

중요: 각 문제점당 최소 3번의 thinking 루프를 수행한다. 첫 번째 생각이 최선이 아닐 수 있다. 3번의 반복을 통해 더 나은 관점을 발견한다.

sequential-thinking으로 다음을 분석:

code

이 문제가 정말 문제인가?
- 현재 코드가 실제로 어떤 불편/위험을 초래하는가?
- "수정하기 좋은 코드" 9가지 기준 중 어떤 것을 위반하는가?
- 위반이 없다면, 이건 취향의 문제인가 실질적 문제인가?

사용자가 방향을 제시했다면:

code

이 방향이 정말 개선인가?
- 제안된 변경이 "수정하기 좋은 코드" 기준을 충족하는가?
- 오히려 복잡성을 증가시키지는 않는가?
- 기존 코드베이스의 일관성을 해치지 않는가?
- 과한 추상화(Over-engineering)는 아닌가?

제안된 방향이 최선이 아니라면:

code

더 나은 대안은?
- 더 단순한 해결책이 있는가?
- 점진적으로 개선할 수 있는 방법은?
- 이 문제를 해결하지 않는 것도 선택지인가?

분석 중 다음 상황이면 반드시 AskUserQuestion 도구로 질문:

typescript

// AskUserQuestion 사용 예시
AskUserQuestion({
  question: "useTableColumnHandler가 비대하다고 하셨는데, 이 훅을 사용하는 곳이 몇 군데인가요? 분리 시 모든 사용처를 수정해야 해서요."
})

모든 문제점 분석 완료 후:

계획서를 제시하고 AskUserQuestion으로 승인 요청:

code

리팩토링 계획을 검토해주세요.
- [수용] 문제 1: ... → 이렇게 변경
- [수정] 문제 2: ... → 제안과 다르게 이 방향으로
- [기각] 문제 3: ... → 현재 구조가 더 적절함
진행해도 될까요?

승인 후 계획에 따라 코드 수정. 각 단계마다:

훅 분리 시:

컴포넌트 분리 시:

폴더 구조 변경 시: