1章. IOCP란 무엇인가?

일반적으로 (IO Completion Port)을 일컬어 IOCP라 한다.
이는 IO 작업[1] 을 수행하는 메커니즘 중의 하나이다. 보다 구체적으로 말하면, 비동기로 IO 작업을 수행해 오버헤드를 크게 줄이는 입출력 방식을 뜻한다. 즉, 지금까지의 입출력 방식이 프로그램을 수행하는 동안 입출력 작업을 수행하는 직렬 방식이었다면, 이 IOCP 방식은 프로그램의 수행과 입출력 작업을 분리해 병렬적으로 수행하는 것이다. 그 정의와 역할에 대한 설명은 이후 본문에서 계속하도록 한다.
이 IOCP라는 처리 방식의 특징은 모든 IO 작업을 오버랩시키면서 수행하는 입출력 방식, 즉 (Overlapped IO)를 통해 극명하게 드러난다고 볼 수 있다. (Overlapped IO)에 대해서는 차후 보다 자세히 언급할 것이다.
이러한 IOCP 처리 방식은 모든 입출력 작업에 적용될 수 있으나, 특히 IO 작업의 수가 대단히 많아 부하가 많이 걸리는 대규모 입출력 작업, 네트워크 작업과 같은 작업에 있어서 큰 효율을 보인다. 현재 대용량 윈도우 서버는 거의 대부분이 IOCP로 이루어져 있을 만큼, 이 IOCP는 동시에 많은 작업을 처리하는 경우에 최고의 효율을 자랑한다.
이 글에서는 IOCP가 어떠한 방식으로 작동하며, 왜 다른 입출력 방식보다 효율적이며, 실제로 코드상에는 어떤 식으로 구현되는가에 대해 살펴보도록 하겠다. 또한 이 IOCP를 보다 효율적으로 사용할 수 있는 알고리즘에 대해 논해보겠다.

2章. IOCP의 기반 지식

(1) Overlapped IO
IOCP에 대해 언급하려면, 먼저 (Overlapped IO)라는 것이 무엇인가부터 논해야 한다. IOCP에서 사용하는 것이 바로 이 (Overlapped IO)이기 때문이다. (Overlapped IO)라는 말은, 말 그대로 IO 작업이 서로 오버랩되어서, 즉 겹쳐져서 수행된다는 뜻이다. 즉, 다른 IO 작업이 수행되는 동시에 또 다른 IO 작업이 수행될 수 있는 기능을 말한다.
이처럼, 하나의 프로세스 내에서 여러 개의 IO 작업이 컨커런트하게 진행된다는 의미로 해석할 수 있다. 일반적인 입출력 작업에서 블럭되어 입출력을 기다리는 것과 달리, 여러 개의 IO 작업을 병렬적으로 수행할 수 있다는 뜻이다. 이러한 (Overlapped IO) 구조체를 넘겨받는 것으로 IOCP 작업이 수행된다. 각각의 (Overlapped IO) 구조체가 IOCP 작업의 단위라고 볼 수 있다.
이 (Overlapped IO)는 SCAN 방식[2] 이라는 스케줄링 정책을 선택해 보다 나은 성능을 보여준다. 즉, 반드시 IO 작업이 들어온 순서대로 수행하는 것이 아니라, 보다 빨리 수행할 수 있는 것부터 수행한다.

(2) Multithread Programming
 과거에 이용되어 왔던 멀티쓰레드 프로그래밍의 경우, 하나의 유저에 대해 하나의 쓰레드를 생성하는 것이 일반적이었다. 이는 IO 작업의 특성과 긴밀하게 맞물려 있다. 하나의 쓰레드가 어떤 IO 작업을 수행하려 한다면, 그 쓰레드는 IO 작업이 끝날 때까지 블럭되어 가만히 머물러 있어야 한다. 즉, 그러한 이유로 하나의 쓰레드가 여러 명의 유저를 처리해줄 수는 없다. 그래서 프로세스는 여러 명의 유저에 대해, 하나의 유저 당 하나의 쓰레드를 지녀야 한다.
 이것은 몇천 명의 유저가 접속하는 대용량 서버에 있어서 치명적인 오버헤드가 된다. 유저의 수만큼 쓰레드가 필요하므로, 이 쓰레드의 리소스만 해도 엄청난 오버헤드이다. 그것보다 더 큰 문제는 각각의 쓰레드를 빈번하게 교체하는 경우 발생하는 문제, 즉 Context Switching[3]에서 발생하는 오버헤드이다.

(3) Problem of Context Switching
Context Switching이란, 커널을 점유한 쓰레드 혹은 프로세스가 점유를 중단하고 다른 쓰레드에게 그 점유권을 넘겨주는 작업을 뜻한다. 이 작업은 쓰레드의 당시 상태를 모두 기록하고 레지스터를 다시 기록해야 하는 등, 아주 무거운 오버헤드를 발생시키는 작업이다. 되도록이면 피하는 것이 좋다.
그러나 멀티쓰레드 프로그래밍으로 대용량 서버를 구현할 경우, Context Switching은 엄청나게 빈번하게 발생할 수밖에 없다. 즉, 멀티쓰레드 프로그래밍은 Context Switching의 문제로 인해 대용량 서버에 적합한 모델이 되기 힘들다. 따라서 사람들은 멀티쓰레드 프로그래밍을 진행하면서도 최대한 이 Context Switching 문제를 줄이는 방법을 연구해왔다. 그 대안들로 Select-Poll과 같은 방법이 제시되긴 했지만, 아래 설명할 IOCP의 성능에는 미치지 못한다.
요약하자면, 저러한 문제들을 해결하기 위해 제시된 대안이 바로 IOCP라는 것을 알 수 있다.

3章. IOCP의 개념 및 역할

그렇다면 이제 IOCP가 무엇인가를 살펴보자. IOCP는, IO 작업을 위해 윈도우 운영 체제에서 제공하는 커널 오브젝트의 일종이다. (IO Completion Port)라는 이름의 의미는, 이 포트에 IO 작업들이 연결되고, 이 작업들이 완료되었을 때 특정한 방식으로 프로세스에 통지한다는 의미로 해석할 수 있다. 즉, 이 IOCP는 IOCP와 연결된 전반적인 IO 작업을 총괄하며, IO 작업들을 직접 핸들링한다.
이 IOCP 객체가 수행하는 일은 크게 두 가지로 나눌 수 있다.

(1) IOCP 쓰레드 풀 생성.
IOCP의 특성상, IOCP를 사용하면 IO를 관리하는 쓰레드들이 빈번하게 wake, 혹은 sleep를 반복한다. 그러한 경우 IOCP는 쓰레드를 일일이 생성하거나 소멸시키는 대신, 일정 수의 쓰레드들이 포함된 Pool을 미리 생성하고 그 Pool 속의 쓰레드들을 꺼내 썼다가 다시 집어넣는 식으로 사용한다. 이는 쓰레드를 생성하고 소멸시키는 데에 필요한 오버헤드를 크게 감소시키는 훌륭한 방식이다. 이는 사용자가 굳이 설계할 필요가 없이, IOCP 객체를 생성하고 이용함으로써 자동으로 생성된다.

(2) 활성화된 쓰레드의 숫자를 조절한다.
쓰레드를 사용하기 위해서는 그 쓰레드가 CPU를 점유해야 한다. 컨커런트하게 수행되는 프로그램이라고 해도, 어느 한 순간에 실제로 CPU를 점유하는 것은 하나뿐이다. 그래서 쓰레드들의 CPU 점유를 관리하기 위해 스케쥴러가 사용된다. Starvation[3]을 피하기 위해 쓰레드들을 스케줄링할 필요가 있기 때문이다. 하지만 이 쓰레드의 스케줄링은 그다지 가벼운 작업이 아니다. 쓰레드에 대해 (Context Switching)을 수행할 경우 이는 엄청난 오버헤드를 발생시킨다. 이것은 앞서도 말했던 고질적인 (MultiThread Programming)의 문제이다. 하지만 IOCP의 경우, 이러한 쓰레드의 숫자를 제한하고 적절한 숫자의 쓰레드만이 활성화되도록 컨트롤할 수 있다. 이는 대단히 중요한 IOCP의 장점이다.

4章. IOCP의 비교 우위

IOCP가 비교 우위에 서 있는 원리를 정리하면 다음과 같다. IOCP는 IO 작업을 수행하는 경우, 블럭되어 멈추어 있는 대신 바로 함수를 리턴해 버린 후, 그 IO 작업은 IOCP Queue에 삽입해 다른 쓰레드에게 맡겨버린다. 그리고 그 IO 작업이 완료된 이후의 진행은 다른 루틴에서 진행된다. 즉, 비동기로(Asynchronous) IO 작업을 수행함으로써, 많은 IO 작업을 수행하면서도 최소한의 쓰레드만으로 프로세스를 유지함으로써, IO 작업 처리의 효율성을 제고한다.
이에 비해 멀티쓰레드 프로그래밍의 경우, 하나의 IO 작업을 수행하면 그 IO 작업에 대해 계속 블럭되어 멈추어 있다가 그 아래 루틴에서 작업을 수행해야 한다. 그러므로 하나의 쓰레드가 동시에 하나의 IO 작업밖에 수행할 수 없다. 그래서 IO 작업이 필요한 객체 하나당 하나의 쓰레드가 필요하다. 이것은 동기(Synchronous) IO 작업 수행 방식의 특징이다. 이 방식은 수많은 클라이언트들로부터 수많은 요청들이 서버에 쏟아질 때, 엄청난 Context Switching을 수행해야 하는 치명적인 단점이 있다.

5章. IOCP 구현 메소드

IOCP의 실제 코드 상의 구현을 설명하기 위해서 IOCP와 관련된 메소드를 설명해보겠다. 실제로 IOCP가 IO 작업들 중에서도 소켓 통신에 많이 이용된다는 점을 감안, 소켓 통신에 사용되는 메소드들을 뽑아 예시로 사용했다.

(1) WSARecv & WSASend
각각 비동기로 입력, 출력을 수행하는 함수이다. 이는 IOCP와 연계되어 사용된다. 즉, 함수의 파라메터 중 m_overlappedRead/Write를 이용해 (Overlapped IO)를 지정할 수 있다. 이 함수는 여섯 번째 파라메터를 이용해 입출력 작업을 비동기로 수행하도록 명령할 수 있다. 이는 쉽게 말하자면, 루틴이 진행되는 가운데 프로그램과 상관없이 알아서 진행된다는 뜻이다. 이는 IOCP와 연결되었기 때문이다.
6, 7번 파라메터의 설정에 의해 IOCP와 연결이 가능하다. 6, 7번 파라메터를 NULL로 두면 동기로 수행된다. 일반적인 Recv와 Send와 같은 용법으로 사용된다고 볼 수 있다.
이 함수 아래의 루틴에서는 이 함수가 읽어들인 것을 처리하지 않는다. 이 함수는 바로 ERROR_IO_PENDING이 반환되어 버리며 종료된다.
ERROR_IO_PENDING의 의미는 동기화되지 않았기 때문에 차후 수행할 예정이라는 뜻이다. 차후 이 함수가 읽어들인 값은 GetQueuedCompletionStatus 함수에서 받아오게 된다.
이 함수에서 명령한 입출력 작업이 IOCP에 할당된 쓰레드에 의해 완료되는 순간, 예의 GetQueuedCompletionStatus 함수가 리턴하게 된다. 그 아래 루틴에서 이 GetQueuedCompletionStatus에서 수행한 작업이 어떤 작업인가를 m_overlappedRead와 CompletionKey를 통해 알아낼 수 있다.
이 함수가 수행되면 이 IO 작업은 비동기로 수행된다. 완료되었을 경우 (IOCP Queue)에 삽입되며, 처리는 차후 GetQueuedCompletionStatus가 호출될 때이다.

(2) CreateIOCompletionPort
일반적으로 두 가지 용도로 쓰인다. 순수한 IO Completion port의 생성의 용도와, 이 함수를 통해 생성된 IO Completion port에 입출력 Handle을 연결하는 용도이다. 이 함수는 네 개의 파라메터를 받는다.
첫 번째 인자는 붙일 IO 핸들을 의미한다. 소켓 통신이므로 Socket 구조체가 될 것이다.
두 번째 인자는 IOCP의 이름이다.
세 번째 인자는 사용할 객체의 포인터이다. 이는 차후 GetQueuedCompletionStatus 함수에서 지금 수행 중인 작업에 대한 객체가 어느 객체인가를 구분하기 위해 필요하다.
네 번째 인자는 이 IOCP에 붙일 쓰레드 수이다. 숫자를 지정하지 않으면 CPU 숫자에 2를 곱한 값에 다시 2를 더한 값으로 지정된다. 이처럼 소수의 쓰레드만을 사용하는 것이 오버헤드를 줄이는 힘이다. 다만 이 숫자를 정확하게 얼마로 하는 것이 좋은가, 하는 문제는 보다 연구해볼 가치가 있다.

(3) GetQueuedCompletionStatus
IOCP Queue에 완료된 결과가 들어왔을 경우 쓰레드를 깨우거나, 쓰레드가 없을 경우 쓰레드 풀을 생성하게 된다. 만약 너무 많은 쓰레드가 활성화되어 있으면 그 숫자를 제한한다.
이 함수는 쓰레드에서 일괄적으로 큐에서 결과를 읽어내기 위해 사용된다. 읽어들인 결과가 있을 때까지, 다시 말하자면 비동기 입력 작업이 완료될 때까지 계속 대기한다. 5번째 인자를 통해 너무 많은 시간이 지날 경우에 대해 타임아웃이 지정 가능하다.
즉 IOCP와 연결된 입출력 함수 (Ex. WSARecv) 등이 호출되는 경우 그 함수가 읽어들인 내용을 이 GetQueuedCompletionStatus 함수의 아래 루틴에서 실제로 처리하게 된다.

(4) PostQueuedCompletionStatus
PostQueuedCompletionStatus를 사용하면 GetQueuedCompletionStatus를 강제로 호출할 수 있다. 엄밀히 말하면 PostQueuedCompletionStatus를 사용해 IOCP Queue에 전달하는 것이고, 이것을 처리한 후 IOCP Queue에서 결과가 드러나면 GetQueuedCompletionStatus이 호출된다고 볼 수 있다.

6章. IOCP의 사용 예시

IOCPThread
// IOCP에서 읽어들인 결과를 전담하는 쓰레드이다.
{
             GetQueuedCompletionStatus(...);
             // 아래에서 읽어들인 바이트 처리
             // CompletionKey 검사 후 다른 function으로 분기
             // 혹은 Virtual Function을 사용
             // 어디서 왔는가를 판별 (WaitThread, IOThread(WSARecv), WSASend 등등)
             // 적절하게 읽어들인, 혹은 보낸 데이터를 처리.
             // 읽어들인 데이터는 저장하고 모자란 부분을 더 보내는 등의 작업.
}

WinMain
{
             CreateIOCompletionPort(...)
             // 포트를 생성한다.
             ...
             서버용 Socket 생성
             CreateIOCompletionPort(Socket, ...)
             // 소켓 생성 후 Accept하면 WaitThread에 연결
             ListenThread;
}

ListenThread
{
             WaitForMultipleObject 등 사용해서 다중 접속 대기.
             접속시
             {
                           socket = accept(...)
                           CreateIOCompletionPort(Socket, ...)
                           Recv();
                           // 여기서 데이터의 수신이 이루어진다.
                           // 이 함수는 받든 못 받든 IO_ERROR_PENDING으로 지나가버림
                           // 만약 IO작업이 이루어지면 IOCP Queue에 들어감.
                           // GetQueuedCompletionStatus 아래의 IOCPThread에서 처리하게 됨.
             }
}

Recv(...)
{
             WSARecv(...);
             // 비동기로 수행한다.
             // 파라메터의 적절한 세팅이 필수적으로 요구된다.
}

Send(...)
{
             WSASend(...);
             // 마찬가지로 비동기로 수행한다.
             // 파라미터를 적절히 세팅한다.
}

SendSomething
{
             Send();
             // 데이터를 보내려 할 때 쓰일 수 있다.
             // 이 함수를 호출해 필요한 데이터를 보내준다.
             // WSASend는 한번에 모든 데이터를 전송하는 반면,
             // WSARecv는 한번에 모든 데이터를 받을 수는 없다.
             // 반드시 이 점을 염두에 두고 프로그래밍해야 한다.
}

7章. 요약 및 참고 문헌

지금까지 IOCP에 대해 살펴보았다. 확인한 바와 같이, IOCP는 실제 상용 서버에서도 많이 사용되는 입출력 기술이다. 물론 IOCP가 어떤 경우에도 최고의 성능을 자랑하는 것은 아니다. 하지만 클라이언트로부터의 리퀘스트가 많고 부하가 큰 대용량 서버의 경우, 현재 IOCP의 성능을 따라갈 만한 기술은 없다고 해도 과언이 아니다. 즉, 종합하자면 다음과 같다. IOCP는 다수의 입출력 작업을 처리하기에 최적화된, 우수한 성능을 지닌 IO 메커니즘이다.

참고 문헌

[1]IO란 컴퓨터나 주변 장치로부터 데이터를 교환하는 모든 프로그램, 오퍼레이션, 장치를 통칭하는 용어이다. 마우스나 키보드와 같은 장치는 입력만을 위한 장치이며, 프린터와 같은 장치는 출력만을 위한 장치이다. 하드 디스크와 같은 장치는 입출력 작업 모드를 수행할 수 있다. http://www.webopedia.com/TERM/I/I_O.html

[2]기본적으로 현재 위치에서 가장 가까운 데이터를 우선적으로 처리하며, 한쪽 방향으로 진행하고 한쪽 끝에 도달하면 반대쪽 방향으로 진행하는 방법. http://www.webopedia.com/TERM

[3]OS에서 어떤 자원 목록에 대해 경쟁하는 프로세스가 많고, 이 프로세스들이 자원 목록에 대해 어떤 특정한 스케쥴링 방법대로 권한을 얻어갈 때, 프로세스가 필요한 자원의 권한을 영원히 얻지 못해 일을 하지 못하는 현상. http://www.webopedia.com/TERM

--------------------------------------------------------------------------------

[１]Programming Server Side Applications for Microsoft Windows 2000, Jeff Richter, Microsoft Press

[２]Summary About IOCP, 이기탁, http://www.devpia.com

[３]Unix Network Programming, W. Richard Stevens, Addison-Wesley Professional

[４]Programming Applications for Microsoft Windows, Jeff Richter, Microsoft Press

[５]Programming Server Side Applications for Microsoft Windows 2000, Jeff Richter, Microsoft Press

2.
나는 대구에서 태어나 대구에서 자란 대구 토박이다. 대학에 진학하기 전까지 대구에서 한 발짝도 벗어나본 적이 없는, 심지어 수학 여행조차도 경주로 간... 뼛속까지 TK 출신이다.
80년대 대구의 보수성이란, 그야말로 무엇을 상상하든 그 이상을 생각하면 되는 지경이었다. 우리는, 김정일은 형제를 죽이고 온갖 악행을 일삼는 인간 이하의 무엇이라고 설명하는 반공 교재를 정독하며 살았고, '광주 사태'는 말 그대로 '광주 사태' 외의 다른 이름으로 부르는 것을 들어본 적이 없으며, 그 실체는 빨갱이들 몇 마리가 지리산 같은 몇몇 산을 돌아다니다가 그냥 총 맞아서 잘 소탕된 그런 '사태'로 알고 자랐다. 학교의 선생님들조차 박정희 전두환 노태우 라인을 칭송하는 마당에, 중학생의 단순한 머리가 편견으로 굳어지지 않는 게 더 이상하다.
우리는 김영삼을 영 - 동그라미 - 삼 - 나머지 세 개의 손가락, 즉 OK 표시라며 지지했고, 김대중은 대 - 커다란 - 중 - 가운데 손가락 - 으로 표현해 Fuck You 표시라며 무시하고 비웃었다. 당시 대구에선 초등학생들도 맹목적으로 그 손가락 표시를 따라하며 영재 교육마냥 정치적 입장을 구축하기 시작했다. 지금 와서 다시 생각해보면, 수사적인 표현이 아니라, 정말 등에 소름이 끼친다.
1997년, 김대중 대통령이 당선되던 그 해에도 나는 알지 못했다. 여전히 대구는 이회창에게 전폭적인 지지를 보내고 있었기 때문에. 그리고 호남 지역의 득표의 엄청난 지지율에 대해 비난하고 있었기 때문에. '저 전라도 투표율 봐라. 완전히 빨갱이 아이가.' 내 부모님, 내 형제, 내 친구들, 내 선생님들. 모든 사람들이 그렇게 말하는 상황에서, 나는 그 모든 것이 당연히 옳은 줄 알았다.

3.
대학에 와서 처음으로 '광주 사태'의 진실을 알게 되었던 그 순간을 아직도 기억한다. 수천명이 죽고 피바다가 된 광주... 그 잔혹하기 이를 데 없던 사진들, 증언과 증거들. 절대로 방송을 탈 수 없었던 그 참혹한 현장이... 다른 지방에는 내가 알고 있었던 바대로 '몇몇 빨갱이들이 선동해서 일으킨 폭동' 으로 알려진 그 씨발 좆같은 일이... 나는 미안했다. 그 사실을 몰랐다는 것 자체가.
그제서야 나는, 대구에서 자라난 내가 얼마나 '모르고 살아왔는가'를 알게 되었다. 언젠가 광주로 투입된 그 공수부대들, 그들에게도 면죄부는 있다는 얘기는 들은 적이 있었다. 무리하게 많은 인원을 안전 장치가 부족한 상태에서 낙하시키면서, 많은 동료들이 다치거나 죽어 갔고 그로 인해서 그들이 흥분 상태에 빠졌었다는 얘기를 말이다. 하지만, 하지만 묘하게도 말이다. 그래서 그 흥분 상태가 된 공수부대가 '구체적으로 무슨 일을 했기 때문에 면죄부가 필요한가?' 를 들은 기억은 없다. 왜 그럴까? 내가 일부러 기억에서 지웠을 리는 없을 테고... 설마 그런 것조차 말할 수 없는 정도의 환경이었을까? 내가 자란 곳이? 그것은 아니었을 것이다. 그것은 아마도 말의 강도의 차이였을 것이다. 우리는 '가해자'를 변호하고 있었기 때문에, '피해자'의 상황에 대해서 세세히 설명할 의무 따위는 없었다. 적어도 그때는 그랬던 것 같다.
우리는 단 한번도 광주 사태를 긍정적으로 언급한 적이 없다. 애시당초 빨갱이들이 선동한 폭동이었으니까. 우리는 전두환과 노태우를 성군처럼 받들어 왔다. 그들이 가장 훌륭한 대통령의 계보라고 말해왔다. 그들이 속한 여당, 그 당이 가장 훌륭한 정치적 견해를 지닌 정당이라고 믿어 의심치 않았다.
그 모든 것의 이면을, 그제서야 볼 수 있었다.
그리고, 예전부터 미스테리이던 그 전라도의 95% 지지율이 무엇을 뜻하는지를 알 수 있었다.
그건 피눈물이었다.
국민투표라는 형태를 빌어, 어떻게든 '그들'만은 안 된다는 극단적인 지지율의 형태를 빌어 눈앞에서 질척하게 흘러내리는 피눈물이었다.
그 노력을 '완전히 빨갱이 아이가'로 매도하던 나의 모습이,
나는 정말로, 부끄러웠다.
부끄러운 줄 알았다는 것이 그나마 다행이었지만, 그럼에도 불구하고 부끄러웠다. 그리고 미안했다. 죄송스러웠다. 지금까지 빨갱이 집단으로 취급하던, 단지 산 하나 건너 살고 있었을 뿐인 똑같은 사람들에게, 미안했다. 그렇게 상처를 입고도, 오해받고 차별받으며 살아야 했던, 그냥 좀더 용감했을 뿐인 그 사람들에게, 너무나도 미안했다.
2002년 대선에서 노무현을 찍는 것으로, 나는 조금이나마 미안함을 덜고 싶었다. 그렇게 내 무지와 편견에 대해 사죄하고 싶었다. 그리고, 이제는 더 이상 모르고 살아서는 안 되리라 결심했다. 다시는 이렇게 무지와 편견 속에서 판단을 내리지 않을 수 있도록, 모든 것을 올바르게 알기 위해 노력하리라. 적어도 내가 그렇게 살아가기 위해 노력함으로써 그 미안함을 씻어낼 수 있으리라 믿었다.
하지만 적어도, 한 사람에게만은 그 미안함을 절대로 덜 수 없으리라는 것을, 나는 오늘에야 깨달았다.

4.
김대중 전 대통령께.
한번이라도 당신을 향해 힘을 보태주는 목소리를 보내지는 못할망정, 당신이 어떻게 그 험난한 삶을 살아왔는지조차 알지 못하고, 어떤 사람들의 목소리를 대변하며 끝까지 소신을 지켰는지 알지 못하고, 대통령이라는 자리에 올라 어떤 일을 해냈는지 알지 못하고, 단지 아는 것이라곤 그저 내 고향에서는 Fuck You로 상징된다는 것밖에 없던 당신에게...
이제서야 감히, 부끄러운 제가, 염치 불구하고 이렇게 말씀을 드립니다.

정말 죄송합니다.
그리고 감사했습니다.

1. 기준

내가 리뷰를 위해 게임을 고르는 기준은 여러 가지가 있다. 무엇보다 가장 우선하는 기준이 '재미'라는 건 두말하면 입이 아플 테고... 그 중에서 은근히 중요한 기준으로, '어떤 면에서 써킹할 수 있나'는 사항이 있다. 아무리 게임을 소개한다고는 해도, 그냥 '재밌다. 해봐라' 라고만 적기보단 '이런 점이 특히 재밌다. 그러니까 해봐라.' 라고 '포인트'를 잡아서 쓰는 편이 더 설득력 있으니까.
오늘 리뷰할 게임을 지금껏 리뷰하지 않은 이유가 바로 그 때문이다. 결론부터 말하면, 이 녀석은 '재미'라는 면에서는 지금껏 소개한 그 어느 게임 못지 않게 빼어나다. 그런데 저 '포인트'의 기준에서 봤을 때는 이게 참 애매하다. 분명 재미있기는 한데, 딱히 "이런 면에서 정말 너무 훌륭하기 때문에..." 라고 말하기가 살짝 난감하다. 왜 그런지, 오늘 리뷰할 게임 Zeliard를 일단 봐보자.

2. 기억

대부분 재미있게 한 게임은 첫 만남에 대한 기억이 생생하기 마련이다. '원숭이 섬의 비밀'은 잡지에서 처음 게임에 대한 기사를 접한 후, 앞뒤 볼 것 없이 바로 게임을 샀었고, '페르시아의 왕자' 같은 경우는 컴퓨터 학원에서 다른 친구들이 하는 것을 보고 감동을 받아서 카피... 했고... (이땐 어려서... 반성하고 있으니 넘어갑시다-_-;;) 여튼 왜 이 게임을 하게 되었는지를 쉽게 떠올릴 수 있고, 보통 리뷰를 쓸 때도 대충 그 기억을 주절주절 늘어놓으면서 서두를 이어나가기 마련이다. 하지만 이 Zeliard는 대체 왜, 어떻게 접했는지 기억이 도무지 나질 않는다.

 이걸 보니 뭔가 기억나려 하는 것 같기도 한데...

개인적으로 그 이유가, 이 Zeliard라는 게임의 특징 때문이 아닐까 생각한다. 원래 아주 매운 음식이나 뜨거운 음식은 기억이 나도, 그냥 적당히 맛있는 음식은 기억이 나지 않는 법이니까.
이 젤리아드는 좋게 말하자면 모든 면에서 모난 곳 없이 그럭저럭 괜찮고, 나쁘게 말하자면 두리뭉실하다. 토먼트와 같은, 정말 사람을 무릎 꿇게 하는 스토리가 있는 것도 아니고, 바이오쇼크처럼 최고의 그래픽과 연출을 자랑하는 것도 아니다. 즉, 재밌게 게임을 플레이할 수는 있지만, 어느 한 부분이 대단히 빼어나다고 말하기는 어렵다.

 당시에는 '최고 수준'의 그래픽이긴 했다. '최고의' 그래픽은 아니었지...

자, 그래서 이 Zeliard란 게임은, 뭐 모든 면에서 그냥 적당한, 그저 그런 게임이란 얘기일까?
물론 그렇지는 않다. 처음 Zeliard를 어떻게 접했는가에 대한 기억은 없어도, 얼마나 열심히 했는가는 생생히 기억난다. 중학교 때, 여름 방학을 싸그리 이 게임의 엔딩을 보기 위해 투자했을 정도니까. 당시 공략집을 찾을 수가 없어. PC통신 하이텔 등에서 Q&A만을 참조해 끝판까지 간 눈물겨운 기억이 난다. 나중엔 맵이 워낙 복잡하고, 난이도가 높아지는 탓에 맵을 매번 그려가면서 플레이하곤 했다. (개인적으로 정말 이건 너무했다 싶었던 두 가지가 있다. 첫째는 점프를 하다보면 기류를 타고 휘리릭 흘러가는 공중부양 퍼즐. 나머지 하나는 하나의 문이 둘 이상으로 이어지는 부분.)

 대체 이런 걸 어떻게 예상한단 말인가...-_-

정말 당시 방학이 아니었다면 지금 인생이 바뀌지 않았을까 싶을 정도로 열심히 했었다. (디아블로와 스타 때문에 인생이 바뀐 그 많은 사람들이 떠오르는군요.) 아무튼, 나는 예나 지금이나 게으른 인간이다. 학교에서 영어 단어도 절대 쓰면서 외우진 않던 놈이, 대체 왜 연습장을 사서 빽빽하게 지도를 그릴 만큼 열심히 이 게임을 했겠는가?
이젠 너무 뻔한 대답이라서 좀 미안할 지경이지만-_- 재밌기 때문이다.

3. 혼합

Jack of all trades is master of none. 유명한 속담이지만 게임은 사람이 아니다.
차라리 나는 게임을 음식에 비유하고 싶다. 얼마나 맛있느냐가 그냥 장땡이니까. 훌륭한 한 가지의 재료의 특성을 잘 살린 요리가 있다면, 무난한 여러 재료들이 조화롭게 섞여 맛을 내는 요리도 있는 법이다. 이 Zeliard는, 후자에 가까운 게임이다.
이런저런 재료들이 서로 부대끼지만 않는다고 해도, 즉, 1+1이 2만 나오더라도 그 게임은 어느 정도 재미있게 즐길 수 있다. (게임이 원래 재밌자고 하는 거니까...) 그리고 이 Zeliard라는 게임은, 1+1이 2를 훌쩍 넘어갈 수 있음을 증명하는 좋은 예시다.
우선 Zeliard의 장르부터 확인해보자. 이 녀석의 장르는 횡스크롤 액션 RPG이다. 장르부터 뭔가 짬뽕 혹은 비빔밥의 냄새가 난다. 그 유명한 YS와 같은 장르다.
그리고, 흔히 알려진 최초의(최초로 성공을 거둔) 액션 RPG이기도 하다.

사실 게임을 소개할 때, '최초'라는 것에 큰 의의를 두지는 않는 편이다. 도대체 게임에서 최초인 게 뭐가 중요한가, 어쨌든 게임은 재미있으면 장땡인데. 그리고 게임은 대부분 '최초'보단, 최초의 시행 착오를 거친 이후의 결과물들이 더욱 훌륭한 경우가 많이 있다. 1편을 능가하는 그 수많은 2편들이 있지 않은가. (대항해시대 2, 창세기전 2, 프린세스 메이커 2, 삼국지 2, 등등...)
하지만 액션 RPG라는 장르의 위상을 생각해보면 여기엔 좀 의미를 두어도 될 것 같다. 아니 의미를 좀 두어줘야 한다. 이 장르가 어떤 장르인가? 바로 디아블로 아닌가. 요즘 나오는 온라인 게임의 태반은 기본적으로 액션 RPG이다. 한국의 게임 산업을 지배하고 있는 그 많은 온라인 게임들은 모두 결국 Zeliard의 자식인 것이다. 게임계에서 족보 따위는 별로 의미가 없지만, 액션 RPG의 시조 정도면 인정해줄 만한 것 아닌가.

이 녀석도 젤리아드의 증증손자쯤 될지도,,.

약간 빗나간 얘기지만, 액션 RPG라는 이름 자체는 조금 우습기도 하다. 액션 RPG의 특성상 대부분 1인을 조종하는데, 혼자서 무슨 Role을 Play한단 말인가... 뭐 이미 RPG라는 장르는 성장의 유무로 구분하는 것이 관례가 되었으니 일단 넘어가자.
자, 그럼 다시 Zeliard의 게임 자체의 얘기로 돌아오자. 아무리 뼈대 깊은 가문의 시조였다고 해도 지금 와서는 아무 소용 없다. 이 Zeliard는 그래서, 액션 RPG의 시조라는 그 간판 말고 뭐 어떤 훌륭한 점이 있냐고?
일단 액션이라는 장르가, 더 나아가서는 사실 거의 모든 게임이 갖춰야 할 가장 큰 덕목이 있다.
그렇다. 바로 타격감이다.

 특히 사운드가 압권.

이 Zeliard는 수준 이상의 타격감을 보여준다. 단순한 Hack & Slash로 처음부터 끝까지 밀고 나가지만, 그다지 지루함을 느끼지 않을 정도이다. 주인공 Garland가 휘두른 칼에 몹들이 맞아 'ALMA'로 분해되는 연출은 시원시원하고 호쾌하다. 조금 단조로울 수 있는 단순한 칼 위주의 근접전에, 장거리 공격을 시도할 수 있는 마법이라는 요소를 첨가해 맛을 냈다.

 마법 공격의 타격감은 정말 시원하다.

마법 얘기가 나왔으니, RPG의 요소인 성장 얘기를 안 할 수가 없다. 이 게임은 보스를 하나 넘길 때마다 새로운 마을을 발견하게 되고, 그에 따라 새로운 마법을 획득하게 된다. 이 마법들은 나름 의미도 있고 개성도 있고 뽀대도 나고 위력도 있다. 그야말로 '필살기'라는 명칭이 잘 어울린다. 특히 마지막으로 얻는 마법은 최종 필살기답게, 그냥 화면 전체를 뒤덮는다.

근데 이펙트는... ㅋ... 뭐 모든 면에서 완벽할 수 있나요...

이러한 마법의 획득과 더불어 게임의 풍미를 돋구는 것이, 개성 있는 보스전이다. 총 화면 상단의 9개의 보석 숫자만큼 존재하는 보스들은, 제각각 패턴이 다양해 단순히 똑같이 칼을 휘두르는 식으로는 잡기 어렵다. 어떤 보스들은 점프를 통한 공격으로 데미지를 주어야 하고, 어떤 보스는 마법을 잘 써서 타격을 줘야 잡기 수월한 등등. 다양한 방법으로 패턴을 풀어야 한다.

 간장게장...

패턴 얘기가 나왔으니, 이 Zeliard의 가장 큰 매력인 동시에 가장 큰 짜증 유발 요소인 길찾기 얘기를 하지 않을 수가 없다. 대부분의 RPG가 그렇듯, Zeliard 역시 던전을 헤매는 게임이고, 미로를 잘 통과해 올바른 곳으로 향하는 길찾기가 대단히 중요하다.
Zeliard는 액션 RPG답게 이 길찾기에 많은 공을 들였고 잘 만들어냈다. 발판을 연이어 건너는 부분이나, 줄을 타고 이동하는 부분, 혹은 적절한 점프를 통해 이동하는 부분 등등. 사방이 막힌 곳이 없이 연결되어 있고, 맵의 이동은 문을 통해서만 이루어지기 때문에 이러한 길찾기 패턴을 다양화할 수 있다. 이러한 액션의 요소들을 이용한, 다양한 길찾기의 패턴은 Zeliard가 주는 재미의 핵심이다.

 뭐... 앞서 얘기했듯 이런 요소들은 짜증을 유발하기도 한다. -_-

RPG의 핵심 요소 중 하나가 길찾기라면, 다른 핵심 요소 하나를 언급하지 않을 수 없다. 스토리...

어디선가 본 것만 같은...

 

사실 이 Zeliard는 뭐... 스토리는 별로 볼 게 없다. 보스전에 대처하는 재미나, 마을 사람들이 던지는 농담 등이 잔재미를 주는 정도다. 

 

뻔하지만 왠지 멋있어...

그러나 이 스토리에, 모든 면에서 그냥 훌륭한 Zeliard에서 정말 빼어난 요소 하나가 첨가되면 얘기가 조금 달라진다. 바로 음악!
Zeliard의 음악은 대단히 아름답다. 심지어 Zeliard의 이 단조롭고 전형적인 스토리를 즐길 수 있게(!) 해준다. 게임이라는 매체는 패턴 해결을 그 골자로 삼기 때문에, 반복적인 작업을 많이 시도할 수밖에 없고, 이러는 가운데 계속 귀에 울려퍼지게 되는 '음악'의 중요성은 더 말할 나위도 없다.
Zeliard의 음악을 이 시점에서 한 단어료 표현하자면 다음 말 외에는 떠오르질 않는다. 화룡점정. 정말 훌륭한 짬뽕에 마지막으로 첨가하는 미원 한 숟가락처럼... 이 Zeliard를 잊혀지지 않는 훌륭한 게임으로 완성시키는 요소다.
이처럼 많은 요소들이 잘 어우러진 Zeliard라는 요리는, 뭐 하나 특출난 것은 없다고 해도, 결코 잊을 수 없는 맛을 선사한다.

4. 해봐

Jack of all trades don't need to be master. 그는 그걸로 그냥 충분하다.
그러니까, 다운받아서 해보시라.
재밌다.

1. Idea

2. Lemming?

레밍Lemming이라는 건 대체 무엇일까?
사전적 의미로 말하자면, 레밍이란 나그네쥐라고도 불리는 쥐의 일종이다. 북유럽 등에 분포하며, 크기는 별로 크지 않은 등등. 다른 쥐들과 차별되는 이 녀석들의 핵심적인 특징은 바로 '집단 자살'이다.
레밍은 쥐답게 시간이 흐르면 개체수가 급격히 증가한다. 그러다 그 수가 감당할 수 없을 만큼 불어나면 단체로 자살을 택한다고 한다. 재미있는 것은 그 방식이다. 팔목을 물어뜯거나 목을 매는 그런 것이 아니다.
이 레밍들은 죽음의 순간 직선을 이루는 줄을 길게 서서, 바다로 향한다. 그리고 선두의 쥐부터 바다 속으로 걸어들어간다. 나머지 쥐들은 차례차례 한 마리씩 그 뒤를 따르는 것이다. 얼핏 보면 실소가 나올 만큼 바보 같은 행동이다. 그러나 바꿔 생각해 보면 매우 섬뜩한 광경이기도 하다. 수많은 생명들이 맹목적으로 자살을 택하는 모습이라니.

생긴 건 귀여운데...

확실한 것은, 이러한 광경은 자연에서 보기 드문 현상임과 동시에 은유를 내포하기 쉬운 현상이라는 것이다. 그래서 일상 생활에서도 곧잘 인용되는 이 유명한 용어가 탄생했다. 레밍 현상Lemming Suicide. 맹목적인 쏠림 현상으로 주로 사용되는 용어이다.
사실 이러한 레밍 현상은, 잘못 알려진 통설이라고 한다. 숫자가 늘어난 레밍들은 그냥 마찬가지로 숫자가 증가한 천적들에게 먹혀서 줄어드는 것뿐이라고 한다. 본인들의 의지와 다르게 맹목의 대명사로 사용되는 레밍들은 조금 억울할지도 모르겠다. 하지만 인간들이 하는 대부분의 일이 그렇지 않겠는가? 이미 레밍 현상이라는 말이 널리 쓰이고 있는 이 시점에서, 레밍이 실제로 자살하느냐, 족제비의 먹이가 되느냐 하는 문제는 중요하지 않다. 그런 특이하고 재미있는 현상이 존재한다는 사실이 중요할 뿐.

얘도 생긴 건 참 귀여운데...

즉, 여기서 핵심 키워드는 바로 이거다. '특이하고 재미있는'. 다른 것들과 구별되어 시선을 잡아끄는 동시에, 그 자체로 재미를 줄 만한 것. 이러한 형용어구가 잘 어울리는 것은 무엇일까?  바꿔 말하면, 이 현상은 어디다 써먹으면 참 좋을까?
그렇다. 바로 게임이다.
이러한 레밍 현상을, 기발한 아이디어로 승화시켜 게임으로 탄생시킨 것이 바로 [레밍즈]이다.

3. How?
 
자, 그러면 [레밍즈]는 어떠한 형태로 이 레밍 현상을 게임화했을까? 우선 자유롭게, 이를 모티브로 만들어낼 만한 게임들을 한번 생각해보자.
여러 가지를 떠올릴 수 있다. 레밍이 자살하는 이유를 찾아 세계를 헤매는 어드벤처 게임. 레밍들이 자살하지 않도록 개체수를 조절하며 번식하도록 하는 시뮬레이션. (이놈은 심앤트SimAnt와 비슷해지겠구나...) 자살하는 레밍들 뒤를 쫓는 족제비를 조종하는 액션 게임. 혹은 자살하지 않고 난 누군가, 쥐란 무엇인가 고민하며 무럭무럭 레벨업을 해 족제비를 이기기도 하는 레밍즈 게이트...

행성 파괴 무기다. 가끔 나는 RPG처럼 성장할 수 있다면 인간이 우주를 지배할 거라고 생각하곤 한다.

여러 가지 안이 나올 수 있다. 하지만 기본적인 것을 한번 생각해보자. 게임이라는 것은 직관적이어야 한다. 이 현상의 핵심은 무엇인가? 그렇다. 줄을 지어 바다로 들어가는 레밍즈의 맹목적인 '행동' 그 자체이다.
이 [레밍즈]는 바로 그 사실에 주목했다. 그리고 그 단순한 행동을 가장 잘 표현하기 위해서 [레밍즈]가 택한 장르는 바로 '퍼즐'이다.

4. Puzzle

퍼즐이라는 장르는 가장 유서 깊은 게임 장르 중 하나이다. 그렇기 때문에, 게임의 본분에 가장 충실한 장르이기도 하다.
실제로 레밍 현상에서 볼 수 있는 레밍들의 행동은 단순하다. 그런 레밍들의 행동을 직관적으로 게임으로 표현하려면, 복잡한 스토리나 민첩한 조작 따위는 필요하지 않다. 감성에 호소하거나 반사 신경을 요구할 이유가 없는 것이다.
레밍즈의 목표는 아주 단순하면서도 명쾌하다. 가만히 놔두면 죽거나 헤맬 레밍즈를, 출구로 옮기는 것. 어떻게? 가만히 놔두면 오로지 직진만을 반복하는 레밍들에게, 특정한 행동을 지시함으로써.
매우 쉽기 때문에 여기서 스샷을 올려서 설명해도 큰 무리가 없을 1번 스테이지를 예로 들어보자.

레밍들은 저렇게 떨어져 내려와 직진하기 시작한다. 놈들은 가만히 놔두면 평생 동안 직진하며 반복한다. 그나마 1번 스테이지는 나은 편이다. 다른 스테이지에 가면 시작하자마자 바다를 향해 걸어가 빠져 죽거나, 낭떠러지에서 떨어져 죽거나, 불에 타 죽거나... 여튼 아주 다양하게 죽는다. 그야말로 레밍 현상을 아주 직관적으로 표현하고 있다.
각설하고, 놈들을 출구로 옮기려면 어떻게 하면 될까? 그 방법을 고민하는 것이 바로 우리가 해야 할 일이다. 1번 스테이지는 쉬우니 답을 말하자면, 저 녀석들 중 하나를 시켜 땅을 파게 하면 된다.

그렇다. 이렇게 땅을 팜으로써 닫혀 있던 공간을 열리게 하며, 출구로 갈 수 있는 경로를 생성하게 된다. 이게 정답이다.
이 게임의 골자는 극히 단순하다. 가만히 놔두면 직진만 하는 맹목적인 레밍즈들을, 출구로 옮기려면 어떻게 해야 할까? 이에 대한 대답을 요구하는 것이다. 출구까지 가는 길 만들기. 막혀 있다면 뚫고, 끊겨 있다면 새로 긋고, 떨어져 있다면 연결하고, 방향이 잘못되었다면 길을 막아서 돌아가게 하는 등등의 방법으로. 이 쥐들은 선두의 쥐를 따라 직진하므로, 하나의 방향을 지닌 직선으로 파악할 수 있다. 이 직선을 출구까지 연결하는 것. 이 패턴을 해결하는 것이 바로 레밍즈의 핵심이다.

라프 코스터의 재미 이론에서 언급된 것처럼, 게임이라는 것은 지루하지 않게 패턴을 지속적으로 제공하는 작업이다. 게임이 너무 어려워도, 혹은 너무 쉬워도, 그 게임을 플레이하는 게이머는 금세 질려버리기 마련이다.
이 [레밍즈]는 이러한 패턴을 매우 흥미롭게 제공한다. 각종 레벨은 즐길 만한 가치가 충분하도록 만들어져 있다. 또한 새로운 형태의 길을 잇는 방식을 지속적으로 제공함으로써 지루하지 않도록 해준다. 게임의 방식에 조금씩 익숙해지도록 해, 난이도를 점진적으로 상승시킨다. 게이머로 하여금 도전 의식을 계속 불태우게 한다. 그 오묘한 난이도 조절을, [레밍즈]는 멋지게 해냈다.
패턴을 푸는 퍼즐 게임으로서, [레밍즈]는 충분히 재미있다.

5. Fantasy

하지만 이러한 패턴 해결이 [레밍즈]의 전부라고 말한다면, 조금 섭섭할 것이다. 패턴 해결이 게임의 전부라고? 그렇다면 이 게임을 완벽하게 패턴화시켜보자. 위 1번 스테이지를 단순화하면, 다음과 같은 그림을 그릴 수 있다.

그림이 조잡하지만 이해해 주시리라 믿습니다. -_-;

즉, 이런 녀석을

가운데를 뚫어서 길을 냈음...

이렇게 만드는 것이다.
자, 핵심은 이렇다. 좀 극단적이긴 하지만, 이 게임이 위의 허접한 그림과 같은 형태로 제공되었으면 어떨까? 지금처럼 재미있을 거라고 말할 수 있을까? 결코 그렇다고는 말할 수 없다. 왜 그럴까? 패턴화시킨 것이니 어차피 골자는 같은데?
그 이유는, 패턴을 포장하는 환상Fantasy이 다르기 때문이다.
패턴을 해결하는 능력은, 개인의 능력이나 성향 등에 따라 차이가 있다. 그래서 단순히 패턴만을 제공하는 퍼즐만으로 재미를 주는 것은 상당히 까다롭다.
하지만 이 퍼즐에, 환상을 덧붙인다면?
슈퍼 마리오를 예로 들어보자. 마리오의 본질은? 걷고 달리고 점프함으로써 목표점까지 도달하는 게임이다. 패턴화를 해보면, 끊어진 선과 선을 이어 가며 장애물을 피하고 만들고 없애는 행동들의 집합으로 표현할 수 있다. 하지만 그 귀여운 그래픽, 산뜻한 음악, 천재적이라고 칭찬하고 싶은 사운드 등이 마리오 월드라는 매력적인 세계를 구축하면서, 슈퍼 마리오는 전설적인 게임으로 자리매김했다.
이처럼, 골자는 같아도 그에 붙인 육의 풍성함이 다르다. 그에 따라 볼품 없이 뼈만 남은 스켈레톤도 될 수 있고, 육감적인 몸매를 뽐내는 미녀도 될 수 있다.
그게 바로 게임이다.
자, 그러면 여기서 [레밍즈]로 돌아와보자.
레밍즈의 패턴은 출구 찾기 게임이라는 한 마디로 설명할 수 있다. 하지만 이 게임에 빠져들게 하는 원동력은 그 한 마디만으로는 너무나 불충분하다. 귀여운 레밍즈들의 생김새. 멍청하고 바보 같지만 어딘지 모르게 정감 가는 움직임. 퍼즐의 일부가 되는 작은 동작 하나하나마다 신경 써서 만들어놓은 애니메이션. 이 귀여운 쥐들을 보다 보면, 왠지 모르게 얘네들을 살려야 할 것 같은 느낌이 든다. 이런 느낌, 무언가 속고 있다는 느낌. 이건 바로 환상이다.

정말로 살리고 싶어진다.

레밍 현상이라는 그 단순하고 바보 같은, 어찌 보면 미련하지만 한편으로는 피식 웃음이 나오게 하는 역설적인 자연 현상.
그 현상을 고스란히 환상이라는 요소로 실어내, 잘 만든 퍼즐을 풍성하게 살찌운 게임.
그것이 바로 [레밍즈]다.

6. Lemmings

잡설이 길어서 스크롤을 내린 분을 위해 친절하게 요약하겠다.

레밍즈는 매우 잘 만든 패턴을 지닌 퍼즐 게임이다. 하지만 그 패턴을 포장하는 환상이라는 요소가 뒷받침되지 않았다면 이렇게까지 성공하지는 못했을 것이다. 폭발적인 인기와 함께 수많은 후속작을 양산했고, 지금까지도 레밍즈 3d와 같은 게임이 나오며 시리즈가 명맥을 잇고 있으니 말이다.
언제나 내 리뷰가 그랬듯, 마지막은 이 말로 끝마치겠다.

해보지 않겠는가?