Arachneng on Everything

망할 놈의 집 (2)

Fri, 17 Feb 2012 01:35:52 +0900

어쩌다 보니까 대전에서의 생활을 마무리하고 다시 집에 얹혀서 살아야 하는 신세가 되었다. 실은 그게 최근 글을 못 쓰는 이유 중 하나인데(바쁘니까) 그건 뭐 그렇고, 집에 와서 느끼는 점이라고는 내가 최선이 아닌 차악을 선택했구나 하는 후회 뿐이다. 예전에 같은 제목의 글로 그 불만을 토로했건만 그다지 나아진 건 없다.

내가 만에 하나 자식을 가진다면, 만약 자식이 (내가 보기에) 바람직한 행동을 하지 않을 경우 나는 “그 일을 하지 말라”라는 고압적인 지시보다는 (좀 자신이 없긴 해도) “그 일을 하면 어떤 일이 생길까?”라는 토론을 할 작정이다. 이를테면, 왜 횡단보도에서 신호를 지켜야 하는가? “지켜야 하니까”라는 답변은 전혀 쓸모가 없다. 사실 그렇게 듣고 자라 온 많은 사람들은 커서 절대로 횡단보도에서 신호를 지키지 않는다. 그보다 더 정확한 답변은, “도로는 보통 차가 다니지만 그렇다고 사람이 다닐 수 없게 하면 길을 건널 수 없기 때문에 일정 시간동안은 차가, 일정 시간동안은 보행자가 다니도록 서로 약속해 놓는 것”이라는 내용이어야 한다. 서로 양보하지 않으면 당연히 교통사고가 일어날 것이니까. 그렇다면 이런 질문이 날아 올 수 있다. “그럼 모든 횡단보도를 육교로 만들면 되잖아요?” 이제 유모차를 끌고 다니는 아기 엄마들과 보행이 불편한 사람들에 대해 설명해 줄 차례이다.

이런 접근은 좀 시간이 걸리고 항상 쓸 수 있는 접근이 아니긴 하지만, 만약 접근이 먹힌다면 고압적인 지시보다 훨씬 바람직한 게 확실하다. 게다가 이 과정에서 내가 잘못 생각하고 있는 것들을 바로 잡을 수 있다. 예를 들어서 자식한테 횡단보도를 육교로 만들지 않는 이유를 “그러면 불편해 할 사람들이 많으니까”라고 말할 수는 있지만, 사실 우리는 이 모든 게 돈 때문이라는 걸 알고 있다. 만약 자식이 충분히 나이가 충분히 된다면 저 답변이 완벽하지 않다는 사실을 눈치챌 것이고, 그렇다면 부모도 “나도 잘 모르겠다”라는 항복 선언을 해야 할 때가 올 것이다. 이 때 단순히 항복을 하는 것이 아니라, “정말로 돈 때문에 못 세우는 것인가?”라는 의문을 갖고 자식과 함께 자료를 찾아 보고 토론을 한다면 좀 더 도움이 될 것이다. 물론 모든 일에 대해 토론을 할 수는 없기 때문에 적절한 타협점이 필요하다.¹

나는 모든 사람이 저러리라고 기대하지는 않았지만, 적어도 내 부모님께서 저런 노력이라도 하는 시늉이라도 보여 주셨으면 하는 기대는 다소 있었다. 물론 그 기대는 십수년이 지난 지금 완전히 시궁창으로 빠지고 말았지만. 텔레비전(그렇다, 그 망할 바보상자 말이다!)에서 지나가는 얘기를 검증 없이 그대로 받아 들이고, 실제로 그게 옳은지 그른지 찾아 보거나 적어도 얘기를 나눠 볼 생각 없이 무지막지하게 강요를 하며, 그 강요에 대해서 적절하게 응수하려고 하면 정신승리 급의 논리로 대화를 원천 차단하는데 무슨 기대가 필요한가? 녹즙이나 과즙을 많이 마셔야 한다는 얘기를 듣고 과일을 살 생각은 안 한 채 포도즙을 두 상자를 배달시켜서 대재앙을 일으킨 사건은 지금도 잊을 수가 없다. 내가 모든 걸 포기하고 악을 쓰면서 힘겹게 설득을 시키는 장면이 상상되시는지?

그렇기에, 나는 적어도 내 자식(생긴다면…)한테는 내 부모님의 과오를 되풀이할 생각은 추호도 없다. 제대로 할 수 있을 지는 모르겠지만, 적어도 나중에 이 글을 읽는 미래의 자식이 내가 소싯적에 이런 생각을 하긴 했구나, 하고 내 사정을 이해라도 해 줄 수 있으면 절반 정도는 성공한 게 아닐까. 모름지기 자기가 원하지 않는 일을 남에게 시키지 말라 했으니, 부모님을 타산지석으로 삼아 내 자신을 바꿔 나가야 할텐데 꿈은 높고 현실은 그저 그렇다. 그래도 노력해야지.

내가 아는 사람 중에는 어릴 적에 지나치게 토론만을 강조받은 끝에 주화입마에 빠져 버린 인물이 있다. 아주 옛날에 심하게 비판했던 두 사람 중 한 사람인데(다른 한 사람과는 화해한지 오래이다), 인지부조화로 끝장 보는 사람으로 유명하다. ↩

요즘 허구한 날에 “학력 인증”을 하겠다고 덤벼드는 일이 잦은데, 그 양상은 크게 둘로 나눌 수 있다. 하나는 그 대상이 (가짜의) 학력을 내세워서 이런 저런...

Thu, 26 Jan 2012 11:59:59 +0900

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

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

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

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

실제로 조선일보 같은 경우 분야에 따라서는 매우 질 높은 기사를 뽑아 내기도 한다. 이 얘기를 하던 도중에 어떤 이가 “조선일보는 일부 질 좋은 기사를 통해 빠져나갈 수 있는 부동층을 다시 끌어 모으고, 그로써 여론 지배력을 확립한다”라고 지적했는데, 틀린 말은 아니지만 어차피 조중동 뿐만 아니라 모든 언론은 비판적으로 봐야 하는 것이다. 일부 언론이 팩트를 의도적으로든 아니든 숨기면 다른 언론에서 그 팩트를 찾아 나서는 수 밖에 없기도 하고. ↩

제로보드 4

Thu, 12 Jan 2012 14:42:57 +0900

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

사건

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

웹 서버를 돌리는 몇몇 서버가 제로보드 취약점으로 웹셸이 뚫렸다.
웹셸은 보통 웹 서버 계정(www-data, www 등)으로 돌아 가지만, 추가적인 취약점을 사용해서 루트 권한을 얻을 수 있다.
이렇게 얻은 루트 권한을 가지고 SSH 서버를 갈아 치우면 SSH 접속 시 아이디와 암호를 평문으로 기록할 수 있다. (SSH가 아무리 암호화를 한다고 해 봤자 SSH 서버 자체가 기록을 하면 아무 소용이 없다!)
이제 이 아이디와 암호를 가지고 다른 서버에 접속을 시도해 본다. 성공하면 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를 쓴다는 것은 자기 뿐만 아니라 남들까지 위험에 빠뜨리겠다는 생각이라고밖에 할 수 없다.

나는 preg_replace가 널 문자를 받으면 정규식을 짤라 먹는다는 건 알고 있었어도 “왜” 그러는진 몰랐으며, 왜 어떤 경우에는 널 문자를 받아도 정규식이 짤리지 않고 에러가 나는지 알지 못 했다. 나중에서야 HTTP 요청에 들어 간 %00이 PHP 및 웹 서버 설정에 따라 널 문자로 파싱되지 않는 경우도 있다는 걸 알게 되었다. ↩
한 번 당한 뒤에 웹셸 설치가 불가능하도록 웹 서버 설정을 따로 추가했는데… 그래도 솔직히 불안하다. ↩

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

Mon, 09 Jan 2012 03:05:36 +0900

아… 근데 이 글 써 놓고 보니까 원래 내가 하고 싶은 얘기는 앙골모아 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이 되겠지만) 앙골모아도 고칠 부분이 꽤 있을 것 같다. 이게 문제 해결에 도움이 된다면 얼마나 좋으련만.

리샘플링을 하기는 하는데, 리샘플링된 오디오 데이터를 별도의 중간 버퍼를 쓰지 않고 출력으로 그대로 보내 버리는 코드이다. 오디오 드라이버에 따라서 이게 허용이 되지 않는 경우도 있는 모양이다(하지만 내가 알기로 윈도에서 쓰는 DirectSound 백엔드는 허용을 했기 때문에 그냥 주석 없애고 그대로 썼었다). 1.3에서는 어떻게 잘 해결한 듯. ↩
이 문제는 theseit에서도 똑같이 겪었고, 그래서 맥 오에스 텐에서는 아예 그냥 SDL 무시하고 운영체제 API를 가지고 low latency 입력을 구현하려고 했지만… 다 아시듯이 망했어요. ↩
이 문제는 theseit에서도 똑같이 겪었고, (후략) ↩

앙골모아 2.0

Mon, 09 Jan 2012 02:45:46 +0900

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

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

뭐 그래서, 2.0 alpha 1까지 들어 간 기능은 이런 게 있다.

호환성 관련해서 상당히 많은 부분을 뜯어 고쳤다. 이제 엔디안 관련된 문제는 별로 없을 것이다. 사실 의도적으로 이렇게 짠 건 아닌데 반대 엔디안으로 테스트를 해 본 적이 없어서 드러나지 않은 문제가 상당수 있었다.
옵션을 좀 더 멀쩡하게 갈아 엎었다. 이제 ./angolmois foo.bme vw 3.0 이런 웃기지도 않은 옵션(…) 대신 ./angolmois foo.bme --viewer --no-fullscreen -a 3.0 식으로 쓸 수 있다. 참고로 getopt 안 쓰고 하느라 좀 머리를 굴렸다.
옵션 갈아 엎는 김에 한 키에 여러 키보드 키를 대응시키는 기능을 추가했다. 이 기능은 생각보다 간단하지 않은데, 심지어 이런 기능이 있는 BMS 플레이어들 중에서도 처리를 대강 대충 하는 경향이 있다. 앙골모아에서는 귀찮다는 이유로 여러 키보드 키 중 한 개 이상이 눌려 있으면 계속 눌려 있는(즉 롱노트라면 눌려 있는 상태로 유지되는) 것으로 가정하였다.
viewer 모드에서 제대로 된 오토 플레이가 동작한다. 즉, 스코어와 콤보가 제대로 올라간다.
게이지가 좀 더 짜졌다. 옛날에는 MISS 시 게이지의 2.3%가 깎였지만 이제는 6% 정도 깎인다(다만 앙골모아는 MISS와 BAD의 게이지 하락 폭이 달라서 매우 빡센 건 아니다). 그리고 올라가는 속도도 좀 조정해서 한 노트에 1% 이상 올라가는 일이 없도록 하였다. 1.0 게이지는 당시 내가 리듬잇²에서 클리어할 수 있는 곡은 앙골모아에서도 클리어할 수 있고 못 하는 곡은 못 하도록 의도는 했는데 게이지가 훨씬 후했던 것으로 판명이 나 버렸다. 2.0에서는 평균적으로 ☆12로 인정받는 곡을 내가 아슬아슬하게 클리어³할 수 있을 정도로 재조정했다.
리소스 로딩 속도를 개선했다(…). 1초에 리소스가 30개 이상 로딩이 잘 안 되던 옛날 컴퓨터에서는 전혀 깨닫지 못 했는데, SDL_Flip이 수직 동기화에 영향을 받아서 1초에 로딩 가능한 리소스 수가 제한되어 있었다. ~~이래서 사람은 SSD를 쓰고 봐야 합니다.~~
이제 공식적으로 ogg/mp3 키음을 지원하고, 최근 경향에 발맞춰 동영상도 어느 정도 지원한다. 동영상 지원에 smpeg를 사용하고 있어서 MPEG-1만 지원하긴 하지만 어차피 호환성 때문에 아무도 다른 걸 안 쓰므로 웬만한 건 잘 도는 것 같다.
별 건 아니지만 F3/F4로 속도 조절을 할 때 삑 하는 소리가 나도록 했다. 안 나니까 헷갈리더라.
~~옛날보다 코드가 100배 정도 깔끔해졌다.~~

이 버전이 “alpha 1”이라는 말은 물론 그 뒤에도 좀 손을 볼 게 남아 있다는 소리다. 당장 생각하고 있는 것으로는 다음과 같은 것이 있다.

코드를 좀 더 정리한다. 기존 코드에 비하면 상당히 정리된 상태긴 하지만 여전히 정리가 되지 않은 부분이 많고, 코드 구성도 산만함의 극치이다. 워낙에 초기 코드가 기괴했던 터라, 코드를 제대로 정리하면 코드 길이가 오히려 “줄어들” 것으로 기대하고 있다. (나름대로 2천줄을 마지노선으로 잡고 있는 터라…)
비슷한 의미에서, 라이브러리나 표준 함수들로 해치울 수 있는 것들을 일일이 수작업으로 하고 있는 코드들은 모두 걷어 낸다.
리플레이 기능을 만든다. 물론 리플레이 파일을 만들려면 처음에 옵션을 줘야 한다. (이게 귀찮다면 셸 스크립트로 shell을 만들어서 써도 된다. 사실 이렇게 쓰는게 앙골모아의 최소주의 철학에 더 걸맞다!)
비트콘 지원을 할 수 있는지 확인해 봐서 되면 지원하도록 한다. 사실 윈도라면 Joy2Key가 있긴 하지만, SDL이 조이스틱 입력을 지원하니 가능하면 바로 되게 하는 게 낫지 않을까 싶다.
게임 종료 후 결과 화면을 좀 더 개선해 볼 수도 있을 것 같다.

최근 추이로 볼 때 다음 개발은 2014년이 될 것 같지만… 여하튼 theseit는 죽었어도 앙골모아는 안 죽었으니까 희망을 놓지 말자.

1만 5천 줄이 아니라 1만 5천 바이트다… 지금 생각하면 줄일 여지는 훨씬 많다. 큰 어려움 없이 1만 바이트 아래로 줄일 수도 있을 것이다. ↩
게다가 리듬잇은 BMS 플레이어 중에서도 판정·게이지가 매우 후한 것으로 잘 알려져 있다. 나중에 루브잇에서 다소 어려워졌으나 그래도 여전히 후한 축. ↩
앙골모아는 게이지 30%(=150/512)가 클리어 기준이므로, 이 기준을 그대로 IIDX나 그와 비슷한 판정·게이지를 가진 플레이어로 가지고 가면 클리어를 못 하는 게 맞다. ↩

사흘 전(2012-01-03)에 찍은 이 사진은 아마도 내가 3년 가까이 유비트를 하면서 가장 희열을 느낀...

Fri, 06 Jan 2012 05:38:08 +0900

사흘 전(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를 찍었는데 에어레이드라고 못 할 이유가 있겠는가? 하하.

리듬게임은 음악의 “리듬” 요소를 극대화시켜 그로부터 게임 요소를 만들어 낸 게임이다. 그런데 리듬은 멜로디와는 달리 그 패턴이 덜 다양하니, 게임 요소를 만들 때는 패턴화된 리듬에 덧붙여 지루함을 덜기 위한 추가 요소를 통해 변화를 꾀하게 마련이다. 유비트의 경우 요즘은 너무 보편화된 것 같은 글자 패턴(…)이 한 예가 될 것이다. ↩

월드 와이드 웹의 생일을 축하합니다 (또는, 성탄절 개명하기)

Sun, 25 Dec 2011 22:33:57 +0900

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

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

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

문지동이라고 흔히 부르는 학교랑 좀 멀리 떨어진 기숙사에 살고 있는데, 아무래도 새 건물인데다 넓고 인기가 없어서...

Mon, 28 Nov 2011 12:32:47 +0900

문지동이라고 흔히 부르는 학교랑 좀 멀리 떨어진 기숙사에 살고 있는데, 아무래도 새 건물인데다 넓고 인기가 없어서 그런지 기숙사비도 싸서 나는 만족하지만 인기가 없는 데는 당연한 이유가 있는 법. 아무리 빨라도 30분, 늦을 때는 90분에 한 번 오는 셔틀버스 탓이다. (덕분에 룸메가 중고 차를 샀다.) 그래서 셔틀버스 시간표를 좋든 싫든 봐야 하는데, “본원도착”과 “본원출발”에 하이라이트가 들어가 있으니 문지에서 출발하는 시각 대신에 본원에 도착하는 시각을 보는 경우가 적지 않다. 도대체 누가 도착 시각에 신경 쓸까? 심지어 돈 받고 사람 태우는 고속버스에도 출발 시각은 있어도 도착 시각은 없다(예상이 어렵기 때문이기도 하지만).

텀블러가 최근 접속이 전혀 되지 않아서 (그것도 *.tumblr.com은 되고 CNAME은 모두 맛이 가는 웃기지도 않는 상황인지라) 글을 전혀 올리지 못 했다. 아마 조만간...

Sat, 19 Nov 2011 00:51:55 +0900

텀블러가 최근 접속이 전혀 되지 않아서 (그것도 *.tumblr.com은 되고 CNAME은 모두 맛이 가는 웃기지도 않는 상황인지라) 글을 전혀 올리지 못 했다. 아마 조만간 텀블러를 떠나든지 대체 수단을 마련하든지 어떻게든 할 것 같은데… 일단은 글 올리는 속도는 기대하지 마시길.

최근의 그 글에 대해서는 할 말이 굴뚝같이 많지만 말을 좀 아껴야 겠다. 지금 보니까 너무 길고 장황하다. 어중간한 운영이 운영을 안 하는 것보다 못하다는 점만 짚고 넘어 가기로 하자.

외래어와 외국어

Mon, 31 Oct 2011 07:52:34 +0900

외래어와 외국어:

neoocean: 포토스트림에 대한 해석.

[전략]
문제는 ‘포토스트림’이라는 이름입니다. 혹시 이 단어가 영어권 국가 사람들에게는 포토스트림의 작동 방식과 의미를 쉽사리 설명할 수 있었을지도 모릅니다. 하지만 포토스트림을 한국에서는 ‘사진 스트림’으로 번역했는데 이걸로는 포토스트림이 ‘사진첩’과 다른 속성이라는 사실을 전달 받기 어렵습니다. ‘스트림’이라는 말에 익숙한 사람은 십중팔구 개발자일 가능성이 높기도 합니다. 사실 잠깐 생각해서는 마땅한 표현을 생각해내지 못했지만 이 부분은 iOS5 출시 전에 좀 더 시간을 들여 고민했어야 하지 않았나 싶습니다. 이름만 적당히 지었어도 사람들이 포토스트림을 사진첩으로 인식해 정리하려고 시도하는 불행한 일은 훨씬 줄어들었을 겁니다.

이거 보고 그냥 생각났는데, 한국어에서 “스트림”과 “스트리밍”은 다른 말이다. 전자는 한국어권에서 어떤 유용한 의미도 담지 않은 외국어이지만 후자는 음악이나 영상을 실시간으로 받으면서 본다는 의미로만 쓰이는 외래어이다. 아마 “스트리밍”을 보고 뭔가 흘러간다는 생각을 할 사람은 많을지 몰라도 “스트림”을 보고서 그 생각을 할 사람은 많지 않으리라 본다. 사진이 흘러간다는 느낌이 안 드니 기능을 착각하는 것도 당연한 일인데, 차라리 stream의 뜻을 살리지 않고 옮겨간다는 느낌만 살려서 다른 말을 만드는 게 나았을 지도 모른다.

“스트림”과 “스트리밍”에서 볼 수 있듯, 영어권에서 한국어권으로 외래어가 들어 올 때는 관련된 낱말이 들어 올 때도 있고 안 들어 올 때도 있다. 원래 낱말이 명사였고 그게 동사로도 쓰인다면 보통 해당하는 동사나, 명사와 동사가 겹쳐서 구분이 안 될 때는 동명사(-ing)가 함께 들어 오기 마련이다. (예: 프로그램, 프로그래밍) 반면 원래 낱말이 동사였을 경우 대응되는 명사는 거의 들어 오지 않고, 동사 대신 동명사가 들어 오는 경우도 흔하다. Streaming의 경우 본래 영어에서의 동사는 명사로부터 유추되는 뜻이긴 하지만, 한국인 중 누구도 명사로서의 stream에는 주목하지 않았기 때문에 명사와는 구분되면서 다른 뜻을 가진 동명사 streaming이 외래어로 정착된 것으로 보인다. 이게 좀 심해지면 동사로 들어 온 낱말이 명사로 전용되거나 반대의 일도 일어날 수 있다(예를 들어 “makeup”이라는 낱말은 영어에서 동사로 전혀 쓰일 수 없지만 한국어에서는 “메이크업하다”라는 말이 정착되어 있다).

외국어에 익숙한 사람들은 이런 상황을 보고 잘못된 외국어 사용이라고 비판할 수 있겠지만, 그 비판은 정당하지 않다. 왜냐하면 우리가 쓰는 것은 외국어가 아니라 외래어이기 때문이다. 외래어는 한국어에 있던 낱말만으로 소화할 수 없는 개념을 한국어로 들여 오기 위해 다른 언어의 낱말의 “의미”를 끌어 들인 것이지, 그 낱말이 그 언어에서 어떻게 활용되는지까지 끌어 들인 게 아니라는 걸 주의해야 한다. 반대로 외래어를 외국어에서 잘못 사용하는 실수만 범하지 않는다면 상관 없다(다행히 한국인들도 요즘은 얘기를 워낙 들었는지 외국에서 시도 때도 없이 fighting! 하진 않는 것 같다만).

가명과 필명의 차이

Tue, 25 Oct 2011 23:37:48 +0900

나는 내 실명을 공개하는 데 별 거부감을 느끼지 못 하는 사람 치고는 사용하는 필명¹이 많은 편이다. 지금 주로 쓰는 lifthrasiir나 아라크넹 같은 이름 말고도 제한적으로 하지만 꾸준히 사용하는 필명(안타깝게도 여기서 말하기에는 좀 문제가 많은 게 있다)이나, 옛날에 아무 생각 없이 정했다가 지금은 묻혀버린 필명(문제의 ㅌㄲㄱ)까지 합하면 열 몇 개 정도 되는 것 같다.

내가 이렇게 필명이 많은 이유는 아무래도 상황에 맞춰서 새 필명을 만들기 때문인 게 강하다. 예를 들어서 프로그래밍을 할 때는 거의 대부분 lifthrasiir를 쓰고(옛날에는 이 역할을 ㅌㄲㄱ이 맡고 있었다), 좀 장난스런 글을 쓸 때는 아라크네/아라크넹을, 조용한 문맥(트위터 같이 글 별로 안 올리는 곳이나, 학술적인 곳이나)에서는 senokay를, 정말로 내 주장을 강조하는 글이나 기술 문서 같은 경우 내 본명을 쓰는 식이다. 어차피 조금만 찾아 보면 네 이름이 동일인을 가리키는 걸 쉽게 알 수 있을테니 신원을 숨길 목적은 아니고, 이 글이나 코드 등등이 어떤 시점에서 작성되었는지 무의식적인 힌트를 주는 목적이 더 강하다. 이 저널을 옛날부터 구독한 사람이라면 저널 옛날 이름이 “Arachneng on Everything”이라는 걸 알텐데, 이것도 이 맥락에서 생각하면 당연한 것이 애당초 이 저널은 메아리에 완전히 포함시킬 목적으로 만든 곳은 아니었기 때문이다(지금이야 뭐 통합되었고 이름이 잘 숨겨져 있지만). 나 보고 왜 이리 필명이 많냐(…)고 묻던 사람은 이걸로 어느 정도 답변이 되었길 바란다.

뭐 나같이 필명이 넘쳐나는 사람은 드물겠지만, 이름은 필명이든 실명이든간에 자신의 아이덴티티를 나타내는 좋은 수단이기 때문에 필명만 쓴다는 이유로 누군가를 배척하거나 하는 사고는 매우 위험하다. 애당초 실명을 쓰지 않는 이유는 실명은 i) 보통 자기가 정한 게 아니고 ii) 설령 바꾸고 싶어도 바꾸기 힘들 뿐만 아니라 iii) 어차피 제약 사항이 강하기 때문이니까 말이다. “지나가다”와 같은 정말로 생각 없이 휘갈겨 놓은 가명을 문제 삼을 순 있어도, 그 사람이 꾸준히 써 오던 필명을 문제 삼는 것은 참으로 생각 없는 행동이라 할 수 있다. 현실 사회의 관계를 굳이 온라인에서까지 끌어 오고 온라인에서의 관계를 끊어 버리려고 하는 듯한 모 SNS들의 행동이 혐오스럽게 느껴지는 이유 중 하나다.

영어에서 흔히 pseudonym이라고 부르는 말인데, 사실 이걸 그대로 “가명”이라고 번역하기에는 용례가 가지각색이어서 무리가 있다. 내가 말하고자 함은 “특정한 목적을 가지고 장시간동안 유지하는, 법적인 이름이 아닌 또 다른 이름”인데 여기에 딱 들어 맞는 용어가 한국어에도 영어에도 없다(heteronym이라는 말이 있긴 한 모양이다만). 장시간 유지하는 게 포인트인지라 일반적인 “가명”과는 분명히 구분되는 개념임을 유의할 것. ↩

Do Not Fall Back to UTF-8

Sun, 23 Oct 2011 03:41:15 +0900

Everyone knows that UTF-8 is now universal; it is so universal that a half of all webpages collected by Google is in UTF-8 by 2010. This success is certainly backed by an ASCII-compatibility (and thus, an ability to encode many Latin letters without further overheads) of UTF-8, which UTF-16 certainly does not have. But it does not mean that you can use UTF-8 for everything.

Case study: You are writing an IRC client. IRC (Internet Relay Chat) is very ancient chatting protocol and still kicking around. While IRC is not designed for Unicode in mind¹, it is a text-based format and all UTF-8 multibyte characters do not overlap with ASCII characters like @ or ! which are special in IRC. As a result nowadays UTF-8 in IRC is quite common, and even if the default encoding is not UTF-8 it seemed that using UTF-8 for every characters not in that default encoding is reasonable. Right?

No. You are dead wrong. It may make sense when you are limited to Western charsets like ISO 8859-1. For example, you are very sure that a two-byte sequence looks like UTF-8 is really encoded in UTF-8 even though it is found in ISO 8859-1 text: the first byte of such sequence should be an accented uppercase Latin letter and the second byte is either special characters, unused bytes or one of handful accented letters extended by Windows-1252. But this assumption breaks down when most characters used do not fall in the ASCII-compatible region. Let’s see how this problem can be devastating.

In Korea, EUC-KR was a dominant legacy Korean encoding until UTF-8, and until very recently the major Korean IRC networks only supported EUC-KR. The Hangul syllables, which contain most multibyte characters used in Korean, are encoded from B0 A1 to C8 FE. As two-byte UTF-8 sequences run from C2 80 to DF BF, roughly 9% of EUC-KR Hanguls and 11% of two-byte UTF-8 sequences overlap with each other! As a result many Korean words can incorrectly guessed as a meaningless UTF-8 text: some common examples include “킁킁”, “특징”, “치킨”, “친척”, “황홀” and so on. This is clearly unacceptable for Korean users, as they cannot recognize the resulting UTF-8 text “ůů”, “Ư¡”, “ġŲ”, “ģô” and “ȲȦ” at all.

In fact, this kind of problems can appear in any EUC encodings: EUC-KR (commonly used as a form of Code Page 949), EUC-JP (long-time standard for Unices but not others), EUC-CN (commonly used as a form of GBK) and EUC-TW (rarely used). Fortunately (or unfortunately), Japaneses gave up about using multibyte encodings in IRC a lot earlier and used ISO-2022-JP instead; now UTF-8 is becoming increasingly popular though. But I guess Chinese IRC networks have the exactly same problem.² Unfortunately there are still many IRC clients that have this problem.

The moral of this story is that you cannot harmonize UTF-8 with other legacy encodings. If one does have to use a legacy encoding ever, he/she should use that encoding and nothing else (including UTF-8). Hence the title: Do Not Fall Back to UTF-8. Ever.

IRC is as old as Unicode standard, both emerged in late-1980s. And Unicode was not quite stable until version 2.0 (1996), when all existing characters are guaranteed not to change. That’s maybe why Windows 95 (1995) chose to use Unicode 2.0, even though it was in development at that time. ↩
I don’t really know about the encoding usage in Chinese IRC networks, though I do know that ISO-2022-CN is not widespread. ↩

데니스 리치

Thu, 13 Oct 2011 13:47:22 +0900

이번 달 들어 이 동네 사람들이라면 누구나 알고 있을 법한 두 사람이 죽었다. 한 사람은 외신 베껴쓰기에 바쁜 국내 언론들이 열심히 치켜 세우고 있는 스티브 잡스요, 다른 한 사람은 그런 언론들이 관심 1그램도 주고 있지 않은 데니스 리치(Dennis Ritchie)이다. 팀 브레이가 그가 없었으면 일어나지 않았을 일들을 몇 개 요약해 놓았다.

데니스 리치는 사실 스티브 잡스보다 더 중요한 사람이다. 왜냐하면 그가 수십년 전에 (일부는 여러 사람과 함께) 만들었던 운영체제와 프로그래밍 언어가 세계를 장악하고 있기 때문이다. (모르는 사람을 위해: 각각 유닉스와 C.) 운영체제는 마이크로소프트 윈도의 도래로 그 세력이 좀 줄어들었다고 반론할 수는 있겠으나, 그 윈도조차도 결국 그가 만든 프로그래밍 언어로 짜였다는 걸 생각해 보면 반론을 할 여지도 별로 없다. 게다가 그 운영체제에서 유래한 개념들은 지금의 운영체제들에서 마치 당연하다는 듯이 쓰이고 있지만 (역시 모르는 사람을 위해: 파이프!) 그 당시로서는 매우 혁명적인 것이었다. 그렇기에 스티브 잡스의 영향력은 그가 직간접적으로 관여한 장비와 소프트웨어를 사용하는 사람들에게만 미치지만, 데니스 리치의 영향력은 현대의 거의 모든 프로그래머와, 그 프로그래머들이 만든 프로그램을 사용하는 거의 모든 사용자들에게 미친다.

데니스 리치의 또 다른 영향력은 프로그래머들이 새 언어를 배울 때 흔히 짜는 코드에서도 찾아 볼 수 있다. “Hello, world!” 프로그램은 그가 The C Programming Language에서 처음으로 쓴 것이다. 그렇기에 데니스 리치의 추모를 다음 코드로 대신하는 것은 충분히 의미가 있지 않을까 싶다. (via HN)

#include 

int main(void) {
    printf("goodbye, world\n");
    return 0;
}

뭐 이맘때면 하게 되는 일이지만, 유비트 코피어스는 열심히 하고 있다. 니트가 나왔을 적에 쓴 글과 비교했을 때...

Tue, 11 Oct 2011 11:04:09 +0900

뭐 이맘때면 하게 되는 일이지만, 유비트 코피어스는 열심히 하고 있다. 니트가 나왔을 적에 쓴 글과 비교했을 때 코나미가 스코어 데이터를 다시 무료화한 건 환영할 만한 일이요, 레벨 8의 세분화가 전작에 이어 계속 진행되고 있다는 점은 우려할 만한 일이다. 레벨 10 추가된 건 대부분 해 봤는데, 역시 에반스와 에어레이드의 위력을 뛰어 넘을 만한 곡은 없었던 것 같다(첫 플레이에 대부분 89~93만을 기록했다). 짤방은 아직 해금도 안 된 주제에 박스모드에서 운 좋게 걸려서 첫 플레이에 엑설런트를 찍은 HEAVENLY MOON 베이직.

《그=그녀》

Tue, 20 Sep 2011 04:19:16 +0900

오랜만에(아마도 2년만에?) 《그=그녀》를 봤다. 아직도 완결이 안 났던가 이거….

내가 좋아하는 만화·애니메이션 분류는 크게 세 가지로 나뉘는데, 한 가지는 일상물이고, 다른 한 가지는 개그물이요, 마지막 하나는 일상물이자 개그물인 만화이다. 이 얘기인즉슨 나는 줄거리의 기복이 크면서도 개그 요소가 전혀 들어 있지 않은 만화를 특히 싫어한다¹는 말이고, 덕택에 대부분의 “싸우는” 만화, 능력자 배틀, 그리고 거의 모든 극화를 보지 않는 편이다. 그러나 줄거리의 기복이 큰데도 개그 요소가 들어 있어서 재밌게 잘 보는 작품이 없지는 않은데 이 작품도 그 중 하나이다. 사실 작가 긴다이치 렌주로(金田一蓮十郎)가 《정글은 언제나 맑음 뒤 흐림》에서 보여 준 센스를 생각하면 시리어스 전개라고 해도 여기에 속하지 않는 게 이상하다. (그리고 사실 《정글은…》도 시리어스 전개야 많고.)

내용은 (뭐 알 사람은 다 알테니) 생략하고, 개인적인 감상(처음 봤을 때는 1권만 봤었다…)으로는 성장물을 이렇게 구성할 수도 있구나하는 생각이 들었다. “철이 드는 과정”이 아닌 “서로를 이해하는 과정”을 다루는 것만 빼고는 구조가 매우 흡사하다. 물론 후자를 다루는 작품이 적은 건 아닌데, 두 사람이 부대끼던 도중에 문제가 생겨 갈등이 봉합되고 하는 걸 반복하는 게 흔하지 각자 혼자서 주어진 환경에서 고뇌하고 회복하는 경우는 흔하지 않다. 애초에 캐릭터의 설정이 굉장히 특이하기 때문에 서로 부대끼거나 고민을 남에게 털어놓거나 하는 게 힘들어서 생긴 특징이 아닌가 싶은데(마코토의 뇌내 회의를 생각해 보면), 결과적으로는 다른 작품과 차별화되는 요소가 되었다. 심지어 줄거리가 전개될 대로 전개되어서 거의 모든 갈등 요소가 정리된 상태에서도 이런 상황이 계속 나타난다(물론 시의적절하게).

어떻게 말하자면 결국 사람은 결혼 전까지는 육체적이든 정신적으로든 계속 성장하는 거니까, 이런 “확장된” 성장물의 구성이 나쁜 건 아닌 듯 하다. 고등학생은 좋은 대학교 들어 가면 인생 끝날 거라 착각하고, 대학생은 좋은 직장 취직하면 인생 끝날 거라 착각하는데 이 작품에서는 마찬가지로 “직장인은 좋은 배우자 만나면 인생 끝날 거라 착각하는” 부분을 꾸준히 건들고 있다. 게다가 주인공이 배우자는 없는 주제에 자식은 있는 오묘한 상황이라 마무리된 것으로 보이지만 실제로는 마무리되지 않은 정신적 성숙을 이야기로 풀어 나갈 수 있기에 이런 점은 더 부각된다. ~~이런 상황에 꾸준히 개그를 넣어서 적어도 평균을 유지하는 작가가 더 무섭다~~ 한 가지 흠은 이런 구성을 만들기 위해 사용한 배경 상황이 꽤 호불호가 갈릴 상황이라 모든 사람이 공감할 만한 소재는 아니라는 것이지만, 그 따위거 신경 안 쓰는 나 같은 사람한테는 괜찮았다. 그러니 혹시나 이걸 보려는 사람이 있다면 처음 대여섯 화를 보고 바로 결정하는 것보다는, 2권 중간 정도까지 본 뒤에 결정하는 쪽을 추천한다. (왜냐하면 전체적인 상황이 간단치 않은 까닭에 상황 정립에 1권 거의 전체를 쏟아 붓고 있어서 실제적인 에피소드는 2권 초부터 시작하기 때문이다. 프롤로그가 엄청나게 길달까…)

한 줄 요약: 가끔씩은 애니화 안 된 만화도 좀 봐야 겠습니다.

여기에 해당되는 작품은 뭔가 특별한 게 없다면 절대로 보지 않는데, 비교적 최근에 본 것 중에 여기에 속하면서도 잘 봤던 것이 그 유명한 《마법소녀 마도카☆마기카》였다. 그러나 이것도 1쿨 애니메이션이라 그랬지 2쿨이라거나 만화판이었다면 절대로 보지 않았을 것이다. ↩

…귀찮다고 글 쓰기를 차일 피일 미뤘더니 한 달동안 아무 글도 쓰지 않았구나!!! 어떤 프로그래밍 언어를 배우는 가장 확실한 방법은 그 언어로 충분히 큰 프로그램을...

Wed, 14 Sep 2011 15:26:49 +0900

…귀찮다고 글 쓰기를 차일 피일 미뤘더니 한 달동안 아무 글도 쓰지 않았구나!!!

어떤 프로그래밍 언어를 배우는 가장 확실한 방법은 그 언어로 충분히 큰 프로그램을 (바닥부터) 짜 보는 것이다. 시간 대비 효과가 얼마나 되는지는 사람마다 다르긴 한데, 나 같은 경우 그 효과가 굉장히 확실하다. 물론 시간을 감당할 수 있을 때의 얘기지만.

C: 앙골모아. 정확히 말하면 C는 잘 알고 있었지만 C로 어디까지 기괴하게 만들 수 있는가를 테스트한 것에 가깝다.
C++: theseit. STL, Boost 모두 적극적으로 써 보고 적극적으로 쓴 맛(…)을 맛봤다.
D: Delight. D로 뭔가 짜 볼까 기웃거리고 있는데 어째 쓰려는 라이브러리마다 성에 차지 않아서 결국 새로 만들다가 망한 비운의 프로젝트.
PHP: TiniWiki. 아마도 처음부터 끝까지 혼자서 짠 PHP 프로그램 중 가장 큰 것 같다(다른 것들은 협업이거나 말아 먹거나 해서). 데이터베이스를 쓰지 않는다는 특징이 있다.
Ocaml: Esotope. 모든 난해한 프로그래밍 언어를 아우르는(…) 거대한 구현체. 덕분에 설계에서 애를 먹고 있다.
하스켈: Liquid라고 하는 프로젝트가 있는데, 아직 공개할 만한 수준이 못 된다.

특이하게도 파이썬과 자바스크립트는 이런 대규모 프로젝트 없이도 부드럽게 잘 익혔는데, 아무래도 둘은 워낙 짧게 짧게 짤 일이 많아서 다른 언어와는 성격이 다르기 때문에 그렇게 된게 아닌가 싶다. 그 밖에 대강 할 줄은 알지만 목록에 들어가지 않은 언어로 루비, 자바, C# 같은 게 있는데 워낙 쓸 일이 없어서 코드 읽기에 부족하지 않을 정도로만 알아 둔 탓이 크다.

시간이 굉장히 많이 걸리긴 하지만, 이런 식으로 밑바닥부터 시작하면 언어를 사용하면서 느끼는 웬만한 의문점을 자기 스스로 해소할 수 있다는 장점이 있다. 예를 들어서 C++에서 직접 라이브러리를 만들어 보면 왜 다른 라이브러리들이 그런 식으로(= 종종 필요 이상으로 일반화되어) 설계되는지 이해할 수 있게 된다. ~~그리고 C++에 대한 적대심이 커진다.~~ 또한 코드만으로는 알기 힘든 언어 사용자의 문화나 자주 쓰이는 코딩 컨벤션 등을 이해하는 데도 도움이 되는데, 예를 들어 Ocaml에서는 좋든 싫든 모듈 구조화를 해야 하는데 이 모듈 구조화라는 것이 의외로 다단계로 올리기가 쉽지 않아서¹ 모듈을 한 단계에 몰아 넣고 대표 모듈을 만들어서 open SomeProject 같이 쓰면 안에 들어 있어야 할 모듈들이 다단계처럼 보이게 하는 꼼수를 쓰는 경우가 종종 있다. 직접 이런 구조가 필요한 프로젝트를 안 짜 보면 나중에 이런 상황이 닥칠 때 어떻게 해야 할지 알 수 없다(…).

특히 모듈이 여러 단계로 구성되어 있을 때 모듈을 “거슬러 올라가서” 접근하는 게 사실상 안 된다고 보면 된다. 예를 들어서 SomeProject라는 모듈에 SomeProject.Algorithm과 SomeProject.Handler라는 부모듈이 있어서 각각 알고리즘들과 (그게 뭐든간에) 핸들러들을 담는다고 하자. 그럼 SomeProject.Handler.Foo에서 SomeProject.Algorithm.Bar를 접근하고 싶은 게 당연한 얘긴데, 실제로 해 보면 거의 안 된다고 보면 된다. 굳이 하고 싶으면 함수자(functor)를 써서 실제로 Foo를 쓰려는 곳에서 SomeProject.Handler.Foo.Make(SomeProject.Algorithm.Bar) 따위를 하거나 해야 한다…. 애초에 Ocaml의 모듈 시스템은 보통 생각하는 패키지 시스템과는 어느 정도 거리가 있어서 어쩔 수 없는 노릇이긴 하지만 이럴 때는 많이 짜증난다. ↩

이전 글에서 계속. 둘째 집에도 상자는 무진장 많다(…). 이 쪽에도 한 50개 쯤 있지 않나...

Mon, 15 Aug 2011 03:29:32 +0900

둘째 집의 상자들. 이 쪽도 만만찮게 많다.

둘째 집의 중심부. 전체 3층에서 2층에 해당한다.

둘째 집 앞에 있는 거대한 용암 주사위. 지도에서 *빨갛게* 나온다!

둘째 집 1층의 나무 농장.

둘째 집 3층의 선인장 농장. 오른쪽에는 실패한 음악이...

아침놀의 집. 당연히 이 집 하나만 있는 게 아니다.

하늘로 향하는 철도.

날아 올라서...

이 철도는 현대식이라 안 내리고도 행선지를 선택할 수 있다(...).

하늘이 모조리 스카이로드로 뒤덮여 있다(...).

이전 글에서 계속.

둘째 집에도 상자는 무진장 많다(…). 이 쪽에도 한 50개 쯤 있지 않나 싶다.
이 집은 첫째 집(골짜기에 천장을 씌움)과는 다르게 산 안쪽을 깎아서 만들어서 규모가 좀 작은데, 그럼에도 불구하고 있을 건 다 있다. 이곳은 2층이고, 1층·지하 광산으로 가는 계단이 왼쪽에, 3층으로 가는 계단이 저기 너머에 보인다. 왼쪽에 잘 보면 선인장 농장에서 선인장이 떨어지면 켜지는 레드스톤 횃불도 볼 수 있다.
그리고 여기가 둘째 집 앞의 하이라이트. 모조리 용암으로 이루어진(!) 주사위이다. 안쪽은 비어 있어서 안쪽에 들어 가서 이 웃기지도 않는 용암 주사위의 위용을 구경할 수도 있다.
1층의 나무 농장. 첫 스크린샷(2층)에서 오른쪽에 잠시 보였던 것이 바로 저 나무들이다. 귀찮아서 자주 안 베니까 아주 빽빽하게 자랐다.
3층의 선인장 농장. 선인장은 본래 블록 3개까지 자라는데, 가로 4방향에 다른 블록이 있으면 자라더라도 바로 아이템으로 떨어지기 때문에 이런 메커니즘이 가능하다. 일단 선인장 아이템이 지정한 위치에 떨어지면 2층의 횃불이 켜지게 된다.
돌아 오는 길. 내 첫 집 옆에는 아침놀의 집이 있는데, 이 녀석 집도 장난이 아닌데 저널에서 보여 주기에는 양이 너무 많다….
첫 집의 둘째 동굴에 보면 웬 철도가 하나 놓여 있다. 이 철도 또한 반자동화되어 있는데, 직접 타 보면…
하늘을 향해 날아 올라…
스카이로드에 다다른다! 스카이로드란 마인크래프트 하는 사람들이 한 두 번쯤은 만들어 보는, 매우 높은(보통 y>120) 고도에 만드는 하늘길인데, 철도가 만들기 쉬워지면서 걸어다니는 (위험천만한) 하늘길을 모조리 철도로 교체해 버렸다. 게다가 광산차에서 내리지 않고 버튼만 눌러 바로 방향을 선택할 수 있는 시스템까지 구축되어 있다(표준화까지 되어 버렸다).
분명 내가 시작할 적에는 하늘에는 아무 것도 없었는데(…) 여기 저기에 스카이로드가 있으니 아주 볼만하다.

마인크래프트 9일차 스크린샷을 올린 뒤에 아무 것도 안 올렸었는데, 이게 다 귀찮아서 그런 거다. 솔직히 내가...

Mon, 15 Aug 2011 03:14:12 +0900

새로 정돈한 집. 복제기(...)가 눈에 띈다. 건너편에는 개집이...

집 옆에 있던 골짜기에 천장을 박아서(!) 인공 동굴을 만들었다.

대놓고 복제를 하기 위한 대량 생산 체제도 오케이.

집 윗쪽. 모두 깎은지 오래.

집 한켠에 있는 상자 무더기. 대강 60% 정도 쓰고 있는 듯.

멩거 스펀지는 횃불 꼽다가 포기(...). 길에는 사탕수수 밭이 생겼다.

다른 집으로 향하는 철도.

서버의 누군가가 만들어 놓은 엄청난 크기의 항공모함.

저 너머에는 프로토스 모선도 보인다. 모래를 무진장 많이 썼다나.

다른 집으로 향하는 통로.

마인크래프트 9일차 스크린샷을 올린 뒤에 아무 것도 안 올렸었는데, 이게 다 귀찮아서 그런 거다. 솔직히 내가 마인크래프트에서 뭔 삽질을 하는지는 아는 사람은 다 알고 있기도 해서(…). 하지만 맥북 에어를 사 놓고 보니 마인크래프트가 많이 빨라져서 매우 만족하고 있는데, 이 시점에서 마인크래프트 181일차 스크린샷을 올리기로 한다. 스크린샷이 너무 많아서 두 개로 나누기로 하자.

본래의 집은 골짜기에 천장을 박아서 만든 인공 동굴이었는데, 이 인공동굴을 최근에 아주 매끈하게 다듬고 횃불도 가멸차게 박아 넣었다. 윗쪽에 보이는 동굴이 개(늑대)집, 오른쪽 아래가 광산 입구이고, 윗쪽에 자세히 보면 보이는 문은 바깥쪽으로 통하는 또 다른 통로이다. 광산은 7층까지 있는데 6·7층을 빼면 사실상 폐광산이어서 지금은 다른 용도로 잘 쓰고 있다.
그리고 본래의 집 옆에 있던 골짜기 또한 개척했기 때문에 더 큰 인공 동굴이 탄생했다(…). 첫 동굴과는 달리 둘째 동굴은 자연 그대로를 유지하고 있다. 소규모 실험에 적합한 것 같다.
첫 스크린샷에 보면 다이아몬드 블록이 널려 있는데, 이것의 비밀이란… 뭐 숨길 게 있겠는가, 마인크래프트 서버 베타 1.7부터 1.7.2까지 존재했던 피스톤 블록 복사 버그를 사용한 복제기이다. 본래는 1.7.3이 나오면서 고쳐진 건데, 워낙 임팩트가 강했기 때문에 이 서버에서는 다음 버전 나올 때까지 1.7.2로 그대로 유지하자는 의견이 많아서 그대로 유지하고 있다. 덕분에 자원 걱정이 거의 사라졌는데, 아이템만으로 블록을 만들 수 없는 석탄과 레드스톤을 어찌 저찌 해서 복제할 수 있는 시스템을 폐광산 1층에 구축해서 잘 써 먹고 있다.
그리고 집 윗쪽은 완전히 갈렸다(…). 저기 위에 하늘로 솟아 오르는 무언가는 다음 글에서 설명.
첫 스크린샷에서는 가렸지만 집에 상자가 거의 100개 가까이 있고, 그 중 50% 이상이 사용 중이다. ~~마인크래프트 몇 달 하면 이 정도는 기본입니다~~
집에서 지하통로를 통해 바깥으로 나가면 멩거 스펀지 바로 앞에서 나온다. 본래는 멩거 스펀지에서 꾸준히 몬스터가 나와서 막으려고 횃불을 박으려고 일찌기 시도했으나, 너무 귀찮아서 손을 놓은지 오래이다. 아래에는 흙길이 지나갔었는데… 어쩌다 보니 흙길 옆에 사탕수수를 심어서 사탕수수 밭이 되고 말았다. 사실 이게 서버 전체에서 가장 큰(!) 사탕수수 밭인데, 농담이 아니라 길을 지나가면서 사탕수수를 모으기만 해도 평균 2~300개 정도를 공짜로 얻을 수 있다.
자원, 특히 철과 금이 넘쳐나면서 기존에는 꽤나 삽질을 해야 했던 철도를 비교적 자유롭게 만들 수 있게 되었다. 첫 집을 만들고 나서 한참 뒤에 엄청나게 떨어진 곳에 둘째 집을 만들었는데, 나중에 두 집을 잇는 철도를 만들었다. 반자동 시스템이 구축되어 있다(시작점에 광산차를 놓고 버튼을 누르면 자동으로 출발한다).
둘째 집으로 가는 길. 옆에 누군가가 만든 엄청나게 커다란 항공모함이 있다. 서버 전체에서 가장 부피가 큰 구조물이라고 알려져 있다.
반대편에는 프로토스 모선(…)과 농장(…)이 있다. 프로토스 모선 또한 엄청나게 커다란데, 모래가 수만개 들어 갔다(…)고 한다. 한편 농장이라는 건 거대한 몬스터 생성기인데, 생성되는 게 항상 소, 돼지, 닭, 어쩌다 늑대라서 고기를 모으는 데 효율적이라 생긴 이름이다.
그다지 멋은 없지만 둘째 집으로 들어 가는 통로. 다음 글에서 계속…

내가 xkcd를 안 좋아할래야 안 좋아할 수 없는 이유. 이전에 내가 안전한 암호를 만들려면 일단 길이 제한부터...

Thu, 11 Aug 2011 01:51:09 +0900

내가 xkcd를 안 좋아할래야 안 좋아할 수 없는 이유. 이전에 내가 안전한 암호를 만들려면 일단 길이 제한부터 없애라고 오랫동안 말해 왔던 걸 상기해 보자. 몇 가지 추가 사항:

첫번째 암호는 물론 암호에 대한 정보를 전혀 모른다면 엔트로피가 훨씬 높아지는 게 맞다. 이 경우 대략 72비트(~= log₂94¹¹) 정도의 엔트로피를 가진다. 그러나 그렇게 따지면 두번째 암호가 여전히 엔트로피가 더 높다(log₂27²⁵ ~= 119비트). 긴게 장땡이다.
두번째 암호를 그대로 쓰는 사람은 없길 바란다(제발…). 어딘가에 나타난 암호는 암호로서의 생명력을 잃었다고 보는 게 옳다.
두번째 암호가 제시하는 방법이 다 좋긴 한데, 한 가지 주의해야 할 점은 무조건 무작위로 선택한 낱말을 골라라라는 것이다. 인간이 수동으로 고르는 낱말 여러 개는 보통 서로 연관이 있게 마련이다. (그리고 딱 한 번만 시도할 것. 여러 번 시도해서 외우기 좋은 걸 찾았다면 그 암호는 좀 똑똑한 전수 조사로도 빨리 찾기 좋을 수 있다!)
두번째 암호가 제시하는 방법은 완전히 의미가 없는 난수랑 낱말을 잇기 때문에 어떻게 말하면 RFC 1751과 유사하다고 할 수 있다.
그리고 이 모든 것들은 네이트처럼 암호가 뚫려 버리면 답이 없으니까, 사이트의 중요도에 따라 암호를 여러 개 만들어서 관리하는 게 좋다. (나는 대략 대여섯개 정도를 함께 쓴다.)

반려동물

Fri, 05 Aug 2011 02:00:18 +0900

“잘못된 말의 사전” 시리즈를 시작하려고 한다. 옛날에도 이런 스타일의 글을 몇 개 쓴 적이 있어서 이 참에 기존 글에도 태그를 다 붙여 놓았다.

이전 글을 보면 알겠지만 나는 정치적으로 올바른 말 따위는 쓸모가 없다고 생각한다. 그럼에도 불구하고 “정치적으로 올바른 말을 쓰려는 시도”로 비칠 수 있는 시리즈를 시작하는 이유는 말을 까려는 게 아니라 그 말이 함의하는 개념을 까려는 것이다. 저 글에서 언급했듯, “낱말에 새로운 가치, 또는 의미를 부여하여 우리의 사고 방식을 바꾸려는 사람들이 끊이지 않”음에도 불구하고 그 시도는 까여야 마땅한 것이다. 만약 낱말이 그런 인위적인 과정 없이 자연스럽게 형성되었다면 내가 그 낱말을 여기서 다룰 이유는 당연히 없을 것이다.

트위터를 좋아하는 것은 아닌데(이것도 이미 글을 썼다!) 그래도 가끔씩 보면 이건 정말 따지고 싶은 충동이 들 때가 있다. 가장 최근 이슈는 역시 조준 사건이 아닌지 싶은데, 이 사건에 대해서는 정말 하고 싶은 말이 많지만 한 마디만 하면 이걸로 정리가 되겠다. 반려동물이라는 개념은 존재하지 않는다.

“반려동물”이라는 이름은 자칭 동물 애호가(이 낱말 자체는 다행스럽게도 의미를 정확히 담아 내고 있다)들이 사람이 동물을 사랑하고 보살펴 준다는 의미의 “애완동물”이라는 말을 사람과 동물이 동반자가 되자는 의미에서 바꾼 이름이다. 요컨대 인간과 애완동물은 인간이 주가 되는 단방향 관계인 반면, 인간과 반려동물은 인간과 동물이 동등한 위치에 있는 (적어도 그렇게 믿는) 양방향 관계인 것이다. 여기서 가장 큰 문제는, 이게 가능이냐 한 소리냐는 것이다.

이번 사건을 간략하게 요약하면 구조된 고양이를 구조자로부터 분양받은 사람이 그 고양이를 제대로 보살피지 못 하고 잃어버렸는데, 구조자가 분양받은 사람한테 현재 고양이의 상태를 알아 보려 했으나 번번이 답변을 회피하니 공론화시켜서 지금 사건이 이 지경까지 간 것이다. 당연하지만 분양받은 사람은 구조자한테 한 약속을 못 지켰으니 도의적인 책임은 질 필요가 있는데(그게 “피치 못 한 사정”이라면 처음부터 왜 분양받았단 말인가), 고양이 입장에서 생각해 보면 사실 구조자도 못 된 놈이다. 인간을 겨우 피해서 도망쳐 왔는데 구조한답시고 데려 와서 다시 인간한테 맡기다니! 실제로 고양이가 이런 생각을 하는지는 당연히 나도 모르지만 지금의 “구조”라는 작업이 정말로 동물을 위한 것인가에 대해서는 심각하게 고민해 봐야 하지 않겠는가.¹

요컨대, 구조자와 분양받은 사람 모두 결국 자기 만족을 위해 그 일을 하는 것이다. 물론 비단 동물 애호가라는 사람들 말고도 모든 사람은 (그게 어떤 형태로 나타나건간에) 자기 만족을 위해서 살아 간다만, 그 자기 만족이 다른 누군가를 피곤하게 한다면 그 일을 좋다고 하기는 좀 그렇다. 그리고 그 누군가가 꼭 인간일 필요는 없다. 지금 싸우는 짓은 어떻게 보면 당사자인 고양이는 쏙 빼 놓은채, 둘이서 어느 쪽의 자기 만족이 더 높은가를 두고 무의미한 싸움을 계속하는 것에 가깝다고 할 수 있다. 이 얼마나 병신같은 일인가? 게다가 이 문제는 고양이를 설령 데려 와도 제대로 된 얘기를 들을 수 없는(고양이가 어떻게 사람 말을 하겠느냐고) 상황이니, 애초에 고양이, 더 나아가 동물을 “반려자” 삼을 수 있다고 하는 것이 얼마나 우스운 일인지. 애완동물은 가능해도 반려동물은 불가능하다.

덤: 반려동물 논란과는 별개로, 나는 애완동물을 법적으로 금지해야 한다고 생각한다. 아까 말했듯이 인간과 애완동물 사이의 양방향 관계라는 것은 원천적으로 불가능하기 때문에 현재의 상태는 사실은 종이 다르다는 점만 빼면 노예제와 똑같은 상태이다! 인간의 노예제 역사에서도 노예로 사는 것이 자유인으로 사는 것보다 낫다는 이유로 노예로 살아가는 사람이 꽤 있었으니, 동물이 자기가 인간의 애완동물로 살아가는 걸 만족한다고 해서 애완동물을 인정해야 하는 것은 아니다. 다른 대안도 있긴 한데, 그 대안이 뭐냐 하면 애완동물이라는 것이 사실은 동물에 대한 노예제라는 점을 매우 분명하게 인정하는 것이다. 물론 어느 동물 애호가도 자신의 존재 기반을 뒤흔드는 이런 말을 당당하게 할 수 있으리라 생각하진 않는다. 그 잘 나신 자기 만족을 지키고 싶을테니 말이다.

좀 더 수동적인 방법, 즉 야생동물의 활동 영역을 인간의 활동 영역과 명확히 구분하고 꾸준히 관리하는 것이 훨씬 더 윤리적이다. 길고양이에게 최소한의 먹이를 제공하는 것 또한 이런 맥락에서 볼 수 있다. 그리고 이 경우 어디에서도 “애완동물” 내지 “반려동물”이라는 개념이 들어갈 자리는 없다. ↩