요즘 세상에 AI를 어떻게 만드나

어느 날 타임라인에 지나가는 글을 멍하니 읽다가 글에 포함된 링크를 따라가 블로그 글을 읽었는데 아마도 처음으로 구직을 준비하시는 분의 글인 것 같아 보였습니다. 이런 저런 고민을 하고 계시겠구나 하고 타임라인으로 돌아 가려다가 문득 마음에 걸리는 단어를 봤고 머릿속에서 한참이나 단어가 떠나지를 않아 곰곰히 생각해 보다가 요즘 세상에 이 주제를 팀에서 어떻게 다루고 있는지 과거에서 현재를 한번 정리해 두면 좋겠다는 생각이 들었습니다.

머릿속에 남은 단어는 바로 ‘AI 기획서’인데 아마도 여러 장르에 등장하는 플레이어가 아닌 여러 개체나 물체가 게임 안에서 상호작용하는 규칙을 기록한 문서를 가리키는 말인 것 같습니다. 분명 작성할 일이 있고 또 필요한 문서이지만 맥락 상 이 문서가 과거에서 현재에 이르는 사이에 의미가 좀 달라졌다는 생각이 들었습니다.

한국에서 오랜 세월에 걸쳐 수없이 출시된 흔한 MMO 게임을 좀 단순하게 만들어 생각해봅시다. 필드에 오크 한 마리가(처음엔 디아블로의 몰락자를 예로 들고 싶었는데 설명하려니 생각보다 복잡해서 그냥 오크로 정했습니다.) 있는데 주변에 플레이어가 아무도 없을 때는 자원을 절약하기 위해 제자리에 가만히 서 있지만 주변에 플레이어가 나타나 관측을 시작하면 주변을 어슬렁거리며 돌아다닙니다. 이 오크는 멀리 플레이어가 보이더라도 바로 공격하지는 않지만 플레이어가 눈에 띄면 어슬렁거리기를 멈추고 플레이어 쪽을 바라보며 위협을 가합니다. 하지만 언제까지 위협을 가하기에는 플레이어가 보기에도 애처롭고 오크 입장에서도 썩 할만한 짓은 아닌 것 같으니 플레이어를 위협한 다음에도 플레이어가 더 가까이 다가오지 않으면 그런가보다 하고 다시 어슬렁거리기를 반복합니다.

하지만 플레이어가 더 가까이 다가오면 오크 입장에서 플레이어는 이제 현실적인 위협이므로 본격적으로 무력을 가해 플레이어를 제압하려고 시도할 수밖에 없습니다. 이 때 오크는 플레이어를 향해 달려와 전투를 시작합니다. 이제 오크는 이 전투 결과에 따라 플레이어를 죽이고 다시 아무 일 없었다는 듯 어슬렁거리거나 플레이어에 의해 죽음을 맞이한 다음 아무 것도 없는 텅 빈 공간에서 다시 태어나기를 반복할 운명을 맞이합니다.

게임에 등장하는 여러 몬스터들은 저마다 시청각적인 특징이 있는데 이들 뿐 아니라 공통적인 속성을 통해서도 이들을 구분할 수 있습니다. 어떤 몬스터는 시야가 넓어 멀리 있는 플레이어에게도 위협을 가하고 또 어떤 몬스터는 플레이어가 먼저 공격을 하기 전에는 플레이어를 공격하지 않는 성격이기도 하며 어떤 몬스터는 이동 속도가 빨라 전투에서 패배를 직감한 플레이어가 도망가려는 시도를 실패하게 만들고 플레이어에게 따뜻한 죽음의 냄새를 선사하기도 합니다. 또 어떤 몬스터는 공격 속도는 느리지만 대미지가 높아 방심한 플레이어에게 번쩍이는 섬광과 함께 경험치 드랍을 겪게 만들기도 하고 또 어떤 몬스터는 자신의 패배를 직감하면 전투를 멈추고 마치 플레이어 마냥 도망치기도 합니다. 이런 속성들은 어차피 이 세계가 가상 세계라는 사실을 이미 잘 알고 있는 플레이어들이 운 좋게 세계에 몰입하거나 아니면 적당히 가상 세계의 다양성을 즐기게 만드는 역할을 합니다.

가상의 게임에 나오는 오크의 행동과 몬스터의 특징을 정의하는 몇 가지 요소를 소개했으니 이제 이런 몬스터를 게임에 넣으려면 무슨 일을 해야 할 지 생각해보겠습니다. 만약 게임이 이미 개발 중이고 누군가 이미 AI와 전투 시스템을 만들어 놓았다면 오크의 행동은 이 시스템의 규칙과 제약에 기반해 만들어야 합니다. 가령 시스템에 이미 시야 거리, 행동 거리, 이동 속도, 공격력, 방어력 따위를 정의하게 되어 있다면 새로운 오크를 추가하기 위해 이 모든 특징을 바닥부터 정의할 필요가 없습니다. 이런 상황에서는 대체로 이미 규격화된 몬스터 기획서가 있고 이 문서의 빈 칸을 채워 넣는 방식으로 몬스터를 기획하고 몬스터 AI를 정의하게 됩니다.

이 문서에 따라 단지 시야 거리와 행동 거리에 숫자를 넣기만 해도 이에 따라 오크는 시야 거리에 들어온 플레이어에게 ‘위협’에 정의된 행동을 하고 또 행동 거리에 들어온 플레이어를 향해 ‘전투’를 시작할 겁니다. 일단 전투에 돌입하면 오크를 지금까지 제어하던 시스템은 전투 시스템으로 넘어가며 가칭 전투 AI에 의해 제어되며 이는 오크가 패배하거나 플레이어가 패배할 때까지 계속됩니다.  이 상황에서 이른바 AI 기획서는 설정 관점에서 오크의 특징을 정의한 그리 길지 않을 가능성이 높은 텍스트와 이 텍스트의 특성을 반영한 규격화된 기획서, 그리고 기획서에 기반한 숫자들로 구성됩니다.

만약 팀에서 설정 담당자가 이미 오크 몬스터에 대한 설정을 마쳤다면 이 설정에 따라 규격화된 기획서를 작성하고 이에 따라 숫자를 입력하면 오크가 동작하기 시작할 겁니다. 이 상황에서 AI 기획서는 규격화된 몬스터 기획서에 해당하는데 개인적으로는 이 문서 포멧을 썩 선호하지는 않지만 여러 규모가 큰 MMO 팀에서는 엑셀 파일에 몬스터의 상황 별 특징, 이 특징을 드러내는 숫자들을 미리 입력할 수 있게 만들어 관리하곤 합니다. 나아가 어떤 팀들은 처음부터 설정 텍스트에 기반해 규격화된 기획서 단계를 생략하고 바로 데이터를 작성하기도 하는데 어차피 규격화된 기획서와 실제 데이터는 형식이 다를 뿐 본질이 별로 다르지 않기 때문에 굳이 비슷한 역할을 하는 두 가지 문서를 만들 필요가 없다고 생각하기 때문입니다.

규모가 크고 이전부터 MMO를 개발하던 팀들은 데이터에 의해 동작하는 AI를 더 선호하는 경향이 있는 것 같습니다. 위에서 이야기한 시야 거리, 행동 거리 같은 간단한 정의만으로도 쉽게 몬스터의 행동을 정의할 수 있기 때문입니다. 전투를 시작한 다음에는 전투 AI에 지배를 받는데 필드에 있는 단순한 몬스터들은 행동이 그리 복잡하지 않아 시청각적인, 그리고 숫자에 의한 특징을 제외하면 사실상 거의 같은 행동을 공유하는 경우가 많아 주요 데이터를 넣고 나면 사실상 AI 기획서 같은 문서를 만들 일이 많지 않습니다.

여기서 조금 더 파고 들면 몬스터에 따라 여러 몬스터에 걸쳐 행동을 제어해야 하거나 보스 몬스터처럼 단일 개체에 좀 더 긴 시간에 걸친 다양한 행동을 하게 만드는 데는 전통적인 데이터에 의해 동작하는 AI는 한계가 아주 빨리 찾아옵니다. 하지만 몬스터의 숙명은 플레이어에 의해 죽는 것이고 죽기까지 얼마나 고객을 재미있게 만들어 주느냐가 핵심일 뿐 그 행동이 얼마나 다양하고 복잡한지는 그리 중요하지 않아 데이터에 기반한 단순한 AI라도 고객은 이를 잘 느끼지 못할 가능성이 높습니다.

한편 시대가 변하며 전통적인 MMO 만들던 방식을 고집하는 대신 엔진 개발사가 제공하는 MMO 관점에서는 그리 효율적이지도 않고 그리 신뢰할 수 있을 것 같지도 않은 서버를 사용하기도 했는데 처음에는 이 시도는 전통적인 개발사들처럼 제대로 된 MMO 서버를 구축할 기술이나 비용이 없기 때문에 어쩔 수 없는 선택이라고 생각한 적이 있습니다. 하지만 우리들 모두가 잘 알고 있듯 하드웨어 비용이 급격히 낮아지고 인프라 구축 비용과 난이도 역시 빠른 속도로 낮아지며 상대적으로 적은 비용으로 대규모 인원을 신뢰할 수 있는 수준으로 처리할 수 있는 전통적인 MMO 서버를 고집할 이유가 사라지고 있습니다.

이렇게 바뀐 환경에서는 게임 엔진에 포함된 서버에 기반해 멀티플레이 환경을 개발하기도 하는데 이런 환경에서는 이전 시대에는 거의 활용하지 않거나 보스 몬스터에 한해 제한적으로 활용하던 엔진에서 직접 제공하는 AI 저작도구를 활용해 직접 AI를 구성할 수 있습니다. 이런 환경에서는 몬스터의 설정과 에셋이 준비되면 이를 저작도구에서 직접 제어해 몬스터 행동을 만들 수 있는데 널리 사용되는 언리얼 엔진은 비헤이비어 트리라는 방식을 사용합니다. 게임 몬스터를 제어하는 간단한 AI를 공부할 때 항상 나오는 유한상태기계의 확장이라고 이해하면 됩니다. 이런 AI 제작 방식은 중간에 ‘AI 기획서’ 같은 용도가 모호한 문서를 건너뛰고 게임디자이너가 설정에 기반한 의도를 직접 플로우차트 모양으로 작성하고 이 결과가 바로 실행되어 기획서 작성과 구현 사이에 이터레이션을 게임디자이너 한 명이 반복하는 실행과 수정 과정으로 바꿔 버립니다.

‘Unreal Engine AI with Behavior Tree’를 보면 현대에 몬스터 뿐 아니라 게임에 등장하는 여러 개체의 행동을 엔지니어가 아닌 게임디자이너 수준에서 직접 작성하고 이를 바로 테스트 해 결과를 확인하고 수정하기를 반복해 완성된 결과를 도출하고 이 과정에서 작성한 플로우차트는 그 자체가 기획서이기도 하고 또 실행되는 코드이기도 하다는 점을 알 수 있습니다. 물론 이런 작업 시나리오에서도 여전히 AI를 통해 제어할 대상의 설정, 특징 따위를 기술한 문서는 필요합니다. 하지만 이전 시대처럼 몬스터의 주요 특징을 대표하는 숫자를 나열한 규격화된 문서나 상황 별 행동을 자연어로 기술한 문서는 AI를 작성하는 사람이 기획서를 작성하는 사람과 같은 사람으로 만드는 작업 환경의 변화로 인해 별로 필요하지 않게 되어 가고 있습니다.

물론 이런 작업 방식을 어느 팀에서나 실천할 수 있는 것은 아닙니다. 팀의 인력 구성에 따라 엔지니어는 아니지만 전통적인 게임디자이너에 비해서는 좀 더 기술적인 측면에 익숙한 사람들에게 이런 업무를 전담 시키고 나머지에게는 전통적인 게임디자이너처럼 몬스터의 특징을 자연어로 서술하는 기획서를 작성하도록 구성하기도 합니다. 하지만 시간이 흐를 수록 게임디자이너 스스로 문서 작성과 실제 구현을 해낼 수 있는 환경 앞에 그냥 직접 플로우를 만들면 될 일을 문서로 한번 더 작성하는 수고를 굳이 하려고 하지는 않는 분위기입니다.

결론. 흘러가는 타임라인의 여러 글을 보다가 ‘AI 기획서’라는 단어를 봤고 이 단어가 현대 게임 상에 등장하는 여러 개체의 행동을 정의하고 동작하게 만드는 과정에 잘 맞지 않는 단어라는 느낌이 들어 오크의 가장 간단한 시나리오를 빌어 과거와 현대에 몬스터를 제어하는 방법을 간단히 소개해 보았습니다.