[글 쓰는 엔지니어] 아무도 몰라주는 프로그램 개발자로서의 삶, 6부 엔지니어에게 필수적인 비주얼 베이직 (VBA)

 

 

처음부터 제가 접근을 잘못했던 모양이었습니다. 기존 프로그램을 대체하려면 기존 프로그램과 완전히 동일한 결과값부터 나오게 한 뒤 사용자가 자유롭게 입력 값을 변경하도록 했어야 했습니다. 그래야만 두려움과 우려를 불식시키고 신뢰도를 높일 수 있었기 때문입니다. 그래서 저는 포기하지 않고 처음부터 다시 시작했습니다. 어떻게든 계산서의 결과 값에 대해 엔지니어가 검증하고 책임지도록 하고 싶었습니다. 그때는 그런 개념을 몰랐지만 지금 생각해 보면 저는 역설계 (Reverse Engineering)를 적용했습니다. 포트란으로 만들어진 프로그램을 그야말로 후벼 파기 시작했습니다. 리습 (LISP)으로 단련된 프로그램 언어에 대한 감각 덕분에 분명 입력 값들을 가지고 단순히 계산만 할 뿐일 것이라고 확신했습니다. 입력 값과 결과 값을 프린트해서 손으로 쓰고 계산기를 두드려 보며 프로그램의 구조와 알고리즘을 파악해봤습니다. 역시 대부분 단순 계산이어서 쉽게 풀어나갔습니다. 그러다가 한 두군데 정도에서 막혔습니다. 공식을 넣어서 단순 계산한 것이 아니었습니다. 계산서만 봐서는 도저히 알 길이 없어서 관련 설계 이론들을 뒤져봤습니다. 그랬더니 오래 된 이론 중에서 시행착오를 통한 근사값을 찾는 방법이 있다는 것을 알게 되었습니다. 손으로 풀었다면 고차 방정식을 풀면 되는데 포트란으로 하다 보니 어쩔 수 없이  시행착오를 통해 해를 찾는 방식을 적용한 것으로 보였습니다. 여기에는 반드시 오차가 있을 것이라고 봤습니다. 왜냐하면 직접 해를 찾으면 정확한데 반해, 근사치로 찾게 되면 프로그램은 무한 루프를 돌게 되므로 시행착오 도중 어느 순간을 해라고 인식할지 개발자가 미리 정의를 해놓아야 하기 때문입니다.

 

반응형

 

모든 것을 파악한 순간 속으로 유레카 (Eureka)를 외쳤습니다. 완전히 똑같이 만들어서 시연하기로 결심하고 엑셀을 다시 만들었습니다. 모두가 기존에 하던 방식대로 입력 값을 넣기만 하면 모든 것이 완성되도록 디자인했습니다. 거의 다 만들고 나니 문제가 생겼습니다. 지금은 엑셀에서 추가 기능으로 ‘해찾기’ 기능을 제공하지만 당시만 해도 그런 기능이 없었기 때문에 저도 역시 시행착오 방식을 이용해야만 했습니다. 포트란 프로그램과 똑같이 만드는 것이 목표였기 때문에 반드시 넘어야 할 산이었습니다. 그래서 VBA를 공부했습니다. 단순히 버튼 하나 만들어서 시행착오로 해를 찾기 위해서였습니다. 하나의 값을 입력해보고 특정 조건을 만족하지 않으면 또 다른 값을 입력해보는 무한 루프를 만들고 차이가 얼마 이하면 루프를 빠져나오도록 알고리즘을 만들었습니다. 여기에 필요한 함수들과 기법들을 책을 한 권 사서 공부했고, 응용하고 시도한 후 실패하면 또 다른 방법으로 해보면서 결국 성공했습니다. 리습 (LISP)과 비교하면 함수, 문법, 구성은 조금 달랐지만 결국 프로그램 언어는 비슷한 원리를 가진 논리 언어라는 것을 깨달았습니다. 완벽하게 똑같은 프로그램을 엑셀로 만들어서 다시 상사와 직원들에게 보여줬고 이후로 회사는 불편한 포트란이 사라지고 제가 개발한 엑셀 계산서 프로그램들만 사용하게 되었습니다. 그리고 엑셀 프로그램에 저는 이렇게 썼던 기억이 있습니다. “모두의 불편함을 위해 프로그램을 개발했지만, 결과 값은 입력한 엔지니어의 책임입니다. 손으로 풀어도 동일한 결과 값을 얻지 못했다면 이 프로그램은 절대로 사용하시면 안 됩니다.”

 

첫 VBA 프로그램을 개발한 후 지금까지 약 100여개 정도는 개발한 것 같습니다. 단순한 계산부터 복잡한 분석까지 다양했습니다. 기억에 남는 몇 가지 프로그램 중 하나는 해외 현장 생활을 하면서 월간 경비 사용에 관한 보고 용 프로그램이었습니다. 해외 현장, 특히 신용카드 사용이 자유롭지 못한 곳에서는 어쩔 수 없이 현금으로 매월 현장 경비를 지급 받습니다. 그렇게 되면 매월 말에 경비를 어떻게 사용했는지 증빙자료를 엑셀로 만들어 보고하고 있었습니다. 인터넷이 안 되는 것도 아니고 국내 현장은 다들 회사 내 경비 처리 시스템을 이용하는데 해외 현장은 유독 엑셀로 정리해서 보고하라는 것이었습니다. 너무 불합리해서 본사에 따져봤지만 받아들여지지 않았습니다. 게다가 엑셀은 또 왜 그리 복잡하게 만들었는지 누군가 무조건 실수를 할 수밖에 없도록 해놓아서 더욱 화가 났습니다. 경비가 입금되고 사용하는 단순한 한 가지 raw 데이터를 가지고 각 비용 계정별 문서를 별도로 만들어야 하고, 사용처 별로 또 별도로 만들고, 사용 일자 별로 구분해서 또 만들고, 지난달에 비해 어떤 변화가 있었는지 분석해서 만들고, 분기별 현황은 어떤지 만들고, 다음달 예상은 어떤지 적어야 하고 등 총 20가지 정도의 회계 관련 문서를 만들어야 했습니다. 들어보니 매월 이런 문서 작업에만 꼬박 2일씩 걸리고 매번 틀려서 수정하는데 세월 다 보낸다고 했습니다. 그래서 저는 항상 그래왔듯이 의미 없는 단순 반복작업을 할 수는 없어서 VBA로 만들어 보기로 했습니다. 불합리한 시스템 자체를 개선할 수 없다면, 시스템이 요구하는 바에 완벽하게 부합하는 프로그램을 만들기로 했습니다. Input data는 너무나 단순했습니다. 계좌에 들어온 입금액을 입력하고, 몇월 며칠에 얼마의 금액을 어떤 명목과 계정으로 사용했는지만 쓰면 되고, 그런 것들은 가계부 쓰듯이 매일 적는 것이어서 큰 일도 아니었습니다. 그렇게 입력만 하면 각각의 양식으로 미리 작성된 템플릿들을 탭으로 추가하여 루프로 돌아다니며 입력 값들을 적절히 분배만 잘해주면 되고 마지막에 모든 탭들을 각각의 엑셀 파일로 내보내서 저장만 하면 되는 알고리즘이었습니다. VBA 개발에 필요한 부분만 골라서 공부했고 시도해보고 실패하면 또 해결하고 하면서 사흘 만에 개발을 완료했습니다. 결과는 대성공이었습니다. 남들이 매월 이틀씩 걸릴 일을 저는 혼자서 매월 1분이면 가능하도록 했습니다. 게다가 가장 중요한 것은 휴먼 에러 (Human Error)에 의한 실수를 원천적으로 차단했다는 점이었습니다.