소프트웨어는 건물처럼 물리적으로 무너지지 않기 때문에, 시스템이 계속 작동하는 한 복잡성과 성능 저하가 끝없이 누적될 수 있습니다. 이는 마치 끝없이 층을 올릴 수 있는 추상적인 건물과 같습니다. 아마존(Amazon)의 주문 처리 조직은 이러한 문제에 직면하여, 지식 소실과 미완료 재설계가 반복되면서 기존 구조에 새로운 계층과 인력이 계속 추가되는 악순환을 겪었습니다. 시스템이 '작동'하고 있다는 사실이 코드 품질을 보장하지 않으며, 치명적인 변경만 빠르게 되돌려질 뿐 수많은 품질 저하 변경은 그대로 남아 기술 부채(technical debt)가 쌓이게 됩니다.
아마존에 갓 입사한 엔지니어는 수백 명 규모의 팀이 유지보수하는 레거시 주문 처리 시스템을 접했습니다. 이 시스템은 겉보기에는 간단했지만, 실제로는 너무 커지고 복잡해져 전체 작동 방식을 이해하는 것이 불가능했습니다. 몇 년 이상 근무하는 사람이 드물어 조직 지식(organizational knowledge)이 소실되고, 코드는 '유령이 나오는 묘지'처럼 아무도 손대기 두려워하는 상태가 되었습니다. 시스템 단순화를 위한 아키텍처 개선 시도는 늘 있었지만, 불완전한 정보로 시작된 재설계는 결국 기존 아키텍처에 새로운 잔재만 남기고 주도 엔지니어는 승진 후 떠나는 패턴을 반복했습니다. 마이그레이션(migration)은 고통스럽고 인기가 없어 끝내지 못한 채, 늘어난 인력만 남게 되는 상황이 이어졌습니다.
이러한 기술 부채는 사업에 실제적인 위협이 됩니다. 아마존처럼 현금 흐름이 풍부한 기업은 내부 부실을 어느 정도 견딜 수 있지만, 소프트웨어 품질에 민감한 사업 모델에서는 나쁜 소프트웨어가 경쟁사에 기회를 줄 수 있습니다. 기술 부채는 금융 부채처럼 파산으로 초기화되지 않으며, 전면 재작성(rewrite)은 거의 불가능한 선택지입니다. 대신 아마존 같은 대기업은 별도 시스템(side-channel)을 구축하여 새로운 사용 사례를 처리하곤 하지만, 기존 시스템의 유지보수 의무는 그대로 남아 과거를 완전히 지우는 초기화가 될 수 없습니다. 결국, 소프트웨어 품질을 높게 유지하려면 '언젠가 재작성으로 해결될 것'이라는 환상 대신, 침몰을 막기 위한 지속적인 노력이 필수적입니다. 변수 이름 변경, 주석 추가, 절차 문서화 및 자동화, 테스트 보강과 같은 작은 개선의 축적이 장기적으로 더 큰 변화를 가능하게 합니다.