리팩터링 (Refactoring)

리팩터링(Refactoring)은 소프트웨어의 외부에서 관찰되는 동작을 유지하면서 내부 코드 구조를 개선하는 작업입니다. 같은 입력에 대한 결과와 외부에서 사용하는 기능은 보존하고, 코드를 이해하거나 수정하기 쉽게 바꿉니다. 긴 함수의 일부를 분리하거나 역할에 맞는 이름을 붙이는 등 작은 변환을 이어 가며 기존 동작이 유지되는지 확인합니다.

동작을 유지하는 구조 변경

마틴 파울러의 리팩터링 정의는 외부 동작을 바꾸지 않고 내부 구조를 재구성하는 기법으로 설명합니다. 코드를 이해하기 쉽고 수정 비용이 낮은 형태로 바꾸는 것이 목적입니다. 화면에 새 버튼을 넣는 기능 추가와 달리, 사용자가 하는 일과 얻는 결과는 유지됩니다. 파일 수나 코드 줄 수가 줄었는지만으로 판단하기보다, 무엇을 보존하면서 어떤 구조를 개선했는지 살핍니다.

주문 금액을 계산하는 코드에서 할인 조건 확인과 표시 문구 생성이 한 함수에 섞여 있으면 각 부분을 읽기 어렵습니다. 역할이 다른 부분을 나누고 그 역할을 드러내는 이름을 붙이면, 다음 수정 때 해당 부분을 찾아가기 수월해집니다. 이때 할인율이나 금액의 반올림 방식을 바꾸면 계산 결과도 달라집니다. 구조를 정리하는 과정에서는 기존 계산 규칙을 그대로 옮기고, 규칙 변경은 별도로 다룹니다.

버그 수정은 잘못된 동작을 의도한 동작으로 바꾸는 작업이므로 동작 보존을 목표로 하는 리팩터링과 구분됩니다. 한 작업 안에서 둘을 할 수는 있지만, 구조 변경과 동작 변경이 어느 부분인지 분리해 보면 검토하기 쉽습니다. 코드 전체를 새로 작성했다는 사실만으로도 리팩터링이 성립하지 않습니다. 관찰 가능한 동작을 유지했는지와 어떤 구조 변환을 거쳤는지가 설명돼야 합니다.

함수 추출로 나누는 코드의 역할

마틴 파울러의 함수 추출 예시는 청구 내역을 출력하는 함수에서 고객 이름과 금액을 표시하는 부분을 별도 함수로 옮깁니다. 원래 위치에서는 새 함수를 호출하고, 필요한 금액을 인수로 전달합니다. 출력할 내용은 유지하면서 ‘상세 내용을 표시한다’는 역할에 이름을 붙인 형태입니다. 함수를 분리했다는 사실과 기능을 새로 추가했다는 사실이 어떻게 다른지 보여 주는 예시입니다.

코드를 다른 함수로 옮기면 그 코드가 필요로 하는 값과 바꾸는 값을 확인하게 됩니다. 기존 함수 안에서는 바로 읽을 수 있던 값도 분리한 위치에 따라 인수로 전달해야 할 수 있습니다. 결과를 호출한 쪽에 돌려주는지, 외부 상태를 바꾸는지도 보존 대상입니다. 같은 동작을 유지하려면 코드와 함께 값이 오가는 관계까지 옮깁니다.

함수 이름은 분리한 코드의 역할을 읽는 단서가 됩니다. 청구 상세를 표시하는 부분과 합계를 계산하는 부분이 구분돼 있으면, 표시 문구를 바꿀 때 계산 과정을 모두 읽지 않아도 관련 위치를 찾을 수 있습니다. 반대로 서로 다른 일을 하는 코드까지 같은 함수로 묶으면 호출부가 짧아져도 역할은 흐려집니다. 추출 여부는 줄 수만으로 정하지 않고, 함께 이해하고 변경할 내용인지에 따라 판단합니다.

작은 변경과 동작 보존의 확인

마틴 파울러의 작업 방식 설명은 작은 변환을 이어 가며 각 단계 뒤에도 시스템이 동작하도록 유지하는 방식을 강조합니다. 한 번에 바꾸는 범위가 작으면 문제가 생겼을 때 방금 바꾼 부분부터 살필 수 있습니다. 같은 자료는 도구 지원이 없는 경우에도 작은 단계와 잦은 테스트로 실수를 찾는다고 설명합니다. 구조 변경의 크기와 확인 간격을 연결하는 접근입니다.

변경 전후에 같은 테스트를 실행하면 확인 대상의 동작이 유지되는지 비교할 수 있습니다. 금액 계산이라면 일반 입력뿐 아니라 할인 조건의 경계값과 비어 있는 입력을 어떻게 처리하는지도 비교 대상이 됩니다. 테스트에 포함하지 않은 동작까지 자동으로 증명되는 것은 아니므로, 수정한 코드가 영향을 미치는 범위와 테스트 범위를 함께 봅니다. 출력 결과뿐 아니라 외부에 저장하는 값이나 호출하는 작업이 달라졌는지도 확인합니다.

개발 도구가 함수 추출을 자동으로 수행하거나 AI가 구조 변경안을 작성해도 동작 보존이라는 판단 기준은 같습니다. 제안된 변경에서 기능이나 계산 규칙이 함께 달라졌다면 그 부분을 구분해 검토합니다. 코드가 읽기 쉬워졌다는 평가와 실행 속도가 빨라졌다는 평가는 서로 다릅니다. 성능 개선까지 주장하려면 처리 시간이나 자원 사용량처럼 해당 주장을 확인할 측정 근거가 추가로 필요합니다.