Technical debt accrues after managers/teams make hard decisions about time and resources. We don’t have unlimited resources, and we don’t have unlimited time.
Refactoring addresses technical debt after the project has already been designed and started.
Ref: Solution Intent Defintion Document: https://docs.google.com/document/d/1ADF1xWYQ2j0vGfU-LmjrZcwRw8FmETHhWiNp89syOZ8/edit
The definition of refactoring is to make changes to the structure of the design in order to improve a set of non functional or quality factors. Although it is a very common practice in coding, the underlying principles are equally valid in higher level architectural work. However, since it involves structural changes, refactoring can lead to significant amounts of work. Thus refactoring is something that needs to be done continuously.
Refactoring is also an alternative to trying to come up with the “perfect” structure upfront. Often the common patterns, base classes, categories and relationships are only determined once a set of entities exist that exposes these commonalities. For this reason optimising of the system needs to be done as the design proceeds rather than aiming upfront to achieve that goal.