처음 일을 시작할 때 이미 선배들이 작성해 놓은 기획서를 보니 시스템 기획서라는 장르의 문서에는 이 기획서에서 설명하는 동작에 필요할 것으로 예상되는 값들이 늘어서 있고 각 값들이 어떤 데이터 타입인지, 어떤 범위의 숫자를 사용할 작정인지 명시되어 있었습니다. 가령 몬스터 아이디는 숫자인데 ‘int’ 데이터 타입을 사용할 작정이고 몬스터 이름은 20 바이트까지 사용하려고 하며 몬스터 체력은 ‘int’ 타입, 공격력은 ‘float’ 타입을 사용할 작정이라고 기획서에 기입 되어 있었습니다.
그런 문서를 보고 일단 그대로 따르기는 했는데 의문을 지울 수 없었습니다. 기획자들은 데이터구조를 설계하는데 전문가가 아니고 데이터구조 설계에 필요한 학문을 충분히 공부하지도 않았을 뿐 아니라 직접 코드를 다루지도 않는데 어째서 문서에 이런 값을 직접 기입하는 것일까요? 몬스터 아이디를 숫자로 하는 것 자체는 현대적이지는 않지만 다른 한 편으로는 또 아주 이상한 것이 아니기는 합니다. 하지만 몬스터 아이디를 ‘int’ 타입으로 해 달라는 기획서의 요구사항에는 무슨 의미가 있을까요? 몬스터 아이디를 곧이곧대로 ‘int’ 타입으로 해 달라는 의미일까요? 만약 그렇다면 이 숫자는 32비트일까 64비트일까요? 어느 쪽이라도 몬스터 아이디에 그렇게 큰 숫자가 필요할 만큼 아주 다양한 몬스터를 정의할 예정인 것일까요?
20바이트 짜리 몬스터 이름은 근거가 무엇일까요? 이미 인터페이스를 만들어 보고 한글 기준의 글자 폭에 맞춰 20글자까지 인터페이스에 잘리지 않고 나타낼 수 있었기 때문에 20바이트라고 말한 것일까요? 20바이트라는 것은 어떤 표현 방식을 기준으로 한 것일까요? 영문 20글자를 의미하는 것일까요? 만약 그렇다면 한글 기준으로는 몇 글자를 말하는 것일까요?
이런 의문은 요구사항에 근거해 엔지니어가 판단해 결정할 수 있는 것들이라고 생각합니다. 몬스터가 대략 어느 정도 규모로 선언될지에 따라 몬스터 아이디의 데이터 크기가 달라져야 합니다. 몬스터 이름은 바이트가 아니라 인터페이스에 근거한 대략적인 글자 수를 기준으로 선언하고 그에 맞춰 그보다 폭이 좁은 언어를 사용할 때와 폭이 넓은 언어를 사용할 때 화면에 표시되는 상태에 따라 글자 수를 결정해야 합니다.
종종 아주 오래된 프로젝트에서 사용하는 엑셀 파일을 열어 보면 엑셀 파일 어딘가에 데이터 이름과 데이터 타입, 데이터 범위, 기본값 따위가 테이블에 정리된 워크시트를 만날 때가 있습니다. 이런 워크시트는 의외로 여러 프로젝트에 걸쳐 쉽게 발견되는데 아마 비슷한 시기에 비슷하게 배운 사람들이 여러 회사로 퍼져 일하고 있기 때문이 아닐까 싶습니다. 이런 엑셀 워크시트는 이를 보는 사람에게 이 워크시트에 선언한 데이터 이름과 데이터 타입이 코드를 생성하는데 자동으로 참조된다는 잘못된 예측을 하게 만드는 것 같습니다.
전설적이기는 하지만 엑셀 데이터시트를 읽어 데이터 정의를 생성하고 이에 기반해 코드를 생성하는 사례가 없는 것은 아닙니다. 기술적으로 가능하기는 하지만 그렇게 할 이유가 없고 도 그렇게 하면 위험합니다. 일단 비전문가인 기획자가 제안한 데이터 타입과 데이터 범위를 신뢰해서는 안됩니다. 기획자는 요구사항에는 전문가이지만 요구사항을 뒷받침하는 데이터구조에는 결코 전문가가 아닙니다. 이들은 게임 전체에 걸쳐 몬스터가 최대 10만 종류 정도 선언될 수 있을 거라고 예상할 수는 있지만 몬스터 아이디를 ‘int’ 타입으로 정의해야 한다고 말할 전문성은 없습니다.
또한 엑셀 워크시트는 여기에 기입된 데이터가 올바른지 데이터를 작성할 때 바로 알 수 없습니다. 데이터가 올바르게 기입되지 않았음을 엑셀 데이터를 읽어 데이터 정의를 만들어낸 다음 코드를 제너레이팅 하고 나서 그 코드를 실행해 보고 나서야 문제가 있음을 발견할 수 있는데 굳이 이렇게 늦은 시점에 문제를 발견할 수 있는 비전문가가 작성한 아슬아슬한 방법에 데이터를 맡길 이유가 없습니다.
익숙한 습관 때문에 엑셀 테이블에 사용하는 여러 값의 데이터 타입과 데이터 범위, 기본값을 정의한 워크시트를 엑셀 파일에 여전히 포함할 때가 있긴 하지만 근래 경험한 여러 프로젝트에서 이 워크시트는 더 이상 자동화의 대상이 아닙니다. 엔지니어들은 기획서에 정의된 요구사항에 기반해 데이터구조를 정의할 때 엑셀 워크시트에 비전문가가 정의해 놓은데이터 모양을 참고하기는 하지만 결코 이 모양대로 데이터를 선언하지는 않습니다. 엔지닝어의 판단에 따라 코드 상에 데이터 타입을 선언하고 이 모양을 사람이 직접 엑셀 워크시트 상에 수정해 의사소통을 하는데 사용하는 정도입니다. 이 과정에서 데이터 타입을 정의한 엑셀 워크시트는 과거와 달리 자동화된 데이터 생성 과정에 사용되지 않으며 단지 기획자와 엔지니어 사이에 의사소통을 하는 용도로 사용될 뿐입니다.
현대에 이르러 엑셀은 여전히 꽤 괜찮은 데이터 입력 도구이지만 현대적인 개발환경의 도움을 아무 것도 받지 못하는 위험한 환경이기도 합니다. 한때 엑셀 워크시트에 비전문가가 정의한 데이터 모양을 그대로 읽어 코드로 만들어내던 시대가 아예 없었던 것은 아니지만 이제는 비전문가의 데이터 제안을 따를 이유도, 이런 불안하고 도 늦게서야 검증할 수 있는 위험한 방법을 사용할 필요도 없음을 모두가 알고 있습니다. 기획서와 엑셀을 통한 비전문가의 데이터 타입 정의는 그렇게 하면 안 된다는 사실과 그렇게 하는 건 위험하다는 사실을 서로 잘 몰랐던 시대의 산물이라고 생각합니다. 과거에 그렇게 해 왔다는 이유로 지금도 그렇게 해서는 안 됩니다.
여전히 엑셀이 강력하게 활용될 영역이 있을 겁니다. 하지만 그렇지 않은 영역에는 보다 현대적이고 또 안전한 환경을 통하고 비전문가가 데이터를 정의할 수 있을 것처럼 보이는 워크시트 같은 것을 현대에 유지하기 위해 노력할 이유는 없습니다.