시스템을 리팩터링할지 아니면 처음부터 다시 작성할지 어떻게 결정하나요?

Question

IT Interview Practice · Accepted Answer

기본은 **리팩터링**입니다. 다시 작성(rewrite)은 기존 시스템이 더 이상 허용 가능한 비용으로 요구사항을 충족하도록 진화할 수 없고, 그것을 하는 동안에도 가치를 계속 전달할 수 있을 때에만 정당화됩니다. 대부분의 "우리는 rewrite가 필요해"라는 직감은 사실 관리되지 않은 tech debt 문제이며, 점진적 리팩터링이 훨씬 적은 리스크로 해결합니다.

## 제가 추론하는 방식

- **핵심 아키텍처가 여전히 유효한가?** 데이터 모델, 경계, 런타임이 새 요구사항까지 늘어날 수 있다면 리팩터링하세요. 근본 가정이 틀렸다면(잘못된 저장 패러다임, 확장 불가, 언어/플랫폼 수명 종료) rewrite가 진짜 후보가 됩니다.
- **변경 빈도는 어떤가?** 거의 바뀌지 않는 코드는 예쁠 필요가 없습니다. 팀이 매일 작업하는 곳에 노력을 집중하세요.
- **현재 동작을 이해하고 있는가?** rewrite는 수년간 부호화된 엣지 케이스 지식을 버립니다. 테스트도 스펙도 없다면, rewrite는 옛 버그를 다시 들여옵니다.

## 의사결정 프레임워크

| 신호 | 리팩터링 쪽 | rewrite 쪽 |
| --- | --- | --- |
| 아키텍처가 요구사항에 맞음 | 예 | 아니오 |
| 테스트/스펙 커버리지 | 낮거나 높음 | 동등성을 검증할 만큼 충분히 높음 |
| 점진적으로 출시 가능 | 예 | 어려움, 빅뱅 |
| 팀이 코드를 이해함 | 예 | 아니오, 원작자도 떠남 |

## 트레이드오프

- **리팩터링:** 낮은 리스크, 지속적 딜리버리, 그러나 진짜로 썩은 기반 위에서는 느림.
- **rewrite:** 깨끗한 백지, 그러나 **기능 동결 세금**을 내고, **이중 유지보수 비용**을 지며, 고전적인 두 번째 시스템 과잉 설계 함정의 리스크가 있음.
- **strangler-fig** 중간 경로를 선호하세요: 새 시스템을 옛것 옆에 세우고, 트래픽을 점진적으로 라우팅하며, 옛것을 조각조각 삭제합니다. 리팩터링 수준의 리스크로 rewrite의 이점을 줍니다.

## 함정

- 비즈니스 비용이 아니라 **미관이나 이력서를 위한** 이유로 rewrite하기.
- 숨은 동작을 과소평가하기; 항상 현재 동작을 테스트로 먼저 특징지으세요.
- 아무것도 출시하지 않는 여러 분기짜리 빅뱅 rewrite — 모멘텀과 신뢰가 둘 다 붕괴합니다.

## 왜 중요한가

리팩터 대 rewrite 결정은 Tech Lead가 내리는 가장 레버리지 높은 결정 중 하나입니다. rewrite 쪽으로 잘못 판단하면 1년간 딜리버리를 동결하고도 실패할 수 있고; 리팩터링 쪽으로 잘못 판단하면 속도를 서서히 흘립니다. 그것을 취향 결정이 아니라 비용과 리스크 결정으로 규정하는 것이 시니어의 판단력을 선호와 구분 짓습니다.

신호	리팩터링 쪽	rewrite 쪽
아키텍처가 요구사항에 맞음	예	아니오
테스트/스펙 커버리지	낮거나 높음	동등성을 검증할 만큼 충분히 높음
점진적으로 출시 가능	예	어려움, 빅뱅
팀이 코드를 이해함	예	아니오, 원작자도 떠남

제가 추론하는 방식

의사결정 프레임워크

트레이드오프

함정

왜 중요한가

관련 질문