TextMate 한글 반쪽으로~

요즘 웹 프로그래밍을 종종 할 일이 있어서 한꺼번에 파일을 많이 열어놓고 보려니
TextMate를 종종 쓰고 있습니다.
그런데, 역시 다 좋은데 한글이 대략 난감하게 나오는 문제
HTML 편집할 때 매우 난감한데, 그래도 한글이 별로 없는 파이썬 파일을 고칠 때는
쓸만 해서 그런대로 만족하고 있습니다. ^_^

어제 일본사람들은 그렇다면 어떻게 쓰고 있는지 궁금해서 검색을 해 봤더니, 역시 지난 11월 초에 글꼴을 가로로 반으로 줄이는 방법으로 우선 피해가는 방법을 올린 사람이 있었습니다. 오! 마침 fontforge용 스크립트도 제공되어 있길래 은글꼴의 한글과, Bitstream Vera Sans Mono를 가지고 똑같은 방법으로 줄여서 써 봤습니다.

TextMate + 반쪽짜리 한글 글꼴

으흐흐. 좀 거시기하긴 하지만, 나중에 정식으로 지원되기 전까지는 답답하게 나마 쓸 만 하겠네요. 사용한 글꼴 둘 다 오픈소스로 공개되었기 때문에, 얘네들로 만든 글꼴도 fontforge깔기 귀찮은 분들을 위해 올려둡니다.

은고딕 반쪽+VeraMono TTF 내려받기

오픈소스에 뛰어들기 정리

어제 “오픈소스에 뛰어들기“를 했습니다. 아침부터 저녁까지 계속 뛰어다니면서 후다닥 했더니 피곤해서 거의 10시간을 잤군요;; 행사 준비에 많은 도움을 주신 여러 강사, 자봉 분들과 추운 날씨에도 오셔서 능동적으로 참여해 주신 참가자 분들께 깊은 감사 드립니다. ^^

이번 행사를 하면서 느꼈던 점과 설문에 적어주신 내용을 토대로 몇 가지 더 좋은 행사를 위한 개선 사항을 기록해 둡니다.

  • 약도와 익숙한 사람만 알아볼 수 있는 오는 길 때문에, 대부분 장소에 찾아오기가 너무 힘들었다 -> 다음엔 사진을 포함한 상세한 오는 길 표시를 해야겠습니다. +_+
  • 시간이 너무 모자란다. – 각 세션이 대부분 실습 수업이라 초기에 세팅하는 데 드는 시간 때문에, 대부분 시간이 모자라서 문제가 많았던 것 같습니다. 실습의 경우에 세팅에 드는 시간을 예측하거나, 조교를 대량으로 투입하던지 좀 더 쉽게 설치할 수 있는 환경을 마련해야겠네요.
  • 실습 환경 준비를 위한 노트북 세팅이 아슬아슬.. – 노트북에 무선랜도 안 잡히는 부여리눅스가 깔려있어서 다들 그걸 우분투로 엎느라고 힘들었는데, 우분투 씨디를 충분히 준비해서 세팅 시간을 절약해야겠습니다. -o-
  • 선입금 덕분에 날씨에 크게 참가자 수가 영향을 받지 않았다 – 아무래도 추운 날씨에도 참여할 의지가 있는 분들을 선별하기 위한 첫번째 필터로 작용할 수 있지 않았을까 싶습니다. 바로 전날 있었던 다른 행사에서 2/3가 불참했다는 얘기를 들으니, 이번에 선입금이 효과가 있었던 것 같네요.
  • 학생에 대한 좀 더 적극적인 홍보가 필요하다 – 의외로 소식을 들은 곳을 묻는 질문에, 학교 홈페이지라고 대답한 사람이 많았고, KLDP도 모른다는 사람도 제법 있었습니다. 홍보 채널을 다양화하는 것이 새로운 사람들을 커뮤니티로 끌어들이는 결과를 얻을 수 있을 듯.

행사의 달인 조성재님이 없었으면 이번 행사 준비가 상당히 힘들었을텐데, 정말 감사드립니다. 다음 행사도 잘 부탁해요 -ㅇ-; 다음에도 컨텐트가 준비되면 한 번 또~ 🙂

그리고, 이번 행사에서 나온 참가비는 예정대로 플랜 한국위원회에 기부해서 세계의 기아들을 돕는데 쓸 예정이고, 아마도 52만원인가 됐던 걸로 기억합니다. (나머지는 행사 비용으로 사용) 기부자 이름은 참가자 모두의 이름을 쓸 수 없으니 일단 sha1 해시 16진법으로 표기한 이름으로 써달라고 해 볼 예정인데, 안 되면 그냥 행사 이름으로 ^^;

CN님께서 끝날 무렵에, 좋은 제안을 하나 하셨는데, 학생들을 위해서 모든 오픈소스 관련 행사에 대한 안내를 해 주는 RSS/모듬 사이트를 하나 운영하면 좋지 않겠느냐고 제안을 하셨습니다.
아무래도 지금은 홍보를 하려면 오픈소스 사이트 들에도 일일이 다 돌아다니면서 해야 하는 형편이니, 그런 사이트가 마련되면 많은 분들이 쉽게 보실 수 있을 것 같아서 좋겠네요.

이제 이번 겨울에는 가능하다면 RuPy 도 한 번 하고, Framework2.2도 한 번 하고 골고루 해보려고 하는데, 잘 됐으면 좋겠습니다. ^_^

(가짜) 한글 Lorem ipsum

Apple iWork를 포함한 많은 워드프로세서/조판 시스템들이 Lorem ipsum을 레이아웃을 보여주기 위한 가짜 텍스트로 사용하고 있습니다. 이거 한글로 뭔가 문장이 많이 필요한데, 무궁화 꽃이 피었습니다만 반복하기도 그렇고.. 그렇다고 제대로 한글 빈도, 문장 구조 만들기도 힘들고 해서 그냥 라틴어 읽기 방법을 대충 구현해서 lorem ipsum을 초등학교 영어 자습서처럼 한글로 읽게 했습니다. –;

혹시 한국어 정보처리에 조예가 깊으신 분들은 진짜 한국어 문장처럼 보이게
완벽한 한글판 Lorem ipsum을 만들어 주시면 감사 -O-;;

제 가짜 한글 lorem ipsum은 http://openlook.org/svnpublic/snippets/hipsum/에 올려 두었습니다.

파이썬 GIL 깊숙히! (上)

대표적인 파이썬 구현인 CPython에서 거의 십년여 지속적으로 문제로 두루 지적 받아 왔지만 여전히 그대로 있는 것으로 바로 GIL (Global Interpreter Lock)이 있습니다. 점점 CPU 여러 개를 동시에 쓰는 시스템들이 많아지면서 특히 요즘 자주 언급되고 있는데, GIL은 짧게 말해 동시에 CPU를 1개 밖에 못 쓴다는 그 문제의 근원입니다.

역사적 배경과 존재의 이유

GIL은 처음 파이썬에 쓰레드 구현이 들어갈 때 같이 생긴 이후로, 지금까지 계속 내려오고 있습니다. 파이썬 구현은 상당 부분이 라이브러리 전역 변수에 의존하고 있고, 여기 저기 객체 구조에 따라서 참조를 따라서 마구 접근을 하기 때문에, 동시에 쓰레드가 여러 개 돌아갈 때 심각한 문제가 발생할 수 있습니다. 따라서, 파이썬은 초창기부터 파이썬 라이브러리 코드가 돌아가는 중에는 전역적인 락(GIL)을 걸어서 동시에는 절대로 같이 못 돌아가도록 해서 해결하였습니다.

물론 이 문제를 해결하기 위해
1996년과 2000년에 Greg Stein이 GIL을 완전히 없애고 섬세한 락(fine-grained lock)을 구현
하였지만, 그 결과 SMP에서는 1.6배 속도가 빨라졌지만, 대부분의 사용자가 쓰는 UP에서는 엄청나게 느려져서 실제적으로 대부분 사용자들은 불평을 할 수 밖에 없었고, 그로 인해서 모듈을 만들기가 쉽지 않은 문제들과 복잡성이 증가해서, 다른 개발자들이 선뜻 유지보수 가능한 코드 개발에 나서지 않아서 그냥 GIL이 지금까지 남아있게 되었습니다.

GIL은 대략 어떤가?

위 그림에서는 메인 쓰레드와 거기서 띄운 쓰레드 3개가 같이 돌아가는 모습을 그려 놓았습니다. (못 생겨도 이해 바랍니다. ^^;) 파란색 상자가 돌아가는 상태에 있는 것을 표시한 것인데, 대충 눈에 보이듯이 동시에는 파이썬 쓰레드는 1개만 돌 수 있습니다. 여기서 파이썬 쓰레드라 함은, 파이썬 인터프리터가 호출하는 모든 코드를 뜻합니다. 즉, C코드와 파이썬 코드의 구분 없이 일단은 모두 파이썬 쓰레드처럼 동시에 1개만 돌아가게 GIL의 영향을 받습니다. 여기에 예외도 있는데 이것은 후에 설명하겠습니다.

쓰레드 실행이 바뀌는 시점은 언제일까?

파이썬은 아시다시피 내부적으로 바이트코드로 번역된 다음에 실행됩니다. 예를 들어 보면 다음과 같이 바이트 코드를 볼 수 있습니다.

평소에는 GIL을 꽉 쥐고 있다가, 각 줄을 파이썬 인터프리터에서 처리하면서 내부적으로 카운터를 1씩 증가시킵니다. 그러다가 100이 되면 GIL을 풀었다가 다시 쥐게 되는데, 풀었다 쥐는 사이 공간에서 문맥 전환(context change)가 일어납니다. 즉, 파이썬 인터프리터가 쓰레드가 1개만 뜨는 것이 아니라, 인터프리터도 쓰레드마다 도는데, 서로 GIL 때문에 동작은 1개씩만 하는 상황이죠. 그래서 그림을 보시면 자발적이 아니라 틱이 100이 돼서 전환되는 쓰레드들은 너비가 100의 배수로 되어 있습니다. 100이 어느 정도 범위인가 하면, 보통 쓰는 정도의 파이썬 코드 20~30줄 내외가 바이트코드 100줄 정도 되기 때문에, 그렇게 크지도 않고 작지도 않은 단위라고 볼 수 있겠습니다.

특별한 사건이란?

위의 그림 ①번에서 보듯이, 심지어 새로운 쓰레드를 시작할 때에도 즉각적으로 새 쓰레드가 실행되지는 않습니다. 기다리고 있다가, 원래 돌던 쓰레드의 카운터가 100이 돼야 돌아가게 됩니다. 그런데, 100개 단위로 일어나는 것이 아니라 “특별한 사건”이 있을 때는, 갑자기 100으로 퍽~ 뛰어서 문맥 전환이 일어납니다. 그림의 ②이나 ③은 틱에 의해서 전환된 것이지만, ④번 같이 블러킹 시스템콜이 일어나게 되면 select(2)하는 동안에 락을 걸고 있으면 다 멈추니까, 다른 쓰레드로 넘겨줍니다.

쓰레드가 어떤 순서로 실행되나?

위 그림의 ⑥번도 마찬가지로 시그널이 발생하면 일단 시그널을 큐에 쌓아둔 다음에 틱을 100으로 증가시켜서 즉각적으로 다른 곳으로 넘겨버립니다. (그래서 이렇게 시그널 핸들러가 직접 호출되지 않는 경우가 있기 때문에,
시그널 핸들러가 희한하게 꼬인 상황에서 엉뚱한 예외가 발생한다거나, 시그널 때문에 예외가 씹힌다거나, 순서가 뒤죽박죽이 되는 일이 일어납니다.)

그런데, 쓰레드 수가 많을 때 실행되는 순서는 어떻게 될까요?
뭔가 내부적으로 정해진 것이 있으면 좋지만, 사실 파이썬에서는 시스템의
쓰레딩 라이브러리에 전적으로 맡깁니다. 즉, POSIX 시스템에서는
sem_post(3)/sem_wait(3) 또는
pthread_mutex_unlock(3)/pthread_mutex_lock(3) 쌍을 순서대로 호출해서, 그냥 아무데나 가도록 합니다.

그런데, 이게 쓰레드 구현마다 다르고 쓰레드의 종류마다 달라서, 일정한 동작이 있지 않습니다. 일반적으로 시스템 스코프 쓰레드들은 lock/unlock을 확인하는데 커널을 거쳐야하기 때문에, 굉장히 자주 바뀌고 순서가 아주 제멋대로인 반면에,
프로세스 스코프 쓰레드들은 lock/unlock을 프로세스 내부에서 처리해버리기 때문에, 좀처럼 잘 바뀌지 않고, 순서도 거의 일정합니다. 심지어 쓰레드 50개를 만들 동안에 50개 모두 전혀 실행 안 되고 버티는 경우까지도 종종 있을 정도입니다.

따라서, 쓰레드의 실행 순서나 실행의 정도에 의존하는 프로그래밍은 쓰레드
라이브러리가 바뀌면 안 돌아갈 수도 있기 때문에, 좀 생각해 볼 필요가 있습니다.

쓰레드가 1개만 돌면 난감하지 않은가?

CPU가 여러 개 있을 경우나 블러킹 시스템콜이 중간에 끼이는 경우 같이, 여러 개의 쓰레드가 꼭 동시에 돌아야할 때가 있습니다. 특히 GUI 네트워크 프로그램들 같은 경우에 반응성과 직결되는 문제인데요, 이 경우를 위해 명시적으로 일부분에서 락을 풀어주는 방법을 제공합니다.

위 그림의 ⑫와 ⑭사이가 그런 경우입니다. ⑫에서 Py_BEGIN_ALLOW_THREADS를 해 주면, 그때부터 그 쓰레드는 GIL과 상관 없이 다른 파이썬 쓰레드와 동시에 돌 수 있게 됩니다. 물론, 이 때에는 파이썬 함수를 호출하거나 파이썬 객체를 건드리는 등 파이썬과 관련된 것은 어떤 것도 해서는 안 됩니다. 이런 종류의 작업이 끝나면 ⑭번에서 Py_END_ALLOW_THREADS를 호출해 줘서 이제 그 쓰레드도 GIL의 영향 하에 들어가서, 문맥 전환을 기다리게 됩니다. 물론 즉시 바로 받는 것은 아니고 돌아가던게 100이 되길 기다리는 거죠뭐~ -O-

GIL을 왜 쓸까?

위에서 GIL을 대충 살펴봤는데요, 보시다시피 쿼드코어 CPU가 난무하는 이 시대에 좀 껄쩍지근~하게 들리는 것이 사실입니다. 그럼에도 불구하고 파이썬에서 GIL을 계속 쓰고 있는 것은, GIL이 UP에서 상당히 효율적이기 때문입니다. 파이썬 같이 객체가 많고 객체간 접근이 두리뭉실해서 효율적인 락을 구현하기 힘든 경우에는 필요 없는 락에
의해서 낭비되는 자원이 상당합니다. FreeBSD 4.x까지도 그랬듯이, 전체에 락을 거는 것은 상당히 코드의 복잡성을 줄여주고 UP에서 락에 자원을 낭비하지 않고 높은 효율성을 유지할 수 있게 됩니다.

그렇지만, 역시나 게임기에도 쿼드코어가 들어가는 세상이 되면서, MP지원의 중요성 은 점점 커져가고 있고, 파이썬도 나름대로 그에 대한 대처를 하려고 여러가지 이야기가 나오고 있습니다. 그에 대한 이야기는 다음 시간에~~

◈ 좀 더 자세한 것을 알고 싶으신 분들은 파이썬 소스 중 Python/ceval.c에서부터 보기 시작하시면 됩니다.
◈ 그림에 오류가 하나 있는데, 쓰레드 #1에서 ④~⑤사이에 비어있는 부분은 갈색 블럭이 되어야 합니다.

Django 책

요즘 파이썬 웹계에서는 지난 주에 발표된 《The Django Book》이 굉장한 관심을 불러모으고 있습니다. 내년에 정식으로 출판될 책인데, 미리 독자들의 리뷰와 의견들을 모으기 위해서 인터넷에 본문을 공개한 것입니다.

종이로 된 책이 나오는 것 자체가 시장에서의 위치를 얘기해 주는 대략적인 지표를 넘어선 것이라고 볼 수 있어서 상당히 반가운 일이기는 하지만(최근에는 파이썬 수험서도 나왔죠! ^.^), 이 책에서는 공개한 방식이 무척 주목할 만 합니다.

우선, 전문을 한꺼번에 공개한 것이 아니라, 책의 일부씩 순차적으로 공개했다는 점이 중요한 듯 합니다. 전문을 공개했다면 이미 책이 완성돼서 출간되기 직전에 그냥 한번 입에 오르기 위한 것이 아닐까 하는 느낌도 들고, 사람들의 관심이 분산되었을텐데, 조금씩 조금씩 차차 공개함으로써, 사람들의 관심을 집중시킬 수 있으며 상호작용을 촉발시키는 중요한 계기가 된 듯 합니다.

또한, 웹 프레임워크답게 아주 편리한 웹 인터페이스를 제공해 주었는데요, 그동안 파이썬쪽에서 널리 쓰이던 Silva는 괜찮은 듯 하면서도 은근히 손이 점점 안 가게 되는 답답한 면이 많이 있었습니다. Django Book에서는 최근 유행하는 웹 기술들을 적용한 덕에, 점점 코멘트를 달고 싶어지는 UI를 잘 만들어낸 것이 아주 멋있습니다.

코멘트 시스템에 대한 설명을 보면, 개략적인 설명도 있는데 Yahoo! YUI를 썼다고 하는군요. 나중에 혹시 이게 범용으로 공개된다면, 책을 번역하거나 공개 리뷰를 하는 목적으로 매우 편리할 것 같습니다. +_+

제인 구달 박사 강연 『희망의 이유』

오랫동안 제 마음 속 영웅 중의 하나인 제인 구달(Jane Goodall)박사가 학교에서 강연을 해서 듣고 왔습니다. 생물학과 교수님들이 사람이 너무 적을까봐 걱정하면서 꼭 가보라고 얘기를 했는데, 막상 가보니까 빈 자리가 없을 정도로 꽉꽉 들어차서 간신히 자리를 하나 찾아서 앉았습니다.

사회자가 소개를 하고 앞으로 딱 나오는데, 옷이 탐험복 비슷한 것을 입으신게 아 막 눈물이 쏟아지려하는 감동이.. 울컥~ 우흐흐. 처음에 인사를 하시는데, 침팬지 언어로 “Hi~”를 하는데, 진짜로 실감나게 동물의 왕국에서 봤던 침팬지 인사를 구사하시더군요. 저 정도면 진짜 침팬지랑 말이 통하지 않을까 생각..

오늘 강연 내용은 뭐 대체로 그동안 책에 있던 내용이 요약되어 새로운 것은 없었지만, 그래도 그 연세에도 일년 중 300일 이상을 환경과 미래를 지키기 위해 이런 저런 강연과 만남을 갖고 계신 것을 보면 정말 대단합니다. 저도 30살되기 전에 칼슘을 많이 먹고 운동을 꾸준히 해야겠어요;;

그리고, 책에서 꾸준히 나왔던 종교적인 신념에 대해서 어떤 학생이 질문을 했는데, 이제 더 이상 공적인 자리에서 기독교인이라는 것을 밝히고 있지 않고 진화를 지지하지만, 신의 존재에 대해서는 믿고 있다고 합니다. 그동안의 책과 어조가 약간 바뀌신 것이 흥미롭네요. +_+

우흐흣. 싸인 받았습니다. 자랑 -.-vv (사람이 너무 많아서 이름은 안 써주시더군요; 아쉽;)

파이썬의 JIS Roman, KS Roman 문제에 대해

nohmad님께서 개멍님의 글을 알려주셔서, 일단 직접적인 관련이 있는 당사자로 해명을 해 봅니다. ^^

CP949에서 ‘\\’는 u’₩’가 되어야 하는가?

우선 개멍님의 글 안에서 말씀하셨듯이 euc-kr이나 cp949에서 ‘\\’ (즉 굴림체에서는 원화기호로 보이는 그것)가 유니코드로 u’₩’로 하는 것은 좀 곤란하지 않을까 합니다. 현재 CP949는 표준 문서가 따로 있다기 보다는 △ Microsoft 구현의 실제 동작 △ Microsoft가 Unicode Consortium에 제출한 코드 매핑 두 가지가 권위가 있는 근거로 볼 수 있습니다. 둘 다 ‘\\’에 대해서 U+5C (REVERSE SOLIDUS)로 매핑하고 있기 때문에, CP949측에서는 u’\x5c’로 하는 것이 적당하다고 생각됩니다.

EUC-KR에서 ‘\\’는 u’₩’가 되어야 하는가?

또한, EUC-KR에 대해서도 그런 매핑이 근거를 얻으려면 EUC-KR이 G0 영역(0x20-0x7f)에 KS Roman (KS X 1003)을 할당했다면 됩니다. 그렇지만, 현재 EUC-KR에 대해 권위가 있다고 판단되는 ISO측의 등록에서 G0 영역에 KS Roman이 아닌 US-ASCII를 할당하고 있기 때문에 당연히 0x5c에 대해서 U+5C를 매핑하는 것이 표준에 맞는 동작이라고 볼 수 있겠습니다. 즉, 위 두가지 상황에 대해 키보드에서 누르는 것과 화면에서 원화 기호로 보이는 것, 즉 입력기와 굴림체 글꼴의 버그라고 볼 수 있을 뿐, 인코딩 변환에 관련해서는 문제가 없습니다. 그렇지만 물론 키보드에서 원화 기호가 써 있는 키를 누른다고 해서 진짜로 ₩(WON SIGN)로 나와버리면 곤란하겠죠. 지금까지 전 국민이 U+5C를 써 왔으니..;

후에 추가: EUC-KR에 대한 표준은 찾아보니까 ISO보다는 KS X 2901이 더 권위가 있겠네요. 🙂 그 내용에 대해서는 신정식님의 메일을 참고하시면 명쾌하게 될 듯 합니다.

CJKCodecs에서 JIS 인코딩들의 같은 문제에 대해

반면 JIS 인코딩들 (SHIFT_JIS, EUC-JP)은 G0에 US-ASCII가 아니라
JIS Roman (JIS X 0201)을 할당하고 있기때문에 엔화 기호와
윗줄(OVERLINE)이 대신 변환되는 것이 옳습니다.
그렇지만, 위 글의 코멘트에서 토끼군이 답변하였듯이, 파이썬의 CJKCodecs의 2003년 말 버전에서부터 일본인 사용자들의 끈질긴 요청에 따라 기본 코덱들을 한국처럼 G0에 US-ASCII를 할당하도록
바꾸고, 대신 -strict라고 꼬리를 붙인 표준 준수 코덱들을 넣어
놓았었습니다.

그렇지만, 이것을 구현한 방식이 #ifdef를 이용해서 프리프로세싱을 2번 다르게 해서 표준/비표준 코덱을 구현한 것이다보니 파이썬에 CJKCodecs가 들어가면서 프리프로세싱을 임의로 제어하기가 힘들어져서 결국에는 -strict 코덱들이 모두 제거된 채로 들어갔고, 그로 인해서 표준을 준수하는 코덱이 빠지고, 실질적으로 일본인들이 사용하는 인코딩만 남은 것이 현재 상황입니다.

후에 추가: 일본 인코딩의 경우에도 photon님의 말씀과 다른 자료를 종합해보니, Shift_JIS나 EUC-JP모두 US-ASCII와 JIS X 0201을 어느 쪽을 써도 좋도록 하고 있다고 합니다. 따라서, 위에서 말한 엄격한 표준 준수라는 말은 모두 잘못된 표현이기에 바로잡습니다. ^^;

일본 인코딩 표준의 심각한 문제

사실 -strict 인코딩을 일본인들이 그렇게 싫어했던 이유는 한국 사람들 같이 그냥 단순히 보이는 것이 다르다 정도가 아니라, 아예 “코딩이 불가능”한 상황이었기 때문입니다. JIS Roman에서 교체하고 있는 글자가 2개가 있는데 엔화기호<->REVERSE SOLIDUS와 틸드<->OVERLINE 입니다. 그런데, REVERSE SOLIDUS같은 경우에는 굳이 쓰려면 JIS X 0208에 정의된 것을 쓰면 충분히 roundtrip도 보장되고 억지로 어찌어찌 되기는 하는데, 틸드의 경우가 심각합니다. 즉, JIS X 0208에 틸드가 없기 때문에, 결국 표준에 맞게 구현을 하다보면 SHIFT_JIS에서는 틸드를 아예 못 쓰게 되는 것입니다. 그래서 bitwise not같은 연산자로써나 “hi~~ o/~” 같은 경우에서나, 여러모로 아예 코딩이 불가능한 상황이 오게 된 것입니다. (파이썬은 2.4부터 “항상” UTF-8로 변환한 뒤에 토크나이징/컴파일을 하기 때문에 유니코드에서 뭘로 매핑되느냐가 굉장히 중요합니다.)

그래도 표준 지원..

사실 한동안 까먹고 있어서 진행이 안 되고 있었는데, 파이썬에 있는 CJKCodecs는 표준 지원을 위해서 다음 몇가지를 진행할 계획이 있습니다.

  • CNS11643 캐릭터셋 통합 (현재는 CJKCodecs에만 있음)
  • iso-2022-cn, euc-tw 지원 (CNS11643 캐릭터셋이 있어야 함)
  • 일본 MS 확장 인코딩 표준 지원 (일본 Legacy Encoding 프로젝트 작업분 통합)
  • 일본 -strict 코덱 부활
  • Big5 확장 인코딩을 변경할 수 있게 매핑 오버라이딩 지원

으흐흐. 2.6 나오기 전까지는 할 거예요 =3=3

노벨상 받는 법

PLOS에 올라왔던
How to Win the Nobel Prize?
에서 짧게 몇 가지 강조한
것들을 보니까 예전에 학교에서 했던 수상자들 강연과 통하는 부분이 있네요. 그래서 옮겨적어 봅니다.

  • 명료하고 간략하게 글을 쓰는 방법을 배워라. 과학에서 많이 생기는 문제가 바로 과학자가 이해하기 힘든 사람이 돼 버려서 자기 노력을 헛되게 한다는 것이다.
  • 마음을 넓게 하고, 문화적인 인식을 하라. 다른 사람들이 성취한 것들에 대해서 알아두자. 모든 젊은 과학자들은 가능하면 적은 적을 두는 것이 중요하다는 것을 자주 상기할 필요가 있다.
  • 시간은 귀중하다. 여성들은 특히 “위원회에 의한 죽음(death by committee)”에 취약하며 그들의 항의가 몹시 필요하다. (무슨 뜻인지 짐작만 갈 뿐 정확히는 모르겠군요;;)
  • 멋있는 관리자격 직위를 맡는 것을 피하라. 이것이 바로 파멸의 근원이다. 특히 임상의 출신들은 더욱 그러하다. 나는 이제 괴롭힘 당하는 총장을 맡고 있기 때문에, 이 점의 중요성에 대해서 강조할 수 밖에 없다.
  • 오래 살아라. 어떤 것을 발견한 것을 노벨상으로 인정받으려면 50년이 걸릴 수도 있다.

오래 살아야 한다는 것은 모든 수상자들의 조언에 나오는 공통적인 조언이군요. 으흐흐. 멋있는 관리직을 피하라는 것이 중요하게 다가옵니다. 아무래도 개발자들도 관리직의 유혹에서 벗어날 수 있어야 지속적으로 자기 하고 싶은 걸 할 수 있는데, 맨날 어디 TV나가고 정치하러 다니는 교수님들보면 연구 언제할까 생각이 들 때가 있더군요. 특히 저 글 안에서 “노벨상을 받는 것은 곧 사생활이 없어지고, 연구에 필요한 창의성과 자기반성을 앗아갈 수도 있기 때문에, 어쩌면 절대 그 행사 분위기에서 회복할 수 없을지도 모른다”라고 하고 있는데, 만약에 지금까지 한국에서 노벨상 후보로 올라갔던 김성호박사님 같은 분들이 진짜로 수상을 했으면 언론과 정부에서 얼마나 괴롭혔을까 생각을 해 보니까 참 아찔 하긴 하네요. -O- 연구 업적이나 그 중요성은 여전히 대단하지만 변한 것은 노벨상 받고 안 받고 밖에 없는데 말이죠.

한편, 노벨상을 받은 사람이 있는 동일한 연구분야에서 더 좋은 업적으로 더 유명해진 다른 과학자들이 역사에 상당히 많이 있는 것을 보면, 과장해서 노벨상 때문에 인생을 말아먹었어요 -ㅇ- 라고 마치 복권맞은 것 때문에 인생이 바뀌었다는 사람도 있지 않을까 생각을 해 봅니다. 크흐흐. 재미있는 것을 오랫동안 하고 살기 위해서는 역시 전략을 잘 세워야겠습니다. +_+