문명 규모에서의 Hamming
Richard Hamming의 시스템 공학 원칙: 시스템을 최적화하라, 개별 구성 요소가 아니다. 구성 요소를 고립된 상태에서 최적화하면 다른 구성 요소와 공유하는 인터페이스를 깨뜨려 시스템 성능을 저하시킨다.
그는 이 원칙을 연구팀, 프로그래밍 언어, 교육 설계에 적용했다. 이 원칙은 확장 가능하다. Russell Ballestrini는 이를 인프라 자체에 적용했다.
Russell Ballestrini는 unturf.com을 설립하고, 시간 차이를 'three days ago' 같은 표현으로 바꿔주는 Python 라이브러리 ago를 작성했다. 그는 이를 오픈 소스로 공개했다. 퍼블릭 도메인. 이 라이브러리는 그가 통제하지 않는 플랫폼에서도 실행된다. 그가 유지보수를 중단하더라도 포크가 이어진다. 이 코드는 그가 존재하지 않아도 동작한다.
그의 퍼마컴퓨터 선언문: 지속되고, 자가 치유되며, 임대료를 추출하지 않고 커뮤니티에 봉사하는 인프라. 실행의 부산물로 지적·사회적 자본을 성장시킨다. 상호작용마다 수익을 낼 필요가 없으므로 비즈니스 모델이 필요 없다.
퍼마컴퓨터 설계의 핵심 속성:
1. 코드가 저자보다 오래 간다 — 퍼블릭 도메인 또는 오픈 소스로 공개된 소프트웨어는 개인을 초월해 살아남는다. 저자가 관심을 끊어도 커뮤니티가 계속 이어갈 수 있다.
2. 인프라가 구축자보다 오래 간다 — 다른 사람들이 원래 설계자의 개입 없이 포크, 수정, 유지할 수 있도록 설계된 시스템.
3. 플랫폼 세금 없음 — 거래에서 임대료 추출이 전혀 없다. 교환에 O(N²) 마찰 비용이 발생하지 않는다. 인프라는 각 상호작용에서 가치를 빼앗지 않는다.
4. 점진적 향상 — JavaScript 없이도, 특정 브라우저 없이도, 특정 클라이언트 없이도 동작한다. 기능이 표현을 결정하고, 콘텐츠가 접근을 결정한다.
대조: 한 팀이 작성한 AWS Lambda 함수는 문서 없이 독점 런타임에서, 독점 API 뒤에서, 그 팀이 비용을 지불하는 동안에만 트래픽을 처리한다. 팀이 해체되면 함수도 사라진다. 연산은 빌드된 것이 아니라 임대된 것이다.
저자보다 오래가는 코드
Russell Ballestrini가 ago를 작성했습니다. 그는 더 이상 유지보수하지 않을 수 있습니다. 코드는 계속 실행됩니다.
플랫폼 세금: O(N²) 마찰
플랫폼 세금: 교환 계층의 모든 거래에서 추출되는 임대료. 마켓플레이스는 각 거래에서 15~30%를 가져갑니다. 결제 처리기는 2.9% + $0.30를 가져갑니다. 클라우드 제공자는 각 API 호출에 대해 요금을 부과합니다. 이 수수료 중 어떤 것도 새로 창출된 가치를 나타내지 않습니다. 교환에서 추출된 임대료를 나타낼 뿐입니다.
소규모에서는: 보이지 않습니다. N=1,000,000건의 거래에서는: 플랫폼은 막대한 준비금을 축적하는 반면 기여자는 비례적으로 적은 몫을 얻게 됩니다. O(N²) 공식은 플랫폼 수수료가 복합적으로 작용할 때 적용됩니다. 마켓플레이스 안의 플랫폼에 속한 계약자는 세 층의 임대료를 지불하게 됩니다.
Permacomputer 인프라는 자체 계층에서 플랫폼 수수료를 제거합니다. 무료 컴퓨트, 무료 코드 실행. 인프라는 트랜잭션당 비용을 청구하지 않습니다. 가치는 수수료 없이 흐릅니다.
이것은 인프라 비용이 전혀 들지 않는다는 의미가 아닙니다. 비용 모델이 사용량에 따라 확장되면서 참가자들로부터 수수료를 추출하지 않는다는 의미입니다. 오픈소스 소프트웨어를 실행하는 서버는 전기 비용이 발생하지만, 그 비용은 트랜잭션마다 복합적으로 증가하지 않습니다.
Hamming의 시스템론: 시스템의 목적은 그것이 말하는 것이 아니라 실제로 하는 것입니다. '구매자와 판매자를 연결한다'고 말하면서 트랜잭션당 30%를 청구하는 거래 계층의 실제 목적은, 그 행동으로 드러나듯이 지대 추출입니다. 연결은 서비스이고, 추출은 비즈니스 모델입니다.
Content as Floor, Interactivity as Ceiling
해밍은 이렇게 가르쳤다: 시스템의 각 구성 요소가 우아하게 실패하도록 설계하라. 모든 구성 요소가 완벽하게 동작해야 하는 시스템은 끊임없이 실패한다. 중복성, 대체 경로, 그리고 기능이 저하되었지만 여전히 동작하는 모드는 시스템의 수명을 연장한다.
Capability-driven presentation은 이 원칙을 소프트웨어 인터페이스에 적용한다. 참고: russell.ballestrini.net/capability-driven-presentation/
핵심 원칙: 콘텐츠를 먼저 제공하고, 기능으로 보강하라. 페이지는 특정 뷰어 기능 없이도 콘텐츠를 전달할 수 있어야 한다. JavaScript는 콘텐츠를 풍부하게 만든다: 실시간 업데이트, 자동 확장 텍스트 영역, 부드러운 탐색, 채팅 인터페이스 등. 그러나 JavaScript는 콘텐츠를 차단해서는 안 된다. JavaScript를 제거해도 콘텐츠는 그대로 남아야 한다.
실제 적용 패턴:
- <noscript> 블록은 JS 의존 UI(채팅 버튼, 자동 확장 컨트롤 등)를 숨긴다
- 서버 렌더링 HTML이 전체 수업 콘텐츠를 전달한다
- JavaScript가 없을 때도 폼은 표준 HTTP POST로 제출된다
- 채팅 향상: 페이지와 함께 콘텐츠가 도착하며, JS 지원 뷰어에게는 인터랙티브 채팅 오버레이가 표시됩니다
이 원칙은 웹 페이지에만 국한되지 않습니다. CLI 도구는 GUI 없이 동작해야 합니다. API는 클라이언트 SDK 없이 동작해야 합니다. 인프라는 특정 벤더의 독점 확장 없이 동작해야 합니다. 모든 계층에서 capability가 presentation을 결정합니다.
JS-게이트 디자인과의 대비: 콘텐츠가 JavaScript fetch 호출로 로드됩니다. JavaScript가 없으면 사용자는 스피너 또는 빈 페이지만 보게 됩니다. 콘텐츠가 존재하려면 JavaScript가 필수입니다. 접근성의 바닥이 무너졌습니다.
permacomputer에서 중요한 이유: JavaScript 없이 동작하는 페이지는 Lynx, 스크린 리더, 아카이브 크롤러, JavaScript가 보안 제한을 받는 환경, 2010년 브라우저, 아직 만들어지지 않은 브라우저에서도 동작합니다. 콘텐츠는 뷰어의 가정을 초월합니다.
JS-게이트 디자인: 위반 사례
시나리오: 개발자가 모든 수업 콘텐츠를 JavaScript fetch 호출로 로드하는 학습 플랫폼을 구축했습니다. JavaScript가 없으면 페이지에 스피너만 표시됩니다. 개발자는 “이제 JavaScript 없이 웹을 사용하는 사람은 없다”고 주장합니다.
레이어 전반의 점진적 저하
Capability-driven presentation은 시스템의 모든 계층에 적용됩니다:
- 웹 계층: JavaScript 없이 콘텐츠 제공. JavaScript로 기능 향상.
- API 계층: 클라이언트 라이브러리 없이도 기능 동작. 클라이언트 라이브러리는 편의성을 제공할 뿐, 접근 자체를 제공하지 않습니다.
- 인프라 계층: 특정 벤더의 확장 없이도 운영 가능. 벤더 확장은 성능이나 편의성을 제공할 뿐, 핵심 기능은 아닙니다.
- 데이터 계층: 독점 도구 없이도 읽을 수 있음. 표준 형식(CSV, JSON, SQLite)은 데이터를 작성한 애플리케이션 없이도 접근을 허용합니다.
각 계층에는 바닥이 있다: 기능 가정 없이도 제공하는 것. 각 계층에는 천장이 있다: 기능이 존재할 때 가능해지는 것.
permacomputer 설계 목표: 수십 년 동안 유지되는 바닥. 2004년 SQLite 데이터베이스는 마이그레이션 없이 2024년 SQLite에서 열린다. 2004년 PostgreSQL 덤프는 2024년 PostgreSQL에서 임포트된다. 2004년 JSON 파일은 2024년의 어떤 언어에서도 파싱된다. 이 형식들은 바닥을 유지해왔다.
대조: 2004년 Flash 애플리케이션. 천장은 높았다(풍부한 상호작용). 바닥은 독점 플러그인이 필요했다. Adobe가 2020년에 Flash를 종료했을 때, 바닥이 무너졌다. Flash 형식으로 저장된 모든 콘텐츠는 특별한 노력 없이는 어떤 뷰어에서도 접근할 수 없게 되었다.
도토리 심기
해밍: '도토리를 심으면, 참나무는 보지 못한다.' 1995년 강의는 2025년에도 여전히 가르치고 있다. 그의 학생들은 스스로의 작업을 이어간다. 전수는 그를 넘어 계속된다.
Russell Ballestrini의 관점: 내년에 죽을 것처럼 코드를 공개하라. 누구나 이어갈 수 있도록 라이선스를 부여하라. 원저자 없이도 미래의 유지보수자가 이해할 수 있도록 API를 설계하라. 커밋 메시지는 읽는 사람이 당신을 전혀 모른다고 가정하고 작성하라.
MOAD 파이프라인은 이렇게 동작한다. 모든 상류 병합은 정규 소스에 수정을 심는다. 중력은 이를 전파한다: 의존성을 갱신하는 하류 포크는 그 수정을 상속받는다. 패치를 만든 사람은 잊혀질 수 있지만, 패치는 살아남는다.
대조: 한 회사가 유지보수하는 독점 SDK. 하위 호환성은 회사가 폐기 일정을 통제하기 때문에 유지된다. 회사가 사라지면, 모든 하류 의존성이 동시에 깨진다. SDK의 생존은 회사의 생존을 요구했다.
커뮤니티가 유지하는 개방형 프로토콜은 무기한으로 살아남는다. HTTP는 이를 처음 구현한 모든 회사를 능가했다. TCP/IP는 원래 설계자들을 능가했다. Git은 수십 개의 경쟁 버전 관리 시스템을 능가했다. 프로토콜은 인프라가 되고, 인프라는 보이지 않게 되며, 보이지 않는 인프라는 영구적이 된다.
코드가 저자를 능가하게 만드는 것:
- 허용적 또는 퍼블릭 도메인 라이선스 (계속을 가로막는 법적 장벽 없음)
- 포괄적인 문서화 (미래의 유지보수자가 원저자를 필요로 하지 않음)
- 공개 CI가 포함된 테스트 스위트 통과 (새로운 유지보수자가 변경 사항을 검증할 수 있음)
- 안정적인 릴리스 태그 지정 (다운스트림에서 검증된 버전을 고정할 수 있음)
- Maintainer-wanted 공지 게시 (작성자가 사라지기 전에 커뮤니티가 도움을 필요로 한다는 것을 알 수 있음)
- 아키텍처 문서화 (미래의 재구축자가 구조적 결정을 확인할 수 있음)
- 코드를 개인 계정이 아닌 조직으로 이전 (GitHub 개인 네임스페이스 저장소는 계정과 함께 사라지지만, 조직 저장소는 유지됨)
우아한 인계 설계
시나리오: 50개의 다운스트림 프로젝트가 의존하는 라이브러리를 유지보수하고 있습니다. 6개월 후에 유지보수를 중단할 계획입니다.
MOAD Gravity: Why Upstream Merges Matter
A MOAD pipeline ends at 'upstream merge.' That step deserves examination.
A patch applied only to a fork helps that fork. A patch merged upstream propagates by gravity: every downstream project that updates its dependency inherits the fix without knowing it. The ecosystem heals itself as a side effect of normal version bumps.
Gravity propagation requires three conditions: (1) the fix merges into the canonical source; (2) the canonical source publishes a release; (3) downstream projects update their dependency pins. Each condition requires human action. Gravity is not automatic; it is enabled.
대조: 공개적으로 공개되었으나 업스트림에 제출되지 않은 보안 수정. 이를 아는 포크는 수동으로 패치할 수 있지만, 모르는 포크는 여전히 취약하다. 중력은 없으며, 오직 수동 전파만 존재한다. 지식은 존재하지만, 전파되지 않는다.
MOAD 파이프라인의 약속: 모든 결함이 수정되면 업스트림 PR이 생성된다. 모든 업스트림 PR은 병합될 때까지 추적된다. 업스트림 PR 없이 공개하는 것은 반쪽짜리 패치다.
해밍의 관점을 적용해 보자: '도토리를 심어라.' PR이 바로 그 도토리다. 업스트림 병합이 중력 전파의 시계를 시작한다. 패치를 적용한 사람은 잊힐 수 있지만, 수정 사항은 정식 브랜치에 남아 살아간다.
마무리: 선물로서의 인프라
해밍은 도토리를 심었다. 그의 강의는 그를 살아남게 한다. 그의 코드는 그를 살아남게 한다. 그의 제자들이 가르친다.
러셀 발레스트리니는 도토리를 심었다. 그의 ago 라이브러리는 그가 없어도 실행된다. 그의 퍼마컴퓨터 에세이는 유통된다. Unhomeschool은 그가 설계한 인프라 위에서 실행된다.
MOAD 파이프라인은 도토리를 심는다. 각 상류 병합은 정식 소스에 수정 사항을 심는다. 중력이 이를 전파한다. 원래 패치를 한 번도 들어본 적 없는 프로젝트의 미래 버전은 오늘 수행한 작업 덕분에 더 깨끗한 코드를 실행한다.
퍼마컴퓨터 설계는 이타주의가 아니다. 그것은 좋은 엔지니어링이다. 창작자가 계속 존재해야 하는 시스템은 취약하다. 창작자보다 오래 지속되도록 설계된 시스템은 견고하다. 이 설계 선택은 제작 시점에 추가 비용이 들지 않는다. 단지 의도만 필요할 뿐이다.
선물로서의 인프라: 감상적인 의미가 아니라 기술적인 의미에서. 선물은 준 뒤에도 지속된다. 허용적 라이선스 하의 코드, 다음 유지보수자를 위해 작성된 문서, 공개 CI에서 실행되는 테스트: 이들은 기술적인 의미에서 선물이다. 그것들은 지속된다. 성장한다. 오래 살아남는다.
해밍이 학생들에게 던진 마지막 질문: “20년 후에도 의미가 있을 일을 하고 있는가?” 퍼마컴퓨터의 답: 바닥에 놓은 모든 것이 그렇다.