리팩터링 실전 강의 교재¶

5장 — 리팩터링 카탈로그 보는 법¶

대상: Java/Spring 백엔드 입문~중급 수강생 형식: 짧은 메타 장 — 6장부터의 카탈로그 사용 설명서 전제 환경: Java 17+, Spring Boot 3.x

0. 이 장을 시작하기 전에¶

0.1 학습 목표¶

6~12장 카탈로그가 어떤 일관된 형식 으로 쓰였는지 안다.
"이 리팩터링을 언제 쓰고, 언제 안 쓰는가" 의 선정 기준 을 이해한다.
카탈로그를 사전처럼 쓰는 법 — 처음부터 끝까지 안 읽고, 필요할 때 펼침.

0.2 큰 그림 — 6~12장은 사전이다¶

3장 악취 → "이 코드가 어떤 악취?"            진단
                ↓
5장 카탈로그 보는 법 → "어떤 처방?"          이 장
                ↓
6~12장 카탈로그 → "어떻게 적용?"            처방

비유 — 5장은 "사전 사용 설명서"입니다.

처음부터 외울 게 아니라, 카탈로그를 언제 어떻게 펼지 를 배우는 짧은 길잡이.

0.3 현업에서 왜 중요한가¶

5장을 건너뛰면 6장부터 "기법 나열" 처럼 보여 길을 잃기 쉽습니다.
카탈로그 형식이 익숙해지면 새 기법을 1분 내에 평가 할 수 있게 됩니다.

5.1 리팩터링 설명 형식¶

각 리팩터링 항목은 다음 5단 구성입니다.

단	이름	내용
1	이름	`함수 추출하기` 같은 표준 이름 — 팀의 합의된 어휘
2	개요(스케치)	Before/After 코드 한 쌍의 그림. 의도가 한눈에
3	동기	왜 이 리팩터링이 필요한가, 언제 적용·언제 회피하는가
4	절차	작은 단계의 순서 — 어디서 멈춰도 동작 보존
5	예시	실제 코드로 절차를 따라가는 시연

왜 이런 형식인가¶

이름 이 있어야 팀에서 같은 단어로 합의 가능 ("이거 함수 추출 PR입니다" 한 줄).
절차 가 있어야 안전하게 적용 — "한 단계마다 테스트가 초록" 이 가능해짐.
예시 가 있어야 추상적 설명이 실제 손동작으로 연결.

시그너처 (★별) 표시¶

책에서는 일부 리팩터링에 ★를 붙여 "가장 중요" 또는 "기본기" 임을 표시. 이 강의 교재에서도 ★ 표기 유지.

대표 ★: - 함수 추출(6.1) ★ — 모든 리팩터링의 기본 - 변수 추출(6.3) ★ - 함수 선언 바꾸기(6.5) ★ - 함수 옮기기(8.1) ★ - 조건부 로직을 다형성으로(10.4) ★

5.2 리팩터링 기법 선정 기준¶

Fowler가 카탈로그를 추리는 선정 기준 은 다음과 같습니다 (책의 정신 요약).

1. 자주 마주치는 상황¶

희귀한 케이스보다 매일 마주치는 코드 패턴 의 처방을 우선. 그래서 "함수 추출", "변수 추출", "이름 바꾸기" 같은 기본기가 책 앞쪽에 배치.

2. 작은 단계로 분해 가능¶

각 리팩터링이 작은 단계의 순서 로 풀려야 함. 한 단계 적용 후 즉시 테스트 → 초록이면 다음 단계. 이게 안전성의 핵심.

3. 자동화·도구 친화적¶

IDE(IntelliJ·Eclipse)의 자동 리팩터링 메뉴 에 매핑되는 기법이 우선. 자동화 가능 = 안전성·속도 동시 확보.

4. 한쪽으로 갈 수 있는 만큼 반대쪽도 다룬다¶

거의 모든 리팩터링이 쌍으로 존재: - 함수 추출(6.1) ↔ 함수 인라인(6.2) - 변수 추출(6.3) ↔ 변수 인라인(6.4) - 클래스 추출(7.5) ↔ 클래스 인라인(7.6) - 위임 숨기기(7.7) ↔ 중개자 제거(7.8) - 참조→값(9.4) ↔ 값→참조(9.5) - 명령→함수(11.10) ↔ 함수→명령(11.9)

왜? 어제 옳던 선택이 오늘 틀릴 수 있음. 항상 한 방향 = 도그마. 양방향 = 도구.

5. 동기와 반대 신호를 함께 제시¶

각 항목의 동기 절은 "언제 쓰는가" 뿐 아니라 "언제 쓰지 않는가" 도 다룸. 모든 망치를 들고 다닐 필요 없음.

카탈로그를 활용하는 4가지 모드¶

모드 1: 진단 → 처방 (가장 흔함)¶

3장에서 악취 발견 (예: "이건 긴 함수")
처방 매트릭스로 후보 리팩터링 (예: 함수 추출 6.1)
해당 항목의 "동기" 읽고 적용 결정
"절차" 따라 한 단계씩

모드 2: 코드 리뷰 어휘¶

리뷰 코멘트에 카탈로그 이름을 인용:

"이 부분은 반복되는 switch(악취 3.12) 같습니다. 조건부 로직을 다형성으로(10.4) 적용 검토해 주세요."

→ 합의가 빨라짐. 신입도 표준 어휘로 학습.

모드 3: 신입 교육¶

각 항목의 Before/After 한 쌍을 발췌해 교육 자료. 1주에 5개씩 익히면 3개월에 다 통과.

모드 4: 도구·자동화 매핑¶

IntelliJ의 Refactor 메뉴와 카탈로그 이름이 거의 1:1. 매뉴얼 보면서 IDE 단축키 익히기.

카탈로그의 한계 — 5장이 미리 인정하는 것¶

1. 모든 상황을 다루지 못함¶

책은 ~66개. 실제 코드에는 그 이상의 패턴이 있음. 카탈로그는 사고의 출발점, 정답집이 아님.

2. 언어 의존성¶

2판은 JavaScript 예제. Java/Kotlin에서는 일부 기법(클래스 분리·접근 제한) 비중·구문이 다름. 원칙은 100% 같음.

3. 콘텍스트 무시 위험¶

"긴 함수는 무조건 추출" 같은 도그마는 위험. 절차서가 아니라 카탈로그.

4. 거대 리팩터링은 다루지 않음¶

모듈 분리·서비스 쪼개기 같은 큰 단위는 별도 책 (Working Effectively with Legacy Code, Building Evolutionary Architectures).

6장부터의 학습 전략¶

권장 진입 순서¶

6장 기본적인 리팩터링 (11) — ★ 5개가 여기. 다른 모든 장의 기반.
3장 다시 펴기 — 각 악취 옆에 6장 기법 매핑이 보이기 시작.
7장 캡슐화 (9) — OO 핵심.
8장 기능 이동 (9) — "산탄총 수술" 처방.
10장 조건부 로직 (7) — 다형성 패턴.
11장 API 리팩터링 (13) — 공개 인터페이스 설계.
9장 데이터 조직화 (6) — 자료구조 정리.
12장 상속 다루기 (11) — 마지막. 상속은 조심.

시간이 없다면 — 황금 10개¶

#	리팩터링	왜
6.1	함수 추출 ★	가장 자주
6.5	함수 선언 바꾸기 ★	이름 정리의 시작
6.8	매개변수 객체 만들기	인자 4개+ 처방
7.3	기본형을 객체로	기본형 집착 처방
7.5	클래스 추출	거대 클래스·뒤엉킨 변경
8.1	함수 옮기기 ★	기능 편애·산탄총 수술
10.4	조건부 로직을 다형성으로 ★	반복 switch 처방
11.1	질의 함수와 변경 함수 분리 (CQS)	API 설계의 정석
11.3	플래그 인수 제거	boolean 매개변수 처방
12.10	서브클래스를 위임으로	상속 → 합성 전환

이 10개만 익혀도 PR 절반은 처리 가능.

핵심 교훈¶

카탈로그의 5단 형식 (이름·개요·동기·절차·예시) 을 자주 보면 새 기법 흡수가 빨라진다.
거의 모든 리팩터링은 쌍 — 추출/인라인, 위임 숨기기/중개자 제거. 양방향 도구로 들고 있어라.
자동화 가능한 기법 우선 — IDE 메뉴와 카탈로그 이름이 거의 일치.
카탈로그는 출발점이지 정답집 아님. 콘텍스트 판단이 마지막 책임.
6장부터의 학습은 6 → 7 → 8 → 10 순서 권장.

함정 / 주의¶

카탈로그 외우기 가 목적이 아니다. 펼쳐 보며 적용할 수 있으면 충분.
이름 도그마: "이건 절차에 안 맞으니 진짜 함수 추출 아냐" 같은 형식주의는 피하라.
자동 도구만 믿기: 동적 참조(리플렉션·SpEL·JSON 키)는 사람 눈으로.

체크리스트 (카탈로그 사용)¶

진단 (3장 악취) 먼저 한 뒤 처방을 골랐는가
골라낸 리팩터링의 동기 절을 읽고 적용 결정했는가
절차 의 작은 단계마다 테스트가 초록인가
IDE 자동 메뉴를 활용했는가
한 PR = 한 리팩터링 = 한 의도인가

퀴즈¶

Q1. 모든 리팩터링이 "쌍"으로 존재하는 이유는?

A. 문맥에 따라 어제 옳던 선택이 오늘 틀릴 수 있기 때문. 항상 한 방향(예: 항상 함수 추출)만 적용하면 도그마가 되고, 양방향 도구로 들면 상황 적응 가능. 오브젝트 의 "추상화는 도구지 종교가 아니다" 와 같은 메시지.

Q2. 카탈로그 형식의 5단 중 가장 중요한 단은 무엇이고 왜?

A. 절차(4단). 안전성의 핵심이 "작은 단계로 분해" 인데, 절차가 그 단계를 명시. 절차 없는 리팩터링은 곧 재작성 = 위험.

Q3. "황금 10개" 만 익혀도 PR 절반은 처리 가능한 이유?

A. CR에서 가장 자주 지적되는 코드 악취 (긴 함수·반복 switch·플래그 인수·기본형 집착·인자 다수) 의 처방이 그 10개에 다 포함되기 때문. 카탈로그의 80/20 — 20%의 기법이 80%의 사례를 해결.

Q4. "카탈로그 외우기가 목적이 아니다" — 그럼 무엇이 목적?

A. 악취를 보면 후보 리팩터링이 떠오르는 사고 회로. 정확한 절차는 책을 펴 보면 되지만, 진단·후보 매핑은 머리에 들어 있어야 코드 보다가 즉시 보이게 됨.

다음 장 예고 — 6장: 기본적인 리팩터링¶

드디어 카탈로그 본편. 11개 기본 리팩터링 — 함수 추출 ★, 함수 인라인, 변수 추출 ★, 변수 인라인, 함수 선언 바꾸기 ★, 변수 캡슐화, 변수 이름 바꾸기, 매개변수 객체, 여러 함수를 클래스로, 변환 함수로 묶기, 단계 쪼개기. ★가 책 전체의 기반.