혜식이의 열고 보는 세상
얼마전에 예고되었던 대로, 드디어 CPython의 컴파일러가 AST
기반으로 교체되었습니다. AST 파서는 거의 Perl6처럼 오랫동안
허풍웨어같은 척을 하고 있었지만, 올해 들어서 활발한 개발자들의
작업으로 거의 완성 단계에 이르러 드디어 메인 브랜치로 들어오게
되었습니다. 🙂
AST의 주요 개발자 중의 하나인 Neal의 설명에 따르면, AST를 사용하게 되면 Jython과 문법 정의 부분을 공유하기 때문에, 새로운 문법을 적용하는 경우에 전에 비해서 훨씬 간단해 진다고 합니다. 그리고, 원래 쓰던 파서/컴파일러에 비해서 구조화가 잘 되어 있기 때문에,
앞으로 최적화나 새로운 기능을 넣을 경우에 구조 때문에 고생하는
것이 많이 줄어들 것이라고 하네요.
우선은 속도상으로는 직접적인 이득은 없지만, 앞으로 뭔가 대단한 일이 일어날 것 같아서 기분이 상큼합니다. ^_^;
오늘은 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 때는 그래서 리뷰에 리뷰를 거쳐서 깔끔하게 올렸더니 첫인상이 좋았던지 단번에 반응이 꽤 좋았던 것이.. 첫인상의 중요성을.. 🙂
yser님의 다음 질문에 대한 답변입니다.
퍼키님이 내부에서 쓴다는 코딩 정책을 읽어 봤습니다.
퍼키님은 스페이스 신봉자이신 듯 한데, 처음 소스 짤 때부터 스페이스로 하셨나요? 저는 요즘 탭으로 하던 버릇을 소프트 탭=공백 치환으로 바꿔야 할까 고민 중입니다. kldp 의 논쟁이나 다른 데서 비교하는 걸 봐도 결국은 취향 문제 아닌가 하는데 장단점이야 다 있는지라 어느 하나가 절대적으로 우세하다고는 못하겠더군요.
답
제가 쓴 그 코딩 정책은 회사에서 쓰는 것이기 때문에, 개인적인 선호와 전혀 상관이 없는 것은 아니지만 그대로 반영하는 것은 아닙니다. 그리고 한 프로젝트에 대한 것이기 때문에 C 코드나 Win32 API를 쓰는 C++코드, 본셸 코드 같은 것은 명시하지 않았구요. 그냥 그런 것도 쓴 적이 있더라.. 정도로 보시면 되겠습니다.
들여쓰기를 할 때 탭을 쓰느냐 스페이스를 쓰느냐에 대한 제 의견은 “환경에 가장 맞는 것을 써야 한다”는 것입니다. POSIX 환경에서 주로 편집이 이뤄지고 셸에서 많은 작업이 있어야 하는 경우에는 당연히 탭의 크기는 8이기 때문에, 인덴트를 스페이스로 합니다. 주의하실 점은 탭 크기와 인덴트 크기는 의미가 다르다는 것입니다. 탭 크기는 ‘\t’ 아스키 문자의 화면 표시상의 크기를 뜻하는 것이고, 인덴트 크기는 들여쓰는 단위를 뜻하지요. 따라서, 8칸씩 띄어서 쓰기에는 너무 크기 때문에 보통 4칸 들여쓰기를 하기 위해서는 스페이스를 쓰는 방법 밖에 없습니다. ts=8 sts=4 noet 즉, 인덴트는 4칸으로 하면서 가급적이면 탭을 쓰기는 쓰는 방법도 영 안 쓰이는 방법은 아니지만, 이런 경우에는 정규식으로 소스코드 치환하기가 매우 까다로워지기 때문에, 가급적이면 탭 크기와 인덴트 크기가 다를 때는 스페이스로 풀어쓰는 것이 좋겠습니다.
반면에, 대부분의 사용자들이 쓰는 편집기가 탭 크기를 4로 쓰고 있는 MSVS같은 IDE를 기반으로 하는 환경에서는 탭이 4이고, 스마트 백스페이스같은 기능이 지원되지 않기 때문에 탭 1개로 들여쓰기를 하며 4칸으로 쓰는 것이 좋습니다. MSVS에서 물론 탭을 스페이스로 풀어쓰기를 지원하기는 하지만, 해당 설정이 프로젝트에 저장되는 게 아니라, 설치된 컴퓨터의 레지스트리에 저장되기 때문에, 해당 기능을 설정하지 않은 개발자들과 혼선이 빚어질 수도 있기 때문이죠.
그리고, 만약 자기가 새로 만든 프로젝트가 아니라, 기존에 있는 프로젝트에 참여하는 것이라면, 당연히 그 프로젝트에서 원래 쓰고 있는 스타일을 따라가는 것이 맞습니다. 명시적으로 프로젝트에서 쓰는 스타일을 문서화를 한 경우라면 가장 좋겠지만, 문서가 없더라도, 남의 소스를 고칠 때는 비슷한 다른 부분을 찾아서 누가 만든 것인지 구분이 안 갈 정도로 같은 스타일로 맞춰 주는 것이 좋습니다. 구분이 확연히 간다면, 해당 부분에서 나중에 문제가 발생하게 되면 다른 사람들은 그 코드가 자기 코드가 아니라는 생각이 먼저 들게되고, 그쪽 코드 문제가 아니더라도, 분노 게이지가 꽉 차서 결국은 버그는 안 잡고 버그 트래커에서 싸움질만 하게 되겠죠. 누구 코드인지 구분을 못 하게 돼버리면 모든 소스는 공동 재산과 같은 성격을 띄게 돼서, 너의 버그가 나의 버그이고 나의 버그도 너의 버그이고.. 이런 상태가 돼서, 모두가 생산적으로 일할 수 있게 됩니다. 🙂 (굳이 svn blame 같은 기능 써가면서 추적해서 욕하는 사람을 만나면 잘 기억해 뒀다가 다음에는 같이 프로젝트를 안 하도록 잘 피해 보세요.)
결론적으로, 제가 쓰는 스타일은 이렇습니다. (vim 명령어로..)
=_=;;;;;;;;;;
토끼군과 퍼즐릿님의 활약으로 이제 국내에서도 꽤 뿌리를 내린
난해한 프로그래밍 언어계에 이제 마이크로소프트도 손을 내밀었습니다. 이름은 “요다”. 헬로월드는 이렇게 쓴다는 군요.
|
1 2 3 4 |
(args of string many are they) Main is what they seek yet return they do not. Brace you must Written it is, the Console. “Hello World” |
2004년 여름쯤에 파이썬 2.4가 릴리스되기 전에 collections 모듈에
타입이 1개 밖에 없는데 이름이 복수로 붙어서, 피보나치 힙을
넣자는 얘기가 있을 때 한 3주일 고민을 해서 피보나치 힙을 구현
했었습니다. 그런데, 피보나치 힙이 워낙 괴짜스러운 자료구조라서 복잡하고
편리한 것들을 추가하기에는 영 불편해서 결국은 그냥 중단했었습니다.
올해 초에는, 피보나치힙과 비슷한 용도에 사용할 수 있지만,
바이너리 트리의 특징을 유지하고 있기 때문에, 구현이 훨씬 쉬운
레드블랙 트리를 한번 구현을 해 볼까 생각을 했었습니다. 그런데~ 훈련소
다녀오고 나니까 머리가 안 돌아가서.. 이히히 ^_^;;
결국은 한참을 벼르던 레드블랙 트리 구현을 마침 숙제하기가
너무 귀찮기도 하고 파이썬 2.5도 곧 피쳐프리즈가 되지 않을까 해서 밀어넣어보려고 한번 집중해서 구현해 봤습니다. 기본적으로
제공되는 메쏘드는
아무래도 레드블랙트리나 피보나치힙류는 세션 테이블같이 정렬 순서에 따라서 빠르게 작업을 해야 하는 경우에 프리어러티 큐로 활용하는 것이 가장 대표적인 용례인데, 피보나치힙으로 구현을 한다면 순위를 뽑으려고 할 때 매번 extractmin을 해야하는 반면에, 레드블랙트리는 그냥 트리에서 돌아다니는 것으로 구할 수 있다는 것이 장점이라고 할 수 있겠습니다. (속도는 완전한 C 타입으로 구현하면 피보나치힙이 훨씬 빠르지만, 파이썬의 비교연산 특성상 파이썬 확장 모듈이 되면 별 차이가 안 납니다.)
소스는 오픈룩 trac 작업실안에도 있고, 소스포지 패치 리뷰 트래커에 Patch #1324770으로 올렸습니다. 이히히. 잘 돼서 파이썬 2.5에 들어가면 좋겠군요.
일반적인 오픈소스 프로젝트는 아무래도 여가시간에 자발적으로 참가하는만큼 프로젝트 진행 방향에 있어서 기업 프로젝트에서와 같이 “데드라인 엄수”, “최저 생산가”, “최고의 속도”, “가장 완벽한 인터페이스”가 아니라, 그저 “개발자의 재미”가 최고의 가치로 작용합니다. 완벽한 UI를 만들면 재미있는 개발자들은 완벽한 UI를 만들고, 표준을 완벽하게 엄수하는 것으로 재미를 느끼는 개발자들은 표준을 어기는 코드가 있으면 길이길이 날뛰면서 표준에 맞게 고쳐서 패치를 내겠지요. (토끼군처럼 남이 못 알아보도록 짜는 것에 재미를 느낄 수도 있고.. =3=3) 재미가 오픈소스 프로젝트의 가장 큰 요소인 것은 너무나 당연함에도 불구하고, 그동안 정부의 오픈소스 정책이나, 오픈소스를 추종하는 사용자들, 체계적인 체제를 갖추지 않은 오픈소스 프로젝트 들에서는 많이 간과되어 왔습니다.
최근 《재미와 소프트웨어 개발》이라는 논문이 나왔습니다. 이 논문에서는 주로 오픈소스 프로젝트들을 예를 들어서, 개발자들에게 개발의 재미를 주는 요소들과, 프로젝트 생산성, 창의성의 관계에 대해서 살펴보고 있습니다. 작업의 명료성, 재미, 충동, 주의, 집중 등이 프로젝트 결과에 영향을 주는 요소로 재미있게 분석되어 있습니다. 🙂
Haskell로 구현된 Perl6 프로젝트인 pugs 개발자가 쓴 O’Reilly 기사에서 얘기하고 있는 pugs의 -Ofun 성공 비결은 이렇게 요약하고 있습니다. (각 조건의 설명은 원문을 참조하세요.)
기업이 투자하는 것이 아니라면, 오픈소스 프로젝트가 성공하기 위해서는 리더들은 무엇이 개발자들에게 개발 동기를 유발하는가를 고려하여 그 점들을 자극할 수 있는 무언가를 충분히 재공해 줘야할 듯 합니다. 주변의 예만 보더라도, FreeBSD의 버그 트래킹 시스템인 GNATS는 웹에서 접근할 수 있는 개발자 리소스가 제한되어 있기에, 버그 트래킹 시스템에 접근하려면 ssh로 중앙 서버에 접속해야하고, 그 과정이 미미하지만 동기 요소를 떨어뜨리는 요소로 작용하게 마련입니다. 그래서 FreeBSD 버그 트래킹 시스템에서는 유난히 오래된 버그들이 많고 개발자들이 할당만 해놓고 거들떠보지도 않는 경우가 많습니다. 또한, 코드를 직접 커밋해서 다른 사람들이 리뷰할 수 있는 경우와, 최근 CVS로 업데이트한 다음에, diff를 떠서, 복잡하게 버그 트래킹 시스템에 올린 다음에, 커미터에게 리뷰를 받아서 다시 또 설명을 한 다음에 결국 한참 있다가 커밋되는 것과는 피드백의 시간에 있어서 동기 유발에 큰 차이를 보이겠지요.
그나저나, 저 오라일리 글의 “bus error” 표현은 아주 재미있군요. 이히히히~
Worse yet, a “bus error” (a key person being hit by a bus) may stall the project for good.
10월 29일에 개최될 예정인 Hello FreeBSD 세미나에서 발표할 자료를 만들었습니다.
웹에 떠돌아다니는 여러 프리젠테이션들과 머리 속에 흩어져 있는
정보를 참고로 하여 극히 일부만~ 으흐흐
제가 주최하는 행사가 아니라, 구체적으로 어떤 형식으로 진행될 지는 잘 모르겠지만, FreeBSD관련 행사가 정말 오랜만에 있는 것이니만큼 FreeBSD에 관심 있는 분들이 많이 오셨으면 좋겠습니다.
그동안 많은 행사가 개발자 중심의 세미나였던 반면에 이 세미나는 내용을 봐서는 SE들을 위한 행사인 것 같네요~
학생이 되니까 들고다녀야하는 장비의 종류가 꽤 다르군요. 흐흐. 이제 슬슬 중도에 하루 종일 있어도 그다지 불편하지 않은 단계가 되었습니다. 아하하;;
계산기
예전에 EL-5120을 썼었는데, 물리랑 화학 외에는 앞으로 쓸 일없겠지 하고 누구 빌려준 다음에 누구한테 빌려줬는지 까먹어서 결국은 새로 샀습니다. -.-; 옛날보다 가격이 많이 내렸군요.. 한동안 계산기가 없어서 전화기로 rath님의 hanirc 프로그램을 띄워가지고 IRC에 들어가서 IRC봇한테 파이썬 명령을 내려서 계산했었는데, 하나 계산하려면 2~3분씩 타이핑하느라 고생;; 그래서 결국은 큰맘먹고 새로 계산기를.. 흑흑. log랑 실수 제곱만 제공되면 전자사전에 들어있는 계산기 써도 되는데 아쉽네용.
타이머
저는 시간을 무척 비효율적으로 쓰는데, 막 뭔가 하나 잡으면 딴짓하느라 시간가는지도 모르고 2~3시간이 훌쩍 흘러버립니다. 으흐흐.. 그래서, 이번 학기는 꼭 멋지게 시간을 보내 보고자 승범이가 쓰던 타이머와 같은 모델을 사서, 뭘 해도 시간을 정해놓고 하고 있습니다. 아하하. 특히 제일 좋을 때는 10분만 자야지 하고 타이머를 쥐고 자고 있으면 아주 -.-b _-_ 그리고 공부에 너무 빠져 들어서 밥먹는 것 잊어버리는 상황을 피할 때도 좋습니다. (괜히 걱정해 본다;;;;)
전자사전
흐흐 모르는 단어가 왜 이리 많은지.. 벌써 단어장에 단어가 100개를 넘었습니다. 흑. 단어장 기능 정말 좋군요. 🙂 전자사전에 공학용계산기 기능이 없다는게 가장 아쉽군요. 넣을 만도 한데 계산기 팔려고 안 넣었나…
