기본은 리팩터링입니다. 다시 작성(rewrite)은 기존 시스템이 더 이상 허용 가능한 비용으로 요구사항을 충족하도록 진화할 수 없고, 그것을 하는 동안에도 가치를 계속 전달할 수 있을 때에만 정당화됩니다. 대부분의 "우리는 rewrite가 필요해"라는 직감은 사실 관리되지 않은 tech debt 문제이며, 점진적 리팩터링이 훨씬 적은 리스크로 해결합니다.
제가 추론하는 방식
- 핵심 아키텍처가 여전히 유효한가? 데이터 모델, 경계, 런타임이 새 요구사항까지 늘어날 수 있다면 리팩터링하세요. 근본 가정이 틀렸다면(잘못된 저장 패러다임, 확장 불가, 언어/플랫폼 수명 종료) rewrite가 진짜 후보가 됩니다.
- 변경 빈도는 어떤가? 거의 바뀌지 않는 코드는 예쁠 필요가 없습니다. 팀이 매일 작업하는 곳에 노력을 집중하세요.
- 현재 동작을 이해하고 있는가? rewrite는 수년간 부호화된 엣지 케이스 지식을 버립니다. 테스트도 스펙도 없다면, rewrite는 옛 버그를 다시 들여옵니다.