메아리 저널

요즘 허구한 날에 “학력 인증”을 하겠다고 덤벼드는 일이 잦은데, 그 양상은 크게 둘로 나눌 수 있다. 하나는 그 대상이 (가짜의) 학력을 내세워서 이런 저런 이득을 취했을 것이라고 “추정”하여 인증을 시도하는 것이고, 다른 하나는 그 대상이 그 말을 할 자격이 있는 권위자(authority)인지 알고자 하는 것이다. 전자의 대표적인 예로 타블로 사건이 있겠으며, 후자는 대중 매체에서 떠들어 대는 대부분의 학자들에 해당된다.

전자의 경우 모든 문제는 학력이 필요하지 않은 맥락에서 학력을 떠들어 대는 작자들 내지 그런 상황을 만드는 작자들에게 있다. 왜 타블로가 스탠포드 나온 게 중요한 건가? 어차피 스탠포드 나와서 그런 데 걸맞는 일을 하는 것도 아니고 (좀 과장하자면) 딴따라 하고 있는 건데? 타블로가 원하든 원하지 않았든 이미지 메이킹을 한 데에 대한 책임을 져야 하는 건 옳지만, 사실 일이 이 지경까지 간 데는 “학력 팔아서 이득을 취한다”는 설레발이 더 크게 작용했다.

후자의 경우, 몇 년 전에도 똑같은 얘기를 했는데 말의 진실은 그 말을 한 사람과 상관 없다. 어떤 주장이 사실임을 검증하려면 그 주장의 근거를 검증해야지 그 말을 한 사람을 검증하면 안 된다. 이걸 제대로 못 하면 여당일 때는 FTA 찬성하고 야당일 때는 FTA 반대하는 멍청한 한나라당·민주당 꼴이 되는 것이다. 비슷한 이유로 나는 뉴스를 볼 때 언론을 딱히 가려서 읽는 편이 아니다. 조중동조차도.¹

…슬슬 옛날 글 링크하는 것만으로 한 글을 때울 수 있을 정도로 옛 글이 쌓이는 것 같다.

내가 어제 제로보드 4 까는 트윗을 올렸는데 하루 사이에 리트윗이 100명을 넘었다. 워매… 무서워… 근데 이거 문맥이 없으면 왜 이러는지 이해하기 어려우니까 조금 더 자세히 얘기해 보자.

사건

그제와 어제 학교 내 리눅스 머신 수십대가 루트킷에 감염되었다는 것이 확인되어서 하루 내내 홍역을 치뤘다. 이 루트킷은 (다행인지 불행인지) 동일한 공격자가 심어 놓은 것인데, 나중에 알려진 것들을 종합하면 대강 다음과 같은 경로로 전파된 것 같다.

1. 웹 서버를 돌리는 몇몇 서버가 제로보드 취약점으로 웹셸이 뚫렸다.
2. 웹셸은 보통 웹 서버 계정(www-data, www 등)으로 돌아 가지만, 추가적인 취약점을 사용해서 루트 권한을 얻을 수 있다.
3. 이렇게 얻은 루트 권한을 가지고 SSH 서버를 갈아 치우면 SSH 접속 시 아이디와 암호를 평문으로 기록할 수 있다. (SSH가 아무리 암호화를 한다고 해 봤자 SSH 서버 자체가 기록을 하면 아무 소용이 없다!)
4. 이제 이 아이디와 암호를 가지고 다른 서버에 접속을 시도해 본다. 성공하면 3번 과정을 반복한다.

이 과정을 거쳐서 공격당한 기계들 중에 꽤 사용자가 많은 서버(대표적으로 아라…)가 있다는 게 알려지자 공격자가 이걸 가지고 서버 관리자들을 놀려 먹으려고 IRC에 등장했는데(…) 이 과정에서 1번에 사용된 취약점이 다른 게 아니라 내가 2005년에 발표한 그 취약점이라는 게 확인된 것이다. -_-; (CVE-2005-1820) 내가 다니는 학교에 있는 서버가 내가 발견한 취약점으로 뚫리는 것 만큼 허무한 일이 어디 있을까.

물론 공격자가 최초 공격 이후 거점을 넓혀 나갈 수 있었던 이유는 제로보드 취약점이 아니라 사람들이 여러 기계에서 똑같은 아이디에 똑같은 암호를 썼다는 이유였다. 실제로 이 사건 이후 일부 서버는 SSH keyboard-interactive를 완전히 못 쓰게 하려는 시도도 하고 있는 것 같다. 하지만 그렇다고 제로보드 취약점에 당한 서버의 책임이 무마되는 건 아니다.

역사

이 문제의 취약점은, 링크에서도 알 수 있듯이 사실 2003년에 처음으로 발견한 것이다. 게다가 이건 정확한 메커니즘은 전혀 모른 채¹/만 들어 가면 에러가 난다(…)는 것을 알고서 실험하던 도중에 발견한 것이다. 당시 나는 철 모르던(?) 학생이었고, 이 취약점의 중요성에 대해서 별로 인식하지 못 한 채 일부 서버에 몸소 실험을 해 보는 무모한 짓까지 몇 번 시도했을 정도였다. 발견한 지 한참 뒤에서야 공개적으로 발표하게 된 것은 이런 면도 어느 정도 작용했을 것 같다.

내가 공개를 한참 미뤄야 했던 다른 이유로는 타이밍이 잘 안 맞았다는 점도 있다. 제로보드 4는 4.1이 2002년에 나온 이래 이렇다 할 변경이 거의 이루어지지 않은 것으로 악명이 높았는데, 특히 내가 버그를 발견했을 적의 최신 버전인 4.1 pl4(2003년 8월)는 무려 1년 반 가까이 갱신이 되지 않았다. 대학교 입시에 바빠지기 시작할 2004년 초반 즈음에 어떻게 할까를 고민했었는데, “어차피 나 말고도 이 버그 발견할 사람들이 충분히 있을텐데 나중에 확인해 보자”라는 생각으로 일단 묻어 두고 있었다(그리고 그 때만 해도 나는 누구한테 메일을 보내서 문제를 알리는 데 익숙하지도 않았다). 그래서 2004년 말에 4.1 pl5가 나왔을 때, 이 버그가 전혀 고쳐지지 않은 것에 상당히 놀랐다. 그리고 불안감이 엄습해 왔다. pl5가 나와서 사람들이 패치를 하는 이 시즌에 문제가 해결되지 않으면 그 다음 pl6까지 기다리기 전에 문제가 커진다! 그래서 개발자 연락 없이 곧바로 버그를 공개하게 된 것이다. 참 배짱도 좋았다.

후에 확인해 보니, 내가 발견한 preg_replace 기법은 생각보다 잘 알려지지 않은 기법이었던 것 같다. 이 버그는 흔히 정규식을 동적으로 생성해서 검색 하이라이팅을 하거나 하는 코드에서 주로 발생하는데, 도대체 누가 검색어에 널 문자 같은 걸 넣겠냐는 말이다. 많이 찾아 본 건 아니지만 CVE에서 이 기법을 사용한 취약점은 2005년 이후로 급증했는데, 그 첫 타자가 제로보드 취약점이었다(…). 게다가 실제로 발견한 시기를 생각해 보면 내가 아마도 이 문제를 인식한 초기 그룹에 속하지 않으려나 싶기도 하다. 정말로 어쩌다가지만.

“이 때가 아니면 제로보드 취약점은 안 고쳐진다”라는 생각을 했던 사람은 나 말고도 더 있던 모양이어서, 내 발표 직후에 나온 제로보드 4.1 pl6에는 문제의 취약점 말고도 다른 취약점 하나가 고쳐졌다. 그리고 몇 달 안 지나서 pl7에서 또 다른 취약점이 고쳐졌고, 드디어 사람들이 제로보드가 보안 취약점 덩어리라는 걸 인식하게 되었다. 제로보드의 새 버전이었던 zb5(지금은 접혔다)가 개발 도중에 급하게 나온 이유도 비슷한 이유라고 생각한다. 개발자조차도 제로보드 4에 미래가 없다고 생각할 정도여서 뭔가로 갈아 타긴 해야 하는데, 그 뭔가가 필요한 시점이 갑자기 찾아 왔던 것이다. 다행히도 한 두 해 사이에 급격한 전환이 이루어져서, 더 이상 새로운 사이트를 만드는 데 제로보드 4를 쓰는 사람은 없었다.

현재

제로보드 4는 4.1 pl9를 마지막으로 업데이트가 중단되었으나, 제로보드 4를 아직도 사용하는 웹사이트들은 여전히 남아 있다. 심지어 내 웹 서버 한 구석에도 전환이 어려워서 알려진 보안 버그만 패치된 채로 돌아 가는 제로보드 4가 하나 남아 있다.²

내가 취약점을 발표한 지 무려 7년이 지났건만, 이렇게 아직도 남아 있는 제로보드 4는 상당한 보안 문제를 유발하고 있다. 해외 공격자들이 제로보드 4가 호구쉬운 공격 타겟임을 알게 되자 제로보드 4 소스를 하나 하나 분석해 가면서 모든 방법으로 공격을 시도하기 시작했고, 이는 점차 자동화되어서 이번 사건처럼 제로보드 4가 깔려 있는 서버가 관리자 모르게 또 다른 서버를 공격하기 위한 용도로 사용되는 경우도 매우 흔하다. (하긴 제로보드 4를 패치 없이 방치하는 서버는 관리를 포기했다고 봐야 할 지도 모르겠다.)

내가 이렇게 말한다고 방치된 서버에 정신을 쏟을 사람이 얼마나 있을진 모르겠다. 하지만 적어도 나는 7년 전에 발견한 취약점이 아직도 현역으로 돌고 있는 걸 보고 좋아할 사람은 아니다. 제로보드 4를 피치 못 한 이유로 계속 써야 한다면 적어도 pl9를 쓰고, 웹 서버 설정을 최대한 제약해서 가능한 문제를 최대한 줄여야 한다. 이럴 만한 능력도 없는데 제로보드 4를 쓴다는 것은 자기 뿐만 아니라 남들까지 위험에 빠뜨리겠다는 생각이라고밖에 할 수 없다.

아… 근데 이 글 써 놓고 보니까 원래 내가 하고 싶은 얘기는 앙골모아 2.0 얘기가 아니라 2.0 작업 과정에서 알게 된 내용이었던 것 같다….

앙골모아는 옛날도 그렇고 지금도 그렇고 SDL에 크게 의존하고 있다. 그런데 SDL은 1.2.x가 나온 뒤로 기능 추가가 매우 느렸고, 심지어 명백한 버그도 잘 안 고쳐졌다. 앙골모아에서 발견할 수 있는 버그 중에서 실제로는 SDL 버그이거나 기능 부족으로 구현이 골때린 케이스는 다음 몇 가지가 있다:

• 샘플링 레이트가 44100/2^k Hz 꼴이 아닌 WAV 파일들은 pitch가 어긋난다. 7년 전에 확인해 봤을 때 SDL의 오디오 서브시스템이 이 경우에 대해서 리샘플링을 안 해서 그런 거라는 결론을 내렸는데, 1.3.x 개발 버전에서는 드디어 고쳐졌지만 1.2.x에서는 얄짤 없다. 아니, 얄짤 없는 수준이 아니라 코드는 있는데 활성화가 안 되어 있다.¹
• 알파 채널이 없거나 있어도 지원이 잘 안 되는 BMP의 특성상 rgb(0,0,0)이 투명색 대용으로 쓰여 왔는데, 일부 BMS가 이 색깔 말고 rgb(4,0,4) 같이 비디오 오버레이에서 사용하는 색깔을 투명색으로 쓰는 경우가 있었다. 투명색이 한 종류라면 SDL의 colorkey 기능을 사용해서 바로잡을 수 있지만, 두 종류면 역시 방법이 없다. 근데 1.3.x에서 colorkey를 없앨 것 같기 때문에 어차피 새로 구현해야 할 수도 있다.
• 맥 오에스 텐 옛날 버전에서 입력 latency가 ~50ms까지 치솟는 매우 심각한 문제가 있었다.² 그런데 똑같은 1.2.x대여도 최신 맥 오에스 텐에서 돌리면 큰 문제 없이 돌아 가는 것으로 보아 SDL 문제가 아니라 맥 오에스 텐 문제 같기도 하다.
• 비슷한 이유로, SDL_mixer는 생각보다 latency가 큰 편이다. 가장 큰 이유는 크로스플랫폼이라서 자체 믹서가 없는 백엔드에서도 믹싱을 지원해야 하기 때문에 자체 믹서가 있는 백엔드에서도 그 믹서를 사용하지 않기 때문이다.³ 상황에 따라 키음 수십 개가 함께 재생될 경우 수십 ms 정도의 latency를 직접 들을 수도 있다. 개발이 (이제서야) 활발히 진행되고 있는 SDL과는 달리 SDL_mixer는 기능 추가가 거의 중단된 터라 이 구조가 바뀌길 기대하기도 어렵다.

이런 이유로 SDL 1.3이 나온다면 (그 땐 SDL 2.0이 되겠지만) 앙골모아도 고칠 부분이 꽤 있을 것 같다. 이게 문제 해결에 도움이 된다면 얼마나 좋으련만.

별로 도움이 되지 않는 것 같은 메아리 첫 페이지를 자주 보는 사람이라면 어제 희대의 이상한 BMS 플레이어 앙골모아가 갑자기 2.0 alpha 1을 찍었음(!)을 알 수 있을 것이다. 참고로 앙골모아는 2009년에 마지막으로 커밋을 했으니 3년만의 커밋인데(…), 저작권 연도를 보면 원래 개발을 2~3년에 한 번씩 한다는 매우 중요한 사실을 알 수 있다.

본래 앙골모아는 원래 코드를 줄일 요량으로 만들었으며(1.0-final이 15K¹를 찍었음) 당연히 기능이고 뭐고 최소화한 프로그램이었지만, 어쩌다 보니까 쓸만한 크로스플랫폼 BMS 플레이어가 없는 상황이 계속 되다 보니까 실질적으로는 “최신”(이것도 웃긴게, “최신”이라고 하는 것이 2003~4년이다) BMS 확장을 지원하는 거의 유일한 크로스플랫폼 BMS 플레이어가 되어 버렸다. 그래서 1.0을 마지막으로 정리해서 내 놓을 때는 ‘시바 이거 더 이상 개발 안 해’라고 생각하고 있었으나, 생각을 조금 바꿔서 (어차피 이 쪽에 관심 가지고 있는 사람들도 없잖아?) 아주 핵심적인 기능만 기준으로 계속 개발하기로 했다. 물론 지난 개발 전적을 생각하면 개발 속도는 더럽게 느리겠지만….

사흘 전(2012-01-03)에 찍은 이 사진은 아마도 내가 3년 가까이 유비트를 하면서 가장 희열을 느낀 순간이었다. 유비트를 모르는 사람한테 이 사진의 가치를 설명하려면 “4,300회 플레이하면서 이 곡만 200회 넘게 했는데 처음 나온 기록”이라고 설명하면 대강 되겠지만, 유비트를 아는 사람이라면 더 듣고 싶은 말이 있을 것이다.

---

유비트를 오랫동안 하다 보니 웬만한 곡은 S 찍는 건 어렵지 않고 좀 연습하면 웬만큼 악랄한 곡이 아니고서야 SS/SSS를 찍을 수 있는 정도의 실력을 가지고 있는데, 이 기록을 찍기 전까지는 S를 못 찍은 곡이 두 개가 있었다. 하나는 에반스고 다른 하나는 에어레이드인데, 둘 다 난이도가 안드로메다로 넘어 가는 걸로 유명하지만 에반스는 초기작부터 지금까지 난공불락으로 남아 있었기 때문에 훨씬 인지도가 높다. 그리고 리듬게이머들 사이에는 에반스는 에어레이드와는 달리 외워도 난이도가 내려가지 않는다(…)는 악명이 자자하기도 했다.

앞에서 4,300회 플레이 중 200회가 에반스 (물론 EXTREME 난이도) 플레이라고 언급했는데 이 수치는 실제로 내가 가지고 있는 자료에서 계산해 낸 것이다. 이 자료에 따르면 난 2009년 6월 26일에 처음으로 이 악랄한 곡을 접한 이래, S에 다다르기까지 2년 반동안 22회나 기록이 찔끔 찔끔 갱신된 걸로 나온다. 특히 처음으로 A를 찍은 동년 11월 6일 이래 갱신 폭이 1만점을 넘긴 경우는 한 번 뿐이었다. 게다가 자료 중간에 열 달에 다다르는 긴 공백이 있는데, 이 공백동안 점수는 정확히 2천점 올라갔다(…). 이러니까 내가 애증이 넘친다고 할 수 밖에 없다. 참고로 이 기간보다 훨씬 짧은 기간 사이에 레벨 10 호구곡(다소 개인차가 있긴 하다)으로 불리는 Russian Snowy Dance는 엑설을 찍을 뻔 했다….

에반스는 보통 크게 네 구간으로 나눈다. 첫 20여초간의 가벼운 손 풀기(퍼펙트 기준 ~16만 9천점), 회오리로 끝나는 45초간의 저속 구간(~44만 9천점), 그리고 답이 안 나오는 중반 폭타(~71만 2천점), 마지막으로 끝까지 답이 안 나오는 후반 폭타(~90만점)가 바로 그것이다. 네 구간은 구조가 서로 따로 놀기 때문에 한 구간을 잘 한다고 다른 구간을 잘 한다는 보장이 없는데(“그나마” 후반 폭타 일부는 중반 폭타의 변형이긴 하다), 내가 겪은 문제도 바로 이것이었다. 나는 곡 패턴을 거의 외우지 않기 때문에, 올콤보를 노리기 위해서 곡에 맞춰서 외우는 케이스를 제외하면 구간 전체를 외울 생각을 하지 않는다. 하지만 에반스의 중반 폭타는 반엇박으로 동시 치기가 나오는 매우 흉악한 패턴이라서 몸이 외우지 않으면 비슷하게라도 치는 게 어렵고, 그래서 중반 폭타를 잘 치면 88만점, 못 치면 85만점(…)이라는 웃기지도 않은 상황이 된 것이었다.

그래도 200번 플레이해 보니까 자기가 처한 상황은 확실해져서, 회오리가 끝날 때까지 무조건 43만점(즉, 많아도 2만점 감점) 이상으로 플레이하면 적어도 A(85만점 이상)는 받을 수 있다는 걸 알게 되었다. 조금 운이 더 따라 주면 44만점대도 안 되는 건 아니었다. 이걸 가정했을 때 S를 받으려면 이 뒷구간에서 9만점 이상 깎이면 안 되기 때문에, 중반 폭타에서 많아도 6만점, 후반 폭타와 최종 게이지에서 많아도 3만점이 깎인다고 계산해야 했다. 아까 전에 퍼펙트일 때 점수를 생각하면 이건 중반 폭타가 끝났을 때 64만점 이상을 받은 뒤에 뒷부분을 최대한 잘 쳐야 한다는 걸 뜻한다. 이 과정에서 몇 가지 꼼수가 등장했는데,

• 점수를 최대한 더 잘 받는 게 목표라면 잡다한 박자들을 덜 신경쓰고 4개짜리 동시치기를 제대로 치도록 노력하는 게 좋다. 실제로 에반스에서는 4개 동시치기보다 반박 빠르게 또는 반박 늦게 한 개짜리 노트가 나오는 패턴이 흔한데, 어차피 못 외울 거면 한 개짜리 노트를 버리는 게 점수에 유리하다.
• 중반 폭타 중간 쯤에 긁어서 퍼펙트를 낼 수 있는 부분이 존재한다. 이 부분은 다른 곳의 변형 엇박과는 구조가 다르기 때문에 딱 이 부분만 외우고 나머지를 일반적인 전략으로 처리하는 게 편했다.
• 중반 폭타와 후반 폭타 사이에 약간 쉬어 가는 부분은 무조건 콤보를 이어야 한다. 그래야 게이지를 최대한 올려서 후반 폭타가 좀 잘 안 되어도 최종 게이지에서 그만큼의 점수를 건져낼 수 있다.
• 후반 폭타의 중간 부분에는 점대칭으로 긁는 것”처럼” 보이는 부분이 있다. 이 부분은 실제로는 긁으면 절대로 올콤보를 할 수 없으나, 어차피 올콤보는 포기한 마당에 최대한 그럴듯하게 긁는 전략을 썼다.

결과적으로, 90만점을 넘긴 아주 운 좋은 플레이의 경우 회오리까지 44만 2천점, 중반 폭타까지 63만 5천점, 후반 폭타를 넘겼을 때 80만 6천점, 그리고 운이 좋게도 게이지가 거의 안 깎여서 최종 점수가 90만 3천점이 되었다. 이 전략으로 나올 수 있는 최대 점수에 가까울 것 같다. 한 가지 재밌는 점은, 나랑 비슷한 실력을 가진 주변 사람들은 대부분 회오리 이후의 폭타가 아니라 회오리 전에서 점수를 깎아 먹는 게 많았다는 것이다. 다른 말로 하면 폭타를 “보고” 어떻게든 칠 수 있다는 얘기가 되는데, 아무래도 전반적으로 내가 특이한 게 아닌가 싶다.

---

또 한 가지 흥미로운 점은, 내가 에반스를 S 못 넘긴다고 말할 때마다 거의 모든 사람들이 님 실력에 S를 못 넘긴다니 흠좀무라는 반응을 보였다는 것이다. 하긴 그렇다. S가 넘어 가면 어쨌든 이 곡은 외워야 하는 곡이고, 만약 내가 처음부터 외우기 시작했다면 지금쯤 SS를 찍었을 지도 모를 일이다.

하지만 난 지금까지 그러지 않았다. 난 옛날도 그렇고 지금도 그렇지만 리듬게임은 결국 패턴화를 어떻게 하느냐에서 재미를 찾는 게임이라고 보아 왔다.¹ 리듬게임을 어느 정도 한 사람들이라면 노래를 들었을 때 절로 자기가 하는 게임에서 그게 어떤 채보로 나올 지를 상상한 적이 있을 것이다. 그게 자연스러운 이유는, 기존의 리듬게임에서 그러한 종류의 음악이나 리듬이 그러한 채보로 나와 왔기 때문이다. 만약 패턴화가 불가능한 채보가 있다면, 그 채보에서 재미를 찾는 것은 기존에 리듬게임이 주던 재미랑은 다른 재미를 찾는 것이 될 것이다. 실제로 에반스는 안 하는 사람과 하는 사람의 차이가 극심한 것으로 알려져 있으며, 아예 에반스만 파고 다른 곡을 안 하는 사람들을 일컬어 “에반스 플레이어”라는 말로 부르기까지 할 정도로 이 곡에 파고 드는 사람들도 적지 않다. 하지만 난 에반스를 플레이하는 게 아니라 유비트를 플레이하는 사람이고, 일반적인 패턴화를 통해 재미를 찾고 싶지 에반스에 특화된 패턴화로 재미를 찾고 싶지는 않다.

비슷한 이유로, 아마도 나는 S를 못 찍은 마지막 곡인 에어레이드도 한동안 고생을 해 가면서 플레이를 할 작정이다. 에어레이드는 나같이 채보를 외우지 않는 사람한테는 에반스보다 더 어려운데, 곡을 구간 별로 분리할 수는 있으나 모든 구간이 어렵다(에반스는 회오리 앞뒤의 난이도가 확연히 차이가 나서 클리어 난이도가 생각보다 낮다). 하지만 에반스를 결국 S를 찍었는데 에어레이드라고 못 할 이유가 있겠는가? 하하.

나는 나름대로 기독교인이라고 생각하면서도 성탄절이라는 날을 그렇게 좋아해 하지 않았다. 애당초 성탄절은 예수님의 탄생과 전혀 상관이 없는 날짜이기도 한데다가, 로마 제국에서 태양신(Sol Invictus)을 기념하는 축일이 전파된 것이라는 설도 있을 정도이다. 게다가 기독교에서 예수님의 탄생이 언제냐는 그다지 중요한 것이 아니며(예수님의 죽음 및 부활이라면 모를까), 설령 탄생일을 기념할 수 있다고 백발짝 양보하더라도 종교 중립적인 관점에서 종교와 상관 없는 국가 차원에서의 공휴일로 만들 이유는 없다. 차라리 크리스마스를 걷어 내고 한글날을 공휴일로 만드는 게 올바른 일일 것이다.

그러나 만약 성탄절이라는 날짜 자체를 포기하지 않은 채 성탄절을 기념하고 싶다면, 내가 생각하기에 가장 좋은 방법은 월드 와이드 웹의 탄생을 기념하는 것이다. 21년 전 오늘 팀 버너스리(Tim Berners-Lee)는 최초의 웹 브라우저와 웹 서버를 개발해서 운영하기 시작했다. 물론 그 전에도 하이퍼텍스트라는 개념이 존재하지 않았다는 건 절대 아니지만, 기술에 익숙한 사람 뿐만 아니라 누구나 접근할 수 있고 누구나 사용할 수 있는 그런 보편적인 시스템을 만든 기반에는 그의 첫 발짝이 있었다. 날짜도 맞지 않고, 특정 종교에 매여 있을 수 밖에 없으며, 심지어 상업적으로 변질되기까지 하는 공휴일보다 이런 것을 기념하는 것이 더 올바른 일이 아니겠는가?

덤: 비슷한 이유에서 리처드 스톨만은 성탄절에 아이작 뉴턴의 탄생(1642년 12월 25일)을 대신 기념한다고 한다. 하지만 예수님의 탄생과 마찬가지로, 특정인의 탄생은 생각보다 그렇게 기념할 가치가 없다. 특정 개념의 탄생은 다르다.