Arachneng on Everything

최근 글들을 잠깐 짬을 내어 읽어 보니 내가 주석을 과용하고 있는 게 아닌가 하는 생각이 든다. 주석이라 함은 본디 본 글에 속하지는 않으나 흥미로울 내용을 문맥에서 뜯어 내서...

Thu, 17 May 2012 02:02:15 +0900

최근 글들을 잠깐 짬을 내어 읽어 보니 내가 주석을 과용하고 있는 게 아닌가 하는 생각이 든다. 주석이라 함은 본디 본 글에 속하지는 않으나 흥미로울 내용을 문맥에서 뜯어 내서 본래의 문맥을 훼손하지 않고 새로운 문맥을 주기 위한 장치이다. 그러나 그렇게 뜯어낸 문맥이 본래 문맥보다 더 커지면 문제가 크다. 나의 경우 괄호로 묶을 곁다리 수준의 내용이 두 문장을 넘으면 주석으로 옮기는 현상이 자주 일어나는데, 제대로 하려면 그러한 곁다리 내용을 어떻게 본래 문맥에 녹여낼지를 고민해야 하는 게 맞는 듯 하다. 게으르니까 생각의 흐름을 그냥 흘려 보내는 셈이다. 반성하자.

무시당하는 이념, 보답받지 못하는 노력

Mon, 14 May 2012 14:15:17 +0900

최근 자유 및 오픈 소스 소프트웨어 동네를 여기 저기 둘러 다니면서 느끼는 점이 두 가지 있다. 하나는 GPL은 너무 순진했다는 점이랑, 다른 하나는 노력이 제대로 보답받는 경우는 (언제나 그렇지만) 드물다는 점이다. 그리고 둘 다 공통적으로 드러나는 ~~악의 축~~ 기업이 하나 있다.

너무 순진한 GPL

GPL의 기본적인 아이디어는 “이 소프트웨어를 쓸 때 당신이 갖게 되는 자유를 다른 사람한테도 보장해야 한다”는 것이다. BSD 쪽에서야 그렇게 생각하지 않는 것 같지만, GPL 입장에서는 자기는 자유를 얻었는데 다른 사람한테 그 자유를 보장시키지 않는 경우를 근본부터 차단할 필요가 있음은 당연한 것이다. GPL이 순진했던 점은 그 다음인데, 보통 사람들은 이런 제약을 걸어 놓으면 그 소프트웨어를 쓰지 않고 그 소프트웨어의 대안을 찾아 나선다. 그래서 거의 모든 GNU 소프트웨어는 그것과 거의 비슷한 일을 하는 비-GNU 소프트웨어가 하나씩 달라 붙어 있다. glibc가 그렇고, GCC가 그렇고, GNU Screen이 그러하며, GMP가 그러하지 아니한가!

GCC/LLVM의 경우를 조금 더 자세히 말하면, 나는 개인적으로 정치적인 문제를 제외하면 GCC와 LLVM 모두 좋은 소프트웨어라고 생각한다. GCC는 오랜 기간 유지된 소프트웨어인만큼 연륜이 묻어 나는(다른 말로 하면, 레거시가 쩌는) 코드 베이스가 문제긴 하지만 그 최적화 패스는 절대 무시할 수 없고, LLVM은 GCC만한 연륜은 없지만 코드 베이스가 깔끔하며 다양한 확장이 가능하다는 장점이 있다. 그런데, LLVM의 시작을 잘 살펴 보면 그 뒤에는 GCC에 울며 겨자먹기로 Objective-C 프론트엔드를 집어 넣어야 했던 애플이 버티고 있다. 물론 XNU/Darwin 자체가 BSD 기반이니 GPL을 좋아할 것 같진 않지만, GCC를 개선하는 게 아니라 LLVM을 지원하는 방향으로 가고 있다는 것은 그 의도가 뻔히 보인다. 아니, 솔직히 까고 말하면 GPL을 기만하는 게 아닌가?

물론, SourceForge가 지고 GitHub이 그 자리를 꿰어 찬 걸 보면 확실히 시대가 바뀌긴 했다. 자유 및 오픈 소스 소프트웨어는 그동안 상호 보완적인(전자는 이념적이고, 후자는 개발 모델에 관한) 개념으로 인식되어 왔다. 하지만 요즘 추세를 보면 귀찮고 코드 공유에 도움 안 되는 이념적인 부분을 완전히 제끼고 오픈 소스라는 개념에만 집중하는 느낌이 많이 든다. 하긴 귀찮긴 하다. 당장 나도 요즘 짜는 취미 코드는 대부분 MIT 라이선스거나 아예 퍼블릭 도메인으로 많이 하니까(사실 그 정도로 가치 있는 코드가 없는 게 사실 더 큰 이유다만). 하지만 Zed Shaw가 통렬하게 지적하듯 이념적인 부분을 무시하면 그 코드의 가치는 무시당한다. 결국 이념은 그런 상황을 막기 위해 존재하는 것이다.

보답받지 못 하는 노력

이번에는 둘 다 (L)GPL인 두 소프트웨어를 살펴 보자. 다른 게 아니고 모질라와 웹킷이다. 모질라는 에릭 레이먼드가 오픈 소스 진영의 커다란 승리라고 자뻑을 했을 만큼 역사적인 의미가 크다. 물론 “모든 제품은 죽어서 오픈 소스를 남긴다”라는 웃지 못할 진실의 첫 사례이기도 하지만…. 여하튼, 모질라 재단은 분명히 오픈 소스에서 출발했으나 그 행보는 자유 소프트웨어 진영을 능가하는 이념적인 부분이 더 많다.¹ 모르겠으면 모질라가 프라이버시 보호에 얼마나 많은 노력을 쏟아 붓는지 살펴 보면 바로 이해가 갈 것이다.

한편 웹킷은 본래 KDE 프로젝트에서 자체 브라우저를 만들려고 제작한 KHTML에서 그 유래를 찾을 수 있다. 음… 여기까지는 좋았다. 그런데 아까도 언급되었던 그 문제의 기업, 바로 애플이 자기 브라우저를 만들려고 KHTML을 포킹해서 대규모로 뜯어 고치면서 상황이 달라진다. (애플은 한동안 웹킷을 개발하면서 KHTML한테 주요 패치를 보내지 않은 것으로 원성을 들었다. 지금은 애플 혼자서 웹킷을 개발하는 게 아니라서 상황이 달라졌지만.) 이 와중에 구글도 자기 브라우저를 만들기 위해서 웹킷을 또 포킹을 하는 상황이 되면서 졸지에 모질라는 거대 기업 두 개가 뒷받침하고 있는 브라우저랑 경쟁해야 하는 안습한 상황에 처하고 만다.

그 다음은 다들 알고 있는 바이다. 최근 구글 크롬은 전 세계 브라우저 시장에서 인터넷 익스플로러를 거의 다 따라잡고 다른 브라우저의 사용률도 크게 떨어뜨리면서 선전하고 있다(파이어폭스가 이 와중에 피를 많이 봤다). 더군다나 모바일 브라우저에서는 아예 선택의 여지도 없이 사실상 모든 것이 웹킷이다. 상황이 이렇게 되다 보니까 구글 크롬이 새로운 IE가 되는 게 아니냐는 얘기까지 나오는 판이고(구글 크롬을 웹킷으로 바꿔도 논지에는 별 차이가 없다), CSS의 경우 -webkit- 접두사가 표준처럼 받아들여지는 끔찍한 상황도 일어나고 있다.² 물론 이런 상황이 꼭 웹킷 팀 및 구글 크롬 쪽의 책임이라고 할 수는 없지만, 적극적으로 웹 개발자들을 교육시켜서 다른 브라우저도 신경쓰게 만들려는 움직임도 보이지 않는 건 우려스럽다. 반면 모질라는 새 기능이 나와도 개발자 사이트에 웬만한 주요 브라우저 호환성에 대해 서술하고, 크로스 브라우저 개발을 위한 튜토리얼도 많이 갖춰 놓았다.

그래서 어쩌라고

뭐 뻔하지 않겠는가? 아무리 이념이 귀찮더라도 이념을 무시하지는 말고, 아무리 쓰기 편하다 하더라도 노력을 무시하지는 말자고. 그 이념과 노력이 이 세상을 어떻게 바꿔 왔는지 알고 있는 사람이라면 쉽게 그 이념과 노력을 무시할 수는 없을 것이다. 비록 현실은 시궁창일지라도.

물론 실용적인 부분도 많이 고려되는 게 사실이긴 하다. APNG와 관련해서 PNG 그룹과 마찰을 빚은 사례를 예로 들 수 있는데, PNG 그룹은 APNG가 PNG와는 달리 실질적으로 영상 포맷이기 때문에 별도의 미디어 타입을 받아야 한다고 주장했던 반면, 모질라는 그렇게 했다가는 하위 호환성이라는 원래의 목표가 사라지는데 왜 그렇게 해야 하냐는 실용적인 접근을 취했다. 결국 모질라는 PNG 그룹을 무시하고 APNG 스펙을 그대로 구현했다. 개인적으로는 PNG 그룹이 MNG의 실패에서 도대체 뭘 배운 건지 의심스럽기만 하다. ↩
웹킷이 구현하면 심지어 그게 HTML5에 들어 가지 않더라도 상당한 수의 사용자한테 먹히기 때문에 그렇게 된다. 그런데 현실적으로 말하자면 -webkit- 접두사는 실험적인 기능을 위해 사용하는 것인지라 웹킷 개발팀 마음대로 바뀌는 경우도 비일비재하다. 대표적인 예로 그라디언트가 있는데, 대부분의 CSS3 그라디언트 생성기가 뱉어 내는 걸 보면 다른 브라우저 벤더 별로 한 줄씩 있는 반면 웹킷은 두 줄(-webkit-linear-gradient와 -webkit-gradient)이 있는 것을 볼 수 있다…. ↩

리듬게임 인생 (3)

Mon, 30 Apr 2012 10:01:43 +0900

첫번째 글, 두번째 글에서 이어진다. 거의 1년동안 방치되어 있던 초안을 더 이상 이대로 방치해 둘 수 없다는 까닭으로(…좀 더 정확히는 저널을 지나치게 방치했다 싶어서) 써 놓은 부분까지 정리하고 올리기로 했다. ~~그러니까 원래 이번에 들어 가야 했을 이지투디제이는 다음 기회에~~

팝픈뮤직

코나미의 리듬게임 개발 역사는 크게 세 개로 나눌 수 있는데, 리듬게임이라는 장르 자체를 확립한 시기(1997~2002), 이어뮤즈먼트 서비스가 등장하며 플레이어별 서비스가 가능해진 시기(2002~2008), 그리고 인터넷과의 강력한 연계가 이루어진 시기(2008~현재)로 나눌 수 있다. 당연히 1997년에 처음 발매된 비트매니아와 1998년에 발매된 댄스 댄스 레볼루션은 첫 시기에 속하는데, 여기에 속하는 또 다른 게임이 있다는 건 리듬게임을 어지간히 하지 않으면 모르는 경우가 많다. 그도 그럴 것이 팝픈뮤직(1998년 발매)은 한국에서 정말 찾아 보기 힘든 리듬게임 중 하나이기 때문이다.

나는 팝픈뮤직을 2006년 경에 학교 근처에 있던 오락실에서 지인의 소개로 처음 접했다. 한국의 팝픈뮤직 발매 역사는 정말 이상해서, 2012년 현재 최신 버전이 20인데 지금껏 정발된 버전이 1과 8밖에 없다.¹ 그나마 팝픈뮤직 1은 지금의 팝픈뮤직에 비교하면 매우 어중간한 작품이기 때문에 제대로 즐기려면 8을 해야 했는데, 다행인지 불행인지 그 오락실에서는 그제껏 8을 돌리고 있었다. 그 때 나온 최신 버전의 곡을 즐길 수 없다는 건 불행이었지만, 팝픈뮤직의 주요 버전을 얼추 다 접할 수 있어서 버전 사이의 오묘한 차이들에 익숙하다는 건 다행이라고 할 수는 있겠다. (이런 차이가 한 둘이 아닌데, 대표적인 예로 배속을 0.5 단위로 변경 가능하게 된 게 15부터이다.) 그 오락실이 망한 뒤에는 대전역 근처에 있는 오락실(14를 돌리다가 나중에 15로 바꿨다)에 갔고, 서울에서 일하는 동안에는 광명시에 있던 오락실(15)에 갔으며, 그 뒤에는 딱히 가까운 오락실이 없어서 그냥 어쩌다가 있는 오락실에 갈 일이 생기면 한 두 번쯤 해 보는 수준이 되었다.

팝픈뮤직 8을 처음 접한 것은 한 가지 장점이 더 있었는데, 여기에서 추가된 곡의 대부분이 “적절히” 어렵지 “미친듯이” 어려운 경우는 별로 없었다는 것이었다. 레벨²이 40을 넘는 곡이 심심하면 추가되는 지금의 팝픈뮤직과는 달리 8에서 추가된 40을 넘는 곡은 딱 두 개였고, 이 둘을 빼면 나머지는 한 번 시도는 해 볼만한 느낌이 드는 곡들이었기 때문이다. 나 같은 경우 8에서 가장 좋아했던 곡은 단연 100sec. Kitchen Battle!!일텐데, 이 곡은 (지금도) EX가 없고 HYPER(레벨 36)밖에 없기 때문에 한동안은 이 곡을 깨는 것이 목표가 되었다. 만약 내가 최근작(이를테면, 18이라고 해 보자)으로 팝픈뮤직을 시작했다면 이러한 단계적인 목표를 세울 수가 없었을 거라고 생각한다. 그 뒤 팝픈뮤직 14를 접하면서 새 목표는 BAROQUE HOEDOWN(EX 40)이 되었고, 자연스럽게 클리어 가능한 곡의 범위가 레벨 40 근방으로 올라가게 되었다. 이 범위는 지금도 크게 바뀌지는 않아서, 레벨 40은 어떤 건 깨고 어떤 건 못 깬다. 아주 최근에야 41을 조금 깰 수 있게 되었다.

팝픈뮤직이 다른 리듬게임과 가장 크게 다른 점을 든다면 역시 커다란 버튼일 것이다. 혹자는 이게 비시바시 챔프에서 남은 버튼을 쓴 거 아니냐는 농담도 하긴 하는데³ 실제로 해 보면 누르는 감촉이 조금 다르다. 아마도 사람들이 다 세게 눌러서 고장나기 쉽기 때문에 내구도를 높이려고 뭔가 조정을 한 것 같은데, 여기에서 볼 수 있듯이 팝픈뮤직은 플레이를 하다 보면 싫어도 어쨌든 기계를 부수게 되는 흔치 않은 리듬게임이다. 그리고 나 같은 경우에는 기계 말고도 손도 부수게 되었다(…). 한 번은 열심히 플레이를 하고 나니까 중지 마디의 피부가 벗겨져서(!) 매우 쓰라렸는데, 아직 남은 판이 있어서 휴지로 응급처치를 하고 마저 플레이한 뒤에 반창고를 붙였던 일이 있었을 정도였다. (이런 일이 몇 번 있고 나서는 항상 반창고를 들고 다니게 되었다.) 다른 사람은 안 그러는 걸로 봐서는 아무래도 내 손배치에 심각한 문제가 있는 것이 확실한데, 손배치를 바꾸기에는 더 이상 팝픈뮤직을 맘놓고 할 시간은 많지 않은 것 같다.

이렇게 한 때는 열심히 팝픈뮤직을 즐겼던 나라고 해도 팝픈뮤직에 할 말이 없는 건 아니다. 특히 이건 아마 많은 사람들이 공감하지 않을까 싶은데, (특히 고난이도) 곡들의 레벨을 현실화할 필요가 있다. 당장 레벨 43 곡들 중에도 윗물과 아랫물이 있다는 것은 잘 알려진 사실이고 (그 사이에 넘을 수 없는 4차원의 벽이 있다는 것도…) 43까지 가지 않아도 40에서도 나눌 것들이 꽤 있는 판이다. 현재의 레벨 시스템이 이 모양 이 꼴이 된 것은 플레이어들의 요구를 따르기 위해 꾸준히 고난이도 곡들이 추가되었지만 최고 레벨을 그에 비례하도록 늘릴 생각은 안 하고 있는 레벨 시스템에 끼워 맞추다 보니 밀도가 높아진 것인데, 비록 버전이 올라가면서 계속 재조정이 되고 있다고는 해도 40~43 사이의 곡들을 4개의 단계만으로 구분하는 데는 굉장히 무리가 따른다고 본다.

유비트

유비트는 여러 가지로 언급할 가치가 많은 게임인데, 코나미 리듬게임 역사의 세 시기 중 마지막 시기를 화려하게 연 게임이자 한국에서 모든 주요 버전이 꾸준히 정발되고 있는 유이한 비매니 시리즈(리플렉 비트가 나오면서 이 기록을 깼다)라는 점이 바로 그것이다. 실은 처음에 유비트가 한국에서 필드 테스트를 한다는 얘기를 듣고 가서 해 본 뒤에도 이게 실제로 출시될 거라는 생각은 전혀 하지 않았기 때문에 크게 기대하지 않고 있었다. 학교 근처 오락실에 유비트가 들어 오기 전까지는.

뭐 아무튼, 나는 유비트를 초기작부터 계속 해 왔다(물론 앞에서 말했듯 초기작이 정발되자 마자 시작한 건 아니다). 유비트는 일본에서는 2008년 7월에 나왔지만 한국에서는 12월에 정발되었는데, 내가 실제로 플레이를 시작한 2009년 6월에는 이미 유비트가 전국 오락실에 상당히 분포되어 있던 터라 팝픈뮤직과 같이 오락실이 사라지면 게임을 못 하게 되는(…) 불상사는 다행히도 일어나지 않았다. 다만 나 같은 경우 초기작을 다음 버전(리플즈)이 나오기 두 달 전부터 했기 때문에, 초기작에서 겪을 수 있는 여러 가지 애매한 상황들을 겪지는 않고 바로 리플즈로 넘어 갔기 때문에 초기작부터 했다고 말하기가 살짝 애매하긴 하다.⁴

유비트는 다른 비매니 시리즈에 비해서 난이도가 상당히 낮은 편이다. 이건 코나미 리듬게임 역사에서 마지막 시기에 처음으로 출시된 게임군에서 공통으로 나타나는 현상인데, 처음 접하는 사람들을 최대한 오랫동안 하게 만드는 게, 즉 대중적으로 만드는 게 게임의 성공에 도움이 된다는 어찌 보면 당연한 진리를 공격적으로 적용하고 있는 것 같다. 물론 기존의 플레이어들을 무시할 수는 없기 때문에 최상위 난이도는 여전히 존재하기는 하는데, 최상위 난이도라고 해서 클리어가 불가능하거나 한 수준까지 가지는 않는다. 당장 팝픈뮤직을 하는 사람한테 사일런트(EX 레벨 43, 실제 제목은 그냥 “음악”이지만 보통 이 제목으로 잘 알려져 있음)를 시켰을 때 깰 확률과 유비트 하는 사람한테 에반스(EXTREME 레벨 10)를 시켰을 때 깰 확률이 얼마나 차이가 나는지 생각해 보면 이해가 빠를 것이다.⁵ 이게 좋은 것인지 나쁜 것인지는 아직도 논쟁이 많지만, 나는 우선 신규 플레이어의 유입이라는 면에서는 매우 긍정적으로 평가한다.

뭐, 꼭 좋은 것만은 아닌게, 예전에 유비트 니트의 난이도 체계가 슬슬 이상해지고 있다는 소리를 한 적이 있다. 이 점은 다음 작인 유비트 코피어스에도 비슷하게 이어져서 레벨 8과 9는 슬슬 둘로 나눠야 하는 거 아니냐는 얘기가 나올 수준이 되었다(투덱의 12레벨 체계?!). 여기에는 유비트의 너무 낮은 난이도도 한 몫을 하는데, 난이도가 너무 낮으니 BASIC이나 (yellow head joe 같은 극히 일부의 예외를 제외하면) 대부분의 ADVANCED는 찬밥 신세고 EXTREME을 많이 하게 되지만 EXTREME에 넣을 수 있는 패턴의 난이도가 고르게 분포해 있을 리가 없다. 레벨 8과 9는 다른 게 아니라 EXTREME의 평균 난이도이기 때문에 그런 현상이 특히 심하게 나타난다.⁶ 전곡 순회와 저렙곡 엑설런트를 권장하는 달성 과제 시스템은 이런 점을 보완하려 한 흔적임이 확실하지만, 과연 그게 얼마나 어필했는가는 의문이 든다.

분석은 이 쯤 하고 개인적인 얘기를 하자면, 결과적으로 유비트는 내가 하는 아케이드 게임 중에서 가장 오랫동안 가장 많은 돈(1년에 20만원 쯤?)을 갖다 바치는 ~~돈 먹는 하마~~ 게임이 되었다. 전혀 S를 못 찍을 것만 같았던 에반스조차도 이제 S가 두렵지 않은 수준이 되었고⁷, 어쩌다 한 번 삘 받을 때 하는 엑설런트 곡 수도 70개를 넘었고, 웬만한 곡은 이제 SS를 못 찍으면 뭔가 심신이 굉장히 피곤함을 나타내는 바로미터로 쓸 수 있을 정도가 되었다. 내가 오락실에 어쨌든 계속 가게 만드는 큰 동인이기도 하니 이쯤 되면 이 시리즈 전체의 맥락인 리듬게임 “인생”을 대표하기에 손색이 없는 게임일 것 같다. 물론, 앞으로도 할 얘기는 많다.

차회 예고

왠지 내년에 올라올 낌새가 만만치 않지만 아무튼 다음 글을 쓴다면 이지투디제이와 비트매니아 IIDX를 다루게 될 것이다. 그나저나 그 뒤에도 글을 대략 네 개 정도 더 써야 할텐데 남은 글들의 얼개를 어떻게 짜야 할지 벌써부터 걱정이다. ~~4편부터 쓴 뒤에 걱정해라~~

이 글의 초안을 쓰기 시작한 이래 이 문장에는 매우 중요한 뒷얘기가 따라 붙게 되었다. 그동안 일본에서 팝픈뮤직을 비롯한 비매니 게임들을 암암리에 직수입해 왔던 조이플라자가 2012년 2월에 문을 닫았고(따라서 기존 시리즈의 차기작들은 한국에 못 들어 올 가능성도 있다), 한 술 더 떠서 4월에는 본래대로라면 한참 뒤에 해금되어야 할 팝픈뮤직 20의 게임 요소(PHASE MAX)가 한국에서 몇 달 먼저 해금되는 사태가 벌어진다. 다행(?)히도 일본에서도 그 뒤 1주 안에 해금 커맨드가 뚫리면서(…) 상위 플레이어들의 의욕을 심하게 꺾게 되는데, 여하튼 이런 일련의 사건을 보면 알 수 있듯 한국 내의 비매니 게임 시장은 매우 심각하게 왜곡되어 있다. 가장 좋은 방법은 어떤 형태로든 정식 발매 창구를 찾는 것이겠으나—-홍콩을 예로 들면, 홍콩 내에 있는 비트매니아 IIDX의 숫자가 10대 남짓 함에도 불구하고 어쨌든 정식으로 발매가 되어 이어뮤즈먼트까지 쓸 수 있다—-, 과연 그런 일을 할 수 있을 업체가 국내에 존재하는지는 의문이 든다. ↩
팝픈뮤직 레벨은 1부터 43까지 존재하는데, 1부터 39까지는 난이도와 대략 선형적으로 비례하고, 40은 39보다 두 배 정도 어려우며, 41은 40보다 서너배, 42와 43은 41보다 열 배 이상 어렵다(42와 43 사이의 난이도 차이는 개인차가 너무 심해서 수치로 표현할 수가 없다). 팝픈뮤직에서 최고 난이도의 곡은 비매니 시리즈 전체에서 가장 어려운 곡에 속하는데, 같은 비매니 시리즈인 유비트랑 비교하면 대략 유비트 레벨 10이 팝픈뮤직 레벨 39~40에 대응한다고 봐야 할 것이다. ↩
비시바시 챔프에도 버튼은 9개(플레이어 세 명 당 세 개씩) 있고, 한 줄로 배치된 것만 빼면 외관상으로는 매우 비슷하다. 하지만 비시바시 버튼은 빨강·초록·파랑 세 종류밖에 없는 반면 팝픈뮤직은 다섯 종류의 색깔이 필요하고, 비교적 나중에 정발된 후속작인 더 비시바시에서는 9개의 버튼 말고도 플레이어 별로 작은 노란 버튼이 생겼기 때문에 많이 멀어진 게 사실이다. ↩
유비트 초기작에서 플레이어 레벨의 최상위 단계는 SS였고 그 아래는 S4였다. 그런데 나는 S4를 찍기는 했지만 SS의 요구 조건, 엑설런트(100% 완벽한 플레이) 1곡 이상을 본 순간 이건 무리라고 생각하고 생각하기를 그만 두었다. (다른 요구 조건으로는 EXTREME 평균 95만점 이상… 같은 게 있었는데 당시에는 92만점이긴 했지만 계속 꾸준히 했다면 어렵지 않게 가능했으리라 본다.) 유비트에서 엑설런트가 그렇게 하기 어려운 것이 아니라는 건 나중에 리플즈가 나온 뒤 BASIC부터 꾸준히 플레이를 하면서야 알게 되었다. ↩
내 최선의 예측으로는 전자는 0.1% 이하, 후자는 20% 정도이다. 전자는 일본에서 레벨 43 전곡 클리어자가 사일런트를 뺀 전곡 클리어자의 1/3 정도라는 통계에서 나왔고, 후자는 JubeatInfo 랭크 통계에서 추측한 것이다. ↩
이건 신규 유입자 입장에서도 피곤한게, 처음 하는 사람은 보통 어느 정도 하면 7~8에서 정착하게 되는데 여기 속하는 곡들의 레벨 산정이 찍기라면 플레이를 할 맛이 안 날 것이다. 참고로 앞에서 레벨 8 얘기는 했지만 7은 안 했는데, 7은 산정 방법이 이상한 건 아니지만 지뢰곡들이 몇 개 깔려 있는 걸로 잘 알려져 있다…. ↩
저 글 쓴 뒤에 몇 번 더 갱신해서 지금은 91만점을 조금 넘긴다. 아, 물론 아직 에어레이드는 못 한다. 이 글 쓰는 시점에서 아직도 S를 못 찍은 단 하나의 곡이다. orz ↩

회사에서 Redis 클라이언트를 써서 뭔가를 해야 할 일이 있었는데, 프로토콜이라고 할 것도 없는 것에 따로 라이브러리까지 필요한가 싶어서1 그냥 점심 시간 즈음에 짧게 구현해...

Wed, 07 Mar 2012 13:29:26 +0900

회사에서 Redis 클라이언트를 써서 뭔가를 해야 할 일이 있었는데, 프로토콜이라고 할 것도 없는 것에 따로 라이브러리까지 필요한가 싶어서¹ 그냥 점심 시간 즈음에 짧게 구현해 보았다. 파이썬으로 에러 체크까지 포함해서 50줄. 매우 만족스럽다.

사실 깔려 있긴 한데 virtualenv 안쪽이라서 enable하기 귀찮았다. ↩

뭔가를 배우는 가장 좋은 방법은 그걸 절실하게 필요로 할 상황을 만드는 것이다. 그럼 자기가 원하지 않아도 자동으로 그걸 배우게 될 것이다. 한 가지 단점은 그렇게 한다고 그...

Thu, 01 Mar 2012 23:27:59 +0900

뭔가를 배우는 가장 좋은 방법은 그걸 절실하게 필요로 할 상황을 만드는 것이다. 그럼 자기가 원하지 않아도 자동으로 그걸 배우게 될 것이다. 한 가지 단점은 그렇게 한다고 그 상황이 해결된다는 보장은 없다는 것.

최근 열흘 정도 동안 짬짬이 파이썬, PHP, Sikuli, Swing, Mechanize, SQLite, qmail(??), 그리고 크로뮴(???????)이 섞여 있는 기괴한 프로그램을 아는 사람들과 함께 짜다가 돌발 변수로 프로젝트가 반쯤 접혔는데, 덕분에 Sikuli와 qmail 소스는 정말 거하게 봤으나 프로젝트가 접히는 걸 막을 수는 없었다. 그래서 생각난 얘기.

이틀 전 외출 후 돌아가는 길에 지하철 플랫폼에서 촬영. 아무리 우측 통행을 그렇게 강조하고 싶었어도 이건 너무...

Tue, 28 Feb 2012 09:57:37 +0900

이틀 전 외출 후 돌아가는 길에 지하철 플랫폼에서 촬영. 아무리 우측 통행을 그렇게 강조하고 싶었어도 이건 너무 무리수를 뒀다. 뭔 말인지 모르시겠다면 저걸 180도 회전한 뒤에 당신이 우측 통행을 하고 있는 경우를 상상해 보라.

이 그림을 올리고 바로 “그래도 우측 통행을 하면 건너는 시간차가 있기 때문에 더 안전하다”는 지적을 받았다. 음, 하긴 횡단보도 등이 켜져 있는데도 무작정 전진을 하려는 차량이 없다면 그게 옳은 말이다(아마도 20%라는 통계는 그것에서 나온 게 아닐까). 근데 2차로 정도로 좁은 길에서 흔히 그러듯이 횡단보도 무시하고 진행하는 차량이 있으면 다 필요 없고 대각선으로 건너는 게 가장 안전한 듯….

망할 놈의 집 (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를 쓴다는 것은 자기 뿐만 아니라 남들까지 위험에 빠뜨리겠다는 생각이라고밖에 할 수 없다.

2012년 3월 28일 덧붙임: 문제의 공격자는 결국 경찰에 붙잡혔다. 17세 네덜란드 소년이라고.

나는 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 <stdio.h>

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

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

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

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