개발기초 레거시 시스템 리팩토링하다가 겪은 문제들 (실무에서 배운 접근 방법)

10년 넘게 운영된 EMS 시스템 을 리팩토링하는 작업을 맡은 적이 있습니다. "코드를 깔끔하게 정리하면 되겠지"라고 가볍게 생각했는데, 실제로 시작해보니 예상보다 훨씬 조심스럽게 접근해야 하는 작업이었습니다. 이번 글에서는 그 과정에서 겪었던 문제와 배운 점을 정리해보겠습니다.

상황: 왜 리팩토링이 필요했나

오랜 기간 여러 개발자를 거치면서 코드 스타일이 제각각이었고, [비슷한 기능을 하는 코드가 여러 곳에 중복되어 있거나 / 함수 하나가 몇백 줄씩 되는 곳]이 많아서 신규 기능을 추가할 때마다 시간이 오래 걸리는 상황이었습니다.

문제 1: 어디부터 손대야 할지 감이 안 왔다

전체 코드베이스가 워낙 방대해서, 처음에는 어디서부터 시작해야 할지조차 판단이 서지 않았습니다.

시도했던 것: 전체를 한 번에 정리하려고 했다가, 며칠 지나서 "이 방식으로는 끝이 안 나겠다"는 걸 깨달았습니다.

해결: 전체를 다 고치겠다는 생각을 버리고, [최근 1년간 버그가 가장 많이 발생했던 모듈 / 신규 기능 추가가 예정된 영역]부터 우선순위를 정해서 좁혀 들어갔습니다. 범위를 좁히니 실제로 진행이 가능해졌습니다.

문제 2: 테스트 코드가 없어서 리팩토링이 무서웠다

기존 코드에 테스트 코드가 거의 없어서, 코드를 수정한 뒤 정말 기존과 동일하게 동작하는지 확신할 수가 없었습니다.

증상: 사소해 보이는 리팩토링 하나로 [운영 환경에서 예상치 못한 오류]가 발생한 적이 있었고, 이후로는 코드 수정 자체가 두려워졌습니다.

해결: 전체 테스트 커버리지를 한 번에 올리려 하지 않고, 리팩토링할 영역에 대해서만 최소한의 테스트(입력값을 넣었을 때 기존 코드와 동일한 출력이 나오는지 비교하는 수준)를 먼저 작성한 뒤에 리팩토링을 진행하는 방식으로 바꿨습니다.

문제 3: 다른 팀원들과의 작업 충돌

리팩토링을 진행하는 동안에도 다른 팀원들은 기존 코드에 기능을 계속 추가하고 있어서, 브랜치 충돌이 자주 발생했습니다.

해결: 리팩토링 작업을 큰 단위로 오래 붙잡고 있기보다, [작은 단위로 쪼개서 자주 머지]하는 방식으로 전환했습니다. 팀 전체에도 리팩토링 진행 상황을 공유해서, 같은 영역을 동시에 건드리지 않도록 사전에 조율했습니다.

마무리하며

이 경험을 통해 느낀 건, 레거시 리팩토링은 **"코드를 예쁘게 만드는 작업"이 아니라 "위험을 관리하면서 조금씩 개선하는 작업"**이라는 것이었습니다. 다음에 비슷한 작업을 맡게 된다면, 처음부터 범위를 좁히고, 최소한의 안전망(테스트)을 먼저 확보한 뒤에 시작할 것 같습니다.

오래된 시스템을 유지보수하고 계신 분들이라면, 전체를 다 고치려 하기보다 영향도가 큰 부분부터 좁혀서 접근하시는 걸 추천합니다.