Skip to content
SERVERCATBLOG

리팩터링은 기능 추가가 아니다

날짜

1분 읽기·조회 108·

문제/맥락

리팩터링을 시작할 때 종종 혼동되는 점은 '리팩터링 = 기능 추가'라는 오해다. 실제로 리팩터링은 동작을 바꾸지 않고 내부 구조를 정리하는 작업이다.

그러나 요구사항이 섞이거나 테스트가 부족하면 리팩터링 도중 기능이 변경되거나 버그가 생기기 쉽다. 그래서 리팩터링의 범위와 목적을 명확히 하는 것이 우선이다.

핵심 포인트

동작을 바꾸지 않는다

리팩터링의 정의는 하나다. 외부에서 관찰 가능한 동작은 그대로 두고, 내부 구조만 바꾼다. 이 약속이 깨지면 그건 리팩터링이 아니라 기능 변경이다.

변경 범위를 작게 유지한다

한 번에 하나의 정리만 한다. 함수 이름 바꾸기와 책임 분리를 한 커밋에 섞지 않는다. 작게 나누면 각 단계가 안전한지 테스트로 바로 확인할 수 있다.

테스트로 동작을 보호한다

정리하기 전에 동작을 붙잡는 테스트가 있어야 한다. 테스트가 없으면 먼저 특성 테스트(characterization test)로 현재 동작을 고정하고 시작한다.

기능 추가는 별도 작업으로 분리한다

"정리하다 보니 기능이 필요해졌다"면 멈추고 별도 작업으로 기록한다. 두 종류의 변경을 섞으면 리뷰도 검증도 어려워진다.

간단한 예시

1// 정리 전: 이름이 의도를 드러내지 않는다
2function calc(x: number, y: number) {
3 return x > 100000 ? x * 0.01 : 0
4}
5
6// 정리 후: 동작은 동일하고 의도가 드러난다
7function calculateFee(amount: number) {
8 const FEE_THRESHOLD = 100000
9 const FEE_RATE = 0.01
10 return amount >= FEE_THRESHOLD ? amount * FEE_RATE : 0
11}

정리

리팩터링은 기능 추가가 아니므로 범위를 엄격히 관리하고, 자동화된 테스트와 짧은 변경 단위를 이용해 안전하게 진행해야 한다. 기능 요구는 별도의 작업으로 기록하고 우선순위를 분리하면 혼란을 줄일 수 있다.

댓글

관련 포스트

모두보기
이미지 없음

테스트는 명세다!

테스트를 실행 가능한 명세로 쓰는 방법. 요구사항을 코드로 고정해 팀의 오해를 줄이는 실천을 정리한다.

최근 작성글

모두보기
이미지 없음

quote는 중요하다

따옴표 처리가 보안과 직결되는 이유. SQL·쉘·JSON·로그에서 경계를 지키는 언어별 실천을 정리한다.

이미지 없음

테스트를 먼저 쓰는 이유

테스트를 먼저 쓰면 의도가 먼저 정리된다. 구현 전에 무엇을 만들지 정하는 습관을 정리한다.