아마존 놀이
달러 환율이 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의 한글화 정도만 신경쓰고 있지만 (그나마 별로 안하고 있지만), 사람이 꾸준이 모인다면, 이런 것들에 손을 대볼지도 모르는 일.
아 참, 그리고, 토끼군님이 웹페이지의 인터페이스 개선과 한글화 작업을 진행중이시다.
어떤 practice가 보편화되어있고 그것을 보조하는 툴이나 생각의 장치들이 잘 만들어져있다면, 오히려 그 practice의 장점이 무엇인지 파악하는 데에는 방해가 되기도 한다. 어떻게 보면, 생산성을 높히고자 하는 우리의 노력이 때로는, 각 개인의 능력을 키우는 데에는 방해가 될 수도 있는 것이다.
예를 들어, 잘 만들어진 소프트웨어 프로세스 환경에만 익숙한 개발자는, 그러한 프로세스가필요없다고 주장하는 사람에게, 그것이 왜 필요한지 제대로 설명하지 못할 것이다.현대의 특정 프로그래밍 언어에만 익숙한 사람은, 자신이 활용하고 있는 수많은 언어적 장치들의 이점을 제대로 이해하고 있지 못할 가능성이 높다.
마찬가지로, 잘 만들어진 Model-View-Controller(이하 MVC) 프레임워크에만 익숙한 사람이라면, 그 패턴이 가지고 있는 유용성이나 의미를 발견하지 못할 가능성이 높다. 대부분의 웹어플리케이션 개발자들은, 프리젠테이션과 로직이 뒤섞인 기존의 웹어플리케이션에만 익숙하거나, MVC 프레임워크 웹어플리케이션에만 익숙하다. 기존의 웹어플리케이션이 MVC를 사용함으로써 어떤 점에서 좋아질 수 있는지는 전자나 후자의 프로그래머들 모두 알지못할 가능성이 높다.
이 글의 목적은 기존의 웹어플리케이션에 MVC 패턴을 적용하면서 리팩토링하는 과정을 보임으로써, MVC 패턴의 유용성을 재발견하는데 있다.
…
Galaxy(http://rubyforge.org/projects/galaxy/)의 public release를 위해서, lastmind-specific한 design에서 좀 더 generic한 design으로 손봤습니다. (네, 네, Word Press 스타일입니다. 그렇게 안보이는 분들도 계시겠지만…) 색상이나 형태 등은 가능한 한 CSS로 분리했습니다. (완벽하지는 않습니다.) 게다가 아직도 view/filter 변경 인터페이스나, admin 인터페이스 쪽은 멀었습니다.
제가 혼자 사용하기에는 별로 문제없었는데, product로 release 하려니, 상당히 손이 많이 가는군요. Brooks의 Programming Product에 관한 이야기를 실감합니다.
boost-devel 메일링 리스트에서 최근에 제 관심을 끄는 이슈들입니다.
http://article.gmane.org/gmane.comp.lib.boost.devel/121123/match=proposed+boost+tr1
John Maddock이 작업 중이던, TR1의 (거의) 완전한 첫번째 구현이 나왔습니다. 언제쯤 boost에서 그리고, g++에서 볼 수 있을까요? 기대됩니다.
http://lists.boost.org/boost/2005/04/24164.php
Boost.Net library에 관한 논의는 아주 오래전부터 있어왔지만, 구현을 하시던 분이 실종되기도 하고 (?), 우여곡절 끝에 최근에 다시 논의가 뜨거워지고 있습니다. C++에 아직 보편적으로 쓸만한 network library가 없다는 것은 C++ 개발자로서는 괴로운 일일 수 밖에 없죠. 간단한 작업을 위해서도 reinvent wheel을 해야하니까요. 최근에 개발된 언어들은 대부분 기본적인 socket으로부터, http와 같은 상위 layer protocol 까지 모두 지원하고 있는데 말입니다. 어서 C++ 개발자들도 자유롭게 개발할 수 있었으면 합니다. 전에도 적었듯이 reactor + fsm 을 구현해보고 싶은 생각이 있는데, boost에서도 multiplexor에 대한 논의는 계속 진행중입니다. (fsm은 이미 있긴 한데, 상당히 generic한 디자인이다보니 좀 복잡해서, multiplexor와 함께 잘 쓰일 수 있는지는 의문입니다.)
예전부터 다음 위키 페이지에 잘 정리되고 있으니 관심있는 분은 참고하시길.
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet
더불어 Async I/O를 어떻게 제공해야하는가, platform neutral해야하는가, thread와 독립적이어야 하는가 등의 이슈에 대한 논의도 활발하게 진행중입니다.
http://lists.boost.org/boost/2005/04/24098.php
http://lists.boost.org/boost/2005/04/24559.php
Boost에는 원래부터 automated regression testing을 하고 있었습니다만, 아마 개발자가 build를 하고 그 결과를 자동적으로 집계하는 식이었을 겁니다. 최근에 BuildBot(http://buildbot.sourceforge.net/)을 Boost의 regression testing에 도입하기로 결정된 것 같습니다. BuildBot은 분산 환경에서 주기적으로 build를 해주는 소프트웨어로 보입니다.
제가 회사에 있을 때, 팀에서 개발 중인 라이브러리의 regression testing을 담당하고 있었고, Boost를 모델로 했지만, 그 당시에도 차후에는 BuildBot과 같은 것이 필요하다는 생각을 했었습니다. 그 때는 BuildBot과 같은 기능은 차후로 미루고 단순히 cron을 사용했는데요. 굳이 새로이 개발하기보다는 BuildBot을 가져다 쓰는 것도 괜찮을 것 같군요. 주기적으로 build를 trigger하는 것뿐만 아니라, 분산 환경에서 on-demand build도 가능한지가 궁금하군요.
참, Regression Testing에 대해서 알고 싶으신 분은 Regression Testing에 대한 Wikipedia 항목을 참고하시기 바랍니다. (혹, 나중에 블로깅할 일이 생길지도 모르겠네요.) Automated regression testing의 이익에 대해서 알고 싶으신 분들은 Joel Spolsky의 Daily Builds Are Your Friend를 읽어보시기 바랍니다. Daily Build는 Joel의 유명한 The Joel Test에도 들어있는 항목이지요.
TR2와 C++0x의 스케줄이 잡혔다는군요. boost의 threads, filesystem, signals가 제안될 계획이라는 군요. (물론 TR2로 겠죠.) thread를 사용하기 위해서 boost 전체를 설치해야한다는 게 부담스러워서, 따로 thread library를 만들기도 했었는데요. 표준화가 된다면 얘기가 달라질 것 같군요. boost의 위상이 점점 높아만 가는군요. production에서 boost를 쓰는 것도 별 무리가 없지 않을까요?
* October 2005: cutoff date for C++0x major library proposals
* October 2006: cutoff date for library TR2 proposals
* April 2007: cutoff date for C++0x library clean-up papers
The usual rule-of-thumb is that new library components go in TR2, while
changes to existing components go in C++0x. The LWG will consider
exceptions to the rule on a case-by-case basis.
The LWG is planning to issue a “Call for Proposals” with details, but in
the meantime Boost developers might want to start thinking about which
Boost libraries they want to propose to the LWG. Because most proposals go
through one or more revisions before being accepted, it helps a proposal’s
chances if it reaches the committee as many meetings as possible before the
final cut-off.
So far there are plans to propose Boost.Threads, Boost.Filesystem, and
Boost.Signals. As well as proposals for some of the more major libraries, I
personally hope someone will do a sweep through Boost looking at some of
the smaller utilities and helpers for a possible “Small Additions”
proposal.
–Beman
h3. What is websvn?
p. websvn(http://websvn.tigris.org/)은 cvsweb이나 viewcvs와 같은 svn의 web frontend다.
…
조금 있으면 개봉할 Star Wars Episode III: Revenge of the Sith의 TV 광고가 4월 18일자로 추가로 공개되었다.
http://www.starwars.com/episode-iii/release/trailer/
다음은 TV 광고들의 동영상 링크 모음.
99만 9천원 짜리 노트북을 내놓아서 히트를 치더니, 이번엔 역시 싸면서도(149만 9천원) 깔끔한 디자인을 가진 서브 노트북을 내놓았다. 갖고 싶긴 하지만, 역시 필요가 크지 않기 때문에, 사게 되지는 않을 듯하다. (학교에서 프로젝트도 해야하고, 수업이 빈 시간에 빈둥거리기도 해야하기 때문에, 필요가 아주 없는 것은 아니다.)