소프트웨어가 나빠지고 있을지는 몰라도, 예전에는 끔찍했음

현대 소프트웨어의 품질 문제를 인정하더라도, 과거 소프트웨어가 더 좋았다는 향수는 1990년 이후 겪은 잦은 시스템 충돌과 작업 손실을 잊은 것임 물리 매체 출시에 필요한 최소 품질선은 있었지만, 드라이버와 운영체제의 결함, 취약한 보안, 수동 디스크 조각 모음처럼 사용자가 직접 감당해야 하는 문제가 많았음 Google Docs 팀에서 2010년 사용 행동을 측정했을 때, 이미 자동 저장 중인데도 Ctrl+S가 편집 외 행동 상위 5개에 들 만큼 작업 손실의 기억이 깊게 남아 있었음 Diablo II의 부정행위와 아이템 탈취, CPU 속도에 의존하던 프로그램의 호환성 문제는 소프트웨어 설계가 시행착오를 통해 개선된 사례임 현대 소프트웨어의 비대함과 복잡성, 에이전트 위임에 따른 이해력 약화는 문제지만, 프로세스 격리와 온라인 업데이트, 고수준 언어를 버리고 과거 개발 방식으로 돌아가고 싶지는 않음 품질 저하와 과거에 대한 향수는 별개임 다른 조건이 같다면 코드 생산량이 10배 늘 때 오류율이 10분의 1로 줄지 않으면 프로덕션 앱의 버그는 늘어남. 현재의 품질 저하 문제는 이전 글에서도 다룸 하지만 “예전에는 소프트웨어가 더 좋았다”, “과거의 프로그래밍 방법을 잊었다”, “수십 년째 품질이 하락했다”는 향수는 1990년 이후의 사용 경험과 맞지 않음 John Carmack처럼 프로그램 전체를 머릿속에 담고 잘 설계된 코드베이스를 수십 년간 다듬는 개발자도 있었지만, 당시 사용하던 소프트웨어 대부분을 그런 개발자가 만든 것은 아님 Windows 중심 환경과 물리 매체 출시 Windows 점유율은 전성기에 약 95% 였으며, 출처에 따라 몇 퍼센트포인트 차이가 있었음. 대부분의 사용자는 Intel 또는 AMD 프로세서를 탑재한 Windows PC를 썼음 iMac과 Debian 같은 대안도 있었지만 예외에 가까웠음 Mac에는 애플리케이션 공급의 제약이 있었음 고등학교 시절 Debian 설치 경험에서는 XF86Config를 편집하는 도구가 가장 인기 있는 앱처럼 느껴질 정도였음 당시 회사는 소프트웨어를 플로피 디스크, CD, ROM에 담아 포장하고 배송해야 했으므로, 출시한 버전이 처음부터 작동해야 하는 최소 품질선은 있었음 블루스크린과 저장되지 않은 작업 블루스크린은 Windows의 커널 패닉에 해당했으며, 작업 중이든 아무것도 하지 않든 시스템이 갑자기 멈출 수 있었음 주변기기에 동봉된 플로피 디스크나 CD로 설...