- 저장 용량을 여러 차례 늘려도 사용량이 함께 증가하며, 81명이 참여한 Mastodon 설문에서도 약 절반이 디스크를 75% 넘게 사용하고 있었음
- 빈 상태보다 가득 찬 상태에 도달할 방법이 많다는 엔트로피 논리로 일부 설명할 수 있지만, 사용자 행동까지 완전히 설명하지는 못함
- 한계에 이르기 전까지 정리를 미루다가 당장 필요한 만큼만 지우는 행동이 디스크를 상시 포화 상태에 머물게 함
- 느려진 소프트웨어, 누적된 기술 부채, 혼잡한 도로, 빡빡한 일정도 고통이 임계점에 도달한 뒤에야 대응한다는 같은 패턴을 보임
- 전체 자원보다 작은 인위적 제약을 예산처럼 설정하면 성급한 최적화를 피하면서도 문제를 한계점까지 방치하지 않을 수 있음
저장 공간이 계속 가득 차는 이유
- 루트 드라이브는 사용 가능한 0.47TB 가운데 17GB만 남아 여유 공간이 3% 이며, 추가로 설치한 12TB 드라이브도 140GB, 약 1%만 남아 있음
- 저장 공간은 1990년대 약 80MB에서 수십 TB까지 여러 차례 두 배로 늘었지만 여전히 대부분 사용 중임
- 정리할 파일을 찾아주는 소프트웨어가 오래전부터 존재한다는 사실도 이 문제가 지속돼 왔음을 보여줌
- Mastodon 설문 응답자 81명 중 약 절반은 하드 드라이브를 75% 넘게 사용하고 있어, 저장 공간이 비어 있기보다 가득 찬 경우가 흔했음
- 빈 디스크보다 가득 찬 디스크를 구성하는 상태가 더 많으므로, 저장량을 고려하지 않고 상태를 무작위로 바꾸면 포화 상태로 향한다는 엔트로피 기반 해석이 가능함
- 그러나 디스크는 더 저장할 수 없을 때까지 문제로 느껴지지 않고, 그 시점에는 지나치게 어질러져 모든 파일의 삭제 여부를 판단하기 어려움
- 사용자는 시간을 벌 만큼만 정리하고 중단하므로 디스크가 다시 빠르게 한계에 도달함
- 저장 용량을 몇 자릿수 규모로 늘려도 이러한 행동은 바뀌지 않음
고통의 한계점과 인위적 제약
- 문제가 견딜 수 없는 수준에 이를 때까지 대응을 미루는 패턴은 여러 영역에서 반복됨
- 소프트웨어는 너무 느려질 때까지 최적화하지 않아 대체로 계속 느린 상태에 머묾
- 기술 부채는 코드 작업이 고통스러워져 리팩터링이 불가피할 때까지 쌓임
- 경험이 적은 개발자는 아예 다시 시작하기도 해 대부분의 코드베이스가 어수선해짐
- 도로망은 감당하기 어려울 만큼 혼잡해진 뒤에야 확장함
- 식단은 더 큰 바지를 사야 할 때까지 관리하지 않음
- 전업 직장을 그만두고 자영업자가 되어 의무와 지시가 사라져도 일정은 이전만큼, 때로는 그 이상 바쁘게 채워짐
- 한계점까지 기다리면 진행 중에 조금씩 해결했을 때보다 처리해야 할 일이 훨씬 커지지만, 반대로 성급한 최적화 역시 바람직하지 않음
- 두 문제를 조정하려면 Jevons paradox를 활용해 전체 가용 자원보다 작은 실질적 제약을 두고, 그 범위에 맞춰 최적화할 수 있음
- 개인 재무에서는 이를 예산이라고 부르지만 다른 분야에서는 같은 원리가 반복해서 간과됨
- Raspberry Pi에 소프트웨어를 배포해 직접 사용하며 최적화하면 Threadripper에서도 빠르게 동작함
- 80×25 터미널의 Vim에서 탐색 가능한 코드베이스는 강력한 현대식 IDE에서도 탐색할 수 있음
- 자원과 기능이 늘어나면 더 많은 일을 할 수 있을 것 같지만, 실제로는 같은 일을 더 큰 비용으로 수행하게 만들기도 함