legacy 시스템을 언제 refactor, replace, 또는 retire 해야 합니까?

Question

IT Interview Practice · Accepted Answer

legacy 시스템은 불편하지만 종종 가치 있습니다, 비즈니스를 굴립니다. **refactor, replace, retire** 결정은 낡은 코드에 대한 혐오가 아니라 비용과 가치로 이끌어야 합니다. "낡고 추하다"는 이유가 아니고, "우리에게 비용이 든다"가 이유입니다.

## 의사결정 가이드

```text
REFACTOR(제자리 개선) 할 때:
  - 핵심 로직이 건전하다; 비즈니스 가치를 지키고 있다
  - 문제가 국소적이다; 점진적으로 개선할 수 있다

REPLACE(rewrite/migration) 할 때:
  - 중요한 작업을 막고 점진적으로 고칠 수 없다
  - 합리적 기간에서 유지보수 비용 > 재구축 비용
  - 점점 커지는 보안 또는 신뢰성 책임이다

RETIRE(완전 제거) 할 때:
  - 그 가치가 더 이상 어떤 유지보수 비용도 정당화하지 않는다
  - 사용이 줄었다; 더 단순한 경로가 존재한다
```

## rewrite 함정을 조심하라

전면 rewrite는 유혹적이고 종종 재앙적입니다, 예상보다 오래 걸리고, 옛 버그를 재도입하며, 그 사이 작동하던 시스템이 썩습니다. 점진적 refactoring이나 strangler-fig replacement를 선호하십시오. 점진적 경로가 진정으로 닫혔을 때만 전면 rewrite에 손을 뻗으십시오.

## 구체적인 예시

monolith가 고통스럽지만 잘 돌아가고 당신의 bottleneck이 아니라면, 최악의 모듈을 refactor하고 rewrite하지 마십시오. 그러나 내년에 보안 지원이 끊기는 database 버전에 있고 업그레이드 경로가 없는 시스템은, 강제된 replacement입니다, 그리고 신중히 계획하십시오.

## 함정

감정적 결정: 유행에 뒤떨어졌다고 충분히 좋은 시스템을 replace하거나, sunk cost 때문에 죽어가는 시스템에 매달리는 것. 비용과 가치로 결정하십시오.

## 왜 중요한가

불필요한 rewrite는 수년을 낭비하고 이미 해결된 문제를 재도입하며, 방치된 legacy는 째깍거리는 시한폭탄이 됩니다.

이 결정을, 미학이 아니라 증거로 제대로 내리는 것은 senior TL이 내리는 가장 고위험 판단 중 하나입니다.

의사결정 가이드

rewrite 함정을 조심하라

구체적인 예시

함정

왜 중요한가

관련 질문