서기 2020년 현재에도 개발팀에서 기획 데이터 입력 대부분을 엑셀로 해결하고 있습니다. 전체 에디터 파이프라인도 오래 전과 비교해 달라진 점이 별로 없습니다. 엑셀 데이터를 읽어 뭔가의 중간 형태로 변환한 다음 이를 읽어 코드제너레이팅을 하고 엔지니어들은 엑셀을 완전히 잊은 채 데이터에 접근합니다. 이미 7년 전에도 비슷한 이야기를 했습니다. 현대 개발과정은 더 빠르고 데이터끼리 의존성이 더 높으며 더 강하게 밸리데이팅 해야 하고 더 많은 동시작업을 요구하지만 전통의 엑셀은 이 새로운 요구사항 중 어느 것 하나도 스스로 해결하지 못합니다. 모두가 이미 잘 알고 있어요. 하지만 기획자들은 여전히 엑셀을 선호하고 언리얼에디터에서 리소스 경로를 복사한 다음 엑셀 데이터시트에 붙여넣는 짓을 하게 해달라고 요구합니다. 왜때문일까요.

사례

리소스 경로

플레이어와 인터랙션 해야 하는 오브젝트가 필요했습니다. 어느 한 상태를 유지하다가 플레이어가 인터랙션하면 다른 상태로 바뀝니다. 상태와 상태 사이를 전환할 때는 애니메이션을 재생한 다음 상태가 바뀐 다음에는 그 상태의 애니메이션을 반복 재생하고요. 각각의 애니메이션은 애님몽타주로 컨테이닝해 나중에 노티파이를 추가하거나 파티클시스템을 붙일 경우에 대비합니다. 이 오브젝트의 상태 이름과 상태를 전환할 때 플레이할 애니메이션은 엑셀에 기입하게 했습니다. 발주한 에셋이 기획팀에 도착하면 엑셀을 열어 상태 별 애님몽타주와 상태 전환 애님몽타주를 플레이해본 다음 이들의 경로 각각을 엑셀 데이터시트에 따로따로 기입합니다. 앞에 이야기한 '중간 형태'로 변환한 다음 클라이언트를 실행한 다음에야 접근할 수 있는 테스트환경에서 이 데이터를 테스트합니다. 뭔가 잘못됐다면 애니메이션 플레이어부터 다시 시작해서 과정을 반복합니다.

사실 언리얼에디터에서 이미 이와 비슷한 과정을 훨씬 편안한 방법으로 해결할 수 있습니다. 언리얼 데이터에셋에 상태 이름 별로 애님몽타주를 끼워넣을 수 있게 만들어두면 몽타주를 드래그 앤 그랍으로 입력할 수 있을 뿐 아니라 클라이언트를 재시작할 필요도 없고 중간 형태로 데이터를 변환할 필요도 없습니다. 이미 입력된 노티파이 이름에 편안하게 접근할 수 있을 뿐 아니라 실시간으로 데이터 오류를 확인할 수도 있습니다. 애초에 규격에 맞지 않는 몽타주는 입력조차 안 되도록 만들어놓을 수도 있고요. 하지만 이 훨씬 편안한 방법은 기획자들의 강력한 저항에 부딪쳤고 엑셀로 만들어졌습니다. 없는 경로나 없는 리소스를 가리키고 있지는 않은지 '중간 형태' 데이터를 읽어 리소스를 확인하는 코드를 별도로 사용해야 했습니다.

포션

포션을 만드는 전통적인 방법이 있습니다. 포션은 인벤토리에 들어가는 아이템이고 사용할 수 있어야 합니다. 사용하면 체력을 회복하는 동작을 수행한 다음 사라져야 합니다. 아마도 Item.xlsx 같은 파일에 포션 데이터를 한 줄 추가할 겁니다. 하지만 이 데이터만으로는 체력을 회복하는 기능을 데이터로 표현할 수 없을테니 체력 회복 부분만 어딘가 다른 데이터로부터 가져와야 할텐데 이런 상황에서 가장 많이 사용하는 방법은 스킬시스템을 차용하는 것입니다. 전통적인 MMO 게임에서 '스킬'은 월드와 플레이어가 상호작용하는 거의 모든 방법을 정의할 수 있게 만들어진 거대한 시스템입니다. 플레이어가 소셜 애니메이션을 재생하는 것부터 항상 모두를 괴롭히는 여러 타겟을 순차로 선택해야 하는 체인 라이트닝 스킬에 이르는 넓은 범위의 기능을 정의할 수 있습니다. 그래서 일단 스킬 시스템을 구축하고 나면 게임의 온갖 사소한 기능들이 이 시스템에 의존하게 됩니다.

그래서 스킬시스템을 사용해 아마도 Skill.xlsx 같은 파일에 아이템을 사용한 플레이어를 타겟으로 하는 체력 회복 및 시각효과를 기술한 데이터를 추가하고 위 아이템 데이터에 이 스킬데이터를 연결해서 포션을 완성합니다. 그런데 이 모든 데이터는 엑셀 파일이므로 포션을 만들기 위해 아이템과 스킬 데이터를 열고 각각의 데이터를 입력한 다음 서로를 적당한 구분자 - 보통은 숫자로 된 - 로 연결해야 합니다. 엑셀은 관계형 데이터베이스와 비슷하지만 관계형 데이터베이스는 아니므로 이 구분자의 유효성을 즉시 검증할 수 없습니다. 만약 어느 데이터라도 잘못 입력했거나 잘못 연결했다면 문제를 인식하고 수정하기 난감한 양상으로 나타납니다. 포션을 사용했는데 아무 일도 안 일어나는 식으로요. 엑셀이 아니었다면 항상 정확한 데이터만 연결할 수 있도록 강제하고 연결한 스킬 데이터가 어떤 역할을 하는지 미리 확인하는 인터페이스를 제공할 수도 있었을텐데요.

GUID

언리얼에디터에서 배치한 여러 액터를 구분할 방법을 찾다가 언리얼 기능 중 하나인 GUID를 사용하기로 했습니다. 월드에 액터를 드랍할 때마다 GUID를 발급하고 게임의 여러 로직에서 이 액터를 가리킬 때 이 아이디를 사용하게 됩니다. 하지만 컨텐츠를 개발할 때 이 아이디를 사용하는데 찜찜한 상황이 생겼습니다. 여러 컨텐츠를 정의하는데는 엑셀을 사용하고 있어 이 아이디 문자열을 엑셀에 직접 붙여넣어야 했습니다. 아마도 붙여넣은 아이디로도 게임은 별 일 없이 동작하겠지만 붙여넣은 문자열이 실제로 존재하기는 하는 건지, 이 상황에서 사용 가능한 액터를 가리키는 아이디인지는 알 수가 없었습니다. 이 상황만을 위한 밸리데이션 코드를 작성해야 했고 인간이 알아보기도 어려운 문자열이 가득한 엑셀 파일이 생겼습니다.

만약 엑셀이 아니었다면 이 문자열을 인간이 직접 볼 일을 없앨 수도 있었습니다. 언리얼에디터 안에 표시되는 액터 이름을 표시하고 GUID는 눈에 안 보이는 곳으로 치워버릴 수도 있었습니다. 당연히 연결된 개체들이 유효한지, 이 상황에 사용 가능한 타입인지 실시간으로 검사할 수도 있었을 겁니다. 하지만 엑셀을 사용해야만 했고 엑셀을 사용하면서 생기는 온갖 문제와 마주해야 했습니다. 각각의 문제를 해결하며 왜 서기 2020년에도 이런 상황과 마주하고 있어야 하는지 좀 괴로웠습니다. 한편으로는 지금도 엑셀을 고집하는 상황이 원망스럽기도 했고요.

원인

기획자들이 근본적으로 엑셀을 선호하는데는 전통적으로 엑셀을 사용해 왔기 때문에 이 환경에 익숙한 것도 있습니다만 한편으로는 개발이 진행되면서 인하우스툴의 지원이 끊기는 경험을 자주 해 왔기 때문이기도 합니다. 개발 초기에는 지난 프로젝트에 겪었던 온갖 괴상한 문제를 해결할 방법으로 최소한의 인하우스툴을 개발해 인간의 실수가 개입할 여지를 줄이고 작업 자체도 간결하게 만들 꿈과 희망을 가집니다. 하지만 시간이 흐르면서 이 희망은 순식간에 무너집니다. 양산형 게임 개발과정을 설명했다시피 모든 마일스톤은 정신없이 진행되며 반짝이지 않는 기능을 마일스톤에 끼워넣기는 쉽지 않습니다. 다른 반짝이는 기능이 슬쩍 끼워넣어야 간신히 개발을 진행할 수 있는 상황에서 거의 반짝이지 않는 인하우스툴은 금새 버려집니다.

이런 상황을 겪다 보면 잘 동작하지 않게 된 툴로 인해 작업이 불가능해지는 상황보다는 차라리 엑셀 파일이라도 편집할 수 있으면 인하우스툴이 동작하지 않으며 이걸 수리하기 위한 엔지니어링 자원을 전혀 받을 수 없는 상황에서도 어쨌든 작업은 가능해집니다. 흔히 말하는 기획자를 갈아서 개발을 유지하는 상황인데 이런 문제를 안고있음에도 불구하고 이 상태로 런칭도 하고 라이브도 진행합니다. 제대로 자원이 배분되지 않는 인하우스툴보다는 차라리 엑셀이 나은 상황입니다. 이런 상황을 몇 번 겪다 보면 언리얼 에셋 경로를 엑셀에 붙여넣고 해시 문자열을 타이핑하고 클라이언트와 서버를 재시작해 테스트하는게 어쨌든 일을 할 수는 있으니 차라리 낫다는 생각을 하게 됩니다. 이런 상황에서 누군가 '데이터를 실시간으로 검증할 수 있으니 엑셀 말고 다른 수단을 사용하자'고 이야기하면 당연히 저항하게 되고요.

결론

왜 아직도 현대 개발 요구사항의 대부분을 만족하지 못하는 엑셀을 몇 십 년째 사용하고 있는가. 왜 기획자들은 그 구려터진 엑셀을 지금도 고집하는가. 익숙함 이외에 현대 양산형 게임 개발과정에서 인하우스툴의 우선순위는 쉽게 낮아지며 이미 개발된 인하우스툴도 쉽게 버려져 작업이 불가능해지는 상황을 자주 겪어왔기 때문입니다. 그래서 어느 한 구석에라도 엑셀을 집어넣어 만약의 사태를 대비하다 보니 서기 2020년에도 엑셀을 사용하고 있습니다. 이런 문제가 해결 가능하기는 한 것인지 잘 모르겠습니다.