조건과 이벤트

최근에 이전까지 개발된 게임 상에서 어떤 행동을 할 때 확인해야 할 조건들이 서로 다른 기능에 흩어져 있어 엔지니어들이 이들을 단일 기능으로 통합하기를 원해 작업을 지원한 적이 있습니다. 제 관점에서는 플레이어가 어떤 행동을 요청할 때 이 행동을 해도 되는지 확인하기 위한 여러 가지 조건들은 보통 게임 전체에 걸쳐 거의 똑같은 조건 목록이 사용되곤 해 왔기 때문에 어쩌다 보니 이 기능들이 서로 다른 시점, 서로 다른 사람에 의해 개발되다 보니 곳곳에 서로 다른 기능에 근거해 흩어져 있었고 이를 하나의 목록과 하나의 데이터에 기반한 기능으로 정리하면 되는 완전히 말이 되고 또 완전 단순한 일이라고 생각했습니다.

여느 게임에서 비슷한 기능을 사용하려 할 때 항상 사용되던 기능을 나열한 메모를 만들어 놓은 다음 게임 상의 여러 기능에 걸쳐 흩어져 있는 조건들을 찾아 살펴봤는데 제가 미리 만들어 놓은 목록과 별로 다르지 않았습니다. 다른 점이 있다면 저는 모든 조건을 하나의 목록에 나열해 놓고 있었던데 비해 게임의 각 기능이 확인하는 기능들은 각 기능이 개발될 때 요구사항에 언급된 기능만을 확인하고 있었다는 점입니다. 이 상태로도 겉보기에 게임은 아무 문제 없이 동작하겠지만 조건을 추가하거나 삭제하려 할 때 필요 이상으로 일이 복잡해질 수 있었고 또 게임이 계속해서 개발되어 감에 따라 같은 값을 과거의 방식으로 평가하거나 최신 방식으로 평가하는 차이에 의해 의도하지 않은 결함이 생길 가능성도 있어 시간이 더 흐르기 전에 이들을 통합하는 것은 의미 있는 의사결정이었습니다.

상황을 조금 더 살펴보면 기반 장르가 MMO인 여러 게임에는 플레이어의 요청에 따라 수행 여부를 결정하는 여러 가지 행동이 있습니다. 가령 던전에 들어가기 위해 던전 입구와 상호작용 할 때 플레이어가 던전이 요구하는 조건을 만족하는지 확인한 다음 던전에 입장 시켜 주는 것, 플레이어가 던전에서 어떤 문을 열려고 할 때 이 문이 열려도 되는 상황인지 확인한 다음 문을 열어 그 다음 플레이를 진행할 수 있도록 하는 것, 또 필드에서 어떤 약초를 수집하려 할 때 그 약초를 수집하기 위해 필요한 조건을 갖추고 있는지 확인한 다음 채집 행동을 시작하는 것 등이 여기에 해당합니다. 사실 이들은 모두 거의 똑같은 기능이지만 각 기능이 개발되는 시점, 개발에 관여한 사람들의 역할 등에 따라 이들이 사실 완전히 똑같은 기능이라는 사실을 눈치 채지 못하고 그냥 제각각 개발하게 될 수 있습니다.

누군가 초반에 약초를 만들고 약초를 채집하는 요구사항을 나열한 기획서에 기반해 개발을 진행했다고 해 봅시다. 약초는 이제 앞으로 게임에 추가될 여러 가지 상호작용 가능한 대상을 대표해 개발되었을 테고 약초 자체에는 지금 당장 썩 필요하지 않은 여러 기능을 함께 예상해서 개발되었을 가능성이 높습니다. 약초는 앞으로 앞서 설명한 문, 스위치 같은 다양한 물건을 대표하는 상호작용 가능한 물체로 약초에는 필요하지 않은 열려 있거나 닫혀 있는 상태 구분, 상태에 따라 서로 다른 에셋을 사용해 표현되는 기능, 서로 다른 상태로 전환될 때 일정 시간에 걸쳐 애니메이션을 재생하는 기능 등을 함께 포함하게 되는데 덕분에 약초 자체의 기능은 단순하지만 미래에 이와 비슷한 행동을 할 지도 모르는 물체에 예상되는 기능을 포함해 요구사항을 정의하기 꽤 어려웠을 겁니다. 어떻게 이렇게 빨리 만들었나요?에서 이런 상황에 개발 비용을 극도로 낮추는 방법을 소개했지만 기반 장르가 MMO인 개발팀에서 뻔히 예측 가능하다고 생각하는 미래를 무시하고 이런 방법을 사용하기는 어려울 것 같습니다.

그런데 약초를 개발하는 시점과 조금 다른 시점에 던전 입구에 상호작용 하면 조건을 확인한 다음 던전에 들여보내 주는 기능을 개발하려 한다면 사실 이 기능은 이미 개발 중이거나 개발이 완료된 약초 기능에 기반해 상호작용의 결과로 정해진 위치인 던전 내부로 이동하거나 이동에 실패하는 동작을 추가하기만 하면 되니 그리 큰 일이 아닐 가능성이 높습니다. 하지만 이런 기능들이 사실 서로 거의 똑같은 기능이라는 사실을 인식하지 못하는 사람이 기획서를 작성하기 시작했거나 약초라는 기능에 대한 요구사항이 개발 중이라는 사실이 잘 공유되지 않은 상황이라면 불행하게도 던전 입구의 상호작용 기능을 개발하려는 사람은 약초와 비슷한 요구사항을 하나하나 언급한 문서를 작성하게 됩니다. 사실 이렇게 문서를 작성하더라도 문서를 검토하는 사람, 문서의 요구사항을 개발하는 사람 등등이 각 단계에서 이미 누군가 상당히 비슷한 다른 작업을 이미 수행했거나 이미 수행 중이라는 사실을 떠올리기만 하면 완전히 새로운 기능처럼 보이는 던전 입구의 동작이 사실 그리 큰 일이 아니라는 사실을 확인하고 기획서 단계에서 발견했다면 이미 준비된 기능에 작은 사용 사례를 추가하는 수준에서 끝나거나 개발 단계에서 발견했다면 이미 작성된 기능을 끌어다 사용해 예상보다 훨씬 빨리 개발하는 수준에서 끝날 수도 있습니다. 하지만 이런 어느 단계에서도 겉모습이 다를 뿐 거의 같은 기능이 서로 다른 이름으로 개발되고 있다는 사실을 눈치 채지 못하면 거의 같은 기능을 하는 서로 다른 코드가 작성되고 절약할 수 있었을 개발 비용을 낭비하는 결과를 초래하며 근미래에 게임에 계속해서 개발 되어 가면서 비슷한 상황에 결함이 나타날 가능성이 늘어나고 결함을 해결할 난이도 역시 증가하는 썩 바람직하지는 않은 상태에 놓이게 됩니다.

이전에 한 수집형 게임을 만들 때 평소에는 일어나지 않았지만 새 계정을 만들어 처음부터 플레이를 시작하면 특정 스테이지에서 획득해야 할 보상이 인벤토리에 들어오지 않는 결함이 있었습니다. 일단 한참 게임을 플레이 하던 계정으로는 이 결함을 재현할 수 없어 분명 저는 결함이 일어났다고 보고했지만 QA 부서에서는 결함을 재현할 수 없다고 지라를 저에게 다시 돌려보냈는데 저는 재현 시나리오에 따라 새 계정을 만들어 테스트 하면 항상 문제를 재현할 수 있었습니다. 그래서 이번에는 아주 주의 깊게 계정을 생성하는 단계부터 재현 시나리오를 정확히 작성해 다시 보냈고 이번에는 결함을 재현할 수 있었습니다. 엔지니어들이 확인한 결함의 원인은 인벤토리에 아이템을 직접 꽂아 주는데 사용하는 함수를 사용할 때 인벤토리가 초기화 된 상태인지 확인하는 코드를 포함한 새 함수를 사용하도록 어느 시점에 규칙이 변경되었는데 이 규칙이 나타나기 전에 작성된 코드는 이전 함수를 사용해 인벤토리에 아이템을 넣고 있었습니다. 이전에 작성된 함수는 인벤토리가 초기화 되었는지 여부를 확인하지 않고 냅다 아이템을 인벤토리에 넣으려고 시도하는데 이전에 플레이 한 적이 있어 이미 초기화된 인벤토리를 보유한 계정에서는 결함이 재현되지 않았지만 계정을 새로 만들어 인벤토리가 정상적으로 초기화되지 않은 상태일 때 이전에 작성한 함수를 사용해 인벤토리에 아이템을 넣으려고 시도하면 조용히 실패한 다음 아무 응답도 하지 않는 동작을 하고 있었습니다. 결국 똑같은 인벤토리에 보상을 넣는 코드에 사용된 오래된 함수를 새 함수로 변경하는 간단한 조치로 결함이 수정되었고 또 게임 코드 전체를 뒤져 오래된 함수를 사용하는 부분을 모두 찾아내 수정하고 오래된 함수를 제거하는 것으로 상황이 일단락 됩니다. 이 사례는 게임 상에서 비슷한 기능을 수행하는 코드가 여러 곳에 분산 및 중복되어 있을 때 이들의 작은 차이로 인해 결함이 발생할 수 있다는 교훈을 줍니다.

이런 미래에 발생할 고통스러운 문제를 미리 피하기 위해 앞서 예를 든 던전 입구, 문, 약초를 개발할 때 제각각 작성된 조건을 판단하는 코드를 하나로 합치기로 하고 각각이 합쳐지기 전과 합쳐진 다음의 동작, 데이터 형태 따위를 정의하는데 관여했습니다. 엔지니어들에게 설명하는 일은 단순했습니다. 그저 조건 데이터를 통합하고 통합하기 전에 하던 동작이 통합된 다음에 변경되거나 유지되어야 할 모양을 판단한 다음 이를 요구사항으로 정의해 전달하기만 하면 됐습니다. 그런데 오히려 이런 일이 진행되고 있고 이 일이 진행된 다음에는 서로 분산해 작성하던 조건을 같은 데이터에 작성한 다음 이를 연결해 사용해야 한다는 점을 미리 공지하자 제가 속한 게임디자인 부서 안에서 일어납니다. 어떤 문제가 발생했다기 보다는 제가 여러 곳에 분산되어 있던 조건을 한 곳으로 통합해 사용하게 된다는 공지를 하고 얼마 지나지 않아 그게 뭐가 됐든 게임 상에 어떤 ‘조건’이라는 말이 나타나기만 하면 그 상황에 해당하는 데이터를 이 작업에서 통합한 조건에 포함해야 한다고 생각하고 저에게 문의하는 사람들이 한가득 나타났습니다. 이들 중 일부는 실제로 제가 관여한 게임 곳곳에 흩어져 있던 조건 데이터를 한 곳으로 통합한 일과 관련이 있었기 때문에 제가 대응할 수 있었지만 나머지는 조건과 이벤트를 혼동해 이벤트를 마치 조건의 일부인 것처럼 생각하고 이를 통합된 조건 목록에 추가해야 한다고 생각하고 저에게 찾아온 것이었습니다. 이런 잘못된 이해에 기반한 업무 처리 시도에 몇 번 대응하며 조건과 이벤트의 차이를 여러 번 서로 다른 사람에게 설명하다가 도대체 이게 어디부터 잘못된 것인지 곰곰이 생각해보다가 조건과 이벤트의 개념을 구분하지 않고 요구사항을 작성한 사례가 꽤 많다는 점을 알게 됩니다.

‘조건’의 정의를 사전에서 찾아보면 ‘어떤 일이 이루어지려면 갖추어져야 할 상태나 요소’라고 되어 있습니다. 여기서 ‘갖추어져야 할 상태나 요소'에 집중해 이해하기 쉬운데 조건의 또 한 가지 중요한 부분은 앞쪽의 ‘어떤 일이 이루어지려면 갖추어야 할’입니다. 이 정의는 조건이 어느 시점에 평가되어야 하는지, 또 우리가 이전에 재정의하고 통합한 조건이 어떻게 동작하는지를 설명하는데 도움이 됩니다. 조건은 ‘갖추어져야 할 상태나 요소’이기도 하지만 동시에 ‘어떤 일이 이루어지려면’의 ‘어떤 일’을 정의하는 것 역시 중요합니다. 앞서 비슷한 기능을 제각각 개발하는 사례로 약초, 던전 입구, 문 같은 것들을 나열했는데 이들 각각이 조건에 따라 동작하는 결과가 바로 ‘어떤 일이 이루어지려면’의 바로 그 ‘어떤 일’인데 이 ‘어떤 일’들의 특징을 살펴보면 조건이 어느 시점에 필요해지는지 알 수 있습니다. 약초는 플레이어가 이를 채집하려고 할 때, 던전 입구는 플레이어가 여기에 진입하기 위해 상호작용을 시도할 때, 문 역시 플레이어가 문을 열거나 닫기 위해 상호작용을 시도할 때 조건이 필요해집니다. 조건은 플레이어에 의해 요청된 행동을 수행할지 여부를 판단할 때 사용되며 플레이어가 요청하지 않는 한 조건을 판단하지 않습니다. 또한 이 조건들은 플레이어의 요청에 의해 판단을 수행함과 동시에 플레이어의 요청이 일어난 그 시점에 즉시 판단할 수 있는 요소로 구성해야 한다는 점 역시 약초, 던전 입구, 문 사례로부터 짐작할 수 있습니다.

그러면 이제 제 관점에서 조건의 정의를 잘못 이해하고 저를 찾아온 분들의 사례를 조금 살펴보겠습니다. 먼저 던전의 실패 조건이 있습니다. 어떤 던전을 플레이 하다가 던전 클리어에 실패할 조건을 나열하고 이 조건 중 하나 이상을 만족하면 던전을 실패한 것으로 간주하고 플레이를 중단 시킨 다음 플레이어들을 던전 밖으로 내보내는 동작을 준비하고 있었는데 여기에 ‘던전 실패 조건’을 앞서 통합한 조건에 포함해야 한다고 생각한 것 같습니다. 겉보기에 던전 실패 조건을 살펴보면 이들은 앞서 살펴보면 조건 목록과 별로 다르지 않아 보입니다. 모든 플레이어가 죽은 상태일 때, 제한시간이 끝났을 때, 던전 입장권을 모두 소진했을 때 같은 것들이었는데 이들은 언뜻 보면 조건 목록에 추가하고 이들 중 하나 이상을 만족할 때 던전을 실패 처리하도록 만들어 달라는 요구사항을 작성해도 이상하지 않을 것 같습니다. 하지만 조금 들여다보면 크게 두 가지 관점에서 이상함을 느낄 수 있는데 먼저 각 조건은 플레이어가 어떤 행동을 요청하는 특정 시점에 판정하는 것이 아니라는 점입니다. 가령 단 한 번이라도 죽으면 클리어에 실패하는 단전이 있을 때 플레이어가 죽은 상태를 앞서 소개한 조건 목록에 추가해 판단하려면 조건을 판정할 어떤 시점이 필요합니다. 가령 약초를 채집하려 할 때 약초 채집 스킬이 5레벨 이상인지 확인하는 조건이 있다면 이 조건은 항상 플레이어가 약초 채집을 시도하는 ‘특정 시점’에 판정합니다. 그런데 던전을 플레이 하던 도중 플레이어가 죽었는지 판정하기 위한 조건을 같은 방식으로 판단하려면 플레이어가 던전을 플레이 하는 내내 단위 시간마다 반복해서 플레이어의 상태를 확인해야 합니다.

가령 1초에 한번씩 플레이어가 죽었는지 확인하고 죽은 상태라면 실패 처리로 넘어갈 수 있습니다. 하지만 이런 동작은 또 다른 문제를 만들 수 있습니다. 먼저 아주 짧은 시간마다 여러 가지 조건을 판정해야 할 수 있습니다. 던전 실패 조건이 플레이어가 죽었을 때 하나 뿐이라면 특정 시점에 근거한 조건 목록을 짧은 단위 시간마다 판단하더라도 별 문제가 일어나지 않을 수 있습니다. 그런데 이런 조건이 늘어나면 매 1초마다 플레이어가 죽은 상태인지, 입장권이 유효한지, 특절 아이템을 가지고 있는지, 특정 퀘스트를 클리어 한 상태인지 등을 계속해서 확인해야 하고 이 목록이 길어질수록 이 확인을 매 1초마다 하기에 부담스러워질 겁니다. 특히 이 던전이 게임 전체에 걸쳐 수 만 개가 있다면 1초마다 이 모든 던전의 실패 조건 판단을 해야 하니 엔지니어 입장에서 이는 그리 만만한 요구사항이 아닙니다. 또 1초는 어떤 조건을 판단하기에 그리 충분한 시간이 아닐 수 있습니다. 만약 던전 실패 조건이 ‘플레이어가 사망한 상태일 때’인데 이를 1초마다 판단한다면 1초보다 더 빨리 동작하는 부활 아이템의 존재가 이 규칙을 망가뜨릴 수 있습니다. 죽었지만 번개같은 동작으로 부활 아이템을 사용해 순식간에 죽은 상태로부터 빠져나오면 매 1초마다 일어나는 상태 확인을 피할 수 있습니다. 이런 일이 벌어질 가능성이 낮기는 하지만 이런 결함을 알고 있는 고객들은 순식간에 부활하면 클리어에 실패하지 않는다는 사실을 깨닫고 이를 활용해 우리가 의도하지 않은 만큼 보상을 가져갈 수도 있습니다.

첫 번째의 ‘판정 시점이 모호한' 문제에 대해 알아봤으니 이번에는 두 번째 문제인 각 조건을 판단하는데 시간이 필요한 상황에 대해 이야기하겠습니다. 저에게 찾아온 또 다른 ‘조건’을 사용하는 사례에는 다른 게임 사례를 들어 닫힌 문 앞에서 노래를 누르면 문이 열리거나 어떤 약초 옆에서 한동안 서 있으면 약초가 채집 가능한 상태로 바뀌는 모양을 만들고 싶어했습니다. 그래서 조건 목록에 ‘노래를 부른다’, ‘한동안 서 있는다’ 같은 조건을 추가하고 싶어했는데 제 관점에서 이들은 특정 시점에 판정 가능한 조건이 아니라 액티브스킬에 더 가까운 모양이었습니다. 먼저 ‘노래를 부른다’를 이전에 통합한 조건에 넣을 수 없는 이유는 이것이 주로 플레이어가 요청한 특수한 시점에 평가할 수 없는 조건이기 때문입니다. 앞서 약초를 채집하려 할 때 ‘약초 채집 스킬’이 있는지 여부를 확인하는데 이 조건 확인은 순간적으로 완료하고 조건에 따라 채집 성공 및 실패 여부를 확정할 수 있습니다. 이 시나리오에서 조건을 판정할 시점과 조건 각각은 시점이 플레이어의 요청에 의한 것이어서 명확하고 또 조건 각각이 이 명확한 요청 시점에 즉시 판단할 수 있는 것들로 구성되어 있습니다. 그런데 특히 ‘한동안 서 있는다’는 조건이라고 부를 수는 있지만 조건으로써 동작하는 메커닉이 완전히 다릅니다. 이 조건은 한동안 서 있는 동작을 통해 어떤 액티브스킬이 사용되고 이 스킬의 사거리 안에 이 스킬에 맞으면 반응하는 특정한 대상이 있을 경우 그 반응이 일어나는 모양으로 만들어야 합니다. 이 ‘시간’의 존재가 조건 목록에 들어갈 수 있는지와 그렇지 않은지를 구분하는 중요한 점이라는 사실을 여러 차례에 걸쳐 서로 다른 사람들에게 설명해야 했습니다.

약초 옆에 한동안 서 있는 동작이 약초를 채집하기 위한 조건이 아니라 일종의 액티브스킬이라는 사실을 이해하면 문 앞에서 노래를 불러 문을 여는 시나리오 역시 완전히 똑같다는 점을 이해할 수 있을 겁니다. 문이 열리기 위한 조건은 문 앞에서 정해진 노래를 부르는 것입니다. 이렇게 표현하면 조건 목록에 ‘노래를 부른다’를 추가해야 할 것 같지만 노래는 플레이어가 요청한 특정 시점이라는 관점에서는 조건 목록에 넣을 수 있을 것 같지만 ‘노래를 부른다’는 행동에 이번에도 ‘시간’이 포함되기에 조건 목록에 넣는 대신 액티브스킬에 가까운 모양으로 만들어야 합니다. 노래를 부르는 행동은 기반 장르가 MMO인 게임에서 상호작용을 주고 받는 가장 일반적인 방법인 ‘스킬 시스템’에 의해 일종의 액티브스킬로 해석되어야 합니다. 노래를 일정 시간 이상 부르면 플레이어로부터 일정 반경 안에 액티브스킬이 사용되고 이 스킬에 맞은 대상이 특정 스킬에 맞을 때 어떤 행동을 하도록 설정되어 있어야 합니다. 이 시나리오에서는 닫혀 있는 문은 주변에서 여러 플레이어에 의한 스킬에 맞고 있다가 ‘노래 부르는 스킬’에 맞으면 그 반응으로 자기 자신을 열어 주는 식으로 동작합니다. 이 관점에서 ‘노래를 부른다’는 시간을 포함하고 있기에 조건 목록에 포함될 수 없고 또 노래가 끝나는 시점을 알아야 하기에 조건을 평가할 플레이어가 요청한 특정 시점을 알아내기도 어렵습니다. 때문에 조건 목록 보다는 액티브스킬로 해석되어 만들어지는 편이 적합합니다. 사실 그러는 편이 더 적합하다고 은근히 표현하기는 했지만 실은 이런 요구사항이 조건 목록에 뒤섞이기 시작하면 애초에 이 조건 목록을 개발한 목적에 어긋나는 모양으로 발전하기 시작해 겉잡을 수 없는 괴물로 변할 수 있으니 조심해야 합니다.

같은 설명을 여러 사람들에게 반복하고 또 같은 설명을 슬랙에 여러 번 반복하면서 대체 왜 이런 잘못된 이해가 발생하는 것인지 생각해봤습니다. 근본적으로 우리가 ‘조건’과 ‘이벤트'를 정확히 구분하지 않고 그냥 ‘조건’이라고 부르기 때문에 발생하는 문제라고 생각합니다. ‘조건’은 주로 플레이어의 요청에 의한 특정 시점에 그 즉시 평가 결과를 알 수 있는 항목들로 구성된 것입니다. 문을 열려고 할 때 ‘어떤 퀘스트를 플레이 중인지’ 확인하거나 약초를 채집하려 할 때 ‘약초 채집 스킬’을 가지고 있는지 확인하는 것들이 여기에 해당합니다. 이에 비해 어떤 조건을 - 여전히 ‘조건’이라는 말을 사용해 헛갈릴 수밖에 없음 - 던전 플레이가 진행되는 내내 계속해서 확인하다가 상황이 발생하면 그 때 어떤 동작이 발생해야 하거나 어떤 문이 계속해서 자기 주변에서 일어나는 일을 관찰하다가 끝까지 진행된 노래를 확인하면 자신을 열어주는 것처럼 판단 시점이 명확하지 않고 또 판정 자체에 시간이 걸리는 것들은 ‘조건’이 아니라 이 행동에 의해 발생하는 ‘이벤트’로 분류해야 합니다. 이들이 이벤트라는 관점에서 각 시나리오를 살펴보면 문제가 훨씬 간단해진다는 점을 알 수 있습니다. 던전 실패 조건은 나열된 실패 조건이 일어날 때 ‘이벤트’가 발생하고 이 이벤트에 의한 결과로 클리어에 실패합니다. 노래 역시 노래가 온전히 끝날 때 이벤트가 발생하고 이 결과로 닫혀 있던 문이 열립니다. 이렇게 해석하면 던전이 매 1초마다 죽은 사람이 있는지 확인할 필요가 없고 또 문 역시 매 1초마다 자기 주변에서 노래를 끝까지 부른 사람이 있는지 확인할 필요가 없습니다. 그저 ‘이벤트가 일어나면’ 그 때 대응하면 됩니다.

이 글 전체에 걸쳐 ‘조건’은 판정 시점을 특정할 수 있고 또 그 시점에 즉시 판정 가능한 것들을 모은 것, 그리고 ‘이벤트’는 판정 시점이 모호하고 또 판정에 시간이 필요한 것들을 모은 것이라고 정의했습니다. 그런데 이들을 구분하지 않고 흔히 ‘조건’이라고 부르기 때문에 판정 시점과 판정에 시간이 필요한 것들을 구분하지 않고 이들을 같은 시스템, 같은 데이터구조에 밀어 넣을 수 있다고 생각하기 쉽습니다. 근본적으로 이들을 모두 포함한 조건 정규화 시스템을 만들 수도 있을 거라고 생각합니다. 하지만 기반 장르가 MMO인 게임 대부분은 이들을 명확히 구분하는 시스템을 이미 가지고 있을 가능성이 높습니다. 판정 시점이 명확한 것들을 ‘조건’이라고 한다면 시점이 모호하고 또 판정에 시간이 걸리는 행동들은 이미 게임 내 개체들이 상호작용을 주고 받는 표준 방법인 ‘스킬 시스템’에 의해 정규화 할 수 있을 겁니다. 이미 구축된 기능으로 표현할 수 있는 요구사항을 ‘조건’이라는 말을 보고 ‘조건’으로 잘못 판단하는 상황이 발생한 이유는 일단 제 스스로가 이런 상황을 예상하지 못하고 ‘조건’이라는 평범한 이름으로 조건들이 통합된 시스템을 부른 것이 가장 큽니다. 만약 한번쯤 더 생각해봐야 할 것 같은 다른 이름을 선택했다면 ‘조건’이라고 생각한 사람들이 제 자리로 달려오게 만들지 않았을 겁니다. 또 ‘조건’과 ‘이벤트’를 서로 구분하지 않고 그냥 ‘조건’이라고 표현하도록 방치하는 것 역시 썩 좋은 아이디어는 아니라고 생각합니다. 이벤트는 조건에 시간이 포함되는 것을 말한다고 정의하더라도 크게 틀리지 않을 가능성이 높으며 일단 시간이 포함되는 순간 이들의 올바른 표현 방법은 정규화된 조건 목록이 아니라 액티브스킬이라는 점을 알아둘 필요도 있습니다.

다음에 다른 프로젝트를 하게 된다면 그때는 처음부터 같은 기능이 서로 다른 요구사항에 의해 별도로 개발되는 일이 일어나지 않도록 평소처럼 잘 막을 테지만 그와 동시에 기반 장르가 MMO일 때 조건에 시간이 포함되는지 여부에 따라 이를 판정 시점이 명확한 조건에 포함할지, 아니면 게임 내 개체들이 상호작용을 주고 받는 표준 방법인 스킬 시스템의 액티브스킬에 해당하는 것인지 평가하는 방법을 잘 설명할 필요도 있겠다는 교훈을 얻었습니다.