누가 고쳐야 할까

언리얼 환경에서 개발하는 가상의 프로젝트에서 사용하는 아이템 데이터 엑셀 파일을 생각해 봅시다. 엑셀 파일을 열면 거대한 워크시트가 펼쳐지고 첫 칼럼에는 아이템 아이디 수 천 개가 줄줄이 늘어서 있습니다. 오른쪽으로 조금 스크롤 해 보면 아이템 아이콘을 설정하는 자리가 있고요. 여기에는 언리얼 에디터에서 에셋 경로를 복사한 에셋 종류와 경로, 네임스페이스가 쭉 연결된 텍스트가 붙어 있습니다. 아이템 아이콘을 수정하고 싶으면 언리얼 에디터에서 원하는 아이콘의 스프라이트 에셋을 찾은 다음 컨텐츠 브라우저에서 경로를 복사해 엑셀 워크시트에 붙여 넣고 저장한 다음 클라이언트를 다시 실행하거나 클라이언트가 실행된 상태에서 데이터만 새로 고쳐 테스트 해 보면 됩니다.

이런 체계를 구축할 때 잠깐 생각해 봐야 할 것이 있습니다. 사실 아이템 아이콘 대부분은 아이템의 종류와 등급에 의한 규칙에 따라 결정됩니다. 가령 체력 포션 아이콘은 유리 병 안에 들어 있는 빨간 액체 모양인데 체력 포션은 다섯 가지 등급이 있다면 다섯 가지 아이콘은 모양을 예상할 수도 있고 에셋 경로를 예상할 수도 있습니다. 미리 다섯 가지 등급을 숫자 1부터 5로 약속해 놓으면 굳이 아이콘 에셋의 정확한 경로를 찾기 위해 컨텐츠 브라우저로 아이콘을 찾을 필요도 없습니다. 그냥 이전 등급 포션 아이콘 경로를 복사해 숫자만 고치면 동작하리라 기대할 수 있습니다.

이를 알면서도 처음 데이터를 만들 때 습관적으로 아이콘 경로를 직접 입력하게 만들었습니다. 초반에는 미래에 아이템 데이터가 어떻게 발전될지 알기 어렵습니다. 사실 아이템 등급 정도는 완전 초반에도 예상할 수 있기는 하지만 미래에 숫자 모양으로 표현할 수 없는 등급을 사용할 수도 있습니다. 그래서 미래를 예측해 미리 만들기 보다는 각 시점에 확실한 요구사항에 집중해 설계하는 편을 선호하곤 합니다. 또 팀 전체가 규칙을 정확히 지키기는 상당히 어렵습니다. 아트 에셋의 이름 규칙을 유지기는 쉽지 않습니다. 규칙을 만드는 것 자체는 어렵지 않지만 규칙을 확장하거나 규칙에 어긋난 에셋이 나타날 때 에셋 이름을 수정하는데는 상당한 노력이 필요합니다. 그래서 게임에 사용할 에셋을 직접 다루는 분들은 이름 규칙에 민감하게 반응하곤 합니다.

하지만 이런 규칙이라도 틀리는 사례는 항상 일어납니다. 이제 처음에 설명한 가상 프로젝트에 일어난 버그를 수정해 보겠습니다. 게임 상에서 3등급 체력 포션 아이콘이 안 나오고 있습니다. 우선 컨텐츠 브라우저에서 아이템 아이콘을 찾아 보니 3등급 아이콘 에셋은 있습니다. 이번에는 엑셀로 아이템 데이터를 열어보니 3등급 포션 데이터에 아이콘 경로도 잘 붙어 있고요. 하지만 자세히 살펴보니 아이템 데이터 상에 설정된 에셋 경로와 언리얼 에디터 상의 에셋 경로가 서로 다릅니다. 아이콘 이름 끝부분을 등급에 따라 HealthPotion_3과 같은 형식으로 이름과 등급 사이에 언더바 문자를 넣기로 했는데 엑셀 데이터 상에는 언더바가 들어가 있지만 에셋 파일 이름은 언더바가 빠져 있었습니다. 위에 설명한 대로 실제 에셋 유무를 확인하지 않고 규칙에 맞는 에셋이 있으리라 예상한 경로를 입력했기 때문일 것 같습니다.

원인을 파악했지만 해결 방법은 두 가지입니다. 하나는 에셋 이름을 규칙에 맞게 수정하는 것입니다. 하지만 에셋 이름을 그냥 수정하는 건 안전하지 않습니다. 언리얼 에디터가 이 스프라이트에 의존성을 가지는 에셋을 찾아 알아서 수정해주긴 하겠지만 이를 완전히 신뢰하면 안됩니다. 하다못해 이 스프라이트를 만드는데 사용한 원본 파일과 규칙이 깨져 리임포트 할 때 문제가 생길 수 있습니다. 이쯤 되면 시급한 상황일 경우 에셋 이름을 수정해 달라고 요청하기 난감해집니다.

다른 방법은 이럴 때를 대비해 아이콘 에셋 이름이 규칙적으로 정해짐에도 모두 수동으로 입력하게 해 둔 아이콘 에셋 경로 칼럼을 활용해 틀린 경로 이름을 그대로 사용하는 것입니다. 이번에는 에셋 의존성이나 파이프라인 의존성을 전혀 신경 쓰지 않고 그냥 잘못된 에셋 이름을 그대로 사용해 빨리 문제를 수정할 수 있습니다. 특히 시급히 수정해야 하는 상황이라면 다른 부서에 도움을 요청하지 않고 데이터를 다룰 수 있는 사람 한 명이 문제를 해결할 수 있고요. 문제는 해결되고 아무 일도 없었던 것처럼 평화로워지겠지만 규칙에 어긋난 에셋은 영원히, 심지어 서비스를 종료하는 그 순간까지도 그대로 유지될 겁니다.

종종 이런 상황을 어떻게 처리해야 할지 고민하게 됩니다. 원칙대로 접근하면 에셋 이름을 수정해 문제를 해결해야 합니다. 하지만 그렇게만 주장하기는 어렵습니다. 팀에 속한 모든 사람들이 칼 같이 규칙을 지키기를 기대할 수 없습니다. 사람인 이상 실수를 하기 마련이고요. 또 급하게 수정해야 한다면 다른 팀에 도움을 요청하는 대신 지라 이슈를 받은 사람이 그 자리에서 즉시 문제를 해결하는 편이 나을 수도 있습니다.

어떤 방법이 올바를지는 잘 모르겠습니다. 아예 이런 문제로 고민할 필요조차 없는 데이터 입력 환경을 구축해 애초에 잘못된 데이터가 입력되지도 않도록 만들 수도 있을 겁니다. 이 경우에는 또 이 나름대로의 단점이 예상되기는 하지만 적어도 예로 든 가상의 프로젝트 같은 상황이 일어나지 않을 것은 확실합니다. 다만 고민의 초점을 이런 상황이 발생할 때 누가 문제를 해결하는 것이 옳은지에서 어떻게 하면 이런 상황 자체가 발생하지 않도록 개발환경을 구축할지로 옮겨 가는 편이 더 좋은 고민의 방향이라는 생각은 듭니다.