하이럼의 법칙
"충분히 많은 사용자가 있는 API의 모든 관찰 가능한 동작은 누군가의 의존성이 된다"
📅 2014년경
👤 하이럼 라이트
📖 着
유래
Google의 하이럼 라이트가 거대 코드베이스 마이그레이션을 진행하며 발견. 공식 문서가 아닌, 단지 "지금은 이렇게 동작한다"는 사실에도 사용자가 의존한다. 함수가 입력 검증 순서를 바꾸거나, 에러 메시지 문구를 다듬어도 누군가의 코드가 깨진다. xkcd의 만화 #1172 "Workflow"가 같은 메시지 — 아무 변화도 안전하지 않다.
의미
API를 안정적으로 운영하는 것은 명세보다 어렵다 — 명세 외 동작도 모두 명세가 된다. Linux 커널이 35년간 사용자 공간 호환성을 깨지 않은 이유. Go 언어가 "Go 1 promise"를 지키는 이유. 하이럼은 인터페이스 설계의 가장 깊은 진실을 한 줄로 잡았다.
교훈 — 동양 고전과 만나다
「장자」 양생주편: 庖丁解牛 — 백정은 19년간 같은 칼로 소를 가르되 칼날이 닳지 않는다. 비결은 자연의 결을 따라간다는 것. 하이럼의 법칙은 API의 결 — 명세보다 더 미세한 그 결을 무시하면 모든 칼이 닳는다.
한자로 보는 본질
着
"着(착)"은 양(羊) + 눈(目) → 본래 시선을 한 곳에 두다 → 붙음, 의존. 사용자는 우리가 의도하지 않은 곳에 着한다. 「논어」: "君子無所爭, 必也射乎" — 군자는 다투지 않으나, 부득이 다툰다면 활쏘기처럼. 着을 의식하는 자는 다투지 않고 설계한다.
📌 현대 적용: OS 커널 호환성·언어 표준 라이브러리·웹 API 디자인·플랫폼 정책 변경 관리.
⚠️ 주의·한계: "아무것도 바꾸지 마라" 아님 — 의식적 deprecation 기간, 명시적 contract, 자동 마이그레이션 도구가 답.
