코드가 나빠지는 데는 한계가 없다

건물과 달리 소프트웨어에는 물리적 붕괴 한계가 없어, 시스템이 계속 작동하는 동안에도 복잡성과 성능 저하가 끝없이 누적될 수 있음 Amazon 주문 처리 조직에서는 지식 소실과 미완료 재설계가 반복되면서, 기존 구조에 새 계층과 인력이 계속 남는 악순환이 이어짐 시스템을 완전히 멈추는 변경은 빠르게 되돌려도, 그전에 품질을 악화시킨 수천 건의 변경은 남으므로 작동 여부가 코드 품질을 보장하지 않음 기술 부채에는 파산 같은 초기화가 없음: 전면 재작성은 좀처럼 선택하기 어렵고, 별도 시스템을 만들어도 기존 사용 사례와 유지보수 의무는 사라지지 않음 언젠가 재작성으로 해결할 수 있다는 믿음은 현재의 결정을 악화시키며, 코드 품질을 지키려는 지속적인 노력을 대신할 수 없음 Amazon 주문 처리 조직에서 반복된 재설계 대학 졸업 직후 Amazon에 입사해 접한 레거시 주문 처리 시스템은 겉보기에는 데이터베이스에 정보를 기록하고, 다른 팀의 서비스에 유효성을 묻거나 장부 갱신을 요청하는 구조였음 당시 동료들은 제대로 구현한다면 유능한 엔지니어 24명 이내로 유지보수와 발전이 가능하다고 추산함 실제 조직은 수백 명 규모로, 시스템 전체의 작동 방식을 배우는 일이 불가능할 만큼 커지고 복잡해진 상태였음 조직 지식의 소실과 변경에 대한 두려움이 단순화를 가로막음 몇 년 넘게 머무르는 사람이 드물어, 코드는 손대기 두려운 ‘유령이 나오는 묘지’로 가득했음 주문 유형별 업무 규칙을 정한 사람들은 이미 떠났고, 규칙은 심하게 낡은 ‘살아 있는 문서’에 있거나 찾을 수 있는 어디에도 기록이 없었음 시스템 상당 부분이 팀 경계 너머에 있고 코드 접근도 쉽지 않아, 동작을 직접 추적하기 어려웠음 기존 시스템을 단순화하려는 노력도 충분한 보상을 받지 못함 누락된 주문 처리는 얽힌 서비스 의존 관계의 다른 쪽에서 문제가 발생한 뒤 호출 알림으로 드러남 이 피드백 덕분에 시스템은 계속 운영됐지만, 변경하기 어렵고 성능도 매우 나빴음 최신 Amazon 제품과 기능을 지원하는 새 계층은 계속 추가됐고, 기술 부채를 갚지 않는 조직은 ‘침몰하는 배’처럼 느껴졌음 아키텍처 개선 시도는 늘 있었지만, 같은 실패 주기를 반복함 새 관리자나 시니어 엔지니어가 문제를 발견하면 경영진도 개선에 동의했으나, 가용 엔지니어가 없어 인력과 팀을 추가함 계속 바뀌는 시스템을 제대로 이해하려면 수년이 필요했지만, 조직 정치상 설계에 그렇게 오래 쓰기 어려워 불완전...