python

오늘은 yser님의 다음 질문에 대한 답변을 겸해서 CJKCodecs의 뒷이야기에 대해서 얘기할까 합니다.

파이썬 2.4 에 유니코드 코덱 추가된 것 보면서 신기해하는 중입니다. 오픈소스로 개발되면서 막상 한국인이 비교적 알려져있는 프로젝트에 정식으로 코드 추가 되는 걸 못본지라.. 그런데 저 많은 인코딩 정리하면서 별로 힘들진 않으셨는지? 간만에 저런걸 보니 머리가 지끈거리는군요.

사실 코드 쪽에 관심이 있습니다. 아는 분이랑 정보 교환해가며 이해할려고 한참 헤맸던 적도 있는데 국내엔 정말 자료 찾기가 힘들어서 정작 외국에서 다 찾아야 하더군요. 이럴 땐 정말 영어 독해 잘하는 게 절실합니다.

파이썬 2.4에 CJKCodecs가 들어간 것에 대해..

우선, 파이썬 2.4에 추가된 것에 대해서는 코덱을 따로 설치하지 않아도 돼서 좋긴 하지만, 한국인이 기여한 것으로는 서지원님의 제너레이터 익스프레션 구현이 좀 더 인상적입니다. 🙂 제너레이터 익스프레션은 누구나 쓰는 일반 문법이면서 파이썬의 장래에도 큰 영향을 미칠 부분이라서~ 코덱은 그냥 보조적인 역할이지용. 그리고, 그 외에도 한국인이 올린 패치는 수도 없이 많습니다~

국제화(i18n)에 대한 문서의 부족..

한국어 코드에 대한 것들은 사실 찾아보면 국내에도 자료가 제법 있습니다. 김경석 교수님 홈페이지도 있고, 카이스트에 있는 좀 오래된 자료 중에서도 몇가지 괜찮은 게 있습니다. 일본어나 중국어 정보처리에 대한 것은 국내에는 자료가 크게 많지는 않은 편인데, 사실 한국어 사용자 중에서 일본어나 중국어, 베트남어 정보처리를 프로그래밍 해야하는 개발자가 얼마나 될 지를 생각해 보면 그다지 자료가 많아야 할 필요는 없다고 생각합니다. 많은 개발자가 실제로 쓰는 자료가 풍부해야겠지요..

CJKCodecs의 전신 KoreanCodecs

여기부터는 유아저씨의 《신화창조의 비밀》 스타일로.. –;; CJKCodecs는 최초에 KoreanCodecs로 시작되었습니다. KoreanCodecs는 2001년에 지금은 OSK에 계시는 이만용이사님의 작품인데, 당시에 파이썬 유니코드 스펙이 나오고 얼마 지나지 않아서 나온 것이라서, 파이썬 안에 들어있는 charmap 코덱처럼 딕셔너리 자료형을 기반으로 순수 파이썬으로 구현되어 있었습니다. 룩업 때문에 일어나는 속도 저하를 극복하기 위해서, 별도로 KoreanCodecs 2.0을 fork해서, C로 작성된 코덱을 추가하였습니다. KoreanCodecs 2.0에서는 디코딩과 인코딩 모두 trie와 비슷한 자료구조를 사용해서 빠르면서도 메모리 소모가 적은 형태로 구현을 해서, 나중에 JapaneseCodecs의 구조에도 영향을 주었습니다.
KoreanCodecs 2.0이 처음 나온것이 2002년 2월이었고, 2002년 12월 정도까지 업데이트가 됐습니다.

CJKCodecs로 통합

2003년 초, KoreanCodecs, JapaneseCodecs 모두 활발히 메인테인은 되고 있었지만, 파이썬에 들어가기에 용량이 지나치게 크고 메모리를 많이 사용한다는 문제점이 지적되어서 많은 유럽어권 개발자들이 꺼리고 있었습니다. 그리고 파이썬에 들어가더라도 관리할 사람이 필요했는데, JapaneseCodecs를 개발하던 카지야마씨가 박사학위 논문으로 너무 바빠서 뭐 이런 저런… 으흐흐..

ChineseCodecs는 사실상 그때 전혀 관리되고 있지 않았고, 파이썬 2.3에서 새로 들어간 PEP 293 코덱 에러 콜백기능 때문에, 기본 코덱 구현조차 멀티바이트 인코딩에서는 극도로 어려워지고 코드 양이 엄청 늘었으며, 스트림 코덱은 정말 복잡한 상태가 돼 버렸습니다. (PEP 293을 쓴 사람은 독일 사람이라 별로 난이도에 대해서 고려를 안 한듯 했지만..;) 그래서 결국은 PEP-293을 지원하는 코덱 프레임워크를 만들고 그 걸 이용해서 한, 중, 일 인코딩을 모두 지원하는 방향으로 구현해 버렸습니다. 결국 2003년 6월 첫 CJKCodecs을 내놓았습니다.

CJKCodecs 성숙

CJKCodecs는 사실 한국에서는 인코딩이 지원되느냐 마느냐 정도로 아주 간단한 문제였기 때문에 큰 관심을 끌지는 못했지만, 일본에서는 인코딩 수가 장난이 아닌데다가 캐릭터셋도 수시로 업데이트가 되기 때문에 많은 관심을 끌었습니다. 초창기에 CJKCodecs의 일본어 캐릭터셋 중에 JIS X 0201-R과 JIS X 0208같은 경우 표준을 정확하게 준수해서 구현을 했지만 오히려 그렇게 한 것이 일본 사용자들의 현실적인 사용에 불편을 줘서, 실제로 일본에서 널리 쓰일 수 있는 형태로 대폭 개정하는 등 여러가지 현실화 작업을 거쳤습니다. 그리고, 일본의 최신 표준이었던 JIS X 0213:2000을 반영해서 거의 12개의 일본어 인코딩을 지원하기 시작했습니다.

파이썬으로 편입

파이썬 2.4 릴리스를 위한 피쳐 프리즈가 다가오던 2004년 초에, 드디어 표준 파이썬에 CJKCodecs를 통합하려는 작업을 시작했습니다. 마침 2003년 12월에 제가 itertools 모듈 관련 작업을 위해서 파이썬 커미터로 들어가 있었기 때문에, 관리상의 문제도 없었고 패치에 안간힘을 써서 메모리/소스 용량을 최소로 줄여서 서구권 사용자들에게 잘 보이도록 노력해서 결국은 별 수정 없이 들어가게 되었습니다. 당시에 사실 용량 부담을 줄이기 위해서 euc-tw나 iso-2022-cn같은 것을 지원하기 위해 필요한 CNS 11643을 빼버렸는데, 아직도 파이썬에서는 CNS 11643이 빠져 있어서 euc-tw를 지원하지 않고 있습니다만.. 대만 사람들이 별 관심이 없는지 한 번도 거기에 대해서 얘기를 들은 적이 없어서 그냥 빠진채로 놔두고 있습니다. 으흐흐;

편입 이후의 변화

파이썬에 편입된 이후에는 우선 일본에서 새로 나온 표준인 JIS X 0213:2003 지원과 홍콩의 새로운 표준인 HKSCS 2004를 지원했습니다. 소스코드가 캐릭터셋과 인코딩들이 다 각각 나뉘어 있어서 모듈 수가 20개 가까이 됐던 것을, 각 국가별로 캐릭터셋과 인코딩을 모두 묶어서 1개씩으로 만들어버렸습니다.

CJKCodecs 편입 과정에서의 느낌

CJKCodecs를 만들고 파이썬에 넣는 과정 중에서 느낀 점이 많았습니다. CJKCodecs를 만들었을 때 KoreanCodecs나 ChineseCodecs보다 빠지는 점 없이 완벽한 대체판이 될 수 있었음에도 불구하고, 한국과 중국 모두 CJKCodecs가 별로 반향이 없었다는 점에서, 사용자들의 관심은 아무래도 자기 언어를 쓰는 것에 보다 관심이 있는 것이라는 점을 깨닫게 되었습니다. 당연하겠지요. 저도 그런데. 이히히. 당연한 것을 개발에 한참 빠져있으면 까먹게 되더군요.. ㅡ.ㅜ

한편, CJKCodecs가 관심을 얻은 곳은 일본 사용자들 중에서 새 표준에 관심있는 사람들이나 서구권 개발자들이었습니다. 서구권 개발자들은 그 지긋지긋한 CJK 문제를 CJKCodecs 하나만을 끼워줌으로써 말끔히 해결할 수 있다는 점에 매력을 느낀 것 같고, 일본에는 특유의 문화로 독특한 것 좋아하는 사람들이 많아서.. -.-;; 그래서 그 덕분에 일본의 현실에서 쓰는 코드와 다른 표준들을 피해가는데 많은 도움을 얻을 수 있었습니다.

그리고 또 하나! 패치에 있어서 첫인상은 정말 중요하다는 점..
보통 패치를 올릴 때 대충 만들어서 올린 다음에, 계속 고쳐야지 하는 경우가 많은데, KoreanCodecs를 파이썬에 넣으려고 패치를 올렸을 때 초기에 버그가 좀 많아서 개발자들이 처음에 시도해 보다가 나중에는 다 고치고도 별 관심을 보이지 않았습니다. CJKCodecs 때는 그래서 리뷰에 리뷰를 거쳐서 깔끔하게 올렸더니 첫인상이 좋았던지 단번에 반응이 꽤 좋았던 것이.. 첫인상의 중요성을.. 🙂

한국의 대안언어축제와
비슷한 성격의 일본의 축제인 LLDN 2005가 8월 27일에 있었다고 합니다. 우리도 비슷한 행사를 하고 있으니 관심을
가지고 좀 찾아보았습니다. 🙂

예산과 행사 조직

대안언어축제 초기에도 LLDN에 대한 얘기가 좀 있긴 했는데,
LLDN은 기존에 잘 꾸려진 커뮤니티들이 연합하여 하는 것이지만
대안언어축제는 유명무실한 커뮤니티들 사람들 몇몇이 임시로
모여서 하는 거라 좀 다른 면이 있습니다. 그리고 대안언어축제는
지원을 정부기관에서 했지만, LLDN은 O’Reilly Japan이나
여러 다른 출판사, 신문사, 소프트뱅크 같은 곳에서 지원을
하고 있습니다.

LLDN은 2003년부터 계속 이름이 바뀌어 왔는데,
2003년엔 LLSaturday로 토요일에 했고, 2004년에는
LLWeekend로 주말에 이틀간 했고, 올해는 LLDay&Night로 해서
낮과 늦은 밤까지 한 것 같습니다. 낮에는 아카데믹하게,
밤에는 축제적인 요소를 가미했다는군요. 대안언어축제도
1박을 하는 바람에 예산이 걷잡을 수 없이 엄청나게 불어난
것을 생각해 보면, 늦은 밤까지 해버리는 것도 괜찮은 것 같습니다. 🙂

세션 구성

LLDN의 낮 세션에는 “아카데믹”을 정말 그대로 실현하기 위해서인지
각 언어별로 1개씩 세션을 빼곡히 채워놓았습니다. awk, curl,
gauche, haskell, ml, perl, php, python, ruby, squeak 모두 10개나 되네요. 대안언어축제에 비해서 확실히 다양성이 있는게 무척 부럽습니다. 그리고, 대안언어축제에서는 언어보다는
언어 독립적인 것들을 많이 발표 세션에 배치한 반면에, LLDN은
발표 세션은 모두 각 언어별로 배정이 되어 있군요.

독특한 세션 – 낮

발표 세션을 제외하고 독특한 포맷의 세션을 보자면, LLDN의
대표적인 두가지 “체제 대결”과 “너라면 어떻게 쓰겠니?”가 있네요.
“체제 대결”에서는 RoR, Kahua, Sledge 세가지 웹 프레임워크의
전문가들이 나와서 발표를 하고서 사회자의 진행으로 열띤 토론을
하는 것 같습니다. 대안언어축제에서도 사실은 원래 이런 걸
해 보고 싶었는데, 사람이 모자라다보니 못한게 좀 아쉽네요..
그리고, “너라면 어떻게 쓰겠니?”는 각 언어의 참가자들이
하나씩 규정연기와 자유연기 중 선택 또는 둘 다 시연을 하게되는데,
관중이나 다른 참가자들이 “너라면!” 상황에서 구현한 것을
서로 비교해보는 정말 살떨리게 재미있을 것 같은 세션일 것 같습니다. 🙂

독특한 세션 – 밤

그리고, 축제의 자리인 Night에서는 “안돼 자랑”, “데모 자랑”, “선물 대회”가 있는데,
“안돼 자랑”에서는 보통 금지되어 있는 흑마법들을 이렇게도 할 수 있다!
하면서 “으아아아~ 안돼~~~” 하는 거라고 합니다. 다른 언어 유져들에게는 숨겨온것들은 자진해서 얘기하자는 거라는군요.. (설명해 주신 미쓰님 감사!) 그리고, “데모 자랑”에서는 백문이불여일견으로 자기가 자기 언어나 툴킷/프레임워크에서 자랑하고 싶은 것을 나와서 보여주고 다른 사람들이 “우와~~” 해주는 행사라고 합니다.
역시 재미있을 것 같습니다. 하아~

대안언어축제와는..

LLDN은 대안언어축제와 매우 유사한 주제를 다루고 있음에도 불구하고
매우 다른 형식과 규모, 조직성을 갖고 있다는 점에서 서로 배우거나 가르쳐줄 것이 많은 사이인 것 같네요. 대안언어축제의 코드레이스, 야외활동, 로제타카드는 정말 자랑할 만 한데요.. ^^
그리고, 아무래도 LLDN은 사람 수가 너무 많고 장소가 강의용 장소라서 페어나 실습은 크게 못해보는 것 같네요.

LLDN 홈페이지에 올라와 있는 블로그 트랙백을 보면 참가자들 수십명이 자기 블로그에 글을 쓰고 트랙백 보내는 걸 보면 참 부럽습니다. 우리도 내년엔! 우후훗.;

하나 희망적인 것은 LLDN은 참가자가 수백명인데 여성참가자가 한명도 없었다는군요.. (그래서 그런지 LLDN 홈페이지를 보면 페이지 마다 의미없는 여성 모델이 나오는 이미지 컷이 -_-;;)

(그런데, LLDN 블로그 소프트웨어가 OpenLook과 같은 coreblog라서 매우 반갑습니다. 크크 _-_)