외부 동작을 바꾸는 개선은 리팩토링과 구분한다
리팩토링은 관찰 가능한 동작을 유지하면서 내부 구조를 바꾸는 작업이다. 더 안전하거나 쓰기 편해지는 개선이라도 반환 형식·오류 처리·인증 방식처럼 소비자가 의존하는 행동을 바꾸면 그 부분은 계약 변경으로 다룬다.
이름보다 전후 동작을 본다
함수 추출·중복 제거 과정에서는 기존 소비자가 보는 결과와 필요한 부작용을 보존하는지 확인한다. 반면 문자열 응답을 구조화된 객체로 바꾸거나 세션 방식에서 토큰 발급으로 전환하면 호출자와 상태 관리에 미치는 영향이 달라진다. 이를 단순 정리라고 표현하면 필요한 요구사항·호환성·회귀 검토를 놓칠 수 있다.
이름·주석도 스키마 생성이나 프롬프트 구성에 소비되면 외부 입력을 바꿀 수 있다. 단순 명명 정리처럼 보여도 해당 소비 경로가 있다면 생성 결과를 대조해야 한다.
한 작업에 구조 개선과 기능 수정이 함께 필요할 수 있다. 이때 무엇을 보존하고 무엇을 의도적으로 바꾸는지 명시하고, 변경된 행동은 새 수용 조건으로 검증한다. 설명을 구분한다고 반드시 PR을 여러 개로 쪼개야 하는 것은 아니다.
원천 대조
Vigilantis의 변경 검증 Reference에 이미 있는 동작 보존·생성 입력 대조 원칙을 개인 지식으로 승격했다. 프로젝트의 상세 검증 절차는 원문이 소유한다. 2026-09-19 현재 본문을 읽고 아래 책 예제·Fowler의 정의와 대조했다.
WikiDocs 로그인 개선 예제는 비밀번호 처리뿐 아니라 응답 형식과 인증 수단도 바꾼다. 이를 외부 동작이 보존되는 리팩토링의 예로 그대로 채택하지 않는다. 예제만으로 인증 설계의 안전성이 확보됐다고 판단할 수도 없다.
- Martin Fowler, Refactoring: 관찰 가능한 동작을 유지한다는 정의의 직접 근거.
- 소프트웨어 분석설계 - WikiDocs: 책의 표현을 교정한 이유와 확인 범위.
- 요구사항의 변경 영향은 설계·구현·검증 연결로 추적한다
- 규칙은 소유한 가장 좁고 안정적인 공개 경계에서 깊게 테스트한다
- 요구사항에서 검증까지