온라인 게임에서 동기를 얻어 게임에서 사용하는 것과 비슷한 도끼로 동생을 살해한 사건이 벌어졌다. 범행 후 죄책감도 느끼지 못했다는 그를 보고 사이버 세계와 현실 세계의 벽이 무너지고 있다는 것을 새삼 느끼게 됐다.
게다가 이정도 일로 놀라면 곤란하다. 이미 소설 속에 예견되어 묘사된 일들이고 유수의 기업들은 사이버 세계와 현실 세계의 벽을 더더욱 낮추고 부수기 위해 가장 잘 훈련되고 상상력이 탁월한 인재들에게 해머와 드릴을 안겨주고 있으니 우리에게 일어나는 사건들이 사이버 세계에서 일어난 일인지 현실 세계에서 일어난 일인지 조차 헷갈릴 날이 머지않은 듯 하다.
그 학생이 죽인 것은 동생이 아니다. 그는 게임의 게임을 클리어하고 레벨을 올리기 위해 죽여야만 하는 상대 플레이어를 죽인 것 뿐이다. 그가 죄책감을 느끼지 못하는 것도 당연하다.
그가 속한 사이버 세계 안의 게임의 법칙이고 그는 그 룰에 따라 플레이했을 뿐이다. 그에게 잘못이 있다면 현실 세계로 돌아오지 못했다는 점이다. 그를 단죄하기 위해서는 일단 현실세계로 돌려 놔야 한다.
사이버 세계의 그를 살해하거나 더 이상의 이벤트가 없어 게임이 종료됐음을 알려야 할 것이다. 필자가 온라인 게임의 제작자라면 그 헌장에 다음과 같은 문구를 추가하겠다.
우리 세계와 현실 세계를 움직이는 법칙은 다르며 그를 구분 못 할때는 다시는 어느 한쪽으로부터 갇히게 될 수 있으니 주의하라
삶이란 감정의 물결
게임 제작자들은 온라인 게임을 좀더 현실화시키기 위한 방법을 부단히 찾고 있다. 현실화시킨다는 것은 실제 아픔을 느끼고 거래를 하고, 소비욕구를 충족하고, 집단 생활에서의 기쁨을 얻는 감정을 온라인 게임에서도 얻을 수 있게 되는 것이다.
단발성인 이벤트가 있지만, 참여할 수 있는 인원의 제한과 그 유지 기간이 짧고 끊임없이 아이디어를 내야 하는 한계에 봉착하게 된다.
이를 해결하는 방법은 이미 우리가 감정의 기복을 만드는 현실 세계의 체계(시스템)를 가상 세계에 이식해 현실 세계에서 얻는 감정을 사이버 세계에서도 느끼게 만드는 것으로 요약될 수 있다. 그건 현재까지 자본주의라는 체계로 불리우고 있다.
상상력이라는 열매
대기업 기획실 부장에서 자리를 옮겨 중견 벤처 기업의 기획이사를 맡고 있는 P부장이 필자에게 이런 질문을 했다. GNP가 2만달러이고 성장률이 3∼4%인 나라와 GNP가 8천달러이고 성장률이 8∼9%인 나라 어느 곳이 더 재미 있을 것이냐고. 여러분은 뭐라고 대답하겠는가.
필자는 우리나라가 좋다. 우리나라는 참으로 자유로운 나라다. 멸치잡이의 자식으로 자라도 대통령이 될 수 있고 정치적이나 종교적으로 억압도 전세계 인구 비례로 보면 매우 적은 편이다. 자유에 따르는 부작용을 막아줄 치안도 나름대로 훌륭한 편이다.
흔히 일본은 우리나라 보다 더 재미있는 나라라고 한다. 그 이유는 무엇이라 생각하는가. 역시 사람마다 각자 의견이 다르겠지만 결국 자유(특히 미디어의)라는 걸로 추상화할 수 있을 것이다.
자유는 구성원들이 집단 규칙 안에서 새로운 시스템을 새로 만들어 내는 재미있는 습성을 가지고 있다. 모든 걸 규정해 주지 않아도 스스로 새로운 규칙을 규정해 간다. 그래서 씨앗만 뿌려도 이 멋진 세상을 만들어준 상상력이라는 열매를 딸 수 있게 해준다. 그게 자유라는 것이다. 이 자유에 화폐를 결합해 보자. 빙고! 그렇다. 자본주의다.
리니지
자본주의 모델을 가장 온라인에 성공적으로 이식한 온라인 게임이 바로 리니지다. 리니지는 당시 출시된 어떤 게임보다 그 자유를 보장했다. 게임 이벤트에 순서 독립적인 진행의 자유도가 아닌 힘과 권력(혈맹)으로 돈을 벌어들일 수 있는 자유를 누릴 수 있는 것이다. 레벨만 높다면 심지어 리니지를 관리하는 게임 마스터들까지도 죽일 수 있다.
그들이 가진 멋진 아이템 때문에 이런 'PK'가 간혹 일어나지만, 물론 다음날 검색돼 모든 아이템을 압수당하고 추방된다. 또한 동굴 앞에는 반드시 레벨이 높은 플레이어들이 지키고 있어 지날 때마다 통행세를 걷을 정도이다.
엔씨소프트의 리니지
약한자는 혼자서 함부로 돌아다니기 힘들고, 따라서 무리를 만들어 혈맹을 만들게 되고, 비록 온라인이지만 목숨을 걸만큼 끈끈하게 뭉친다. 수십 명씩 떼를 지은 혈맹끼리의 전투는 힘에 대한 무한한 욕망을 갖게 한다. 플레이어의 힘은 그 아이템의 성능과 직결된다.
이런 리니지에서 좋은 아이템에 대한 욕구는 대단해 실제 현금으로의 매매는 공공연한 사실이다. 리니지 유니크 아이템에 고유번호가 붙어 있어 복제 판매나 훔쳐 파는 판매가 불가능하다. 그런일이 벌어지더라도 얼마 안돼 검색돼 처벌을 받기 때문이다. 따라서 아이템을 얻는 방법은 구걸을 하거나 구입하는 방법밖에는 없다.
리니지 내의 화폐는 실제 화폐와 실 교환가치를 가진다. 리니지 화폐인 아덴과 원의 환율은 2대 1정도. 한때 리니지내에 레벨 51이 나와 화제가 된 적이 있었는데, 그는 5000만원 가량 투자했다는 인터뷰가 있었고 레벨당 100만원이 들어간다는 소문을 어느 정도 확인할 수 있는 기회였다.
깡패게임이니 소니의 에버퀘스트나 울티마 온라인 등의 게임에 비하면 드라마나 구성이 부족하다고 폄하하는 사람도 있지만 분명한 것은 여태껏 나타났던 그 어떤 게임도 현실 세계와 사이버 세계의 상거래를 이만큼 낮추지는 못했다.
한게임
라디오를 듣다보면 30∼40대 주부들의 남편에 대한 불만으로 자주 들리는 것의 하나가 남편의 컴퓨터 중독이다. 무슨 소리인가 들어보면 집에 오자마자 인터넷 게임, 주로 고스톱이나 포커 등의 게임을 잘 때까지 붙들고 있느라 가족에 소홀하다는 이야기다. 전자메일을 사용하기 위해 인터넷을 한다는 구세대 인터넷족들이 이제는 온라인 도박을 즐기기 위해 옮겨가는 것이 아닌가 하는 느낌이다.
사회주의자들도 자본주의의 부작용이라며 금지시킨 것이 도박이다. 순수히 현금흐름만 내게로 옮겨 오겠다는 이 제로섬 법칙을 가장 제대로 파악한 것은 바로 한게임(www.hangame.com)이다.
가지고 있는 자금 여력에 따라 들어갈 수 있는 방이 다르다. 판돈이 비교적 적은 고스톱 등으로 자금을 모아야 포커판에 낄 수 있다. 포커는 특성상 밑자금이 더 큰 쪽이 유리하다. 자금이 부족해서는 레이스에 따라 갈 수 없기 때문이다.
그러나 이렇게 사이버 머니를 차곡차곡 모아서는 자금을 모으기 힘들기 때문에 실 화폐로 사이버 머니를 사게 되고 실제 수억에서 수조의 사이버 머니를 상황에 따라 몇 만원에서 몇 십만원에 실제 거래되고 있는 상황이다.
네이버의 한게임
노벨상
두 게임의 예에서 사이버 세계와 현실세계 간의 현금 흐름이 작지만 인위적이 아닌 본능적으로 시작됐으며 현금 흐름을 유리하게 만드는 것일수록, 다시 말해 사이버상의 화폐와 실화폐 가치와의 경계가 낮을수록 사람들을 끌어 들인다.
동독을 흡수해버린 것은 서독의 돈이었다. 이 경계를 무너 뜨린다면 전산학자들도 노벨상을 노려 볼 수 있다. 노벨 경제학상말이다. 이 정도 인정받을 수 있다면 일생을 걸어볼만 하지 않은가.
그렇다. 여러분의 노벨상을 위해 필자는 키보드에 손을 얹었다. 두 자본주의 간의 경계를 줄이는 일에 조금이나마 일조하기 위해서 말이다. 두 체제간의 경계를 줄이는데 있어 선결해야 할 문제들이 있으므로 그들을 집어보고 대안을 만들어 보도록 하겠다.
사이버 머니를 지켜라
현실 세계의 화폐도 위조가 가능하다. 마찬가지로 사이버상의 화폐 역시 조작이 가능하다. 아직은 사이버 머니가 실화폐로 교환되는 실례가 드물기 때문에 문제가 되지 않지만, 앞에서 말했듯 사이버 머니와 실화폐간의 경계가 낮아지면 굉장한 이슈가 될것이다. 일단 현재 서비스하고 있는 업체를 마루타 삼아 우리의 고민을 투영해 보자.
온라인 게임 사이트 설계
회원이 1000만명이 넘었다는 온라인 게임 업체도 있다. 이 경우 동시 접속자를 1%로 계산한다면 10만명 정도가 되는데 이는 엄청난 수이다. 여러분이라면 이런 사이트를 만든다면 어떤 아키텍처를 택할지 한 번 생각해 보라.
클라이언트/서버 구조라면 엄청난 서버 비용이 소요될 것이다. 필자가 사이징을 한다면 썬의 엔터프라이즈급 정도 서버라면 한 개당 300개의 TCP 커넥션을 원활히 처리할 수 있을 것 같고, 그러면 약 333개의 서버가 필요하게 될 것이다(<그림 1>). 이렇게 된다면 아마도 백억 단위의 가격이 나오지 않을까 싶다.
<그림 1> 전체 클라이언트/서버 기반
아무리 돈을 많이 물려받은 재벌 2세거나 수백 억원의 펀딩을 받은 회사의 CEO라고 해도 백억원 단위의 가격이라면 쉽게 구매 계약서에 사인하기 어려울 것이다.
이럴 때는 클라이언트끼리 짝을 지을 수 있는 만남의 장소로서의 로비만 제공해주고 나머지는 방에 들어간 사용자들이 알아서 하도록 하는 방식을 이용해야 할 것이다. 이 대표적인 예가 스타크래프트의 배틀넷이다(<그림 2>).
<그림 2> 피어 투 피어 기반의 클라이언트/서버
배틀넷은 로비만 제공해 주고 방을 만들고 나면 그 방 개설자가 서버가 되고 그 이후에 들어온 클라이언트들이 그곳에 접속하게 된다. 그리고 게임의 승패 여부만 게임 종료 후 메인 서버에 하면 돼 서버의 부하를 줄이고 있다.
게임을 하는 시간이 대부분이므로 로비에 접속하는 수는 훨씬 줄어들게 되고 1%만 잡아도 3∼4개의 서버만 있어도 된다는 계산이 된다. 피크 타임에 견디기 위해 몇 대를 더 증설한다고 해도 훨씬 저렴하게 구현할 수 있다.
이 구조라면 게임별로 로비를 만들고 게임을 할 수 있는 단위로 그룹을 묶어 주고 서로 게임을 할 수 있도록 만든다. 따라서 제일 먼저 방을 만든 사람이 서버가 되고 카드를 섞고 각 클라이언트에 카드를 나눠주게 된다.
이때 클라이언트는 서버로부터 받은 자기 카드만 볼 수 있지만, 서버인 플레이어는 카드를 나눠줄 때 남의 카드까지 알아 낼 수 있다. 나눠 줄 때 소켓 함수를 후킹해 그 패의 패킷을 알아 낼 수 있는 것이다.
암호화를 한다고 해도 암호화 함수가 고정이라면 모든 플레이어를 자신이 한 후에 패킷과 실제 패를 비교하면 그 패턴을 읽어 낼 수 있다. 이것을 수행하기 위해 본지 1999년 11월에 소개한 오스틴파워에게 호출하자. 1999년 12월호 <리스트 3>의 InitInterceptStub()의 szModuleName을 'WSOCK32.dll'로 바꾸고 szFuncName에 'send'를 넣자.
// 후킹할 함수들을 위한 스텁을 만든다.
BOOL InitInterceptStub()
{
char szModuleName[] = WSOCK32.dll,
szFuncName[] = Send;
PVOID pRealAddress;
HMODULE hModule;
...
그리고 HookProc은 <리스트 1>과 같이 정의해 통신 내용을 감청할 수 있도록 하자. 내용은 HookLog.txt에 쌓이게 될 것이다. 간단히 최소한의 살만 붙인 것이므로 후에 여러 가지로 필터루틴 등을 넣어 꼭 필요한 정보만 쌓이도록 개조하기 바란다. 이제 컴파일하고 DLL 파일을 만들자.
<리스트 1> HookProc 정의하기
void HookProc( PDWORD pParam)
{
int nLen;
char *szSockBuf;
HFILE hFile;
pParam++; // 소켓 핸들
szSockBuf = (LPSTR)*(pParam++); // 통신 버퍼
nLen = (int)*(pParam++); // 버퍼 길이
hFile = _lopen( HookLog.txt, OF_READWRITE);
if( hFile == HFILE_ERROR )
hFile = _lcreat( HookLog.txt, 0);
_llseek( hFile, 0, FILE_END);
hFile = _lwrite( hFile, szSockBuf, nLen);
_lclose( hFile);
}
통신 내용을 가로채기 위한 오스틴파워를 커스트마이징했다. 이제 잠입시키는 것이 문제다. 온라인 게임은 웹상에서 액티브X를 이용해 바로 실행 파일을 실행시킨다. 따라서 미리 프로그램을 띄어놓아 봤자 실행되지 않고 해당 웹사이트가 뜨게 된다.
참여한 방의 종류와 룸 번호 등을 담은 문자열을 파라미터로 실행시킨다. 따라서 이 파라미터를 그대로 전달하면서 실행시키게 해보자. 원래 게임 실행 파일이 DuGame.exe라고 하자. 이 파일을 SeGame.exe로 바꾼다. 그리고 다음 소스를 컴파일하고 DuGame.exe로 바꾼다.
#include
#include Spy.h
void main(int argc, char *argv[])
{
int i;
char szCommand[256] = {0,};
AustinPower ap;
sprintf( szCommand, SeGame.exe );
for( i = 1; i < argc; i++)
{
strcat(szCommand, argv[i]);
strcat(szCommand, );
}
ap.CreateAustinPower( szCommand );
}
이렇게 하면 실행과 동시에 함수 후킹 엔진을 넣을 수 있다. 그리고 새벽 5∼6시 사이에 일어나 게임방에 가보자. 그리고 3군데를 빌려서 모두 한방에 넣고 패와 HookLog.txt 패킷을 비교해 보자.
앗! 후킹이 안된다고요. 지난 2000년 12월호의 소스는 윈도우 NT와 윈도우 2000용인데 게임방에는 분명 윈도우 9x 시리즈가 깔려 있을 것이다. 지난 2000년 5월의 AS 연재에 윈도우 9x에서 동작케 하는 소스가 실려있으므로 참조하기 바란다.
이런 경우 서버에게 각각 간단한 암호키를 받아 Diffie-Hellman을 간단히 구현해 둘간에 암호키를 만든다면 패가 같더라도 암호문이 변화는 암호키에 따라 달라져 패턴을 읽기 어렵게 된다.
초대용량 온라인 게임 솔루션
다음 단계의 온라인 RPG는 맵에 변화를 줄 수 있어야 할 것이다. 집도 짓고 성도 쌓고 말이다. 맵이 변화한다는 것은 기술적인 의미이고 실제 의도하는 것은 토지에 대한 재산권이다. 토지, 즉 영토라는 것은 노동력과 생산을 의미하며 이는 곳 권력으로 귀결된다. 몬스터가 많이 나오는 지역을 울타리를 둘러 쌓은 다음, 돈을 받고 견습생들에게 레벨을 올리도록 하게 할 수도 있고 멋진 별장을 지어 거래를 할 수도 있을 것이고, 성으로 영토를 구분한다면 나라가 자연스레 생길 것이다.
자연스레 영토를 얻기 위한 전쟁이 가능하다. 빼앗을 영토의 배분을 약속으로 용병을 모집할 수 있고 이웃 나라와 동맹을 맺는 일도 가능해 진다. 리니지 성공의 큰 요소인 국가 단위로 혈맹을 맺을 수 있는 것이다.
기술적 구현
그러나 기술적 구현은 너무나 어렵다. 어디 한 군데서 집을 짓거나 성을 쌓는다면, 그 변화 내용은 모든 클라이언트에 변화돼야 한다. 접속돼 있는 모든 사람들에게 이 정보를 전송한다는 것은 엄청난 처리 용량과 네트워크 대역폭을 요구한다.
그러므로 현재의 동일 내용에 동시 접속자 수를 늘리기 위한 대용량의 클러스터링 방법으로 이 부하를 견딘다는 것은 무한의 용량이 가능해도 그 트랜잭션 처리와 동기화는 거의 불가능해 진다.
단지 각 지역을 담당하는 서버가 각각 존재해야 할 것이다. 그러면 각 지역별 서버에 접속하는 클라이언트는 훨씬 줄어들게 될 것이다. 비유를 하자면 우리나라를 배경으로 벌어지는 온라인 RPG가 있는데 광주에 있는 플레이어나 부산에 있는 플레이어 모두 한 서버에서 정보를 얻었다.
그런데 부산에 큰 건물이 들어섰는데 그 내용을 광주나 대전에 있는 플레이어에게까지 굳이 전송할 필요가 없다. 그들이 부산에 왔을 때 알려주면 되는 것이다. 그 건물의 변화는 부산에 있는 플레이어들에게만 전송하면 된다.
그리고 이런 구조라면 보유 아이템이나 금액 등도 이 서버들이 담당하게 되면 중앙 서버의 부하는 크게 줄어들게 된다. 여기서 플레이어가 이동해 다른 서버가 관할하는 지역으로 가게 되면 아이템과 상태를 넘겨주고 그 정보를 받은 서버는 그 플레이어에게 바뀐 맵 정보를 줘야 할 것이다. 상태 로밍(Status Roaming) 정도로 부르면 훌륭할 듯 싶다.
상태 로밍
로밍 방법도 메인 서버에 변화 내용을 반영한 뒤에 가져가는 집중식 방법과 지역별 서버에게 넘긴 후에 플레이어가 종료할 때 그 내용을 메인 서버에 반영하는 분산식 방법이 있다.
집중식 방법은 로밍에 있어 이동한 서버에서 다시 가져오는 방식이므로 코딩이 비교적 쉽고 명쾌하지만, 메인 서버에 부하가 많이 걸리게 된다. 분산식의 경우 메인 서버로의 접속은 플레이어가 처음 접속할 때와 종료할 때 두 번뿐으로 메인 서버의 부하는 낮다.
그러나 지역 서버간에 플레이어 정보를 주고 받아야 하므로 로밍 구현자체가 좀 복잡하며 지역 서버의 장애시 데이터 손실이 올 가능성이 있다.
<그림 3> 집중식 상태 로밍
<그림 4> 분산식 상태 로밍
그러나 TCP 커넥션 100개 정도를 원활히 처리할 수 있는 PC 서버가 있다고 하자. 현 온라인 RPG 경우 각 클라이언트의 변화 내용을 모든 클라이언트에게는 푸시(Push)할 필요는 없다. 그러나 맵이 변화하는 모델이라면 맵의 변화 내용을 서버에 연결된 모든 클라이언트에게 푸시해야함에 따라 그 네트워크 부하는 배로 늘어나게 될 것이다.
그렇게 되면 리얼타임 맵 관리가 훨씬 중요해 질 것이다. 이 리얼타임 맵관리 DBMS의 중요성이 크게 부각될 것이고 복잡한 RDB의 경우 리얼타임 DB로 사용할 수 없다. 따라서 맵과 같이 업데이트 트랜잭션 처리에 강한 리얼타임 DB가 이 기술의 선결 과제다.
이 정도의 부하를 처리하기 위해서는 SCSI 하드 디스크가 아닌 램을 이용한 어레이(Array) 장비나 NAS(Network Attached System) 시스템이 필요하게 될 것이다.
이런 시스템 구성이라면 기존 시스템보다 엄청난 구축 비용이 들 것이다. 그렇지 않아도 감가상각이 큰 서버에 많은 투자가 돼야 할 것이고 백본도 엄청난 대역을 확보해야 할 것이다.
피어 투 피어 기반 C/S 구조
해결책이 없는 것이 아니다. 피어 투 피어를 기반으로 한 서버드 클라이언트(Servered-Client) 방식이 그것이다. 한 지역에 제일 처음 들어오게 되면 서버는 그에게 지도 정보를 준다. 그리고 그 이후에 그 지역에 접속하는 클라이언트에게 온라인 게임 RPG의 DNS 서버는 그 클라이언트에 접속시킨다.
스타크래프트 배틀넷에서 이미 실험된 사항으로 6∼8개 정도 접속시킨다. 전쟁이나 혈맹 전쟁이라도 벌어지게 되는 상황에서는 서비스 업체 자체 내에 100여명이 동시 입장 가능한 서버를 몇 개 둬 로밍하게 한다. 서버인 클라이언트가 접속이 끊긴다든지 하는 장애가 발생했을 때 자체 내에 다시 로밍되게 해야 한다.
<그림 5> 피어 투 피어 기반 클라이언트/서버 구조
이렇게 되면 아이템이나 돈의 보안이 문제가 된다. 클라이언트 서버를 이렇게 두면 아이템을 조작할 수 있기 때문이다. 또 아이템을 갖고 있었는데, 메인 서버에 반영하기 전에 통신회선이 끊겼을 경우 문제가 될 것이다.
이를 막기 위해 돈과 아이템 정보의 경우는 각 클라이언트가 똑같이 갖고 있도록 해 한 클라이언트가 끊겼을 때는 다른 클라이언트 정보를 취합해 가장 최근의 시간 도장이 찍혀 있는 정보를 서버에 반영시킨다. 그리고 아이템은 그때 그때 서버로부터 받은 인증키로 암호화해 그 조작을 막는다.
이 프로토콜은 피어 투 피어를 서버로 사용하기 위한 필수 프로토콜이 될 것이며 사용하기에 따라 CDMA에 버금가는 파워를 발휘할 것 같다. 욕심은 나지만 시간을 더 짜내기 힘든 필자로서는 여기까지이고 미천한 필자의 아이디어에 살을 붙이기 바란다.
바로 전 컬럼이 2000년 9월호 기사였으니 7개월만이다. 그나마 지난해의 기사를 마무리 안하냐고 항의하는 독자들도 있었으나 올해 들어 뚝 끊긴 걸 보면 요즘은 다들 잊어버린 듯하다. IT 쪽이 다 그렇지만 짬을 내기가 너무 힘들기 때문에 일년에 두 번 쓰는 것도 참 힘든 일이다. 2월호 특집기사는 필자의 설 연휴와 맞바꾼 결과다.
그러나 미인도 가끔봐야 이쁜 법이고 나쁜 짓도 가끔해야 기쁨이 더 크지 않던가. 이번호는 독자들에 대한 그리움으로 게임이라는 부담없이 받아들일 수 있는 주제를 다뤘다. 게임을 후킹하고 패킷의 규칙만 찾아내면, 상대편의 패를 알아내는 것은 그리 어렵지 않을 것이다. 프로그램을 완성하면 필자에게도 소개시켜 주기 바란다.
사실 그 사이에 필자는 엄청난 놈을 만들고 말았는데, 네트워크로 대상 컴퓨터에 루트 권한을 주는 백오리피스 기능에 전파력 높은 CIH 감염 엔진을 얹는데 성공했다. 감염시키는 것이 불편한 백오리피스와 네트워크를 이용하지 못하는 CIH의 단점을 보완했다고나 할까.
그런데 여러 상황에서 일반적으로 동작하게 하는 것에 대한 기술적인 어려움으로 이번호에 다루지 못했다. 사실 백신을 피하는 방법도 양념으로 준비중인데 그 결과는 백신 기술의 발전으로 이어질 것이다. 아마 다음 기사는 이 녀석을 다루게 될 것같다. 기대해도 좋을 것이다.
옛 바이러스 제작자들의 고해성사 비슷한 이야기와 멤버 구속으로 해체된 유명 바이러스 그룹에서 활동하던 사람들의 스토리도 재미있었다. 필자의 활력소를 불어 넣어주는 이런 독자들의 작으면서 큰 이야기들에 늘 감사하다. @
