技術的負債の定義は色々あるが、大きく分けると、改修時に問題となるモノと、時間経過と共に問題となるモノの2パターン存在する。

前者（改修時に問題となるモノ）は開発効率は落ちるが、必ずしも返済の必要は無いモノ。
なぜならば、返済した箇所が今後の改修で、どれだけ使われるか読みきれないから。但し、上手く付き合わないと不具合発生率が高くなる。
また、リファクタリング（動作を変えずに作りやすくする事）は諸刃の剣で、自動テストのケース漏れか仕様理解が足りないと不具合を作るだけで、疲労感しか生まない。

一方、後者（時間経過と共に問題となるモノ）は必ず返済しなければならないモノ。
なぜならば、今まさに問題となっている、または今後、問題が表面化しそうだと気付いたから。
原因は異常系や負荷等の考慮不足の場合が多い。但し、一概にエンジニアの問題とは言えない。
経験不足や疲労で考慮できない事もあるが、スピードを優先して意図的にやらない事も多い。
また、システムには必ず制限事項が存在する。実際、AWSや他のサービスにも存在していて、無限にスケール出来る訳ではない。

しかし、人間は見たくないモノや理解出来ないモノは、無意識に見えなくなる。
この行為と技術的負債の掛け合わせが、（勝手に命名しましたが）思考的負債だと感じている。

スピート優先で作った人も、その不足を補う動きをした人も、制限事項を理解した上で、平等に称賛されるべきで、そうしないと、補う動きをする人は少なくなり、負債がどんどん大きくなって。。。（後は想像にお任せします）

他も同じだと思うが、目立つモノに目を奪われてはダメなんだろうなというお話でした。
誰かが誰かの仕事を支えている（某CMっぽいけど）