AI 레거시 리팩토링 (코드 이해, 테스트, 리스크)

레거시 코드 리팩토링

입사 3개월 차에 2009년산 PHP 코드를 건네받았습니다. 주석은 한 줄도 없었고, 함수 하나가 300줄을 넘었으며, 전역 변수가 40개 가까이 흩어져 있었습니다. 원작자는 이미 퇴사한 지 오래였고, 저는 그걸 "살려달라"는 요청을 받은 상태였습니다. 솔직히 처음 그 코드를 받았을 때 느낀 감정은 막막함보다는 일종의 배신감이었습니다. 면접 때는 "신규 기능 개발 위주"라고 들었는데, 입사하고 보니 첫 업무가 누구도 손대고 싶어 하지 않는 레거시였습니다. AI가 레거시 리팩토링을 쉽게 만들어준다는 말이 반은 맞고 반은 틀린 이유를, 3개월간 직접 겪으면서 정리하게 됐습니다.

코드 이해와 테스트: AI가 진짜 시간을 아껴주는 구간

솔직히 이건 예상 밖이었습니다. 가장 먼저 한 일은 문제의 함수를 AI에게 붙여넣고 "이게 뭘 하는 건지 설명해줘"라고 묻는 것이었는데, 돌아온 답이 꽤 정확했습니다. 주석이 전혀 없는 코드였는데도 "이 블록은 사용자 세션을 초기화하고, 이 분기는 결제 상태를 처리하는 것 같다"는 식으로 흐름을 짚어줬습니다. 제가 직접 며칠을 붙잡아야 할 코드를 몇 시간 안에 파악할 수 있었습니다.

제 개인적인 인상으로는, 이 단계에서 AI가 잘하는 이유는 따로 있다고 생각합니다. 사람은 코드를 읽을 때 "이게 왜 이렇게 짜여 있을까"라는 의문을 먼저 품고 거기서 멈추는 경향이 있는데, AI는 그런 감정적 마찰 없이 패턴 매칭만으로 흐름을 따라갑니다. 어떤 의미에서는 AI가 코드에 대한 존중심이 없다는 게 오히려 장점으로 작동한 셈입니다. 저는 "왜 이렇게 짰을까" 고민하느라 시간을 버렸는데, AI는 그냥 "이건 이런 동작을 한다"고만 말해줬습니다.

그다음이 테스트 작성이었는데, 여기서도 AI가 실질적인 도움이 됐습니다. 레거시 리팩토링에서 가장 먼저 해야 할 일은 현재 동작을 테스트로 고정하는 것입니다. 이를 특성화 테스트라고 부릅니다. 특성화 테스트란 리팩토링 전 코드의 실제 동작을 그대로 기록해두는 테스트로, 수정 이후에도 동작이 바뀌지 않았음을 검증하는 안전망 역할을 합니다. Michael Feathers가 레거시 코드를 다루는 핵심 전략으로 제시한 개념이기도 합니다.

문제는 사이드 이펙트가 너무 많아 어디서부터 테스트를 짜야 할지 막막하다는 점이었습니다. 사이드 이펙트란 함수가 반환값 외에 외부 상태를 변경하는 동작을 말하는데, 이게 많을수록 테스트 격리가 어려워집니다. AI에게 함수의 경계 조건을 테스트해달라고 요청하니, 정상 케이스, 엣지 케이스, 예외 케이스를 구분한 스켈레톤을 만들어줬습니다. 전부 그대로 쓸 수는 없었지만, 시작점이 생겼다는 것만으로 속도가 달랐습니다.

여기서 제가 따로 느낀 점이 있는데, AI가 만든 테스트 스켈레톤의 진짜 가치는 테스트 코드 자체가 아니라 "어디부터 시작해야 할지 모르겠다"는 마비 상태를 풀어준다는 데 있었습니다. 백지 상태에서 첫 줄을 쓰는 게 가장 어려운 작업인데, AI가 만든 초안을 고치는 건 심리적 부담이 훨씬 낮습니다. 이건 단순히 시간 단축의 문제가 아니라 작업을 시작하게 만드는 동기 부여의 문제였다고 생각합니다.

AI가 코드 이해와 반복 작업에서 시간을 아껴준다는 점은 실제로 경험해보니 맞는 말이었습니다. 특히 다음 세 구간에서 효과가 뚜렷했습니다.

• 주석 없는 레거시 코드의 로직 흐름 파악
• 특성화 테스트 스켈레톤 초안 작성
• 보일러플레이트 코드 생성 - 반복적으로 작성해야 하지만 실질적인 로직 변화가 없는 코드

GitHub가 공개한 개발자 설문에서도 Copilot 사용자의 상당수가 반복적인 코드 작성 시간이 줄었다고 응답한 바 있습니다. 제 경험도 이 통계와 크게 다르지 않았습니다.

리스크 판단: AI가 절대 대신할 수 없는 영역

그런데 리팩토링을 진행하면서 분명한 한계도 드러났습니다. 제가 직접 써봤는데, AI의 제안이 코드 구조상 더 깔끔해 보여도 실제로 적용하면 버그가 생기는 경우가 있었습니다.

예를 들어 전역 변수를 클래스 속성으로 옮기는 과정에서, AI는 일반적인 OOP 원칙에 따라 캡슐화된 구조를 제안했습니다. OOP란 데이터와 그 데이터를 처리하는 로직을 하나의 단위로 묶는 프로그래밍 패러다임입니다. 제안 자체는 교과서적으로 옳았지만, 문제는 그 전역 변수 중 일부가 다른 레거시 모듈에서 직접 참조되고 있다는 사실이었습니다. AI는 그 암묵적 계약을 알 방법이 없었습니다. 암묵적 계약이란 코드에 명시되지 않았지만 시스템 전체가 암묵적으로 의존하는 전제 조건을 뜻하는데, 오래된 레거시일수록 이런 계약이 많습니다.

이 사건을 겪고 나서 제가 내린 결론은 조금 더 냉정했습니다. AI는 "보이는 코드"만 분석합니다. 같은 저장소 안에 있더라도 import 관계가 명시적으로 드러나지 않은 의존성, 혹은 다른 배치 작업이나 크론잡에서 같은 전역 변수를 건드리는 경우는 AI의 시야 밖에 있습니다. 저는 이 일을 겪은 뒤로 AI의 리팩토링 제안을 적용하기 전에 반드시 grep으로 해당 변수나 함수명이 저장소 전체에서 어디에 쓰이는지 먼저 확인하는 습관을 들였습니다. 이건 AI가 대신해줄 수 없는, 순전히 제 손으로 해야 하는 작업이었습니다.

리팩토링에서 위험한 순간은 코드가 "더 나빠 보일 때"가 아니라 "더 좋아 보일 때"입니다. AI의 제안이 깔끔하고 논리적으로 보일수록, 그걸 그냥 적용하고 싶은 충동이 생깁니다. 그 충동을 참고 도메인 지식으로 검증하는 과정이 실제 리팩토링의 핵심이라는 걸, 저는 몇 번의 실수를 통해 배웠습니다.

저는 실제 리팩토링 과정에서 AI를 '제안자'로, 저를 '검토자'로 역할을 나눴습니다. 이 분기문을 전략 패턴으로 바꿀 수 있을지 물으면 AI가 장단점을 정리해줬고, 최종 결정은 항상 제가 도메인 지식을 근거로 내렸습니다. 전략 패턴이란 알고리즘을 클래스로 분리하여 런타임에 교체할 수 있게 만드는 디자인 패턴으로, 복잡한 분기문을 정리할 때 유효한 방법 중 하나입니다. Martin Fowler의 리팩토링 원칙에도 코드 동작을 바꾸지 않고 구조만 개선하라는 기본 전제가 있는데, AI는 그 경계를 스스로 판단하지 못합니다.

개인적으로 덧붙이고 싶은 비판이 하나 있습니다. AI는 "이 코드가 왜 이렇게 만들어졌는가"에 대한 역사적 맥락을 절대 알 수 없다는 점입니다. 어떤 코드는 비효율적으로 보여도 과거에 특정 장애를 막기 위해 일부러 그렇게 짜인 경우가 있습니다. 저는 한 번, AI가 제안한 대로 중복된 검증 로직을 하나로 통합했다가, 알고 보니 그 중복이 특정 결제 모듈의 타이밍 이슈를 우회하기 위한 의도적인 방어 코드였다는 걸 나중에 알게 됐습니다. 다행히 배포 전에 동료가 발견해서 큰 사고로 이어지지 않았지만, 그날 이후로 저는 "왜 이렇게 짰을까"라는 질문을 AI에게 묻는 대신, 그 코드와 가장 가까운 git blame 기록과 과거 커밋 메시지를 먼저 살펴보는 순서로 바꿨습니다.

3개월이 지난 뒤 결과는 이랬습니다. 함수 수는 절반으로 줄었고, 전역 변수는 거의 사라졌습니다. 테스트 커버리지는 0%에서 61%로 올라갔습니다. 테스트 커버리지란 전체 코드 중 테스트가 실행하는 비율을 뜻하며, 60% 이상이면 최소한의 안전망이 갖춰진 상태로 봅니다. 그리고 그 3개월 동안 서비스는 단 한 번도 다운되지 않았습니다.

레거시 리팩토링에서 AI는 도구입니다. 좋은 도구이지만, 도구는 쓰는 사람이 판단을 가지고 있을 때만 제대로 작동합니다. AI가 코드를 빠르게 파악해주는 동안, 그 코드가 돌아가는 비즈니스 맥락은 오직 제 머릿속에만 있었습니다. 그 비대칭이 AI와 협업할 때 절대 잊어서는 안 되는 전제라고 생각합니다. 레거시를 처음 맞닥뜨린 분이라면 먼저 AI에게 로직 설명을 요청해보는 것에서 시작해보시길 권합니다. 단, 제안을 따르기 전에 반드시 특성화 테스트를 먼저 갖춰두시기 바랍니다.

---

참고:
Martin Fowler – Refactoring (2018, Addison-Wesley) Michael Feathers – Working Effectively with Legacy Code (2004, Prentice Hall) GitHub Blog – "How developers use Copilot for refactoring" (2024) Sourcegraph Cody 공식 문서: https://sourcegraph.com/cody