라이브러리 함수의 반환값 순서나 오류 메시지 문구를 조금 바꿨을 뿐인데, 멀리 떨어진 서비스가 갑자기 깨졌다는 보고가 올라오는 일이 있습니다. 문서에는 그런 세부 사항을 약속한 적이 없는데도 누군가 그 동작에 기대고 있었던 것입니다. 이런 현실을 한 줄로 요약한 관찰이 바로 ‘하이럼의 법칙(Hyrum’s Law)’입니다.

하이럼의 법칙이란 쉽게 말해 ‘인터페이스를 쓰는 사람이 충분히 많아지면, 문서에 무엇을 약속했는지는 중요하지 않고 시스템의 관측 가능한 모든 행동에 누군가는 의존하게 된다’는 소프트웨어 공학의 경험 법칙입니다. 구글에서 대규모 코드 변경을 다루던 하이럼 라이트(Hyrum Wright)의 관찰을, 동료 타이터스 윈터스(Titus Winters)가 ‘하이럼의 법칙’으로 이름 붙여 알렸습니다.

본 자료에서는 하이럼의 법칙이 말하는 정확한 뜻과 유래부터 암시적 인터페이스가 생기는 원리, 개발 현장에서 자주 보는 사례, 그리고 대응 요령과 한계까지 차례로 살펴보겠습니다.

문서보다 깊은 계약, 하이럼의 법칙

하이럼의 법칙이란 무엇인가?

이 법칙은 흔히 이렇게 적힙니다. 어떤 응용 프로그래밍 인터페이스(API)의 사용자가 충분히 많다면, 계약서에 무엇을 적었든 상관없이 시스템이 보여 주는 모든 관측 가능한 행동에 누군가는 의존한다는 것입니다. 라이트는 자신의 글에서 이 관찰에 ‘하이럼의 법칙’이라는 이름을 붙이고 널리 알린 공을 윈터스에게 돌리고 있습니다.

같은 취지로 ‘암시적 인터페이스의 법칙(Law of Implicit Interfaces)’이라는 말도 등장합니다. 사용자가 늘어날수록 비공개라고 여긴 구현 세부까지 사실상의 계약이 되고, 결국 구현을 조금만 바꿔도 ‘버그 대 버그 호환성(bug-for-bug compatibility)’을 요구받게 된다는 뜻입니다.

• 명시적 계약(Explicit Contract): 문서와 규격에 적어 둔 입력·출력·오류 조건입니다.
• 암시적 인터페이스(Implicit Interface): 문서에 없어도 사람들이 반복해서 관찰하며 기대하게 된 동작입니다.
• 관측 가능한 행동(Observable Behavior): 응답 순서, 지연 시간, 오류 문구, 로그 형식처럼 밖에서 확인할 수 있는 모든 결과입니다.

암시적 인터페이스가 생기는 원리

하이럼의 법칙은 개발자가 게을러서가 아니라, 규모가 커지면 거의 필연적으로 나타나는 현상입니다. 추상화로 안쪽을 숨겼다고 믿어도, 밖에서는 여전히 많은 신호를 읽을 수 있기 때문입니다.

(1) 사용자는 문서보다 동작을 본다
급한 일정 속에서 규격서를 한 줄씩 대조하기보다, 어제와 같이 돌아가는지부터 확인하는 경우가 많습니다. 그래서 우연히 안정적으로 보이던 세부 사항이 ‘당연한 약속’처럼 굳어집니다.

(2) 의존은 제각각이지만 합치면 구현 전체다
어떤 팀은 정렬 순서에, 다른 팀은 오류 코드 문자열에, 또 다른 팀은 평균 응답 시간에 기대입니다. 사용자 수가 커지면 그 의존의 합이 구현의 거의 모든 면과 겹칩니다.

(3) 조엘 스폴스키의 누수 추상화와 맞닿는다
조엘 스폴스키(Joel Spolsky)의 ‘누수 추상화의 법칙(Law of Leaky Abstractions)’은 추상화가 안쪽 사정을 완전히 가리지 못한다고 말합니다. 하이럼의 법칙은 그 새어 나온 단서들마저, 사용자가 많아지면 계약처럼 굳는다고 덧붙입니다.

개발 현장에서 만나는 사례

이론처럼 들리지만, 일상적인 라이브러리·서비스 작업에서도 같은 패턴이 반복됩니다. ‘규격 밖’이라고 생각한 변화가 가장 멀리 있는 시스템을 흔들 때가 많습니다.

(1) 반환 목록의 순서
문서가 “순서는 보장하지 않는다”고 적어도, 그동안 항상 같은 순서로 나왔다면 그 순서에 맞춘 코드가 쌓입니다. 어느 날 병렬 처리를 도입해 순서가 바뀌면 테스트에 없던 가정이 한꺼번에 드러납니다.

(2) 오류 메시지와 로그 문구
사람이 읽으라고 쓴 문장을 다른 프로그램이 문자열로 파싱해 분기하는 경우가 있습니다. 친절하게 문장을 고쳤을 뿐인데 자동화가 멈추는 일이 바로 이 유형입니다.

(3) 성능과 타이밍
규격이 지연 시간을 약속하지 않아도, 수년 동안 비슷했던 속도는 사실상의 기대치가 됩니다. 캐시를 빼거나 검사 단계를 늘려 약간 느려지면 ‘기능은 같은데 우리 쪽만 타임아웃’이라는 신고가 이어집니다.

하이럼의 법칙에 대응하는 요령과 한계

이 법칙은 변화를 포기하라는 뜻이 아닙니다. 오히려 관측 가능한 면이 곧 계약이 될 수 있음을 전제로, 바꿀 수 있는 여지를 의도적으로 남기라는 경고에 가깝습니다.

• 계약 명확화(Clear Contract): 보장하는 것과 보장하지 않는 것을 문서와 테스트로 분명히 나눕니다.
• 의도적 흔들기(Intentional Jitter): 처음부터 순서를 섞거나 지연을 조금 흔들어, 우연한 가정이 자라지 못하게 합니다.
• 호환성 검증(Compatibility Testing): 대규모 변경 전에 실제 호출 패턴을 광범위하게 돌려 깨지는 지점을 먼저 찾습니다.

다만 사용자가 아주 많아지면 어떤 작은 수정도 누군가를 깨뜨릴 수 있습니다. 『Software Engineering at Google』에서도 이 법칙은 엔트로피처럼, 없앨 수는 없어도 설계와 유지보수에서 늘 염두에 두어야 할 제약으로 다룹니다. 반대로 규칙을 핑계 삼아 필요한 개선을 끝없이 미루는 태도 역시 경계해야 합니다.

하이럼의 법칙은 인기 있는 시스템의 진짜 인터페이스가 문서보다 훨씬 깊다는 현실을 일깨웁니다. 구글의 대규모 라이브러리 변경 경험에서 태어난 관찰이, 오늘날 API와 플랫폼을 오래 유지하려는 팀의 공통 언어가 되었습니다.

작은 동작을 고치기 전에 ‘문서에 없어도 이미 누가 보고 있지 않을까’를 한 번 더 떠올려 보는 것, 그것이 깨지지 않는 변화를 설계하는 하이럼의 법칙 활용의 첫걸음입니다.