사용자 도구

사이트 도구


사이드바

blog:serial-number-case

고유번호 사례

짧게 적었던 '고유번호 사례'에 대해 조금 더 설명하려고 합니다. 개인적으로는 개발 진행 과정에서 개발 주체들 사이에 여러 가지 요구사항이 오갈 수 있는데 이 요구사항을 어디까지 받아들이고 또 어디까지 받아들이지 않을지, 그리고 어느 선까지 의견을 조율해야 할지를 생각해보는 계기가 되었습니다.

예전에 개발을 진행 중이던 프로젝트에서 게임이 읽을 엑셀 데이터시트를 설계해야 했습니다. 극 초반을 지난 프로젝트에 합류해보면 이미 팀마다 조금씩 다른 엑셀 사용 규칙과 적당한 컨버팅, 밸리데이팅 환경이 이미 갖춰진 경우가 많습니다만 완전히 바닥부터 시작한다면 엑셀 데이터를 작성하는 방식과 컨버팅 환경에 대한 요구사항을 처음부터 제시해야 할 수도 있습니다. 이 때는 모든 것을 바닥부터 제시해야 하는 상황이었습니다.

배경지식

엑셀을 데이터 입출력 도구로 사용: 다른 소프트웨어 개발에서는 어떨지 모르겠습니다만 게임 개발에서는 엑셀을 주요 데이터 입출력 도구로 활용합니다. 일정한 규칙에 따라 반복되는 데이터가 많아 스프레드시트 형식으로 표현할 수 있고 입력 도구로 사용하기에 안정적인 환경을 제공하기 때문입니다. 특히 후자는 엑셀에서 다른 데이터를 참조해 계산을 수행한 결과를 데이터로 저장하고 다른 포멧으로 변환해 사용하게 됩니다. 한편 엑셀 자체만으로는 실시간 데이터 검증이 어렵습니다. 또 관계형 데이터를 아주 원시적인 방법으로 입력해야만 합니다. 이 단점은 상당히 치명적이어서 현대 게임 개발의 생산성을 유의미하게 떨어뜨리는 요소입니다만 현업에서 이를 크게 문제삼는 분위기는 아닙니다. 관성에 가깝게 게임 개발팀이 처음에 신경쓰는 주제 중 하나일 뿐입니다. 맨 처음에 엑셀 컨버팅과 데이터 밸리데이팅을 개발해 놓습니다. 이 파이프라인 자체를 의심하지는 않습니다.

기술 이해 수준이 서로 다른 사람들: 게임 개발팀에는 기술 이해 수준이 서로 다른 사람들이 섞여있습니다. 엔지니어들이라도 근현대의 동향이나 패러다임에 관심이 있는 분들도 있고 그렇지 않은 분들도 있습니다. 아티스트들 역시 좀더 기술적인 이해가 있는 분들이 있고 그렇지 않은 분들도 있습니다. 극단적인 경우에는 팀에서 공기처럼 사용하는 형상관리도구에 이해가 없는 경우도 있습니다. 이런 경우에는 공동작업을 위한 최소한의 기술적인 작업을 대신 수행하는 스탭을 따로 두기도1) 합니다. 이런 개발팀에서 게임디자이너들 역시 기술 이해 수준이 상대적으로 낮고 또 리소스 파이프라인에 대한 이해도 얕은 편입니다. 이들 중 기술이나 파이프라인을 이해하는 사람들이 팀 간 통역가 역할을 담당하곤 합니다. 하지만 모든 의사소통이 통역가를 거치기 어렵기 때문에 종종 통역가 없이 팀 간에 중요한 협의가 이루어지기도 합니다. 분명 상황을 이해하고 판단하고 협의했다고 생각했지만 다른 이해를 가진 사람이 조금 뜯어보면 필요 없는 일이거나 기계가 대신할 수 있는 일을 떠맡아 오기도 합니다.

상황

모든 엑셀파일의 키 칼럼에 모든 엑셀파일에 고유한 숫자 아이디를 부여해 달라는 요구: 한번은 이미 협의된 결정사항으로 모든 엑셀파일의 키 칼럼에 모든 엑셀파일에 대해 고유한 숫자를 기입해 달라는 요구를 받았습니다. 모든 데이터 행(Row)마다 고유한 식별자를 사용하자는 것은 꽤 괜찮은 아이디어처럼 보였습니다. 로그에 기록해 두면 문제가 있는 데이터를 찾아내기 쉬워질 겁니다. 엑셀을 제외한 다른 도구에서 특정 데이터를 가리키기도 편해보입니다. 다만 방법은 문제입니다. 처음에 상상한 것은 엑셀파일의 모든 데이터 행마다 '적당한 방법'으로 GUID를 부여할 모양이라고 생각했습니다. 만약 그렇다면 심지어는 게임디자이너들에게 공지할 필요도 없었습니다. GUID가 굳이 엑셀파일에 기입될 필요도 없었으니까요.

하지만 방법이 문제였습니다. 엔지니어들은 GUID가 엑셀파일의 첫번째 칼럼에 기입되길 원했고 그러려면 지금까지 사용하던 아이디와 같은 형식이어야 했으며 그러려면 숫자여야 했습니다. 최소한의 규칙을 포함한 거의 무작위에 가깝게 발급되는 GUID와 달리 연속된 숫자를 이와 같은 용도로 사용하려면 별도의 일련번호 발급 규칙이 필요하고 엑셀파일을 편집하는 모든 인간 - 주로 게임디자이너 - 들이 매번 행을 추가할 때마다 일련번호 발급 규칙에 따라 번호를 생성하고 이 번호가 일련번호 발급규칙에 맞는지, 중복되지는 않는지를 검사해야 합니다. 기계가 검사과정을 단순하게 만들어줄 수는 있겠지만 중앙집중형 형상관리도구를 사용하는 이상 온갖 예상할 수 있는 문제가 있었습니다.

제안

만약 GUID와 유사한 개념을 차용해 장점을 취하고 싶지만 그 형식이 숫자이기를 원한다면 개별 지역 엑셀파일에서는 이전과 같이 더 작은 숫자를 사용하고 이들은 서로 다른 엑셀파일간에 충돌할 수 있게 두고 각 파일마다 별도로 정해둔 큰 숫자를 더해 GUID처럼 사용할 수도 있을 겁니다. 이전까지는 엔지니어들로부터 받은 요구사항만 있었습니다만 상황에 실 작업자들 - 주로 게임디자이너 - 의 요구사항을 추가했습니다. 실 작업자들은 이전과 완전히 동일하게 다른 엑셀파일에서 아이디로 사용하는 숫자에 관심 끄고 같은 파일 안에서만 숫자가 겹치지 않도록 신경쓰는 겁니다. 대신 각각의 엑셀파일마다 더해줄 큰 숫자를 어딘가 적어놔야 하고 이 규칙을 정의한 다음 적어도 이 규칙만이라도 기계가 수행하고 검증하도록 구현해 달라고 요구해야겠다고 생각을 정리했습니다.

하지만 GUID의 개념을 설명하고 방법을 제시하는 것으로는 설득할 수가 없었습니다. 이유는 근본적으로 무작위로 아이디를 생성해내는 방식이 충돌을 막을 수 없기 때문인데 충돌할 가능성이 아주 낮다고 생각하기는 했지만 이를 즉석에서 수학적으로 설명할 수가 없었습니다. 때문에 이를 통한 설득에 실패했습니다. 대신 엔지니어들이 요구한 큰 숫자 형식을 사용하기로 하고 일련번호 체계를 만들었습니다. 파일 별로 큰 숫자로 된 일련번호를 부여하고 각 지역 엑셀파일을 변환할 때 미리 정해놓은 큰 숫자를 더해 GUID처럼 사용하는 겁니다. 지역 엑셀파일을 변환할 때마다 더해 줄 큰 숫자는 별도 엑셀파일에 기입해놓고 사용하며 새로운 엑셀파일을 추가할 때 이 파일에 일련번호 대역을 추가해야 합니다. 처음에 의도한 것과는 좀 달랐지만 각 작업자가 지역 엑셀파일에서 아이디로 사용하는 숫자 대역 이외에는 신경을 끌 수 있고 엔지니어들은 숫자로 된 고유 식별자를 얻었습니다. 물론 새 파일을 추가할 때마다 새로운 큰 숫자 대역을 미리 약속한 엑셀파일에 추가해야 하는 작업이 남아있지만 이건 새로운 파일을 추가할 때 한 번 씩만 생기므로 그럭저럭 합의할 만한 수준이었습니다.

교훈

결국 위에 이야기한 방식으로 개발했습니다. GUID를 도입해 엔지니어가 원하는 바를 얻고 실 작업자들은 완전히 신경 끄길 원했으나 그 수준에 도달하지는 못했습니다. 개념은 동일했지만 아이디가 중복될 가능성이 충분히 낮음을 설명하기는 어려웠습니다. 근본적으로 기술적 이슈에 대한 게임디자이너들의 지위와 이해가 낮아 협의보다는 단순히 설명을 반복하는 수준에 머물렀습니다. 쉬운 선택으로는 아무것도 안 하고 그대로 놔두면 엔지니어도 편하고 우리도 생전 처음 보는 일련번호를 정의하는 엑셀파일을 이해하려고 노력하지 않아도 됐을 겁니다. 그냥 전통적인 방법으로 모든 엑셀파일에 걸쳐 중복되는 아이디를 찾아내는 수고를 모두가 매번 하게 되고요. 제 입장에선 그게 그리 나쁜 것은 아닙니다. 망가지는 것은 팀의 생산성이지 제 작업의 복잡도는 아닙니다. 또 개인적으로 이 체계를 유지한 채로 제 작업 자체만 단순하게 만들 방법은 얼마든지 있습니다.

하지만 사람이 기계가 더 잘하는 일을 더 비효율적이고 부정확한 방법으로 개발과정은 물론 서버를 중단하는 그날까지 반복하는 일은 막아야 했습니다. 사람은 그러라고 만들어진 것이 아닙니다. 우리들 각각의 기술 이해 수준이 다를 수 있지만 각자가 전문성을 발휘할 수 있는 분야가 있고 거기에 집중할 수 있게 만들어야 합니다. 고작 데이터 전체에 행마다 고유한 숫자 하나를 얻자고 모든 작업자들을 매번 이상한 규칙에 얽매이게 만들어서는 안됩니다.

종종 파이프라인 전체를 고려하지 않으면 이상한 결정을 하게 됩니다. 작은 불편함 하나를 추가하려 할 때 이 결정이 개발팀 전체에 미치는 영향을 충분히 감안해야 합니다. 또 잘 모르는 결정을 해야 할 때는 그 자리에서 직접 결정하지 말고 다른 사람들에게 물어보는 것도 좋은 방법입니다.

1)
과거의 전설에 따르면 SVN 커밋만 전담하는 스탭이 있는 팀도 있었다고 합니다.
blog/serial-number-case.txt · 마지막으로 수정됨: 2019-08-18 20:43 저자 neoocean