강연은 먼저 고대 문명, 예를 들어 기원전 11,000년의 호주 원주민과 기원전 2700년의 이집트 문명이 이미 정교한 태양력과 윤년 개념을 이해하고 있었음을 보여줍니다. 하지만 로마인들은 이러한 지식을 무시하고 비논리적인 10개월 달력에서 시작하여, 율리우스 카이사르와 아우구스투스 황제의 개혁을 거쳐 현재의 복잡한 월별 일수 체계를 만들었습니다. 특히 2월의 짧은 일수와 윤년 계산 방식은 로마 시대의 정치적 결정에서 비롯된 것이며, 이는 오늘날 프로그래밍에서 날짜 계산의 복잡성을 야기하는 주요 원인 중 하나입니다.
이어서 강연은 현대 CPU 아키텍처가 성능에 미치는 비직관적인 영향을 설명합니다. 윤년 판별 함수와 월별 일수 계산 함수를 예시로 들어, 분기 예측(branch prediction) 실패와 메모리 접근 지연(memory latency)이 어떻게 코드 성능을 저하시킬 수 있는지 보여줍니다. 강연자는 조건문(if-else)이 많은 코드보다 CPU가 예측하기 쉬운 ‘더 많은 작업’을 수행하는 코드가 때로는 더 빠를 수 있음을 실제 벤치마킹 결과를 통해 입증하며, 성능 최적화에는 반드시 가정이 아닌 측정이 수반되어야 함을 강조합니다. 에포크(epoch) 시간 변환의 복잡성 또한 로마 달력의 유산이며, 단순한 나눗셈으로 날짜를 계산할 수 없는 이유를 설명합니다.
또한, 강연은 그레고리력 개혁 사례를 통해 대규모 시스템의 파괴적 변경 배포에 대한 교훈을 제시합니다. 1582년 교황 그레고리 13세의 달력 개혁은 단순하고 명확한 패치 지침, 기존 문제(춘분점 오차) 해결, 그리고 120년에 걸친 점진적인 채택 기간을 통해 이루어졌음에도 불구하고, 국가 및 도시별로 채택 시기가 달라 역사적 날짜의 혼란(누락된 날짜, 중복된 날짜)을 초래했습니다. 이는 소프트웨어 V2 배포 시 고객 전환의 어려움과 하이럼의 법칙(Hyrum’s Law)의 중요성을 상기시킵니다. 즉, 시스템이 어떻게 작동하는지에 대한 문서는 곧 사양이며, V1 출시 전에 장기적인 유지보수 가능성을 신중히 고려해야 한다는 것입니다.
마지막으로, 강연자는 시스템 재작성(rewrite)에 대한 노버트의 황금률을 제시합니다: ‘다른 원칙 위에 구축하고자 할 때만 재작성하라.’ 이는 단순한 코드 정리나 테스트 추가가 아닌, 단일 쓰기 데이터베이스, CQRS와 같은 명확한 ‘원칙(axioms)’을 정의하고 이를 통해 시스템의 확장성 및 경쟁 우위를 확보할 수 있을 때만 재작성이 의미 있다는 것입니다. C++의 chrono 라이브러리를 모범 사례로 들며, 시간 경과(duration)와 특정 시점(time_point)을 엄격하게 구분하고, 컴파일 타임에 단위 및 의미론적 검사를 수행하여 안전성과 성능을 동시에 확보하는 방법을 설명합니다. 이는 프로그래머가 명시적으로 추상화를 전환하도록 강제함으로써 도메인 특유의 복잡한 로직을 명확히 처리할 수 있게 합니다.