May 2005 Archives

Folksonomy란 social classification 또는 collaborative categorization이라고 얘기되는 인터넷 어플리케이션의 형태를 가리키는 일종의 buzzword입니다.Flickr나 del.icio.us의 태깅(tagging)기능을 사용해보신 분이라면 아실겁니다.

드보락 아저씨는 이를 엄청나게 비판합니다. 결론이 대체 무엇인지 모르겠지만, 논지는 대략,

• 원래부터 있던, 새로울 것이 없는 아이디어다.
• 스팸(spam)과 파괴행위(vandalism) 문제를 고려하지 않고 있다.
• 대부분의 사람들이 선하다는 이상주의에 기초하고 있다.

라는 것입니다. 게다가, Wired와 몇몇 유명한 블로거들에 대한 강한 적개심을 보이고 있군요.

원래부터 있던 기술이라는 것은 별로 중요한 얘기는 아닐 듯 합니다. 기술은 항상 끊김없이 흘러가는 것은 아니니까요. 기존에 있던 아이디어들이 환경이나 기술등의 제약에 부딪히고, 또 그것을 헤쳐나가는 방식으로 발전하는 기술들도 많이 있는 것 같습니다. Folksonomy도 기원을 찾으라면 충분히 찾을 수도 있을겁니다. 하지만, 현재와 같이 편리한 시스템을 가지게 된 것은 분명히 발전이라고 생각합니다. 시장은 오랜 역사를 가진 개념이지만, 세계를 편리하게 이어주는 증권 시장 시스템이 없었다면 증권 시장이 과연 오늘날과 같은 특성을 보일까요?

정말로 대부분의 사람들이 선하지 않을까요? 위키피디아를 보면 그렇지도 않은 것 같습니다. 위키피디아는 "Given enough eyes, ..."라는 Linus' Law를 기반 아이디어로 훌륭하게 컨텐츠를 관리하고 있습니다. 즉, 충분히 많은 사람들이 보고 있으면, 스팸이나 파괴행위도 별로 문제될 것이 없다는거죠. 설령 대부분의 사람들이 선하지 않더라도, 적어도 충분히 많은 사람들은 선한 것 같습니다. Folksonomy의 스팸 또는 파괴행위 문제도 앞으로 해결해야할 기술적 과제일 뿐이고, 크게 다르지 않을거라고 생각합니다.

"social" 접두어를 가진 최근의 기술들은 한가지 성질을 공유하고 있습니다. 바로 사용자 한 사람 한 사람의 이해관계가 결집되어서 새로운 어플리케이션을 창조한다는 것입니다. 이것은 물론 인터넷의 발달과 더불어 예견되었을 법한 일이죠. 인터넷 자체가 복잡 시스템(Complex system)의 특성을 가지고 있고, 이러한 social application들도 이러한 특성을 공유하고 있습니다. 마치, 우리는 단순히 물건을 사러 혹은 물건을 팔러 시장에 나가지만, 그러한 사람들이 모여서 시장의 독특한 성질이 만들어지는 것과 마찬가지죠. 그래서, 우리는 시장에 가면, 단순히 물건만 살 수 있는게 아니라, 서로 흥정을 해서 저렴한 가격에 물건을 살 수 있기도 하고, 여러가지 볼 거리도 구경할 수 있는거지요.

드보락 아저씨는 Folksonomy를 블로거들의 마지막 희망(bloggers' last hope of invention)이라고 얘기합니다. 저는 그렇게 생각하지 않습니다. 인터넷이라는 플랫폼에서, 아직도 알려지지 않은 창발성(emergence)을 이용하는 어플리케이션은 분명 엄청나게 많이 있을겁니다. 이러한 어플리케이션들은 인터넷이 없었던 시절에는 꿈꿀 수 없었지만 사용자들은 분명히 원하는 그런 종류의 것들일겁니다. 드보락 아저씨는 분명히 미래를 잘못 짚고 있다고 생각합니다. 블로그의 시대에 살고 있는 저널리스트인 드보락 아저씨는 Disruptive Technology의 가장 직접적인 희생양일지도 모르겠군요.

스타워즈와 같은 흥행예상작들을 개봉일 근처에 보기는 힘들다. 금방 매진이 되어버리고, 설령 표를 구할 수 있다고 하더라도, 자리가 그다지 좋지 못하고, 결정적으로 나는 좋은 표를 구할 수 있을 정도로 성실하지는 못하기 때문에, 그런 영화들은 개봉 후 2-3주 후에나 보는 편이다. 그래서 난 개봉일을 가상적으로 늦출 수 있는 능력을 지니고 있다. 이번에도 역시 시간 왜곡 드라이브를 가동중이엇는데, 마침 여자 친구에게 열받은 친구 녀석이 보여준다고 해서 좋다거니 따라나섰다. 대전 CGV 5관이었고, 지난 목요일 심야 23시 30분 프로였는데도, 사람들이 꽉 들어찼다. 자리는 역시 그다지 좋은 편은 아니었다. 그렇다고 친구의 성의를 무시하고 나와버릴 만큼 나쁜 것도 아니어서 다음번에 한번 더 보면 되겠거니 하고 참고 봤다.

스타워즈 팬은 아니더라도 (팬을 자처하는 사람들이 너무 많아서 그렇게 불리기도 싫다), 어느 정도 스타워즈에 대해서는 관심이 있는 편이기 때문에, 3편의 스토리도 어느 정도 알고는 있었다. 3편에서 기대한 것은, (2편에서 이미 예고한) 우주에서의 함대 전투, 사건의 세부적인 전개 상황과, 다쓰 베이더의 탄생 장면이었다.

도입부를 장식하는 것은 분리주의자들과 공화국의 우주 함대전이다. 기본적으로는 오비완과 아나킨의 침투 장면이지만, 그 배경을 장식하는 함대전은 그야말로 시리즈 중 최고의 비주얼을 선보였다. 다시 한번 스타워즈를 볼 기회가 생긴다면, 비주얼에 집중해서 봐야할 듯하다.

한편, 제다이 원탁 회의에서 염려하고 있었듯이, 아나킨은 팰퍼틴 의장에 의해 다크 사이드의 유혹을 지속적으로 조금씩 받고 있었고, 거기에 파드메의 죽음에 대한 예견이 더해져 자신의 선택에 대해 조금씩 의심을 가지기 시작한다. 아나킨의 변절 장면에서도 아나킨은 어느 쪽을 결정했다기보다는 흔들리고 있는 처지였다. 주어진 상황이 어쩔 수 없이 아나킨의 결정을 요구했고, 그는 (결과적으로) 윈두를 죽인 후 외친다. "What I've done!". 그 한순간의 결정에 따른 상황의 변화가 아나킨의 미래를 지배해버렸다. (마치, 약혼자를 죽일 계획으로 약혼자를 데리고 차를 몰고 있었으나, 아직도 마음이 흔들리고 있는 도중, 의도치 않은 자동차 사고가 나고 약혼자는 죽어버렸다는 식.) 그 순간에 아나킨은 팰퍼틴을 죽이고 자신의 실수를 인정할 수 있었을까. 아니, 그렇지 않다. 자연주의(naturalism) 소설에서 자주 등장하는 레퍼토리. 하지만, 이 장면에서 아나킨이 몇초 가량 괴로워하다가 바로 팰퍼틴에게 무릎을 꿇는 것은 매우 부자연스러워 보였다. 다만 아나킨이 약삭빨라서인가.

강력한 포스를 가지고 있으면서도 라이트 사이드와 다크 사이드 사이에서 갈등한다는 아나킨의 캐릭터의 설정 자체는 좋다고 생각한다. 하지만, 좀 더 설득력있게 그리고 매력적으로 그릴 수 있었을텐데, 아나킨의 심리를 보여주는 방식에 뭔가 부족한 느낌이 든다.

다쓰 베이더의 탄생 장면은 그야말로 팬들의 탄성을 절로 자아내게 하는 장면이었을테다. 어디서든 다쓰 베이더의 그 숨소리만 들려도 팬들은 즐거워할텐데, 그 첫번째 숨소리라니! 다쓰 베이터의 탄생 장면을 보면서 깨달은 것은 이 영화는 바로 다쓰 베이더의 탄생을 위해서 만들어졌다는 것이었다. 다쓰 베이터의 탄생을 설명하기 위해 너무나 많은 스토리를 짧은 시간 내에 담으려고 허겁지겁 스토리를 진행한 느낌이 많이 들었다. 무엇보다도 캐릭터들의 진실성이나 매력이 와닿지 않았고, 그것은 캐릭터의 감정이나 심리를 표현하는데 충분한 장면을 할당하지 못했기 때문에, 충분한 감정이입이 이루어지지 못했기 때문이라고 생각한다. 그런 몇 장면을 꼽아보자면, 일단 방금 얘기했던대로 아나킨의 변절 장면에서의 아나킨의 급격한 심리 변화는 납득하기가 힘들었다. 또한, 아나킨과 오비완의 결투 장면에서도, 싸움을 하면서 나눈 몇마디 대화가 아나킨과 오비완의 심정을 포용하지 못하는 느낌이 들었다. (오비완이 아나킨을 이길 수 있었던 이유도 너무나 허술하지 않은가.) 후일의 영웅이 될 쌍둥이들을 출산하는 파드메의 장면에서도 마찬가지였다. 연출력이 모자란 것인지 연기력이 모자란 것인지.

덧붙여, 그리버스라는 캐릭터도 반동 캐릭터로서는 너무 부족한 느낌이 들었다. 전투를 좀 잘하는 드로이드일 뿐 그 이상의 매력은 없었다. C3PO나 R2D2의 인간미 넘치는 캐릭터라든가 인간이면서도 제다이와 대결이 가능한 장고펫 같은 캐릭터와는 대조적이다.

한 마디로 이번 영화를 평하자면, 친구에게도 얘기했듯이, 비주얼은 역대 최고, 드라마는 역대 최악이다.

황우석을 바라보는 일관된 방법
http://yeinz.pe.kr/blog/index.php?page=3

황교수 논문 있는그대로 보기!
http://goodking.new21.net/bbs/rgboard/view.php?&bbs_id=0002&page=&doc_num=400

과학기술의 덫에 갇힌 언론
http://www.greenreview.co.kr/archive/80KangYanggu.htm

프로그래밍 언어의 평가

나쁜 프로그래밍 언어란? 어떤 사람들은 문법이 마음에 들지 않아서 나쁜 프로그래밍 언어라고 부를테고, 어떤 사람들은 그 언어를 사용해 개발한 프로덕트의 성능이 너무 떨어져서 나쁜 프로그래밍 언어라고 부를 것이다. 어떤 사람들은 자신이 필요로 하는 라이브러리가 없어서 나쁜 프로그래밍 언어라고 부른다. 모두 자신만의 기준을 가지고 있다. 어떤 기준이 옳은가?

프로그래밍 언어는 종교가 아니라 도구다. 프로그래밍 언어를 선택할 때에는 자신이 해결하고자 하는 문제와 그 문제를 해결하는 상황에 가해지는 제약 조건이 프로그래밍 언어와 잘 맞아떨어지는 가를 살펴야한다. 애초부터 나쁜 프로그래밍 언어가 존재하기보다는 프로그래밍 언어를 선택하는 사람의 문맥에서만 좋고 나쁨이 존재하는 것이다. (물론 논리적으로는 모든 상황에서 나쁜 언어가 존재할 수는 있다. 하지만, 아마도 그런 언어는 당신이 경험해 볼 기회가 없을 것이다. 이 글은 철학 에세이가 아니다.) 프로그래밍 언어 논쟁이 자주 이상한 길로 빠지는 이유는 논쟁에 참여하는 사람이 그 언어를 경험한 문맥은 제각기 다르기 때문이다.

한편, 프로그래밍 언어는 문법 내지는 표준 라이브러리로만 구성되는 것이 아니다. 프로그래밍 언어 자체 뿐만이 아니라, 프로그래밍 언어가 사용되는 방법, 프로그래밍 언어를 사용하는 사람들, 프로그래밍 언어를 위한 도구들 등 프로그래밍 언어 외적인 요소들도 프로그래밍 언어 평가의 범주에 포함시켜야 한다.

결국 의미있는 프로그래밍 언어의 평가는, 프로그래밍 언어를 평가하는 사람의 특정한 문맥 - 예를 들어, 해결하고자 하는 문제와 문제를 해결하는 상황적 조건 - 에서 프로그래밍 언어 자체 뿐만 아니라 프로그래밍 언어 외적인 요소들까지도 포함해서 이루어져야 하는 것이다.

PHP 프로그래밍 언어의 평가

일단, PHP 프로그래밍 언어의 평가가 어느 정도 정당하기 위해서는 그 평가가 웹 어플리케이션에 대해서 이루어져야 한다고 생각한다. PHP가 사용되는 어플리케이션의 절대 다수는 웹 어플리케이션이기 때문이다. 이 때, 우리는 웹 어플리케이션 개발 양상의 변화를 염두에 두어야 한다. PHP가 처음으로 선보일 당시, PHP가 해결하고자 했던 웹 어플리케이션 상의 문제와 현재 개발되는 웹 어플리케이션의 문제는 크게 달라졌기 때문이다. 가장 중요한 변화는 바로 규모와 복잡성이다.

PHP가 처음 만들어질 당시에는 비교적 작은 규모의 단순한 웹 어플리케이션들이 대부분이었다. 당연히 PHP의 설계 철학도 거기에 맞춰졌으리라고 생각한다. PHP로 만들어지는 어플리케이션의 규모가 작았기 때문에, namespace의 부재나 템플리팅, 전역 변수들이 미치는 부정적인 영향보다 긍정적인 영향이 더 컸으리라고 생각한다.

하지만, 웹 어플리케이션의 규모가 점점 커지고, 유지 보수 문제가 중요한 문제로 떠오르게 되었다. Java 진영에서는 JSP, JavaBean, EJB 등의 기술을 기반으로 MVC를 도입한 JSP Model 2를 발전시켰다. 하지만, PHP 진영에서는 언어 자체가 원래부터 초기의 웹 어플리케이션 개발에 초점이 맞추어져 있었기 때문에 변화 자체가 힘들었고, 기존의 사용자를 버리고 변화할만큼의 자유는 없었다고 생각된다. (기술 발전에 있어서 이와 유사한 경우는 자주 발견된다.) 전형적인 예가, PHP의 템플리팅 기능이라고 생각한다. 웹 어플리케이션 개발이 발전하면서 프리젠테이션과 로직의 분리가 상당히 강조되어왔지만, 템플리팅 기본 지원이라는 강력한 이점을 포기하기는 너무나 힘들었을 것이다.

이와 같이, PHP 프로그래밍 언어 자체(문법과 라이브러리)에는 큰 규모의 웹 어플리케이션에 잘 어울리지 않는 아쉬운 점이 있는 것이 사실이다. 하지만, 이러한 문제들도 완전히 극복할 수 없는 그런 종류의 문제들은 아니다. 적어도 non-trivial한 언어라면 어떤 언어든지 제대로 사용하기 위해서는 어느 정도의 숙련을 필요로 한다. PHP 프로그래밍 언어의 문제점들도 숙련된 프로그래머의 정련된 discipline (이 단어에 대응하는 적당한 우리말 단어가 없는 듯 하다)를 통해서 해결되거나 피해갈 수 있는 문제들에 지나지 않는다. 따라서, PHP 문법의 세련되지 못함을 이유로 PHP가 언어의 선택에서 탈락되어야 하는 경우는, 문법 이외에는 모든 조건이 다른 언어들과 거의 동등하다거나, PHP에 숙달된 프로그래머가 별로 없다거나, 다른 목적 (예를 들어, 다른 고급 언어를 사용함으로써 충족되는 프로그래머의 만족감)이 필요한 상황 외에는 없을거라고 생각한다.

이러한 점에서 이미 PHP 프로그래밍 언어를 사용하고 있는 프로젝트에서 PHP 프로그래밍 언어 자체의 문제를 이유로 들어 다른 언어로 바꿀만한 정당성은 거의 없다고 생각한다. (반면에 새로운 프로젝트에서 프로그래밍 언어를 선택해야하는 입장에 있는 경우에는 굳이 PHP를 선택할 필요는 없는 것은 말할 필요도 없다.) 내가 다니던 회사에서도 PHP 프로그래밍 언어를 사용하는 대규모 웹 어플리케이션의 유지보수가 큰 문제가 되어서, 다른 언어로 바꾸자는 의견이 분분했던 적이 있다. 분명히 유지보수의 문제는 PHP 프로그래밍 언어 자체에도 어느 정도 책임이 있을 것이다. 하지만, 그들이 PHP 프로그래밍 언어의 문제에 눈이 멀어 보지 못했던 것은, 대규모 웹 어플리케이션 자체의 복잡성이었다고 생각한다. 대규모 웹 어플리케이션 자체의 복잡성을 해결하기 위한 다른 노력을 고려하지 않으면서, 프로그래밍 언어 또는 관련 제반 기술을 바꾸면 문제가 해결된다는 생각은 엔지니어링의 결과로 보기에는 힘들고, 웹 어플리케이션 자체를 위험에 빠뜨릴 수 있는 위험한 생각이라고 생각한다. (사실 당시에, 나도 그러한 생각을 하는 사람 중의 한 사람이었고, 이후로 이 문제에 대한 고민이 시작되었다.)

Zend에서는 몇몇 문제를 해결한 PHP 5를 내놓았고, PEAR를 정통적인 3rd party 라이브러리로 내세우고 있다. 이러한 노력들이 다른 수많은 기술들과의 경쟁에서 이기고 좋은 결과를 거둘 수 있을지는 미지수이다. 개인적인 의견으로는 PHP에는 아직도 초기 디자인의 유물들이 너무나 많이 남아있기 때문에 비관적이라고 본다. 그럼에도 불구하고 PHP의 커다란 사용자층은 PHP를 계속 살아남도록 하는 원동력이 될 것이다. 그리고, 그 동안에 무슨 일이 벌어질지는 아직 아무도 모르는 일이다.

한편, 웹 어플리케이션 뿐만 아니라 어떤 어플리케이션 개발에 있어서 기술의 성숙도는 프레임워크가 있느냐 없느냐로 결정된다고 생각한다. 프레임워크는 어떤 어플리케이션의 베스트 프랙티스(best practice)들을 모두 모아놓은 결과물이기 때문이다. 웹 어플리케이션 개발 분야에서도 프레임워크 기술은 2000년 즈음 이후로 크게 발전해서 널리 퍼지게 되었다. 웹 어플리케이션을 자신의 니치(niche)로 가지고 있는 PHP 진영에서도 이러한 노력이 분명히 있을 것이라고 생각했고, 나는 회사의 개발자 메일링 리스트로 "PHP에서 가장 널리 쓰이는 MVC 기반 웹 프레임워크가 무엇인지" 질문을 했다. 며칠이 지나도록 답변이 없었다. 나는 직접 웹 검색을 해보기로 했다. 웬걸, PHP로 만들어진 웹 프레임워크는 너무나 많았다. 국내에서 가장 유명하다는 PHP 커뮤너티 사이트인 PHPSCHOOL에도 가보았다. MVC에 관한 글은 단 하나(!)였다. (현재는 두개다.) 성급한 일반화일런지는 몰라도, 적어도 국내에서는 PHP 개발자들은 MVC 프레임워크를 거의 사용하지 않는다는 것이다. 대부분의 개발자들은 JSF와 같은 새로운 JSP 기술에 열광하고, RubyOnRails에 열광하는데, 어째서 PHP 기반의 MVC 프레임워크는 찾지 않을까. 이상하다고 생각했다.

내가 아는 PHP 개발자는 스스로가 하고 있는 일을 가치가 낮은 일로 여겼다. 그 이유는 PHP는 좋지 못한 언어란 것이었다. PHP 개발자를 포함해 내가 아는 대부분의 소프트웨어 개발자들은 PHP 언어를 싫어하고, 동시에 PHP 개발을 낮은 가치를 지닌 일로 평가한다. 같은 어플리케이션을 만들어도 J2EE 나 .NET 플랫폼에서 개발을 하면 높은 가치를 생산하고 PHP로 만들면 낮은 가치를 생산할까? 위에서 내 논리를 잘 따라왔다면 합리적인 답변은 그렇지 않다는 것이다. 하지만, 나는 이 질문이 잘못되었다고 생각한다. PHP, JSP, ASP 개발은 낮은 가치를 생산하는가? 아마도 대부분이 그렇다고 대답할 것이라고 생각한다. 사람들은 웹 어플리케이션 개발(특히, 웹 티어 개발)을 낮은 가치로 평가한다.

닷컴 붐이 일 때, 엄청나게 부풀려진 웹 어플리케이션 시장은 평균적으로 경험이 적고 기술 수준이 낮은 웹 프로그래머를 양산하게 되었다. 당연히 경험이 적고 기술 수준이 낮은 프로그래머로부터 나오는 산출물 또한 그 품질이 낮을 수 밖에 없다. 여기서 사람들은 한가지 착각을 한다. 산출물의 품질이 낮은 프로그래머가 사용하는 기술은 가치가 낮은 기술이라는 인식이다. PHP는 처음부터 프로그래머가 쉽게 배울 수 있고 편이성을 강조한 언어였다. 당연히 경험이 적은 대다수의 초보 프로그래머가 선택한 언어는 PHP 였을 것이다. 그리고, PHP는 동급의 웹 어플리케이션 기술인 JSP나 ASP에 비해서도 오히려 낮은 평가를 받는 처지가 된다.

PHP 기술에 대한 낮은 평가는 기술 수준이 낮은 PHP 프로그래머들을 낳게 된다 (기술 수준이 높은 프로그래머는 다른 언어로 옮겨가거나 PHP를 선택하지 않음으로써). 이것은 positive feedback으로 전체 PHP 프로그래머들의 수준을 낮추는 결과를 가져왔고, 현재 커뮤너티의 수준도 낮은 수준에 머무르게 된 것이라고 생각한다. (이 얘기는 당사자들에게는 민감한 얘기라고 생각한다. 이것은 평균적인 수준에 대한 얘기이지 PHP 프로그래머 개개인에 대한 얘기가 아닌 것을 유념해주기 바란다. 또한 이것은 비난이나 인신공격도 아니다. 이 글은 문제점을 제대로 파악하자는 의도를 가지고 있다.)

PHP 개발자를 낮은 기술에 머무르게 하는 이 positive feedback 구조에도 불구하고, 숙련된 개발자는 PHP를 사용하더라도 분명히 높은 가치의 산출물을 낼 것이라고 생각한다. PHP를 사용하는 개발자는 PHP를 사용하기 때문에 가치가 낮은 것이 아니라, PHP 개발자에게 기대하는 수준 이상의 것을 하지 못하기 때문에 구조의 족쇄에서 영영 빠져나오지 못하는 것이다. 솔직히 말해서, 한번 이러한 feedback이 확립된 이상 PHP 언어가 거기로부터 빠져나오기는 힘들다고 생각한다. 하지만 PHP 개발자 개개인은 그렇지 않다는 것이 중요하다. 합리적이지 않는 이유 - PHP를 사용한다는 이유로 자신의 가치를 낮게 평가하지 말고 경험을 쌓고 더 높은 가치의 일을 하도록 노력해야한다고 생각한다. HTML markup과 PHP 코드를 자유자재로 구사하면서 스파게티 웹 티어 코드를 생산해내는 PHP 프로그래머와 프리젠테이션과 로직의 분리라는 디자인 목적을 깨뜨리지 않으려 세심하게 노력을 기울이는 PHP 프로그래머, 5년 후 그들 사이의 갭은 얼마 만큼 일까.

Summary

웹 어플리케이션 개발을 위해 만들어진 PHP 프로그래밍 언어는 초기 웹 어플리케이션의 개발에 최적화 되어있고, 요즘 웹 어플리케이션의 대형화 복잡화 경향을 잘 따라가지 못하는 한계를 분명히 가지고 있다. 하지만, 그것은 분명히 극복할 수 있는 한계로서, PHP 기반의 웹 어플리케이션 프레임워크들과 같은 노력들도 존재한다. 언어적인 한계를 평가할 때는 그것을 실제 이상으로 과대 평가하지 않도록 주의를 기울여야 한다. PHP5나 PEAR와 같은 PHP의 개선을 위한 노력들도, 어느 정도 한계는 있지만 PHP가 확보하고 있는 넓은 사용자층으로 인해 기대해볼 만하다.

PHP 언어를 사용하는 것은 낮은 가치를 지니는 일이란 것은 일종의 미신이다. 이러한 미신으로 인해 PHP 언어에 덮혀씌워진 오명은 피드백 구조로 인해 당분간 깨어지기는 힘들 것이다. 하지만, 개발자 개인이 이러한 미신을 깨뜨리고 높은 가치를 지니는 개발자가 되는 것은 개발자 자신의 몫일 것이다.

Hatred for PHP

대부분의 사람들은 PHP가 표방하는 PHP의 철학에 동의한다. 그렇다면 무엇이 싫단 말인가? 웹 검색을 통해서 다음과 같은 글들을 발견할 수 있었다.

• I hate PHP
• Why PHP sucks (for large systems)
• PHP in contrast to Perl
• Experiences of Using PHP in Large Websites
• PHP annoyances
• PHP: A love and hate relationship
• PHP 5 Enterprise Edition?"

이 사람들은 PHP를 미워하고 있다. 그 이유는? 어느 정도 유효하고 중요한 내용들만 내 생각들과 함께 정리해보았다.

Language Syntax

• No namespaces: 어느 정도 복잡한 product를 만들 때, 불편한 점 중의 하나는 함수 이름이나 변수 이름이 중복되는 것이다. 이 문제에 대한 해결책으로, 모든 함수나 변수들의 이름에 prefix를 붙여서 namespace를 구분하거나, 클래스를 namespace의 대용으로 사용하는 방법이 있다. C와 같은 다른 언어들을 생각해보면, 분명히 namespace가 없이도 커다란 프로덕트를 만드는 것은 가능하다. 하지만, 최근에 나온 대부분의 언어가 namespace를 가지고 있음에도 불구하고 PHP 5에 namespace가 들어가지 않은 것은 상당히 아쉬운 부분이다.
• Arrays are ordered maps: PHP의 array는 기본적으로는 key, value pair의 집합인 ordered map이다. PHP의 array는 이러한 map의 용도 뿐만 아니라 여러 용도로 전용된다. integer를 key로 하는 전통적인 array를 비롯하여, list, queue, stack 등으로 사용될 수 있다. 이러한 사실은 array function들을 보면 알 수 있다. 언어가 단순해지고, 여러가지 데이터형으로 활용함으로써 얻는 편리한 점도 있겠으나, 프로그래머가 array라는 데이터형에 대한 명확한 모델을 머리속에 그리지 못하게 하고, 또한 프로그래머가 실수를 할 가능성을 높힌다는 측면에서 그리 좋지 못하다고 생각된다. 많은 언어들이 array와 map을한다. 하지만, 그렇다고 string 만으로 array를 지원하는 언어들을 무시할 수는 없다. 어떤 데이터형을 지원하는가 하는 문제는 언어의 단순성과 프로그래머의 편이성 사이의 trade-off 문제라고 생각한다. 어떤 언어가 어떤 데이터형을 지원하느냐는 그 언어의 철학에 달린 일이고, 정답이 있는 것은 아니다.
• Does not enforce the declaration of variables: PHP는 선언 또는 정의되지 않은 변수이더라도 참조가 가능하다. (물론 warning은 발생한다.) "<? print $undeclared_variable; ?>"라는 PHP 코드와 "print undeclared_variable"이라는 Ruby 코드를 실행해보라. PHP에서는 아무렇지 않은 듯이 조용히 실행되지만 Ruby에서는 "undefined local variable or method"라는 에러가 발생한다. 비교적 작은 프로그램, 모듈, 또는 함수에서는 큰 문제가 되지 않지만, 코드가 길어지고 복잡해질 수록 버그를 발생시킬 가능성이 높아지고, 이 버그를 발견하는 것도 힘들어진다. PHP에서는 옵션을 통해 정의되지 않은 변수 접근에 대한 경고를 켤 수 있다.
• No real references: reference가 아니라 name alias일 뿐이기 때문에 여러가지 문제가 발생한다. http://www.php.net/manual/en/language.references.php
• No chained method call: $foo->bar()->op() 같은 문법이 불가능했었다. PHP 5에서 가능해졌다.
• No closure, not even anonymous functions
• shortcut behavior: 다른 언어들과는 달리 shortcut의 결과값이 boolean 값이다.
• call-time pass-by-reference deprecation: PHP에서 reference를 사용하는 문법은 매우 이상했다. function을 정의할 때 파라미터에 reference임을 나타낼 수도 있고, 실제로 호출을 수행할 때도 reference임을 나타낼 수 있었다. 이 점은 기존 PHP 문법이 상당히 불완전함을 나타내는 증거라고 볼 수 있는 것 같다. (예를 들어, function 정의의 파라미터에도 reference라고 명시하고, 호출 시 아규먼트에도 reference라고 명시한다면 어떻게 될 것인가. reference의 reference? 답은, 그냥 reference다.) 결국은 호출 시 reference 명시는 deprecated 되었다. 문제는 이 deprecation으로 기존에 할 수 있었던 일을 할 수 없게 되어버렸다는 것이다. PHP 5에서는 모든 variable을 reference semantic을 가지도록 바꾸었기 때문에 더이상 이런 문제는 없을 것이다.

Language Implementation

• Template: 대부분의 언어들은 templating을 언어의 구현과 분리해놓지만, PHP의 구현에는 완전히 합쳐져있다. 웹 어플리케이션의 규모가 커지면서 프리젠테이션과 로직의 분리가 중요해진 지금 시점에는 그다지 좋지 않은 방법이다.
• Register Globals: Register Globals는 CGI를 통해 들어오는 리퀘스트 변수들을 전역 변수로 만들어주는 기능이다. namespace를 가지지못한 PHP로서는 전역 namespace를 더럽히는 것은 엄청나게 해로운 일이다. 물론 여기에는 "웹 프로그래머의 편이"라는 언어가 만들어지던 당시의 고려가 담겨있다. 하지만, 웹 어플리케이션의 규모가 커지면서 이 기능은 PHP를 해치는 기능이 되어버렸다. 최근에는 이 기능을 켜고 끌 수있는 옵션의 기본 값이 "끄는 것"으로 바뀌었다.
• Bad recursion support: 스피드를 위해서 stack에 저장하는 데이터가 많기 때문에 recursion에 좋지 않다.
• Not thread-safe: 구현을 보면 thread safety를 위한 노력을 하고 있으나, 실제로 thread-safe 하지는 않다.
• Magic quotes: Magic quotes는 PHP가 사용하는 데이터에서 특정 문자들을 자동으로 escaping 해주는 기능이다. 프로그래머가 직접 하더라도 크게 불편하지 않은 작업을 굳이 자동으로 해주어서 복잡도를 증가시키는 것은 좋지 않은 기능인 것 같다.

Standard Library/3rd-party Library/Framework

• Inconsistency: PHP에서 기본으로 제공되는 라이브러리에 들어있는 함수들의 이름이나 파라미터들은 상당히 일관성이 없다. 다음 링크 참조.
• no crucial XXX library: html parser, MIME builder, WWW library, consistent database API, gd를 제외한 graphics library가 없다는 것을 불만스러워하고 있다. PEAR에서 어느 정도 해결되기를 기대해본다.
• no CPAN: 현재는 PEAR가 공식적인 extension repository가 되었으나, CPAN 처럼 사용하기에 편리한 것은 아니다.

People

• Knowledgeable people are in a serious minority: 외국의 PHP 커뮤너티조차도 수준이 낮다는 지적을 많이 받고 있는데, 내가 보기에는 국내의 PHP 커뮤너티도 크게 다르지 않은 것 같다. 가장 유명하다는 PHPSCHOOL에 가보라.

요즘 들어 휴강이 많아져서, 월/수요일 같은 경우에는 4시간 가량의 공백이 생긴다. 과 전산실에서 웹브라우징을 하는데, 탭브라우징을 지원하는 불여우(Firefox)를 사용하다가 IE를 사용하려니 너무 불편했다. 과 전살실의 컴퓨터에서는 일반 사용자가 프로그램을 설치할 권한이 없다. 문득 USB 드라이브에 불여우를 설치해서 사용한단 얘기가 생각나서 셔플(Shuffle)에 설치해보기로 마음먹었다.

USB 드라이브에 불여우를 설치하는 방법은 두가지가 있는 것 같았다. PC의 불여우 설치본을 그대로 복사하는 방법과 USB 드라이브에 설치하는 용도로 따로 만들어진 패키지를 이용하는 방법이다. 나는 전자를 선택하기로 했다.

이 방법을 간단히 설명하면,

1. 그냥 PC의 불여우 디렉토리를 그대로 셔플에 복사하고,
2. 불여우의 프로파일 디렉토리도 복사한 다음,
3. 불여우를 실행할 때 프로파일 디렉토리를 지정해주는 배치 파일 하나를 만들어주는 것이다.

난 프로파일 디렉토리를 복사하지 않고, 그냥 빈 디렉토리만 만들어주고 배치 파일에 그 상대 경로를 넣어주었다. 아무 문제 없이 디폴트 프로파일이 생성되었다.

역시 탭브라우징을 사용할 수 있게 되니, 웹브라우징이 훨씬 편리했다.

한가지 문제는, USB 드라이브 상의 불여우의 정보 - 북마크를 어떻게 PC와 Sync 하느냐 하는 것이다. 이 문제는 회사와 집 두군데에 정보를 분산해놓는 문제와 같은 것이다. 그 문제에 대한 내 해결책은 인터넷 상에 정보를 두는 것이었고, 이번에도 같은 방식으로 해결하면 될 것 같다.

Introduction

어떤 practice가 보편화되어있고 그것을 보조하는 툴이나 생각의 장치들이 잘 발달되어 있다면, 오히려 그 practice의 장점이 무엇인지 파악하는 데에는 방해가 되기도 한다. 어떻게 보면, 생산성을 높히고자 하는 우리의 노력이 때로는, 각 개인의 능력을 키우는 데에는 방해가 될 수도 있는 것이다.

예를 들어, 잘 만들어진 소프트웨어 프로세스 환경에만 익숙한 개발자는, 그러한 프로세스가필요없다고 주장하는 사람에게, 그것이 왜 필요한지 제대로 설명하지 못할 것이다.현대의 특정 프로그래밍 언어에만 익숙한 사람은, 자신이 활용하고 있는 수많은 언어적 장치들의 이점을 제대로 이해하고 있지 못할 가능성이 높다.

마찬가지로, 잘 만들어진 Model-View-Controller(이하 MVC) 프레임워크에만 익숙한 사람이라면, 그 패턴이 가지고 있는 유용성이나 의미를 발견하지 못할 가능성이 높다. 대부분의 웹 어플리케이션 개발자들은, 프리젠테이션과 로직이 뒤섞인 기존의 웹 어플리케이션에만 익숙하거나, MVC 프레임워크 웹 어플리케이션에만 익숙하다. 기존의 웹 어플리케이션이 MVC를 사용함으로써 어떤 점에서 좋아질 수 있는지는 전자나 후자의 프로그래머들 모두 알지못할 가능성이 높다.

이 글의 목적은 기존의 웹 어플리케이션에 MVC 패턴을 적용하면서 리팩토링하는 과정을 보임으로써, MVC 패턴의 유용성을 재발견하는데 있다.

Galaxy

Galaxy는 개인적으로 개발중인, RSS를 주기적으로 받아와서 사용자에게 보여주는 웹 어플리케이션이다. 이 글에서 예로 들 부분은 Galaxy의 admin 모듈이다. 이 모듈의 기능은 다음과 같다.

• 사용자는 자신이 구독할 RSS Subscription을 등록, 삭제하거나 조회, 수정할 수 있으며,
• 각각의 Subscription에는 Category를 할당할 수 있다.
• 이 Category 역시 등록, 삭제, 조회, 수정될 수 있다.
• 그리고, 사용자는 전체 Subscription을 수동으로 업데이트할 수 있다.

Galaxy in traditional-web-application style

일단 Galaxy의 첫번째 버전에서는 Subscription을 등록하는 기능만 제공하기로 결정했다고 가정해보자. 자, 먼저 Subscription을 등록하는 폼을 보여주고 사용자가 정보를 입력하고서 폼을 submit하면 Subcription 정보를 DB에 저장하는 로직을 처리하는 어플리케이션을 생각해보자.

자신을 Perl CGI나 PHP, ASP 등을 사용하는 웹 어플리케이션이 막 퍼지기 시작하던 시절의 웹 프로그래머라고 가정해보자. 필요한 기능은 그다지 많지 않고 로직도 단순하다. 그 시절에 방명록 따위를 심심풀이로 짜본 경험이 있다면, 금방 감이 올 것이다. 파일 이름은 admin.rb라고 하자. (Galaxy는 Ruby 어플리케이션이므로, 예제 역시 Ruby 언어를 사용한다. 간단한 템플리팅(templating)을 위해 eruby를 사용한다고 가정하자.) 웹어플리케이션이라는 신기술을 다룰 줄 아는 우리가 생각해낸 코드는 아마 다음과 같을 것이다.

즉, 'mode' 리퀘스트 파라미터가 없을 때는 Subscription 등록을 위한 양식(form)을 보여주고, 이 양식이 submit되면 'mode' 리퀘스트 파라미터가 설정되어 Subscription 등록을 처리하는 방식이다.

이 코드에 어떤 문제가 있는가? 그렇지 않다. 문제는 없어 보인다. Subscription 등록이라는 단순한 기능을 수행하는 목적의 어플리케이션으로서 이 이상의 무언가를 필요로 한다면, 그게 더 이상한 것이다.

이제 다시 질문을 하겠다. 이 코드에 어떤 문제가 있는가? 그렇다. 이 어플리케이션은 현재는 Subscription 등록이라는 단순한 기능밖에 없지만, 앞으로 위에서 언급했던 여러 기능들을 모두 넣어야하는 미래를 가지고 있다. 자 여기서 약간의 상상력이 필요하다. 이 기능들을 하나씩 추가할 때마다, 리퀘스트 파라미터에 따라 분기하는 if-else-end 구문은 엄청나게 길고 복잡해져갈 것이다.

그리고, 이 어플리케이션은 웹 어플리케이션임을 기억해야한다. 위의 예에서는 html이 별로 사용되지 않았지만, 실제 서비스에 적용하기 위해 웹 디자이너가 던져준 화려한 페이지의 html 마크업은 훨씬 복잡할 것이다. 기존의 웹 어플리케이션은 프리젠테이션을 위한 html 마크업과 도메인 로직을 위한 코드가 복잡하게 뒤섞이는 경향이 있다.

웹 어플리케이션의 또 한가지 중요한 특징은, 로직의 변경 빈도와 프리젠테이션의 변경 빈도가 현저히 차이난다는 것이다. 커다란 리뉴얼부터 자잘한 수정까지 html 마크업은 코드에 비해 자주 변경된다. 문제는 html 마크업과 코드가 뒤섞여있음으로 인해, 잦은 html 마크업의 변경은 필연적으로 코드, 그 중에서도 가장 중요한 도메인 로직의 버그 가능성을 낳게 된다.

결국, 우리에게는 프리젠테이션과 도메인 로직의 분리(decomposition)가 필요하다.

Extracting domain objects

위의 예에서 도메인 로직은 어떤 부분인가? 바로 "Subscription을 등록하는 것"이다. 도메인 로직을 프리젠테이션으로부터 분리해내는 방법에는 여러가지가 있겠지만, 우리는 객체지향언어를 사용하고 있으므로, 도메인 로직을 도메인 객체(domain object)의 형태로 분리해내는 방법을 채택하자. "Subscription을 등록하는 것"에서 도메인 객체는 무엇일까? 바로 Subscription이다.

Subscription 객체를, 우리가 사용하고 있는 Ruby로 표현하기 위해서는 클래스를 사용하면 되겠다.

그리고, 기존 코드는 Subscription 객체를 사용하도록 바뀔 것이다.

이로써 원래 코드에 있던 도메인 로직 부분을 몽땅 하나의 클래스로 분리해낼 수 있게 되었다. 변경된 admin.rb에는 클래스 하나와 훨씬 간단해진 나머지 코드가 남게되었다. 또한, 프리젠테이션을 자주 변경해도 DB에 도메인 정보를 저장하는 걸 빠뜨리거나 할 가능성은 훨씬 줄어들게 되었다.

MVC 패턴에서는 도메인 정보를 나타내거나 그것을 처리하는 역할을 하는 도메인 객체를 Model이라고 부른다.

제가 만든 MovableType의 클라이언트인 MovableTypeWriter를 약간 손봤습니다. 에디터로 사용하던 mshtml을 전에 한번 언급했던 XStandard로 바꾸었습니다.

바꾸는 작업은 그리 어렵지 않았습니다.XStandard Lite를 설치하는 것부터, 프로젝트에 XStandard COM component에 대한 Reference를 추가해주고 10라인 정도의 코드를 수정하는 작업까지 어저께 오전 1-2시간 만에 끝났습니다. 그리고, Doodle Bug부터 지금 쓰는 글까지 모두 새로운 MovableTypeWriter를 사용해서 작성했죠. XHTML 1.0 표준에 호환되는 코드를 생성하는 것을 확인하니 매우 기분이 좋더군요.

어떤 분들은 이 블로그의 오른쪽 메뉴바에 XHTML 1.0 표준 호환 배너가 달렸다는 것을 눈치채셨는지도 모르겠습니다. (무려 XHTML 1.0 Strict 입니다.) 배너에 해당 페이지의 Markup Validation Service가 링크되어있으니, 호기심이 많으신 분들은 테스트해보셔도 되겠습니다. (그러고보니 XHTML 1.1이 아니라 왜 XHTML 1.0일까요? 기본 템플릿의 Doctype이 XHTML 1.0으로 되어있었던 모양입니다. 이것도 손봐야겠군요.)

덤으로 MT의 템플릿과 최근 글 내용들이 표준에 호환되도록 좀 손봐주었습니다. 표준에 호환되지 않는 예전 글들이 많아서, 손으로 일일이 바꾸기 보다는, 적당한 툴을 사용해서 한번에 손봐야할 것 같습니다.

SessionSaver와 Adblock은 최근에 쓰기 시작한 Firefox extension입니다.

뉴스 사이트에서 읽을 거리를 탭으로 먼저 열어놓은 다음 하나씩 읽는 스타일이기 때문에, Firefox를 닫아야만 하는 상황일 때, 남아있는 탭은 골칫거리입니다. Firefox의 시작 페이지 기능을 (시작페이지를 현재 페이지를 설정하면 모든 탭이 저장되죠.) 사용해보기도 하고, 북마크로 일일이 저장해주는 방법도 사용했었습니다만, 불편한 건 어쩔 수 없었습니다. SessionSaver는 Firefox를 닫을 때 자동으로 탭들을 저장해주고, 다음에 Firefox를 시작할 때 복구해줍니다. 특히 여러 Firefox 인스턴스가 떠 있을 때, 윈도우를 종료하더라도, Firefox를 띄우면 원래대로 복구되더군요. 여기에 더해서 현재 세션(탭 상태)을 따로 저장하거나 저장된 세션을 간편하게 복구할 수도 있습니다.

Adblock은 인터넷 한겨레가 개편되면서 많아진 Flash 광고를 제거하기 위해서 쓰기 시작했습니다. (IE에서 보면 Flash 위치가 제대로인데, Firefox에서 이상한 위치에 나타나는 경우가 여러 사이트에서 종종 보이더군요.) URL의 패턴을 사용해서 이미지나 링크 등을 막을 수 있습니다. 특히, 페이지 상의 Flash에 마우스를 갖다대면, 그 옆에 "Adblock" 이라는 버튼이 나와서, 패턴을 사용하지 않고도 바로바로 막을 수 있도록 하는 기능을 제공하고 있습니다. 상당히 편리하고 유용합니다.

무진은 어디에 있는 도시인가? 안개가 많은 도시라는 것을 볼 때, 바닷가 근처거나 호수가 있는 내륙지방(강원도)의 느낌이 난다. 읽다보면, 호남지방인가 하는 생각도 잠시 든다. 어디에 있는 도시인가는 별로 중요하지 않고, 오히려 별로 알려지지 않은 점이 중요한 것인가? 도시로부터의 도피처? 실락원?

영화 "생활의 발견"와의 관련성. 지방 도시에서 만난 여선생과의 정사라는 스토리라인. "우리 서로 솔직해지기로 해요"라는 대사.

서울과 무진의 공간적 대비. 서울은 이성이 지배하는 공간. 무진은 욕망이 지배하는 공간. 자의식과 무의식. 욕망(비이성)에의 옹호? 주인공의 이중성 자체도 비이성?

부조리극. Camus. 타인의 속물적 행동에 대한 비판과 주인공 자신의 속물적 행동.

"문학의 이해" 수업 시간에 전봉관 교수님(황금광시대의 저자)이 르네 지라르의 욕망의 구조 분석에 관한 얘기를 잠깐 언급하셨다. 간단히 말해서, 욕망의 대상으로의 욕망은 욕망의 매개와의 관계 속에서만 형성된다는 얘기다. "삼각형"이 나오는 걸로 봐서는 구조주의 쪽의 사상으로 보인다. 과학적 근거가 제대로 있는지는 궁금하지만, 일변 설득력이 있는 흥미로운 얘기다.
제프리 버튼 러셀의 "악마의 문화사"라는 책도 언급하셨다. 이 책의 저자는 악의 이해를 통해서, 선을 이해하려는 노력을 하고 있다고 한다. 저자는, 하느님이 악마를 창조한 것은 하느님의 전능성을 부정하는 것이 아니냐라는 주장에 대한 "반박" 중, 아퀴나스의 설명을 가장 설득력 있는 것으로 언급하고 있단다. 그 설명이란, 하느님이 "악"을 창조한 것이 아니라, 어떤 상황에 놓여있는 인간의 상대성이 선과 악을 창조한다는 것이다. 난 중세철학을 폄하하는 선입견을 가지고 있었는데, 그것은 순전히 무지로부터 나온 것인 듯 하다. 공부해볼 것.

어저께 학교를 돌아다니며 Shuffling을 하다가 발견한 곡입니다. 아무리 우울하더라도, 이런 흥겨운 곡을 들으며 하루를 시작하면 기분이 좋습니다.

Ronald Baker - Doodle Bug

날씨도 한 몫 하는군요. 더구나 날씨는 이번주 내내 좋을 것 같구요.

주말엔 우울했는데, 음악과 날씨 덕분에, 즐겁습니다! 오늘부터 축제도 시작한다지요.

Konfabulator 2.0이 나왔군요. 요즘은 The Weather Widget만 사용하고 있었는데, 2.0에서는 모양이 약간 변했습니다. 별다른 주목할만한 차이점은 느끼지 못하겠습니다.

그리고, 사이트에 놀러갔다가, Flickr Upload Widget을 발견했습니다. 당분간 좀 써보게 되겠군요.

회사에 다닐 때, 몇몇 프로젝트 관리 도구들 - Microsoft Project나 dotproject 같은 웹 기반 도구들을 사용해보았는데, 쓸데없이 너무 복잡하거나, 필수적인 기능이 빠져있는 경우가 많았을 뿐만 아니라, 사용하기가 너무 불편했다.

XP 방법론이나 TDD 같은 practice를 보면서, 그러한 방법론에 잘 들어맞는 툴이 없다는 것도 느낄 수 있었다.

예를 들어, XP 방법론에서는 User Story로부터 요구사항을 수집하고 구현해야할 기능들을 찾아낸다. 그리고 이러한 기능들 중, 특정 기간 내에 개발할 기능들을 골라낸다. 기능별로 여러 사람들에게 분배되고, 기능을 구현하면서 또는 사용자의 피드백을 통해 추가적으로 찾아낸 기능들은 다음번에 구현할 기능으로 넣어둔다. 이러한 프로세스를 따라가면서 기존의 프로젝트 관리 도구를 사용해보라. 페이지를 이리저리 왔다갔다 해야하고, 불필요한 수많은 정보들을 입력해야한다. 방법론이 강조하는 프로세스를 따라가면서, 프로젝트 관리자나 개발자가 프로세스 상에서 발생하는 정보를 자연스럽게 입력하고 조회하는 것은 매우 불편하다.

한마디로, 방법론 상의 프로세스와 프로젝트 관리 도구의 사용성은 잘 들어맞지 않는다. 하지만, 복잡한 프로젝트 관리 도구들을 사용하더라도 위의 프로세스에서 발생하는 정보들을 모두 표현할 수는 있다. 그렇다면 무엇이 문제인가?

그 이유는, 여러가지 방법론 사이의 중요한 차이점이 그것들이 가지고 있는 정보가 아니라, 정보가 전달되는 방법과 방향의 특성 - 프로세스에 있기 때문이다. 우리에게는 프로세스의 흐름을 잘 반영하는 도구를 찾아보기가 힘들다. 만약 이러한 요구를 잘 반영한 도구가 있다면, 요구의 반영은 잘 신경써서 만들어진(crafted) 사용자 인터페이스의 형태로 나타날 것이다. 이러한 점에서, 프로젝트 관리 도구의 불편함은, 도구의 기능적인 면과 도구가 다룰 정보에만 치중하고, 사용자 인터페이스 즉, 도구를 다루는 방법은 무시하는 프로그래머들의 일반적인 경향이 반영된 결과일런지도 모른다.

한편, 기존의 프로젝트 관리 도구들은 방법론의 특성을 제대로 반영하지 못할 뿐만 아니라, 그러한 방법론이 실무에 적용되면서 발생하는 변형들도 잘 반영하지 못한다.

프로세스 상의 약간의 변형이나, 필요한 정보 자체의 변형이 발생하는데, 대부분의 프로젝트 관리 도구는 이러한 변형을 잘 반영할만한 유연성을 갖추고 있지 못하다. 반대로, 특정 방법론(이른바 표준 방법론)에 잘 맞춰져있는 도구에 자신들의 방법론을 맞추는 것은 완전히 어불성설이다. (이는 많은 사람들이 저지르는 실수중의 하나이다.) 프로젝트의 환경에 따라 방법론은 적절하게 변형되기 마련이다.

nohmad 옹의 최근의 웹 어플리케이션에 관한 글에서 소개된 sproutliner는 작업 관리를 위한 도구다. sproutliner는 자기가 원하는 대로 작업 항목의 필드를 늘리거나 줄일 수 있는데, 위와 같은 프로젝트 관리 도구상의 필요를 반영하는 것이 아닐까. 물론 작업 관리라는 한정된 기능을 수행하고 있고, 정보의 변형에 있어서의 요구만을 반영하고 있어서, 아쉬운 점이 좀 남는다.

또, 어떻게 보면, 방법론에 무관하게 유연한 도구를 만들고 싶다는 목적을 달성하기 위해서는, 커다란 단일한(monolithic) 도구가 아니라, sproutliner처럼 서로 통신할 수 있고 조합할 수 있는 작은 단위의 도구들의 형태를 가져야할 지도 모른다.

기회가 된다면, 내 주변의 - 나 자신 또는 나를 포함한 팀의 - 방법론에 잘 들어맞는 프로젝트 관리 도구를 만들어보고 싶다.

루비 프로그램 맨 위에 다음과 같이 적어주면 된다. (여기를 참고.)

또는 ruby의 command-line parameter로 '-rprofile'을 줘도 된다. (역시 profile module을 맨처음 require하는 의미)

이런 방식으로 profiler와 함께 실행시켜보면 다음과 같은 결과를 볼 수 있을 것이다.

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 35.56     0.16      0.16       86     1.86     7.44  Kernel.require
  8.89     0.20      0.04       57     0.70     1.58  SubscriptionManager#constructSubscriptionFromRow
  8.89     0.24      0.04      203     0.20     0.30  Kernel.puts
  6.67     0.27      0.03       23     1.30    10.00  Array#each
  6.67     0.30      0.03        7     4.29    12.86  Mysql::Result#each
  6.67     0.33      0.03      728     0.04     0.04  Array#[]
  4.44     0.35      0.02      407     0.05     0.05  IO#write
  4.44     0.37      0.02       18     1.11     1.11  Mysql#initialize
  2.22     0.38      0.01       92     0.11     0.11  Kernel.==
  2.22     0.39      0.01       80     0.13     0.13  String#==
  2.22     0.40      0.01       13     0.77     0.77  Module#attr_accessor
  2.22     0.41      0.01       18     0.56     0.56  Mysql#query
  2.22     0.42      0.01      119     0.08     0.08  Fixnum#to_s
  2.22     0.43      0.01       31     0.32     0.32  Module#attr_reader
  2.22     0.44      0.01       22     0.45     0.45  Module#alias_method
  2.22     0.45      0.01       57     0.18     0.18  Subscription#initialize

한편, eruby interpreter랑은 좀 이상하게 동작하는 (무한루프) 문제가 있어서, eruby tag를 모두 빼고 테스트해야만 했다. 이 문제는 좀 더 살펴보아야겠다.

이상직님의 삼보 컴퓨터 (2005/5/19 목)에서 발췌

당시에 전산실에서는 PC가 완전히 듣도보도못한 기술이었겠지만 지금 듣고 있는 시스템 엔지니어링 클래스에서 들은 바로는 그 당시 우리나라 연구기관에서도 IBM 칩과 PCDOS를 가져다가 PC를 개발했었다고 한다. 대한민국이 브로드밴드 보급률로 유명해진 것은 얼마되지 않았지만, 시스템 엔지니어링 클래스를 가르치시는 전길남 교수님은 1980년대부터 국내 인터넷의 기반을 닦은 인물이다. 그 외에도 ETRI에 의한 TDX라든가 CDMA 기술의 개발도 우리나라에 보편화되기 훨씬 전부터 연구를 시작했던 것이었다. 요즘 한창 얘기가 많이 나오는 3G나 DMB 기술도 마찬가지다. 전길남 교수님의 랩에서는 수년 후에나 보편화될 가능성이 있는 람다 네트워킹(lambda networking)을 연구하고 있단다.

회사에 다니다보면, 또는 기술에 관련된 웹사이트를 돌아다니다보면, 나를 포함해 수많은 사람들이 동시대의 기술들을 허겁지겁 따라가는 모양새가 문득 눈에 띈다. 반면에, 대학 연구실이나 연구소 사람들은 10년 후에나 보통 사람들이 구경할 수 있는 것(물론, 어떤 것들은 아예 볼 일이 없게되겠지만)을 연구한다. 이건 누구나 알고 있는 평범한 사실이겠지만, 회사를 다니다가 복학해서 그 두가지 광경을 직접 보고 있노라니, 상아탑에 살고 있는 사람들에 대해 살짝 부러운 생각도 든다. 단지, 자신의 생존 조건과 격리된 학문에 대한 어설픈 동경인가. 글쎄.

10년 후에나 보편화될 기술을 연구한다는 것은, 10년 후의 시스템의 초기조건을 형성하는 일이다. 그리고 그 시스템은 초기조건에 민감하다. 자신의 밈(meme)이 영향을 미칠 수 있는 범위가 넓을 수록, 그리고 그 영향에 있어서 중요한 요인이 될 수록 가치있어 보이는 것, 일변 당연하지 않은가.

물론, 현업에서도 그러한 일이 불가능하란 법은 없다. 10년 단위는 아니더라도 신기술을 만들어내는 3-5년 단위의 프로젝트는 어느 정도 대규모의 회사라면 쉽게 볼 수 있고, 그들이 세계에 미치는 영향은 때로 어마어마하다. (예를 들어, 발매되지도 않은 XBOX 360, PS3에 대한 최근의 열풍을 보라.) 따라서, 현업과 상아탑이라는 이분법으로 보기에는 좀 무리가 있을지도 모르겠다.

대다수의 일반인들은 기술을 소비하기만 한다. 특정 분야에서 어느 정도 전문 교육을 받은 사람들은 다른 사람이 생산한 기술을 소비하면서 또 다른 기술과 가치를 창출한다. 그리고, 소수의 사람들이 새로운 기술을 생산해낸다. 이러한 기술 생산과 소비의 (양적이기보다는) 질적인 차이에 따라 생산 위주의 계층으로부터 소비 위주의 계층이 형성된다고 보는 것이 좀 더 현실에 적합할까.

그렇다면 나는 나에게 질문을 던진다. 난 이들 계층 중 어디쯤 위치하고 있을까. 그리고 어디에 위치하기를 원하는가.

나는 친구와 함께 언덕과 산들로 둘러싸인 녹초지를 걷고 있었다. 매우 외딴 곳이어서, 우리는 겨우 히치하이킹을 할 수 있었고, 운전사 양반은 넉살이 좋아보였다.

언덕을 둘 셋 정도 넘었을까, 우리의 시야에는 강이 들어왔고 (강이라기보다는 바다 같기도 하고), 길은 강의 얕은 목을 가로질러 뚫려있었다. 강바닥에는 모래질의 흙이 투명하게 비쳤고, 마침 해가 질 무렵이라, 강(바다?) 저편은 아름답게 빛나고 있었다. 나 뿐만이 아니라 친구도 운전사도 그러한 경치에 경탄하고 있었고, 우리는 거기에 대해서 이야기를 나누었다.

마침 강을 건너고나서 바로 곁에 있는 높은 언덕에는 커다란 장원이 보였고, 우리는 경치도 구경할 겸해서 쉬어가기로 했다. 그 장원에는 인적이라고는 찾아볼 수 없었고 이상한 분위기가 감돌았다. 우리는 이곳저곳을 돌아다니다가 뒷뜰의 텃밭 정도임직한 곳을 발견했다.

그 밭에서는 코를 찌르는 악취가 났고, 처음에는 봄철의 작물을 심기 위해 거름을 뿌려놓은 것으로 생각했다. 하지만, 가까이 다가가자 반쯤 썩은 수백구의 시체들이 뒤섞여있는 것을 발견할 수 있었다. 나는 친구를 바라보았고, 또 운전사 양반을 바라보았는데, 내 상상인지 진실인지 몰라도, 그 운전사의 표정은 그 장원의 사연에 깊게 관여한 자의 것이었다. 모르는 체 우리를 꾀어 여기까지 데려온 것인가?

팔다리가 서로 뒤엉키고 살점이 반쯤 썩고 뼈가 들어난 시체들 사이에는 갓태어난 듯한 아이의 머리통도 뒤섞여있었다. 나의 머리속은 새하얗게 되어서 아무런 생각을 할 수 없었고, 운전사는 곁에서 무언가를 계속 중얼거렸다. 갑자기, 아이의 머리통이 (시체가?) 울음소리를 내면서 시체 무덤을 헤치고 튀어나왔다. 마치 시체로부터 살아있는 아이가 태어나는 듯이.

모든 게 깜깜해지며 빙글빙글 돌았고, 나는 잠을 깨었다.

Peopleware : Productive Projects and Teams, 2nd Edition by Tom Demarco, Timothy Lister

소프트웨어 개발 프로젝트는 수많은 요소들이 복잡하게 상호작용하는 시스템이다. 그렇다면 가장 중요한 요소는 무엇일까? 어떤 사람들은 프로세스와 문서라고 얘기하고, 어떤 사람들은 소프트웨어 개발자의 장인정신(craftmanship)에 있다고 생각하고, 또 다른 사람들은 조직이라고 얘기한다. Peopleware에서 얘기하는 것은 바로 사람이다.

Peopleware의 핵심은 소프트웨어 개발 프로젝트에서 개발자들을 행복하게 만들어주어야 한다는 것이다. 기업가나 관리자의 도덕성의 차원에서 이를 주장하는 것이 아니다. 개발자들을 행복하게 해주는 것이, 소프트웨어 개발 프로젝트의 생산성과 품질을 개선하기 위한 가장 중요한 요인 중의 하나라고 주장하고 있다.

이에 대한 중요한 근거 중의 하나는 소프트웨어 개발은, 기존의 제품을 생산하는 일(예를 들어, 치즈 버거 가게)과 완전히 다른 종류의 일이라는 것이다. 소프트웨어 개발은 기본적으로 사람들 사이의 커뮤니케이션이라는 점을 강조한다. 따라서, 치즈 버거 아르바이트생처럼 마음에 안들면 바로 자르고, 다른 사람을 고용할 수 있는 것이 아니고, high turnover - 높은 인력교체율을 경계해야한다고 주장한다.

초과근무(overtime)나 일중독(workholic)에 대해서도 마찬가지다. 개발자 자신이 원하든 원하지 않았든, 초과근무는 대체로 개발자의 삶을 행복하지 못하게 만들고, 따라서, 높은 인력교체율의 원인이 된다는 것이다. 그리고, 장기적으로 높은 인력교체율는 소프트웨어 개발 프로젝트 또는 기업의 비용을 증가시킨다는 것이다.

품질(quality)에 대해서는 매우 재미있는 생각을 보여주고 있다. 현실적으로 품질은 다른 중요한 비즈니스 요소(예를 들어, time-to-market)에 의해 희생될 수 있는 요소임을 인정하지만, 품질이 개발자를 행복하게 만들어줄 수 있다는 면에서 불필요한 품질을 적절하게 추구해야할 필요성이 있다고 얘기한다.

파킨슨의 법칙(Parkinson's Law) - 어떤 일이든 그 일에 대해 할당된 기간을 채운다, 즉, 기간을 촉박하게 잡을 수록 생산성이 높아진다는 생각은 회사를 다닐 때에도 관리자나 같은 개발자들을 통해 자주 접할 수 있었던 생각이었다. DeMarco는 이번에는 실험 데이터를 통해서 이를 정면으로 반박한다. Parkinson 은 과학자가 아니었고, 그의 법칙도 어떤 근거가 있는 것이 아니라는 것이다. time-to-market이 중요한 요소일 경우에 어느 정도의 필요성은 인정하지만, 항상 적용하는 것은 어딘가에 문제가 있는 것이라고 지적한다.

여기까지가 Part 1의 중요한 내용들이다. Part 2에서는 지난 번에 부분적으로 언급했던 사무실(office) 환경과 개발자의 생산성과의 관계를 얘기하고 있고, 그 이후로는 주로 팀 빌딩(team building) - 어떻게 좋은 팀을 만들 수 있는가를 얘기하고 있다. 이 내용들 또한 실제로 내가 회사를 다닐 때 체감했던 내용들이고 또, 중요한 내용들이라고 생각한다. 기회가 된다면, 이 내용들에 대해서도 차후에 따로 다루어보겠다.

흥미로운 것은 많은 1987년에 처음 쓰여진 이 책이 최근에 유행하던 XP와 같은 방법론의 생각도 어느 정도 담고 있다는 것이다. (예를 들어, 40-hour week practice) 즉, XP는 어느날 갑자기 누군가의 머리로부터 튀어나온 것은 아닌 것이다. DeMarco와 Lister는 그들의 컨설팅 경험을 이 책에 집약해놓았고, 내 경험에 비추어보더라도, 현업의 개발자들이 항상 체감하고 있으면서도, 자신의 환경을 바꾸려고 시도해보지는 않은 그런 내용들을 담고 있는 것 같다. 모든 관리자들이 이 책을 읽고 개발자들에게 기업과 개발자가 모두 행복해질 수 있는 바람직한 환경을 제공해주면 더할나위 없이 좋을 것이다. 하지만, 모든 개발자들이 이 책을 읽고 관리자에게 자신이 필요한 것을 요구하는 것이 그러한 날을 더 앞당길 수 있는 방법이 되지 않을까.

역시 크리스마스 시즌에 개봉할 "해리 포터와 불의 잔"의 트레일러(mov)가 나왔군요. 좀 더 성숙한 엠마 왓슨의 모습입니다. 애들은 빨리 크는군요.

영화 나오기 전에 해리 포터 동화책 버전도 읽어봐야하지 않을까 하고, 알라딘을 뒤적거리다, 그만두었습니다. 그냥 영화만 볼렵니다. 시간도 없고, 돈도 없고, 결정적으로 별로 안 당기는군요. 그 시간에 딴 책을 읽는 게 낫겠습니다.

인터넷 어플리케이션의 세상을 살아가는 소프트웨어 개발자로서, 놓칠 수 없는 흐름이, RIA(Rich Internet Application) 기술의 흐름이다. ActiveX가 기술적으로 좋은 선택이 아님에도 불구하고, 우리나라에 ActiveX 기술이 보편화된 것은, 바로 RIA 기술에 대한 요구의 반영이라고 볼 수 있다.

DHTML이나 Gmail에서 도입된 후 유행하고 있는 ajax, Flash 등도 모두 이러한 흐름의 한 갈래라고 볼 수 있다. (nohmad님의 flickr-throws-flash-adopts-dhtml 참고)

또한, 이러한 frontend 기술들을 backend 기술과 조합한 RIA 솔루션을 제공하는 회사들도 있다. (일전에 #perky 채널에서 rapzzard님이 알려주신 것들을 정리해보았다.)

• Smart Client와 ASP.NET
• Laszlo
• Flex
  • Flex Overview: 상당히 인상적인데, 이것을 처음 본 사람이라면, Adobe와 Macromedia의 합병을 새로운 눈으로 볼 수 있을 것이다.
  • Flex Builder Videos
• Bindows

얼마전에, ACM Queue에 올라온 Death by UML Fever와 UML Fever: Diagnosis and Recovery를 읽었다.

UML을 사용하면서 발생하는 여러가지 부정적인 현상들을 UML Fever라고 표현하고 있다. 이 글을 쓴 Boeing Company의 Alex Bell은 UML Fever의 궁극적인 원인은 그 기술이나 프로세스를 선택하고 적용해야하는 개인의 경험 부족에 있다고 본다. 쓸데없이 메타포를 남발해서 읽기가 굉장히 힘들지만, 요약하면 다음과 같은 현상들로 나타낼 수 있다.

• 자신의 프로그램에 어떠한 기술과 프로세스가 적합한지 평가하는 것이 아니라, 다른 사람이 다른 프로그램에서 사용한 것들 그대로 받아들이는 행위.
• UML 다이어그램만 있으면 자동적으로 소프트웨어를 개발할 수 있고, UML이야말로 모든 소프트웨어 공학의 해결책이다라는 생각.
• UML artifact를 많이 가지고 있을 수록 가치가 증가한다는 생각.
• 쓸데없이 너무 많거나 상세한 UML artifact를 만들어내는 것을 소프트웨어 개발 프로세스나 프레임워크 혹은, UML 그 자체의 탓으로 돌리는 행위.
• 생산성의 향상을 이유로, 자신의 프로세스에 맞지도 않는 비싼 UML 툴을 구입하는 행위.
• 이미 불필요해진 UML artifact를 버려서는 안된다고 생각하고, 비용을 감수하면서 관리하려는 경향.
• 아무런 목적이 없이 UML을 만드는 행위.
• 세분화된 기능적 decomposition을 use-case로 만들려는 경향. (모델을 단순화하려는 목적을 잃고, 오히려 더욱 이해하기 힘들게 만든다.)
• UML 다이어그램을 극단적으로 상세하게 만드려는 욕구. (어떤 것이 중요하고 중요하지 않은지 판단하기 위해서는 코딩 경험이 중요하다.)
• 상세한 디자인 요소들을 포함하는 거대한 UML 모델을 만드는 행위. (코드 없이, 모든 정보를 표현할 수 있다는 생각.)
• UML 디자인 모델과 코드로부터 reverse-engineer한 구현 모델의 차이를 인지하지 못하는 것
• 모든 프로젝트 구성원들이 경험에 상관없이 교환가능하다는 생각.
• 전문적인 기술이 없는 사람을 그 기술이 필요한 position에 기용함으로써, 조직 전체가 그 사람의 practice를 best practice로 여기게 되는 현상.
• 간단한 디자인 툴이나 언어 문법에 대한 클래스에 사람을 보내고서, 전문가로 될 것이라고 기대하는 행위.

UML Fever의 여러가지 현상은 단지 UML에 한정되는 것이 아니라, Software development에서 사용하는 모든 기술, 더 나아가서는 모든 기술에 적용된다고 생각한다. 어떤 기술에 대한 제대로 된 지식이나 경험의 부족은, 그 기술이 어떠한 해결책에 적합한지를 제대로 평가하지 못하게 만들고, 그 기술에 대한 맹신이나 잘못된 적용을 낳는 것 같다. 이와 비슷한 얘기를 삼색볼펜초학습법과 소프트웨어 엔지니어링이란 글에서도 언급을 했었다.

토요일 새벽 무렵에 프로젝트 결과물을 메일로 보내고, 한숨 돌렸습니다. 그리고나서, 일주일간 멀리하고 있었던 Counter-strike: Source를 다시 잡았습니다.

며칠 전 릴리즈된 de_port 맵을 오늘 처음으로 플레이해보았는데, 꽤 재미있더군요. 그동안 Source 버전에는 넓고 확 트인 맵이 별로 없어서 좀 답답한 느낌이 있긴 했죠. 상당히 넓은 맵이라 스나이퍼들이 필수적으로 필요하고 (의도적으로 스나이퍼들을 위한 장소들을 제공해주고 있습니다.), 더군다나 지하 통로나 건물을 통해서 생기는 경로가 많아서, 돌아다니다 보면 화력이 분산되는 면이 있습니다. 양측 실력이 비슷하면, 후반에서 난전이 되는 경향이 있죠.(전 난전을 좋아합니다. 순발력이 좋다기보다는 경험많은 노련한 플레이어거든요.) 반대로 한쪽 실력이 더 좋으면, 상대편 스나이퍼들을 학살해주는 재미가. ;;;

더불어, de_inferno도 처음 해봤는데요. 맵이 상당히 예뻐졌습니다. A bomb site에서는 통로에 엄폐물이 많아져서, CT에게 상당히 유리해졌고, B bomb site에서는 앉아서 지나야 했던 구멍이, 오르막으로 바뀌어서 TR이 진입하기에 좀 더 쉬워진 느낌입니다.

하핫, 28 킬의 [=FoxHound=] Raiden이 접니다.

다음은, 이른바 "비키니 모델"을 적용한 화면입니다. 덕분에 인질맵을 플레이하는 게 좀 즐겁죠. 호홋. (저는 인질맵에서 TR을 선택하는 경향이 있어서 더욱 좋죠)

릴리즈를 계획한 것은 꽤 오래전인데, 학업이 바쁘다보니 차일피일 미루다, 드디어 Galaxy 0.1.0을 릴리즈 했습니다. 곧 Rubyforge 탑에 올라오겠죠.

결함도 많고 마음에 안드는 것도 많이 있지만(코드는... 물론 엉망입니다.), 일단은 릴리즈하고 피드백 받으면서 개선해나가는 것이 좋을 것 같습니다. Eric Raymond의 The Cathedral and the Bazaar를 읽어보신 분이라면 이해하시리라고 생각합니다.

그러한 결함 중 한가지 예를 들면, 설치 방법이 너무 복잡한 문제가 있는데요. crontab 사용을 포기한다든가, RubyOnRails로 간다든가 해서, 설치 방법을 단순화할 수 있는 방법을 찾아보아야할 것 같습니다.

릴리즈를 위해서 데모 사이트도 만들었습니다. 관심 있으신 분은 둘러보시길.

한가지 덧붙일 것은, 0.1.0 릴리즈와 동시에, 갤럭시 개발 Iteration 3를 마치고, Iteration 4가 시작된다는 것입니다. Iteration 4에서 개발할 것들을 결정해서 곧 올리도록 하겠습니다.

likejazz.COM에 달았던 comment덕에 받은 comment.

내가 영어 단어를 사용하는 것은, 언어 사대주의와는 완전히 거리가 멀다. 완전히 실용적인 이유 - 가볍게 적는 글에 번역의 비용을 들이기는 부담스러운 이유라든가, 원문의 글을 오해 없이 옮기거나 쉽게 찾아볼 수 있도록 하기 위한 이유라든가, 하루에 접하는 언어의 양이 한국어보다도 영어가 더 많다든가 하는 이유 때문이다.

하지만, 요즘 들어, likejazz에서 뿐만 아니라, 이오덕 선생의 언어사대주의에 관한 글을 많이 링크하는 것을 보게되었다. 내 주변의 엔지니어들 중에는 말을 할 때도 영어를 사용하는 사람이 많은데, 언어사대주의 때문에 그렇다는 생각은 전혀 하지 않는다. 위에 적은 것과 유사한 순전히 실리적인 목적이다. 실제로 사대주의와 거리가 먼 사람에게 저러한 글을 링크해주는 것은 거의 인신공격적이라고 생각한다. 물론, 언어사대주의나 순전히 과시욕에서 영어를 사용하는 사람들도 있다. 하지만, 그렇지 않은 사람들에게는 언어 사대주의를 내세우는 방식보다는 우리말 사용의 실리나, 한국 문화의 발전 또는 정체성 확립과 같은 이유를 통해 합리적으로 설득을 하는 것이, 그들이 원하는 올바른(?) 우리말 사용의 확산을 앞당기는 길이라고 생각된다. 그 같은 이유로 나를 설득하는 것은 힘들겠지만 말이다.

한가지, 영어 단어를 사용하는 것이 (글을 쓴 사람을 포함하여) 독자가 글을 읽게 힘들게 만드는 것은 인정한다. 이러한 면에서, 한영 병기를 사용하는 것이 좋은 해결책이 된다고 생각한다. 문화적 정체성 운운은 내게는 통하지 않는다. 문화의 다양성에는 동의하지만, 특정한 문화를 무조건 수용하라는 태도는 마음에 들지 않는다. 무엇보다도, 영어공용론을 반대하는 사람들의 논지처럼, 내게 언어는 "한낱 연장에 지나지 않"기 때문이다.

한편, 어떤 사물이나 사건의 본질을 파악하기 전에, 그에 대한 유행하고 있는 생각을 비판없이 무조건적으로 받아들이고, 아무 경우에나 사용하는 경향을 너무나도 자주 본다. 블로그가 유행하면서 다른 사람들의 생각을 더욱 세세하게 볼 수 있게 되면서 이러한 현상을 더욱 자주 볼 수 있는 것 같다. 요즘 유행하는 "언어 사대주의"의 비판도 이러한 경향 중의 하나가 아닐까?

무엇이 옳든 간에, 로마에서는 로마의 법을 따라야 하는거겠지만.

다음은 likejazz.COM에 올라온 War Room에 관한 글에 대해 적은 comment. "DeMarco는 Peopleware에서 독립된 개발환경을 주장하지만, XP 또한 옹호하고 있는데, XP의 War Room과 배치되지 않느냐라는 생각"에 대한 반론이다. 여기서 김창준님의 comment도 참고.

이 comment를 적을 당시에는 마침 Peopleware의 그 부분을 읽는 중이었는데, comment를 쓰고 나서 읽은 그 다음 단락에서, comment에서 내가 얘기한 것과 똑같은 논지의 얘기가 나왔다. 즉, 팀은 대체로 같은 일을 하기 때문에, noise나 interruption에 의한 문제가 별로 없다는 것이다.

학생의 비극이랄까요. 악몽의 주간입니다. T.T (아참! Ta-Da Lists 한글이 이제 되더군요.)

	디지탈 실험, #5 준비 (2005년 5월 12일)
	전산학 프로젝트, 디자인 문서 (2005년 5월 12일)
	영미소설, 발표할 내용 한번쯤 더 읽어보기 (2005년 5월 12일)
	영미소설, 백경에 나오는 성서적 상징에 대한 조사 (2005년 5월 12일)
	영미소설, 중간 레포트 (2005년 5월 16일)
	한국근현대사, 교재 요약 숙제할 것 (2005년 5월 16일)
	시스템 엔지니어링, 중간 발표 다시 준비 (2005년 5월 18일)
	한국근현대사, 중간 레포트 (2005년 5월 27일)

	한국근현대사, 조선독립선언과 기미독립선언문의 비교 레포트 (2005년 5월 9일)
	시스템 엔지니어링, book presentation 준비 (2005년 5월 11일)
	문학의 이해, "칼의 노래" 감상문 (2005년 5월 10일)

http://josephjang.tadalist.com/lists/public/38951

“칼의 노래”는 임진왜란, 정유재란을 배경으로 한, 이순신의 삶을 그린 일종의 전기 소설이자 역사 소설이다. 줄곧 1인칭 시점으로 그려져있고, 이순신 자신이 한 일들을 나열해 놓은 식이 많아서, 읽는 동안 딱딱하다는 느낌도 들었고, 마치 이순신 자신이 쓴 일기 – “난중일기”의 현대어 번역판을 읽는 느낌이었다. 리얼리즘? 글쎄. 김훈의 작품을 별로 읽어보지 않은 나로서는 당대최고의 산문가라는 평에 약간은 반발심을 느끼지 않을 수 없었다.

대한민국의 정규 교육과정을 거친 사람이라면, 이순신은 어린 시절, “존경하는 인물”의 후보들 가운데 한명이었을 것이다. 그가 원균의 모함을 받고, 백의 종군을 하고, 몇몇 대첩에서 크게 승리했다는 역사적 사실이나, 그가 지었다는 유명한 시조, 그가 삶을 거두면서 한 얘기 정도의 조각들은 이른바 상식일 것이다.
억울한 누명을 쓰고도, 백의 종군을 해서, 종묘사직을 지켜내는 그 충의! 거북선이라는 인류최초의 철갑선을 발명한 희대의 지장! 죽음에 이르러서도 혹여 자신의 죽음이 전쟁에 영향을 미칠까 자신의 죽음을 감추는, 대의를 위한 그 희생 정신! 사직을 위태롭게 하는 왜를 물리치고 나라를 구한 무인! 그는 바로 영웅의 전형이었다.
어느 나라에나 위대한 정복자라든가 숭고한 방어자와 같은 국가적 민족적 영웅은 있게 마련이다. 그러한 영웅들이 “만들어진 영웅”이라는 사실은 더이상 비밀이 아니다. 영웅은 비극적으로 스러져가고 없어도, 그의 영웅담은 계속 재생산되면서 국가적 민족적 정체성을 확립하는 도구가 되었던 것이다.
영웅의 일대기를 역사로 본다면, 영웅이 일대기가 그 도구적 역할에 의해 창조되었다는 사실은 도리어, 역사가 그 도구적 역할에 의해 창조되었다는 사실로부터 연역될 수 있다는 것을 깨달을 수 있을 것이다. 역사에 대한 상대주의적 관점이 확립된 이래로, 역사는 상아탑의 학문이 아니라, 역사가 개인의 감정이나 정치적인 도구의 산물로서 해석되기 시작했다.
이처럼, 오랜 군사 독재가 지배하던 시절의 영웅 이순신에는, 어떤 불순한 의도가 섞여있으리란 생각을 떨칠 수 없다. 충의정신, 얼마나 전근대적인가. 그의 희생정신은 파쇼에의 의심마저 들게한다. 거북선이 실제로는 이순신이 창제한 것이 아니라는 사실은 언급할 필요조차도 없다. 하지만, 신기한 것은, 이러한 낡은 정신들이나 인식은 철이 들면서 기꺼이 버렸지만, 이순신이라는 인물은 영웅이라는 생각이 머리 속에 각인되어있다는 것이다. 게다가, 그 영웅을 둘러싸고 있는 정신들은 완전히 지워진 것이 아니라, 내 무의식 중에서 그 본연의 목적을 충실히 수행하고 있을지도 모르는 일이다. “내 귀의 도청장치”랄까.

정치가나 독재자가 역사 속의 영웅을 적절하게 해석하고 변용하여 모종의 목적을 이루어 내려는 것처럼, 작가도 글을 쓰는 목적이 있고, 문학작품 속의 허구적 인물을 통해 이루고자 하는 목적이 있다. 그렇다면, 역사가 아닌 문학이, 역사가가 아닌 김훈이라는 작가가 얘기하는 영웅 이순신은 어떤가를 살펴보아야할 것이다.
김훈의 이순신은 임금이나 다른 장수들의 무능함, 세상이 돌아가는 방식을 제대로 인식하고 있다. 그러면서도, 필요할 때는 맞서고, 필요할 때는 타협하는, 현실적이고 합리적인 인간이다. 그는 군기를 어긴 자는 엄하게 다스려 곤장을 치고 목을 베나, 아들의 마지막 순간을 얘기해달라고 청하며 슬퍼하는, 엄격한 아버지이자, 동시에 자상한 아버지이기도 하다. 여진이라는 한 여자에 대한 욕과 정을 동시에 지닌, 그는 한 인간이기도 하다. 한마디로, 김훈의 이순신은 전근대에 살고 있는 현대적 인물이다. 그는 잘 나가는 기업의 중역 정도의 캐릭터를 맡아도 아무런 문제가 없을 정도다.
김훈의 이순신은 자신의 무능력함에 고뇌하면서도, 때로는 투쟁하면서, 때로는 타협하면서 세상을 헤쳐가는 인간형을 나타낸다.
임금이나 원균, 명의 수군 총병관 진린과의 거듭되는 정치적인 게임에서도 이순신의 그러한 면을 잘볼 수 있다. 세상은 그가 원하는 것을 도와주지 않지만, 그는 적절하게 투쟁하거나 타협함으로써 그가 원하는 것을 얻어낸다. 이러한 정치 게임도 재미있게 볼 수 있지만, 이순신의 인간형을 가장 극적으로 보여주는 부분은, 이순신이 그와 정분이 있던 여진의 시체를 발견하지만, “내다 버려라.”라고 명령하는 장면과 이 때 그의 심정이 아닐까. 그는 여진의 죽음앞에서 성욕을 느끼는 자신을 발견하며, “세상은 칼로써 막아낼 수 없고 칼로써 헤쳐나갈 수 없는 곳”이라는 것을 확인한다.
한편, 어린 시절 알고 있던 이순신의 영웅성에 비해, “칼의 노래”의 이순신은 너무나 인간적이다. “칼의 노래”를 읽는 것은 마치 그리스 로마 신들의 찬란함에 가려진 인간적인 모습이 드러나는 장면 같달까. 이순신의 인간적임은, 그의 주변에 있는 인물들의 인간적임과 어우러져 묘한 여운을 준다. 예를 들어, 자신이 사랑하는 여자와 탈영하다가 붙잡힌 군관의 자기 여자를 살려달라는 애원 앞에 선 이순신의 모습을 보자. 이순신은 그 군관의 생사여탈을 결정할 수 있는 신 또는 영웅의 위치에 있다. 하지만, 곧바로 형 집행을 명령하는 장면과 애원대로 그 여자를 놓아주는 장면 사이에 있는 여운은, 노골적인 찬사보다도, 이순신의 인간성을 훨씬 돋보이게 만들어준다.
영웅에는 필수적인 조건이 있다. 보통 사람보다 싸움을 잘한다거나, 불사의 몸을 가졌다거나, 지혜로운 것이 아니다. 바로 영웅을 영웅으로 기억해주는 사람들의 가치나 생각을 반영해야한다는 것이다. 이러한 의미에서, 김훈의 이순신은 김훈의 영웅이자, 김훈이 현대를 살아가는 우리 모두에게 영웅으로서 제시해주고 싶었던 이순신의 모습이 아닐까? 우리가 삶의 고통이라는 질곡에서 빠져나올 수 있다는 실날같은 희망을 주는 인간적인, 너무나 인간적인 본보기를 보여주고 싶었던 게 아닐까?

세상의 끝이……이처럼……가볍고……또…….고요할 수 있다는 것이……, 칼로 베어지지 않는 적들을…… 이 세상에 남겨놓고…… 내가 먼저……, 관음포의 노을이…… 적들 쪽으로……

“칼의 노래”는 이 마지막 독백을 통해 죽음을 앞둔 영웅이, 아니 한 인간이, 어떤 진리를 깨닫는 것으로 끝난다. 그것은 “칼로 베어지지 않는 적”이라는 인간의 힘으로 어찌할 수 없는 문제에 고뇌하며, 진중한 영웅의 삶을 살았으나, 결국 죽음의 앞 – 세상의 끝에서는 모든 것은 아무런 가치를 지니지 않게 되어버린다는, 너무나 진부하지만 역시 참일 수 밖에 없는 삶의 진리가 아닐까.

덧붙임: 위의 글은 "문학의 이해" 강의 숙제로서, 가능한 한 "무난하게" 쓰려고 노력한 것이지만, 사실 그다지 새로울 것도 없는 문제의식이라고 생각한다. 평범한 주제를, 이순신이라는 대중적인 소재와 결합한, 베스트셀러용 작품이었다고 생각한다. (김훈 씨 자신도, 자신은 밥벌이를 위해 글을 쓴다고 했으니, 대단히 예의에 어긋나는 말은 아닐 것이다.) 그 결합 자체가 도발적이었는가 하면, 우리가 살고 있는 시대에 있어, 결코 아니다라고 생각한다. 추천하기는 힘들 것 같다.

대부분의 블로그 서비스가 트랙백 표준을 지키지 않고, EUC-KR 트랙백에 의존하고 있어서 MT로 트랙백을 보내는 데에 애로사항이 있다. 물론, Gratia님의 트랙백 패치도 있지만, 패치 자체가 복잡해서 귀찮은 나머지, 그냥 euc-kr로 보내도록 수정해버렸다. charset을 적절히 설정해주는 한 트랙백 표준 1.2에 위배되는 것은 아니니까... 그리고, UTF-8을 지원하는 블로그 구현이라면, 트랙백 표준도 제대로 구현하고 있을거야, 라는 약간은 안일한 가정. 다음 코드는 MT/lib/MT.pm의 수정사항.

의도한 것은 아닌데, 어쩌다보니 마루타가 되어버린, 젊은 거장님과 윗치님, 그리고 묵형에게 심심한 사과의 말씀을 드려야겠다. (사실 묵형쪽은 의도적으로 테스트한 것이다!)

        ## Build query string to be sent on each ping.
        my @qs;

        # BEGIN trackback patch by Joseph Jang
        #push @qs, 'title=' . MT::Util::encode_url($entry->title);
        #push @qs, 'url=' . MT::Util::encode_url($entry->permalink);
        #push @qs, 'excerpt=' . MT::Util::encode_url($entry->get_excerpt);
        #push @qs, 'blog_name=' . MT::Util::encode_url($blog->name);
        use Encode;
        push @qs, 'title=' . MT::Util::encode_url(Encode::encode("euc-kr", Encode::decode("utf-8", $entry->title)));
        push @qs, 'url=' . MT::Util::encode_url(Encode::encode("euc-kr", Encode::decode("utf-8", $entry->permalink)));
        push @qs, 'excerpt=' . MT::Util::encode_url(Encode::encode("euc-kr", Encode::decode("utf-8", $entry->get_excerpt)));
        push @qs, 'blog_name=' . MT::Util::encode_url(Encode::encode("euc-kr", Encode::decode("utf-8", $blog->name)));
        #END

        my $qs = join '&', @qs;

        #$qs = Encode::encode("euc-kr", Encode::decode("utf-8", $qs));

        ## Character encoding--best guess. Default to iso-8859-1, just as we
        ## do in MT::Template::Context::_hdlr_publish_charset.

        # BEGIN trackback patch by Joseph Jang
        #my $enc = $mt->{cfg}->PublishCharset || 'iso-8859-1';
        my $enc = "euc-kr";
        #END

책으로 읽어보지는 않았지만, (적어도 판타지 장르 소설계에서는) 너무나 유명한 작품이죠. 디즈니에서 영화로 제작중이고 2005년 12월 9일에 개봉한답니다.

http://www.narnia.com/

다음은 티저 트레일러(.mov)입니다. (Slashdot에 떴더군요!) 트레일러를 보니까, 책을 읽고 싶은 마음이 굴뚝같지만, 너무 바빠서 참아야겠습니다. 방학 때에나 도전해봐야겠군요.

http://tinyurl.com/bmdhh

GCC 4.0: A Review for AMD and Intel Processors

-O3 옵션을 사용한 벤치마크. amd64에서는 컴파일 속도가 기존 버전에 비해서 느리게 나오고 P4에서는 빠르게 나온다.

GCC 4.0 C++ Compilation Speed

-O0 옵션을 사용한 KDE 코드에 대한 벤치마크. 상당한 개선을 볼 수 있다.

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition by Frederick P. Brooks

소프트웨어 엔지니어링 과목을 수강한 적이 있다면, 소프트웨어 엔지니어링에 어느 정도 관심이 있다면, 한번쯤은 이 책 제목 정도는 들어보았을 것이다. M-MM은 소프트웨어 엔지니어링의 고전이다.

Brooks는 IBM에서 OS/360 개발 프로젝트의 관리자였다. 나중에 Brooks는 이 경험을 분석하고, 그것에 관하여 여러 동료들과 논의했다. 그래서 그 결과로 나온 책이 바로 M-MM이다. 이 책은 각각 하나의 주제를 가지고 있는 에세이 모음의 형식으로 되어있다.

그 중에서도 가장 유명한 내용은 아무래도 Brooks' Law가 나오는 책과 동명의 에세이인 'The Mythical Man-Month'일 것이다. Brooks' Law는 간단히 말하면,

늦어진 소프트웨어 프로젝트에, 인력을 더 투입하면, 그 프로젝트는 더욱 늦어진다.

이 책이 워낙 오래 전에 쓰여진 책이라, 현재의 기술에는 약간 맞지 않는 얘기도 나오지만, 대부분은 여전히 유효한 얘기들이다. 뿐만 아니라, 요즘에 나오는 소프트웨어 개발에 관한 수많은 철학의 근간은 M-MM에 빚지고 있는 것으로 보인다.

내가 산 책은 1995년에 나온 Anniversary Edition으로, 그 시점에서 원래의 M-MM에 대한 스스로의 평가를 내리고 있다. 특히, 인상적이었던 것은 , 원래 Parnas가 주창한 Information Hiding을 격하게 비판하던 Brooks가, "Parnas Was Right, and I Was Wrong about Information Hiding"이라고 적으면서, 자신이 틀렸음을 솔직하게 인정하고 있다는 것이었다.

Anniversary Edition에는 역시 엄청나게 유명한 에세이인 "No Silver Bullet"을 함께 싣고 있는데, 이 에세이는 소프트웨어 개발자라면 반드시 읽어봐야할 에세이라고 생각한다. (인터넷에서도 쉽게 구할 수 있고, 번역도 되어있는 걸로 알고 있다.) 이 에세이는 소프트웨어 개발에 있어서의 어려움은 본질적인(essential) 어려움과 비본질적인(accidental) 어려움으로 나눌 수 있다고 얘기한다. 비본질적인 어려움은 기술의 발전과 함께 개선되고 점차 사라져왔지만, 본질적인 어려움에 있어서의 기술 발전은 10년 내의 범위에서 크게 이루어지지 않을 것이다라는 그의 예측은, 이 책이 쓰여진 1975년에도, Anniversary Edition이 쓰여진 1995년에도 맞았고, 지금도 맞지않을까 하는 생각이다. 그가 생각하는 본질적인 어려움의 궁극적인 해결책은 소프트웨어 컴포넌트의 시장화를 통한 재사용이다. 현대에는 어느 정도 컴포넌트의 시장화가 진행되었지만, 본질적인 어려움을 해결할만큼의 재사용에 있어서는 벽에 부딪히고 있는 것이 실정이다. 하지만, "Software Factory"같은 개념을 발전시켜 나가고 있고 그와 같은 개념은 바로 Brooks의 이상을 정확하게 표현한 것이 아닐까 싶다.

흔히, 고전을 "오래된 것", 그래서 낙후된 것으로 생각하는 사람들이 많다. 하지만, 고전의 참뜻은 "전범"이다. 그리스/로마 신화를 이해하지 못하고서, 서양의 미술을 이해하기 힘든 것처럼, 소프트웨어에 관해 이해하기 위해서 반드시 읽어야할 책들 중의 하나가 바로 M-MM이다.

달러 환율이 1000원선을 맴돌고 있는 가운데, 오랜만에 "아마존 놀이"를 했습니다.

싸이 홈피 리뉴얼

혹자는 철지난 싸이 홈피를 뭐하러 리뉴얼 하냐고 하지만, 아직도 나름대로 싸이는 인맥의 중심지인 것 같다. 랜덤 홈피 방문을 해보면서 실제로 사용자들이 싸이 홈피를 식상해하는 건 사실인 것 같긴 한데, 여러 동문 친구들이 싸이 홈피를 가지고 있다는 사실만으로도, 실용적인 가치는 있으니까. 최근의 사진들을 좀 올리고, 남아있는 도토리를 사용해서 스킨이랑 플레이룸 등을 다듬었다.

아바타: 사용자가 정말로 원하는 것인가?

싸이홈피든 세이홈피든, 미니룸/플레이룸(이하, 플레이룸)과 같은 것은 나같은 사람에겐 쓸데도 없고, 이중적인 관리 노력만 든다. 대체 왜 항상 다른 사람들에게 플레이룸이니 미니미니 등을 보여주어야 하는지 않은지 모르겠다. (이것이 내가 따로 블로그를 차린 중요한 이유 중 하나겠지만.) 떡하니, 빈 공간이 들어차있으면, 단장하지 않으면 안되는 부담감이란.

아바타 = 가짜 아이덴티티

이런 서비스의 사용자는 "자신을 드러내고", "관계를 맺는데" 관심이 있다. 관계를 맺기 위해서는 다른 사람이 누구인가를 홈피를 통해서 살펴본다. 그런 욕구를 가진 사용자는, 자신은 가능한한 매력적으로 보이도록 노력하고, 다른 사람은 그 매력이 진짜인지를 확인하려할 것이다. 일종의 게임이다. 당연하게도, 가짜 아이덴티티에는 한계가 있다. 시간이 지나면서, 사용자들은 학습을 하게된다 - 가짜 아이덴티티에 속아도 보고, 실망도 해봤을 것이다. 물론, "진짜 아이덴티티"란게 있다는 철학적인 주장을 하고 싶은 건 아니다. 이러한 서비스에서 아이덴티티의 요건은 적어도 "가짜"라고 느끼기 힘들어야한다는 것이다. 그러한 면에서, 아바타 - 홈피/플레이룸도 일종의 아바타다 - 는 거의 신뢰할 수 없는 아이덴티티로 전락하게 마련이다.

생각해보라, 맥주 광고에는 늘씬한 미녀가 나와서 당신의 성감을 자극하는 것으로 충분하다. 하지만 노트북이나 아파트 광고는 그렇지 않다. 소비자가 노트북이나 아파트를 구매할 수 있을 만큼 설득을 해야한다. (물론, 비이성적인 면과 결합시키려는 노력도 병행하는 경우도 많다.) 즉, 중요한 제품일 수록 소비자는 이성적으로 판단하는 경향이 있는 것이다. 인간 관계도 마찬가지라고 생각한다. 인간관계의 중요성에 따라, 즉 그 관계가 시간 때우기용이냐, 평생 지기냐에 따라, 사용자들의 자기 홍보 전략은 달라져야하는 것이다.

사용자들이 어떠한 자신의 홍보 전략을 최대한 표출할 수 있는가는, 당연히 서비스에 달려있다. 서비스를 오래 유지하고 성공하기 위한 원동력은 당연히 시간 때우기용 관계가 아니다. 인간 관계에 중요한 가치를 두는 사용자들에게 최대한의 편이를 제공해 주어야하는 것이다. 이러한 이유에서, "진짜 아이덴티티"라는 사용자의 욕구를 충족시켜주지 못하는 근본적인 한계를 지닌 아바타 서비스는 커뮤너티계의 천덕꾸러기가 되어가는 것 아닐까?

플레이룸(아바타)의 다른 효과들

물론, 플레이룸에도 어느 정도의 "아이덴티티"의 효과라든지 게임성의 효과와 같은 긍정적인 효과가 있는 것은 사실이다.

그 약간의 "아이덴티티"의 효과란 것은 바로, 누군가는 예쁜 플레이룸을 만들 수 있고, 다른 누군가는 그렇지 않기 때문이다. 하지만, 어째서 모든 사람이 플레이룸을 꾸미도록 강제되어야 하는가? 자신을 홍보하기 위해서 글을 사용하는 사람은 일기를 쓸 테고, 사진이나 그림을 사용하는 사람은 갤러리를 추가할텐데, 어째서 플레이룸만 mandatory냐 말이다. 어떤 기획자는 서비스의 충분한 노출을 위한 의도였다고 주장할 지도 모르겠다. 하지만, mandatory로 해서만 성공시킬 수 있는 서비스라면, 과감히 버리는 게 오히려 옳다고 생각한다. 사용자들이 원하지 않는 것을 강요하지 말라는 단순한 법칙이다.

게임성의 효과도 물론 어느 정도 인정할 수 있다. 일종의 펫처럼 꾸미는 과정 자체에서 재미를 찾는 사람들이 있을 수 있다. 하지만 마찬가지로, 모든 사람이 여기에서 재미를 느낄 것인가? 홈피의 1/4 정도의 공간을 차지할만한 가치가 있는가?

그리고, "플레이룸"이란 이름이 나타내듯이, 현실 세계로부터의 반영으로 볼 수 있다. 즉, 사람과 사람이 만나는(플레이) 어느 정도 사적인 공간(룸)인 것이다. 특히, 세이홈피의 그것에서는 이러한 면이 크게 강조되어있다. 하지만, 개인적으로는, 현실세계의 행위를 반영하기에, 인터페이스가 너무 조잡하고 불편해서, "현실세계의 반영"으로서의 역할을 충분히 하지 못한다고 생각한다. 분명히 여기에는 극복하기 힘든 기술적인 제약이 존재한다고 생각한다.

아바타를 강조하는 한국의 커뮤너티 서비스들

한국의 커뮤너티 서비스들은 한결 같이 아바타를 강조한다. 아바타가 없는 커뮤너티 서비스를 본 적이 없다. 위와 같은 생각을 가진 나는 왜 그러는 지 이해할 수 없다. 단기적인 이익을 노린 상술인가, 사용자의 욕구를 조정할 수 있다는 오만인가. 단순히, 그냥 따라했을 뿐인가? 서비스의 철학은 어디로 갔는가?

블로그 서비스가 성공할 수 있었던 것도, 아바타적인 요소를 제거하고, "진짜 아이덴티티"를 표출할 수 있는 자유를 제공했기 때문이 아닐까? 너무 결과론적인가? 글쎄, 적어도 나는 그렇게 생각하지 않는다. 나 자신은 분명히 그런 욕구를 지녔었기 때문이다.

한번도 아바타에 관한 기획이나 전략을 세워본 적도 없고, 적절한 이론적 베이스도 없는 나로서는, 분명 내 주장이 틀릴 가능성이 있다고 생각한다. 건설적인 코멘트 주시라.

MMORPG는 이미 우리나라에 보편화된 게임 문화다. MMORPG 마다 세계관이며 스토리도 다르고, 캐릭터 스타일도, 추구하는 게임성도 다르겠지만, 공통점 중의 하나는, 뭔가를 열심히 해야한다는 것이다. 일주일에 수십 시간씩 투자해서 레벨업을 하곤 한다.

Idle RPG는 IRC 기반의 RPG로, 아무 것도 하지 "않아야"하는 RPG다. Idle RPG의 서버는 특정 IRC 채널에 bot으로 접속하여, 그 채널안에 있는 사람이 어떤 동작 - 예컨대 말을 한다던가, 채널을 나간다든가 - 을 하는 가를 모니터링 하고, 얼마나 오랫동안 아무 것도 하지 않는지 (idle) 시간을 잰다. 그리고 그것이 일종의 경험치(XP)가 되어서, 일정 시간에 이르면 레벨업이 되는 것이다!

물론, 보편적인 RPG 처럼 성장을 위한 "전투"도 있다. 레벨 마다 한번씩 랜덤한 상대와 대결을 하게 되어, 이기면, 레벨업에 걸리는 시간을 줄이고, 반대로 지게 되면, 그 시간을 늘리는 것이다.

어린이날에 Idle RPG에 관한 얘기를 #perky와 kldp에서 듣고는, 재미있을 것 같아서, 서버를 설치해보았다. 현재의 플레이어 현황을 볼 수 있는 페이지도 있다. 현재, idlerpg bot은 HanIRC의 #idlerpg 채널에서 동작 중이고, idlerpg bot의 감시망을 피하는 안전가옥이 #idlerpgchat 채널이다.

그냥 룰만 본다면, "무슨 재미로 하냐"라고 할 것 같지만, 의외로 중독성이 있다. 3-40명 가까이 꾸준히 접속해있는 편이니까. 사람들은 "성장"이라는 요소 하나만 있어도 재미있어하는 것이다. 아무래도 며칠 지나면 지루한 사람들이 조금씩 떠나지 않을까 하지만...

나름대로 Idle RPG를 수정해서, 여러가지 게임성을 추가한 사례도 있다. uric에서는 몬스터가 있어서, 플레이어와 근접하게 되면, 플레이어가 몬스터를 공격하도록 지시할 수 있다. (사실 이 정도 되면, Idle RPG라고 하기엔 어렵지 않을까?) 클래스와 스킬 개념도 넣었다. 당장은 bot의 한글화 정도만 신경쓰고 있지만 (그나마 별로 안하고 있지만), 사람이 꾸준이 모인다면, 이런 것들에 손을 대볼지도 모르는 일.

아 참, 그리고, 토끼군님이 웹페이지의 인터페이스 개선과 한글화 작업을 진행중이시다.