Tesler's Law

테슬러의 법칙

Every application has an inherent amount of irreducible complexity.

테슬러의 법칙 또는 복잡성 보존의 법칙(Conservation of Complexity) 은 모든 시스템에는 아무리 제거하려고 해도 없앨 수 없는 고유의 복잡성이 존재한다고 말합니다. 그리고 가능한 경우 복잡성을 사용자에게 전가하지 말고 코드가 담당하는게 더 좋은 디자인이라고 말합니다.

물론 한계는 있습니다.

어떤 업무는 사용자가 직접 감당해야할 수도 있습니다. 그럴 경우 사용자가 복잡성을 혼자 떠안게 두기 보다는 적절한 선택을 할 수 있도록 안내하는것이 좋은 설계입니다.

테슬러

Larry Tesler는 Apple 의 Lisa 초기 GUI 개념 개발에 참여하였고 1980년대에 이 원칙을 정립했습니다.

누군가가 복잡성을 처리하지 않는 한 모든 것을 단순하게 만들 수는 없다는 점을 말합니다. 이는 우리가 실무에서 시스템을 설계할 때 피할 수 없는 근본적인 트레이드오프입니다.

예시

공유기 설정

테슬러의 법칙의 예시로 공유기 설정이 있습니다.

간단한 공유기 설정은 설정 마법사(Wizard)를 통해 진행할 수 있습니다. 사용자에겐 간단하지만 보이지 않는 펌웨어가 적절한 기본값을 사용하여 설정 과정의 상당 부분을 자동으로 처리합니다. 그리고 사용자가 원할경우 직접 설정하는 기능을 제공합니다.

네트워크 구성의 복잡성은 변한것이 없습니다. 다만 그 복잡성을 누가 처리하냐가 달라진 것입니다.

Form

HTML 에서는 <form> 이 적절한 예시가 될것 같습니다.

잘 설계된 폼은 사용자가 입력하기 전에 정보를 미리 채워주거나 입력하는 즉시 값을 검증하거나 사용자가 직접 입력해야하는 항목 자체를 없애기도 합니다. 예를 들어 사용자가 도시를 직접 입력하도록 요구하는 대신 현재 위치를 자동으로 감지할 수 도 있습니다.

개인적으론 해외 직구할 때 Stripe 가 인상적이었습니다. 일부 주소만 입력하면 시스템이 가능한 주소를 제안하고 카드 번호만 입력해도 브랜드를 식별합니다.

소프트웨어가 복잡성을 대신 가져가는 것입니다.

마치며

테슬러의 법칙은 복잡성을 어디에 둘 것인가에 대한 이야기 입니다. 물론 모든 것을 자동화하는 것이 정답은 아닙니다. 사용자가 직접 결정해야 하는 사항까지 소프트웨어가 임의로 결정해서는 안됩니다.

중요한 것은 사용자가 반드시 감당해야 하는 복잡성과 소프트웨어가 대신 감당할 수 있는 복잡성을 구분하는 것입니다.

우리가 소프트웨어를 설계할 때

이 복잡성을 누가 감당하는 것이 나은가?

라는 질문을 한번 더 생각하게 해주는 법칙이라 생각합니다.