왜 엑셀 데이터를 컨버팅 할 때 유효성 검사가 필요했을까

이전에 로직을 데이터 모양으로 표현한 간단한 스킬 시스템에서 스킬 로직을 데이터 모양으로 표현할 수 있게 만들고 이 데이터를 엑셀 모양으로 만들어 게임을 제어하게 하는 모양으로 개발하는 과정을 소개했었습니다. 또 한때 현대 게임 개발에서 엑셀의 구려 터짐을 알면서도 이를 사용하고 있을 수밖에 없는 이유를 이야기한 적도 있습니다. 잠깐 이 이야기들을 소개하면 엑셀은 먼 옛날부터 데이터 입력에 사용하던 도구인데 스프레드시트 모양은 이해하기 쉽고 여러 데이터를 편집하기 편하며 별도로 거의 교육하지 않아도 사용 방법을 잘 알고 있는 소프트웨어인 데다가 스스로 계산 기능도 있고 스스로 스크립팅 환경도 가지고 있는 나쁘지 않기 때문에 이를 개발에 활용해 왔습니다. 하지만 범용 도구이다 보니 입력한 데이터가 올바른지 바로 확인할 수 없고 스프레드시트 모양으로 펼쳐 놓을 수 있는 데이터 모양이 아니면 엑셀에 표현하기 어려우며 언리얼 엔진 같은 현대적인 개발환경에 잘 붙지 않는 등의 이유 때문에 장점만 있다고 하기는 어렵습니다.

이런 배경에서 한번은 우리의 프리프로덕션 단계의 개발 상황을 보긴 주니어님이 자신이 이전에 경험했던 꽤 괜찮은 데이터 작업 파이프라인을 제안하시겠다고 하셔서 제안을 부탁 드렸습니다. 프로젝트에 따라 데이터 파이프라인을 프로젝트 처음부터 정립하고 시작할 때도 있고 프리프로덕션이 지난 다음에 정립할 때도 있었습니다. 가령 전에는 시작부터 우리가 만들어야 할 제품의 전체 크기를 어느 정도 예측할 수 있었기 때문에 처음부터 데이터 파이프라인을 정립하고 시작했음. 그래서 오히려 아직 데이터를 사용할 곳이 아직 개발되지는 않았지만 데이터 컨버터 개발부터 시작하기도 했습니다. 반면 이번에는 우리가 만들어야 할 제품의 전체 크기를 예측하기 쉽지 않았기 때문에 우선 우리가 당장 사용할 수 있는 데이터 파이프라인을 우선 사용하고 팀 크기나 제품의 규모가 어느 정도 가늠 되기 시작할 때 여기에 어울리는 데이터 파이프라인을 설계할 작정이었습니다.

이 말은 프리프로덕션 단계에서는 커다란 MMO 개발팀이라면 당연히 갖추고 있을 예쁜 데이터 파이프라인을 갖추지 않은 상태로 개발을 하고 있다는 의미입니다. 조금 더 날것 그대로를 설명하면 엑셀로부터 시작해 컨버팅 도구와 데이터 밸리데이션 과정, 빌드에 적용하는 단계 등이 잘 정립되어 있지 않고 각 기능을 개발하는데 관여한 사람들의 취향에 따라 어느 부분은 엑셀로, 어느 부분은 언리얼 데이터에셋이나 블루프린트로 개발 되어 있는 상황입니다. 이 상태는 미래에 프로덕션 단계로 접어들 때 정리할 대상이기는 했지만 그 정리가 두려워 프리프로덕션 단계의 개발에 영향을 끼치게 할 생각이 없었고 어차피 프로덕션을 시작하며 한번 정비해야 할 대상이라고 생각했기 때문에 지금의 우리 상태를 문제라고 생각하지 않고 있었습니다.

며칠 동안의 문서작업 끝에 주니어님이 제출하신 문서를 보고 이 사태를 어떻게 해야 할 지 고민스럽기도 하고 또 한편으로는 웃기기도 한 미묘하고도 또 불편한 감정상태를 느꼈습니다. 제안된 작업 방식은 대략 엑셀 워크시트 마다 스키마를 선언한 별도 워크시트가 있어야 하고 스키마 워크시트를 읽어 코드를 제너레이팅 해야 하며 스키마에는 값의 타입, 범위, 빈 값을 사용할 수 있는지 여부, 어떤 열거형 데이터를 사용하는지 여부, 다른 테이블과의 연결 정보 등을 스키마 워크시트에 선언하고 이 스키마 워크시트의 정의에 따라 데이터 테이블을 작성하며 엑셀에 작성한 데이터 테이블을 프로그램 관점에서 보다 편하게 접근할 수 있는 방식으로 컨버팅 한 다음 규칙에 따라 밸리데이팅 해서 통합 작업에 포함 시켜 서버와 클라이언트에 동시에 적용하는 식이었습니다.

거칠게 요약하면 개발한 지 오래 된 사람들이 설계한 큰 MMO 개발팀을 위한 파이프라인 설계와 별로 다를 것이 없었습니다. 한편 이 제안에 딱히 틀린 곳은 없어 보였지만 제안에 포함된 데이터 파이프라인의 각 구성요소가 왜 지금의 모양이 되었는지, 왜 기획에서 작성한 스키마 테이블을 프로그램이 읽어 코드를 제너레이팅 해야 하는지 등에 대한 이유를 설명할 수는 없는 상태여서 이제는 슬슬 웃기기보다는 이 상황을 어떻게 수습해야 할 지에 대한 생각으로 머릿속이 복잡해졌습니다.

엑셀은 분명 나쁘지는 않은 데이터 입력 도구이지만 오직 이 이유만으로는 현대 개발의 복잡성에 대응하는데는 무리가 있다고 생각합니다. 우선 엑셀은 편안한 작업환경을 유지하기 위해서는 엑셀 파일 형식으로 저장할 수밖에 없는데 이는 필연적으로 엑셀을 사용하지 않을 때는 필요하지 않은 데이터 변환 과정을 요구합니다. 이론적으로 엑셀을 XML이나 JSON 같은 형식으로 변환한다고 해서 문제가 일어날 여지가 없지만 실제로 개발을 해 보면 이 변환 과정 자체에도 온갖 이상한 일들이 일어날 여지가 있습니다. 그래서 이런 변환 과정은 정말로 필요하지 않은 이상은 웬만하면 만들면 안 됩니다.

또 엑셀은 나머지 개발환경과는 동떨어져 따로 동작하기 때문에 입력 즉시 값을 확인하거나 애초에 조건에 맞지 않는 값의 입력을 막기 어렵습니다. 불가능하지는 않지만 나머지 개발 환경과 엑셀을 연결하기 위한 별도 개발이 필요합니다. 위에서 엑셀을 입력 도구로 사용하는 이유 중 인하우스 도구의 우선순위가 낮아져 인하우스 도구가 유지보수 되지 않는 상황을 종종 겪다 보니 인하우스 툴의 생산성이 더 높음을 알면서도 굳이 엑셀을 고집하게 되는 상황을 소개했는데 그렇다고 해서 엑셀이 좋다는 이야기는 아닙니다.

또 엑셀을 데이터 입력 도구로 계속해서 사용하다 보면 머릿속에서 오직 엑셀로 표현할 수 있는 모양의 데이터만을 상상하게 됩니다. 여러 테이블이 연결된 관계형 데이터베이스나 아무 곳에나 배열을 추가할 수 있는 몽고DB 스타일의 데이터 모양을 상상하기 어렵고 또 이런 데이터 모양을 생각했다 하더라도 엑셀에는 쉽게 표현하기 어려운 더 쉬운 방법을 두고 항상 2차원 모양으로 표현하기 편안한 방법만을 고려한 이상한 데이터 모양을 만들기 쉽습니다.

근본적으로 데이터 입력 후 값을 검증하는 과정은 데이터 입력을 엑셀로 했기 때문에 필요한 과정입니다. 우리가 여러 고객을 대상으로 한 소프트웨어를 개발한다면 클라이언트에서만 값을 확인하는 건 좋은 결정이 아닙니다. 하지만 개발에 사용할 인하우스 도구를 만든다면 클라이언트에서만 확인해도 그리 나쁜 결정이 아닐 겁니다. 만약 엑셀 대신 언리얼 데이터에셋을 사용해 데이터를 입력 받는다면 처음부터 조건에 맞지 않는 값을 입력할 수 없습니다. 스켈레탈 메시를 넣는 자리에는 항상 스켈레탈 메시 경로를 넣을 수밖에 없고 좌표를 넣도록 만든 자리에 엉둥한 텍스트를 넣을 방법이 없습니다. 텍스트를 넣는 자리에 오직 로케일 네임스페이스만을 넣을 수 있게 설정했다면 여기에 엉뚱한 데이터를 넣을 방법 역시 없고요. 그래서 일단 데이터를 입력하는데 성공했다면 굳이 이 데이터를 형식적인 방법으로 밸리데이션 할 필요도 없습니다. 형식적인 밸리데이션이 필요한 이유는 데이터를 엑셀로 입력했기 때문입니다.

주니어님의 제안으로 돌아가 이 제안은 제안 자체만으로는 딱히 틀리지 않았지만 프리프로덕션 단계나 프로덕션 단계 같은 개발 진행 상황의 맥락에 대한 몰이해와 데이터 입력, 변환, 검증, 통합, 적용 같은 각 단계가 있음을 알고는 있지만 각 단계가 왜 필요한지, 실제로 어떤 동작이 일어나는지에 대한 이해는 극도로 부족한 신기한 제안이었습니다. 제안 자체가 틀리지는 않았지만 우선 개발 단계에 처한 맥락에 근거해 지금 당장 이 제안을 받아들일 이유가 없고 개발이 다음 단계로 진행될 때 지금보다 더 우리가 만들어야 할 제품의 규모와 우리 팀의 크기와 역량을 더 잘 알게 되었을 때 협의를 통해 구체적인 절차와 방법을 정의하게 될 겁니다. 이를 설명하고 최소한 각 단계의 의미와 실제 동작을 스스로 파악하는데 시간을 사용하도록 해야겠다는 생각이 들었습니다.