코드가 얼마나 나빠질 수 있는지에는 한계가 없다

방치된 코드베이스에 대한 끈질긴 비유가 있습니다: 침몰하는 배. 그것은 결국 끝이 있음을 암시합니다 — 물이 갑판에 닿고 모두가 버리는 지점. 하지만 그것은 오해를 불러일으킵니다. Zach Kehs가 그의 에세이 나쁜 코드에는 한계가 없다에서 주장하듯이, 물리적인 배와 달리 소프트웨어 시스템에는 본질적인 구조적 한계가 없습니다. 끝없이 복잡성을 추가할 수 있습니다. 그것은 무너지지 않을 것입니다. 단지 느려지고, 변경하기 어려워지고, 작업하기 더 고통스러워질 뿐입니다.

아마존의 실제 사례

Kehs는 아마존에서 주문 처리 팀에 있었던 10년 전의 경험을 설명합니다. 시스템의 핵심 기능 — 데이터베이스에 쓰고 다른 서비스를 호출하는 — 은 24명의 엔지니어가 유지 관리할 수 있어야 했습니다. 그러나 조직에는 수백 명의 사람들이 있었습니다. 엔지니어가 떠나면서 제도적 지식이 침식되어 코드에 '유령이 출몰하는 묘지'가 남았습니다. 비즈니스 규칙은 종종 문서화되지 않았고, 시스템은 팀 경계를 넘나들어 추적이 불가능했습니다.

몇 년마다 새로운 시니어 채용자가 재아키텍처를 시도했습니다. 항상 실패했습니다. 시스템은 완전히 이해하기에 너무 복잡했고, 성급한 승진 주기는 불완전한 정보로 설계된 수정을 의미했습니다. 결과: 아키텍처에 접목된 새로운 레이어, 결코 사라지지 않는 인원 증가, 그리고 반복되는 사이클.

비유가 왜 무너지는가

저자의 핵심 통찰: 사업은 침몰할 수 있지만 — 소프트웨어 자체는 그렇지 않습니다. 코드는 항상 더 나빠질 수 있습니다. 항상 또 다른 간접 레이어, 또 다른 성능 저하가 있습니다. 그러나 아이러니하게도, 코드가 어떤 종류의 '바닥'에 도달하기 전에 사업이 죽는 경우가 많습니다.

레거시 시스템을 다루는 개발자에게 얻을 수 있는 교훈은 '침몰하는 배'가 거짓된 위안을 준다는 것입니다. 상황이 마법처럼 리셋되는 돌아올 수 없는 지점은 없습니다. 그러한 시스템에 있다면, 침몰하기를 기다리는 것이 아니라, 변경 비용이 현상 유지 비용보다 크다는 결정을 누군가가 내리기를 기다리는 것입니다.

대규모 조직에서 기술 부채의 메커니즘에 대한 더 깊은 성찰을 위해 전체 에세이를 읽어보세요.