엑셀 매크로 포트폴리오

xlsm 파일을 제출해주시면 실행하지는 않고 코드만 읽습니다.

엑셀로 만든 전투, 경재 시뮬레이터는 상황에 따라 미리 입력해 놓은 값을 기반으로 계산을 수행해 결과를 보여주는 기능을 만들어낼 수 있음을 알릴 수 있는 좋은 방법이기는 합니다만 연차가 오를 수록 단순히 이 시뮬레이터를 제출하는 것만으로는 경쟁력이 부족합니다.

포트폴리오에 엑셀 매크로 문서를 첨부해 주시는 분들이 계십니다. 거의 대부분이 전투 시뮬레이터나 경제 시뮬레이터를 만들어 주셨습니다. 대부분 비슷한 동작을 합니다. 게임에 등장하는 각 개체들의 전투 관련 수치들을 워크시트 하나에 정리해놓고 전투할 두 개체를 입력하면 스크립트에 작성해 놓은 전투 규칙에 따라 전투를 수행해 각 턴에 대미지를 얼마나 입히는지, 장착한 아이템에 따라 대미지가 어떻게 변하는지, 최종 승패가 어떻게 되는지를 로그 모양으로 보여줍니다. 이 정도가 딱 기본인데 여기서 수준이 조금 더 올라가면 같은 전투를 여러 번 반복한 결과를 종합해 통계 수치를 보여주거나 플레이어가 성장을 거듭하며 같은 사냥터에서 플레이가 어떻게 변해갈지를 보여주기도 합니다. 사실 여기까지 오면 단순히 엑셀을 다룰 수 있음을 넘어서서 시뮬레이터가 실제로 개발과정에 어떻게 이용되는지를 이해하고 있다고 가정할 수 있다고 생각합니다.

요즘 세상에 엑셀 시뮬레이터만으로는 경쟁력이 부족합니다. 작은 연차일 때는 엑셀 시뮬레이터를 만들어 엑셀로 이 정도 결과를 만들어낼 수 있음이 경쟁력이 될 수도 있지만 거기서 시간이 더 흐르면 엑셀 시뮬레이터를 제출하시면 좀 곤란합니다. 아직까지도 이걸 만들어 제출하는 행동이 자신의 경쟁력이 될 수 있다고 가정하시면 위험합니다. 적어도 안전하지 않습니다.

엑셀 시뮬레이터를 만드는 이유는 전체 개발 플로우 상에서 밸런스를 맞춰야 할 때입니다. 플레이를 반복해 밸런스를 맞춰야 하는 상황이라면 반복 플레이의 최종 목표는 이를 근거로 게임에 올바른 숫자들을 집어넣는 겁니다. 일정 수준 이상의 보상감을 유지하기 위해 힘을 뺄 부분과 힘을 줄 부분을 잘 분배해서 배치하려 한다면 제한된 시간 안에 수많은 반복 플레이를 통해 게임 내 개체들과 플레이어 사이의 전투가 의도한 대로 일어나는지 확인하고 의도와 다르다면 이들을 수정해야 합니다. 수치를 수정할 수도 있고 공식을 수정할 수도 있습니다. 여기서 반복 플레이에 시간이 너무 많이 걸리고 또 소모적이라고 느낀다면 시뮬레이터를 만들어 소모적인 부분을 자동화하고 감각적인 판단을 수치에 의존한 판단으로 바꿀 수도 있습니다. 여기에 시뮬레이터가 필요합니다. 그런데 시뮬레이팅을 하더라도 결과는 다시 변경된 수치여야 합니다. 시뮬레이터를 만든 다음에는 이를 여러 번 구동해서 얻은 통계를 정리하고 이 통계가 의도와 얼마나 다른지를 판단해야 하며 이 판단 결과에 따라 게임을 어떻게 바꿨는지에 대한 과정을 설명할 수 있어야 합니다. 단순히 시뮬레이터를 만들 수 있다는 주장만으로는 경쟁력이 부족합니다. 엑셀 시뮬레이터는 시뮬레이터 사용 전후의 맥락을 함께 제시할 수 있어야 경쟁력을 가지게 됩니다.

엑셀로 시뮬레이터를 만드는 이유는 근본적으로 프로그래머와 밸런스 협업이 잘 되지 않기 때문입니다. 엑셀 시뮬레이터는 실제 전투를 처리하는 코드와 유리되어 있어 위험합니다. 작은 실수만 해도 서버에서 수행하는 연산과 기획자가 엑셀에 구현한 연산에 차이가 생겨 엉뚱한 결과를 보고 밸런싱을 하게 될 수도 있습니다. 이런 위험을 근본적으로 해결하는 방법은 서버에서 수행하는 연산을 그대로 사용하는 시뮬레이터를 만드는 겁니다. 하지만 마일스톤 계획에 맞춰 온갖 기능을 맥락 없이 마구 구현해야 하는 현실 속에서 서버 프로그래머와 기획자가 이런 이터레이션을 진행하는데는 한계가 있습니다. 기획자가 이런 필요와 이 필요를 달성하기 위해 프로그래머가 무슨 일을 해야 하는지 제시하기 어렵고 또 눈에 보이는 ‘기능’이 아닌 것을 구현하는데 자원을 소모하는데 동의하기도 쉽지 않습니다. 후자는 좀 더 단위가 큰 근본적인 문제이지만 여기서는 어쩔 수 없다고 하고 넘어가겠습니다.

이 상황에서 그나마 기획자는 자신이 문서에 적었던 연산공식을 바탕으로 엑셀 시뮬레이터를 만들지만 이 시뮬레이터의 결과가 서버 측 연산과 동일할 거라는 보장이 없고 이를 검증하기도 쉽지 않습니다. 때문에 엑셀 시뮬레이터를 제출한다면 시뮬레이터를 만들어야만 했던 상황, 시뮬레이터가 가지고 있는 근본적인 한계를 어디까지 인식하고 이를 극복하거나 한계를 설정한 이야기를 제시할 수 있어야 합니다. 이 이야기가 빠져있다면 앞에서와 마찬가지로 단순히 엑셀로 뭔가를 만들 수 있다는 것 이상의 경쟁력을 가지기는 어렵습니다.