단, 내가 이러한 규칙을 알려주었다고 해서 미래에 관한 예측을 근거로 하여 설계에 관한 결정을 내리라는 뜻으로 오해하는 사람은 없기를 바란다. 설계 관련 결정은 미래 예측을 기반으로 내려서는 안 된다. 예측한 모든 일은 확률일 뿐 모든 예측에는 틀릴 가능성이 내포되어 있기 때문이다.

소프트웨어의 미래 변화상에 관한 예측 말고 현재 데이터, 현재 소프트웨어 시스템을 기반으로 결정을 내릴 때 올바른 방향으로 향할 가능성이 훨씬 높다. 소프트웨어 설계 중 발생하는 실수는 미래에 무언가를 반드시 해야 한다고 (혹은 절대 하지 않을 거라고) 가정한 데서 비롯될 때가 많다.

특히 나중에 쉽게 고칠 수 없는 소프트웨어를 다룰 때 이 원칙을 꼭 기억하라. 변화를 완전히 피할 수는 없다. 하지만 소프트웨어를 바보 같을 정도로 단순화해두면 수정해야 할 일도 줄어든다. 환경 변화에 발맞추어 소프트웨어를 수정하지 않는다면 그 때문에 시간이 지남에 따라 소프트웨어의 품질과 유용성이 저하되긴 할 것이다. 하지만 복잡한 시스템과 비교한다면 저하되는 속도가 느릴 것이다.

원칙적으로는 원한다면 언제든지 소프트웨어를 업데이트할 수 있어야 한다. 누군가에게 ‘업그레이드’해달라고 부탁하지 않아도 앱이나 웹 사이트를 즉각적으로 업데이트할 수 있는 게 웹의 큰 장점이다. 하지만 사실 모든 플랫폼에서 늘 그렇게 할 수 있는 건 아니다. API처럼 때로 십 년 이상 아주 약간의 변화만 주면서 계속 써야 하는 코드를 만들 때도 있다. 이런 코드를 먼 미래에도 잘 쓰려면 단순하게 만드는 방법밖에 없다. 단순하지 않은 시스템은 장래에 필시 노후되거나 망가지거나 혼돈 그 자체가 되어 사용자에게 불쾌한 경험을 선사할 것이다.

재미있는 사실은 소프트웨어를 간단하게 만드는 게 복잡하게 만드는 것보다 더 쉽다는 점이다. 머리는 조금 더 써야 할 수도 있지만, 시간과 수고는 전체적으로 적게 든다. 그러니 합리적인 선에서 최대한 단순성을 유지하며 자신에게, 사용자에게, 시스템의 미래에 도움이 될 결정을 하자.