노트

하이럼의 법칙

Hyrum's Law

설계#architecture · 연결된 개념 8개

쉽게 말하면

하이럼의 법칙은 쓰는 사람이 많아지면 약속하지 않은 동작에도 누군가는 기대게 된다는 말이에요. 자주 쓰는 앱이 버튼 위치만 살짝 옮겨도 손이 엉뚱한 곳을 누르듯, 정렬 순서나 에러 문구 하나도 사실상 계약이 돼요.

비유가 깨지는 곳 사람은 잠깐 헷갈리고 말지만, 코드에서는 바뀐 동작에 기대던 프로그램이 실제로 깨져요. 그래서 공개 동작을 처음부터 좁게 잡고, 바꿀 땐 새 것과 옛 것을 함께 두는 단계를 거쳐요.

API(Application Programming Interface) 사용자가 충분히 많아지면, 계약에 무엇을 적었든 시스템의 관찰 가능한 모든 동작에 누군가는 의존하게 된다는 법칙. 구글의 하이럼 라이트(Hyrum Wright)가 라이브러리 변경 경험에서 관찰했고, 『Software Engineering at Google』에 소개됐다.

  • 공식 명세뿐 아니라 응답 시간, 에러 메시지 문구, 결과의 정렬 순서, 버그까지 의존 대상이 된다
  • 그래서 실질적인 계약은 문서가 아니라 실제로 관찰되는 동작 전체다
  • 운영체제가 문서화되지 않은 동작에 기대는 오래된 프로그램을 위해 옛 동작을 남겨 두는 것이 대표적인 예다

설계에 주는 교훈

  • 공개하는 동작을 처음부터 좁게 잡는다. 순서를 보장하지 않는다면 일부러 섞어서 내보내는 라이브러리도 있다
  • 바꿀 때는 한 번에 깨지 말고 새 것과 옛 것을 함께 두는 단계를 거친다(병렬 수정 (팽창-수축))
  • 더하기는 쉽고 빼기는 어렵다: 기능이나 옵션은 한번 내보내면 누군가 쓰기 시작해 거둬들이기 어렵다. 추가하기 전에 정말 필요한지 따져 보는 이유다
  • 놀랍지 않은 동작을 고르면 나중에 바꿀 일도 줄어든다(최소 놀람의 원칙)

받는 쪽에 관대하라는 포스텔의 법칙는 이 문제를 키울 수 있다. 관대하게 받아 준 잘못된 입력이 곧 의존 대상이 되기 때문이다.

출처: Laws of Software Engineering: Hyrum's Law · Hyrum's Law 하이럼 라이트

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 심플 디자인

    켄트 벡이 XP(Extreme Programming)에서 제시한 단순한 설계의 네 가지 규칙. 우선순위 순으로 ① 모든 테스트를 통과하고 ② 의도를 드러내고 ③ 중복이 없고 ④ 요소가 가장 적다. 마틴 파울러가 이렇게 정리한 형태가 널리 쓰인다.

  • 힉의 법칙

    결정하는 데 걸리는 시간은 선택지의 수와 복잡도에 따라 늘어난다는 법칙. 1952년 윌리엄 힉과 레이 하이먼의 실험에서 선택지가 늘수록 반응 시간이 로그 함수로 증가한다는 결과가 나왔다.

  • 『UX/UI의 10가지 심리학 법칙』

    존 야블론스키가 사용자 경험(User Experience, UX) 디자인에 자주 쓰이는 심리학 원리를 정리한 책. 법칙마다 기원, 핵심 내용, 실제 사례를 짧게 다루고, 마지막 장에서 이 원리들이 사람을 조종하는 데 쓰일 수 있다는 윤리 문제를 짚는다. 같은 내용을 저자의 사이트 lawsofux.com에서도 볼 수 있다.

  • 디미터 법칙

    객체는 직접 아는 친구하고만 이야기하고, 친구의 친구에게 말을 걸지 말라는 원칙. a.getB().getC().doSomething() 같은 체인 호출을 피해 결합도를 낮춘다.

  • 구조와 동작, 옵션의 가치

    켄트 벡이 정리 시점을 판단하려고 꺼내는 경제학 틀. 소프트웨어는 두 가지 가치를 만든다. 오늘 하는 일(동작)과, 내일 새로 할 수 있게 되는 일(옵션)이다. 구조는 동작을 바꾸지 않지만 옵션을 만든다.

보기 옵션