아직도 VBA를 가르친다고?

2년 전에 '기획자가 프로덕션에 VBA 쓰면 안돼요!'라고 한 적이 있습니다. 게임 개발의 여러 부분에 엑셀을 사용하고 또 엑셀 사용자들 모두에게 현대적인 엑셀 개발 환경을 교육할 여유가 없다면 VBA는 서기 2023년에도 여전히 엑셀이 제공하는 기능 이상의 뭔가를 상상할 때 처음으로 고민하게 되는 기술이기는 합니다.

한편 그런 장점에도 불구하고 VBA에 의한 결과가 프로덕션 파이프라인에 관여하는 순간 여러 가지 슬픈 일이 일어납니다. 소스 버전 관리가 안 되어 유지보수가 어렵고 숙련되지 않은 작업자가 위험한 코드를 쉽게 사용할 수 있고 여느 코드와 마찬가지로 문서화가 잘 되지 않아 담당자가 없으면 아주 작은 문제에도 쉽게 피해를 입으며 인터페이스와 로직의 경계가 흐릿한 오래된 개발환경의 특성 상 유지보수가 급격히 어려워지는 단계에 쉽게 진입합니다.

이런 상황에서 VBA의 결과물이 프로덕션 파이프라인에 관여하면 기획팀은 현대에 코드를 작성하는 분들이 사용하는 현대적인 도구의 도움을 받지도 못하면서 업데이트 일정에 따라 제한 시간에 쫓기며 더 불리한 환경에서 코드를 만들면서도 작업 시간을 잘 인정 받지도 못하는 물리적으로나 정치적으로나 아주 불리한 상황에 쉽게 처하게 됩니다. 그래서 이전에는 프로덕션에 VBA를 적용해서는 안된다고 약하지는 않은 어조로 이야기했습니다.

한번은 어느 회사 면접에 갔는데 이 글을 읽은 면접관님이 ‘아니 개발 하다 보면 VBA좀 쓸 수도 있는 것 아닌가요?’ 라고 하셔서 면접 보다 말고 깊은 고민을 시작했습니다. 여기서 이 사람에게 프로덕션 파이프라인에 VBA를 사용할 때 겪을 수 있는 위험성을 하나하나 설명할 것인가, 아니면 VBA를 좀 사용할 수도 있지 않느냐는 면접관님의 입장을 대강 따르는 척 하며 이 위기를 모면해야 할 지 입으로는 다른 말을 하며 시간을 벌고 머릿속으로는 한참 생각합니다. 그리고 면접관님의 말에 동의한다는 의미로 고개를 끄덕이며 현대에는 좀 더 선정적인 제목을 선택해야 사람들에게 관심을 더 받을 수 있는 것 같다고 하면서 그런 관점에서 설정한 제목이라고 말하며 다른 주제로 넘어갔습니다. 실은 제목은 내 관점에서 전혀 선정적이지 않았고 여전히 제목과 같은 생각을 하고 있습니다. 이 면접 결과가 어땠는지는 비밀입니다.

한편 지난번에 생각을 남겨 놓고 나서 2년이 넘게 지났는데 지금도 여전히 VBA가 프로덕션에 개입해서는 안된다고 생각합니다. 프로덕션에 개입해서는 안된다고 선을 긋는 이유는 프로덕션 환경이 아니라면 오피스만 인스톨하면 아무 설정 없이 즉시 사용할 수 있는 이 20년도 넘은 개발환경이 여전히 일단 시작하기에는 편하고 엑셀에서 직접 지원하지 않는 귀찮은 계산을 적어도 겉보기에는 단순하게 만들 수는 있다고 생각하기 때문입니다. 다만 이걸 프로덕션에 사용해서는 안될 뿐입니다.

한번은 이전에 함께 일한 적이 있는 분과 만나 이야기하다가 요즘 주말에 무슨 일을 하는지 이야기했습니다. 주말에 글을 쓰고 운동하고 주중에 알아보려고 적어 놨던 주제를 주말에 리서치하고 넷플릭스 보고 게임하는 등등의 이야기를 했는데 그 분은 요즘 주말에 강남 어딘가에 있는 게임 기획 학원에 다닌다고 하십니다. 개인적으로 게임 기획을 가장 잘 배울 수 있는 방법은 직접 개발팀에 채용되어 개발 하는 거라고 생각합니다. 이보다 더 잘 배울 수 있는 방법은 없습니다. 또 게임 관련 교육기관에 대한 얕은 불신이 있기도 합니다. 교육 기관에서 대체 게임 개발 과정의 어떤 면을 교육할 수 있을지 잘 모르겠습니다.

그래서 교육기관에서 무엇을 배우고 계신지 여쭤보니 게임 밸런싱에 대해서 배우고 있으며 커리큘럼 중 하나로 엑셀 VBA를 배우고 계시다는 말씀을 들었습니다. 잠깐 블리자드 페이스팜이 머릿속에 떠올랐지만 적당히 이야기를 마무리하고 돌아오는 길에 서기 2022년에 VBA의 의미와 그걸 교육기관에서 가르치는 의미에 대해서 생각해 보게 되었습니다.

프로덕션 파이프라인 관점에서는 여전히 VBA는 20년도 넘은 유서 깊고 또 접근하기 쉬운 방법이지만 결코 손 대서는 안된다고 생각합니다. VBA에 손 댈 생각을 하는 사람은 직업 프로그래머가 아닐 가능성이 높습니다. 코드를 능숙하게 다루지 못하는 사람이 만들어진 지 20년은 된 아주 낡은 도구를 사용해 개발해야 하는 상황입니다. 환경이 너무나 열악해 현대적인 힌트, 현대적인 디버깅, 현대적인 실수 방지, 현대적인 성능 개선 등 어떤 도움도 받을 수 없습니다. 굳이 장점을 찾는다면 높은 접근성, 낮은 난이도, 도처에서 찾을 수 있는 자료, 쉬운 배포 정도입니다.

VBA를 사용할 생각을 한 것 자체가 좋은 신호가 아닙니다. 기획에서 엑셀의 기본 기능 바깥에서 계산 방법을 찾아야 한다고 판단했다면 이 판단 자체가 올바르지 않을 수 있습니다. 더 단순한 계산 방법이 있지만 거기까지 고민하기 전에 VBA를 먼저 떠올리는 상황일 수 있고요. 데이터를 더 잘 정규화하고 계산과정의 요구사항을 단순하게 만들다 보면 VBA를 통한 계산을 피할 수 있을 가능성이 높습니다.

또 엑셀로 시뮬레이터를 만들어야 한다고 판단했다면 망한 겁니다. 숫자는 엑셀로 만들지만 숫자가 적용되어 동작하는 코드는 완전히 다른 계산을 통한 결과를 냅니다. 클라이언트 및 서버와 코드를 공유하지 않는 엑셀로 만들어진 시뮬레이터는 시뮬레이터로써 역할을 전혀 하지 못하는 고약한 코드 덩어리일 뿐입니다. 또 엑셀로 데이터 컨버터나 익스포터를 만들어야 한다고 판단했다면 탈출을 진지하게 고민해야 합니다. 어떤 이유로 직업 프로그래머가 담당할 일이 기획팀에 무책임하게 넘어와 있는 상황입니다. 이를 관리자들이 방어하지 못했다면 비슷한 일이 계속해서 일어나 개발 속도가 느려지고 결국에는 전문가의 손에 맡길 부분을 비전문가가 담당하는 상황에 쉽게 도달하게 됩니다.

그럼에도 불구하고 VBA 사용 방법을 익혀 두는 것이 오직 단점만 있다고 생각하지는 않습니다. 위에서 잠깐 설명했지만 접근성이 높고 시작 난이도가 아주 낮습니다. 또 네이버 블로그를 검색해 보면 문제를 쉽게 해결할 자료를 검색해낼 수 있고요. 또 그냥 xlsm 파일을 보내면 끝이라 배포가 아주 쉽습니다. 만약 코드를 만드는 방법을 배워야겠다고 마음 먹은 누군가가 도대체 어디서부터 시작할지 고민이라면 의외로 VBA는 나쁘지 않은 시작이 될 수도 있습니다.

다른 현대적인 언어와 개발환경을 배우는 편에 당연히 더 장점이 많습니다. 하지만 이를 위해서는 윈도우 사용자들 입장에서 별로 익숙하지 않은 커맨드라인 환경과 에디터 설정, 개발환경과 런타임 설치 같은 썩 달갑지 않은 과정이 기다리고 있습니다. 현대에 어지간한 윈도우를 지원하는 개발환경은 이런 과정을 실행파일 하나로 쉽게 처리해주지 않느냐고 할 수도 있지만 실은 썩 그렇지 않습니다. 그런 도구에서 제공하는 표준 시나리오에서 단 한 발자국이라도 밖으로 벗어나려면 결국 복잡한 설정 파일을 오타 없이 수정해야 하고 윈도우 터미널을 관리자 모드로 실행할 방법을 검색해야 합니다. 이런 관점에서 평소에 일하며 사용하던 엑셀에 기반할 뿐 아니라 오피스 환경에서 바로 시작할 수 있고 배포가 쉬운 아주 오래된 개발 환경은 이를 프로덕션 파이프라인에 절대로 적용하지 않는다는 조건 하에는 나쁘지 않은 시작이라고 생각하게 되었습니다.

여전히 VBA를 프로덕션에 적용해선 안된다는 생각은 변하지 않았습니다. 하지만 지금도 VBA를 가르치는 교육기관에 대해서는 그 교육기관이 현대적인 개발 환경을 알아볼 만한 능력이 없을 거라고 지레짐작하면서도 그 교육기관에서 VBA를 배우는 행동이 그렇게까지 나쁘지는 않을 겁니다.