Experiments never fail

쾌락과 고통

(yong27) — Sat, 03 Jan 2009 11:05:04 +0900

어떻게 진화가 가능했을까? 이 질문은 생명현상에 대한 근본적인 질문이다. 나는 오늘도 나 자신을 보며 혹은 이 세상을 보며 그 답을 생각해 본다.

언제쯤부터였을까? 유전자는 쾌락중추와 고통중추를 설계했다. 그 이전의 어떤 성과물보다도 효율적인 장치임에는 틀림이 없다. 진화에 도움이 되는 방향의 자극에 대해 두뇌 및 신경 어느 부분에 쾌락이란 느낌을 선사하고, 유전자 자신에게 해가 되는 방향의 자극에 대해서는 고통이란 느낌을 느끼게 함으로써, 자신의 불멸을 향한 첫 안전장치를 만들어냈다. 이로써 생존기계는 유전자의 노예가 됐다. 그것도 아주 충실하고 순종하는.

식욕, 성욕 등을 통한 쾌락과 안 좋은 자세에서 나오는 허리의 통증 등의 고통은 우리의 뇌 어디에선가 방출되는 신호일 뿐이다 라는 것은 다 알고 있다. 단지 신호일 뿐인데, 어찌나 신경중추와 밀접하게 연결되어 있는지 그리고 그 강도가 심각한지 우리는 그 신호에 거스를 수 없다. 매트릭스의 사이퍼가 본질보다 그 신호를 더 중요하게 여기는 것도 이해가 간다.

이 쾌락과 고통중추는 그 생물학적 장치를 넘어 사회적으로도 영향을 확장한다. 연인을 향한 사랑의 감정, 자식을 향한 감정, 혹은 사회적인 기여를 통한 명예 등은 생물학적 장치 없이 감정만으로도 쾌락을 준다. 고통도 마찬가지다. 실연의 아픔을 두려워하여 다른 방향을 취한다든가 등등. 고통을 멀리함으로써 안전을 도모한다. 중요한 것은 이것 역시 진화에 도움이 되는 방향이라는 것. 유전자의 명령은 직접, 혹은 하나 건너뛰어 간접적으로도 진화에 관여한다.

내가 만일 진화 시뮬레이션을 설계한다면 어떻게 객체에 쾌락과 고통중추를 장착할 수 있을까? 단지 점수를 주고 그 점수가 높아야만 생존하는 모델만 가지고는 나 자신처럼 동작하지 않을 것 같다. 어떻게 보면 이것이 자아를 만들어내는 근본적인 질문인 것 같다. 욕구를 추구하고 고통을 회피한다는. 더불어 복잡한 진화를 가능하게 한 비밀인 것도 같다.

2009년의 시작

(yong27) — Thu, 01 Jan 2009 14:19:49 +0900

매년 한해의 시작전에 포스팅(예, 2007년)을 했었는데... 2008년에는 안했다는. 그때 당시에는 쓰나 안쓰나 별 차이없는 것 아닐까 하며 지나쳤는데, 역시나 회고와 각오의 기억이 없으니 슬며시 잊혀지는것이 이대로는 안되겠다싶어 기록차원에서라도 남겨야겠다.

올해 연말에는 기년회 참석을 계기로 혼자서 지난해 결산의 시간을 가졌었다. 블로그와 위키로그, 이메일 저장소 1년치를 두루 둘러보며 올해는 이런일이 있었구나 하며 회고해볼 수 있었다. 기년회 발표시간에도 소개했었던 나의 뿌듯했던 일들 몇가지.

1, 책 시크릿을 읽고 나의 미래에 대한 자기확신을 가질 수 있었던 것이 기억에 남는다. 단순한 자기믿음을 넘어 각오와 작은 습관들이 모여 미래를 변화시킬 것이란 생각을 했고, 올해 성공적으로 습관이 된 두가지는 출근길 영어 팟캐스트 청취와 잠들기전 요가 및 스트레칭 20분. 이는 영어에 자신감을 갖게했고, 1년내내 건강한 몸상태를 유지할 수 있게 했다. (내년엔 적절한 피드백으로 습관의 성과의 질을 높히는 방안을 연구해야지)

2. 구글리더로 RSS리더기를 바꾼 뒤, 접하는 정보용량이 많이 증가했다. 읽기로 한 포스트는 모두 읽었다. 훑어만 본다 혹은 넘 많은 피드라 강박관념이 생긴다 등의 단점도 있지만, 내 머리속 어딘가에 남아서, 아, 그런것이 있었지 라고 떠올릴 수 있다는 점은 큰 장점이다. 좀 더 노력하고 성장하여 나도 좋은 글을 쓰고 싶다는 다짐까지.

3. 고군분투했던 올해 정보화 용역사업. 예전엔 연구용 소프트웨어라는 명목아래 해당 기능의 구현만 만들고 끝이였던 것을 올해 과제를 통해 좀 더 체계있고, 기반있는 프로그램를 만들 수 있는 기회를 가질 수 있었다. "지속가능성" 이라는 화두 아래 어떻게 하면 서버가, 데몬 프로세스가, 프로젝트가, 팀워크가, 개인발전이 지속적으로 동작할 수 있을까를 고민했었고, 프로젝트 측면에서 문서화, 테스트, 소스코드관리, 백업, 매뉴얼, 사업스케줄관리, 사용자 접근성등을 탄탄히 할 수 있었다.

뿌듯했던 점 들 이외에 아쉬운 면도 있는데 작업불발이 제일 기억남는다. (다음엔 실수하지 않을테야 ㅡ.ㅡ;) 음... 살사공연팀을 만들고 직접 우리힘으로 공연해낸 기억도 좋았고, 미투데이 자주 쓰면서 다양한 사람들을 온라인에서 만났던 점도 좋았다. 오늘 부터 시작되는 2009년에는 꼭 뿌듯했으면 하는 것들 몇가지.

1. 일에 끌려다니기 보다 여유롭게 일하고 싶다. 강한자가 여유롭다고 했던가. 일할 때는 몰입을 통해 최고의 작품을 만들고, 일하지 않을 때는 여유롭게 인생을 즐기고 느끼고 싶다. 그래야 그동안 부족했던 인간관계적 부분을 잘 해나갈 수 있을꺼야.

2. 나에게 자부심이 되는 프로그램을 만들고 싶다. 오픈소스로 추진해서 많은 사람들과 같이 할 수 있으면 더 좋겠다. 왜 그동안 내가 만든 그 무언가에 자신이 없었을까. 실력이 부족하고, 지속적 관심이 없어 그대로 잊혀지는 것들. 이제는 자부심을 가질 만한 뭔가를 만들어 내고 싶다.

내가 원하든 원하지 않든 시간은 정확한 속도로 흘러간다. 1분스피치로 얘기할 때 처럼, 하고싶은 말이 많건 적건간에 1분을 채워야하고 또 1분안에 끝내야한다. 넋놓고 시간을 흘려보내서도 안되고, 과중한 무게로 인생의 시간을 고달피 만들어도 안된다. 이제는 시간을 보내는 방법을 알때도 되지 않았을까. 2009년은 잘 보냈다 싶은 한해가 되어야 겠다. 1년뒤 이글 보고 뿌듯할 수 있기를.

이 블로그 오시는 분들도 "시간관리"성공하시고, 새해 좋은일 가득하시기 바랍니다.

OBK 작은모임

(yong27) — Sun, 07 Dec 2008 10:00:49 +0900

오태윤님이 추진했던 OBK 작은 모임에 다녀왔다. Open Bioinformatics Korea 우리나라에서 오픈(소스) 생물정보학 연구를 목표로 하는 모임이다. 그간 생물정보관련 커뮤니티활동이 그다지 활발하지 못했지만, 이 모임을 시작으로 많은 변화를 기대해본다. 각개전투로 살아남았던 업계 분들이 하나둘 모이면서 더 큰 시너지를 낼 수 있을 듯.

연구란 것이 골방에 틀어박혀 혼자서 맨땅헤딩하는 것이 아니라, 자꾸 끄집어내어 다른 사람들과 의사소통하고 공유하는 것이 더 중요하다는 것을 느끼게 했다. 박찬희님 말씀대로 이제 시대가 된 듯하다. 자신의 연구분야를 숨기고 방벽을 치는 것이 아니라 널리 알리고 조언을 구하기.

그런 의미에서 오태윤님의 시도는 매우 좋았다. 자신이 그동안 혼자서 끙끙 앓아야 했던 문제들을 사람들에게 내어 놓음으로써 다른사람들의 조언을 얻을 수 있었고, 다른 사람 역시 새로운 아이디어에 대해 접하고 토론할 수 있는 기회를 가질 수 있었다.

유전자 및 용어 네트워크를 그리는 내용에서는 지난 시맨틱 웹세미나의 네트워크 드로잉 시연을 기억나게 했다. 가중치의 개념을 잘 적용하고 적절하게 네트워크를 다듬으면 좀 더 실질적인 의미를 찾아볼 수 있을 듯.

OBK에서는 앞으로 작은 세미나 형식으로 각자의 관심분야를 발표하면서 모임에서 할 수 있는 주제를 좁혀보기로 했다. 관심있는 분들의 많은 참여를 기대해 본다.

테스트 강박

(yong27) — Fri, 28 Nov 2008 15:19:22 +0900

정보화용역사업 마무리즈음 백업서비스를 구현해야 할 일이 생겼다. 장고 데이터 덤프기능을 이용하여 데이터 백업하고, 사용자 업로드 파일디렉토리는 rdiff-backup을 쓰면 깔끔하겠다 생각하고는 쉘스크립트. (cron으로 하루 1회 백업하고, 30일 지난 것 지우기)

#!/bin/sh

rdiff-backup /usr/local/dsite /home/agrims_backup/file
rdiff-backup --remove-older-than 30D /home/agrims_backup/file
/usr/local/bin/python /usr/local/dsite/manage.py dumpdata > /home/agrims_backup/db/dump_`date '+%Y%m%d.json'` 2>&1

앗, 쉘스크립트로 dump_20081101.json 이렇게 되어 있는 파일의 30일 이전 것을 어떻게 찾지? 음냐; 저부분은 파이썬으로!

#!/usr/local/bin/python

import sys, os
from datetime import date, timedelta

target = sys.argv[1]
for d in os.listdir(target):
if d.startswith('dump_'):
year = int(d[5:9])
month = int(d[9:11])
day = int(d[11:13])
file_date = date(year,month,day)
if date.today() - file_date > timedelta(30):
os.remove(os.path.join(target, d))

잘 돌아가나 확인을 해봐야하는데, 음... 대충 target 디렉토리에 빈 파일 넣어보고 돌려본다. 잘 되네... 그러고 넘어가려던 중 갑자기 어제 읽은 포스트가 생각났다.

저는 테스트 케이스가 없는 코드를 레거시 코드로 봅니다. ... 테스트 없는 코드는 나쁜 코드입니다. 얼마나 잘 짰는지는 중요치 않아요. 아무리 예뻐도, 아무리 객체지향적이어도, 아무리 캡슐화가 잘 되어 있어도 소용 없습니다. 테스트가 있으면 빠르고 검증가능한 방식으로 코드의 행위를 수정할 수 있습니다. 테스트가 없으면 코드가 좋아지고 있는지 나빠지고 있는지 알 방법이 없지요.

꿀꺽. 나도 테스트가 중요하다는 것쯤은 안다고. 음냐; 테스트 만들자. 그간 테스트없어서 고달펐던 몇몇 일들을 떠올리며,,, 아 그리고 며칠전 읽었던 파이썬스러운 용법들 적용해서 멋스럽게~

#!/usr/local/bin/python

import sys, os
from datetime import date, timedelta

def remove_older_than(target, days, basis=None):
if not basis:
basis = date.today()
for d in os.listdir(target):
if d.startswith('dump_'):
year = int(d[5:9])
month = int(d[9:11])
day = int(d[11:13])
file_date = date(year,month,day)
if basis - file_date > timedelta(30):
os.remove(os.path.join(target, d))

def main():
target = sys.argv[1]
days = sys.argv[2]
remove_older_than(target, days)
return 0

import unittest
class RemoveTest(unittest.TestCase):
def test_remove_older_than(self):
days = 30
basis = date(2008, 11, 27)
target = '/tmp'
recent_filename = os.path.join(target, 'dump_20081101.json')
old_filename = os.path.join(target, 'dump_20081001.json')
open(os.path.join(target, 'dump_20081101.json'),'w')
open(os.path.join(target, 'dump_20081001.json'),'w')
self.assert_(os.path.exists(recent_filename))
self.assert_(os.path.exists(old_filename))

remove_older_than(target, days, basis)
self.assert_(os.path.exists(recent_filename))
self.assert_(not os.path.exists(old_filename))

def tearDown(self):
try:
os.remove(os.path.join(target, 'dump_20081101.json'))
os.remove(os.path.join(target, 'dump_20081001.json'))
except:
pass

if __name__=='__main__':
unittest.main()
status = main()
sys.exit(status)

테스트가 생겨서 뿌듯하긴 하다. 하지만 뭔가 아쉬움이 남는 것이 배보다 배꼽인듯한...

시간에 대한 단상

(yong27) — Fri, 21 Nov 2008 19:50:53 +0900

과거로 돌아가고 싶다고 느낄 때가 있다. 뭔가 잘못된거야 과거로 돌아가서 다시 시작하면 얼마나 좋을까. 비슷한 표현으로 이런것도 있다. 다시 태어난다면, 혹은 다음 생에는...

과거로 돌아가는 것이 정말 좋은 것일까?

그 중간에 지금의 자신을 있게 한 정말로 어려웠던 순간들이 있다. 그런것들마저 하기 전으로 돌린다는 이야기인데... 살짝 아쉬움이 남는다. 그간 힘들게 만들어놓은 건데, 사귀어 놓은건데, 다시 돌아가라고? (그래서 그런지 svn revert도 왠만함 잘 안하게 된다.)

그렇다면, 지금 알고있는 것들은 그대로 간직한채 과거로 돌아갈 수 있을까? 음... 아무래도 이건 좀 과한 욕심이다. 과거로 돌아가는 행운을 누린다면 그건 아마도 아무것도 모른채 돌아가는 것일 것이다. 왠지 그래보인다. 영화 쥬만지에서는 다 알고 있는 상태로 과거시점으로 돌아가긴 하던데... 그래서 더더욱 부러워보였던 모습이였다는.

그러고 보면, 아무것도 모른채 돌아가는 과거는 의미가 없다. 돌아간 그 시점의 내가 미래에서 온 나라는 것을 알 수 없다면, 그건 지금을 살고있는 이 순간과 마찬가지다. 미래에서 왔다는 정보가 남아있지 않다면, 그건 지금 현실과 같은 것이니까. 또한 그렇게 돌아간 과거라면 똑같은 삶을 살게 될 것이다. 아무 느낌없이 같은 삶을 반복하겠지. (큭, 가끔씩 느끼는 "지금 이 상황 이거 꿈에서 본것 같아" 이거 미래에서 왔다는 흔적일지도 모르겠다. ㅡ.ㅡ;)

갑자기 상대성이론의 펼쳐진 시간 개념이 이해되는 듯한 느낌이 드는 듯(하지만, 그건 착각이고)... 시간의 흐름이란 정보의 축적이란 작은 결론을 얻는다. 지구가 태양을 4백만 7천번 돌았을 때와 4백만 7천 1번 돌았을 때와는 그사이의 변화에 대한 정보가 존재한다. 그 정보는 지표면에 기록으로 남기도 하고, 인간의 두뇌에 남기도 한다. 펼쳐진 시간의 개념안에서는 이미 정보는 다 정해져 있고 지금 이 순간은 미지의 정보를 읽어가는 과정이 아닐까? 시간의 고정된 속도는 컴퓨터의 고정된 클럭주파수를 떠올리게 한다.

횡설수설.

정보화 용역사업 감리

(yong27) — Sun, 16 Nov 2008 20:42:01 +0900

올해도 작년에 이어 진행중인 정보화 용역과제에 대한 감리를 받았다. 감리때마다 느끼는 것이지만, 지나친 형식에 대한 요구는 늘 부담스럽다. 프로젝트의 성공적 수행이라는 공통의 목표를 갖고 있지만 그 접근방식은 많이 다르다.

감리원분과의 식사기회가 있었다. 이런저런 이야기들을 나누다가 개발자의 환경에 대한 이야기가 나왔다. 감리든 개발사든 좀 더 나은 미래를 위해서는...

나 : 개발자를 북돋아 주는 분위기가 필요한 것이 아닌가?

감 : 더 안좋았던 시절이 있었다. 지금은 많이 좋아진거다.

나 : 이 사진이 적절하게 풍자하고 있긴하다. 개발 자체에 대한 것 보다는 불필요한 요소들이 너무 많다.

감 : 개발자 마인드에서 벗어나야 한다. 개발자 마인드에서만 생각하면 고객의 실질적 요구사항이 무시되기 쉽다. SI 개발사업은 진입장벽이 낮기 때문에 쉽게 진입해서 회사를 설립하기도, 학원등에서 프로그래밍을 한두달 익혀 개발자가 되기도 쉽다. 제대로 된 사업결과를 얻기 위해서는 전문적인 사업관리가 필요하다.

나 : 그렇다고 해도 실제로 중요한 소스코드/개발자 보다 그 외의 것들이 더 중요시 여겨지고 있는 것 같아서 아쉽다.

저 대화를 통해 개발을 바라보는 보통의 시각을 이해할 수 있었다. 아. 진입장벽이 낮다는 이유가 그렇게 연결이 되는 구나. 가장 넓은 스케일을 다루면서도 작은 부분에 치밀해야하고, 창조적이고 논리적이어야 하는 프로그래밍이지만, 한편으로는 아무나 쉽게 일을 맡아서 그르칠 수도 있다. 그렇기 때문에 개발자의 경력을 따지고, 감리라는 것을 통해, 걸러내기도 한다라고.

그건 그렇고, Trac 하나만 잘 쓰면 감리정도는 문제가 아니라고 생각하고 있지만, 감리분들은 오로지 첨부된 오피스포맷의 문서 문서... 티켓닫을 때마다 subversion changeset을 로그로 남기던 습관은 감리에 전혀 도움이 안됐다. 내가 보기엔 매우 중요한 부분인데 말이다.

파이썬과 장고는 비주류?

(yong27) — Fri, 07 Nov 2008 11:42:48 +0900

일반적인 기업(혹은 기관) 전산실 고객은 신규 정보화사업을 구상할 때 생소한 환경을 싫어한다. 관리자 자신에게 익숙한 환경이어야 한다. 들어보지도 못한 환경에 사업성공여부를 맡기고 싶지는 않겠지. 그 생소한 환경이 어떤 장점들과 진보가 있는지는 중요하지 않다. 안전한(?) 성공여부가 중요하다. 그러다 보니, 실제 영업하는 분들도 의례 그 의지를 따라가게 된다.

보통 선호하는 환경이 JSP, PHP이다. 가장 많은 개발자들이 있고, 또 기존 시스템이 그것을 이용해왔기 때문. 예상치 못한 프로젝트 중단의 위험을 생각한다면 가장 많이들 사용하는 언어로 개발하는 것이 위험부담을 최소화한다고 생각한다.

이제는 안정된 개발환경이라고 생각했던 파이썬은 아직까지 생소한 환경이다. 모 프로젝트의 경우, 파이썬으로 만든다고 했더니 나중에 JSP로 바꿀꺼죠? 라는 질문을 들어야 했다. 여전히 비주류 환경이다.

시대가 조금 변하여 어떤 고객이 "루비 온 레일즈 괜찮다던데 어떤가요?" 라고 물어온다. 자바만을 주장하던 예전과는 사뭇 달라진 모습이다. 새로운 장점들이 받아들여지는군 싶지만, "장고"는 모른다. 나의 환경은 여전히 비주류이다. (흑 어째 이놈의 인생은 늘 비주류이더냐 ㅡ.ㅡ;)

비주류일때의 장점도 있다. 얼마 안되는 분들만 하는 환경이다 보니, 상대적으로 실력자가 많고, 친분도 쉽게 쌓을 수 있다. 접하는 문제들이 대개 처음 맞닥뜨리는 것들이고 이것의 해결은 세계적인 주목을 받을 수 있다.

하지만, 아직까지도 파이썬 환경, 그리고 장고 환경이 비주류 취급을 받는 건 좀 아니라고 본다. 파이썬의 넓은 범용성. 구글을 비롯한 다양한 외국사례. 그리고 장고의 세계적 추세, 편리한 사용 및 성능을 보면, 국내에서의 비주류 취급이 억울하다. 이 이유는 우리에게 있는 듯. 자주 사용하고 자꾸자꾸 알려야지.

웹 애플리케이션 서비스와 설치형 프로그램

(yong27) — Sun, 02 Nov 2008 12:44:42 +0900

리처드 스톨만이 웹 애플리케이션 서비스를 사용하는 것이 대해 다음처럼 이야기했다고 한다.

“자신의 컴퓨팅 활동을 오직 웹 기반 서비스만 쓰는 것은 자신의 통제권을 잃는 것이다. 그것은 상용 소프트웨어를 쓰는 것만큼 나쁜 일이다. 컴퓨팅에 있어 자유를 제공하는 소프트웨어를 이용해서 여러분의 PC에서 여러분의 작업을 하라. 여러분이 상용 소프트웨어를 쓰거나 누군가의 웹서버에 있는 애플리케이션 기반 서비스를 사용하지 말아야 하는 이유이다.” --from 클라우딩 컴퓨터에 대한 쓴소리

처음 위 얘기를 들었을 때, 아니 요즘 같은 웹 2.0 시대에 왜 웹 애플리케이션 서비스를 쓰지 말라는 거야 하는 생각이 잠깐 스치면서 몇 가지 생각할꺼리를 남겼다.

보통 사람들이 일반적으로 사용하는 웹 애플리케이션 서비스들을 정리해보자. (대표적인 서비스들을 떠올려봤음)
1. 전자우편 - 지메일
1. 블로그 - 티스토리
1. 마이크로블로그 - 미투데이
1. 웹 노트 - 스프링노트
1. 사진 - 플리커
1. 동영상 - 유튜브
1. 문서작성 - 구글 닥스
1. RSS 리더 - 구글 리더
1. 동호회모임 - 다음카페
1. 네임서버관리 - DNSever
1. 북마크 - 딜리셔스
1. 모임약속관리 - 온오프믹스

생각해보면 좀 더 많은 곳이 있다. 각 개인은 각 서비스사이트에 자신의 계정을 만들고 자신의 자료를 입력 및 관리한다. 따로 프로그램을 설치하거나 할 필요없이 가입하고 쓰기만 하면 된다. 각 서비스 사이트는 사람들 구미에 맞는 서비스를 준비하고는 사람들을 모으고, 트래픽을 유발시켜 광고수익을 얻는다.

가만히 보면, 꼭 따로 그 서비스를 이용하지 않아도 쓸 수 있는 기능들이다. 나는 예전에 위키 하나만 있으면 나머지 모든 것들이 다 대체 가능하다는 생각을 했었다. 위키의 저자동 고유연성은 위에 표시된 거의 모든 기능을 대체할 수 있다. 하지만 위키를 처음 접했을 때 기대했던 "난 텍스트 키우러 간다 위키위키로"의 미래는 잘 보이지 않고 - 위키피디아에서만 볼 수 있음 - 웹 세상의 각 기능은 특화된 개별 웹서비스들로 분화했다. 어쨌건 위 기능들은 개인 서버를 구비하고, 웹메일, 위키엔진, 게시판, 블로그, 네임서버등을 설치해서 개별적으로 운영할 수 있다. 질적으로 딸리는 것이 문제이긴 하지만.

인터넷의 특징은 그 분산성에 있다. 인터넷은 중앙집중형 네트워크가 아니라 분산형이다. 분산되어 있기 때문에 중요한 허브에 마비가 오더라도 기능을 수행할 수 있다. 티스토리의 블로거가 있는 반면 설치형 프로그램의 블로거도 있는 것이고, 티스토리서버에 이상이 왔어도 영향받지 않는 블로거가 있을 것이다. 지메일이나 한메일이니 그곳에 대한 의존도가 커질 수록 정치적 영향 (FBI가 메일내용을 검색할지 알 수 없는 일) 또한 간섭이 커질 것이다.

덩치 큰 허브보다는 작지만 똑똑한 노드들이 많은 네트워크가 인터넷에는 더 잘 어울린다. 그런 의미에서 RSS나 트랙백 같은 기능들은 의미가 크다. 노드들끼리 연결해주는 중요한 통로를 제공하기 때문이다. 어디선가 인터넷은 분산과 집중이 주기적으로 반복된다는 얘기를 들은 듯 하다. 집중형 서비스의 단점을 보완하는 설치형 프로그램을 기대해 본다.

한국 XP 사용자모임 - 스티브 프리먼 강연

(yong27) — Mon, 27 Oct 2008 00:04:16 +0900

한국 XP 사용자모임의 스티브 프리먼 강연회에 다녀왔다. 정말이지 오랜만에 참여했던 XP모임이라 그런지 아는분이 얼마 없더라는. 그래도, 새로 인사나눈 분들도 있었고, 각자 자신의 조직에서 좋은 팀을 만들고자 고민하는 열정들을 볼 수 있었다.

스티브 프리만의 강연 "자기조직화 팀" 이야기는 나의 팀을 어떻게 꾸려나갈 것인가에 대한 많은 영감을 갖게 했다. 합의되지 않고 불확실한 프로젝트의 결과를 향해 어떻게 해야 하는가. 강연중에도 attractor 얘기가 나왔는데, 최고는 바로 그 팀 자체가 아닐까란 생각이 들었다. 매력적인 팀.

(나의 프로젝트를 투영해봐야 할 모델 슬라이드)

실시간 통역이라는 조금은 새로운 방식의 진행이 이뤄졌다. 영어 강연으로 이해도가 더 떨어지지 않을까 하는 마음에 통역이 있었으면 좋겠다고 생각했었다. 진행시간이 좀 더 걸린다는 단점은 있으나, 좀 더 정확한 전달 및 발표자와 통역자의 커뮤니케이션 또한 구경할 수 있다는 장점으로 매우 유익한 시간이었다. 영어문장을 들으면 앞 문장이 기억안나면서 뭔가 듣긴 했는데 뭐였드라 하는 애매함을 확실히 정리해 주신 듯.

이런 유익한 자리는 왠만해선 경험해보기 힘들 듯. 김창준님을 비롯하여 준비에 수고하신 모든 분들 감사합니다.

자신감

(yong27) — Fri, 10 Oct 2008 10:51:36 +0900

회사에서 모 외산 프로그램의 API 교육이 외국에서 있는데, 여기에 참여하겠느냐는 제의가 있었다. 당시에는 가게되면 많이 배울 기회가 있겠구나 하고 좋아했는데, 곧이어 날라온 참여 개발자의 조건부분에서 조금 망설여졌다. Java SWT 에 관한건데 이를 따라갈 수 있는 고급 객체지향 개발자여야 한다는...

Java를 제대로 써먹어본 적이 없는터라 이긍 못가겠구나 싶었는데, 곧 회신된 우리 연구소장님의 메일. 실력있는 고급기술자가 갈 것이라고. 헉. 음... 비록 지금은 잘 모르는 기술이긴 하지만, 교육전까지 열심히 공부해가면 되지 않을까? 그래. 할수있다고 얘기해놓고 따로 노력하면 될지도 모른다.

이쯤해서 몇가지 이야기가 떠올랐다.

해커 그 광기와 비밀의 기록에 나온 3세대 해커 윌리암스. 그는 새로운 직장을 얻을 때 새 직장이 요구하는 특정 기술에 대해 이미 다 아는 척 하고 이력서를 쓴다음, 실제 그 프로젝트가 시작되기 전까지 열라 공부했다고.

드라마 베토벤 바이러스에서 정명환. 그는 천재이기 때문에 전날 밤샌 티를 낼 수 없었다고. 남들 눈에는 놀러다니는 걸로만 보이는 천재지만, 남모르게 피나는 노력을 해야만 했더라는.

그래. 그러고보면, 미리 겁먹고 시도조차 하지 않는 것 보다는 할수 있다고 선언해놓고, 이를 따라가기 위해 열심히 노력하는 것도 괜찮은 방법일꺼야. 암. 하지만, 그렇다고해서 마구 공수표를 날려서는 안되겠지. 할수있는 범위내에서만. 그렇다고 해도 자신의 여력보다는 살짝 윗 목표를 설정하는 것이 성취감도 생기고, 성장도 되고, 여러모로 좋을 듯. (힘이야 들겠지만서도)

해서 지난 저녁 이클립스깔고 SWT 사용법을 하나하나 알아보기 시작했다. 요즘처럼 바쁜 시기에 또 일거리가 늘었군 싶었지만, 좋은 기회다 싶은 맘에...

혹시 세상의 천재들 원래 다 이런거 아닐까 혼자 상상해보기도... ㅡ.ㅡ;

큭, 근데 바로 다음날 API 교육이 내년 초로 미뤄졌다는 연락이 왔다. 음냐; 다행이다.