Jong10 in Wonderland

무언가를 모르는 9가지 이유

종텐 — Sun, 08 Nov 2009 02:27:54 +0900

lameproof에 굉장히 좋은 글이 올라왔다. 무언가를 모르는 9가지 이유라는 글이다. 이 우주에는 날로 먹으려고 하는, **(심의상 삭제)한 생명체들이 참 많다. 아서라. 그러다가 배탈 난단다.

1. 읽지 않는다
참고서, 메뉴얼 등을 읽지 않는다. 읽을 생각도 전혀 없다.

2. 조사하지 않는다
인터넷 등에서 최소한의 내용도 스스로 조사하려고 하지 않는다.

3. 시험하지 않는다
귀찮다, 등의 이유로 실행해보지 않는다. 할 생각도 없다.

4. 기억하지 않는다
누군가에게 쉽게 들은 대답은 자기 것이 되지 않기에 문제해결 직후 잊어버린다.

5. 설명을 할 수 없다
무엇이 문제인지, 제 3자에게 정확하게 전달할 문장을 쓸 수 없다.

6. 이해력이 부족하다
아니, 이해력보다도, 이해하려고 하지도 않는다.

7. 사람을 이용하려고만 생각한다
응석을 부리거나 억지로, 사람을 부려 임시로 그 문제만 극복하려고 한다.

8. 감사하지 않는다
가르쳐주는 것은 당연. 일이 끝나면 굿바이~

9. 적반하장
자신이 생각하는대로 안 되면 자기가 모르고, 잘못한 것임에도 도리어 화를 낸다.

Python + Django + Oracle

종텐 — Thu, 05 Nov 2009 01:37:50 +0900

Java + IIS + Tomcat + Spring + iBatis + Oracle 로 진행 하려던, 두 달짜리 프로젝트를, IIS + Python + Django + Oracle 로 하기 위해서 찾아보다가, "Django에 오라클 지원이 되긴 하지만, 커넥션 풀이 지원되지 않는 것 같다??"는 정보를 얻고는, 이를 극복하기 위해 여러 방안을 알아보고 있다. ㅠㅠ (IIS와 Oracle은 고객(?)의 환경인듯. -_-)

더불어, Django를 올리더라도, IIS에서 파이썬 프로세스가 매번 재실행되지 않아야 할텐데 싶어서 이것도 동시에 알아보고 있다. 이 쪽은 원래는 wsgi로 생각하다가, twisted.web(비동기인 모양이다)의 성능이 엄청나다고 해서, 이쪽에 또 혹~했다. -_-;; 근데 뭔가 알아볼수록 점점 더 복잡해지는 것 같아서, 이러다가 다시 자바로 돌아가는게 아닌지 걱정이 좀 된다.

내가 원하는 것은, IIS가 돌아가는 환경에서, 오라클을 DBCP 쓰듯이 쓰면서, WAS는 Django의 컨트롤러와 간단한 템플릿 엔진을 사용하고, 모델은 Django를 사용할 수 있으면 이걸 쓰고, 안되면, SQLAlchemy를 사용하는 것인데... 뭔가 간단치 않은 것 같다. 자바로 개발하기는 싫은데. ㅠㅠ (멤버십에 있는 내 PC에서 이클립스가 너무 느려서 파이썬으로 하려는거 아니다... 진짜다... 후... 그냥 PC를 사버리고, 자바로 할까... -_-;;)

TornadoWeb (epoll을 쓰기 때문에, Windows에서는 안된다.)
http://www.tornadoweb.org/

Twisted.Web
http://twistedmatrix.com/trac/wiki/TwistedWeb

SQLAlchemy - Connection Pooling
http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/pooling.html

SQLAlchemy - Oracle
http://www.sqlalchemy.org/docs/05/reference/dialects/oracle.html

Oracle Backend with SessionPool (Django #7732)
http://code.djangoproject.com/ticket/7732

Django with twisted.web.wsgi
http://clemesha.org/blog/2009/apr/23/Django-on-Twisted-using-latest-twisted-web-wsgi/

Building Oracle Database-backed Web Applications in Django
http://www.oracle.com/technology/pub/articles/vasiliev-django.html

Connecting To Oracle Directly (Without settings.py)
http://blog.awarelabs.com/2007/connecting-to-oracle-directly-without-settingspy/

Django and Oracle (한글)
http://biohackers.net/wiki/DjangoAndOracle

pyorapool : An oracle connection pooling daemon for python based projects
http://pyorapool.googlecode.com/

Oracle & Python
http://demmer.ipax.at/blog/oracle-python/

Django on Windows with IIS and SQL Server
http://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer

원래는, "검증된 것만 사용해서 빨리빨리 끝내자"라는 계획이었는데, 뭔가 점점 일이 커지는 것 같기도 하고;; 아 그냥, 순결한 마음가짐으로, servlet/jsp 날코딩으로 RESTful하게 만들어놓고, SproutCore와 jQuery로 적당히 때워줘야 하는걸까? 흠...

고객(?)의 요구사항에, "아무나 불러서 유지보수하기 쉽게"도 있었는데, (유지보수 비용을 낮추기 위한 프레임웍들임에도 불구하고) 뭔가 유지보수와는 점점 거리가 멀어지는 것 같기도 하고. -_-

-- 이상한 나라의 종텐.

바보도 짐작하는 e-book 산업의 가능성

종텐 — Tue, 03 Nov 2009 21:22:00 +0900

아마존닷컴의 3분기 순이익 실적은, 작년에 비해 69% 뛰어서, 1억9900만 달러(약 2374억원)를 기록했다. 이 말도 안 되는 수치 가운데에는 Kindle이 있다. e북 리더다. “또 e북? 그래봤자 pdf 리더 아니야?”라고 생각할 지 모르지만, 오 이런. 그랬다면 69%나 뛰었을까? Kindle은…

종이 같은 품질의 전자 잉크를 사용했고, (이걸 사용한 제품은 국내에도 있다.)
아마존닷컴이라는 엄청난 분량의 e북 컨텐츠가 있으며,
무선망을 이용해 아마존닷컴에 접속해서 e북을 구매하는데 1분도 안 걸리고, 그 접속 요금을 아마존에서 지불한다.

이정도 말했으면, 느낌이 팍 안 오나? 나 정도의 일개 블로거 따위에게, “우와. 킹왕짱!”이라는 느낌이 올 정도면, 이미 늦은 거 아닌가? 근데 우리나라는 왜 아직 이런 단말기가 없을까? 삼성이나 아이리버에서 전자 잉크를 사용한 e북 리더를 만들긴 했지만, 컨텐츠가 없잖아! 오 이런… e북 산업은 단말기 사업이 아니라고. pdf 따위를 읽을 수 있는 것은 백만년 전에도 많았다고.

두 가지 가능성. 단말기 제조업체라면, 애플이 음반 업체들을 모두 잡아서, 아이튠즈를 만든 것 처럼, 공격적인 사업으로 컨텐츠를 다량 확보해야 하는데(애플을 돈 방석에 앉힌 아이팟의 성공 비결의 핵심이 아이튠즈라는 것을 모른다면 어쩔 수 없지. 단지, 이쁘게 생긴 mp3 플레이어 팔아서 돈 벌었다고 생각하는 멍청이도 충분히 많으니깐), 우리나라의 단말기 업체들은 뼛속이 전자회사라서, 커다란 리스크를 가지는 이런 공격적 전략은 하지 않겠지.

대형 온라인 서점이라면, 단말기 업체를 하나 물어서 독점 계약을 하고, 자사의 컨텐츠를 제공하는 온라인 마켓을 창설, 무선망 접속비용 제공. 책을 모바일로도 팔아치우면서, 막대한 수익 창출. 하지만, 온라인/오프라인 마켓으로도 적당히 팔리는데, 앞장서서 e북 산업에 많은 투자를 하진 않겠지. 다른 곳이 성공하면, 따라하거나.

사실, 나 정도도 생각할 수 있는 거면, 이미 다들 준비하고 있지 않을까 싶기도 하지만. 애플 AppStore의 경우도, 이건 확실히 되는 거라고 생각했는데, 몇 년간 아무도 안 하더라고? 물론, 생각은 다들 하기야 하겠지만, 위에 앉은 고지식한 어르신들은 기각하겠지.

그래서, 세 번째 가능성, 고지식한 어르신들이, “뭐? 접속 요금을 우리가 낸다고? 그런게 돈이 되긴 되겠어?”하고 방치하다가, 3~4년 지난 후에, 아무리 봐도 외국에는 e북 산업이 잘 나가자, (지금의 SKT, KT, LGT가 뒤늦게 애플의 AppStore 따라하듯이) 그제서야 따라 하거나.

그냥 뭐, 그럴 것 같다고.

-- 이상한 나라의 종텐.

TracMercurial Encoding Problem

종텐 — Mon, 02 Nov 2009 11:38:00 +0900

Apache2, Trac, Mercurial을 연동하고 나서, Subversion일 때는 전혀 없던 문제가 발생. 파일 내용에 UTF-8로 된 한글이 있는 경우는 잘 나오는데, 커밋 로그에 한글이 있을 경우는 ??? 로 깨져서 나온다. Trac은 0.11.1 이고, Hg 연동은 TracMercurial을 사용했다.

Trac 사이트를 뒤져보니, 인코딩에 관련된 TracMercurial 플러그인의 여러가지 버그(#7160, #8180)가 있더라. 가장 간단한 해결책은, HGENCODING 환경변수를 utf-8 로 잡는 것인데, 아파치의 SetEnv에 넣어봤는데도 이상하게 안되더라. 결국, 소스에 박아버렸더니 작동한다.

mercurial-plugin-0.11/tracext/hg/backend.py 파일을 열어서, from 어쩌구 import 어쩌구가 끝나는 적당한 위치에…

os.environ["HGENCODING"] = "UTF-8"

를 써준다. 앗싸. 커밋 로그가 한글로 잘 나온다.

-- 이상한 나라의 종텐.

오만과 편견, 그리고 겸손

종텐 — Thu, 22 Oct 2009 01:02:00 +0900

불과 몇 일 전에, 내 미투데이에서 아래와 같이, 타인의 코드에 대한 비판을 했었다.

차라리 무지했으면, 이 코드를 비난하진 않았겠지만, 나는 new가 NULL을 리턴 하는 것 때문에 Build하는 과정에서 나오는 무수한 warning을 보면서, 굉장히 기분이 나빴다.

하지만, 곰곰히 생각을 해 보니, 해당 코드는 임베디드 시스템에서만 사용되는 엔진이다. 임베디드 시스템에서는 C++의 Exception이 허용되지 않는 플랫폼이나 개발 환경도 많다는 것을 망각했다. Mozilla의 C++ Portability Guide를 보면, “왜 C++을 쓰는 거지?”라는 생각이 들 정도로, 제약사항이 많다. GNU의 g++을 사용하면서, -fno-exception을 쓰는 경우는 충분히 있을 수 있다. 성급히 비판한 나는 너무 오만했다.

물론, 진실은 모른다. 저 개발자는, 단지 std::bad_alloc을 몰라서 저렇게 코딩 했을 수도 있지만, 더 멀리 내다보고, C++의 Portability를 위해서 옛날 방식으로 처리한 것일 수도 있다. 하지만, 단순히 몇 줄의 코드만으로 욕을 먹을만한 엔진인가? 글쎄… 그렇진 않다. 나는 이 정도 되는 것을 만들어본 적도 없다. 그러면, 내 코드는 훌륭한가? 오 이런! 절대로 아니다! 생각이 여기에 도달하자, 부끄러워서 손발이 오그라들었다. 나는 대체 언제부터 이렇게 오만해진 걸까? 겸손했던 마지막이 언제인지, 기억 조차 나지 않는다. 나는 무수한 선배들의 코드 앞에서, 좀 겸손해질 필요가 있다. 내 오만이 오랫동안 내 시야를 가렸을 지도 모른다.

-- 이상한 나라의 종텐.

어른이 되어간다는 것

종텐 — Tue, 20 Oct 2009 21:50:28 +0900

오늘, 오전에 A 작업을 하다가, B 문제점이 드러났다. B 문제점을 수정하던 중에, C 클래스가 이상하다는 느낌이 들었다. C 클래스가 하는 역할이 무려 2~3가지였다. B 문제점을 수정하면서, C 클래스를 리팩토링 하기 시작했다. 내겐 머큐리얼이 있다. 언제든지 revert 하면 된다구!

... C 클래스를 수정하던 중에, 또 다른 D 문제가 나타났다. 게다가 뭔가 왕창 엎어야 하는 분위기!

그래. 어쩔 수 없지. 리팩토링 비용이 상승하는 것은 어쩔 수 없지만, 피해갈 수 없는 요소라 판단했다. 열심히 뜯어고쳤다. 복작복작. 뚝딱뚝딱... 하루가 그렇게 끝났다. -_-;; D 문제는 해결되지 않았고, 이걸 해결하려면, 하루는 더 걸릴 것 같았다. 사실, 이틀이 걸릴지도 모른다. 하지만, 우리의 스프린트는 이미 밀려있었고, 일정은 매우 빠듯한 상황이었다.

팀장님이랑 일일회고를 하던 중에...

종텐 : 냉정히 생각해보니, 지금 당장 급한 것은 B 문제였는데요.. 그냥 C 클래스를 뜯어고치기 이전으로 revert 해야겠어요. (언젠가 다시 고쳐야 할) 지저분한 코드를 그대로 안고 가는 것은 끔찍하지만, D 문제를 해결하려던 것은, 원래 오늘 계획한 일이 전혀 아니었잖아요. 비록, 3~4시간 정도 작업하면서 많은 부분을 고치긴 했지만, 이 코드는 모두 버려야겠어요. 이 리팩토링을 지금 하는 것은 적절하지 않아요.

팀장님 : 하하. 어른이 되어가는군요.

종텐 : 아......

어른이 되어간다는 것은, 조금 슬프구나. 이상을 포기하고, 현실에 적응하려는 것 처럼 느껴진다. 하지만, 이 결정은 이상을 포기하는 것이 아니다. 나는 여전히 이상주의자다. 존재하지 않는 것을 향해, 허공에 떠있는 것이 아닌, 두 다리를 현실이라는 대지에 단단히 딛고 있지만, 하늘을 바라보며 별을 추구하는 것이 이상주의자다. 그렇게, 조금씩 어른이 되어간다.

-- 이상한 나라의 종텐.

강컴에서 책 한권 사기 위한 삽질기

종텐 — Sun, 27 Sep 2009 15:06:00 +0900

크롬을 띄웠다. 자주 가는 사이트 8개에 강컴이 있다.
신간이 나왔나 확인하기 위해 강컴을 누른다.
갑자기, C++ 템플릿 가이드를 사기로 했다는 생각이 들었다.
결재를 해야되니깐, IE8을 띄워서 강컴에 접속했다.
강컴에서 이상하게 IE에서만 페이지가 안 뜬다.
다른 사람들의 IE에선 잘 되던데, 내 노트북에서만 안된다. ㅠㅠ

사실, 지난 몇달동안은 IE에서 강컴이 안되길래, 알라딘을 이용했는데...
덕분에 강컴에서 내 아이디가 우수회원에서 일반회원으로 떨어졌길래 ㅠㅠ
왠지, 이번엔 강컴에서 사고 싶었다.
이것이 모든 것의 시작이었다.

Chrome과 Firefox에선 잘 나온다.
하지만, 결재는 IE에서만 되잖아!
IE에서 강컴에 들어가기 위해서, 에러 페이지 내용을 구글링 해본다.
The parameter is incorrect 라고 나오는데, 무슨 파라미터가 잘못되었는진 안 나온다.
치사한 IIS 6.0.

어쩔 수 없군.
패킷 캡쳐를 해야겠다.
Wireshark 다운로드.
HTTP만 필터링 한다.
IE8에서 강컴 접속.
HTTP Request 패킷을 덤프했다.
흠. 수정해서 보내봐야겠다.

python 실행.
일단, urllib.urlopen()을 때려본다. 잘 나온다.
socket을 열어서, 강컴의 80포트에 접속한다.
덤프한 내용을 밀어넣는다.
헐퀴! 타임아웃이 난다. ㅠㅠ
settimeout()을 하지 않고 보내본다.
음... 응답이 안 오고 있어?!
send()는 되는데, recv()가 안된다?!
아하! \r\n 한개가 빠졌었구나.

일단, 패킷을 좀 간단히 해서, 다시 시도.
Bad request -_-;
다시 수정해서 시도.
우왕. 200 OK가 떨어졌다.
근데, 내용이 없다?!

이상하네? urllib로 하면, 내용이 나오는데,
301 redirect도 아닌데, 왜 내용이 없지?????
아하! 끝나기 전에 recv()를 반복하지 않아서 그랬나보다.
소켓을 오랜만에 했더니 @_@;;
여차저차 수정하고, 에러 재현 완료.
200 OK가 떨어진 직후에, 400 Bad request로 변신한다. -_-;;

이제, 파라미터를 하나씩 바꿔본다.
아… 찾아냈다!
여차저차 수정을 하다보니, 302가 정상적으로 떨어진다!
User-Agent 항목에서 FDM을 제거하니깐 된다.
FDM은, Free Download Manager라는 내가 사용하는 프로그램인데,
이게 설치되면, IE에서만 Http Request의 Header에 포함 되나보다.

강컴에 접속하기 위해서, FDM을 지워야 하나 -_-;;;
다른 모든 사이트는 잘 되는데;;
일단은 지우고나서, IE에서 강컴에 접속하니 잘 된다.
해당 파이썬 소스와, 에러가 발생하는 http header를 강컴에 메일로 보내줘야겠다.

이상으로, 종텐의 1시간 가량의 강컴 삽질기 종료!

-- 이상한 나라의 종텐.

p.s. 우와. 나한테 상으로 책 한권 줘야하는거 아닌가? ㅋㅋ

p.s.2. 월요일 아침에 바로 강컴에서 (해결했으니 확인 부탁드린다는) 전화가 왔다. 다시 FDM을 설치하고, 다시 패킷캡쳐를 하면서 IE에서 접속을 해보니, 이번에도 User-Agent에 FDM 항목이 있는데, 이젠 잘 된다. 강컴의 발빠른 대응에 감사. :-)

프로페셔널이란?

종텐 — Sun, 20 Sep 2009 15:19:00 +0900

<종텐> 프로와 아마추어의 차이는, 집중력에 대한 컨트롤 능력이 아닐까요? 프로든 아마추어든 flow에 진입하면 엄청난 생산성을 보이잖아요? 하지만, 그 flow에 진입하는 것이 컨트롤 가능한 쪽이 프로 아닐까요?

<쿠키아빠> 제 생각엔, 프로는 어떤 상황에서라도 최소한의 생산성을 뽑아내는 사람이 아닐까 싶어요. 주변 환경에 영향을 덜 받고요.

<종텐> 아…

돈을 받고 코드를 뱉는다고, 다 프로는 아니다.
나는 프로페셔널인가? 밥값은 하고 있나?
… 부끄럽다. 어제까지는 아니었던 것 같다.
그럼, 내일은?

-- 이상한 나라의 종텐.

켄트 벡 세미나 후기 - 반응적 설계

종텐 — Sat, 12 Sep 2009 18:45:23 +0900

지난 9월 4일 금요일, 켄트 벡의 “반응적 설계” 세미나를 다녀왔다. 켄트 벡과 같이 사진을 찍는 사람이 아무도 없어서, 같이 찍지는 못하겠구나 싶었는데, 오픈마루 스프링노트 팀이 사진을 찍는 틈을 타서, “저,저도!”라고 외치고 옆에 살짝 서있었다. (웃음).

왼쪽부터, 프리버즈님, 프로도님, 나이누님, 종텐(본인), 켄트 벡, 김창준님.

세미나를 들으면서, 정말 필기를 많이 했다. 아직은, 나름 학생인데, 88,000원임에도 자비(自費)로 신청한 것이었고, 듣고 난 후에 얻은 이야기들을 여기저기 전파하고 싶은 욕심에서였다. 무려, 43,000 바이트 가량의 필기를 했다. 옆에 앉아계셨던 분께 상당히 죄송하다. 타자 소리가 꽤 시끄러웠을 듯. 하지만, 이 모든 내용을 블로그에 쓰진 못할 것 같다. 기록하지 못한 부분도 있고, 아직 켄트 벡의 생각에 대한 내 입장도 좀 애매하고, 소화하지 못한 부분도 있는 듯 하다. 잘 모르겠다.

반응적 설계(이하, RD)에 대한 자세한 내용은, 아래 링크들에서 얻을 수 있다.

강의자료 : http://drop.io/responsive/asset/responsive-design-one-day-ppt
켄트벡 세미나 정리 사이트 : http://sites.google.com/site/kentbackkorea2009/
샌프란시스코에서 했던 RD 세미나 : http://www.infoq.com/presentations/responsive-design
켄트벡 블로그 : http://www.threeriversinstitute.org/blog/

일단, 결론부터 말하자면, 흠… 반응적 설계(이하, RD) 자체에 대한 것은, 좀 평이한 내용들이 많았다. 하지만, 그것을 풀어나가는 과정에 있어서의 설명들과, 다양한 이야기들은 만족스러웠다. 또한, 아직 RD가 완성되지 않은 형태(정리를 하고, 개선을 해서, 책을 쓸 계획이라 했다)라서, 더 보완되리라 생각한다.

뭔가 내용을 기대하고 스크롤바를 내린 분들께 좀 죄송하다. 의견을 교환하고 싶은 내용이 많지만, 파스칼의 말을 빌리자면, 시간이 없어서 글이 길어졌다. 그래서, 필기를 했던 파일을 통째로 올린다. 중간중간에 내 의견을 써놓긴 했으나, 놓친 부분도 많고, 사실, 나중에 정리를 하려고 했었기 때문에, 의견을 써놓은 부분은 굉장히 적다. insight를 교환하고 싶은데 매우 아쉽다. 그 당일에 회고 모임이라도 추진 해 볼껄 그랬다. 나중에라도, 정리를 하게 되면, 다시 포스팅을 할 수 있지 않을까 하는 희망을 조금은 품어본다.

아무튼. 필기한 파일(+ 약간의 의견) 업로드 합니다. 라이센스는 "대인배 라이센스"입니다. 국 끓여 드셔도 되요.

kent_rd.txt

p.s. 세미나 장소에서 우연히 만난, 프리버즈님, 프로도님, 나이누님, 박계홍님, 달룟님, 컴키드님, 김승범님, K-Dog님, 강성희님, 나부군님. 반가웠습니다!

Jazz - 에릭 감마 세미나 후기

종텐 — Mon, 24 Aug 2009 23:03:00 +0900

지난 화요일, 디자인패턴의 창시자 중 한 명이자, 이클립스 프로젝트의 창시자인 에릭 감마의 세미나에 다녀왔다. 에릭 감마가 새로 3~4년째 만들고 있는 협업 플랫폼인 Jazz와 그 플랫폼 상에서 동작하는 RTC(Rational Team Concert)에 관한 이야기들이었다.

행사장에 조금 늦었는데, 도착했을 때에는 시작한 지 10분쯤 지난 후였고, 동시 통역이 진행되고 있었다. 포스 넘치는 에릭 감마 아저씨가 이클립스 프로젝트에 대한 이야기를 하고 있었다. API에 대한 이야길 하는 중이었는데, API는 변화에 대한 리스크가 크기 때문에, 최소한으로 유지하는 것이 중요하다는 점. 그래서, 이클립스가 취한 전략은, Everything is a plug-in 이라고 말했다. “no exceptions”라고도 했다. APIs are a huge commitment이기 때문에, 이런 전략을 취했다고 했다. 즉, API 자체는 정말정말 최소화 하고, 기능 자체를 플러그인으로 만들었다는 소리다.

그 후에, 이클립스의 방향에 대해서 말했다. 2002년에 회사에서 이클립스를 오픈소스화 했을 때에는, 이렇게 잘 될줄은 몰랐다고 했다. 커뮤니티의 힘은 정말 굉장했다면서, 현재의 개발방향 추세에 대해서 말했다. 이클립스 프로젝트가 전세계의 많은 개발자들이 인터넷 상으로 협업을 하는 내용에 다루면서, 어떤 식으로 협업을 하는지에 대해 이야길 했다. 또한, 개발 프로세스에서 Iteration에 대한 이야길 조금 해줬다. 이 팀은 애자일 방법론들을 적용했는데, 특정 방법론에 치우친 것이 아니라, 필요한 부분만 사용했다고 했다. 그러면서, Iteration에 대한 이야길 했다. “It is all about being continuous”라고 하면서, 디자인/리팩토링, 통합/테스팅, 배포/데모, 피드백, learning 등등 모두 continuous하다고 했다.

이클립스의 observer들은 오리가 물에 떠있기 위해서 발을 엄청나게 휘젓듯이, 이클립스 팀이 그 안에서 얼마나 많은 work/stress/human factor를 소비하는지 모른다고 했다. 특히, 팀으로 프로젝트가 진행될 때의 Pain에 대한 이야기가 나왔는데, Collaboration, Development, Project Management에 대한 이야길 해줬다. 그러면서, 슬슬 내용은 (이제서야;;) 본론인 Jazz 로 넘어갔다.

Jazz는 팀 프로세스를 위한 협업 플랫폼이다. 개발, 프로젝트 관리, 애자일 프로세스 등이 통합된 플랫폼이다. 이 중에서도, RTC라고 해서, Rational Team Concert라는 플러그인(?)이 있는데, 이 플러그인이 오늘 얘기의 중점이었다. 온라인용, 또는 회사용, 애자일 개발 도구 세트 같은 느낌?

90년대말은 Point Tools에 포커스가 맞춰졌다. 이클립스는 One Developer에게 포커스가 맞춰졌다. 이젠, Team과 Collaboration을 위한 것이 있어야 한다고 했다. 이클립스 프로젝트의 주역 멤버들이 4년전부터 만들기 시작했고, 자신에게 있어서 Dream Project라고 했다. 왜냐면, 항상 이런 것을 필요로 하고 있었기 때문! (나도 완전 필요했다고!!). 이걸로 개발자들의 삶을 개선할 수 있기를 희망한다고 했다.

현대의 프로세스는, 민첩성을 원하지만, 여전히 예측이 중요하다. 투명성도 중요하다. 생산성은 하나의 개발자를 위한 것이 아닌, 전체 팀을 위한 것이라 했다. (스크럼의 소멸차트가, 개인별로 그려지는 것이 아닌, 팀 위주로 그려지는 이유도 마찬가지라 생각한다). 그래서 이런 것을 위한 것이 Jazz 플랫폼이다.

에릭 감마가 직접 시연을 보여줬는데, 전체 느낌은, 이클립스 + 버전 트래킹 + 이슈 트래킹 + 소멸차트와 같은 애자일에 필요한 도구들 + 온라인 협업 + 코드를 쉽게 추적할 수 있는 기능 + 팀별로 룰과 프로세스를 정할 수 있는 기능 (신입은 커밋을 허락을 받아야 한다던가) + 등등의 많은 기능들을 RTC라는 이름에 다 때려넣었다. 뭔가 사용법은 이클립스를 처음 접했을때 만큼이나 복잡해보였지만 -_-;;; 익숙해지면, 엄청난 향상을 가져올 것 같은 느낌?

중요한 것은, 팀별로 각자의 프로세스가 있는데, RTC에서는 이런 규칙을 정할 수 있다고 했다. 개인별로 대쉬보드가 주어지고, 팀별 대쉬보드도 나오고, 프로세스에 대한 규칙을 정할 수도 있다. 대쉬보드는 현황을 파악하는 것 보다는, 문제에 초점이 맞춰져서, 해당 버그나 기능을 바로바로 추적해서 “지금 당장 어디부터 일을 해야하는지”를 쉽게 파악할 수 있게 해준다. 또한, 전체 프로젝트 리더를 위한, team of team을 위한 대쉬보드도 주어지고, Baglog Plan을 세울 수 있게 하고, Release, Iteration, Daily 등에 대한 것과 현재 진행사항을 정할 수 있고, Burndown Chart도 나온다. Jazz.net에서 현재 버전을 사용해 볼 수 있고, 재즈의 목적은, 각각의 개발자와 구성원들간의 팀 프로세스 상에서의 투명성과 방향성을 제공하여, 커뮤니케이션 비용을 낮추고, 협업을 돕는 것에 있다.

에릭 감마의 발표가 끝나고, 잠시 휴식을 취한 후에, 질답이 이어졌다. 질답은 무려 1시간이 넘게 했고, 많은 질답이 오갔는데, 기록을 별로 못했다. -_-a 기억에 남는 것 몇가지만 추스리자면,

Q. 에릭 감마씨는 API 개발을 많이 해보셨을텐데, API 설계시에 가장 중점을 두는 부분은 무엇인가요?
A. 첫째는, 사용의 용이성. 이해하기 쉬운가. API는 사용의 편리함이 가장 중요하다. 두번째는 UnitTest. 유닛테스트 자체가 사용 용이성의 척도이기도 하다. 세번째는, 고객의 피드백. 완성 전에 고객을 API 개발에 참여시켜야 한다. (고객이라 함은, 해당 API를 사용하는 프로그래머를 의미).

Q. 에릭 감마씨는 GoF 디자인 패턴의 저자인데, 아까 말씀하셨을 때에, 설계시에 가장 중요한 것은 “경험”이라고 하셨는데, 패턴을 굳이 학습해야 하는 이유는 무엇인지? GoF 책 말고도, 다른 패턴들이 있는데, 이것도 모두 학습을 해야 하는지?
A. 그 책은 웹브라우저보다도 오래된 패턴이 있어서, 가끔 얼굴이 화끈거린다. 다시 쓰고 싶은 부분도 있다. 하지만, 패턴은 중요하다. 책의 패턴을 템플릿처럼 그대로 쓰려고 하지 마라. GoF에 나오는 것은 물론이고, 그 책에 안 나온 더 많은 패턴을 익혀라. (예를 들어, 마틴 파울러의, 엔터프라이즈 패턴이라던가, Pattern-Oriented Software Architecture 시리즈에 나오는 패턴들이라던가.) 많은 경험이 소프트웨어 설계에서 가장 중요한 항목인 것은 맞지만, 그런 경험이 없으면, 패턴을 통해 다른 프로그래머들의 경험을 학습할 수 있다. 패턴도 많이 익히고, 경험도 많이 쌓아라.

그리고 마지막으로, 에릭 감마가, “Design is NEVER Easy”라고 강조하며 말했다. 그러니깐, 계속 수련을 하라고.

-- 이상한 나라의 종텐.