Openlook Stories

군집이룬 자료의 비모수 두 표본 차이 검정 (C 구현)

Hye-Shik Chang — Tue, 09 Jun 2009 09:26:46 -0000

두 표본 집단의 차이가 의미가 있나 알아볼 때 보통 t-검정을 많이 씁니다. t-검정에서는 값의 분포가 정규분포라는 가정이 있어서, 자료의 분포를 모르거나 정규분포로 바꾸기 매우 난감한 경우에는 t-검정을 할 수 없어서 비모수 검정을 사용하는데요, 이쪽으로 가장 인기있는 검정법은 아무래도 Mann-Whitney U test입니다.

어느날 MW-U로 재미나게~♪ 통계를 하다가~ 아니!! 결과가 엄청 편향되어 나오는 것입니다! 비모수라더니!! 마이크로RNA 마이크로어레이로 나온 결과를 분석하고 있었는데, 마이크로RNA가 염색체에서 떼로 몰려 있어서 한 놈이 올라오면 같이 우루루 올라오는 특성이 있다보니 군집이 엄청 큰 놈들에 의해 전체가 흔들려서, 아 무슨 좋은 방법이 없을까! 하다가 군집을 이룬 자료들에 쓸 수 있게 변형한 것 (Rosner and Grove, 1999, Datta and Satten, 2005, Haataja et al., 2009) 들을 발견했습니다. +_+

오.... 다 괜찮아 보이지만, 결국은 코드가 공개돼 있는 Datta와 Satten의 것으 로 해서 일단 결과를 뽑았습니다. 매우 만족스럽군요! ^_^

그런데 문제는 순수 R로 구현되어 있다보니 속도가 엄청나게 느려서, 자료가 별로 크지도 않은데 거의 2시간씩 돌려야 돼서 시험삼아 돌려볼 때도 마음을 크게 먹고 돌려야 해서, 바로바로 결과를 확인하는 재미가 없었습니다.

그래서 쭉 벼르고 있다가, 주말에 여자친구가 기말고사 공부해야 해서, 같이 공부하는 척 하느라 짬이 난 김에 C로 새로 코딩했습니다 (다운로드). R이나 SciPy같은데서 쉽게 쓸 수 있게 외부 의존성을 없애려고, Z-통계치에서 p-value구하는 부분은 빼서 의존성을 줄였습니다. 그냥 libm만 있으면 됩니다. (파이썬에서는 scipy.stats.norm.pdf를 써서 Z에서 p-value를 구할 수 있습니다.) 대략 돌려봤더니 2시간 걸리던게 30초로 줄었군요! 이히히 ^__^* 간단하게 컴파일한 다음에 파이썬에서 쓰려면 이렇게 쓸 수 있습니다~

import ctypes
cranksum = ctypes.cdll.LoadLibrary('./cranksum.so')
crs = cranksum.clustered_rank_sum
crs.restype = ctypes.POINTER(ctypes.c_double * 4)
freecrs = cranksum.free_clustered_rank_sum_result

def clustered_rank_sum(X, grp, cluster):
    N = len(X)
    ret = crs((ctypes.c_double * N)(*X), (ctypes.c_int * N)(*grp),
              (ctypes.c_int * N)(*cluster), N).contents
    r = {'S': ret[0], 'E.S': ret[1], 'Var.S': ret[2], 'z.stat': ret[3]}
    freecrs(ret)
    return r

X = [1,4,2,4,6,7,4,7,8]
grp = [0,1,0,0,1,1,1,0,1]
cluster = [1,1,2,2,2,2,0,0,0]
print clustered_rank_sum(X, grp, cluster)

으음.. R에 붙이는 것은... 아직 잘 몰라서... (나중에..;)

한 리스트를 빙글 빙글 돌면서 빈 자리 찾기

Hye-Shik Chang — Mon, 30 Mar 2009 16:18:38 -0000

요즘 블로그에 통 글을 안 써와서 거의 폐가와 같이 되어 가고 있었는데요.. ^_^ 다름이 아니라, 제가 "이러면 좋겠다!"하고 생각해왔던 바로 그런 성격의 너무 좋은 분을 만나게 되어서 다른 곳에는 신경 쓸 시간이 없었네요. 이히히;

그래도, 1달에 1개 정도는 유지해 두고자;; 쌓아뒀던 코드 단편 하나를 올려 봅니다. 헤헤.

종종 아주 긴 리스트에서 자원관리를 하면서, 자원을 순차탐색으로 할당해야하는 경우가 있습니다. 주로 자원이 직접 사람이 쓰는 것이거나 해서, 순서대로 가는 것이 인지적으로나 쓰고 있는 자리가 모아지는 점에서 유리한 경우에 그런데요. 도서관 같은 곳에서 좌석을 배정한다거나, DHCP서버에서 IP 주소를 나눠준다거나, 순차적으로 나눠주는 큐 관리 시스템에서 작업을 나눠줄 빈 큐를 찾는다거나 생각보다 제법 많습니다.

이런 경우에, 10번째부터 순차검색하기 시작했으면 끝까지 돈 다음에 처음부터 9번째까지 돌아야 하는 것이 중심원리(?)인데요. 구현하는 방법은 물론 클래스 인스턴스가 최근 찾은 인덱스를 변수로 들고 있다가 그 인덱스부터 끝까지 한 번 돌리고, 처음부터 시작한 인덱스까지 다시 돌리는 방법이 가장 평범하겠습니다. 완전 순서대로 배정할 필요는 없고 대충만 맞으면 되는 경우다 싶으면, FIFO 큐 같은 것도 괜찮은데, 이걸 쓰면 시간이 지날 수록 여기저기 듬성 듬성 나와서 원래 목적과는 달라질 수도 있고요~

그래서 range 2번 돌리는 폼 안 나는(?) 코드 대신 보통 끊임없는 이터레이터에서 개수 제한하는 트릭으로 많이 쓰이는 zip을 섞어서 이렇게 하면 비교적 폼 나게(;;) 연속 검색이 가능한 순차검색이 되겠습니다~

from itertools import izip, cycle

def contiters(L):
    cycleiter = cycle(L)
    return lambda: (elem for elem, _ in izip(cycleiter, L))

# 여기부터는 테스트
itgen = contiters('abcdef')

g = itgen()
for i in range(3):
    print g.next(),
print

g = itgen()
for c in g:
    print c,
    if c == 'b':
        break
print

g = itgen()
for c in g:
    print c,
print

실행하면 이렇게 나옵니다.

a b c
d e f a b
c d e f a b

못 찾으면 전체를 한 번 돌고, 찾으면 거기서 중단하면 그 다음에 시작하면 거기서부터 시작합니다~

여기서 종종 마지막으로 돌았던 놈에서부터 다음에 찾을 때 시작하고 싶은 경우가 있는데요. 비슷한 것이 아쉬운 사례로, itertools.takewhile을 쓰면 처음엔 조건이 맞을 때까지 다 가져오는 것은 좋은데, 그 다음 원소를 가지고 오고 싶어서 .next()하면 이미 조건 맞는지 보려고 갖고간 바람에, 조건 안 맞는 것 가져오는 목적으로 그 다음 이터레이터를 쓰지 못하는 것이 엄청 불편합니다.

그래서 전에 찾았던 부분에서 다시 시작하도록 해 보자면~

from itertools import izip, cycle

def contiters(L):
    cycleiter = cycle(L)
    indicesnonfirst = xrange(len(L) - 1)
    def geniter(keeping=[cycleiter.next()]):
        yield keeping[0]
        for elem, _ in izip(cycleiter, indicesnonfirst):
            keeping[0] = elem
            yield elem

    return geniter

# 테스트 부분은 동일

네~ 좀 지저분하긴 해 졌는데요;; 실행하면 이렇게~

a b c
c d e f a b
b c d e f a

모르는 것을 보면 전혀 못 알아볼지라도 찾아보기 좋아하는 어떤 분(^_^)을 위해 용어에 좀 과도하게 링크를 걸었습니다 ^^;

어제 상정된 저작권법 개정안

Hye-Shik Chang — Thu, 26 Feb 2009 02:50:46 -0000

어제는 작년에 한참 대치하던 이른바 "MB악법"들을 포함한 여러 법안이 직권상정되거나 소위를 통과했습니다. 미디어관련법개정안들과 FTA비준안이 진행되고 있는 데에 대해서 굉장히 유감이지만 다른 곳에도 글이 많기에 생략하고, 어제 직권상정된 저작권법 개정안들은 이번의 쟁점법안은 아니지만 오픈룩과는 관련이 많기에 정리해 봤습니다.

이번에 상정된 저작권법 개정안은 의안번호 1800400 진성호의원등 12인, 의안번호 1802291 강승규의원등 11인과 의안번호 1802888 변재일의원등 12인입니다. 앞의 둘은 지금 나뉘어 있는 컴퓨터프로그램보호법과 저작권법을 저작권법 하나로 통합해서 저작권법에서 컴퓨터 소프트웨어까지 관할하도록 하는 것이 주요 취지이고, 마지막 것은 FTA비준을 위해서 요구사항을 맞추는 것과 청소년 저작권 위반 처벌 완화에 대한 것입니다.

강승규의원외 개정안(강승규 정병국 진성호 백성운 안형환 김영우 배은희 조진래 김금래 조전혁 이달곤)에서 컴퓨터프로그램보호법이 통합되는 것은 특별한 변동사항은 없고 두 법이 통합되는 정도인데, 점점 콘텐츠 융합 추세로 컴퓨터프로그램과 일반저작권의 경계가 모호해지는 것에 대응하기 위한 것이라고 합니다. 실질적으로 바뀌는 것은 기존에 분리되어 있던 저작권위원회와 컴퓨터프로그램보호위원회가 통합된다고 하는군요.

그리고 통합 외에 온라인에서 불법적으로 전송하는 사람 또는 올라오는 게시판을 정지시킬 수 있는 법적 근거를 넣는다고 합니다. 그 부분은 저작권법 133-2에 신설되는데 불법복제물이 올라오면 삭제하고 이용자를 정지하도록 요청할 수 있다고 되어있습니다. 단, 여기서 서비스정지를 해야 하는 서비스 제공자 중에 기간통신사업자가 빠지는데, 인터넷 선만 제공하는 사업자가 불법복제를 하는지 관리를 해야하는 건 힘들어서 뺐다고는 하지만, 검토보고서를 보면 기간망사업자(KT, SK브로드밴드 등)만 인터넷 서비스를 제공하는 것도 아니고, 기간망사업자도 다른 것을 제공하는 경우가 많아서 좀 더 검토를 해 봐야 한다는군요.

이 내용은 진성호의원외 개정안(진성호 현경병 조전혁 강성천 황영철 박선영 김효재 강승규 윤석용 김동성 박준선 유정현)에서도 다룬 것인데, 그 개정안에서는 P2P같은 서비스도 온라인서비스사업자로 추가하는 내용과 위의 133-2를 같이 다루었고, 강승규의원외 개정안과는 다르게 기간망사업자도 대상에 포함되어 있습니다.

변재일의원외 개정안(변재일 양승조 강성종 이춘석 권영길 홍재형 강봉균 안규백 강기갑 이시종 김종률 백원우)은 한미FTA비준을 위해 나온 개정안 세트 중의 일부입니다. 한미FTA의 저작권부분에서도 인정하는 여러 공정한 사용(Fair Use)을 미리 도입하고, 청소년들이 저작권을 잘 모른채로 어겨서 심각하게 처벌되고 가정 문제나 성장 문제까지도 연결되는 것을 막기 위한 안입니다.

가장 눈에 띄는 것은, P2P 업자나 온라인서비스제공자들이 저작권보호를 위해 충분한 장치를 하고 노력한 경우에는 사용자들이 발생시키는 저작권문제에 대해 책임이 없다는 것인데요. 그동안은 사용자들이 저작권을 어기면 서비스제공자도 책임이 있었던 모양입니다. 그리고 "공정한 사용"이 폭넓게 정의가 되었는데요. "통상적인 이용 방법과 충돌하지 아니하고 저작자의 합법적인 이익을 불합리하게 해하지 아니하는 경우에는 저작물의 이용을 가능하게 함."이라고 정의되어서, 지금까지 저작권자에게 해가 없는 경우에도 엄밀하게는 불법적인 사용이 되어 버린 경우가 이제 어느 정도는 합법화가 되었습니다. 위키백과에서 도움이 되지 않을까 싶군요.

또한 청소년들이 자기도 모른채 저작권법을 어기고 5년 이하의 징역까지 받을 수 있었던 문제가 있고, 이걸 악용해서 일부 나쁜 변호사들이 저작권 어기는 사람들 골라다가 협박메일을 보내는 일이 심심찮게 있었는데요. 이제 침해 권리의 소매가가 100만원 이하이면 처벌하지 못하도록 단서가 붙었습니다. 그리고 인터넷 서비스 같은 곳에서 캐싱 목적으로 저작물을 저작권자 동의없이 임시 저장해 두는 것도 이번에 합법화가 되었습니다.

사진 프리젠테이션 배경음악으로 좋은 노래

Hye-Shik Chang — Wed, 04 Feb 2009 12:49:00 -0000

여러 명이 모이면, 사진 찍는 사람이 한 명은 있기 마련이고, 기억에 오래 남습니다. 행사가 끝날 무렵 사진을 모아서 동영상 비슷한 걸 만들어서 같이 보면, 회상도 되고 뿌듯하기도 해서 뭉클해지는데요. 사진 프리젠테이션이 사실을 왜곡하는 게 아닌가 싶을 정도로 강력해서 웬만한 기억은 모두 순식간에 아름다웠던 기억으로 만들어버리는 막강한 힘이 있습니다.

마침 어제도 어학당 마지막 학기를 기념해서 학기 중에 다른 분들이 찍었던 사진들을 모아서 FotoMagico로 음악을 깔아서 보여드렸는데, 다들 반응이 "아니 이랬었나!" 하면서 센티멘탈해진다고 놀랐습니다. :)

팬 & 줌 효과 (켄 번 효과)도 중요하지만 역시 배경음악도 큰 역할을 하는데, 이런 회고용 사진 프리젠테이션 배경음악을 몇 번 골라보니까 좋은 회고 사진 배경음악의 기준이 몇몇 있는 것 같습니다~

전반적으로 비슷한 느낌으로 진행돼야 하고, 너무 극적인 전개가 있으면 안 좋다.
거북하거나 복잡한 느낌을 남기지 않으려면 코드와 가사가 긍정적인 편이 좋다.
전주가 짧아서, 가사가 시작되기 전의 썰렁함이 적어야 좋다.
간주가 길어서 가사 부분과 이질적인 시간이 생기면 다른 종류의 사진을 중간에 넣어야 해서 귀찮으니, 그냥 간주가 짧은게 좋다.
보컬이 너무 기교있거나 강한 느낌을 주면 사진보다 보컬에 신경이 쓰이기 때문에, 기교 없이 간단하게 부르는 노래가 좋다.
체육활동이나 승부와 관련이 있는 행사라면 좀 발랄한 비트도 괜찮다.
간단한 멜로디 패턴이 많이 반복되는 형식이면, 중간에 잘라 붙여서 길이 조절하기가 쉬워서 좋고, 모르는 노래라도 프리젠테이션 도중에 익숙해져서 친숙한 느낌을 줄 수 있다.

대충 몇 번 해보지는 않았지만 이런 게 중요했던 것 같습니다. 그래서 제가 써 봤던 배경음악을 소개해 드릴게요~

상상 - 송은이: 단순하게 계속 반복돼서 쉽게 친숙해지고 자르기도 정말 쉽고, 목소리도 친근한데다, 아무 행사 사진에 깔아도 아무데나 척척 잘 어울려서 감동도 주고 긍정적인 느낌도 주는 곡~ 원곡은 3분 29초인데, 잘라붙이면 2분 10초, 1분 30초 로도 편집이 가능하고 중간을 반복해서 5분 정도로 늘릴 수도 있습니다. (BioXP 7기 동영상 (글 중간에 있음)에서 사용)
비밀의 화원 - 이상은: 창준형이 소개해 준 매우 좋은 회고용 배경음악. 역시 친숙해지기 쉬운 멜로디, 단순한 전개, 희망적 메시지 등 중요 요건을 모두 갖추고 있습니다. 중간에 분위기가 다른 패턴이 몇 번 나오는데, 여기서 다른 사건 뭉치의 사진으로 전환하면 좋습니다.
많이 안아 주고 싶어요 - 비누도둑: 비밀의 화원은 좀 부담스러운 분위기도 있긴 한데, 이 곡은 시종일관 사랑스러운 분위기라 긍정적인 분위기 사진만 있을 때 일관적으로 좋은 분위기를 만들 수 있습니다. +_+ 역시 반복이 매우 많아서 길이 조절이 쉽고, 비트가 앞의 두 곡에 비해서 좀 빠른 편이라 화면전환에 대충 동기화하기가 쉽습니다.
Love - 요조: 마찬가지로 처음부터 끝까지 사랑스러운 분위기이고, 쉽게 친숙해지는 분위기에 아주 따뜻한 느낌을 줍니다. 전주도 기타가 썰렁하지 않고 바로 사진이 나와도 좋은 분위기로 시작해 줍니다. 화기애애한 모임들 배경음악으로 아주 좋습니다.
Games People Play - Inner Circle: 지루하다 못해 상투적일 정도의 배경음악이기는 하지만, 그래도 전주도 전혀 없는데다 여행이나 야외 활동 사진으로 아무데나 깔아도 정말 잘 어울립니다. 누구나 다 아는 멜로디에, 영어라 가사가 안 들리는 것도 장점이고요. :)
Signal Song - 라이너스의 담요: 담요 노래는 거의 대부분이 강아지를 안고 부르는 분위기이기는 하지만, 이 곡은 특히 아기나 애완동물 사진 프리젠테이션 배경음악으로 잘 어울립니다. +_+ 다만 0:35 근처까지 전주 부분이 효과음만 나오기에 그 앞을 잘라야 프리젠테이션이 안 썰렁합니다.
Ready, Get Set, Go! (radio edit) - 페퍼톤스: 사진 부분보다는, 엔딩 크레딧 롤 올릴 때 매우 좋습니다. 엔딩 크레딧 롤(?)은 참가한 사람들 이름이나 간단한 통계, 있었던 사건들 목록 같은 것을 보여주면서 사진과는 또 다른 매우 효과적인 회고용 감동 도구로 쓸 수 있습니다. Radio Edit는 원래 3분 46초인데, 역시 1분 10초, 1분 40초, 2분 20초 정도로 편집할 수 있습니다.

여러분들이 알고 계시는 좋은 사진 프리젠테이션 배경음악은 어떤 게 있나요? 저도 알려주세요~ +_+

정수선형계획법으로 팀 짜기

Hye-Shik Chang — Fri, 16 Jan 2009 16:50:43 -0000

2006년의 한 워크숍을 진행하면서 팀을 짜는데, 모든 팀이 비슷한 조건을 갖도록 잔기술을 썼던 적이 있습니다. 기준은 평균 실력, 평균 연령, 성비 같은 것들을 모두 비슷하게 맞추고 가능한 다른 곳에서 온 사람들이 섞이도록 했는데요. 이게 손으로 대충해도 되지만 문제는 신청을 한 분이 모두 오는 게 아니라, 몇몇 분들이 빠지거나 지각해서 미리 팀을 짜도 헛수고라 빨리빨리 모두 고려해서 좋은 팀 구성을 해야해서 자동화를 해야 했습니다.

그래서 당시에는 학교에 사이트 라이선스가 있어서 ILOG OPL로 정수계획(IP)을 했었는데요. 얼마 전에 창준형이 그 소스를 참고하고 싶어 하셔서 찾았는데 소스가 없어졌더군요. 크흐. 그래서 생각난 김에 한 번 오픈소스 선형계획 툴킷인 GLPK용으로 만들어 봤습니다.

모델 코드, 데이터 예제

예제는 누구나 쉽게 데이터 성질을 해석할 수 있도록(;;) 소녀시대, 브라운 아이드 걸스, 원더걸스를 모아놓고 수학캠프를 하는 것을 가정하고(;;;) 최대한 다른 그룹끼리 섞이게, 팀 간 평균 나이, 수학실력, 성비는 비슷하게 하도록 하는데, 수학실력은 몰라서 관련이 있을리는 만무하지만 epg 스타정보에서 인기순위로 대충 매기고, 성비는 모두 여자라 제 맘대로 다수를 남자로 바꿨습니다. ^.~

자 그러면 시험삼아 예제 데이터를 한 번 해 볼까요! 팀은 6개로 나누는 것으로 하고, 우선 제대로 돌아가는지 보기 위해 멤버 수만 같게 맞추는 걸 조건으로 해 보면 결과가..

팀	구성	성비(가상)	평균 나이	평균 EPG 인기
A	제시카 써니 티파니	1:2	21.0	4.33
B	가인 제아 선미	2:1	22.7	2.7
C	태연 윤아 예은	2:1	20.7	5.0
D	수영 서현 선예	2:1	20.0	3.0
E	효연 미료 소희	2:1	22.0	3.0
F	유리 나르샤 유빈	3:0	23.3	3.0

팀 안의 인원 수만 맞지, 어느 하나도 비슷하게 흩어진 게 없습니다. 특히 B, C팀은 여러모로 차이가 많이 나서 비슷한 팀구성 목표에 맞지 않고요, A팀은 소녀시대만 있죠. 그럼 앞에서 언급한 4가지 조건 모두를 맞춰서 최적화한 결과는.. (120초 제한으로 풀어서 최적해는 아님)

팀	구성	성비(가상)	평균 나이	평균 EPG 인기
A	제시카 가인 예은	2:1	21.7	3.7
B	태연 서현 유빈	2:1	20.7	3.7
C	티파니 제아 선미	2:1	22.0	3.7
D	유리 나르샤 소희	2:1	22.0	3.3
E	효연 수영 선예	2:1	20.7	3.3
F	써니 윤아 미료	2:1	22.7	3.3

그런대로 비슷비슷한 팀들로 구성이 됐습니다~ 재미있는 수학시간이 될 것 같네요. -ㅇ-;

사실 이 문제 같은 경우에는 결정하는 변수가 모두 정수라서 (정수가 적을수록 쉽게 구할 수 있음) 사실 전수조사에 주먹구구 좀 넣어서 돌리는 거나 큰 차이는 안 납니다만.. 그래도 재미로~ ^.^;;

'한'씨 여배우가 진짜 많은가?

Hye-Shik Chang — Sat, 10 Jan 2009 04:50:53 -0000

넋놓고 TV를 보고 있으면 종종 여자 연예인들의 성씨가 많이 편중됐다는 생각이 듭니다. 그래서 얼마 전에 과연 진짜로 성씨가 편중됐나! 세 보려고 하고 있었는데 마침 어학당 친구들과 얘기하다가 보니 이미 신문기사에서도 여러 번 다룬 적이 있다는군요! (또박사님, 곰형님 감사!) 찾아보니 2004년 조선일보에서 어느 스포츠신문에서 "한씨 열풍"을 지적했다고 하고, 2007년 일간스포츠에서는 역술인들이 '한'씨가 연예인으로 운이 좋은 성씨라고 한다는 얘기를 전하고 있습니다. 2007년 한겨레신문에서는 대중설문조사로 좋아하는 성씨에 대해 조사를 했었는데, 여기서는 '한'씨가 무려 43/332명이 가장 선호하는 성씨로 조사돼서 인구 조사의 비율인 1.53%와 비교하면 뚜렷한 차이가 있음을 보였습니다.

그렇다면 과연 진짜로 성씨 편중이 통계적으로도 뚜렷한 현상인지, 시대적으로 변화가 있는 것인지 궁금해지는데요! 연예인 데이터베이스 중 파싱하기가 비교적 쉬웠던 epg TV가이드에 1월 7일 기준으로 등록된 연예인 전체에서 한국에서 활동하는 배우, 가수 3941명 중, 이름이 한국사람의 보통 이름처럼 들리는 느낌을 가진 사람 3407명 만을 골라서 통계에 썼습니다. 예를 들어, 두 글자 이름이라도 "하은"의 경우에는 한국사람 이름에서 흔히 쓰는 패턴이므로 포함했지만 "태연"은 성-이름 보다는 이름으로 훨씬 더 많이 쓰이기 때문에 제외했습니다. (이 과정에서 데이터 편향이 생겼을 수도 있는데, 실제 최종 결과에서는 이 영향으로 생길 수 있는 편향과 반대 결과가 나와서 신경쓸 만한 수준은 아니었습니다.)

진짜로 한씨가 많냐!

여자 배우/가수에서 '한'씨의 비율은 3.19%로 조사됐습니다. 원래 인구 중 비율은 1.56%로 1141명 중 21명 정도 나와야 하는데, 45명이 나온 것입니다. 제가 좋아한다고 한예슬, 한지민은 2명으로 세고 뭐 이런 것 아니고, 다 1명으로 셌습니다. (ㅎㅎ;) 이항검정으로 '한'씨에 대한 선호는 없다는 귀무가설에 대해서 P-value가 8.9×10^-6정도 나왔습니다. 따라서 한씨에 대한 선호는 확실히 있다고 볼 수 있습니다.

그렇다면, '한'씨가 원래 끼가 있거나 미모가 특출나서 연예인이 많이 되는 건 아닐까? 하고 의심해 볼 수도 있는데요. 그래서 예명 말고 본명을 보면 36명이 원래 '한'씨인 것으로 기록돼 있는데요. 마찬가지로 이항검정에서 같은 가설로 하면 P-value가 0.002로 좀 약해지기는 하지만, 여전히 경향이 있습니다. 그렇다면 진짜 '한'씨가 왕비도 많이 내고 그래서 끼가 있는 걸까요! 아.. 아쉽게도 데이터베이스에 기록된 본명이 온전하지 않거나, 본명을 숨기는 연예인이 많은 것 같습니다. 김씨는 원래 1141명 중 304명은 나와야하는데, 대상에서 267명만 본명이 '김'씨라서 역시 P<0.0076 정도로, 본명 성씨 분포가 원래 인구 비율과 다르다고 볼 수 있습니다.

한편, '한'씨 말고도 여자 배우/가수 사이에서 많이 쓰이는 성씨가 더 있습니다. '선우'씨는 인구 중 비율은 0.01%이지만, 무려 5명 (0.35%)이 있어서 '한'씨보다 더 뚜렷하게 나타났습니다. 그런데, 젊은 분들이 아니고, 원래 희성이다보니 잘 눈에는 안 띈 것 같네요. 그 외에도 '채'씨, '고'씨, '하'씨가 본페로니 보정을 했을 때 95% 신뢰 수준에서 더 많이 나오는 성씨로 나타났습니다. 반면에 '김'씨는 비율대로라면 304명이 나와야하지만 활동하는 이름으로는 247명 밖에 쓰지 않아서, 흔한 성이라 그런지 피하는 경향이 뚜렷했습니다. (P<7.9×10^-5)

남자는 어떨까요! 남자 배우/가수에서는 '주'씨 외에는 확실하게 많이 쓰이는 성씨가 보이지 않았습니다. '주'씨는 인구비율로 2018명 중 9명이 나와야 하는데, 22명이 있어서 P<0.00032로 95% 신뢰구간 상한선인 0.00056에 턱걸이 했습니다. 예명을 쓰면서 '주'씨로 바꾼 남자 연예인은 대표적으로 주진모, 주민준, 주호성 이 있습니다.

시대별로 변하는 선호 경향

이름은 시대적 유행이 있기 마련이라, 시대별로 나눠서 봤습니다. 데뷰는 정확하게 기록되어 있지 않아서, 그냥 생년월일로 했습니다.

"같음" 가로줄을 기준으로 윗쪽이면 인구 비례보다 많고, 아래면 인구 비례보다 낮게 나온 성씨입니다. 가로줄은 생년으로 묶은 그룹이고 서로 약간씩 겹치기도 합니다. 각 그룹에서 95% 신뢰구간에서 지지되는 특징적인 성씨들만 골라서 표시했습니다. 즉, '오'씨는 65년~74년 태생 여자 연예인들에게 많이 나타났지만, 다른 세대에는 인구 비례와 거의 비슷했고요, 71~80년 태생 여자 연예인들은 '정'씨가 인구 비례에 비해 거의 1/4 밖에 안 된다는 뜻입니다.

잘 살펴보면 50, 60년대생에서는 '금', '방', '오' 씨가 인기였다가, 70년대생에서는 '유', '고' 씨가 인기이고, 80년대생에 와서야 '한' 씨의 인기가 시작됩니다. '채'씨도 '한'씨보다 약간 앞서 제법 높은 인기를 끌었었고, 80년대 후반에서는 '민'씨가 상당한 인기를 끌고 있습니다. 반면에 '김', '박', '정'은 시대별로 잠깐씩 적게 나타나는데, 흔한 성를 갖고 있던 여배우들이 성을 바꾸는 경우가 많다고 볼 수 있습니다. 아마도 여자이름은 비슷한 경우가 훨씬 많아서, 흔한 성이기까지 하면 기존에 활동하는 사람과 겹쳐서 피하려고 바꾸는 경우가 많겠죠.

류/유 씨 두음법칙 적용

보통 남한에서 대부분 성이 두음법칙을 적용한 것을 더 많이 쓰는 반면에, 류(柳)씨는 두음법칙을 안 쓰는 사람이 훨씬 많습니다. 그래서 성씨 통계에서도 '류'씨가 따로 잡혀있고, 반면에 두음법칙을 보통 적용하는 유(劉)씨와, 원래 '유'인 유(兪) 씨도 있어서, 인구조사에서는 '류' 1.31%, '유' 0.95%로 잡혀있습니다.

그런데 통계에서는 거의 모든 기준. 즉, 남자, 여자, 배우, 가수, 시대에 상관없이 거의 대부분에서 유의미한 수준에서 적고, '유'씨가 뚜렷하게 많았습니다. 즉, 일상에서는 '류'씨를 쓰다가도 연예인이 되면서는 발음이 쉽도록 두음법칙을 적용하는 경향이 있다고 볼 수 있겠습니다.

코미디언/개그맨도 성씨 선호가 있을까?

상대적으로 코미디언/개그맨들은 이름을 고상하게 지을 필요가 적은데. 과연 배우/가수들과 비슷한 경향을 보일까요?

통계 결과로 데이터베이스에 있는 여자(95명) 중에서는 모든 연령대에서 유의미하게 더 많이 나오거나 덜 나오는 성씨가 없었습니다. 아마도 본명 그대로 쓰는 경우가 많은 것 같군요. 남자(331명)는 유의미한 것이 하나 있었는데 '박'씨가 1/2배 정도로 적게 나타났습니다. (P < 0.00036) 보정을 하면 아주 유의미한 정도는 아니라서 애매하긴 하지만, 원인은 모르겠지만 박씨가 적기는 합니다.

요약하면, 여자 배우/가수는 성씨 선호가 뚜렷하고 예명을 지을 때 신경을 많이 쓰지만, 코미디언/개그맨 이나 남자 배우/가수는 기본 인구 비례와 별 차이가 없다는 결과가 나왔습니다.

자소별로 뭔가 느낌이 있는 것 아닐까!

신문 기사에서도 'ㅎ'이 연예계 운에 좋다고 했으므로 (;;) 자소별 분석을 해 볼 만 하겠습니다. 다음 표에 요약했습니다. (95% 신뢰도로 유효한 것만 표시)

	여자 많음	여자 적음	남자 많음	남자 적음
첫소리	ㅎ ㅅ	ㄹ ㄱ	ㅅ	ㄱ
가운뎃소리	ㅡ	ㅣ	ㅕ	ㅘ
끝소리	ㄴ ㄹ	ㅁ ㄱ	(받침없음)	ㅁ

뭔가 안 보이던 걸 기대를 했었는데, 그냥 '김'이 적고 '한'이 많다 같이 앞에서 나왔던 성씨별 경향으로 대충 설명이 됩니다. 그런데, 남자에서 받침이 없는 성씨가 많다고 나타났는데, 실제로 남자에서 많이 쓰인 받침 없는 성씨로는 '주', '하', '지' 같은 것이 있어서 산뜻한 느낌을 주는 경향이 있었습니다. 'ㅘ'가 적게 나타난 것은 '황'씨가 1/1.5배 정도로 줄어든 것 때문입니다. 여자에서도 마찬가지로 '황'씨가 적기는 했지만 '황'씨가 원래 인구가 비교적 적고 데이터베이스에서 여자 샘플수가 적었기 때문에 통계적으로 유의미하게 나오지 않았을 뿐 비슷한 정도로 적었습니다. 발음이 힘들어서 일까요?

앞으로 트렌드는!

85년 이후 출생을 살펴보면 여자는 '서', '민', '고'씨가 인기이고, 남자는 '강', '성'씨가 인기입니다. (아직 데이터베이스에 등록된 사람이 몇 안 되어서 통계적 유의성은 떨어집니다만.) 새로 예명을 지으실 일이 있으면(;;) 참고해서 예쁘게 지어 보세요. -O-;

참고: 통계는 RPy로 했고, 그래프는 Apple Numbers로 그렸습니다.

자주 보는 논문 저자 찾기

Hye-Shik Chang — Wed, 07 Jan 2009 05:59:45 -0000

저는 논문 관리를 Papers로 하고 있습니다. 순전히 이 프로그램 때문에 맥을 사는 사람이 있을 정도로 정확하게 타게팅을 해서 나온 놈이라 정말 편리합니다. 다만 DevonThink같이 정보를 자동으로 모아서 못 보는 패턴까지 파악하게 해 주는 기능이 많이 아쉬운데요. 그래서 갑자기 자주 보는 저자들의 PubMed 자동 알리미 설정을 한 번 해 볼까하고 저자를 생각해 봤는데, 아무래도 빼먹은 게 있을 것 같아서 Papers에 등록해 놓은 논문 전체에서 가장 많이 쓴 사람들을 찾아봤습니다.

소스코드 - 다행히도 CSV 출력을 지원해서 BibTex 파싱 같은 것은 안 해도 됐고요. 이름은 중간이름을 간혹 생략하는 경우도 있어서 그냥 성과 이름 첫 글자만 가지고 비교를 했습니다. 하는 김에 가장 많이 보는 잡지 이름도 출력했습니다. 결과를 보니까 오! 간단하게 알리미 설정할 사람들 목록이 나왔습니다. :)

제 상위 저자, 잡지는 이렇게 나오는군요.

===== Authors =====
  1   21 David P Bartel
  2   18 Gregory J Hannon
  3   11 Eric C Lai
  4   11 Thomas Tuschl
  5   10 Nikolaus Rajewsky
  6   10 Alexander Stark
  7   10 Alexei A Aravin

===== Journals =====
  1   96 Nature
  2   89 Science
  3   49 Proceedings of the National Academy of Sciences
  4   48 Bioinformatics
  5   40 Cell
  6   39 Nucleic Acids Research
  7   36 Genome Research
  8   36 Nature biotechnology
  9   31 PLoS Computational Biology
 10   30 Nature Genetics

여러분의 Papers 책꽂이는 누가 많이 차지하고 있나요!

파이썬 2.6의 상위 호환성 기능

Hye-Shik Chang — Thu, 25 Dec 2008 10:39:29 -0000

파이썬 역사상 가장 큰 개혁인 3.0이 발표된 지 이제 한 달이 되어 갑니다. 이번 업데이트는 워낙 변한 것이 많아서 파이썬 개발팀 내부에서도 실제 개발에 적용되려면 2년은 걸릴 것으로 보고 있는데요. 그래서 중간 징검다리로 파이썬 2.6이 3.0을 전후로 발표되었습니다. 2.6에는 3.0 대비에 대한 기능이 많이 들어갔는데, 이 부분만 간단하게 맛보기로 소개해 드립니다~

파이썬 3.0 호환 대비 옵션

파이썬 2.6에서는 3.0에 대비하는 개발자의 편의를 위해서 -3 옵션을 지원합니다. 파이썬을 띄울 때 -3 옵션을 주면 3.0 호환성 경고가 뜹니다. 예를 들면 이렇게요~

cysteine(perky):~% python2.6 -3
Python 2.6.1 (r261:67515, Dec  6 2008, 18:40:24) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7
>>> `1`
<stdin>:1: SyntaxWarning: backquote not supported in 3.x; use repr()
'1'
>>> reduce(lambda x, y: x + ',' + y, 'hehe')
__main__:1: DeprecationWarning: reduce() not supported in 3.x; use functools.reduce()
'h,e,h,e'
>>> {'egg': None}.has_key('spam')
__main__:1: DeprecationWarning: dict.has_key() not supported in 3.x; use the in operator
False

이렇게 파이썬 3.0에서 없어지면서 대체할 수 있는 것을 쓰면 경고가 뜹니다. ~~옵션으로 주지 않고 프로그램 안에서 옵션을 넣어준 것 처럼 하려면 sys.py3kwarning 을 True로 설정해 주면 됩니다.~~ 프로그램 안에서는 sys.py3kwarning을 보면 -3이 설정되었는지 알 수 있지만, 파이썬이 뜨고 나서는 바꿀 수 없습니다.

파이썬 3.0 호환 빌트인 함수

파이썬 3.0에서 새로 생기거나 동작이 바뀌는 빌트인 함수를 2.6에서 미리 쓸 수 있습니다. 그냥 3.0을 바로 쓰는 것과 무슨 차이냐 하면, 기존 2.x용으로 개발된 프로그램 안에서도 모듈 하나 안에서만 선택적으로 빌트인 함수를 3.0 것으로 바꿔서 3.0인 것처럼 쓸 수 있는 것이죠. 하나씩 이렇게 3.0용으로 바꾸다보면 돌아가는 상태를 유지한 채로 2.x에서 3.0용으로 부드럽게 넘어갈 수도 있고요~

future_builtins 모듈이 파이썬 3.0 빌트인 함수를 제공합니다.

>>> from future_builtins import *
>>> map(int, '12345')   # 파이썬 3에서 이터레이터로 바뀌는 map
<itertools.imap object at 0x833deec>
>>> _.next()
1
>>> ascii('한')   # 기존의 repr()을 대체하는 ascii()
"'\\xed\\x95\\x9c'"

파이썬 3.0에서 바뀌는 문법 미리 맛보기

파이썬 3.0에서 바뀌는 print나 유니코드 문자열, 바이트 문자열 같은 것들을 모듈 단위로 미리 쓸 수도 있습니다. 마찬가지로 부분 부분 대처를 해서 3.0용으로 부드럽게 넘어갈 수 있겠죠.

유니코드 문자열

>>> ('산타', len('산타'))
('\xec\x82\xb0\xed\x83\x80', 6)
>>> from __future__ import unicode_literals
>>> '산타', len('산타')
(u'\uc0b0\ud0c0', 2)

print 함수

>>> print('한글', 1)
(u'\ud55c\uae00', 1)
>>> from __future__ import print_function
>>> print('한글', 1)
한글 1
None

어때요! 한 번 해보고 싶으시죠!

다음에는 파이썬 3.0 호환성과 직접적인 관련은 없는 2.6의 새로운 기능을 소개해 드리겠습니다~

파이썬의 매력이 self를 쓰는 거라고 생각해요

Hye-Shik Chang — Fri, 12 Dec 2008 18:55:38 -0000

종종 파이썬에 대한 평을 인터넷에서 한 번씩 검색해 보는데요. 많은 분들이 가장 많이 싫어하는 것은 뭐니뭐니 해도 "들여쓰기 강제"겠죠. 뭐 이거야 취향 문제라 어쩔 수 없는 것이고. 사실 파이썬 사용자들 중에서 "들여쓰기 강제"를 좋아하는 사람이 많기 때문에 파이썬의 원래 목적에도 더 맞다고 생각되고... ^.^;

그에 못지않게 자주 지적되는 것이, 객체 안에서 꼭 self.를 달아 줘야 된다는 것인데요. 저는 self.를 항상 명시적으로 붙이는 거야말로 파이썬의 참 매력이고, self가 없어지면 파이썬이 무너진다고 생각합니다! 특히 자바 프로그래머들이 파이썬의 self에 대해 많이 지적하는데, 자바와 파이썬 모두에서 영향력이 있는 브루스 엑켈도 self를 (메쏘드 선언에서만이라도) 없애보자 했는데, 그에 대한 응답으로 귀도가 불가능한 일이다라고 그 이유를 논리적으로 설명했었습니다.

브루스 엑켈의 제의가 선언에서만 없애자는 것이었기 때문에, 메쏘드 내부의 코드에서 없애면 안 되는 이유에 대해서는 귀도가 설명하지 않았는데요. 브루스 엑켈이 스스로 결론 내린 그 앞 부분의 문제 "self가 왜 있어야 하냐!" 그 이유에 대해서 좀 설명해서 자바 프로그래머 분들이 파이썬을 좀 더 이해할 수 있도록 도와볼까 합니다.

파이썬에서 self가 붙게 된 역사적인 이유는 파이썬의 클래스 내 메쏘드는 기본적으로 외부에 독립되어 있는 함수에 껍데기를 씌운 것이기 때문입니다. 자바는 아예 독립 함수가 없고, 다른 언어에서는 대체로 독립된 함수들과 메쏘드는 다른 취급을 받는데, 파이썬에서는 그냥 함수를 메쏘드로 편입시켜서 쓸 수도 있고, 둘을 비슷한 방법으로 바꿔서 다룰 수 있습니다. 예를 들면 이런 코드가 가능하겠죠.

def egg(self):
    print(self.a)

class A(object):
    def __init__(self, a):
        self.a = a
    egg = egg

A('wow').egg()

밖에서 선언된 함수를 클래스 정의할 때 메쏘드로 끌어들인 것이죠. 메타클래스를 쓴다면 더 동적으로 해 버릴 수도 있습니다. 도대체 이런 코드를 뭐에 쓰냐! 하는 의문을 가지실 수도 있는데요. 의외로 이런 기술이 많이 쓰입니다. egg함수를 C로 구현된 확장모듈에서 끌여들일 수도 있고요. egg만 사용자가 구현할 수 있도록 노출시켜서 외부 모듈에서 불러올 수도 있고요. 심지어 R이나 .NET같은 브릿지에서 다른 언어로 구현된 것을 쓸 수도 있습니다. 메쏘드가 결국 함수기반이라는 것은 생각보다 강력한 개념으로, __로 시작하는 내부 속성을 쓰면 더욱 희한한 것도 제어할 수 있게 되고, 클래스를 안 쓴 코드와 클래스를 쓰는 코드 사이를 넘나들거나 점진적으로 변경할 때 아주 쓸모가 있습니다.

파이썬에서 instance.method(A, B) 는 class.method(instance, A, B) 와 같은 역할을 합니다. 이것은 함수가 메쏘드가 된 얘기 외에도, 다중상속을 받았거나 이름이 중복되는 메쏘드를 부를 때 쓰이기도 하고, 다양하게 상속받은 하위 인스턴스들을 명시적으로 한 메쏘드에게 콕 찝어 줄 때도 쓰이고, 이 규칙 하나가 수많은 모호함을 해결해 줍니다. 그래서 이 일관성이 문법 전반에 계속 흐르고 있습니다.

그렇다면 그냥 함수는 함수로 쓰고 메쏘드는 메쏘드로 쓰고 같은 데서 상속받으면 비슷한 인터페이스가 나올 수 있지 않겠느냐 하는 의문이 있을 수도 있습니다. self의 또 다른 존재 이유로 파이썬을 파이썬으로 만드는 가장 중요한 특징인 "네임스페이스"가 등장합니다.

"네임스페이스"는 파이썬에서 변수를 담아두는 공간으로, 원래는 로컬, 모듈 전체, 빌트인 세 가지 네임스페이스를 찾도록 되어 있다가, 파이썬 2.1부터 상위에 싸여있는 것들도 찾도록 돼 있습니다. 이해를 돕기 위해 예를 들어드리면

A = 1

def X():
    B = 1
    def Y():
        C = 1
    print(A)
    D = 1

이런 파일이 있다면 A는 모듈 전체, 나머지는 로컬에 들어갑니다. 그런데 Y()의 입장에서 C는 로컬인데, B와 D는 자기 로컬은 아니면서 상위 네임스페이스에 속한 변수들이 됩니다. 따라서, 파이썬 2.1부터는 모듈 전체로 가기 전에 B, D가 있는 X영역부터 찾습니다. 파이썬은 변수 선언을 하지 않기 때문에, 변수의 네임스페이스는 대입이 한 번이라도 일어난 최소의 네임스페이스에 영역을 잡는데요. 위에서 C는 Y()안에서 대입이 있었기 때문에 Y()안의 네임스페이스에 잡히고, B, D는 X()에서 대입이 있기 때문에 X()의 네임스페이스에 잡힙니다. 그런데, A는 대입이 모듈에서만 있고, X()에는 없어서 X() 로컬이 아니라 글로벌로 잡힙니다. 이런 네임스페이스를 바꿔주는 키워드가 원래부터 지원되는 global과 파이썬 3.0부터 지원되는 nonlocal이 있습니다. 이건 따로 관심이 있으시면 매뉴얼을 보시면 되겠습니다. +_+

여기서 갑자기 웬 네임스페이스 설명을 self하는 데 하느냐! 하면..

self.을 생략하게되면 로컬 네임스페이스와 인스턴스 네임스페이스가 섞이게 된다는 것입니다. 즉 클래스에서 x = 1하면 이게 로컬로 갈 지, 인스턴스로 갈지 모호해 지는거죠. 자바나 C++은 명시적으로 선언을 하기 때문에 헷갈리지 않지만, 파이썬은 선언을 않기에 명시적으로 쓸 필요가 있죠. 그래서 펄이나 루비에서는 따로 @나 !같은 기호를 도입해서 쓰는데.. 파이썬의 원칙 중 매우 중요한 것으로 "연산자 너무 늘리지 말자"가 있어서 고려 대상은 아닙니다. self.라고 쓰면 파이썬 문법을 모르는 사람도 아 이게 뭐구나! 하고 추측을 할 수 있지만 @같은 걸 붙여놓으면, 문법책을 참조하거나 고난도의 눈치를 보지 않고서는 인스턴스 네임스페이스인지, 클래스 네임스페이스인지, 글로벌 네임스페이스인지 알기가 힘들겠죠.

그럼 또 제기될 수 있는 의문! 대입은 그럼 명시적으로 하고, 쓸 때만 인스턴스와 클래스도 한 번 타 주면 되지 않겠니? 하고 소극적인 부탁을 해 볼 수도 있겠는데요. 읽는 방법, 쓰는 방법이 다른 건 아무래도 파이썬 원칙에는 맞지 않고, 속도도 많이 느려집니다.

모호한 것을 보면, 추측할 수 있을 거라는 유혹은 단호하게 거절한다. (In the face of ambiguity, refuse the temptation to guess.) -- 팀 피터스, 파이썬의 선(Zen)

오픈룩에 관계된 숫자들

Hye-Shik Chang — Sat, 06 Dec 2008 18:07:25 -0000

제가 좋아하는 다큐멘터리 3일 (KBS)에 보면 끝날 때 주제에 대한 사실을 전달하면서도 신선한 반전을 주는 간단한 숫자 몇 가지가 나옵니다. 예를 들면 "추석택배전쟁 72시간"에서는 택배 배송에 관련된 여러 사람들의 고생을 간접체험하는 구성을 하고, 끝에는 "2007년 택배업 종사자는 전년 대비 50% 급증했다."라고 보여줬습니다. 그래서 오픈룩도 그냥 갑자기 몇 가지 간단한 숫자로 정리해 봅니다. 크크; -o-

개설 2010일 째 (2003년 6월 8일부터)
글 824개
댓글 4168개
트랙백 116개
글 속의 사진 1190개
RSS구독자 2247명 (feedburner)
일 평균 방문자 780명 (최근 1달, google analytics)
방문자 중 MSIE 사용자 84%
방문자 중 Windows 사용자 94%
가장 조회수가 높은 Trac과 함께 한 2주 (2004년 12월 21일)
댓글이 하나도 안 달린 글 134개
가장 댓글이 많이 달린 훈련소로~ (2004년 12월 26일)
가장 댓글을 많이 쓰신 t3RRa님 (148개)
최장 공백기간 55일 (2006년 12월 21일~2007년 2월 14일)
하루 중 가장 글을 많이 쓴 새벽 1시 (74개)
하루 중 가장 글을 적게 쓴 저녁 7시 (14개)
가장 긴 혈액형과 성격 그 애증의 대화 주제에 대해 (2008년 9월 23일)
가장 짧은 수요일에 밤을 새면 (2006년 7월 27일)
글 쓰는 데 가장 오래 걸린 미수다 첫째 줄은 의미가 있는가? (2008년 2월 17일) (12일)
가장 긴 연재 망고 음료 리뷰 (16회, 2003년 8월 9일~2004년 3월 5일)

동아시아 민족의 유전적 관계

Hye-Shik Chang — Sat, 06 Dec 2008 15:13:44 -0000

작년에 구글이 투자한 것으로 주목 받았던 23andMe가 올해 타임즈가 2008년 최고의 발명품으로까지 선정할 정도로 대박을 치면서 단일염기다형성(SNP)이라는 말이 더 이상 유전학 전문 용어가 아니라 "돌연변이"처럼 일반 상식에 들어가게 될 무렵... 유럽인들의 유전자 조사를 해 봤더니 지리적 관계와 신기할 정도로 일치하더라!하는 논문이 블로그계에서 한동안 인기를 끌었습니다. 이 논문에서 재미있었던 것은, 단지 유전자 변이 관의 관계만 가지고도 거의 지도를 재현할 수 있을 정도로 지리적 관계가 나왔다는 것도 있었고요. 핀란드가 유전적으로 유럽에서 뚝 떨어져 있다는 사실도 역사를 그대로 재현하듯 나왔다는 것입니다.

세계적으로 유럽 뿐만 아니라 인간 유전적 다형성 연구(HGDP), 세계 주요 인구의 유전적 다형성(HapMap) 등의 대형 프로젝트가 꾸준히 SNP 데이터를 수집해서 가공하고 연구하고 있습니다. 한국인은 앞의 두 프로젝트에서 여러가지 이유로 빠졌는데, 한국에서도 국립보건원과 생명공학연구원/대학 컨소시움에서 독립적으로 한국인의 단일염기다형성 데이터베이스를 구축해서 올해부터 뭔가를 발표하기 시작했습니다. 한편으로는, 며칠 전에 최초로 한국인 유전체 서열이 공개되어서 떠들썩 했는데요. 이제 한국에서도 외국 논문에서만 봤던 쌔끈한 그래프들을 직접 만들어 볼 수 있는 날이 점점 다가오고 있습니다!

그러던 참에, 어제 온라인 오픈액세스 저널인 PLoS ONE에 동아시아인의 유전적 구조에 관한 논문이 발표됐는데요. 앞에서 소개했던 유럽에서의 조사를 동아시아에서 재현한 것입니다. 한국, 일본, 중국 뿐만 아니라 태국, 필리핀, 베트남, 캄보디아 등등 많은 국가를 상대로 했는데, 실제로 이 연구에서 직접 만든 SNP 데이터는 한국인과 미국에 사는 아시아인 밖에 없고, 나머지는 다 앞에서 언급했던 HGDP와 HapMap에서 가져왔네요. 한국인은 아직 KHapMap이 발표되기 전에 시작했는지 직접 21명 피를 한국에서 뽑아갔다고 하는군요~ (요새 환율로 60만원 정도 하는 걸 공짜로... 아.. 부럽다.. ㅡㅠㅡ)

왼쪽은 그냥 동아시아 지도가 가물가물하는 사람을 위해 그려놓은 (;;) 것이고, 오른쪽은 유전정보의 관계만을 사용해서 PCA로 두 가지 기준 수치로 2차원으로 표현한 것입니다. 잘 비교해 보면 기가 막히게도 지리적 관계와 유전적 관계가 맞아떨어집니다! 이 조사에서 나타난 결과로는 한국인은 중국 한족과 일본인의 중간 쯤 되는데, 일본과 훨씬 더 가깝게 나타났다고 합니다. 그리고 시베리아 북쪽의 사하공화국에 사는 야쿠트족은 원래 역사에서 중앙 아시아에서 온 민족답게, 대부분 나라에서 동중국이 기원이라고 추측되는 가운데 야쿠트족만 따로 떨어져 나타났습니다.

이런 연구에서 실용적으로(?) 쓰려고 만드는 몇 가지 도출 정보로는 "유전변이 몇 개를 봐야 어느 나라 출신인지 알 수 있나?" 같은 게 있는데요. 사실 진짜 실용적이라기보다는, 23andMe같이 개인 유전체학으로 사업하는 데서 고객들의 흥미를 끌기 위한 서비스로 이것보다 재미있는 게 없죠. 그래서 이 논문에서도 그런 연구를 했는데, 한국인과 일본인을 구분하려면 5000개 정도 SNP를 보면 비교적 정확하게 구분할 수 있었다고 하고요. 논문에서는 미국에 사는 중국인들이 조상알아보기마커 1500개를 활용하면 싸게 자기 유전적 조상을 알아볼 수 있지 않겠냐 하긴 하는데.. 사실 유럽인들하고 달리 아시아 출신들은 자기 조상이 어디서 왔는지는 워낙 잘 알아서 새삼 신기할 것도 없지 않을까요? ;;

그나저나 어서 중국 김가장에 사는 사람들과 경주 김씨 종가 남자들 침을 받아다가 23andMe에 보내서 진짜 경주 김씨가 흉노족 후예인지 알아봐서 미스터리를 풀어주세요!

xkcd "파이썬" 3.0 수정판

Hye-Shik Chang — Sat, 06 Dec 2008 13:28:43 -0000

며칠 전에 올린 파이썬 3.0 발표 소식에 까리용님께서 만화 속의 호환성 버그를 발견하셔서 3.0 지원 버전으로 만화를 고쳐봤습니다.

원본은 xkcd에서 온 것이고, 원라이선스는 CC 원저자표시-비상업적사용 2.5입니다.

혹시 손글씨 잘 쓰시는 분 있으시면 한국어판 번역도 하나 만들면 좋겠네요~ xkcd는 손글씨모양 글꼴을 쓰지 않고 모두 일일이 쓰는 게 매력이라, 역시 이것도 손글씨를 써서 입혀야 할 것 같아서.. :)

파이썬 3

Hye-Shik Chang — Thu, 04 Dec 2008 11:32:19 -0000

드디어 예정대로 파이썬 3.0 정식 버전이 나왔습니다.

파이썬 3.0은 그동안 이 블로그에서 꾸준히 소개해 와서 특별히 또 소개하지는 않고요. (2007년 3월 1일, 2007년 8월 31일, 2008년 8월 1일) 자세한 내용은 파이썬 3.0에는 뭐가 새로 나왔나!를 참조하시면 되겠습니다~

릴리스 안내문에서 언급한 간단한 바뀐점 목록을 번역해서 옮겨적어 봅니다.

오래된 언어들의 지저분한 것들을 많이 고침
오랫동안 쓰지 말라고 했던(deprecated) 기능들과, 중복되는 문법들을 없앰
표준 라이브러리를 개선하고 구조를 바로 잡음
문자열과 사전 같은 내장 객체들의 세세한 동작을 더 파이썬스럽게 바꿈
그 외에 수많은 새로운 기능이!

파이썬 3.0 새 소식이 나오면 가장 많이 궁금해 하실 부분이, "지금 파이썬을 배우려면 3.0을 배워야 하냐 2.x를 배워야 하냐"하고, "프로그램이 다 2.x용으로 돼 있는데 3.0으로 어떻게 넘어가냐" 일텐데요.

우선 1번) 파이썬 3.0은 하위호환성을 상당 부분 포기했기 때문에, 당장은 업계에서 2.x를 계속 쓰게 될 것입니다. 파이썬 2.x와 3.0이 겉보기에는 문법 차이가 좀 있는 것처럼 보이지만, 파이썬의 기본 이념은 그대로 가지고 있기 때문에 우선 파이썬 2.x를 배운 다음에 3.0 문법을 나중에 배우는 것은 별 일이 아닙니다. 지금 배운다면 2.x를 배우고 쓰시다가, 좀 익숙해진 다음에 3.0에서 다른 게 뭔지 한 번 봐 두시면 됩니다.

2번) 파이썬 2에서 3으로 넘어가는 것은 거의 모든 파이썬 프로그램이 다 2~3년 안에는 겪어야 할 일이기 때문에, 미리 파이썬 3.0을 디자인하면서 자동으로 문법을 변환할 수 있을 것인가! 같은 것까지도 고려 대상이 됐습니다. 그래서 파이썬 3.0에는 2to3이라는 프로그램이 들어있는데, 이걸 사용하면 웬만한 것들은 대부분 자동으로 파이썬 3.0용 프로그램으로 변신할 수 있습니다. 그리고, 파이썬 2.6이 파이썬 3.0을 대비하기 위한 중간 계단으로 같이 나왔습니다. 파이썬 2.6을 쓰시면 파이썬 3.0에 아주 잘 대비된 프로그램을 만들 수 있습니다. 2.6에도 2to3이 같이 들어 있습니다.

참, 그리고 파이썬 3.0 최종판에는 아쉽게도 텔레파시 지원은 예정과 다르게 빠졌지만, 반중력 비행 기능이 생겼습니다. x로 시작하는 모 사이트에 따르면(!) 파이썬에서 import antigravity를 했더니 날 수 있었다고 합니다! (한 번 해 보세요!)

프로그래밍 과목 조교하기

Hye-Shik Chang — Mon, 01 Dec 2008 13:39:44 -0000

저희 학교는 등록금이 상당 부분 세금에서 지원되는 대신, 모든 학기에 뭐든 조교를 하도록 돼 있습니다. 학과 사무실 조교 같은 자잘한 일 도와주는 조교부터 시작해서, 슈퍼컴 관리 조교, BK21 서류 관리 조교도 있지만 대부분은 수업을 돕는 학과목 조교를 합니다. 저도 지금까지 쭉 운도 없이 계속 학과목 조교를 해왔습니다. 지난 학기까지는 쭉 과학 기초과목을 해서 별로 특별한 것은 없었는데, 이번 학기에는 전산, 전자과에서 누구나 듣는 기초과목에다가 바이오를 짬뽕한 "바이오데이터구조"라는 과목을 맡았는데요. 과에서 2학년 필수과목이다보니 보통 저희 과 과목은 수강생이 많아도 10명 정도인데, 이 과목은 처음엔 수강생이 60명이 넘었습니다. (물론 이 안에는 학점을 쉽게 따려고 오는 전산과, 전자과 고학년들도 있긴 하죠. :)

처음 맡는 프로그래밍 관련 과목이라, 제가 학부 때 느꼈던 "조교가 이런 걸 하면 무척 좋지 않을까!"를 한 번 실행에 옮겨 보기로 했습니다. 사실 중간고사증후군보다 졸업논문증후군이 훨씬 심하죠 --;;

제가 맡은 부분은 학기 프로젝트 관리/채점 부분이라서, 이런 것들을 한 번 생각해 봤는데요.

괜히 코드에 a = 1; 같은 것까지 주석 달아야 점수 잘 나온다는 생각은 안 갖게
코드의 실행 결과가 제대로 안 나오거나 만들다 말았어도, 코드의 세세 부분을 보고 겪었을 만한 세부 경험을 기준으로 채점해서 프로그래밍을 잘 못해도 포기하지 않도록
코딩 결과 자체보다, 코드를 돌려본 결과를 성능/속도/알고리즘 등 여러 측면에서 시험해 보는 과정과 원인 분석 과정, 개선 방안, 도메인 문맥에서의 의미 등을 살펴보게
결과 보고서와 코드가 결국 조교 혼자 보라고 쓰는 것이라고 생각하면 영 지루하니, 어떻게든 피드백을 많이 줘서 누군가 읽긴 읽었구나 하는 느낌을 확실히 받도록
프로젝트 진행 중에 학생들의 질문에는 스펙 설명같은 것 자체에 곁들여서, 진행과 관련된 현실적인 조언이나 관련 학문에서의 정보를 전달하게
질문에 대한 답변이나 채점 결과는 가급적이면 빠를 수록 공부에 효과가 좋으므로 가급적 빠르게

그래서 프로젝트를 시작할 무렵에는 우선 가이드라인을 제시했습니다. 원래 내용은 꽤 길지만 요약하면

주석 너무 많이 달지 마라, 주석이 적어도 잘 이해되는 코드가 좋은 거다.
사소한 문제 때문에 진행하기가 힘든 상황이면, 그런 것들은 보고서와 코드에 표시하고 우선 상황을 대충 억지로 넘긴 다음에 시간이 날 때 다시 봐라.
보고서에는 이런이런~~ 것들에 대한 토론이 있으면 좋다. (예시 10가지)

이렇게 시작하고 나중에 오는 질문에는 가급적이면 질문 자체에 대한 직접적인 답보다는, 왜 그렇게 되는지, 실제 프로젝트의 상황에서 어떤 경우가 있어서 그런 결정을 해야하는지 같은 것들을 가급적이면 같이 썼는데, 사실 처음 배우는 프로그래밍 과목에서 하기로는 좀 어려운 프로젝트다보니 제대로 전달이 잘 안 된 것 같아서 좀 아쉽기는 했습니다.

드디어 제출이 다가왔을 때는, 직접 내면 좀 번거로우니까 전자메일로 받기로 했는데요. 아무래도 전자메일에 큰 첨부파일을 보내다보면 사고도 많이 생기고 해서, 별도의 2가지 경로로 보낼 수 있게 메일 주소를 따로 2개를 마련해서 둘 다 보내도록 했습니다. 그리고, 그래도 혹시 또 메일은 알 수 없으니, 과목 홈페이지 게시판에 MD5 체크섬을 올리면 MD5 체크섬이 맞으면 나중에 제출해도 게시판에 올린 시간으로 인정하기로 했습니다. 그런데 정말로 한 학생이 5일 뒤에 메일이 안 갔냐고 자기 성적이 안 올라왔다고 그러는데, 메일이 유실됐는지 전혀 로그에서도 찾을 수 없는 일이 발생했습니다. 마침 게시판에 MD5 체크섬이 올라와 있어서 구원해 줄 수 있었죠.

결국 약간 늦은 학생도 있었지만 대부분 제출이 끝나고 채점을 했는데요. 역시 채점은 하다보면, 점수로만 표현하기는 좀 아쉬운 뭔가 그런 것이 있습니다. 그래서, 아예 성적표 사이트를 하나 만들어서, 각각의 개인의 제출물에 대한 피드백과 학생들의 부분별 상대적 위치를 알 수 있는 도표를 볼 수 있도록 했습니다. (실제 인물이 아니라 이 글에서 인용하려고 가상의 학번을 만들었습니다.)

피드백은 직접 일일이 쓰기는 좀 많아서, 세부항목별로 따로 Z-score를 계산해서 낮은 순서로 몇 개, 높은 순서로 몇 개를 추려서 "좀 더 열심히", "참 잘했어요" 아래에 코멘트를 자동으로 쓰게 했습니다. 뭐 그런대로 괜찮게 나오더군요. :) 하나 재미있는 것은, 웹서버 로그를 보니까, 자기 성적만 보고 가는 학생은 30% 정도 밖에 안 되고, 나머지는 친구 학번을 다 넣어보고 가더군요.;; (친구 관계 네트워크라도 그릴 수 있을 정도!)

이제 프로젝트가 끝나긴 했는데, 제가 맡은 부분이 기말고사가 또 남아있어서.. ㅡㅡ; 또 하려니 막막하네요 -ㅇ-; 그래도, 학생들이 그냥 조교라서 하는 아부도 많이 섞여있겠지만 제출하는 메일이나 게시판 댓글에서 도움이 많이 됐다, 좋은 경험을 할 수 있었다, 많은 것을 배울 수 있었다. 라고 해 줘서 무척 힘이 났습니다. 이제 졸업 준비를 해야하는데.. -ㅇ-;;

오픈룩과 미투의 격한 결합!

Hye-Shik Chang — Sat, 22 Nov 2008 22:03:38 -0000

요즘 졸업논문 준비 한다고 괜히 하는 일 없이 마음만 바쁜데요. 오래 전 부터 그랬지만, 특히 미투를 쓴 이후로 짧은 글이 다 미투로 가서 오픈룩에는 글이 엄청 띄엄띄엄 올라오게 돼 버렸습니다. 을씨년스러운 정적이 흐를 정도였는데, 그래서 옆에 미투 글 목록을 갖다가 뿌려보기도 했지만, 역시 가운데 글이 없으니 영 썰렁하고, 종종 오시는 분들이 왜 글을 안 쓰냐! 가면 좀 볼 게 있어야 하지 않냐! 하기도 하셔서.. 결국은 미투를 오픈룩에 완전히 섞어버렸습니다.

섞는 방법은 보통 미투 -> 블로그 글 배달도 있긴 하지만, 이런 식으로 할 때는 RSS에도 미투를 반복하는 문제도 있고요. 미투하고 오픈룩에 쓰는 글은 종류가 달라서 대상이 다를 수 밖에 없기에, 블로그 글 배달 보다는 그냥 첫 페이지 표시에만 미투 글을 섞어서 보여주는 지금의 모양으로 만들었습니다. (오픈룩 RSS에는 앞으로도 제 미투 글은 섞여 들어가지 않습니다~)

이제 RSS 리더 안 쓰는 오픈룩 독자분들은 종종 놀러오시면 좀 덜 썰렁하게 보일 것 같아서 다행입니다. -ㅇ-;;

그런데, 미투가 아무나 댓글은 쓸 수 없으니, 미투 글에 댓글을 쓰시려면 가입하셔야 합니다. =3=3

루프를 몇 번만 돌려 보고 싶을 때

Hye-Shik Chang — Sat, 22 Nov 2008 15:56:02 -0000

스크립트에서 같은 작업을 많은 데이터에 반복할 때, 한 번 도는데 엄청나게 오래 걸리거나 다른 사이트 리소스를 쓰기 때문에 괜히 민폐를 안 끼치려고 앞 부분만 테스트하는 게 좋을 때가 많습니다. 한 번만 돌릴 때는 이렇게 보통..

for url in 엄청많은URL:
    f = urllib.urlopen(url)
    # 한 번에 확! 하기는 좀 귀찮은 작업을 한다
    raise SystemExit  # 여기서 그냥 1번만 돌고 종료

종종 첫 데이터는 엄청 단순해서 한 5개나 앞쪽 10개만 돌려보고 싶을 때, [:5]나 [:10]하면 좋겠죠. 그런데, 어떤 건 이터레이션은 되지만 이터레이션 자체가 자원을 많이 먹거나 민폐를 끼치거나 하는 경우가 있습니다. 그 때 뭐 제한하려면 enumerate같은 걸 써서 i >5 면 중단 이러면 되겠지만 역시 너무 순수해 보여서 지루하고 타이핑도 많아서 귀찮습니다. 그래서 제가 보통 쓰는 방법

cd = list('12345')
for url in 엄청많은URL:
    # 다른 작업
    cd.pop()

왠지 12345 일일이 써 주면 아! 다섯번 하는구나! 하는 필이 확 오고, 에러로 끝내주니까 아주 신납니다. :)

혹시 직접 쓰시는 재미있는 방법이 있으면 소개해 주세요~

요즘 생각난 경험 나누기 행사 세 가지

Hye-Shik Chang — Fri, 24 Oct 2008 13:22:34 -0000

서울에 있을 때는 이런 저런 행사를 많이 했는데 요즘 대전에 있다보니 영 근질근질해서, 가끔 이런 행사 하면 정말 재미있겠다 상상하며 졸곤(;;) 합니다. 어디 적어두는 습관이 없다보니 생각을 아무리 해 봐야 늘 남는 게 없는데요. 흐흐;; 그래서 최근에 생각났던 걸 함께 생각해 보기도 하고 스스로 안 까먹으려고 적어 놓아 봅니다.

개발자 구보씨의 3일

제가 가장 좋아하는 TV 프로그램은 단연 KBS1 다큐멘터리 3일 입니다. 이 프로그램에선 어떤 장소나 사건을 주제로 3일 동안 같은 곳을 지키며 오가는 사람을 취재합니다. 강남역, 구로역 같은 사람 많이 다니는 지하철 역이 되기도 하고, 강남고속터미널이나 통도사, 동해의 어촌, 추석 특송 기간 동안의 택배 직원들 등등 생활을 밀접하게 다루다보니, 역에서 지나가는 사람들을 보며 저 사람들이 어디서 어디로 가고 어떤 일을 하고 어떤 생각을 하고 가족들과는 어떻게 지내고 어떤 게 행복한지 등이 늘 궁금해 했던 것을 조금이나마 엿볼 수 있게 해 줍니다. 특히 같은 자리에 3일을 쭉 있다보니, 면접보러 서울에 왔다가 다시 며칠 있다가 내려가는 사람, 자전거 여행하러 갔다가 2박 3일 여행하고 돌아오는 사람들의 전과 후를 모두 볼 수 있다보니 정말 재미있습니다. 한 편을 보면 마치 100명하고 술 마시면서 인생 사는 얘기를 하고 온 것 같은 기분이죠.

그래서 개발자도 이런 것들을 할 수 있지 않을까 생각해 봤는데요. 개발자라고 묶으면 왠지 뻔히 하루 종일 컴퓨터 보고 키보드만 칠 것 같지만, 알고보면 회의도 하고, 아이디어 만들기도 하고, 제안서도 쓰고, 싸우기도 하고, 몰래 만화도 보고, 여자친구와 메신저도 하고... 하는 일이나 회사 환경, 개인적인 환경에 따라 적지 않은 차이가 있습니다. 그냥 보면 다 똑같은 개발자의 실제 일하는 환경을 엿보면 고년차 개발자들끼리, 또는 갓 IT업계에 들어온 신입, 대학생, 고등학생 등등.. 추상적인 "이 쪽 전망이 어떻더라..." 보다 도움이 될 것 같아서요.

72시간 VJ들이 쫓아다니는 건 현실적으로 어려우니, 대충 타협해서 72시간 중에 종종 자기 모습이나 하는 일, 주변 환경을 사진으로 찍어서, 그 중 24장을 꼽아서 자기 생활에 대해 페차쿠차 형식으로 발표하는 것입니다! +_+ 자기 자리 자랑도 있을 것이고.. 몰래 회의 장면 같은 데서 이상한 동료 욕도 할 수 있고.. 어려웠던 문제 해결하는 과정을 무용담처럼 얘기할 수도 있고... 단편적인 생활 스케줄을 쫙 훑기보다는, 살아있는 진짜 3일처럼 당시의 생생한 연결된 이야기를 들으면 더욱 좋겠죠!

서울에 사는 세계 개발자 페차쿠차

한국 IT게에서 비전통적 컨퍼런스를 상당히 일찍 시도했던 "KLDP CodeFest"에서는 초기에 계속 꾸준히 서울 인근에 사는 외국인 개발자들이 몇 명씩 참여했습니다. 지난 번 파이썬 페차쿠차는 진행 언어가 한국어였지만 한국어를 잘 하는 프랑스인 개발자가 한 분 참여해서 자리를 빛내주었습니다. 그 때 생각이 떠올랐는데요. 서울에 사는 외국인 개발자들과 또한 그들과 교류하고 싶은 한국인 개발자들이 소통하는 계기가 있으면 좋겠네요.

그래서 역시 지난 번 파이썬 페차쿠차와 마찬가지로 자기가 하는 일이나 한국에서 일하는 개발자로의 경험, 어려움, 팁 같은 것을 페차쿠차로 발표하는 자리가 있으면 촉진할 수 있는 좋은 기회가 되지 않을까 합니다. 아무래도 한국어에 서투른 개발자들도 많이 참가할 수 있도록 공식 언어도 영어로 지정해서 행사장에 누가 있어도 서로 말을 거는 데 주저하지 않을 수 있도록 하면 더욱 좋을 것 같습니다. (한국어를 너무 사랑하는 분들은 이 부분에서 거부감이 있을 수도 있겠지만, 현실적으로 취지를 살려서 한국어를 못하는 개발자를 배제하지 않으려면 이 방법이 최선인 듯 하네요.)

장난감 문제 축제

예전에 언젠가 한 번 제 블로그에 올린 적 있는 생각이기도 한데요. 앞의 "구보씨"와 마찬가지로 다양한 분야에서 일하는 개발자들이 모여서 경험을 나누고 이해를 넓히는 방법으로 장난감 문제를 쓰는 방법을 생각해 봤습니다. 우선 자기 개발 분야에서 아주 간단해서 잘 모르는 사람도 10분 안에 풀 수 있는 장난감 문제를 1개 준비해 옵니다. 예를 들어 게임 프로그래머라면 2D 좌표계에서 충돌 검사를 하는 문제를 가져온다거나, 자판기에 들어가는 펌웨어를 만드는 프로그래머라면 자판기에서 돈 넣으면 잔돈 계산하는 문제, 이미지 처리를 주로 하는 프로그래머라면 간단한 껍데기를 채워넣어서 간단한 알고리즘으로 그림파일 외곽선을 보여주는 문제를 가져오는 등 최대한 자기 분야 특성은 살리지만 장난감 문제인 것을 가져 오면 되겠죠.

그래서 이 문제를 이제 잘 모르는 사람들끼리 무작위로 2명 씩 짝을 만들어서 공략합니다! 이제 그 뒤 부터는 예전에 코드레이스같은 곳에서 했던 형식이나 재미있게 할 수 있는 형식을 여러 가지 만들 수 있을 것 같네요. 채점은 아마도 각 문제를 출제한 사람이 뽑게? ^^;

그냥 최근 떠올랐던 생각 세 가지를 적어 봤는데요. 좀 다듬어서 해 볼 만한 것도 있을 것 같네요. 언제 기회가 되면 한 번 추진을!

Grand Mint Festival 2008 다녀왔습니다!

Hye-Shik Chang — Sun, 19 Oct 2008 19:31:52 -0000

10월 18일-19일 올림픽공원에서 한 거대 박하 축제 2008에 다녀 왔습니다. +_+_+_+_+

사실 GMF나 주최측인 mint paper도 전혀 모르고 있다가 Mocca가 한국에서 공연한다는 얘기를 듣고 GMF에 관심을 가지게 되었는데요. 그 뒤로 GMF에 출연하는 밴드들 노래를 듣다가 홀라당 빠져버려서 한 동안 전의를 불사르며 지내다 드디어 다녀왔습니다!!!! 아고 다리야!! 크크크;

전체 공연 팀은 50팀이 넘었지만, 병렬로 진행되고 이틀만 가다 보니, 몇몇 곳만 가게 됐는데, 저는 위 사진에 있는 11개 팀을 열심히 봤습니다. (윗 줄은 토요일, 아랫 줄은 일요일) 대부분 예습하면서 처음 들은 팀들이었지만, 거의 1달을 쥬크온 플레이리스트에 올려놓고 반복학습하고, 민트라디오를 듣다보니 마치 다들 고등학교 때 부터 좋아했던 것 같이 느껴지네요. ^^;;

전반적으로 일상에서는 팬을 찾기도 쉽지 않은 밴드들이, 축제장 안에서는 마치 아이돌처럼 사람들이 좋아하니 무척 흐뭇(;;)했고요. 대전에서 오랫동안 무료한 생활을 하다가 큰 축제를 가니 사람보는 재미에 푹 빠져서~ 거의 대전에서 한 200년 봐야 볼 수 있는 다양한 사람을 다 본 것 같네요. (GMF의 여성관객 비율은 국내 음악축제 중 거의 최고수준!)

▲ "라이너스의 담요" 공연 준비 중 (공연 중은 촬영이 금지;;)

특히 일요일 "라이너스의 담요", "Mocca" 공연은 장소도 호수를 배경으로 해서 대형 분수도 종종 뿜어주고 해서, 푹 빠져서 헤벌레 해서 정신을 놓고 보았습니다. 세상에나 세상에나!

다른 기대공연이었던 "페퍼톤스", "뎁"은 짧게들 끝나 아쉬워서 다음에 꼭 다른 데서 또 만나겠어요! 뎁♡♡

제가 원래 후기같은 것 쓰는데 많이 서투르니, 이만 줄이고 기억나는 말 소개.. (정확히 받아적은 것은 아님)

페퍼톤스 이장원: (악을 쓰며) 안녕하세요! 락!발라드 밴드 페퍼톤스입니다!!
박새별: (유희열이 라디오에서 안테나뮤직에서 가수는 박새별 밖에 없다고 한 것을 언급하며) 제가 삑사리내면 역시 안테나뮤직 소속 맞구나 하고 박수 꼭 쳐 주세요~
뎁: 여러분 이거 닌텐도 위 게임기에 있는 걸로 만든거 랍니다. (악기에 위모트를 붙여서 공연 중에 뒷 화면에 그림을 그림)
뎁: 스티브 잡스 아저씨 고맙습니다. (VJ에게 비디오아트 기술 발전에 중요한 사람이라는 얘기를 들었다며)
요조: 여러분 제가 음란가수인가요?
요조: (모든 곡이 끝나고 나서, 객석을 향한 마이크의 음량이 화면에 바 그래프로 연결돼 있고 그 위에 "앵콜지수"라고 표시 됨) 이렇게 뜨겁게 앵콜해 주셔서 고맙습니다~
라즈베리필드 소이: 이 곡은 149번 버스에서 만들어서 제목이 149예요.
라이너스의 담요 연진: 나를 있는 그대로 사랑해 줄 사람 완전 대모집합니다. (남자 몇 명이 저요 하며 손 들자) 나를 있는 그대로 사랑해 줄 순 없을 껄!?
라이너스의 담요 연진: 있다가 제가 전자양 세션으로 가는데, 언니네 이발관한테 캐발릴까봐 다들 완전 걱정 중이예요. (전자양과 언니네 이발관이 같은 시간)
마이 앤트 메리: (마지막 곡을 앞두고) 여러분 있다가 앵콜 하실 건가요? (네~) 네 그러면 마지막 곡이랑 이어서 가겠습니다.
전자양: (잠시 곡이 끝나고 조용한 사이, 옆 공연장 소리가 크게 들리자) 중간 중간에 썰렁할 때 BG깔아 주시고 역시 좋네요! 선배님 감사합니다! (약간 씁쓸하지만 긍정적인 어조로)
전자양: (다시 다음 조용한 사이, 언니네 이발관 노래가 들리자) 언니네 이발관 새 앨범 좋더라구요. 사실 저도 공연 보고 싶었는데, 공연을 해야하네.. (밝은 어조로)

"지는 해 파이썬"에 대해

Hye-Shik Chang — Wed, 15 Oct 2008 04:10:16 -0000

며칠 전에 올린 글에서 파이썬을 "지는 해"라고 표현했던 것이 많은 분들의 반향을 일으켰는데요~ 파이썬이 망해간다는 걸로 이해하시는 분들이 많아서, 의도를 명확하게 하려고 좀 부연 설명을 달아 봅니다.

"뜨는 해"인 언어들의 특징은 이런 게 있습니다.

주로 좋다고 하는 사람들은 초괴짜 개발자 아니면 손보다 입으로 더 많이 개발하는 컨설턴트들이다.
뭔가 사소한 문제가 생기면 해결법을 찾는게 무척 재미있다. 그렇지만 보통 한 나절은 걸리고, 결론적으로 인터프리터나 표준 라이브러리를 고쳐서 본의 아니게 "오픈소스에 기여"하게 되어 뿌듯하다.
대부분 사람들은 해 보면 재미있겠다고 생각하지만, 실제로 회사에서 쓰게 되면 그 날로 발목 잡혀서 휴가도 못 간다. 그래서 감히 해 볼 엄두를 못 낸다.
라이브러리나 문서를 찾다보면 없어서 결국 "아 재미있겠는데!"하고 한참 재미를 보다보면, 본의 아니게 라이브러리도 만들고 문서도 쓰고 해서, 자기 이름이 검색엔진에 많이 걸리고 알아보는 사람이 늘어난다.

반면에 "지는 해"인 언어들은 이런 게 있겠죠.

특별히 회사에서 얘기를 안 해도 상사가 이번 프로젝트에서 그 언어를 써 보면 어떻겠냐고 추천한다.
더 이상 제품 설명서나 홍보에 "이 제품은 어떤어떤 언어로 만들었습니다."를 안 적는다.
뭔가 몰라서 검색엔진이나 게시판을 찾아보면 똑같은 문제를 다른 사람이 다 겪어보고 경험을 적어놔서 따라하면 된다.
그 언어를 하는 사람을 찾는 구인 광고를 자주 본다.
라이브러리가 필요해서 찾으면 이미 여러 개가 있어서 뭐가 좋은지 보고 받으면 된다.

저는 이미 한국에서 파이썬이 적합한 분야에는 적절한 빈도로 사용되고 있다고 봅니다. SI나 시스템관리, 게임, 그래픽, 운영체제 같은 전통적인 컴퓨터 분야 뿐만 아니라, 과학계산, 기계공학, 생산관리, 음악, 아파트, 전화기 등등 수많은 분야에서 도입돼서 쓸만한 분야에서는 웬만한 개발자들은 "파이썬"을 한 번 쯤은 들어봤습니다. 이제 여기서 더 파이썬을 쓰는 곳이 늘어난다면, 그건 파이썬이 잘 해서라기 보다는 그냥 그 분야가 확장됐다거나 변화했다고 볼 수도 있을 정도입니다.

"지는 해"라고 "망해가는 언어"가 아니라, 이제 뜨는 과정이 어느 정도 됐으니 큰 고생 없이 쓸 수 있다는 것을 의도했습니다. 해는 대략 12시에 중천에 뜨지만, 사람들은 대부분 오후와 밤에 생활하지 않습니까? C는 벌써 20년째 지는 해인데도 여전히 많은 분야에서 건재하죠.

꽃별천지

Hye-Shik Chang — Wed, 15 Oct 2008 02:59:42 -0000

suapapa님께서 재미있는 걸 하셨기에 저도 import 해서 꽃별천지를!

>>> import LoveIn as l
>>> def gbcj(name):
...     return u"지꽃별천"[sum(l._getStrokeCnt(ch) for ch in name) % 4]
... 
>>> print gbcj(u'장혜식')
지

흑흑.. 지옥으로.. T_T

그렇다면.. "그 분"은..

>>> print gbcj(u'임수정')
별

아 이름을 개명해야겠어요