기획자가 프로덕션에 VBA 쓰면 안돼요!

기획자들에게 VBA는 무슨 만능 도구처럼 이야기되곤 합니다. 이전같으면 인간이 직접 더 복잡한 절차에 따라 수행하며 실수를 남발했을 작업을 자동화할 수 있기 때문이라고 합니다. 함수를 만들어 다른 셀, 워크시트로부터 엑셀의 기본기능만으로는 참조하기 어려운 셀들을 참조해 값을 계산한 다음 결과를 돌려받으면 확실히 편리하긴 할 겁니다. 또 값들이 규칙에 맞는지 검사해보는 간단한 코드를 실행해 누군가 실수로 0을 하나 더 넣거나 의도하지 않은 공백문자가 들어있거나 잘못된 대소문자 같은 것을 클라이언트나 서버가 직접 에러를 토해내기 전에 발견할 수도 있습니다. 하지만 개인적으로는 기획자가 VBA를 사용할 줄 알 수도 있을테고 이를 업무에 사용할 수도 있기는 하겠지만 프로덕션에는 사용하지 않도록 가이드하고 있습니다.

일단 우리들은 훈련받은 전문 프로그래머가 아닙니다. 우리들이 순차, 반복, 조건의 개념을 익혀 나 대신 기계가 작업을 수행하는 코드를 만들 수 있기는 합니다만 우리들의 주 업무는 코드를 만드는 일이 아닙니다. 때문에 우리가 만든 코드가 생각대로 움직여줄지 판단하기 어렵습니다. 전문 프로그래머들은 여러 대비책을 가지고 있습니다. 코드리뷰를 하고 테스트케이스를 만들고 협업을 위한 코딩 컨밴션을 지키고 또 안전한 동작을 어느 정도 보장하기 위한 규칙에 따릅니다. 하지만 기획자들의 VBA 코드는 위험하기 짝이 없게 돌아갑니다. 인자로 전달받은 값이 항상 미리 정해둔 모양일 거라고 기대하고 값을 가져올 셀에 항상 값이 있을 거라고 가정합니다. 코드를 통해 만들어낸 결과가 정상적일지 검사하지도 않고 그냥 파일에 저장하기 일쑤입니다. 이 코드는 한동안은 잘 동작하겠지만 업데이트 전날 우리를 배신할겁니다.

기획자가 VBA를 사용해야겠다고 판단했다면 그건 데이터나 계산방식 설계가 잘못됐다는 신호로 받아들여야 합니다. 값을 계산하기 위해 다른 워크시트에서 조건에 맞는 값을 가져와야 하는데 이 과정을 엑셀 기본 함수만으로 처리할 수 없다면 내 판단이 잘못됐거나 데이터구조가 지금 할 작업에 맞춰 설계되지 않았거나 지금 생각해낸 작업방식이 잘못된 것일 가능성이 있습니다. 우리는 쉽게 복잡한 작업방식을 떠올립니다. 지금 이 순간에는 그 방법이 맞다고 생각하겠지만 딱 일주일만 지나면 그렇지 않다는 것을 알게됩니다. 복잡한 방법은 그 자체로도 문제고 방법을 문서로 관리하지 않으면 아무도 정확한 동작을 모르는 코드 덩어리가 되기 십상입니다. 또 이 방법이 정상적으로 동작하고 있는지 판단하기도 어렵습니다. 프로그래머들 역시 이런 상황을 겪곤 하는데 이들은 그나마 이런 상황을 피하기 위한 습관들을 가지고 있습니다. 조건문을 여러 개 겹쳐 깊게 사용하지 않는다든지 방법이 복잡해지면 이를 분리해서 전처리과정을 만들곤 합니다만 기획자가 작성한 코드에 이런 대비가 되어있을 거라고 예상하기는 어렵습니다. 코드를 사용할 생각을 하기 전에 구조와 방법이 올바른지 먼저 고민해야 합니다.

마지막으로 기획자가 VBA를 사용해야 한다고 판단했다면 팀 간의 협업 과정 어딘가에 문제가 생긴 신호로 받아들여야 합니다. 시대는 여러 가지 일을 할 수 있는 사람을 원한다고 알려져 있지만 실제 팀에는 어느 정도 각자의 전문 영역이 구분되어 있습니다. 기획자는 로드맵을 작성하고 요구사항을 문서화하고 개발과정을 지원합니다. 엔지니어들은 요구사항을 실제로 구현해내고 아티스트들도 발주받은 리소스를 요구사항에 맞게 제작해냅니다. 기획자가 자신의 작업을 진행하는데 코드가 필요하다면 먼저 각자의 역할에 맞춰 코드를 전문적으로 작성하는 사람들에게 상황을 설명하고 도움을 받아야 합니다. 기획자가 생각하는 코드는 전문 프로그래머가 생각하는 코드와는 구성도 효율도 유지보수 가능성도 비교가 되지 않습니다. 하지만 이럼에도 불구하고 기획자가 직접 코드를 만들어야 한다면 팀 간에 작업을 문의하고 요청하는 과정이 없거나 붕괴되었거나 팀 간에 신뢰가 부족해 서로의 전문영역을 질문하기 어려운 분위기일 수 있습니다. 프로젝트가 원활하게 진행되지 않고 있다는 신호일 수 있습니다.

실은 이 외에도 기획자가 사용하는 도구는 프로그래머들이 사용하는 도구에 비해 어처구니없을 정도로 후집니다. 그들이 사용하는 코딩, 디버깅, 테스팅 환경에 비해 기획자들이 엑셀에서 사용하는 코드에디터는 대략 25년전에 멈춰있습니다. 지금도 동작하기는 하지만 그따위 에디터로 코드를 작성하는건 지금 효율적이지도 않고 안전하지도 않습니다. 하지만 이건 일단 기획자가 코드를 작성하기 시작한 이미 잘못된 상황 속에서 일어나는 일이므로 더이상 설명하지는 않겠습니다.

결론. 기획자가 코드를 만들어야 하는 상황이라고 판단했다면 이 판단이 잘못되었을 가능성이 있습니다. 설계가 잘못되었거나 협업 체계가 붕괴했다는 신호일 수 있습니다. 엑셀의 코드에디터를 열기 전에 다른 점을 먼저 의심하세요.