학습 목표
- 유지보수하기 좋은 코드로 바꾸기의 역할과 적용 조건을 설명할 수 있다.
- 현재 동작과 외부 계약을 기록하세요.
- 기존 입력·오류·화면 결과가 유지되는지 확인하고 결정 이유를 남기세요.
사전 지식
앞선 화면 성능을 측정하고 개선하기를 먼저 읽으면 용어를 이해하기 쉽습니다. 이미 아는 내용이면 이 장부터 시작해도 됩니다.
개념 이해
리팩터링은 동작을 유지하면서 구조를 개선하는 일입니다. 줄 수를 줄이는 것보다 코드가 왜 바뀌는지와 어디에서 규칙을 찾을지 명확하게 만드는 것이 목적입니다.
관심사·모듈화·단일 책임
화면 표시·요청·권한·계산을 구분합니다. 같은 이유로 바뀌는 코드는 모으고 다른 이유로 바뀌는 코드는 경계를 둡니다.
재사용·타입·이름
반복되는 컴포넌트와 규칙을 공유합니다. 값의 형태와 null·오류를 타입으로 표현하고 이름으로 의도를 설명합니다.
비즈니스·API·상태 계층
가격 계산은 순수 로직, 외부 통신은 API 계층, 입력과 로딩은 상태로 나누면 독립적으로 확인할 수 있습니다.
오류·문서·주석
오류 형식을 통일하고 왜 특별한 처리를 하는지 주석을 남깁니다. 명백한 코드를 한 줄씩 설명하기보다 제약과 결정을 기록합니다.
의존성·레거시
업데이트 영향과 변경 이력을 확인합니다. 오래된 코드를 한 번에 재작성하기보다 동작을 보호하고 경계부터 점진적으로 바꿉니다.
실제 사용 사례
계산식을 여러 화면에 복사했다면 한 모듈로 모으고 입력·출력 예시를 고정합니다. 화면을 바꾸는 작업과 계산식을 바꾸는 작업을 같은 리팩터링에 섞지 마세요.
단계별 실습
실습은 운영 서비스가 아닌 별도 연습 프로젝트에서 진행하세요. 기존 파일이 있다면 변경 전 기록을 남깁니다.
- 현재 동작과 외부 계약을 기록하세요.
- 중복과 여러 책임이 섞인 경계를 찾으세요.
- 한 책임을 분리하고 호출부를 최소한으로 바꾸세요.
- 기존 입력·오류·화면 결과가 유지되는지 확인하고 결정 이유를 남기세요.
코드와 프롬프트
아래 요청에서 대괄호 부분을 내 프로젝트에 맞게 바꾼 뒤 AI 도구에 전달하세요.
[대상 파일]을 더 짧게 만드는 대신 책임을 명확히 나눠줘. 기존 동작과 타입·오류 계약을 먼저 적고 비즈니스 로직·API·상태·UI 경계를 작은 변경으로 분리해줘. 중복 제거의 이득과 위험을 설명해줘.자주 발생하는 문제와 해결
| 문제와 원인 | 해결 방법과 확인 기준 |
|---|---|
| 공통화 후 호출부가 더 복잡해짐 | 두세 실제 사용 사례에 맞는 최소 추상화만 만듭니다. |
| 리팩터링에 기능 변경이 섞임 | 구조 변경과 기능 변경을 나눠 검토합니다. |
핵심 요약
- 동작 보존이 리팩터링의 전제입니다.
- 명확한 책임과 이름이 유지보수 비용을 줄입니다.
완료 확인
참고자료
확인 기준일: 2026-10-20. 요금·사용 한도·제품 기능·설정 경로는 변경될 수 있으므로 작업 직전 공식 문서와 설치 버전을 확인하세요.