Michael Ogawa의 code_swarm이라는 프로젝트에서 오픈소스 프로젝트의 CVS나 SVN 등 소스 저장고를 분석해서 일어난 작업들을 시각적으로 보여주는 걸 만들었습니다. 요새 UbiGraph같은 도구도 나오고 하는 걸 보면 시각화가 정말 굉장히 유행이네요~
code_swarm - Python from Michael Ogawa on Vimeo.
저는 3분 50초 쯤에 약간 왼쪽 아래에서 나타나서 잠시 머물다가 사라집니다;;; -ㅇ-;;;;;
이 영상은 미디어아트와 데이터 시각화에서 많은 관심을 모았던 Processing으로 만들었다고 하는데.. 전에 봤을 때는 괜히 어렵기만 하고 별 쓸모 없어보니더니 이걸 보니 확 땡기는군요. ^^;;
-- via Python Daily URL
예전에 올렸던 우리말 도우미를 한동안 잊고 있었는데 불여우 3.0 지뢰밭 출시가 임박해서 많은 분이 요청해 주셔서 3.0 용으로 갱신했습니다.
3.0 지원 외에는 아주 사소한 레이아웃 관련 변경이 몇 개 있었지만 별로 눈에 안 띌 것 같네요 -ㅇ-;
아직 모래통 안에 들어 있어서 쉽게 설치가 안 되고, 사이트에 로그인해야지만 됩니다. 므흐흐.. 언젠가는 모래통을 탈출하여 쉽게 설치할 수 있는 날이 오겠죠. -ㅇ-;
이번 업데이트에 큰 도움을 주신 신종훈님께 감사드립니다.
며칠 전에 올렸던 "내 이름 어때?"를 만들면서 썼던 여러 가지 기술적인 부분에 대해서 간단하게 정리해 봅니다. 물론 django로 만들었습니다! 이히히
이름 뒤에 은/는 이/가 같은 것들을 제대로 붙이려면 아무래도 템플릿에서 처리를 해 줘야하는데, django에서는 애플리케이션에서 직접 템플릿 태그나 필터를 정의하는 걸 매우 장려하는 분위기라서 "필터"를 따로 정의해서 처리했습니다.
템플릿에서 이렇게 쓰려고 하는 부분이 있다면:
이름을 뒤집으면 {{ rev_last_name|attach_korean_suffix:"이가" }} 되어서..
필터 정의를 이렇게 해 줬습니다.
@register.filter def attach_korean_suffix(string, suffixes): if hangul.ishangul(string[-1]) and hangul.split(string[-1])[2]: return suffixes[0] else: return suffixes[1:]
마지막 줄에서 1:로 굳이 잡아준 이유는 이름 뒤의 ~이 처럼 받침이 없으면 끝에 안 붙는 경우도 처리해 주려고요..
이름의 인기가 늘고 있는지 줄어드는지를 글자로 판단해서 표현해 주기 위해서, 간단한 계산식을 사용했습니다. 우선 원 데이터 자체는 샘플수가 적어서 노이즈가 많기 때문에 보통 많이 쓰이는 9개 윈도우 평균으로 했고, 이렇게 하면 18개 포인트가 나와서 세 부분으로 나눠서 앞 중간 뒤의 평균을 다시 구해서 3가지 값이 나왔습니다. 그래서 눈으로 딱 보면 값이 계속 증가하는지, 올라갔다 내려갔다 하는지를 볼 수 있는데요, 그냥 값으로 볼 수는 없으니 앞/중간 과 중간/뒤의 각각의 변동폭을 0에서 1사이로 정량화해서 봤습니다. 변동폭은 이름마다 절대량이 다르기 때문에 상대량으로 비교해야해서 아래와 같은 식으로 썼습니다.
보기엔 약간 쓸데없이 복잡하긴 하지만, 그냥 상대비율을 (0, 1) 사이로 넣어주는 일 밖에 안 합니다;;;
이렇게 나온 값으로 앞 뒤가 모두 (0.4, 0.6) 구간에 들어오면 "꾸준한 추세입니다."라고 하거나, 앞-중간은 (0.0, 0.3), 중간-뒤는 (0.0, 0.5) 구간에 들어가면 앞 반쪽에서 감소세가 강하고 뒷 반쪽에서 감소세가 둔하다는 의미이므로 "확 줄어들다가 잦아드는 추세입니다."라고 보여주는 식으로 주된 패턴들을 "대충" 느낌으로 나열하는 방법으로 코딩했습니다. 크흐;
이름 전체의 성별 성향이나 이름의 시대적 경향, 이름 글자의 시대적 경향을 보이는 부분에서 구글 차트를 불러서 사용했습니다. 구글 차트는 직접 URL을 코딩하는 방법은 아니고, pygooglechart를 사용했는데요, 이게 의외로 그런대로 잘 만들어서 웬만한 기능은 불편없이 쓸 수 있게 돼 있더군요. :)
다만, 하나 기술적인 문제가 있었던 부분은 이름 글자의 시대적 경향 같은 경우에는 글자마다 실수값 18개씩(경향)이 저장돼야 하기 때문에, 이걸 그냥 저장하는 건 여러모로 번거롭고 해서 구글 차트 API에서 쓰는 0~4095 사이 인코딩하는 방법으로 썼습니다. (base64와 거의 같은 방법입니다.) 그래서, 저장은 바로 구글 차트 API URL에 쓰면 되는 형태가 돼서 다시 불러올 때 매우 빠르게 불러올 수 있긴 한데, 문제는 한 이름 안에 이름 앞자와 뒷자의 경향을 모두 보여줘야하기 때문에 둘의 그래프 크기를 제대로 조절해 주지 않으면 각 글자의 크기가 잘못 나온다는 점이었습니다.
그래서 결국 선택한 방법은 보여줄 때 앞자 뒷자 인코딩된 값을 다시 풀어서 큰 쪽의 스케일로 맞춘 다음에 다시 인코딩하는 -.,-; 약간 노가다성 방법을 썼습니다. 역시 이런 부분은 numpy의 array의 도움을 많이 받을 수 있었습니다.
확장코드 인코딩/디코딩 부분을 따로 떼서 쓸 일이 좀 있을 것 같아서..
encmap = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-.' decmap = [(encmap.index(chr(c)) if chr(c) in encmap else 0) for c in range(128)] def decode_ggenc(encoded): return [decmap[ord(hi)] * 64 + decmap[ord(lo)] for hi, lo in zip(encoded[::2], encoded[1::2])] def encode_ggenc(data): return ''.join(encmap[int(v//64)]+encmap[v%64] for v in data)
역시 통계 샘플 크기가 작아서 주요 이름들을 빼고는 제대로 된 통계치를 낼 수 없어서 주요 이름들의 성별 경향으로 학습한 걸로 예측하는 부분이 필요했습니다. 이번에는 아예 사용된 적 없는 글자까지도 어떻게 좀 해 보려고 통계치에 전혀 의존하지 않고 그냥 자소별로 분해해서 이름만 피처로 사용하기로 했습니다. 그래서 보통 SVM을 쓰는 것이 여러모로 대세이기는 하지만, 카테고리성(이산) 피처값에 매우 유리한 random forest을 썼습니다. (물론 제가 수학을 워낙 못하는 것도 큰 요인으로;;;;)
Random forest는 아무래도 쓸 수 있는 구현이 적다는 게 큰 문제인데요. 파이썬에서 쓸 수 있는 orange를 쓰면 정말 좋겠지만, 아쉽게도 이 구현은 리그레션은 지원하지 않고요. Y.Y R용 패키지인 party와 randomForest 중에 선택해야하는데, party를 먼저 했으나 메모리 3기가를 먹더니 죽었고 (-_-) randomForest는 안정적으로 대략 200메가 정도 먹고 그런대로 쓸 만한 결과를 줬습니다. :)
학습 기법 측면에서는 남자 샘플이 2배 정도 되기 때문에 편향 문제가 있어서 샘플링 조절을 좀 해야했는데요, 그냥 복잡한 것 쓰지 않고 대략 0.3 밑을 반 다운 샘플링하니까 전체적으로 분포가 윗쪽하고 아랫쪽이 그런대로 맞았습니다. 중성적인 이름이 수가 훨씬 적은 것도 또한 중성적 이름 쪽에서 오차를 많이 발생시킬 수 있는 요인이 될 수 있는데, 이쪽에서 오버샘플링을 하려고 하다가 "될 거 같으면 대충해도 돼야 하는거지" 하는 교수님 말씀이 귓가를 스치며 놀이인데 대충하자 하고 -ㅇ-;; 크흐; 그래서 결국 10-fold cross validation으로 평균 피어슨 연관성이 0.97 정도 나왔습니다. (만... 역시 사람 느낌하고 좀 다른 사례가 개별적으로는 제법 많이 발견되긴 하네요;)
서비스를 공개한 다음 날 점심시간이 좀 지나고 나서는 접속이 폭주해서, 실시간 계산이 상당히 있었던 구현 특성상 앞으로 어떻게 될 지 참 고민이 있었는데요; 그래서 마침 전혀 필요없겠다 싶어서 꺼놨던 django의 캐시 프레임워크를 살려서 해 봤습니다. 백엔드를 선택할 수 있는데, 역시 제일 잘 나가는 memcached를 썼습니다. 이거 소문대로 깔끔하고 잘 돌아가네요. ^_^;
Django는 다행히도 템플릿에서 일부만 특정 변수에 따라서 캐시하는 기능이 있어서 이름에 따라 바뀌는 부분, 성에 따라 바뀌는 부분을 따로 따로 캐시하도록 3조각으로 따로 캐시해서 생각보다 훨씬 간단하게 쉽게 캐시로 넣었고요, 지금은 CPU부하가 전보다 같은 요청에서 거의 1/10로 줄어들었습니다! 이히히.
몇 분께서 물어보셨던 게 자료처리나 통계처리는 어떤 걸 썼느냐가 있는데, 특별히 쓴 것은 없구요, 파이썬 하나면 다 해결됩니다. -ㅇ-; 물론 numpy, matplotlib도 아주 큰 도움이 됐습니다. collections.defaultdict를 전에는 그렇게 자주 쓰지는 않았는데, 이번에 좀 과격하게 3~4 단계 쑥쑥 defaultdict를 겹쳐서도 써 봤더니 pickle이 잘 안 되는 문제만 빼고는, 코드를 아주 많이 줄여준다는 점에서 아주 사랑스러웠습니다.
후속편으로는 이번에 들어온 로그를 한 번 분석해 보려고 하고 있습니다. ^^;
요즘 인터넷에서 단백질을 접는 게임 fold.it이 아주 인기입니다. 단백질 접기(protein folding)는 구조생물정보학의 가장 큰 문제이기도 하지만, 제가 있는 연구실의 주요 주제이기도 해서, 단백질 접기에 관한 몇 가지 얘기를 해 볼까 합니다. :)
단백질은 생물을 구성하는 주요 분자구조 중의 하나인데, 20가지 아미노산이 일렬로 실처럼 쭉 연결되는 것이 기본 구조입니다. (현재 22번째 자연계 아미노산까지 발견되긴 했지만 사람은 20개만 사용하고 있습니다.) 20가지면 컴쟁이가 생각하기에 바로 생각할 수 있는게 알파벳으로 커버하고 남는다 그거죠. 그래서 실제로 아미노산은 알파벳으로 표시하고 있는데 각각의 이름을 따서 BJOUXZ 여섯개를 빼고 나머지로 표현하는 문자열로 많이 씁니다.
그런데, 각 아미노산은 성질이 있어서 자기들끼리 모이려고 하는 것도 있고, 서로 떨어지려고 하는 것도 있고 크기가 커서 부딪히지 않으려고 하는 것도 있고, 기타 등등 여러 성질이 있어서 안정적인 몇 가지 기본적인 구조(나선형, 판형 등..)을 지역적으로 이루는데, 이걸 2차구조라고 부릅니다.
역시 인간관계도 상당히 복잡하듯, 2차구조를 이룬 다음에도 자기들끼리 꼬이면 그나마 남은 관계까지도 복잡하게 얽여서 굉장히 안정적인 구조를 만들 수 있는데요, 이렇게 모인 것을 3차구조라고 부릅니다. 그리고 여러 단백질 가닥이 모여서 큰 단백질을 만들면 4차구조라고 부릅니다.
단백질은 생화학적 작용의 가장 기본적이고 유용한 분자이기 때문에, 생화학 작용에서 단백질을 빼면 거의 남는게 없습니다. 물론 핵산이나 탄수화물 등도 매우 중요하긴 하지만, 생화학 회로를 그린다 하면 거의 대부분 단백질이 주인공이죠. 그런데, 단백질이 상대를 만나서 반응을 하는 기준이 대부분 단백질에 있는 구멍의 특정 모양이나 아미노산들이 배치된 패턴과 상대의 특징들 같이 단백질과 생분자간의 모든 관계가 구조를 빼면 설명하기 힘듭니다.
그래서 단백질의 구조를 밝히는 것이 분자생물학, 세포생물학의 기본 원리를 밝히는 데 뿐만 아니라, 새로운 단백질을 디자인하고 약을 만드는 데 매우 중요한 도구입니다. 90년대 말의 히트작 항암제인 글리벡도 구조를 연구해서 기막히게 구멍을 메우는 약이죠.
웬만하면 구조는 그냥 현미경으로 보면 가장 좋겠죠. 그런데, 단백질은 빛의 파장보다 짧은 구조를 하고 있기 때문에, 가시광선으로는 볼 수 없어서 현미경으로 볼 수 없고, 전자현미경이나 다른 원리를 쓰는 현미경들도 (적어도 아직은) 단백질 구조까지 보기에는 한참 힘듭니다. 그래서 사용하는 것이 일반인들에게 MRI로 유명한 NMR과 X레이 구조결정 두 가지 방법이 쓰이는데요, 보통 X레이가 여러 이유로 더 많이 쓰입니다.
X레이로 그냥 다 찍으면 보이면 좋은데, 이게 결정을 만들어야하다보니, 같은 분자를 다량 정제하는 것도 힘들고 결정으로 만들기도 힘든 고분자를 결정으로 만드는 것도 상당히 경우에 따라 다른 기술이 필요합니다. 그래서, 대량으로 찍고 싶다고 다 나온다기 보다는 관심이 많은 단백질들의 구조에 집중되어 있는 편입니다. 또한, 단백질 구조가 항상 같은게 아니라 꿈틀꿈틀 움직이기도 하고 아예 훽훽 움직이기도 하는데 그 움직임이 중요한 경우도 있어서 원하는 걸 다 얻기도 힘들고, 막 사이에 끼여있는 단백질 같은 경우엔 아예 원래 구조로 결정으로 만드는게 너무너무너무 힘들어서 지금까지 찍힌 것이 손으로 꼽을 정도가 되기도 합니다.
그래서 하는 것이 컴퓨터를 이용한 구조 예측입니다. 기본적으로 원자의 움직임은 물리역학적 특성을 따르기 때문에, 움직임이나 안정적 구조를 컴퓨터로 당연히 이론적으로 예측할 수 있습니다. 대표적으로 사용되는 방법은 분자동역학 시뮬레이션이나 몬테카를로 같은 것들을 쓰는데, 전자의 경우에는 계산량이 엄청나게 많아서 수십나노초(ns)가 넘으면 예측이 거의 불가능해집니다. 그리고 몬테카를로법이나 다른 변종들도 한계가 있습니다. (시작점을 잡기 위한 방법이나 지속적인 움직임을 보기 위한 다른 방법을 도입할 필요가 있죠.)
그 결과 결국 구조 예측의 주축은, 유사성 모델링이 되었는데, 기존의 비슷한 단백질의 구조를 가져다가 여기 저기 비슷한 부분을 잘라 붙인 다음에, 그걸 기존 방법으로 에너지 안정화 시뮬레이션을 좀 거치는 방법입니다. 기존 단백질 구조를 이용해서 완전 바닥이 아니라 벌써 한참 진행된 것을 가지고 하기 때문에 아주 효율적이고 비교적 정확한 결과를 얻을 수 있지만, 기존의 비슷한 단백질이 없으면 구조를 예측하지 못하는 한계가 있습니다. 그렇지만, 데이터베이스가 점점 커져서, 최근에는 단백질 예측에서 유사성을 이용하지 않는 것은 상상할 수 없을 정도가 되었고 데이터베이스 크기가 예측의 품질과 매우 밀접한 관계를 가지게 되었습니다.
이렇게 단백질 구조 예측이란게 아주 정의가 잘 된 계산 문제가 되다보니, 그 다음에 당연히 나올 수 있는 것은 초밥만들기 대회처럼 세계대회가 생기는 것이겠죠. 그 중 가장 큰 것은 단연 CASP입니다. 1994년부터 격년으로 하고 있는데 올해 대회는 얼마 전에 참가접수가 끝나고, 지금 한참 대회가 진행 중입니다.
요즘 유행하는 fold.it도 이 구조 예측 대회를 타겟으로 나온 것인데, fold.it을 만든 워싱턴대학(시애틀) 생화학과의 David Baker 연구실은 한동안 CASP을 휩쓸었던 먼치킨 그룹입니다. 여기는 애플과 비슷한 점이 많은데, 남들이 다 뻔히 될 것 같다고 생각하고는 있지만 실제로는 여러 이유로 안 해보는 것들을 아주 기발하고 멋진 해결책을 들고서 짠! 하고 만들어서 그걸로 굉장한 결과물을 만들어냅니다. 유사성 모델링에서 에너지 계산방법도 그렇고, 구조 데이터베이스 탐색법, 분산계산(Rosetta@Home)등 여러 가지가 그런데요, 이번에 fold.it도 종종 컨퍼런스에서 구조는 역시 사람이 보고 끼워맞추는게 최고다 그런 농담이 자주 나오는 걸 진짜로 게임으로 만들어서 수만명이 달려들게 만들어버렸습니다.
-ㅇ-; 그 결과 지금 fold.it에 슬슬 CASP문제가 나오기 시작했고, 올해 CASP 문제를 게임에서 수만명 플레이어가 여러가지를 아직 알고리즘으로 나오지도 않은 여러 직관을 써서 풀어놓으면 거기서 나온 구조로 CASP 답안으로 제출한다고 합니다. 물론 컴퓨터로 찾는 것 보다 완전 샅샅히 뒤지는 것은 안 되겠지만, 그래도 사람의 직관이 수만명이 모이면 그 힘이 어떻게 될 지는 상상도 안 가네요. 아마도 상당히 상위권에 들어갈 수 있지 않을까 싶습니다.
많은 분들이 물어보셔서 덧붙이자면, 게임 안에서 쓰이는 용어는 모두 실제 생물학에서 사용하는 용어이고, 구조에 큰 영향을 주는 요소들은 상당 부분이 게임 안에서 자세히 표현되어 있습니다.
직관으로 풀면 훨씬 간단한 NP-hard 문제들을 재미있는 퍼즐로만 만들 수 있다면 이렇게 잘 표현한 게임으로 만드는게 수천개 CPU 동원한 클러스터보다 효율적일 수도 있을 것 같습니다. 단백질 구조 외에도 계통 분류 최적화나 RNA 구조, 단백질-단백질/라이간드 도킹 예측/디자인, 단백질 유도 진화 등 재미있는 게 많이 있을 것 같은데 게임으로 과연 만들 수 있을지는 모르겠네요. ㅎㅎ;
예전에 블로그에서 알려드린 적 있는 생활 속의 프로그래밍 동영상이 얼마 전에 올라왔습니다. 이미 보신 분도 계시겠지만, 기록의 의미로 여기도 하나 링크해 둡니다. :)
생활 속의 프로그래밍은 프로그래밍으로 먹고 사는 분들이 일상 생활에서 프로그래밍을 활용해서 재미도 있고 편하기도 하고 배울 것도 있는 여러 놀이를 떠올리는 계기가 되게 제가 그동안 오픈룩에서 썼던 여러 사례들을 소개해 드리는 세션이었습니다. 오픈마루 WoC 스노우캠프와 NHN 네이버토크에서 따로 2번 진행했었는데, 둘 다 비디오 촬영은 되었지만 오픈마루 WoC 것은 아직 공개되지 않았고, NHN 것이 얼마 전에 공개되었습니다.
화면이 잘 안 보이는 편이니, 발표자료를 따로 받아서 보시면 잘 보일 것 같습니다~
사실 제가 말이 좀 느리고 중언부언하는 경향이 있어서 3배속으로 보면 딱 맞을 것 같긴 한데, 아쉽게도 속도 조절은 못 하는군요 -ㅇ-;
어제 스퀵 캠프에서 카즈히로 아베 (阿部 和広)씨를 만났는데, 보여주신 OLPC에 파이썬이 있다길래, 확인해 보니까 코덱도 빠지지 않고 소스로 다 들어가 있군요. 이히히. 반가워서 사진 한 장!
ps. 창준형, 승범이, 나부군님, 이지님, 테라님, 표님 모두 반가웠어요!
엊그제 올렸던 WoC snow camp 얘기는 행사를 주최하는 곳에서 WoC참가 학생을 위한 행사라 장소가 좁아서 일반인은 참가할 수 없다고 알려왔습니다.
제가 미처 확인을 못 하고 알려드려서 죄송하네요~ "생활 속의 프로그래밍" 주제는 앞으로 많은 분들이 참여하실 수 있는 좋은 행사에서 준비가 되면 그 때 다시 알려드리겠습니다. :)
이번 주 토요일(23일) 도곡동 IBM본사에서 WoC snow camp가 있습니다. 저는 "생활 속의 프로그래밍"을 주제로 발표할 예정인데, 아직 구체적인 시간은 결정되지 않은 것 같네요.
이번에는 일상생활 속에서 작은 프로그램들을 활용해서 재미나게 프로그래밍도 즐기고~ 삶도 재미있게 사는 방법을 여러 예를 통해서 보여드릴 예정입니다. 예제는 물론 뭐 긴급하게 새로 다 만들 수 없으니 제 블로그에 지난 몇 년간 올라왔던 글들이 재활용될 예정입니다;; 1시간 안에 제 블로그 전체(?)를 읽으시는 효과를 보실 수 있을지도! -ㅇ-; (뻥을 쳐 본다;)
발표자료는 발표 후에 공개하겠습니다. (참고로 저는 발표자료에는 중요한 내용은 안 적는 경향이 있으니 발표자료만 봐서는 알아보실 수 없을 수도 있습니다. =3)
글도 별로 없는 블로그에 광고를 해서 무척 죄송합니다. -ㅇ-; 그래도 곧 번개 소식이 약간 가미되어 있으니 정보가 되지 않을까 하고 예쁘게 봐 주세요. :)
이번 주에 여름 기념으로 오랜만에 파이썬 마을 번개를 한번 할까합니다. 그냥 번개만 하면 썰렁하니까 Python 3000에 대한 얘기를 조금 하다가 밥먹고 뒷이야기를 하는 자리를 만들려고하는데, 우선 조용하게 모여서 얘기할 곳이 필요해서, 토즈 같은 모임 전용 공간을 쓸 수도 있겠지만 참가비를 안 받고도 할 수 있으려면 혹시 파이썬 마을 회원 분들 중에서 회사나 학교에서 공간을 빌릴 수 있는 분이 있으시다면 그 편이 편할 것 같아서 우선 공개적으로 한번 구해 봅니다.
공간은 20명 내외가 원형또는 사각형으로 모여서 얘기할 수 있는 곳이면 좋구요. 프로젝터를 사용할 수 있어야 합니다. 물론 많은 분들이 쉽게 모일 수 있어야 하기 때문에 되도록 서울에서 교통이 편리한 곳이면 좋겠습니다. 시간은 금요일 저녁이나 토요일 오후로 생각하고 있습니다.
참가신청은 장소에 따라서 시간이 정해진 후에 따로 파이썬 마을에서 받을 예정이니 우선은 장소 대여가 가능한 분 있으시면 알려주세요 ^^;
그동안 많은 분의 노력으로 드디어 OpenSSL에 SEED지원이 들어갔습니다! 와와~ 이제 모질라, 애플웹킷 등 OpenSSL에 지원이 없어서 못 한다고 기다리고 있던 수많은 프로그램들이 SEED를 지원할 수 있겠군요~
이번 패치는 전에 제가 올렸던 OpenSSL 패치가 들어간 것은 아니고, KISA에서 따로 작업한 패치를 KISA의 지원으로 OpenSSL 개발자가 수정한 것이 적용되었습니다. 사실 소스를 보시게 되면 KISA의 작업 과정 중에서 보통의 오픈소스 프로젝트의 관례에서는 어긋나는 이른바 "이름 지우고 소스 베껴오기"가 많이 적용된 흔적은 자명히 존재하긴 하지만, 그래도 제가 원래 올린 패치가 public domain으로 올렸던 것이기에 이름 지우기가 저작권 위반은 아니라는 것을 미리 알려 둡니다. :)
그렇지만 한편으로는 정부기관에서 오픈소스에서의 호환성 지원을 위해 오픈소스 프로젝트에 직접 노력하여 커밋을 재촉하고 실제 적용까지 유도한 사례가 나왔다는 측면에서 굉장히 고무되는 사건임에는 틀림이 없습니다~ :)
오늘 IRC에서 얘기하다가 생각나서 예전부터 있었던 정겨운 깨진 한글들 패턴 몇개를 모아서 소개해 봅니다. :)
占쏙옙占쏙옙!
주로 맥이나 emacs, gnome-terminal등등 유니코드 처리를 하긴 하는데, 설정을 뭔가 잘못했거나 제대로 못 처리한 경우에 자주 발생하는 놈입니다. 구글에서 검색하면 무려 1450000건이나 나옵니다. -ㅇ-; 가히 깨진 한글 중 최고봉..
이 녀석의 의미는 U+FFFD U+FFFD를 utf-8로 인코딩한 것을 euc-kr로 푼 것입니다. 디코드하는 녀석은 euc-kr을 바라고 있고, 인코딩하는 녀석은 뭔가 안에서 단단히 꼬인 경우죠. U+FFFD는 REPLACEMENT CHARACTER이라고, 뭔가 잘못되면 이걸로 글자 수를 유지하기 위해서 바꾸는 경우가 있습니다. 이 경우 대부분 보내는 놈이 잘못했다고 눈치를 챌 수 있습니다.
홰聆究셀
옛날에 PC통신 하시던 분들은 자주 보셨을 것 같은데, 이것도 지금 구글에서 검색하면 29900건이 나오는 상당히 인기깨진한글 입니다. 홰영구셀은 점쏙옙과는 달리 좌우로 물음표나 좀 불길한 표시가 곁들여진다는 특징이 있죠. :)
이 놈의 정체는 바로 euc-kr에서 "안녕하세요"에서 첫 바이트를 떼낸 것입니다. 안녕하세요는 문자열이나 각 줄의 맨 앞에 자주 와서 앞 글자가 잘리는 경우가 유독 많죠~
컴컴컴컴컴컴넴
요새는 컴컴컴컴컴이 나오면 좀 어색하겠지만, 옛날에는 동네 꼬마아이들도 컴컴컴컴을 보면 이게 바로 그거구나! 하고 정겨워할 정도였었죠~ 컴컴컴컴컴에는 옆에 넴이나 백백백, 낡낡이 곁들여 줘야 좀 더 맛이 납니다. 이 놈의 정체는 미국 영어 코드페이지인 cp437에서 좌우로 긋는 선문자입니다. 아직도 와레즈 그룹들은 cp437을 자주 쓰는 관계로 .nfo 파일들에서 컴컴컴컴을 만날 수 있어서 나름대로(?) 반갑습니다;;
이 녀석은 구글에서 검색이 되긴 하는데, 길이에 따라 따로 따로 인덱스되어 있어서 전체적인 수는 정확히 모르겠지만 대략 5000은 될 것 같네요.
덈뀗섏꽭 쩗꿇뀘
요놈은 고정적인 내용을 가지는 것은 아니고 대충 "띠리띠리"가 새끼손가락 콧구멍에 넣고 외계와 통신할 때 내는 소리로 깨지는 형태입니다. 이것도 어설픈 유니코드 프로그램에서 상당히 자주 볼 수 있죠. 이 놈의 정체는 utf-8 인코딩된 것을 cp949로 푼 것입니다. 주로 겹자음과 희한한 받침들이 오는데, 그 이유는 utf-8에서 쓰는 영역이 주로 두 번째 바이트에 0x81~0x9f를 많이 써서, 그 영역이 cp949에서 euc-kr에 추가로 배치한 자주 안 쓰이는 한글 영역과 겹치기 때문입니다.
)C>H3gGO
이것도 고정적인 내용은 아니고 그냥 형태입니다. 주로 대문자, 소문자, 기호 몇가지가 나오고 중간 중간 음표도 곁들여 주며 나오는 이 모양은 8비트를 모두 지원하지 않는 환경에서 EUC-KR에서의 상위 비트가 모두 날아간 놈입니다. 최근에는 볼 일이 거의 없지만, 예전에는 한국IBM같이 도미노 솔루션을 쓰던 곳에서 보낸 메일이 이런식으로 안 보이게 보여서 난감한 경우가 있었죠. 그리고, ISO-2022-KR로 인코드하고 나서 제어문자 필터링에 걸려서 제어문자가 유실되는 경우도 이렇게 됩니다.
¾È³çÇϼ¼¿ä~
아마도 가장 흔하게 많이 볼 수 있는 형태가 아닌가 싶네요~ 요건 EUC-KR을 ISO-8859로 보고 디코딩했을 때 발생하는 형태입니다. 즉, 한글 1글자가 EUC-KR에서 높은 2 바이트가 되기 때문에, ISO-8859에서의 추가 문자에 해당하는 것들이 2개씩 나오게 됩니다. 요건 그래도 ISO-8859-1이 256개 모두 할당되어 있어서 정보의 손실은 없어서 복구는 가능하기 때문에, 다른 것들에 비해서 그래도 준수한 편이라고 할 수 있겠죠. :)
켓아~
요놈은 대부분의 글자가 보이지만 일부가 고정적으로 다른 글자로 대체되는 형태입니다. 대표적으로 "횽아" -> "켓아"와 "아햏햏" -> "아쥑쥑" 이 있죠. 둘다 구글에서 검색해 보면 용례가 그렇게 많지는 않지만, 의외로 유닉스 프로그램들에서는 상당히 자주 겪는 패턴입니다. 이 경우는 인코딩이 euc-kr이라고 가정하고, 두 번째 바이트 글자의 하위 7비트만 보고 디코딩해서 생기는 문제입니다. cp949의 경우에는 두 번째 바이트에 MSB가 없는 경우가 있기 때문에, 구분해 줘야 글자를 제대로 판단할 수 있겠죠.
우선 생각나는 것은 써 봤는데, 그 외에 자주 봤던 깨진 한글 있으시면 알려주시면 추가하겠습니다. ^_^
애자일 이야기에 올라온 7월까지만 일한다면?이란 글을 읽다가, 인용한 그림을 보고 흠칫 놀랐습니다. 어디선가 많이 본 패턴이 보이는데, 으흠~~ 일을 적게하는 나라들에 유독 FreeBSD에서 굉장히 활동이 많은 국가들이 집중되어 있던 것입니다! 그래, 일을 적게 시켜야 뭘 하든 할 것이 아닌가 싶어서 과연 근무시간과 오픈소스 활동과의 상관 관계에 대해 조사를 해 봤습니다. 뭘 조사하느냐를 결정해야 하는데, 메일링리스트를 보는 것도 좋겠지만, 메일링 리스트는 언어의 제약이 굉장히 많이 작용할 것 같아서 FreeBSD의 PR 데이터베이스를 쓰기로 했습니다. 아무래도, 그냥 패치만 보내도 되고 비교적 짧게 적어도 되니까 꼭 올릴 사람들을 올릴 것 같아서~ :)
그래서, 모든 PR 자료를 cvsup으로 받은 다음에 로컬에서 간단하게 뒤져서 분석했습니다. 너무 오래된 자료들은 빼기 위해서 #40000이후만 넣었는데, 40000번이 올라온 것이 대략 2002년 6월 정도 됩니다. 그 이후에 올라온 69374개의 PR 중에서 Received헤더와 From헤더를 토대로 보낸 사람이 사는 국가를 추정했는데, 미국은 FreeBSD 서버들이 미국에 있어서 IP구별이 힘들어서 통계에서 제외하였고, 영국도 알 수 없는 이유로 GeoIP로 검출되지 않았습니다. 결국 남은 것은 총 100개 국가에서 모두 46304개의 PR이 나왔고, 얘네들을 대상으로 분석하기로 했습니다. (사용한 스크립트)
FreeBSD PR수와 근로시간
우선, 대충 생각해 봐도 인구와 활동양은 비례하는 관계가 어느 정도 있을 것이기 때문에, 활동량을 국가의 인구(위키백과에 올라가 있는 최근 자료를 사용)로 나눈 것과 작업량의 상관 관계를 계산했더니 -0.54가 나왔습니다. 아주 높은 것은 아니지만, 그래도 적당히 상관관계가 있다는 것을 암시하는 것 같은 느낌이 오네요~ (위 그래프에서 대충 경향이 약간 있는 것 같죠? 'ㅇ')
그 외에도 생각해 보면, 먹고 살기 힘들면 오픈소스 하기가 힘들테니, GDP하고도 어느 정도 관련있지 않을까 해서 계산해 보니까 0.52가 나오네요. 그래서, 한 번 얘네들을 묶어서 예측할 수 있도록 식을 만들어 봤습니다. 우선은 대충 기분으로 이렇게~
Pr=FreeBSD PR수, W=근로시간, G=GDP, Pop=인구
선형 최소자승법을 쓸 수 있게 약간 풀고 넘기고 하면,
Pr=FreeBSD PR수, W=근로시간, G=GDP, Pop=인구
그래서, 이놈을 스크립트를 짜서 분석해 보면, 각각의 계수가 k1=-1.51, k2=14.7, k3=3135.7, k4=-30172.4 정도 나옵니다. (사용한 스크립트) log G가 보통 10내외 인 것을 감안하면, W는 -로 100내외 정도 영향을 미치고, log(GDP)는 상당히 많은 영향을 미쳤군요. 흐흐 역시 샘플이 적어서 식이 좀 이상합니다. -ㅇ-; =3=3
인구1000만명당 FreeBSD PR수와시간의 관계, (붉은색은 예측 기대값)
그래도 대충 그래프 보면 뭔가 보이긴 하죠? ;; 빨간색은 위에서 근사식으로 만든 것을 다시 적용한 값인데, 마음대로 이름을 OBFI라고 붙여봅니다. -O-; 대충 1000만명당 PR 개수 순으로 정렬했을 때, 일하는 시간은 증가하는 경향을 보이고 OBFI는 감소하는 경향이 나타납니다. (상관계수는 0.618)
대충 빨간색보다 파란색이 위에 있는 나라는 환경에 비해 오픈소스 (여기서는 FreeBSD) 활동이 많고, 반대의 경우에는 환경에 비해 활동이 적다고 볼 수 있겠습니다. 일본이나 독일이 오픈소스에서 그렇게 활동을 많이 하는 것 처럼 보여도, 그래프에서는 별로 튀어 나오지 않는 것이 사실은 인구빨인 게 들통났군요~ 그리고, FreeBSD가 유난히 강세인 덴마크와 네덜란드가 역시 예측된 값과 엄청난 차이를 보여주고, 한국과 멕시코는 역시 약세입니다. 그런데, PR을 대상으로 해서 그런지, 아니면 주로 유럽이 대상이라 그런지 생각보다 언어는 그다지 문제가 안 되는 것 같네요. 영어를 주로 쓰는 호주나 뉴질랜드라고 다른 국가들에 비해 특별이 더 튀거나 그런 경향은 없는 것 같습니다. 러시아나 중국이 끼였으면 좀 더 분석이 좋았을텐데 OECD자료이다 보니, 없는게 아쉽네요.
일을 많이 시켜서 오픈소스 못하는 우리나라~
인구 순으로 하면 우리나라도 OECD에서 상당히 높은데, 앞으로 S모기업이나 L모기업 같은 곳을 비롯하여 사회 전반적으로 사원들이 젊은 시절에도 좀 여유롭고 즐겁고 발전하는 삶을 살게 근로시간을 줄여주면 오픈소스 뿐만 아니라, 인문학도 살고, 좋아지지 않을까 생각해 봅니다. 회사일 말고도 재미있는 것이 얼마나 많은데~
소수의 자료만 갖고 작업한 것이라 통계적으로 그다지 정확한 편은 아니지만 너그럽게 글자만 읽은 셈치고 잊어 주세요 =3=3 흐흐
일러두기 -- 아일랜드와 아이슬란드도 인구가 너무 적어서 통계에서 제외했습니다.Brett의 소개글에서 ohloh에 대한 얘기는 처음 들었는데, 오픈소스 프로젝트에 관한 무지 재미있는 사이트를 발견했군요. +_+
예전에 FishEye 같은 프로젝트 소스 변화를 추적해 주는 곳이나, Coverity같은 소스 품질을 검사해주는 곳은 봤었는데, 여기는 골고루 짬뽕인데다가 디자인도 예쁘고 아주 호감이 갑니다. 으흣. (물론 Coverity처럼 무결성을 검사하는 것은 아닙니다.)
파이썬에 대한 페이지에 가 보면, 주석의 양이나, 코드 크기에서 추산한 유지보수 비용과 소프트웨어의 자산가치, 라이선스의 특성과 잠재적 문제점 같은 것도 알려주고, 코드의 변화에 대해서도 시각적으로 아주 예쁘게 보여주네요~
뉴스를 수집해서 보여주는 것은 BerliOS에서도 했던 것과 비슷한 것 같은데, 그래도 요새는 RSS가 많이 쓰여서 손은 좀 덜 가긴 하겠네요. CIA처럼 개발자별로 따로 통계를 내 주는 기능도 있는데, 이것도 CIA보다 예쁘게 나오는 것이.. 흐흐 아주 마음에 듭니다. 요새 몇달동안 전혀 커밋 안 한 게 들통나서 얼른 밀린 버그 목록을 좀 봐야겠습니다. --; -ㅇ- (저는 cjkcodecs의 무식한 데이터 양 덕분에 변경한 라인 수로는 6위 -.-v =3=3)
예전에 한 번 넣으려고 했다가 중간고사가 임박해서 그만뒀었는데, 오랜만에 libtomcrypt를 받아서 보니 드디어 RFC4269 SEED 지원이 들어갔습니다! 기말고사도 끝난 기념으로 재미 좀 보려고 했더니 이런 할 일이 없어서 아쉽게 되었네요; libtomcrypt메인테이너인 Tom이 직접 구현해서 넣은 것 같네요
libtomcrypt는 작고 가벼운 구현 특성으로 인해 특히 엠베디드 환경에서 많이 사용되고 있는데, 이제 VPN기계들이나 공유기 같은 곳에서도 쉽게 SEED를 채용할 수 있게 되어서 잘 되었네요~ ^_^ 이로써 이제 오픈소스 툴킷 중 SEED를 지원하는 것은 GNU libgcrypt (GPL), Botan (BSD), libtomcrypt (public domain) 세 가지가 되었습니다. 이제 이번 방학 때 FreeBSD와 Linux 커널에도 시간 날 때 한 번 밀어 넣도록 노력해 보겠습니다. ^_^
어제 "오픈소스에 뛰어들기"를 했습니다. 아침부터 저녁까지 계속 뛰어다니면서 후다닥 했더니 피곤해서 거의 10시간을 잤군요;; 행사 준비에 많은 도움을 주신 여러 강사, 자봉 분들과 추운 날씨에도 오셔서 능동적으로 참여해 주신 참가자 분들께 깊은 감사 드립니다. ^^
이번 행사를 하면서 느꼈던 점과 설문에 적어주신 내용을 토대로 몇 가지 더 좋은 행사를 위한 개선 사항을 기록해 둡니다.
행사의 달인 조성재님이 없었으면 이번 행사 준비가 상당히 힘들었을텐데, 정말 감사드립니다. 다음 행사도 잘 부탁해요 -ㅇ-; 다음에도 컨텐트가 준비되면 한 번 또~ :)
그리고, 이번 행사에서 나온 참가비는 예정대로 플랜 한국위원회에 기부해서 세계의 기아들을 돕는데 쓸 예정이고, 아마도 52만원인가 됐던 걸로 기억합니다. (나머지는 행사 비용으로 사용) 기부자 이름은 참가자 모두의 이름을 쓸 수 없으니 일단 sha1 해시 16진법으로 표기한 이름으로 써달라고 해 볼 예정인데, 안 되면 그냥 행사 이름으로 ^^;
CN님께서 끝날 무렵에, 좋은 제안을 하나 하셨는데, 학생들을 위해서 모든 오픈소스 관련 행사에 대한 안내를 해 주는 RSS/모듬 사이트를 하나 운영하면 좋지 않겠느냐고 제안을 하셨습니다. 아무래도 지금은 홍보를 하려면 오픈소스 사이트 들에도 일일이 다 돌아다니면서 해야 하는 형편이니, 그런 사이트가 마련되면 많은 분들이 쉽게 보실 수 있을 것 같아서 좋겠네요.
이제 이번 겨울에는 가능하다면 RuPy 도 한 번 하고, Framework2.2도 한 번 하고 골고루 해보려고 하는데, 잘 됐으면 좋겠습니다. ^_^
추운 날씨에 많은 분들이 뜨거운 열기로 참여해 주셔서 무척 고맙습니다. 오픈소스에 뛰어들기 후기는 이 글에 달아주세요~ 트랙백 또는 답글 모두 가능합니다.
예전부터 준비해 왔던, 오픈소스에 뛰어들기 참가신청을 받기 시작하였습니다. 이번에 Django로 참가신청 프로그램을 만들었는데, 다음에 두고두고 써먹어야겠군요. 소스 정리되는대로 svn에 올리겠습니다. 흐흐 ^.^
주위 학생들과 새로 오픈소스에 뛰어들려는 분들에게 많은 홍보 부탁드려요~
우흐흐. 한 동안 글을 올리지 않았는데, 한 번 안 올리기 시작하니까 완전 관성이 붙어가지고 쓸 거리는 산더미인데 계속 안 쓰게 되네요. 역시 세상은 양의 피드백으로 가득찬... ^_^
오늘은 1달 전 쯤에 얘기했던 그 행사에 대한 준비 모임이 있었습니다. KLDP의 권순선님, 소프트웨어진흥원의 이재경님, 나비/libhangul 프로젝트의 최환진님, 데비안의 류창우님, 그놈의 차영호님, Y모사의 뽀빠이님(회사 몰래 오셨을까봐 닉네임으로 =3)이 모여서 좋은 행사를 위해 머리를 쥐어짜는 자리를 가졌습니다. :)
일단 목적은 오픈소스에 관심이 없거나 혼자 하기 외로워서 시작하지 않았던 학생들과 직장인들을 대상으로 오픈소스에 입문하면서 오픈소스 현장에서 많은 경험을 한 개발자들에게 직접 경험을 받으면서 기본적인 진입장벽을 넘겨주는 것을 기본으로 했습니다. 그래서, 가장 기초적인 것들과 관습, 분위기, 재미 같은 것들을 전해주는 자리가 될 것이구요. 단위는 10명 내외로 해서 밀착된 실습/강의가 될 수 있도록 할 것입니다.
일단 잠정적으로는 12월 3일 (일요일) 오후 1시~6시에 진행될 예정이구요. 장소는 연세대학교 경영대학 상남경영원에서 제공해 주기로 하였습니다. 참가자는 11월 말에 따로 모집 공지를 KLDP와 주요 커뮤니티에 할 예정이니 그 때 많이 신청해 주세요. ^^ 그리고, 이번에는 외국의 여러 여성 컴퓨터과학자/개발자 육성 정책들에 동조하는 의미로, 참가신청에 여성 참가자 우선 쿼타를 일정 부분 할당할 예정입니다. 또한 참가비는 유료이며 전액 자선단체에 기부하려고 합니다.
오픈마루 Winter of Code 2006에 관심이 있으신 학생 분들도 아마 오시면 준비운동도 하고 멘터도 찾아보고 하는 겸사겸사 좋은 기회가 될 것 같으니 특히 학교에 많은 홍보 부탁드립니다. ^^
혹시 좋은 아이디어가 생각나시거나, 내가 뭔가 가르쳐주고 싶다, 행사 진행을 돕고 싶다 등등 행사 기획에 참여하고 싶으신 분들은 메일링 리스트에 가입해 주세요~ 그리고 "어떤 어떤 것 배워 보고 싶다~" 생각이 나시면 답글로 달아 주시면, 관련 강사분들 섭외에 최대한 힘써 보겠습니다. -O-
얼마 전에 있었던 Framework2.1에서 촬영한 동영상이 올라왔습니다. 좋은 강의 다시 들을 수 있어서 다행입니다. ^^ 동영상 촬영과 인코딩에 힘써주신 강문식님께 감사드립니다. (_ _)
지난 9월 17일에 센트럴시티에서 있었던 KLDP 10주년 기념 컨퍼런스에서 발표한 자료를 올립니다. 요약 자료에 다 있어서 별 필요 없으실 것 같아서 안 올리고 있었는데, 김성안님의 요청에 따라서.. ^^;
다카하시 메쏘드 비슷하게 하기는 했지만, 한 페이지에 글자가 계속 겹쳐서 나오는 부분 때문에, 변종 중 하나구나 하고 파악해 주세요. -.-a
얼마 전 KLDP 10주년 기념 행사에서 "오픈소스 프로젝트에 참여하기"라는 세션을 준비하면서, 말로만 하고 지나갔던 여러가지 것들을 대안언어축제에서처럼 시작을 딱 하고 끊어주는 그런 행사가 있으면 좋겠다고 생각이 들었습니다. 대안언어축제에서 많이 느꼈던 것이, 많은 개발자분들이 회사와 각자의 공간에서 떨어져 계시다가, 딱 공간에 모여서 불을 당기니까 막 팟팟~ 하고 터지면서 폭발적인 결과가 나오는 것을 보고 깜짝 놀랐는데요, 그 결과 요새 인터넷 검색하다 보면 부쩍 대안언어 이야기과 대안적인 개발 방법들에 대한 관심이 늘어나는 것이 역시 우리나라에 개발자가 적지는 않구나! 하는 느낌을 받았습니다.
즉, 혼자 공부하기에는 심심하고, 근처에 같이 하자는 사람도 없고, 뭘 해야할 지도 막막해서 그냥 모르고 있었던, 여러가지 오픈소스 참가에 사용되는 기술들을 같이 모여서 시작에 대한 팁을 듣고 같이 해 보면, 오픈소스 개발자가 늘어날 수 있는 토양이 조성되지 않을까 하는 생각이 듭니다. 그래서, 일단 Framework 2.1 처럼, 첫 행사는 조그맣게 4 세션 내외로 해서 간단하게 시작해봐야 겠다고 마음을 먹었습니다. 흐흐 ^^
일단은 다음과 같은 세션들을 생각해 봤습니다. (이 중에 몇 개만 추려서..)
각 과정은 1시간 정도로 아주 짧게 100% 실습형으로 진행하면 좋을 것 같고요~ 각 세션은 되도록 두 분이 진행하셔서 페어 티칭이 되면 좋을 것 같네요. 미리 테스트를 할 수 있는 공간을 만드는 게 좀 시간이 들 것 같군요. 흐흐. 관심 있는 분들의 코멘트 많이 부탁드립니다. -o- 특히 gana쪼꼬렛님은 꼭 gettext를 맡아 주셔야 =3=3
대안언어축제 2006의 Io 튜토리얼 세션에서 진행했던 자료를 올립니다. 진행 도중에 발견 되었던 2가지 오류는 수정했습니다. ^^;
일상이 지루하고 새로운 언어를 한번 보고는 싶은데, 튜토리얼 보기는 따분하다 싶으실 때, 친구 6명 또는 3명을 모아서 한 번 해 보세요. -O-; 나름대로 미지의 문법이나 잘 모르는 소스를 볼 때 대처해야 하는 능력이 길러질 지도 모릅니다.;;
대안언어축제의 Io 튜토리얼 세션에서 진행해 본 결과로는, 참가자의 실력차이가 많이 날 때 서로 경험하는 것의 차이가 심해서 별로 좋지 않았던 것 같기도 합니다. 또한, 한 팀에 사람이 너무 많으면 좀 문제가 있는 것 같고요.. 진행 방법에 대해서는 첫 페이지에 요약해 두었습니다. 해 보신 분들은 소감을.. ^^;
지난 번에 잠깐 얘기를 꺼냈던 대로, 대안 웹프레임워크 연합 세미나(가칭)이 거의 윤곽이 잡히고 있습니다. 오늘은 NCsoft의 도움으로 장소가 마련되었고, 이제 곧 참가자를 받을 예정입니다.
이 행사에서는 빠른 프로토타이핑과 재활용 패턴을 강조하는 여러 웹 프레임워크를 다룰 예정입니다. 이번에는 처음인 만큼 다음 4가지 프레임워크가 참여합니다.
음.. 저는 할 줄 아는 게 없어서 그냥 구경만.. =3=3 날짜는 9월 23일 (토) 오후 중에 4~5시간 정도 이뤄질 예정입니다. 형식은 일반적인 튜토리얼 형식은 아니고, 대안언어축제에 참가하신 분들이면 쉽게 적응하실 수 있는 굉장히 능동적인 참여가 필요한 방식으로 진행될 것입니다.
구체적인 것들이 좀 더 결정되면 다시 알려드리고 광고를 하도록 하겠습니다. ^^ 지금으로써는 아마도 파이썬마을과 한국루비사용자포럼에서 각각 15명, 스퀵사용자모임에서 10명 정도씩을 따로 모집하는 형식으로 할 것 같습니다.
이런 것이 궁금하다, 이렇게 하면 좋겠다 등등 의견 있으신 분들은 답글 올려주시고용 +_+ 혹시 행사 당일 진행에 도움 주실 분들도 알려주시면 고맙겠습니다~ ^^
오늘 CVS 메일링 리스트를 보고 있다가 발견했는데, security/php-suhosin 이라는 프로젝트가 있군요.. 이름이 반짝반짝해서.. 중국 사람이나 일본 사람이 만들었나? 하고 검색을 해 봤는데, 글쎄, 프로젝트 홈페이지에 붓글씨체로 "수호신"이라고!
개발자인 Stefan Esser는 독일 사람인 듯 한데, 한국과 무슨 인연이 있어서 프로그램 이름을 한국어로 따왔는지 무척 궁금합니다. 한국인 아이라도 입양한 것일까요? 아아 궁금하네 -ㅇ-;
KLDP 10주년 기념 컨퍼런스에서 발표할 "오픈소스 프로젝트에 참여하기"의 자료입니다. 책자에 그냥 적을 게 있으시면 적을 수 있게 개략적인 틀을 요약한 것인데, 실제 세션에서는 전에도 그랬듯 타카하시 메쏘드로 할 예정입니다. ^.^;
다음 주 일요일이니 관심 있으신 분들은 많이 참석해 주세요. ^_^
항상 좋은 강의를 웹에 공개해 주는 UC버클리에서 Open Source Development and Distribution of Digital Information: Technical, Economic, Social, and Legal Perspectives라는 강좌를 공개했습니다.
학정번호가 InfoSys, Law인 것을 봐서 개발의 깊숙한 부분이라기 보다는 사회/법적인 측면의 전반적인 수업이 될 것 같습니다. 실라버스의 주제들을 보면 Economics of Opensource, Open Source Business Models, Government Policy toward Open Source 같은 것들이 나와 있는 걸로 봐서는, 국내의 많은 오픈소스 진흥에 관련된 유관기관들에서도 공부를 좀 해야하지 않을까 싶네요. ^^ 단순히 오픈소스 소프트웨어들에 한정된 이야기가 아니고, PLOS나 위키백과같은 오픈소스 디지털컨텐트에 대한 것도 포함되어 있습니다.
특히 우리나라에서는 오픈소스의 저작권법/특허권법적 특징들과 오픈소스 프로젝트안에 숨어있는 경제학적 측면들에 대해서 일반인들의 이해가 굉장히 부족하기 때문에, 시간이 되면 저 강의에 대한 자막을 만들어서 같이 볼 수 있게 하는 것도 좋을 것 같습니다.
예전에 libgcrypt에 대한 SEED패치 작업이 진행되면서, FSF에 저작권을 전달하기 위해 메일을 보냈었는데, 지난 주말에 거의 3주만에 드디어 동의서가 도착했습니다. 목빠지겠어요;
내용물로 △ 동의서 1장 △ 회신용 봉투 1장 △ GNU 소 모양 (스티커커 아님) 2장 △ FSF 멤버가 되세요 광고지 1장 이렇게 들어있습니다. 기왕 주는 걸 스티커를 줬으면 더 좋았을텐데 아쉽네요.
이 문서에 싸인을 하면, 제가 올린 부분에 패치에 대한 저작권을 FSF에 할당하게 돼서, 저작권 방어를 FSF에서 대신 맡게 됩니다. 대략 20줄 내외가 넘는 패치들은 이렇게 한다는데.. 다른 프로젝트에서 다 이런식으로 항상 저작권 할당 작업을 한다면 굉장히 난감할 것 같군요; 좀 더 간단하게 자기가 스스로 인터넷에 간단한 라이선스로 릴리스하고 그걸 받아가게 하는 방법도 있긴 한데, 왠지 한 번 해 보고 싶어서 제일 복잡한 방법으로 한 번 둘러가 봤습니다. ^^;
그러나, 정작 싸인을 하려고 보니까 두둥..
과연 어디에 싸인을 해야 할 것인가! 우리나라에서 늘 쓰는 양식에는 (인) 위에 싸인을 하면 간단한데, 여기는 도대체 어디에 싸인을 해야할 지 애매하더군요; 아흐아흐.. 혹시 외국인들도 우리나라에 와서 싸인할 일이 생기면 (인) 뒤에 공간이 너무 적어서 도대체 여기다가 어떻게 싸인을 하느냐 하고 고민하지 않을까 생각을 해 봤습니다;
왠지 ①아니면 ③ 자리가 맞을 것 같았는데, 인터넷에 찾아보니 대체로 활자로 인쇄된 이름 위에 싸인을 하는 걸 봐서는 ②번 자리에 줄 위에다가 글자를 쓰라는 뜻으로 밑줄을 그어 놓은 것 같아서 거기에 싸인을 했습니다. (혹시 싸인해 보신 분은 정답을 알려주세요 -ㅇ-)
이제 회신을 보내면 저작권 작업이 끝나서, gnupg에서 SEED를 쓸 수 있을 것 같습니다. ^.^
항상 ssh로 서버에 접속해서 메일도 확인하고 채팅도 하고, 간단한 계산도 하고, 실험도 해보고 하는 일상적인 생활에서 학교나 게임방, 병원 같은 데서 아무나 쓰라고 내놓은 컴퓨터에서 ssh 패스워드를 입력하기란 찝찝하기가 짝이 없습니다. 뭔가 깔려있는 프로그램도 수백만개에다가.. 이거 바이러스 잡는 프로그램도 한 5개씩 깔려있는데 그놈들이 뭔가 더 바이러스 같아 보이고.. 그나마 치료도 안 될 것 같고.. 키보드 입력하는 걸 누가 사진 찍고 있을 것 같은 기분도 들고.. -ㅇ-;
그래서 지난 겨울에는 opiekey로 미리 일회용 패스워드를 여러개 뽑아서 종이에 인쇄해 다녔는데, 이게 또 맨날 까먹고 패스워드 다 됐을 때 보충해 놓지 않으면 접속하지 못하고, 종이에 적어다니다보니 잃어버릴 위험도 있고 해서 어제 전화기용 OPIE 제너레이터를 만들어 봤습니다.
요즘 세상이 좋아져서 자바 문법도 모르는데 IDE가 시키는 대로만 하니까 뚝딱 되더군요. (난생 처음 짜본 자바 프로그램 -O-;;)
SKT 전화 쓰시는 분들은 한번 해보세용. 다운로드는 무료인데, 데이터 요금은 듭니다. (데이터 무제한 요금제이면 안 들고..)
처음 자바를 하는데 도움을 많이 주신 랫쓰님께 큰 감사 드립니다~ ^.^
싸이월드도 OPIE 지원하라~~ (먼산)
요즘 굴림체를 합법적으로 쓰는 방법으로 네이버 사전체가 인기를 얻고 있습니다. 상당히 좋은 품질의 비트맵 글꼴을 포함하고 있고, 라이선스도 OS 제한 없이 아무데서나 쓸 수 있게 하고 있어서 썩 괜찮은 선택인 것 같습니다. 흐흐
포트로 등록하기 위해서, 조금 쳐다봤는데 NSIS 인스톨러로 되어있어서 exe를 실행해야 하게 되어있네요~ 그래서 FreeBSD에서 풀 방법을 찾아보다가, p7zip에서 NSIS 설치파일을 풀 수 있다는 것을 발견했습니다. 그런데, p7zip이 C++ 프로그램에 템플릿을 와장창 써버리는 바람에.. 컴파일이 어찌나 느린지.. 그래서 포트에서 잽싸게 설치하는 데 문제가 좀 많아서 결국은 디버거로 한참 뚫어져라 쳐다봐서, 파이썬으로 p7zip에서 하는 짓과 비슷하게 한번 만들어 봤습니다.
>>> import urllib, zlib, md5
>>> URL = 'http://cndic.naver.com/font.nhn?menu=download'
>>> tcmp = urllib.urlopen(URL).read()[60703:14721246]
>>> uncmp = zlib.decompress(tcmp, -zlib.MAX_WBITS)
>>> md5.md5(uncmp).hexdigest()
'd4b2f7fafb16bca61f02108359e029bb'
>>> open('naverdic.ttf', 'w').write(uncmp)
p7zip은 없고 python이 있으시면 요 방법으로 간단하게 풀어보세요~ -O-
9월에 두 행사에서 발표를 맡았습니다. 혹시 직접 만나서 물어보실 것이 있으시거나, 전해주시고 싶은 선물-ㅇ- 이 있으시면 오시면 좋을 것 같습니다. ^o^
9월 1일~3일: 대안언어축제에서 Io언어 튜토리얼을 1시간 30분 정도 진행합니다. Io 언어는 문법이 안 독특한 듯 하면서도, 독특하고 자유도가 별로인 것 같으면서도 굉장히 자유로운 재미있는 성질이 있는데요, 혼자 공부하기 귀찮으시면 오셔서 같이~ 물론, 대안언어축제의 다른 행사들도 ∑n=0,∞{정말정말} 재미있습니다. 요즘 참가신청을 받고 있으니 일정을 확인해 보시고 등록하세요~ (마감임박!)
9월 17일: KLDP 10주년 기념 컨퍼런스에서 "오픈소스 프로젝트에 참여하기"라는 제목으로 발표할 예정입니다. 그냥 사용자로써 종종 불편한 점을 패치해서 개발자들에게 보내주는 방법부터 개발자가 되기 위한 중간 과정, 개발자가 되고 나서 있는 여러 인간관계까지 다양한 상황에 대한 소개를 조금씩 해드리려고 합니다. 구글의 Greg Stein도 온다고 하니, 구글에 관심 있는 분들도 오시면 재미있을 것 같네요~ -- 아마 Greg Stein의 발표는 그동안의 발표 내용으로 미루어보아 Python과 MySQL에 대한 내용이 주가 되지 않을까 생각합니다.
애자일 블로그에 올라온 프로그래머와 수학을 읽고 전에 경험했던 것을 짧게 써 봅니다.
프로그램을 하다보면, 뭔가 하고 있는 것이 비효율적인 것 같은 느낌이 약간은 들지만, 최적화가 충분히 되어있다고 느낄 때가 많습니다. 더 속도가 필요하다면, 더 빠른 언어와 여러 트릭을 동원해서 빠르게 하곤 합니다. 극단적인 경우를 예를 들어서, 항상 예제로 많이 쓰이는 피보나치 수열을 한 번 보겠습니다. 실제 프로그래밍이 피보나치 수열처럼 간단한 루틴일 리도 없고 그렇게 반복적으로 호출될 일은 없겠지만, 그래도 극단적인 예를 보면, 그 특징을 다른 곳에서 활용할 수 있을테니까요~
일반적으로 피보나치 수열 n번째를 구하는 루틴은 파이썬으로 이렇게 합니다.
def fib(n):
a, b = 1, 1
for i in xrange(n):
a, b = b, a+b
return a
만약 피보나치 수열의 200005번째 수 "주변"의 것이 정확할 필요는 없고 대충의 값이 필요해서 호출한다면, 제 컴퓨터에서는 대충 2.82초 정도가 걸립니다. 그런데, 이런 루틴이 적어도 초당 100번 이상은 호출되어야 하는 상황이 왔다고 치면 보통 이런 대안을 생각합니다.
자.. 그런데, C로 하면 과연 얼마나 빨라질까요. 200005번째 피보나치 수는 64비트로 커버가 안 되는 수이기 때문에, 빅넘버 라이브러리를 쓰다보면 결국 시간이 제법 걸리고, 속도도 생각보다는 별로 빠르지 않습니다. 어셈블리로 하면? 과연 오늘 퇴근 할 수 있을까요..
여기서 경험많은 프로그래머는 알고리즘을 휙 보고, 이런 코드로 최적화를 합니다.
def fib(n):
if n == 200000:
a, b = FIB200000TH, FIB200001TH
begin = 200000
else:
a, b, begin = 1, 1, 0
for i in xrange(begin, n):
a, b = b, a+b
return a
200005번째 수를 주는데 걸리는 시간이 눈깜짝할 새 입니다. 아이 그런데, 또 주변의 수가 더 필요해졌습니다. 그래서, 좀 더 많은 범위에서 캐시를 할 수 있게 데코레이터도 쓰고 해서 멋있는 캐시를 넣어서 정말 더 빨라졌습니다. 그랬더니 이제는 메모리를 너무 많이 먹습니다! 결국에는 캐시 관리 기능에 메모리가 얼마인지 보게도 만들어서, 이 프로그래머는 주변의 존경을 받습니다.
그러나, 이때 옆에서 보던 한 수학자가 종이에 뭘 끄적거리더니, 이렇게 하면 안 되겠냐고 조심스럽게 코드를 한손가락으로 톡톡 쳐줍니다.
from decimal import Decimal as d
r5 = d(5).sqrt()
d1, d2 = d(1), d(2)
def fib(n):
# a(n) = a(n-1) + a(n-2), a(0)=1, a(1)=1 을 푼 것임
return int((d1 / r5) * (( (d1+r5)/d2 )**(n+d1) -
( (d1-r5)/d2 )**(n+d1) ))
아! 아.. 프로그래머는 뭔가 속은 기분이 들었습니다. 그래서 유심히 보니까, 실행해 보면 정확한 값이 나오지는 않았습니다. 그래서 따져보고 싶었지만 필요한 것은 그냥 대충 화면 좌표를 잡는 것이라 유효숫자 6개 정도만 하면 넘칠정도라는 사실에 슬펐습니다.
컴퓨터 전공 학생들은 대부분 4학년 되면, 적분기호를 까먹을 정도로 수학을 쓸 일이 없습니다. 그런데, 간단한 프로그래밍의 수준을 지나면 생각보다 훨씬 수학을 활용할 수 있는 일이 늘어나는 것 같습니다. 물론 굳이 수학 뿐만 아니라, 넓게 봐서 논리의 흐름과 여러가지 알고리즘적인 방법, 패턴 등이 있겠죠.
모니터 가까이에서 코드를 보고 있으면, 앞에서 본 C로 하면 무조건 제일 빠를거야!, 터플 때문에 괜히 메모리 할당하는 것을 줄이면 정말 빠를거야! 라는 생각을 늘 하게 되기에 마련이지만, 가끔은 좀 멀리서 최적화에 조바심을 내지 않으면서 코드를 볼 기회도 가져봄 직 할 것 같습니다.
"Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away." - Jonathan Sobel, 《Is Scheme Faster than C?》에서
붙임: 중간에 든 예가 좀 과장이 심해서 죄송 -ㅇ-; 글의 원래의도가 피보나치 수열을 최적화하자는 것은 아닙니다. ^^;
한동안 새로 올라오는 RFC 목록을 안 보고 있다가, 오랜만에 한번 쑥~ 훑어 봤습니다. 아무래도 인터넷의 트렌드를 알려면 RFC 목록을 보는 것이 많은 도움이 되는군요. ^.^
작년엔 주로 SIP 같은 세션 프로토콜들과 그와 관련된 스트리밍 프로토콜들이 주종을 이루었는데, 올해에는 이제 그를 뒷받침해 줄 인프라망에 대한 것들이 많이 올라오는 분위기입니다. BGP 같은 라우팅 프로토콜류에 관한 것들이 특히 많고, Mobile IP의 라우팅 최적화, 3GPP와의 연결 가이드라인 같은 것들이 등장하고 있습니다. 그리고, DNAv4 같이 사용자망에서의 새로운 활용가능성을 더 높이기 위한 기존 프로토콜의 보완작업도 일어나고 있습니다. 이에 따라, 점점 동적인 네트워크가 강화되고, 모바일 네트워크를 제대로 지원해주기 위한 기반 작업들이 굉장히 빠르게 다가오고 있다는 느낌을 받을 수 있습니다.
SSH가 RFC로 등록된 것이 유닉스 개발자들에게는 가장 관심이 있을 만한 것일 듯 합니다. RFC4150을 시작으로 구조, 인증, 키교환, 통신계층, DNS 등 거의 20~30개 정도 되는 RFC들이 우루루 들어왔습니다. 저자로는 SSH를 최초로 고안한 SSH Communications가 당연히 제1저자로 등록이 되어있고, 제2저자는 Cisco 직원이군요. RFC가 이제 IETF Proposed Standard로 등록이 되었으니, ssh 구현 간의 비호환성이 앞으로 많이 줄어들겠지만, 사실상 지금까지 크게 불편했던 점이 없었기 때문에 눈으로 볼 수 있는 변화는 별로 없을 것 같긴 합니다;;; 어쨌거나 표준화가 착실하게 되어서 등록된 점에서는 매우 환영할 일입니다.
그리고, 요새 네임스페이스와 관련한 것도 일상에 영향을 많이 주니 흥미롭습니다. ^^ RFC 4343으로 DNS 대소문자 구분에 대한 것이 등록되었습니다. 지금까지 표준안에서 DNS에서 대소문자 구분에 대한 규칙이 전혀 없었고, 심지어 아스키문자가 아닌 것도 프로토콜에 얼마든지 허용이 되었습니다. (\x00 마저!) 이런 것들에 대해서 존 파일에 쓰는 방법을 표준화 하고, 대소문자 구분을 안 한다는 사실을 처음으로 명문화 하였다고 합니다. --;
뉴질랜드 정부에서 URN 네임스페이스를 등록한 RFC 4350 도 재미있습니다. 개요에서 밝힌 목적은, 뉴질랜드 정부 기관과 기업, 개인들에게 개인 식별자를 제공하기 위한 것이라고 하는데, 예시를 보면 도메인 시스템과 비슷하게 계층구조로 정부에서 관리할 계획인 것 같습니다. 그래서 회사 이름과 지리정보, 국가에서 관리하는 여러 식별번호를 모두 URN으로 통합할 수 있게 되어, 고유식별번호를 교환할 때 매우 편리하게 되었습니다. 무슨 뜻인지 알 수가 없는 UUID만 떨렁 써놓고 표준이라고 주장하는 것을 이제 뉴질랜드에서는 보기 힘들겠군요. :)
그리고, 재작년부터 선풍적인 인기를 끌고 있는 SPF가 드디어 RFC로 등록되었군요. 비록 EXPERIMENTAL 트랙으로 들어가기는 했지만, 그래도 공감을 이끌어낸 뒤 표준화되어 결국 RFC 등록이 되었다는 점에서, "SPF는 단순한 꼼수가 아니냐!"고 무시해버리기는 힘들게 되었습니다. SPF 만세 -O-;
보안과 관련한 것들은 꾸준히 증가하고 있는데, 이번에는 TLS가 RFC 4346에서 1.1로 업데이트됐습니다. (RFC 4346의 제2저자의 소속이 재미있습니다. -O-;;;) TLS 1.0과의 차이점은 그동안 꾸준히 제기되어 왔던 CBC 패턴 분석 공격에 대응하기 위해서 IV (Initialization Vector)를 명시적으로 지정하게 되었고, 간단한 에러 처리 규칙이 몇 가지 바뀌었습니다. TLS 1.0의 내부 버전이 SSL 3.1이라는 사실을 기억하면, TLS 1.1의 버전이 뭐가 될 것인가도 상당히 궁금해 지는데요, RFC 내용을 보면 SSL 3.2로 한다고 합니다. (프로토콜 내부의 핸드셰이킹을 위한 버전 번호)
그리고 IPSec도 RFC 4301에서 업데이트 되었습니다. 성능 향상과 구현의 단순화를 위해 처리 모델을 바꾸고, SPD (Security Policy Database)의 유연성을 확보한 것이 주요한 변경사항인 듯 합니다. 그리고, 일본의 블럭 싸이퍼인 Camellia가 RFC 4312에서 Standards Track으로 승격되면서 IPSec에서 사용가능하게 되었습니다. (SEED는 RFC 4169에서 Proposed Standard)
그 외에 재미있는 것:
덴마크에서 2008년 1월부터 공개 표준(Open Standard)를 법적으로 의무화한다고 합니다. 공개 표준화가 슬슬 여러 국가에서 채택이 되고 있는 가운데, 덴마크에서 거의 최초로 법적으로 광범위하게 강제화 하게 된 것입니다.
이번에 덴마크에서 공개 표준을 주로 노린 부분은 문서 파일 포맷에 주안점을 둔 것 같이 보입니다. 위 뉴스의 (비공식) 영어번역을 보면, 의회의 안의 결정 안에서 이런 법의 도입 목적은 "모든 시민들에게 공공 기관에서 제공하는 모든 디지털 정보를 자유롭게 주고 받을 수 있는 민주적인 권리를 모든 공공 기관에서 사용되는 IT 기술에 대해 적용하려는 정치적인 작업"을 하는 것이라고 합니다. 최근 우리나라에서 고질적인 정부의 표준 무개념에 대한 개선 노력이 눈물겹게 이뤄지고 있는 것을 생각해 보면, 오랫동안의 차별에 무기력하게 익숙해져 있었던 자아를 반성하게 됩니다. ^.^;
그 외에도, △ 대민 서비스와 업무를 위해 공공기관이 구입하는 소프트웨어에 대한 정책적 결정 △ 공개 경쟁의 촉진 △ 여러 단계의 기관들 끼리의 시스템 통합을 위한 공개 표준 채택 △ 공개 표준을 공적으로 관리함에 따른 장기적 관점에서의 경제적 혜택 등을 언급하고 있습니다.
우리나라에서도 지금처럼 단순히 공개 표준을 모른체하며 99%가 쓴다는 고가의 단일회사 제품을 나머지 1%에게도 쓰도록 강요하는 상황이 속히 개선되어서, 초고속 인터넷 (게임) 강국 그러면서 조바심 내지 말고 느긋하고 여유있는 멋진 발전을 이루었으면 좋겠습니다.
앞에서 살짜쿵 얘기해 보았던 〈인터넷 금융 서비스 플랫폼 문제의 현실적 대안〉에서 공개 표준 프로토콜을 도입하는 방법에 대해서 조금 더 자세하게 살펴 보겠습니다. 물론, photon님께서 말씀하신 대로 단기적인 해결책은 우선 현재 돌아가는 형태 안에서 플러그인을 많이 쓰이는 대안 플랫폼들에 포팅하는 것이 되겠습니다. 장기적인 안을 고려하자면 여러 다른 형태도 고려해 봄 직 합니다.
자바스크립트 API로 표준화하기
이 방법은 자바스크립트 API를 "인증서를 확인하라", "개인 인식 번호를 전송하라", "송금 확인을 해서 싸인하라" 등의 기초적인 기능을 수행하도록 표준안을 만드는 것입니다. 그러니까, 세션 암호화 등의 밑에 깔리는 것들은 HTTPS를 이용하고, 인증서 확인과 관련된 것을 웹브라우저 플러그인으로 들어가거나 다른 방법으로 자바스크립트의 함수를 호출하는 것으로 해결을 하는 방법입니다. 도식화 하자면, (이 그림은 일반인의 이해를 돕기 위해 과하게 단순화를 한 것이며, 실제 구조를 정확하게 표시한 구조도가 아닙니다.)
대충 모양은 이렇게 나오는데, 예를 들자면 W3C XMLHttpRequest 같이 자바스크립트 오브젝트를 정의하는 형태이면 적당할 듯 합니다.
자바스크립트 API를 그냥 중간전달자로만 활용하기
이 구조는 지금 이니텍과 소프트포럼에서 채택하고 있는 방식과 비슷한 것입니다. 정확히는 이니텍과 소프트포럼은 Active X 오브젝트나 플래시 오브젝트를 대신 경유하고 있지만, 경유하는 과정을 굉장히 단순하게 전달자로만 쓴다는 점에서는 비슷합니다. 원래는 128비트 암호화를 웹브라우저에서 HTTPS로 지원하지 않아서, 암호화를 하려다 보니 이런 형태를 띠게 되었습니다. 이 구조에서는, 자바스크립트 API를 제공하기는 하는데, 거의 의미없이 그냥 전달만 합니다. 안에 전달 받은 곳에 구체적인 프로그램 동작이나 사용자의 행위를 요구하는 것에 대한 정보가 암호화되어 저장됩니다.
이 경우에는 호출하는 방법도 물론 표준화를 해야겠지만, 매우 간단하기 때문에 별로 흉내내는 것도 어렵지는 않아지고 플랫폼에 따라서 선택적으로 취할 수도 있습니다. 자세한 내부 정보의 바이너리 포맷을 정하는 것이 표준화에서 중요한데, RFC3261 SIP 같이 텍스트 기반의 프로토콜을 채택할 수도 있고, RFC2138 RADIUS같이 바이너리 프로토콜을 채택할 수도 있습니다.
바닥부터 TCP또는 SSL기반의 프로토콜을 만들기
독일에서 쓰는 HBCI (Home Banking Computer Interface)에서 쓰는 방식입니다. 이 방식에서는 HTTP나 SMTP같이 아예 바닥부터 프로토콜을 새로 만들어 버립니다. 이렇게 되면, 꼭 웹브라우저에 의존할 필요가 없기 때문에, 플랫폼이 GUI 프로그램이 될 수도 있고, 텍스트 콘솔이 될 수도 있고, 웹 브라우저에 들어갈 수도 있고, 심지어 집 현관문에 붙은 인터폰