메아리강 성훈13년차 개인 홈페이지입니다. 보통은 소프트웨어를 만듭니다. 도 꽤 쓰고 위키 비스무리한 것도 만듭니다. 바깥에서는 트위터깃허브도 합니다. (모든 페이지 보기)



메아리 새 버전을 만들었다. 뭐 그렇다고.

현재 남아 있는 문제:


표준 라이브러리가 할 수 있는 것과 없는 것

엊저녁에 이런 트윗을 봤다.

@kwangyulseo:

루비의 String 타입이 인코딩을 가변으로 지정할 수 있는 게 장점이라고 말씀하신 분도 있는데, 난 아무리 봐도 이건 장점은 커녕 심각한 API 설계 실수에 가깝다고 생각한다. 비슷한 생각의 글 https://raw.githubusercontent.com/candlerb/string19/47b0cba0a2047eca0612b4e24a540f011cf2cac3/soapbox.rb

유니코드가 지원하지 않는 특수한 인코딩이 필요하면 그걸 위한 타입을 정의하면 될 일이지, 모든 String 타입의 인코딩을 가변으로 만들 일이 아니라고 생각한다.

이게 무슨 얘기인가 살펴 봤더니, 꽤 격한 토론이 있었던 모양이다. 특히 강한 장점으로 제시한 근거는 다음과 같다.

@daesanhwang:

미국 친구들은 대체로 (서양은 원래 문자가 몇 개 없으니) 유니코드면 충분하니 유니코드 방식으로 문자열을 구현하자고 당시 주장하던 편이고, 마츠는 시간이 걸리더라도 모든 인코딩을 지원하는 방식으로 하겠다고 했었습니다.

저는 당시에 양쪽 입장 모두 어느 정도 일리가 있다고 생각했습니다만, 이후에 확장 완성형 등으로 된 legacy 한국 텍스트 데이터들을 처리하는 과정에서 문자열이 여러 인코딩을 지원하는게 얼마나 편리한지 경험하게 돼서 입장이 이렇게 정리됐지요.

예전에 유니코드 지원에 따른 프로그래밍 언어의 분류라는 글을 쓴 적이 있기 때문에 루비의 상당히 특이한 선택은 익히 알고 있었다. 다만 그게 호환성적인 측면(옛날 루비에는 $KCODE라는 것도 있었지 아마…) 때문에 불가피한 선택인 줄 알았지, 마츠가 의도적으로 설계한 것이라고는 꿈도 꾸지 못 했다.

사실 이건 확장성과 편의성 사이에서 얼마나 줄을 타느냐의 문제에 가까워서 정답이 명백하게 나오는 경우가 드물다. 유니코드가 사실상 모든 레거시 문자 집합을 쌈싸먹는 유일한 문자 집합으로 거듭난 상태에서는 그게 정답 아니냐는 지적이 가능하긴 하지만, 위에 언급된 대로 레거시를 정말로 다뤄야 할 경우에는 (그리고, 레거시는 바꿀 수 없는데도 써야 하니까 레거시이므로) 문제가 커진다. 한 가지 예를 들면 윈도 API에서 wchar_t 배열로 표현되는 문자열들은 한동안 UTF-16이 아니라 UCS-2, 즉 surrogate pair를 포함할 수 있었다. (지금은 아니지만…) 유닉스에서도 파일 이름 같은 거의 인코딩은 파일 시스템 설정에 따르는데, 당연히 경로는 문자열로 표현할 수 있겠지라는 생각을 하던 사람들을 가끔씩 놀라게 만드는 원인이 된다. 이걸 피하려면 경로를 문자열과 완전 다른 타입으로 만들거나, 경로를 고정된 인코딩으로 번역하되 왕복 변환(round trip)이 가능하도록 이상한 짓[1]을 해야 한다. 이런 레거시와의 접점이 많을 수록 그냥 문자열 자체가 인코딩을 들고 있는 게 맞지 않느냐는 생각을 하게 되는 건 어쩔 수 없다.

그래서 나는 문제 제기 자체에는 환영한다. 그러나 나는 옛날부터 (실은, 저 글을 썼을 시점부터) 지금까지 줄곧 인코딩을 넣는 것은 정말로 불가피한 이유가 아니면 나쁜 설계라고 생각해 왔는데, 이건 위의 불편함이 실은 존재하지 않거나 미미한 문제라고 주장함이 아니라, 좀 더 근본적으로 이런 설계를 표준 라이브러리에서 지양해야 할 이유가 있기 때문이다.


1

파이썬이 대표적으로, 파이썬 문자열은 UCS-2/4이므로 surrogate pair를 포함할 수 있다. 따라서 기본 인코딩(보통 UTF-8)을 쓰되 디코딩에 실패한 바이트를 surrogate pair로 우겨 넣어서(…) 문자열로 만든다. (PEP 383) 일반적인 인코딩 모드에서는 이 왕복 변환이 꺼져 있기 때문에 오류 처리되므로 아주 큰 문제는 되지 않지만, 경로를 출력하다가 변환 오류가 날 수 있다는 사실을 많은 사람이 인식하고 있을지는 모르겠다.


알파고이세돌을 상대로 2승을 따냈다. 바(둑)알(지)못(하는 사람)인 나조차 중계 방송을 지켜 봤을 정도인데, 아마도 앞으로는 더 이상 실시간으로 중계 방송을 보지 않을 것이다. 일단 업무시간에 집중을 할 수 없고(…) 안타깝긴 해도 이세돌이 처참하게 박살나는 이 상황이 근시일 내에 올 것은 명백했기 때문이다. 앞으로의 대국은, 딥마인드 측이 밝힌 의도마냥, 알파고가 이세돌과 비교했을 때 얼마나 더 잘 두는가의 범위를 추정하는 작업이 될 것이다.[1] 이 자리를 빌어 이세돌에게 심심한 위로를.[2]

알파고가 다른 모든 이슈를 날려버리고 뉴스 헤드라인에 떡하니 박혀 있는 건 좋은 일이라고 생각하지만(이런 일이 흔치 않으니까), 예상했듯 이게 도대체 무슨 의미를 가지는가에 대해서 제대로 짚고 있는 사람은 많지 않다. 그러하니 이게 나한테 무슨 의미를 지니는지 코멘트해 보겠다. 아마 다른 사람들은 다르게 생각하겠지만 이 생각이 다른 사람들에게 영향을 준다면 기쁠 것이다.


1

많이 안 쓰는 것 같지만, 바둑에서도 Elo 레이팅을 적용한 자료가 있다(정확히는 Elo와는 달리 업데이트 모델이 다르지만 수치의 상관은 동일하다). 이에 따르면 이세돌의 3월 11일 현재 레이팅은 3525. 만약 최적 컨디션의 이세돌과 알파고를 계속 맞붙였을 때 평균 승률이 20%:80%면 알파고의 레이팅은 240 높은 3760이어야 하고, 이 숫자는 지금껏 지구상의 어떤 바둑 기사도 근접한 적이 없는 수치이다. 비교를 위해, 이미 컴퓨터가 인간을 갖고 노는 체스에서 최강의 소프트웨어역사상 최강의 인간 플레이어 사이의 레이팅 차이는 400 안팎으로 추정된다(물론 더 이상 인간-컴퓨터가 공식적으로 맞붙는 일은 없으므로 어디까지나 추정).

2

(이 글을 쓰고 이틀 뒤 이세돌이 4국에서 알파고를 이겼다. 이는 알파고의 방법론이 얼마나 인간의 방법론과 유사한지를 보여 주는, 그리고 당연하게도 알파고가 바둑을 완벽하게 풀어 버리는 알고리즘은 아님을 다시금 확인해 주었다고 본다. 이세돌에게나 구글 딥마인드 측에나 다행인 결과가 아닐 수 없다.)


Crystal Society

독후감을 써야겠다고 느낄 정도로 많은 생각을 하게 된 소설은 별로 없는데, 최근에 모 SF 덕후 아저씨서상현 님의 추천으로 SF를 하나 읽었다. 소설 하나를 일주일 내내 (순수 소요 시간만 20시간) 붙잡고 읽게 될 줄은 몰랐는데, 이 아저씨가 왜 그렇게 극찬을 했는지 알 수준으로는 읽었다. 모든 사람이 좋아할 것 같진 않지만. 그래서 혹시나 관심이 있는 사람에게 영업… 아니, 추천을 할 겸 저널을 덜 망한 것처럼 보이게 하기 위해서 독후감 비스무리한 걸 써 보기로 했다.

Crystal Society는 근미래, 그러니까 2039년의 지구를 배경으로 하는 SF이다. 저 아저씨의 표현에 따르면, 무려 인간과 외계인과 인공지능이 나오는 과학 소설. 이 표현이 딱히 틀리지 않은게 정말로 저 셋이 함께 나오는 수준이 아니라 서로 부대끼는 세계관이고, 보통 소설에서 기대하는 기승전결의 구조가 전체 줄거리에서는 보이지 않는, 그러니까 다분히 옴니버스적인 (그러나 각 줄거리 사이에는 강한 접점이 있는) 소설이기 때문이다. 작가도 이 점을 깨달았는지, 저 소설은 3부작의 첫 소설이다(2016/2017년에 다음 소설들을 발표하겠다고 했다). 더럽게 긴(PDF판이 750쪽!) 소설이 더 길어질 예정이다(…).

스포일러를 최대한 배제하고 개요만 쓰면, 이 이야기의 화자는 인공지능이다. 소설의 첫 장이 바로 이 인공지능이 어떻게 태어나고 어떻게 세계를 인식하는지를 그 인공지능의 관점에서 서술하고 있는데, 아무리 영어라 해도 사전지식이 없으면 한 번 쓱 읽어서는 도저히 이해할 수 없다. 그러나 한 번 이 인공지능이 어떻게 사고하는지 알게 되면 왜 저런 서술이 되었는지 이해를 하게 되고, 그 뒤에 이 인공지능이 어떻게 이런 저런 사건들을 헤쳐 나가는지를 납득할 수 있게 된다. 그 전까지는 머리를 부여 잡으면서 이게 무슨 귀신 씨나락 까먹는 소리인지 고민을 해 봐야 한다. (이것 때문에 소설을 읽기 어렵겠다고 생각하는 분들을 위해 “약한” 스포일러에 여기에 대한 얘기를 써 놓았다.)

이 소설은 하드 SF이다. 하드 SF에서 요구하는 과학적 개연성과 더불어, 세계관의 복잡도에서 유래하는 엄청난 양의 뒷배경을 납득이 가는 방법으로 소설 전반에서 이리 저리 묘사하는 것 또한 흥미롭다(여기에는 화자가 인공지능이라는 요소도 한 몫 한다). 그러나 무엇보다 흥미로운 것은, 이 배경 하에서 인공지능이 “어떻게” 인간 사회(와 기타 등등)를 인식하고 사고하는지 또한 적나라하게 드러난다는 것이다. 그런 점에서 이 소설은 인간과 외계인과 인공지능에 대한 얘기긴 하지만, 사실 SF적 요소를 완전 빼 놓고 평가하면 인간 사회에 대한 작가의 관측을 우화적인 방법으로 표현했다고 하는 게 더 정확한 표현일지 모르겠다. 소설에서 인공지능은 꾸준히 인간 사회의 복잡도에 경탄하면서도 그것이 얼마나 “이상한지”를 구체적으로 서술하는데, 이는 합리주의자들의 전형적인 레퍼토리이기도 하다. 하지만 그럼에도 불구하고 인공지능은 그 사회에서 살아 남기 위하여, 그리고 “목적”[1]을 위하여 최선을 다하여 인간 사회에 적응한다. 소설을 읽으면서 작중 등장인물/지능의 행동에 뒷통수를 치면서 아놔! 하고 소리를 치고 나면, 이런 일련의 장치들이 얼마나 흥미로운지를 몸으로 체험할 수 있다.

난 이 소설을 모든 사람에게 추천하진 않는다. 여러 가지가 있는데, 일단 영어라는 언어의 장벽이 하나이고(그리고 나는 이걸 한국어로 번역하면 어디서 문제가 생길지 단박에 보인다), 전공 세부를 알 필요는 없지만 과학적인 상식이 어느 정도 있어야 무슨 일이 벌어지는지 알 수 있는 게 하나이며, 무엇보다 미래의 (가상의) 인간 사회를 적나라하게 묘사하고 있는데 이것이 사람에 따라서는 상당한 부담을 줄 수도 있기 때문이다. 나는 상대적으로 관대한 편이라서 내 가치관과 전혀 동떨어진 작품이라도 (내 가치관과 다르다는 걸 명시적으로 인식하면서) 잘만 읽는 편인데[2], 대다수의 사람은 그렇지 않기 때문이다. 시작부에 이런 요소들이 뭐가 있는지 간략하게 써 놓은 게 있으니 혹시나 불편할 것 같다면 미리 보고 시작하면 좋다. 하지만 이 모든 것들을 감수한다면 상당히 재밌는 SF로 완성되었다고 생각한다.

여기서부터는 스포일러니까 가려 두기로. 아, 설마 링크를 안 눌러 보신 분들을 위해서, 이 소설은 공짜입니다. 링크 타고 가서 바로 읽을 수 있어요.


1

소설에서 이탤릭으로 The Purpose라고 나오는 것. 이게 뭔지는 스포일러는 아니긴 한데 미리 밝히면 재미가 없다.

2

바로 그렇기 때문에 내가 이 소설을 재밌게 읽었다는 것이다. 예를 들어서 이 소설에는 (하드 SF에선 드문 일도 아니지만) 합리주의와 초인류주의의 영향이 강하게 보임에도 불구하고 나는 합리주의자도 초인류주의자(transhumanist)도 아니다. 심지어 나는 초인류주의의 경우 강한 비관론을 가지고 있다. 단지, 그것들이 어떻게 생겨났으며 무엇을 주장하는지는 그걸 믿고 자시고를 떠나서 충분히 이해할 필요가 있다고 생각할 뿐.


Unison

앙골모아에 보면 좀 희한하게 생긴 글꼴이 하나 있다. 원래는 (완벽하게 내가 다 그린 건 아니지만 실질적으로 내가 조정을 가해서 내가 그린 거나 마찬가지인) 비트맵 글꼴인 것에다가 반자동 보간을 넣어서 확대해도 말끔하게 보이게 한 것인데, 음… 어쩌다가 보니까 여기까지 왔는지. 그래서 소개합니다. “나름” 유니코드 글꼴을 지향하는 Unison 글꼴입니다.

…시작할 때는 이 정도로 커질 거라고 생각을 안 했는데 정신을 차려 보니 꽤 많이 그려 놓았다. 참고로 글자를 어떻게 그리냐 하면 이렇게 그린다. 이런 걸 1천개 정도 그렸다. (물론 유니코드 BMP만이라도 커버하려면 5만개 정도 더 그려야 한다.)

glyph sz-lower
........
........
........
./@@@@\.
.@@..@@.
.@@..@@.
.@@.d@/.
.@@.9@\.
.@@..9@\
.@@...@@
.@@...@@
.@@...@@
.@/@@@@/
........
........
........

glyph ß = sz-lower

물론 한글 같은 것도 있고 문자 조합 시스템도 만들어져 있다. 이렇게 써 놓으면 꽤 거창해 보이지만 그냥 문자열 장난이다. 대부분은 노가다…

글꼴 라이선스는 아직 정하지 않았다. 뭐 쓰는 데 제약을 둘 생각은 전혀 없지만 GPL+FE로 할 것인가 SIL OFL로 할 것인가 같은 류의 선택을 경험이 없어서 아직 할 단계가 아닌지라, 정말로 쓸 생각이라면 이 점은 주의하시길. 이 글의 나머지 부분은 글꼴을 만들면서 생긴 이런 저런 일들을 주저리 주저리 써 보도록 한다.