복잡성 보존의 법칙

Tesler's Law (Law of Conservation of Complexity)

쉽게 말하면

복잡성 보존의 법칙은 모임 날짜를 정하는 번거로움이 사라지지 않고 옮겨 갈 뿐이라는 말이에요. 단톡방에서 서로 묻고 답하면 사람이 떠안고, 일정 조율 앱을 쓰면 앱이 대신 떠안죠.

비유가 깨지는 곳 앱이 떠안는다고 공짜가 되는 건 아니에요. 그 복잡성은 개발·운영 비용으로 돌아오고, 먼저 없앨 수 있는 우연한 복잡성과 없앨 수 없는 고유한 복잡성을 구분해야 해요.

모든 애플리케이션에는 더 줄일 수 없는 고유한 복잡성이 있고, 그 복잡성은 없앨 수 없으며 옮길 수만 있다는 법칙. 래리 테슬러(Larry Tesler)가 초기 GUI(Graphical User Interface) 작업 중에 정리했다.

핵심 질문은 "그 복잡성을 누가 감당할 것인가"다. 사용자인가, 시스템(개발자)인가
일정 조율을 이메일로 주고받게 하면 사용자가 복잡성을 떠안고, 일정 조율 서비스는 그것을 시스템이 흡수한다
좋은 설계는 대체로 복잡성을 사용자 경험에서 시스템 내부로 옮긴다. 다만 시스템이 감당하는 복잡성은 개발·운영 비용으로 돌아온다

코드 설계에도 적용된다. 컴포넌트 API(Application Programming Interface)를 단순하게 만들면 그 안의 구현이 복잡해지고, 반대로 내부를 단순하게 두면 사용하는 쪽이 조립을 떠맡는다. 퍼사드 패턴은 하위 시스템의 복잡성을 창구 뒤로 옮기는 패턴이다. 제거할 수 있는 우연한 복잡성(Accidental Complexity)과 제거할 수 없는 고유한 복잡성(Essential Complexity)을 구분하는 것이 먼저다(구성요소 줄이기, KISS 원칙). 선택지 수가 결정 시간을 늘린다는 힉의 법칙(Hick's Law)은 UX(User Experience) 쪽에서 같은 문제를 본다.

출처: Laws of Software Engineering: Tesler's Law (Conservation of Complexity) · Laws of UX: Tesler's Law

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

심플 디자인
켄트 벡이 XP(Extreme Programming)에서 제시한 단순한 설계의 네 가지 규칙. 우선순위 순으로 ① 모든 테스트를 통과하고 ② 의도를 드러내고 ③ 중복이 없고 ④ 요소가 가장 적다. 마틴 파울러가 이렇게 정리한 형태가 널리 쓰인다.
결합도
한 요소를 바꿀 때 다른 요소도 바꿔야 하는 관계. 결합도는 언제나 "어떤 변경에 대해" 결합되어 있는지를 함께 말해야 의미가 있다. 같은 두 모듈도 어떤 변경에는 묶여 있고 어떤 변경에는 독립적일 수 있다.
섣부른 최적화
"섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.
하이럼의 법칙
API(Application Programming Interface) 사용자가 충분히 많아지면, 계약에 무엇을 적었든 시스템의 관찰 가능한 모든 동작에 누군가는 의존하게 된다는 법칙. 구글의 하이럼 라이트(Hyrum Wright)가 라이브러리 변경 경험에서 관찰했고, 『Software Engineering at Google』에 소개됐다.
SOLID 원칙
객체지향 설계를 위한 다섯 가지 원칙의 머리글자. 로버트 C. 마틴(Robert C. Martin)이 정리했고 마이클 페더스(Michael Feathers)가 SOLID라는 약어를 붙였다.

보기 옵션

글자 크기 100%자간 0.00줄 간격 1.7