July 2006 – OpenLook

애자일 컨설팅의 영향력!

July 28, 2006 by hyeshik

어제 저도 여기 올린 적이 있는 대안언어축제 2006 참가신청이 굉장한 성황을 이루며 불과 하루만에 150명이 마감되고 대기자가 거의 20명이 되고 있습니다. 상상을 뛰어넘는 이 상황에 아주 감동받고 있습니다. -O-; 처음에 소프트웨어진흥원측과 얘기할 때 과연 200명의 열성적 참가자를 쉽게 모을 수 있을까 생각을 했었는데, 이거 400명으로 해도 며칠 안 가겠네요! +_+

과연 어디서 오셨을까 궁금해서, HTTP 참조 페이지 주소로 통계내어 보았습니다. (방문 수)

애자일 컨설팅: 182
세종대 동아리: 25
오픈룩: 21
여러 네이버 까페 글: 17
0pen.us: 12
xper.org: 7
rubyist.or.kr: 7
kylix.co.kr : 6 (주의: 불여우에서 보면 거의 레드썬입니다 -ㅇ-)
여러 싸이클럽 글: 5
classpath.egloos.com: 4
objectworld: 3

애자일 컨설팅의 위력이란! 이번 대안언어축제는 상당히 XP적인 분위기가 날 것 같습니다. ^.^ 게다가, 전체 방문자 수가 250명을 넘지 않는데, 170명 정도 신청하셨다는게, 대안언어축제 참가자 분들은 모두 열의가 가득차 계실 것 같네요!

이제 대기자가 쌓이고 있지만, 그래도 혹시나 꼭 참여해야겠다 싶으시면, 자주 방문하시면 언젠가 깜짝 등록이 약간 있을 지도 모르겠습니다. 🙂

수요일에 밤을 새면

July 27, 2006 by hyeshik

여전히 드는 무의식중에 생각이..

4시부터 7시까지 나우누리 정기점검하느라 심심하겠다;

9월의 행사

July 27, 2006 by hyeshik

9월에 두 행사에서 발표를 맡았습니다. 혹시 직접 만나서 물어보실 것이 있으시거나, 전해주시고 싶은 선물-ㅇ- 이 있으시면 오시면 좋을 것 같습니다. ^o^

9월 1일~3일: 대안언어축제에서 Io언어 튜토리얼을 1시간 30분 정도 진행합니다. Io 언어는 문법이 안 독특한 듯 하면서도, 독특하고 자유도가 별로인 것 같으면서도 굉장히 자유로운 재미있는 성질이 있는데요, 혼자 공부하기 귀찮으시면 오셔서 같이~ 물론, 대안언어축제의 다른 행사들도 ∑n=0,∞{정말정말} 재미있습니다. 요즘 참가신청을 받고 있으니 일정을 확인해 보시고 등록하세요~ (마감임박!)

9월 17일: KLDP 10주년 기념 컨퍼런스에서 “오픈소스 프로젝트에 참여하기”라는 제목으로 발표할 예정입니다. 그냥 사용자로써 종종 불편한 점을 패치해서 개발자들에게 보내주는 방법부터 개발자가 되기 위한 중간 과정, 개발자가 되고 나서 있는 여러 인간관계까지 다양한 상황에 대한 소개를 조금씩 해드리려고 합니다. 구글의 Greg Stein도 온다고 하니, 구글에 관심 있는 분들도 오시면 재미있을 것 같네요~ — 아마 Greg Stein의 발표는 그동안의 발표 내용으로 미루어보아 Python과 MySQL에 대한 내용이 주가 되지 않을까 생각합니다.

최적화와 수학

July 26, 2006 by hyeshik

애자일 블로그에 올라온 프로그래머와 수학을 읽고 전에 경험했던 것을 짧게 써 봅니다.

프로그램을 하다보면, 뭔가 하고 있는 것이 비효율적인 것 같은 느낌이 약간은 들지만, 최적화가 충분히 되어있다고 느낄 때가 많습니다. 더 속도가 필요하다면, 더 빠른 언어와 여러 트릭을 동원해서 빠르게 하곤 합니다. 극단적인 경우를 예를 들어서, 항상 예제로 많이 쓰이는 피보나치 수열을 한 번 보겠습니다. 실제 프로그래밍이 피보나치 수열처럼 간단한 루틴일 리도 없고 그렇게 반복적으로 호출될 일은 없겠지만, 그래도 극단적인 예를 보면, 그 특징을 다른 곳에서 활용할 수 있을테니까요~

일반적으로 피보나치 수열 n번째를 구하는 루틴은 파이썬으로 이렇게 합니다.

def fib(n):
    a, b = 1, 1
    for i in xrange(n):
        a, b = b, a+b
    return a

def fib(n):

a, b = 1, 1

for i in xrange(n):

a, b = b, a+b

return a

만약 피보나치 수열의 200005번째 수 “주변”의 것이 정확할 필요는 없고 대충의 값이 필요해서 호출한다면, 제 컴퓨터에서는 대충 2.82초 정도가 걸립니다. 그런데, 이런 루틴이 적어도 초당 100번 이상은 호출되어야 하는 상황이 왔다고 치면 보통 이런 대안을 생각합니다.

파이썬이 느리니까 C로 하자!
a, b는 터플이 묶였다가 풀리면서 메모리 할당을 하니까 따로 따로 하게 2줄로 분리해 보자.
내가 요새 어셈블리에 재미를 붙였는데, 어셈블리로 하면 레지스터도 충분히 활용하고 빠르지 않을까?
루프를 매번 돌리는 것은 비효율적이니까, 16번에 한번씩 돌게 풀어쓰면(unroll) 빨라질거야!

자.. 그런데, 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

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)   ))

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?》에서

붙임: 중간에 든 예가 좀 과장이 심해서 죄송 -ㅇ-; 글의 원래의도가 피보나치 수열을 최적화하자는 것은 아닙니다. ^^;

대학원 지원에 대한 조언을 구합니다~

July 25, 2006 by hyeshik

언제 졸업할 지 까마득했던 저도 이제 2007년 2월에 졸업하게 되었습니다. ^^; 하고 싶었던 길에 좀 더 가까이 가기 위해서, 여러모로 알아봐서 이제 다음 주부터 원서를 접수하는 대전에 있는 모대학의 바이오시스템학과에 지원해 보려고 합니다.

그래서 여러 분야에 경험이 많으신 오픈룩 독자 여러분께 조언을 구해 봅니다. 뭔가 구체적으로 물어볼 것이 있는 것은 아니고요~ 원서 작성할 때 알아두면 좋은 점, 인터뷰 들어갈 때 알아두면 좋은 점 이라던지 연구실 선택의 주의점, 다른 학교가는 것이 좋지 않겠느냐 등등 여러가지 임의의 주제 어떤 말씀이든 좋습니다~

주변 설명을 드리자면, 저는 지금 다니고 있는 과는 기계전자공학부인데, 전공은 정보산업공학입니다. 그리고, 부전공으로 생명공학을 하고 있긴 하지만, 아직 1학기 남았기 때문에 부전공 승인이 난 상태는 아닙니다. 생물 분야에서는 아직 시작한지 얼마 되지 않아서 기초적인 유기화학, 생화학, 미생물학, 물리화학, 생체공학 같은 것만 들었고요, 분자생물학이나 세포생물학은 다음 학기에.. 제 관심 분야는 단백질 3/4차 구조/기능 예측, 컴퓨터-보조 단백질 설계, complex gene regulation network modelling 분야입니다. 그리고, 난감하게도, 다른 보통 지원자들에 비해서 학점이 택도없이 낮기떄문에 별로 상황이 좋지는 않은 편입니다. 아하하 ^^; (그래도 혹시나 하고 한 번 –;)

말씀 부탁드리며 (_ _)*

파이썬 2.5 미리 보기: 8편 절대/상대 경로 임포트

July 24, 2006 by hyeshik

이전 연재 보기

파이썬 2.5 미리보기 이제 마지막회입니다. 파이썬 2.4에서 import 뒤에 괄호치기 같은 문법이 약간 들어왔는데, 2.5에서는 PEP-328 상대경로 import가 들어왔습니다.

파이썬의 패키지 구조는 다단계 구조입니다. 그래서, 패키지를 구성할 때 한참 밑에 들어가 있는 모듈이 상위 단계에 있는 모듈을 들여오기 위해서는 항상 전체 경로를 다 써야 했습니다. 예를 들어서, 다음과 같이 패키지 구조가 구성되어있다고 할 때,

twisted +-- internet +-- iocpreactor --- proactor.py
        |            +-- defer.py
        |            +-- base.py
        +-- plugin.py

twisted +-- internet +-- iocpreactor --- proactor.py

| +-- defer.py

| +-- base.py

+-- plugin.py

defer 모듈에서 proactor 모듈을 임포트 하려면 이런 방법이 있습니다.

[1] from twisted.internet.iocpreactor import proactor
[2] from iocpreactor import proactor

1 2	[1] from twisted.internet.iocpreactor import proactor [2] from iocpreactor import proactor

그리고, defer 에서 base를 들여오는 방법도 2가지 방법이 있습니다.

[3] from twisted.internet import base
[4] import base

1 2	[3] from twisted.internet import base [4] import base

[1]과 [2], [3]과 [4]는 각각 대충 보시다시피 각각 절대경로와 상대경로의 차이입니다. 그동안 권고사항으로 패키지 안에서는 꼭 절대경로로 임포트해 주세용~ 이라고 항상 말을 해 오긴 했지만, 대부분의 파이썬 사용자들이 직접 파이썬 매뉴얼을 읽고 공부하는 것이 아니기 때문에, 필드에서는 상대경로가 더 많이 통용되고 있었습니다. 그런데, 여기서 심각한 문제가 발생하는데, 상대경로 임포트가 시점에 따라서 중복으로 임포트 되어서 오작동을 하거나, 엉뚱한 것이 임포트되기도 하고, base같은 흔한 모듈은 더욱 더 큰 문제가 되곤 했습니다.

그래서, 파이썬 2.6부터는 절대경로 임포트를 강제화해서, 위의 예에서 [2]와 [4]같은 것은 이제 더이상 허용되지 않습니다. 대신, 이제 상대경로라는 것을 명시적으로 지정하는 문법이 새로 들어왔습니다.

# defer에서 base 임포트
from . import base     # 같은 디렉토리

# defer에서 proactor 임포트
from .iocpreactor import proactor    # 하위 디렉토리

# proactor에서 defer 임포트
from .. import defer    # 상위 디렉토리

# plugin에서 defer 임포트
from ..internet import plugin   # 상위 디렉토리의 다른 하위 디렉토리

# defer에서 base 임포트

from . import base # 같은 디렉토리

# defer에서 proactor 임포트

from .iocpreactor import proactor # 하위 디렉토리

# proactor에서 defer 임포트

from .. import defer # 상위 디렉토리

# plugin에서 defer 임포트

from ..internet import plugin # 상위 디렉토리의 다른 하위 디렉토리

음… 저는 그냥 앞으로도 계속 절대경로로 쓰고 싶어지네요 –;;;;;;

《번역은 반역인가》 – 박상익

July 19, 2006 by hyeshik

안정효씨의 다른 책을 찾으러 도서관에 갔다가, 확 눈에 띄는 빨간 색의 표지 때문에
이 책을 발견했습니다. 서양사 관련 도서를 많이 번역하신 어느 교수님이 쓰셨는데,
표지에서부터 “대학원생들에게 번역 하청을 맡긴 교수가 떳떳이 활동하는 사회..”
라고 짧은 글로 한국 번역문화의 문제점을 확실히 드러내고 있습니다.

이 책은 처음에 번역이 역사적으로 문명의 발전에 기여해온 배경, 한국 번역서의
역사적 흐름을 분석하는 것으로 시작하고 있습니다. 유럽 사회가 본격적으로 발전하기
시작한 것이 이슬람과 그리스 책들을 번역한 서적들이 누적되면서라는 점이
설득력있게 전개되어 있습니다. 유럽 사회는 왠지 아주 태고적부터 발전되었지
않았을까 누구나 생각을 해 왔겠지만, 이슬람에 한참 뒤쳐진 거의 야만인 시절의
시기에 선구적인 번역가 집단들의 노력으로, 옛날에 축적된 지식들이 자국어 문화로
편입되면서 발전의 토대를 쌓을 수 있었다고 합니다.

저도 지금까지는 번역을 그냥 시간을 절약시켜 주는 정도로 별것 아니게 생각을
하고 있었습니다. 그런데, 오랫동안 양쪽언어를 모두 했던 유명한 문학가들도
모국어책에서 훨씬 느낌이 정확하게 와 닿고 정보의 양이 차이가 확실하다는
점에서 확실히 번역서가 있고 없고는 해당 국가의 문화에 들어갔는가 아닌가의
차이가 되어 버린다는 생각에 자연스럽게 끄덕이게 됩니다.

우리는 거인의 어깨 위에 올라탄 난쟁이와 같아서, 그 어깨로부터 거인들보다
더 멀리 많은 사물을 볼 수 있으니, 이는 우리의 시력이 예민하거나
우리의 재능이 출중해서가 아니라 우리가 그들의 거인다운 위대함에 의해
지탱되고 고양되기 때문이다. — 52페이지 (사르트르의 베르베르의 말을 재인용)

그런 면에서, 번역서의 품질은 결국 그 문화의 깊이와 넓이를 결정하는 중요한
영향을 미치게 되고, 지금같이 오히려 원문보다도 읽기 힘든 번역서가 판치는
상황은 분명히 문제가 심각합니다.

그러나, 번역을 해 보신 분들은 모두 알 수 있듯이, 한국 출판계의 상황은
별로 좋은 품질로 번역서가 나올 만한 상황이 아닙니다. 열심히 노력해서
번역해 봐야 시급으로 따지면 편의점 알바보다도 못한 보수가 나오는 상황에서
여간 재력이 있지 않고서는 번역을 제대로 하고 싶어도 할 수가 없습니다.
그래서, 그 유명한 (삭제) 책이 나오는
것이 어찌보면 사회적으로 당연한 결과가 아닐까 싶습니다.

번역을 이처럼 하찮게 여기는 것은 우리의 학풍이 이 땅에 발을 딛고 있지 않음을 보여주는 피할 수 없는 증거로 여겨진다. 이 땅에서 살면서 마치 자신이 미국 시민인 것처럼 행동하고, 한국 대학에서 월급을 받으면서도 마치 미국 대학의 교수인 것처럼 행동하는 그들의 모습에서 안타깝게도 ‘주체’에 대한 진지한 고민을 찾아보기 힘들다.
— 207페이지

원서로 안 읽는 후배녀석들을 구박할 때, 그게 당연하다고 생각하는 것보다는
기초학문 정도는 모국어로도 충분히 배울 수 있어서, 본인이 관심만 있다면
12살짜리 커미터, 13살짜리 SCI 논문 발표자가 될 수도 있는 환경이
되었으면 합니다. 그러기 위해서, 정부의 장기적인 지원, 학계의 번역에 대한
인식 재고, 도서관 문화의 개선 등 여러가지 해결책이 이 책에 제시되어 있습니다.
지금이라도 번역에 대한 생각을 제대로 정리할 수 있게 되어서 무척 다행입니다. ^^

저도 이제 파이썬 마을에서 답글 달 때, 영어로 된 매뉴얼에 링크 덜렁 달고
끝내지 않도록 노력하겠습니다;; (반성~)

4천5백만 국민들을 위한 지적 인프라를 구축하는데 투입되는
정부 1년 예산이 서울 강남의 아파트 1채 값이다.
— 224페이지

PuTTY 사용법이 나온 책~

July 19, 2006 by hyeshik

KLDP의 GunSmoke님께서 쓰신 책에 친절하게 한글PuTTY를 소개해 주셨습니다. 책 제목은
《Fedora 리눅스 네트워크 & 웹 서버 무작정 따라하기》 이네요~

책 내용은 제가 페도라를 써 본적이 없어서 잘 읽어보지는 않았지만, 다음에 페도라 쓸 일이 생기면 한번;; -O-; 표지가 무척 깔끔하고 제책이 튼튼하게 잘 되어 있으니 리눅스 시스템 관리자로 입문하시는 분들은 옆에 두고 보기 괜찮을 것 같네요. ^^;;

파이썬 2.5 미리 보기: 7편 표준 라이브러리

July 19, 2006 by hyeshik

이전 연재 보기

파이썬 2.5b2가 며칠 전에 발표되었고, 이제 2.5 최종 릴리스가 바싹 다가오고 있습니다. 오랜만에 파이썬 2.5 미리보기를 이어서 ^^;
오늘은 라이브러리 변화를 간단하게 요점정리해 드리겠습니다~

functools 모듈

이번 파이썬 2.5에서 처음 들어오는 모듈로 PEP-309 Partial 을 포함한 functools 모듈이 있습니다. 아주 옛날에 오픈룩에서 소개해드린 적이 있는 놈입니다. (거의 알박기 식으로 구현을 해 놓은 느낌이;;) 로그를 남기거나, 함수에 들어갈 인자를 여기저기서 조금씩 주거나 할 때, 등등 아주 유용하게 쓸 수 있겠죠~ 특히 함수형 언어 하시던 분들은 반가우실 것 같습니다. ^^;

잘 생긴 AMK의 Functional How-To에서 좀 더 깊은 함수형 프로그래밍의 활용을 다루고 있으니, 읽어보세요 +_+

ctypes

ctypes가 들어왔습니다. 자세한 것은 미리보기 4편에서 소개해 드렸습니다.

ElementTree

가장 파이썬답게 XML을 파싱할 수 있는 라이브러리인 effbot의 ElementTree도 표준 라이브러리로 들어왔습니다. 자세한 내용은 전에 블로그에서 소개해 드린 적이 있습니다. 요새 드는 생각이, BeautifulSoup도 표준 라이브러리로 들어오면 좋지 않을까 하는.. 으흐흐.. 온통 BeautifulSoup.py를 포함해서 배포하는 프로그램들이 여기저기 널려있어서;;

hashlib

전에 한번 오픈룩에서 언급한 적이 있는데, 기존의 md5, sha 모듈 등을 모두 합쳐서 통합된 API로 쓸 수 있게 hashlib이 들어왔습니다. 이제 sha-512까지도 지원하기 때문에, 아직까지는 콜리젼이 발견되지 않은 높은 수준의 해시도 선택적으로 쓸 수 있게 되었습니다.

sqlite3

요즘 전성기를 누리고 있는 파일기반 내장용 SQL 데이터베이스인 SQLite와 DB-API 2.0 어댑터 라이브러리가 들어왔습니다. 아마 대부분의 오픈소스 배포판에서는 라이브러리 의존성 때문에 별도의 패키지로 떨어져서 돌아다니겠지만, MS윈도우에서는 파이썬 인스톨러로 깔면 sqlite3 모듈을 바로 쓸 수 있게 되었습니다. (FreeBSD에서는 databases/py-sqlite3 모듈로 따로 분리하였습니다.)

wsgiref

PEP-333 Python Web Server Gateway Interface에서 정해진 스펙을 구현한 참조구현 라이브러리입니다. WSGI는 그동안 CGI,
Twisted,
Zope,
CherryPy,
mod_python 등이 모두 따로따로 서로 다른 API를 쓰고 있으면서도 비슷한 기능을 지원하고 있었기 때문에, 쓸데없이 포팅이 귀찮았던 문제를 해결하기 위해 정의된 놈입니다. 그래서, WSGI 규약만 제대로 지키면, 모듈 하나만 제대로 구현해서, Twisted에서 돌아가던 것을 mod_python에서도 돌릴 수 있고, Zope에서도 돌릴 수도 있고 여러모로 활용이 편하게 되었습니다. wsgiref는 독립서버로 작동하는 참조구현 모듈입니다. 테스트에도 간단하게 쓸 수 있겠죠~

그 외에는~

앞의 큼직큼직한 변화 외에도, 자잘한 라이브러리 버그 수정과 성능 향상, 기능 추가가 많이 있었습니다. 그 중에 뚜렷한 변화 몇 가지만 추려 보자면,

mailbox 모듈이 메일 내용을 수정하고, 삭제할 수 있게 되었습니다.
codecs.lookup()에서 이제 터플을 돌려주지 않고, stat_result 같은 흉내내는 놈을 돌려줍니다.
쓰레드 lock을 지원하는 데코레이터들이 들어있는 contextlib 모듈이 들어왔습니다.
utf-8-sig 코덱이 추가되었습니다. 윈도우 사용자 중에서 메모장으로 코딩하시는 분들도 이제 utf-8로 저장해서 파이썬으로 실행할 수 있습니다. –;
webbrowser 모듈이 최신 브라우저들에 대한 지원을 대폭 강화하였습니다.
locale 모듈에서 LANG이 LC_CTYPE보다 우선시돼서 생겼던 버그가 수정되었습니다.
그동안 이름없이 seek을 해야 했던 슬픔이 해결되었습니다. os 모듈에 SEEK_SET, SEEK_CUR, SEEK_END 상수가 들어왔습니다.

libgcrypt SEED 패치

July 11, 2006 by hyeshik

지난 번에 OpenSSL SEED 패치를 했었는데,
아직 개발자들의 관심을 끌지 못해서 들어가지 못했습니다.
그래서 우선 다른 암호 라이브러리들에도 집어 넣어려고
OpenSSL, nss에 이은 오픈소스 암호 라이브러리 인기순위 3위쯤 되는 녀석인 libgcrypt에
패치를 만들어서 제출했습니다.

libgcrypt는 아무래도 나중에 나온 것이다보니, 처음부터 디자인을
상당히 현대적인 모양으로 구성을 해서 OpenSSL에 비해서는 거의
작업할 곳이 5분의 1정도로 적었습니다. 한가지 작업을 할 때 고쳐야
하는 곳이 얼마나 흩어져 있느냐가 역시 중요한 소프트웨어 디자인
수준의 척도인 것 같군요. libgcrypt는 LGPL이기 때문에 완전히
자유롭게 쓸 수는 없지만, 그래도 gnupg에서도 쓰고
생각보다 GNU 계열의 프로그램들에서 많이 쓰고 있는 듯 합니다.
이 패치를 넣으면 gnupg에서 SEED로 싸인하는 것도 어쩌면 될지도 모르겠습니다. (? 안 해봐서 장담은.. ^^;;)

단지 하나 걱정되는 것은 libgcrypt도 별로 요새 개발이 활발한 편이 아니라.. 대충 예상하기에 들어가자면 6개월 이상은 걸릴 것 같네요 –;;