legacy 시스템은 불편하지만 종종 가치 있습니다, 비즈니스를 굴립니다. refactor, replace, retire 결정은 낡은 코드에 대한 혐오가 아니라 비용과 가치로 이끌어야 합니다. "낡고 추하다"는 이유가 아니고, "우리에게 비용이 든다"가 이유입니다.
의사결정 가이드
text
REFACTOR(제자리 개선) 할 때:
- 핵심 로직이 건전하다; 비즈니스 가치를 지키고 있다
- 문제가 국소적이다; 점진적으로 개선할 수 있다
REPLACE(rewrite/migration) 할 때:
- 중요한 작업을 막고 점진적으로 고칠 수 없다
- 합리적 기간에서 유지보수 비용 > 재구축 비용
- 점점 커지는 보안 또는 신뢰성 책임이다
RETIRE(완전 제거) 할 때:
- 그 가치가 더 이상 어떤 유지보수 비용도 정당화하지 않는다
- 사용이 줄었다; 더 단순한 경로가 존재한다
rewrite 함정을 조심하라
전면 rewrite는 유혹적이고 종종 재앙적입니다, 예상보다 오래 걸리고, 옛 버그를 재도입하며, 그 사이 작동하던 시스템이 썩습니다. 점진적 refactoring이나 strangler-fig replacement를 선호하십시오. 점진적 경로가 진정으로 닫혔을 때만 전면 rewrite에 손을 뻗으십시오.
구체적인 예시
monolith가 고통스럽지만 잘 돌아가고 당신의 bottleneck이 아니라면, 최악의 모듈을 refactor하고 rewrite하지 마십시오. 그러나 내년에 보안 지원이 끊기는 database 버전에 있고 업그레이드 경로가 없는 시스템은, 강제된 replacement입니다, 그리고 신중히 계획하십시오.