기능은 되는데 수정할수록 고장나는 AI 코드: 구조·중복·결합도

무료 배송 기준을 바꿨는데 장바구니와 결제 화면의 금액이 달라진다면, 수정한 줄 밖에도 같은 규칙이 남아 있을 수 있습니다. 지금의 화면이 동작한다는 사실만으로 다음 변경의 영향을 알 수는 없습니다. 마틴 파울러의 리팩터링 정의는 관측 가능한 동작을 유지하며 내부 구조를 작은 변경으로 개선하는 과정을 설명합니다.

AI가 작성한 코드에도 같은 판단 기준을 적용합니다. 파일 수와 함수 길이를 먼저 목표로 삼으면 코드가 나뉜 뒤에도 규칙의 소유자가 불분명할 수 있습니다. 어느 요구가 바뀔 때 어떤 부분이 함께 바뀌어야 하는지부터 추적하면 구조를 고칠 지점이 드러납니다.

같은 규칙의 복사와 닮은 코드를 구분하기

가상의 쇼핑 앱은 할인 적용 뒤 상품 금액이 5만 원 이상이면 배송비가 없고, 그보다 적으면 3천 원을 받습니다. 예시의 금액과 규칙은 구조 설명을 위해 정한 값이며 실제 상점의 정책이나 실행 결과가 아닙니다. 장바구니, 결제, 주문 생성 코드에 같은 조건이 각각 들어 있으면 기준 금액을 바꿀 때 세 위치를 맞춰 고쳐야 합니다.

세 함수의 이름이 달라도 같은 규칙의 복사일 수 있습니다. cartTotal에서는 합계에 배송비를 더하고, checkoutSummary에서는 무료 배송 문구를 만들고, createOrder에서는 최종 금액을 저장하더라도 같은 기준을 판단합니다. 검색으로 숫자만 찾으면 설정 파일이나 다른 표현으로 작성한 조건을 놓칠 수 있어, 각 값이 만들어지는 흐름도 함께 읽습니다.

반대로 3천 원이라는 숫자가 같다고 배송비와 반품 수수료를 한 상수로 합치면 두 정책을 함께 바꾸게 됩니다. 배송 정책을 바꿀 때 반품 정책이 유지되어야 한다면 서로 다른 변경 책임입니다. 공통 함수로 묶을지는 코드 모양과 변경 이유를 함께 보고 판단합니다.

겉으로는 중복이 없어져도 공통 함수에 여러 정책의 예외 플래그가 쌓일 수 있습니다. isReturn, isAdmin, isPreview 같은 인자가 생길 때는 호출자가 어떤 업무를 맡기는지 확인합니다. 하나의 함수가 서로 다른 이유로 변하는 규칙을 모두 소유하면, 작은 수정의 영향도 다시 넓어집니다.

데이터의 원본, 계산값, 과거 기록을 나누기

React의 상태 구조 원칙은 기존 상태에서 계산할 수 있는 값을 별도 상태로 중복 보관하지 않도록 권합니다. 같은 정보를 여러 상태에 복사하면 갱신 때 서로 맞춰야 하고, 모순된 조합이 생길 수 있기 때문입니다. 이 원칙은 React 화면 상태에 대한 설명이며 모든 캐시와 저장 데이터를 없애라는 규칙으로 확장하지 않습니다.

장바구니의 상품 목록과 합계를 각각 수정 가능한 상태로 두었다면 상품 삭제 뒤 합계 갱신이 빠지는 경로를 찾습니다. 합계가 현재 상품 목록에서 계산되는 값이라면, 원본 목록을 바꿨을 때 화면이 같은 계산 경로를 쓰도록 정리할 수 있습니다. 별도 값을 보관할 이유가 있다면 갱신·무효화의 책임도 함께 설명할 수 있어야 합니다.

확정된 주문의 배송비는 성격이 다릅니다. 그때 적용한 금액을 보존하려는 값이라면 현재 정책으로 매번 다시 계산할 수 없습니다. 이 예시는 주문 생성 시 상품 금액, 배송비, 적용한 정책 버전을 확정해 저장하고 영수증은 그 값을 읽도록 정합니다. 과거 거래를 보존하는 복사와 실시간 계산을 중복 보관하는 상태를 같은 문제로 묶으면 기존 주문 표시가 바뀔 수 있습니다.

자료마다 값을 정하는 주체, 변경 시점, 가리키는 사실의 시점을 적으면 원본을 고를 수 있습니다. 서버 저장값, 화면의 편집 초안, 캐시된 값이 모두 존재할 수 있지만 세 값이 달라도 되는 기간과 합쳐지는 순간은 설명돼야 합니다.

호출 관계를 따라 변경의 바깥 경계를 찾기

함수 이름이나 반환 형식을 바꾸면 호출자도 영향을 받습니다. 파울러의 인터페이스 변경 설명은 모든 호출자를 함께 바꾸는 조건을 강조하며, 외부에 공개한 인터페이스에는 더 주의가 필요하다고 설명합니다. 내부 함수의 새 이름을 적용한 일과 외부 사용자가 쓰는 API의 계약을 바꾸는 일은 변경 범위가 다릅니다.