짧은 안내 장이다. 6장부터 책의 나머지 대부분을 차지하는 리팩터링 카탈로그가 시작되는데, 각 항목이 어떤 형식으로 쓰였는지를 먼저 못박아 둔다. 카탈로그는 소설처럼 처음부터 끝까지 읽는 물건이 아니라, 사전처럼 필요할 때 펴 보는 참조서다. 그래서 형식을 알아 두면 원하는 정보를 빠르게 짚을 수 있다.
항목의 다섯 부분
각 리팩터링 항목은 다섯 개의 고정된 부분으로 구성된다. 하나의 항목이 어떻게 갈라지는지 먼저 구조로 보면 아래와 같다.
flowchart TD item[카탈로그 항목] --> name[이름] item --> sketch[개요] item --> motivation["배경 (언제 쓰고 언제 말지)"] item --> mechanics[절차] item --> example[예시]
이 다섯을 하나씩 풀어 보자.
- 이름(name): 리팩터링 어휘의 핵심. “함수 추출하기”, “변수 인라인하기”처럼 팀이 공유하는 언어가 된다. 이름이 있어야 리뷰에서 “여기 이 부분을 함수로 추출하면 어때요?” 한 문장으로 의도가 통한다. 저자는 좋은 이름을 짓는 데 상당한 공을 들였다고 밝힌다 — 어휘를 만드는 일이기 때문이다.
- 개요(sketch): 이 리팩터링을 언제 쓰는지 한두 문장으로 요약하고, before/after 코드 스케치나 UML 다이어그램을 곁들인다. 기법을 이미 아는 사람이 “아, 그거”하고 기억을 되살리는 빠른 참조용이다.
- 배경(motivation): 왜 이 리팩터링이 필요한지, 그리고 언제 쓰지 말아야 하는지를 설명한다. 나는 이 부분이 카탈로그에서 제일 중요하다고 본다. 기법을 아는 것보다 “지금 이걸 써야 하나”를 판단하는 게 실전에선 더 어렵다.
- 절차(mechanics): 리팩터링을 수행하는 단계별 방법. 오랜만에 쓰는 기법을 안전하게 따라 하기 위한 요리책 부분이다.
- 예시(example): 실제 코드로 처음부터 끝까지 시연한다. 절차의 각 단계를 코드에 적용하며 중간중간 테스트를 돌리는 모습까지 보여준다.
절차 = 최대한 잘게 나눈 안전한 걸음
카탈로그의 절차를 처음 보면 “이렇게까지 잘게 쪼갤 일인가” 싶을 만큼 단계가 촘촘하다. 이게 이 책의 핵심 철학이다. 저자는 리팩터링을 아주 작은 걸음의 연속으로 수행한다. 한 걸음이 작을수록 그 걸음이 무언가를 망가뜨렸을 때 되돌리기 쉽고, 매 걸음 사이에 테스트를 끼워 넣어 “여기까진 멀쩡하다”를 확인할 수 있기 때문이다.
물론 익숙해지면 여러 걸음을 한 번에 뛰어도 된다. 하지만 상황이 꼬이기 시작하면 — 테스트가 빨간불이 되고 원인이 안 보이면 — 곧바로 보폭을 좁혀 절차대로 돌아온다. 절차에 적힌 잘게 쪼갠 걸음들은 “평소엔 건너뛰어도 좋지만, 어려워지면 여기까지 좁힐 수 있다”는 안전 하한선인 셈이다. 이 감각은 pharos 같은 앱에서 큰 구조 변경을 할 때 그대로 통한다. 잘 될 땐 성큼성큼 가다가, 컴파일러가 붉게 물들기 시작하면 커밋 단위를 잘게 쪼개 한 걸음씩 초록불을 확인하며 전진하는 것과 똑같다.
정리
- 카탈로그는 정독하는 책이 아니라 사전처럼 찾아 쓰는 참조서다. 배경만 훑어 두고 절차는 필요할 때 편다.
- 다섯 부분 중 배경(언제 쓰고 언제 쓰지 말지)이 실전 판단에 가장 값지다.
- 절차의 촘촘한 단계는 강제가 아니라 안전 하한선이다. 잘 될 땐 건너뛰고, 꼬이면 그 보폭까지 좁힌다.
- 이름을 외우는 것 자체가 가치다. 공유 어휘가 생기면 리뷰와 설계 대화의 해상도가 올라간다.