오늘은 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 때는 그래서 리뷰에 리뷰를 거쳐서 깔끔하게 올렸더니 첫인상이 좋았던지 단번에 반응이 꽤 좋았던 것이.. 첫인상의 중요성을.. 🙂
