레거시 코드 개선: 특성 테스트와 작은 변경 단위
기술 부채를 구체적인 위험으로 기록하고 리뷰와 AI 제안 검증에 적용하는 절차입니다.
레거시 코드를 고칠 때 ‘코드가 지저분하다’만으로 작업을 시작하면 범위가 커지기 쉽습니다. 먼저 어떤 변경이 어렵고 어떤 실패가 반복되는지 적습니다. 기존 동작을 기록하고 작은 단위로 바꾸면 개선 효과와 회귀 위험을 함께 검토할 수 있습니다.
기술 부채를 관찰 가능한 항목으로
가상의 할인 계산 모듈을 예로 보겠습니다. ‘리팩터링 필요’ 대신 ‘할인 조건 추가 시 세 파일을 함께 수정해야 하고 경계값 회귀가 두 번 발생했다’라고 씁니다. 횟수는 실제 기록이 있을 때만 적고, 모르면 추정으로 표시합니다.
| 항목 | 기록 예시 |
|---|---|
| 영향 | 할인 정책 변경 때 기존 고객 계산이 바뀔 위험 |
| 근거 | 관련 버그와 변경 파일 링크 |
| 첫 작업 | 현재 입력·출력 사례를 테스트로 고정 |
| 완료 조건 | 정책별 계산 경계를 분리하고 회귀 사례 통과 |
| 보류 비용 | 다음 정책 추가 때 같은 부분을 다시 수정 |
이렇게 쓰면 새 기능과 비교해 어떤 위험을 먼저 줄일지 판단하기 쉽습니다.
특성 테스트와 정책 테스트 나누기
기존 함수가 실제로 반환하는 결과를 기록하는 테스트는 구조 변경의 안전망이 됩니다. 다만 현재 결과가 올바른 정책인지까지 증명하지는 않습니다. 알려진 버그가 있다면 기존 동작 기록과 수정 후 기대 동작을 구분합니다.
정상값뿐 아니라 빈 입력, 중복, 경계값, 실패 조건을 고릅니다. 내부 메서드 호출 순서를 전부 고정하면 구현을 바꾸기 어려워지므로 결과 중심 테스트를 우선합니다.
리뷰할 수 있는 변경 크기 유지하기
이름 변경, 책임 분리, 동작 변경을 가능하면 나눕니다. 한 변경에서 포맷과 정책까지 모두 바꾸면 리뷰어가 실제 차이를 찾기 어렵습니다. 함수 이름은 수행하는 행동을, 타입과 변수는 데이터의 의미를 드러내도록 정합니다.
리뷰에서는 스타일보다 데이터 손실 가능성, 권한 경계, 오류 처리, 이전 버전과의 호환을 먼저 확인합니다. 대기 시간이 길다면 리뷰 요청 크기와 담당자 지정 방식을 점검합니다. 더 많은 코드 생성만으로 리뷰 병목이 해결되지는 않습니다.
AI가 제안한 변경도 같은 기준으로
AI가 만든 코드는 실제로 존재하는 API를 사용하는지, 의존성을 불필요하게 늘리지 않는지, 비밀값을 노출하지 않는지 확인합니다. 테스트가 통과해도 누락된 요구사항은 남을 수 있으므로 제안된 설명과 코드의 동작을 비교합니다.
완료 후에는 줄 수 감소보다 다음 변경이 쉬워졌는지와 회귀 사례가 보호되는지 기록합니다. 추측한 시간 절감이나 검증하지 않은 생산성 수치를 성과처럼 쓰지 않습니다.