레거시 개선은 죽은 코드를 안전하게 지우는 데서 시작한다

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

동작을 제대로 모르는 레거시를 모듈화하거나 프레임워크부터 올리기 전에 더는 쓰지 않는 코드를 증명하고 지운다. 살아 있는 시스템이 작아지면 운영하고 이해하기 쉬워진다. 삭제는 추가보다 어렵기 때문에 에디터에서 참조가 회색으로 보인다는 이유만 믿지 말고 런타임, 저장 데이터, 실제 소비자를 함께 확인해야 한다.

임시 조건은 업무가 끝난 뒤에도 남는다

날짜 조건과 과거 외부 협력사에 묶인 분기가 목적이 끝난 뒤에도 남기 쉽다. 그 위에 새 조건이 붙고, 시간이 지나면 누구도 안전하게 지워도 되는지 모른다. 이런 분기가 오랫동안 쌓인 시스템은 실제 동작보다 훨씬 크고 복잡해 보인다.

아키텍처 개편이나 프레임워크 업그레이드 전에 이 경로부터 줄이면 다뤄야 할 코드가 작아진다.

소스 참조만으로 런타임 사용을 알 수 없다

아무도 참조하지 않는 코드는 찾기 쉽다. 더 어려운 것은 메서드끼리는 서로 참조하지만 최상위 진입점이 호출되지 않는 경우다. 정적 검색에는 연결된 그래프로 보이지만 운영 요청은 그곳에 들어오지 않는다.

데이터베이스가 증거를 줄 수 있다. 오래된 유형을 처리하는 분기가 있는데 해당 데이터가 오랫동안 없을 수 있다. 반대로 죽었다고 생각한 경로에 최신 데이터가 계속 쌓일 수도 있다. 코드와 데이터를 함께 봐야 한다.

런타임 수집 도구도 단서가 된다. 다만 일부 클래스나 실행 경로만 관찰할 수 있다. 도구 결과는 조사 범위를 줄여 주지 그것만으로 삭제를 승인하지 않는다.

API는 실제 소비자를 확인해야 한다

사용하지 않는 것처럼 보이는 API 하나가 컨트롤러, 서비스, 리포지토리와 그 아래 의존성을 모두 살려 둔다. 최근 며칠만 보지 말고 해당 업무에서 가능한 가장 긴 주기의 액세스 로그를 확인한다. 1년에 한 번 호출되는 API는 대부분 기간에 죽어 보인다.

내부 API라면 호출 저장소를 열어 실제 사용 여부를 보고 소유 팀에도 묻는다. 액세스 로그와 이 확인 결과를 함께 살핀 뒤 API와 그 아래 호출 흐름을 삭제한다.

점진적으로 빠르게 정리한다

전체 정리를 한 번에 끝내려 하고 배포 확인마다 멈추면 템포가 너무 느려진다. 한 번의 완전한 청소를 기다리기보다 점진적으로, 속도감 있게 죽은 코드를 계속 줄인다.

죽은 코드 삭제는 레거시를 관리하는 핵심 작업이다. 살아 있는 코드가 작을수록 운영 부담도 작고, 더 큰 개편보다 사용하지 않는 경로를 먼저 정리해야 한다. 코드를 추가하는 일은 쉽지만 오래된 코드를 지워도 된다고 확인하는 일은 어렵다.