Dead programmers society

헉.. NATAL

사자바이 — Tue, 02 Jun 2009 03:10:10 GMT

우물 밖 세상은 진정 진화하고 있군요.

상상했던 일들이 하나 둘 실제로 나타나고 있는 상황에서 ,

한 편의 불안감, 한 편의 개발자 호기심이 찾아드네요. ^^

노무현 전 대통령 서거

사자바이 — Sun, 24 May 2009 19:05:11 GMT

기술적인 내용 외에는 특별히 이 쪽에 글을 올리지 않으려고 했습니다만,

2009년 5월 23일 새벽, 슬픈 소식 앞에

답답하고 무거운 마음에 이렇게 글로나마 그 아쉬움을 감추려 합니다.

놀라운 소식을 뒤로 한채 , 인터넷에 올라오는 많은 글들

그리고 그 사실들, 영상들, 역사들 ..

대한민국의 한 국민으로써 왜 그렇게 무심한 삶을 살아왔는지,

반성하고 또 반성하였습니다.

노무현 대통령님께서 말씀하신 것 처럼

삶과 죽음이 모두 자연의 한 조각이라면 ,

오늘날의 우리내의 삶 또한 희망과 좌절이 공존하는 것 아니겠습니까.

당신이라는 희망이 있었기 때문에,

현실의 좌절이 공존하여 하나를 이룬다고 여기겠습니다.

그리고 그것으로 통해 더 나은 삶을 살 수 있도록 하겠습니다.

삼가 고인의 명복을 빕니다.

부디, 다른 세상에서 편안하시길 바랍니다.

일에 대한 신념

사자바이 — Thu, 26 Mar 2009 19:57:57 GMT

자신의 일이 자랑스러울까 어떨까

남의 잣대로 재봤자 소용없다.

그것은 자기 자신이 결정하는 것이다.

- 일본 드라마 [워킹맨] 中

내 일이 과연 세상에 필요한 아름다운 것일까.
그 것이 그만큼 가치를 지닌 것일까.

내 삶을 바쳐서 할 만큼 값어치를 하는 것일까.

한 가지 중요한 사실은 ,

적어도 난, 언제나 그렇게 생각하고 믿어 왔다는 것...

사람간의 믿음

사자바이 — Mon, 17 Nov 2008 14:55:54 GMT

사람간의 믿음이라는거,

사실 그거 별 거 아닙니다.

그저 내가 그 사람을 믿는 만큼,

그 사람도 나를 믿어준다는 사실.

이 것 하나만 기억하면 되지 않을까요 ?

세상, 내 마음처럼 되지 않는 것이 너무나도 많은데...

그것을 인정하지 않는 순간부터,

어쩌면.. 인생이 너무 초라해질 것 같네요.

게임 서버 엔진의 세션과 엔티티 설계

사자바이 — Sat, 08 Nov 2008 17:12:21 GMT

게임 서버 프로그램의 엔진을 개발할 때 주로 고민하게 되는 부분 중 하나인

세션과 엔티티에 대한 이야기를 해볼 까 합니다.

우선, 단어에 대한 정의가 우선이겠군요.

[ SESSION ]
7【컴퓨터】 세션
a 컴퓨터 시스템의 사용자가 단말기 앞에 앉아 로그인하여 사용을 시작한 다음 작업을
끝마칠 때까지의 동안
b 원격 컴퓨터와 사용자 사이에서 교환되는 데이터들의 완전한 집합

[ ENTITY ]
en·ti·ty〔〕 n. (pl. -ties)
1 실재(實在), 존재
2 본체, 실체(實體), 실재물;자주 독립체

*출처 [네이버 단어사전]

위 단어의 뜻을 참고하여, 각각의 단어의 의미를 가지고 아래와 같은 네이밍으로 구성합니다.

[세션] 이란 네트워크 I/O 를 처리하는 클래스를 뜻합니다.

EventHandler, Session 등의 이름으로 구성되는 클래스들을 말하겠지요?

[엔티티]란 로직을 처리하기 위해 설계되는 클래스를 말합니다.

User, Player, Monster 등등 로직을 처리하기 위해 필요한 실재를 구성한 클래스 입니다.

일반적으로 게임 서버 라이브러리에서 세션과 엔티티는 아래와 같이 구성하는 것 같습니다.

그림 1) Socket[Session] 을 상속받은 Player[Entity] 구조

Socket 클래스는 실제 SOCKET 핸들을 속성으로 가지고 그에 대한 인터페이스를 마련한

세션 역할의 클래스입니다. 그리고 Player 는 실제 로직을 처리하기 위한 엔티티 역할이겠지요.

가장 쉽게 접근할 수 있는 구성이며, 또한 매우 단순한 형태의 구조라고 말할 수 있을 것입니다.

아무래도 소켓 자체에 대한 래퍼 클래스를 구성하면서, 매번 이 역할의 클래스에 접근해야 할 일이

많아져, 아예 Socket 클래스에 많은 역할을 가지게 하여 파생된 형태의 패턴이 아닐까 생각됩니다.

그리고 많은 서버 라이브러리가 하는 방식인 세션 역할의 클래스를 상속받은 유저 클래스 형태의

구성이 될 것 이고요. 이 구성의 장점과 단점은 무엇일까요 ?

이 부분에 대해서는 조금 있다가 언급하기로 하고, 이와 비슷한 또 다른 구성이 있습니다.

어느정도 네트워크 패턴에 대해 많이 생각하고 이미 많이 언급된 형태(Reactor, Proactor)의 영향으로

아래와 같은 네이밍으로 구성된 설계가 있을 것입니다.

그림 2) EventHandler[Session] 을 상속받은 Player[Entity] 구조

이 구조는 이미 많이 알려진 Reactor, Proactor 패턴에서 관련 이벤트를 처리하기 위한 EventHandler 를

구현하여 이루어진 형태입니다. [ACE] 가 가장 좋은 예가 되겠지요. ?

실제 구현적으로는 다른 부분이 있을 수 있겠습니다만, 이 글을 통해 이야기하고자 하는

세션과 엔티티 설계 부분에 대해서는 [그림 1] 의 구성과 크게는 다를 것이 없습니다.

위와 같은 형태를 가진 서버 엔진을 실제 구현도 해보고 업무에서 활용하여 서비스도 해보았습니다.

그렇게 하면서 느끼게 된 제 주관적인 장/단점은 아래와 같습니다.

장점

1. 구조가 비교적 단순하여 직관성이 향상된다.

2. 엔진이 알고 있는 세션을 직접 상속하므로 접근성이 확대된다.

3. 디버깅이 효율적이다.

단점

1. 서버 엔진의 구현에 참여된 세션이 그대로 로직에 노출된다.

2. 상속 구조를 가지므로 서버 엔진과 로직의 의존관계가 이루어진다.

3. 엔티티는 세션과 is-a 관계로 불필요한 책임을 가지게 된다. [단일 책임 원칙(SRP) 위반]

저는 위 장/단점을 토대로 고민 끝에 아래와 같은 구성으로 게임 서버 엔진을 개발하게 되었습니다.

그림 3) 세션[Session] 엔티티[Entity] 분할 구성

EventHandler[Session] 은 위에서 소개한(그림 1, 2) 구성과 같은 방식으로 제작된 클래스입니다.

IO Coordinator 는 실제 서버 엔진 Network I/O Layer 에서 발생한 여러가지 이벤트를

UserLayer 즉, 로직에 알리는 역할을 가진 클래스입니다.

Entity 는 서버 엔진이 알고있는 주체와의 연관 관계를 위해 설계된 클래스입니다.

실제로 서버 엔진을 사용하게 되는 유저, 즉 로직은 EventHandler[Session] 을 알지 못하고

오직 Entity 클래스만을 알도록 설계적으로 노출시키도록 하였습니다.

그리고 서버 엔진에서 로직으로, 그리고 로직에서 엔진으로 요구하는 여러가지 명령에 대해

각각의 주체를 공유하기 위한 Unique ID 를 생성해 관리하며 처리합니다.

즉, 위 구성(그림 1, 2) 과는 다르게 세션과 엔티티 클래스의 상속 관계를 제거하였습니다.

따라서 로직이 알 필요가 없는 세션 클래스의 역할 자체를 노출할 필요가 없게 되었으며,

로직에서 엔진쪽으로 접근이 필요한 인터페이스에 대해서는 엔티티 클래스가 그 역할을

가지게 하여 프록시 패턴의 형태로 구성이 됩니다.

따라서, 의존관계가 사라지므로 각 레이어의 주체 클래스(엔진:Session, 로직:Entity) 의

영역을 제거하거나 혹은 직접적인 접근이 이루어지더라도 각각에게는 아무런 영향이

없는 것입니다.

엔티티 클래스 역시도 서버 엔진 구성에 포함되는 클래스이지만, 로직에 노출되는 클래스는

엔티티 클래스로 제한됩니다. 그리고 로직은 엔티티 클래스를 상속 받거나 혹은 이 역시도

불필요한 구성이므로 오직 Unique ID 를 통해 [연결] [종료] [수신] [송신]에 대한 요구와 통보 처리만

노출시키도록 해도 되겠지요.

이와 같은 설계로 서버 엔진을 개발하면서 느낀 장/단점을 정리해보면 다음과 같습니다.

장점

1. 서버 엔진과 로직 간의 의존관계가 사라진다.

2. 서버 엔진에 참여한 세션 클래스의 기능을 불필요하게 로직에 노출하지 않게 된다.

3. 세션은 세션의 역할, 엔티티는 엔티티의 역할만을 수행하므로 역할이 분명해진다.

단점

1. 구조가 복잡해지므로 구조를 이해하기 전 까지 직관성이 떨어질 수 있다.

2. 프록시 클래스가 추가되므로 개발 자체에 대한 비용은 증가한다.

3. 디버깅이 어렵다.

여기서, 위의 단점에 대한 제 의견을 덧붙여 보겠습니다.

1. 구조가 복잡해지므로 구조를 이해하기 전 까지 직관성이 떨어질 수 있다.

<< 오히려 역할 자체가 더 분명해졌고, 또한 서버 엔진과 로직 개발 책임자가 분리된 경우라면

불필요한 기능을 노출하지 않아 오히려 업무 집중력이 향상될 수 있습니다.

2. 프록시 클래스가 추가되므로 개발 자체에 대한 비용은 증가한다.

<< 개발 시 많은 추가 개발사항이 있고 또한 잦은 변동사항이 있는 경우에 개발의 비용이

증가되는 구조는 좋지 않은 선택일 것입니다.

하지만, 서버 엔진은 초기 개발 이 후에는 많은 변동사항이 발생하지 않으며

특별히 요구되는 추가 개발 사항도 비교적 많이 발생하지 않습니다.

무엇보다도 안정성이 생명인 서버 엔진을 개발하는 것이므로, 개발 비용이 증가하더라도

프록시를 구성하여 역할 자체에 대한 제한을 크게 두어 의존성을 분리하는 것이

더 나은 선택이라 생각합니다.

3. 디버깅이 어렵다.

<< 클래스가 많아지면서 디버깅 자체가 불리한 것은 사실입니다.

하지만 역할 자체에 대해서 분리된 구조이므로, 각각의 역할에 대해서 확실한 테스트가

이루어진 다음이라면 오히려 그 기초적인 테스트 기반이 있으므로 분리된 역할에 대한

테스트에 집중할 수 있다는 장점이 있습니다. 또한 분리되어 구현된 경우 테스트가된 부분은

재활용할 수 있다는 장점 또한 말할 수 있을 것입니다.

[틀리다] 와 [다르다] 의 차이

사자바이 — Mon, 29 Sep 2008 10:14:06 GMT

제가 회사 생활을 하면서 민감하게 받아들이는 말이 있습니다.

"그건 좀 틀린거 같아."

사실 위의 말을 하는 사람의 의도는 아래와 같지요.

"너의 의견과 내 의견이 조금 다르구나."

하지만, 받아들이는 사람은 방금 자신이 이야기한 것이 잘못되었다로 인식하기 쉽습니다.

그리고 이러한 말들이 오고 간 대부분의 토론은 서로의 감정만 상하고 끝나기 마련이지요.

아래 정확한 의미를 볼까요 ?

[단어 사전 - 네이버]

다르다
1 『(…과)』｛‘…과’가 나타나지 않을 때에는 여럿임을 뜻하는 말이 주어로 온다｝ 비교가 되는 두 대상이 서로 같지 아니하다.
2 보통의 것보다 두드러진 데가 있다.

틀리다
1 『(…을)』 셈이나 사실 따위가 그르게 되거나 어긋나다.
2 바라거나 하려는 일이 순조롭게 되지 못하다.

위의 단어의 정의 처럼 두 단어는 완벽하게 다른 의미를 가지고 있습니다.

물론, 어떠한 사실에 대해서 이야기할 때는 그 자체가 사실이 아니므로 [틀리다] 라는

말을 사용할 필요가 있을 것입니다.

하지만, 선택해야 할 필요성이 있는 부분에 대해서 각자의 의견이 오가는 토론속에서는

반드시 [틀리다] 라는 말 보다는 [다르다] 라는 단어를 사용해야 할 것입니다.

토론에서 서로의 의견을 가지고 이야기를 주고 받으면서 선택하게 되는 의견은

어느 하나의 의견이 잘못되었고, 다른 하나의 의견이 완벽하기 때문이 아니라

각각의 의견 모두 이유가 있고 장/단점을 가지 있으나, 현재 상황에 선택된 의견이

조금 더 어울리기 때문입니다.

서로의 의사를 존중하고 협의점을 잘 찾아가기 위한 노력을 하는 것이 협업에 있어서

정말 그리고 가장 중요한 부분일 것입니다.

혹시라도 [틀리다] 와 [다르다] 의 표현을 다르게 사용하고 있는 분이 계시다면,

오늘부터라도 그 의미에 맞게 말을 하시면 훨씬 더 수월한 협업이 가능하지 않을 까 생각합니다.

서버 개발과 [Layers] pattern

사자바이 — Sat, 27 Sep 2008 14:40:59 GMT

아키텍쳐 패턴 중에서는 [Layers] 라는 패턴이 있습니다.
서버 엔진 개발을 하면서 [Layers] 패턴을 적용하여 개발하였던 사례를 이야기 할 까 합니다.
[Layers] 패턴은 네트워크에 관련하여 공부를 해보신 분이라면 제일 먼저 소개되는 OSI 7 Layer 로
설명하면 좋을 듯 합니다.
아, OSI 7 Layer 보다는 보다 현실적인 TCP/IP Layer 를 살펴보는 것이 좋을 것 같네요.

[그림 1.1 TCP/IP Layer]

[Layers] 패턴의 정의를 POSA(Pattern-Oriented Software Architecture) Vol. 1 에서는 이렇게 정의합니다.

Layers 아키텍처 패턴은 어플리케이션을 구조화하기 위해 서브태스크들을 그룹으로 묶어 분해한다.

이 때 특정 추상 레벨에 있는 서브태스크들끼리 묶어서 서브태스크들을 각각의 그룹으로 분류한다.

음.. 자 쉽게 이야기하여 봅시다.
위 [그림 1.1] 에서 각각의 Layer 들은 모드 제 각각의 역할을 가지고 있습니다.
사실, 여러 디자인 설계의 목적에 부합하도록 실제로는 하나의 기능을 수행하기 위해 필요한 여러가지
역할을 하나하나 쪼개어져 Layer 로 분할되어진 것이지요.
모든 Layer 가 사실은 하나의 역할, 즉 각 종단 점이 서로 원격으로 통신하도록 하기위해필요한 일들을
분담하여 처리하고 있다는 것입니다.

그리고 그 분담처리를 각 Layer 와 Layer 간의 관계를 통한 교류와 정의된 절차대로 수행합니다.
(위 그림에 대한 구현 내용에 대해서는 스티븐 아저씨의 TCP/IP Illustrated 시리즈의 책을 추천합니다.)

왜!?
한 가지 일을 하기 위한 구성을 이렇게 복잡하게 여러가지로 쪼개서 만들어 두었을까요.
사실 이렇게 만들면 개발 자체는 더욱 어려워질 것입니다.
당연한 말이겠지만, 우선 각 Layer 별로 쪼개기 위해 인터페이스 설계하겠지요.
그리고 별 필요도 없는 기능임에도 각각의 Layer 연동을 위해 추가적으로 필요한 구현도 있을 것입니다.
그리고 테스트도 그 만큼 영역이 확대되어 많아지겠지요.(부정의 의미는 아닙니다.)

하지만, 이러한 구조를 적용함으로써 나아지는 점이 있습니다.
위 주장에 대한 설명은, 이제 제가 개발하였던 서버 엔진에 [Layers] 패턴을 적용하여 얻었던
이 점을 설명하면 충분히 뒷받침이 되리라 생각되네요.

서버 프로그램의 기능은 무엇인가요 ?
네, 서비스를 위해 각 유저 간의 데이터를 송/수신하여 비즈니스 로직을 처리하는 것입니다.
이 것을 각각의 역할로 조금 더 세부적으로 나누어보면 다음과 같습니다.

1) 네트워크 처리 역할 (접속, 연결, 데이터 송/수신)

2) 브릿지 처리 역할 (네트워크 처리와 비즈니스 로직 간의 중개)

3) 비즈니스 로직 처리 (게임 데이터 처리, 기타 ... )

서버 엔진을 개발하면서 위와 같이 서버가 하는 일을 분류할 수 있지 않을 까 생각해봤습니다.
그리고 위 세가지 역할은, 서버가 서비스될 플랫폼이 달라지거나 비즈니스 로직이 달라지는 경우에 따라
역할 별로 다른 처리가 필요한 상황이 있습니다.
Windows Server 환경에서 서비스하다가 중간에 Linux 로 변경될 수도 있는 것 처럼 말이지요.
프로그램 구조 설계에 있어서 근본적인 원칙 중 하나에 따라,
변경에는 닫혀있고 확장에는 열려 있으려면(OCP) 어떠한 접근이 좋을 지 고민을 시작하게 되었습니다.

그리고 그 결론은 [Layers] 패턴을 적용하는 것이었습니다.

제가 개발한 서버 엔진은 아래와 같이 설계하게 되었습니다.

Network I/O Layer ) 에서는 일반적인 네트워크 처리 역할을 담당합니다.
유저 접속, 연결 요청, 데이터 송/수신

이 Layer 는 운영체제와 비즈니스 로직 중간의 네트워크 서비스에 대한 미들웨어 역할을 한다고 볼 수 있습니다.
Windows NT 환경일 경우에는 상황에 따라 IOCP 를 사용하여 개발될 수도 있으며,
그 외의 경우 epoll, select 등 여러가지를 활용할 수 있겠지요.
그리고 Network I/O Layer 인터페이스에 맞게 Adapt 하게 구현하여 이미 개발되어 있는
네트워크 라이브러리를 적용하여 구성할 수도 있을 것입니다.
저도 이 구성에 ACE 도 연동하여 테스트도 진행하여 봤는데, 만족할 만한 결과 였습니다.
상황에 따라 멀티 플랫폼을 지원해야 하는 상황이라면 이미 테스트가 많이 수행된 외부 네트워크 엔진을
적용하는 것도 좋은 방법일 것입니다.

Mainframe Layer ) 에서는 브릿지의 역할로 Network I/O Layer 와 Application Layer 의 중개 역할을 합니다.
엔티티별 송/수신 버퍼 처리, 패킷 마샬/언마샬링, 메시지 핸들링, 보안, 스케쥴링

이 Layer 는 Network I/O Layer 와 Application Layer 중간의 중개 역할을 담당합니다.
Network I/O Layer 에서 넘겨주는 데이터를 비즈니스 로직에 넘겨질 수 있도록 데이터를 가공하고
또한 Application Layer 의 인터페이스에 맞게 해당 가동된 데이터를 전달하는 역할을 합니다.
그리고, 네트워크 서비스에 대한 처리에서 비즈니스 로직에 맞지 않은 상황에 대한 보안 기능을 처리하고
추가적인 스케쥴링 처리도 담당하게 됩니다.
위의 처리는 각 비즈니스 로직에 따라 많은 변경 사항을 동반하게 될 것입니다.

이 변경을 어떻게 처리할 것인지는 여러가지 방법이 있습니다.
다음 스레드에서는 Mainframe Layer 에 적용되었던 여러가지 기능을 소개할 까 합니다.

Application Layer ) 에서는 비즈니스 로직에 대한 처리가 이루어지게 됩니다.
Application Layer 는 이미 구현된 서비스라기 보다는 각 서버 개발에 따라 클라이언트, 즉 이 서버 엔진을
사용할 유저가 직접 구현하는 Layer 입니다. Application Layer 에 맞게 비즈니스 로직을 구현하기만 하면
네트워크 서비스를 사용해 비즈니스 처리를 이룰 수 있는 것입니다.
온라인 게임의 경우라면, 게임 관련 코드가 이 Layer 에 모두 담겨지게 되겠네요.

[Layers] 아키텍처 패턴은 사실, 너무나도 일반적이고 오래전 부터 각인되어 온 것입니다.
이 패턴을 적용하면서 느낀 장 단점은 아래와 같습니다.

또한 온라인 게임 서버 엔진을 개발하면서 느낀 부분도 함께 정리해볼까 합니다.

장점

1) 역할 별 기능 구현에 대한 재사용이 용이하다.
프로젝트 별로 플랫폼별 Layer 개발을 끝낸 후 그에 대한 테스트가 마무리된 상황이라면
이 후 프로젝트에서는 Application Layer 즉, 비즈니스 로직만 변경하여 재활용할 수 있습니다.

O- Windows 환경에서 서비스하다가 회사 정책이 바뀌어 다른 운영체제로 바뀌는 상황이
나타나게 될 경우를 생각하여 보세요. 저는 생각만해도 아찔합니다.;

게임 서버 엔진에 [Layers] 패턴을 적용할 경우에는 간단해집니다.
Network I/O Layer 의 구현만 해당 플랫폼에 맞는 것으로 변경하여 연동하여 주면 되는 것이니까요.
(물론, 비즈니스 로직(Application Layer) 와 Mainframe Layer 가 플랫폼 종속적으로 개발되었다는
가정하에 말씀드리는 것입니다.)

또한, 상황에 따라 요즘 많이 배포되고 있는 네트워크 라이브러리를 연동하여 개발할 수 있습니다.
(테스트로 ACE 를 연동하여 테스트하여 보았는데 만족할 만한 결과였습니다.)

그리고 어느정도 검증된 미리 개발한 Layer 들이 있다면 회사에서는 차기 프로젝트에서도 충분히 활용하여
비즈니스 로직만 다르게 하여 사용할 수 있으므로 재사용할 수 있는 범위가 넓어지게 됩니다.
이에 따라 개발 비용도 엄청나게 줄일 수 있겠지요 !

2) 역할 별 나타날 수 있는 종속성을 최소화한다.
하나의 책임을 수행하기 위하여 분산된 역할 각각이 종속성을 크게 가지게 될 경우,
그에 대한 유지 보수 처리에 대한 어려움이 종속성에 따라 비례적으로 증가합니다.
또한, 업무적으로도 비즈니스 로직 개발자는 네트워크 서비스 개발에는 신경쓰지 않고
비즈니스 로직에만 집중할 수 있으므로 더욱 효율적인 개발이 가능합니다.

O- 개발자 별로 Layer 에 대한 구현을 분담하여 개발하면 업무 효율성이 증진될 수 있을 것입니다.
또한 그 업무 영역이 명확하므로 개발 시 나타날 수 있는 트러블에 대한 비용도 최소화 될 수 있고요.

단점

1) 역할 별로 Layer 를 분할 하는 것이 쉽지 않다.
이는 설계 시점에 중요한 요소일 것입니다. 만약 역할 별로 Layer 를 분할하는 것이
쉽지 않다면 이는 [Layers] 패턴을 적용할 수 있는 구조가 아닌 것입니다.
신중한 판단이 필요할 것입니다.

2) 추가 개발 비용이 증가한다.
하나의 기능을 수행하는 프로그램을 구현하는 것 보다, 각 역할별로 Layer 를 쪼개어
인터페이스를 분할하여 구현하고 또한 그 연동 코드가 들어가면서 필요한 추가 개발
비용이 증가합니다. 또한 그에 따라 프로그램 구조가 복잡해져, 가독성이 떨어질 수 있습니다.

3) 변화가 크게 나타날 경우 보완이 어렵다.
예를 들어, 각 Layer 별 역할이 프로그램 구조상 변경될 경우 각 Layer 간의 인터페이스가
깨지게 되므로 재작업 비용이 크게 발생할 수 있습니다. 이러한 현상이 나타나는 것을
방지하기 위해서 초기 설계 작업을 신중히 할 필요가 있습니다.

온라인 게임이 가져야할 요소에 대하여..(1)

사자바이 — Sun, 02 Mar 2008 16:27:49 GMT

온라인 게임은 싱글 게임과 [게임] 이라는 공통 분모를 제외하고는 전혀 다른 분야라고 생각합니다.

싱글 게임은 그 자신의 재미에만 집중하고, 유저는 그 게임에 대한 재미 요소에 집중합니다.

그리고 유저는 그 재미 요소에 대한 컨텐츠 소비를 통해 게임 플레이에 대한 존재감을 느끼며,

그 존재감이 사라질 시점에 또 다른 게임을 찾을 것입니다.

싱글 게임 개발의 목표 역시 맞추어진 게임 컨텐츠 소비에 집중하여 그 한계를 설정합니다.

하지만, 온라인 게임은 싱글 게임이 가지는 재미와 더불어

또 다른 하나의 세상이 되어야 한다고 생각합니다.

온라인 게임에 접속하는 유저는 싱글 게임을 통해 가질 수 있는 [재미] 에,

온라인으로 만나는 또 다른 유저와의 커뮤니티를 통해 이루는 또 다른 [재미]를 형성해 갑니다.

그를 통해 유저는 온라인 게임 내부에서 또 다른 자신(아바타)를 형성하여 그 속에서 어울립니다.

말 그대로 컨텐츠 한계성이라는 말 자체가 용납되지 않는 상황이라는 것이지요.

온라인 게임에서 유저가 느끼는 컨텐츠의 한계란,

결국 스스로가 할 수 있는 것이 아무것도 없는, 어두운 세상 속의 방랑자가 된다는 것입니다.

하지만, 너무나도 빨리 소모되는 유저들의 컨텐츠 소비량으로 인해

개발의 입장에서 봤을 때 그 컨텐츠의 개발을 쉽게 감당할 수가 없습니다.

사실, 모든 유저의 컨텐츠 소비량을 맞추어서 개발한다는 것 자체가 오류일 수 있을 것입니다.

왜냐하면 모두가 사람이기에 저마다 바라는 [재미] 는 다를 것이며,

또 그를 위해 필요한 사항도 다를 것이기 때문입니다.

그렇다면, 온라인 게임 개발에 있어서 무엇을 중요하게 생각해야 할 까요 ?

단순히 싱글 게임 처럼 한계성을 띄는 컨텐츠에 집중해 게임 자체의 [재미]에 대해서만 신경을 쓴다면

그 [재미] 성향의 소수 유저에게는 매력적일 수 있지만, 그 뿐..

더 이상 온라인 게임에 대한 매력을 가지지 못해 상용화 서비스 단계 전에

그 한계를 드러내버리고 말 것입니다.

이를 근거로 제가 생각하는 온라인 게임 개발에 필요한 요소는 다음과 같습니다.

1. 이미 온라인 게임은 유저들에게 단지 [게임] 이 아닌 또 다른 문화로 인식되고 있습니다.

2. 온라인 게임은 직렬이 아닌 병렬적인 사고로 [재미]에 대한 철학을 재정립할 필요가 있습니다.

3. 사람은 경제적 유인과 더불어 관계적 유인에 반응합니다.

4. 리얼리티를 위한 리얼리티가 아닌 가상을 위한 리얼리티가 필요합니다.

위의 항목에 대한 사항은 다음 포스트에서 이어가겠습니다.

지하철에서의 환상적인 화음 !

사자바이 — Sat, 05 May 2007 18:40:26 GMT

멋집니다.

음악은 역시 위대하군요.. !

아침 출근 시간의 지하철 2호선에서 이러한 노래를 들으며 춤출 수 있는 날이 올까요 ?

다시 시작!

사자바이 — Mon, 26 Mar 2007 00:53:00 GMT

한 동안 프로젝트에 정신이 없던 나머지,

개인적인 이러한 공간을 너무나도 관리하지 않은 것 같습니다.

하나하나, 다시 다음어 가야 할 것 같습니다.

너무 나태해진 제 자신도 반성할 겸 말이지요.

Carpe Diem !