I'm going to write more about technical debt at a later date but it is a subject also worth covering at a legacy level.
Legacy code has a high level of technical debt by it's very nature, in following the series so far the debt is being managed and repaid. The danger you face is adding to the technical debt and never overcoming the debt mountain.
Consider very carefully the single responsibility principle, legacy code tends not to follow this principle and in the refactoring work your first aim is to strictly follow this principle. Failure to do so can result in code mixing concerns and in turns causes technical debt.
If you start to work with the code more, adding new code and failing to follow this principle can cause technical debt.
So why technical debt? Consider that when you leave the code behind and some else picks up the code if the code still has problems those problems need to be overcome, that takes time, resource, money (all debt to you, your project and your company). I do hear sometimes debt can be occured if a programmer is unable to work with the principle, such issues should be measured and balanced against the debt (what is the real cost).