[글 쓰는 엔지니어] 아무도 몰라주는 프로그램 개발자로서의 삶, 5부 비주얼 베이직 (VBA)을 시작한 이유

 

 

며칠에 걸쳐 리습 (LISP)을 제가 독학하게 된 계기에 대해 얘기했습니다. 저도 몰랐지만 태생적으로 단순 반복 작업을 싫어했던 성격, 불합리함을 견디지 못하는 성향, 실패한 경험으로부터 얻은 교훈을 다시 실패하지 않기 위한 에너지로 사용해야 한다는 신념 탓에 필사적으로 독학했다고 말할 수 있을 것 같습니다. 다른 좋은 말 다 빼고 얘기하면, 그냥 야근이 너무 싫었습니다. 어차피 해야 할 야근이라 해도 좀 편안하게 일하고 싶었습니다. 사실 이렇게 불합리한 시스템을 개선하고 조직의 생산량과 업무 효율이 증가하면 승진이나 성과급을 많이 받았어야 했는데 저는 그런 것에 관심이 없었습니다. 오히려 시간 여유가 많아지니까 업무만 늘어났습니다. 여기저기서 도와달라는 부탁도 많았고, 일하는 모습을 지켜보다가 제가 안타까운 마음에 도와준 적도 많았습니다. 지금 생각해 보면, 좀 더 여우처럼 잔머리도 좀 굴리고, ‘속물’로 돈도 좀 밝혀보면서 제 자신을 좀 더 지켰어야 했나 싶은 생각이 들기도 합니다. 하지만 아마 다시 돌아가도 저는 똑같이 행동했을 것 같습니다. 원래 성실하고 우직하게 일만 하는 곰 같은 엔지니어라서 그런 것이니 같은 상황이면 어쩔 수 없을 것 같습니다. 이런 저 때문에 가족들이 고생이라서 항상 미안한 마음 뿐입니다.

 

오늘은 비주얼 베이직 얘기입니다. 그런데 이상하다고 생각하시는 분들이 계실 수 있습니다. 비주얼 베이직은 영어로 Visual Basic이고 VB로 줄여서 부르는데 저는 VBA, Visual Basic for Application이라고 부르기 때문입니다. 굳이 제가 구분하는 이유는 제가 독학한 비주얼 베이직은 애플리케이션 용 비주얼 베이직이기 때문입니다. 무슨 말이냐면, 비주얼 베이직은 마이크로소프트가 윈도우 기반으로 개발한 언어인 반면에 VBA는 윈도우 안에서도 소프트웨어에 특화된 언어라는 의미입니다. 마치 제가 VB를 한다고 하면 윈도우 전반을 아우르며 프로그램을 개발하는 것처럼 비춰질 수 있기 때문에 저는 그게 아니고 VBA를 할 줄 안다고 얘기하는 것입니다. 물론 같은 언어인 비주얼 베이직을 사용하므로 제가 하려고 마음만 먹으면 VB로 소프트웨어를 아예 하나 만들 수도 있겠지만 아직 그럴 필요성을 느끼지 못했기 때문에 VBA로 충분히 만족하고 있습니다. 그래서 좀 복잡하지만 한글로는 그냥 비주얼 베이직, 영어로는 VBA로 쓰고 있으니 양해해 주시기 바랍니다. 대학 1학년 때 DOS 시절 베이직을 구경은 해본 적 있지만 공부할 필요성을 못 느꼈고 배울 기회도 사실 없었습니다. 아마 그때 제가 C 언어를 공부했다면 완전히 다른 인생을 살고 있을지도 모르겠습니다.

 

반응형

 

제가 VBA를 독학한 이유는 토목 엔지니어들이 사용하는 구조 계산과 수리 계산 때문이었습니다. 당시 모든 토목 엔지니어들이 사용하는 구조 및 수리 계산 용 프로그램들이 있었습니다. 누가 만들었는지도 모를 만큼 오래된 무료 공개 프로그램이었고 누구나 사용하고 있던 프로그램들이었습니다. 저도 신입 때 맨 먼저 그 프로그램들을 사용하는 방법을 배우고 또 다른 친절한 누군가가 만들어 놓은 매뉴얼을 보며 공부해야 했었습니다. 프로그램들 모두 오래된 포트란 (Fortran) 언어로 만들어졌고 윈도우 시절임에도 DOS 상에서만 구동되고 있었습니다. 짧은 시간에 마쳐야 하는 설계 프로젝트의 특성 상 어쩔 수 없이 사용은 하고 있었지만 저는 계속 불만이었습니다. ‘이 프로그램은 과연 완벽한가’에 대한 의문 때문이었습니다. 엔지니어인 제가 직접 계산한 것이 아니라 남의 손을 빌렸으니 검증을 할 수가 있어야 하는데 누군가 결과 값이 왜 이러냐고 물으면 프로그램 계산 결과라서 저도 모른다고 답할 수밖에 없었습니다. 이런 방식의 가장 큰 문제는 엔지니어가 결과에 책임을 질 수 없다는 점이고, 더 나아가 이대로 설계에 적용하면 설계 기준보다 과한지 부족한지 알 길이 없다는 것입니다. 중간 계산 과정에서 상수와 변수의 소수점 하나의 차이로도 관경과 철근의 직경이 바뀔 수 있기 때문에 계산 과정은 반드시 투명하게 검증되어야 합니다. 게다가 입력 값을 작성하는 일이 생각보다 쉽지 않았고, 왜 넣어야 하는지 모를 의미 없는 숫자들을 양식에 맞춰 그냥 넣어야 하는 일도 있었습니다. 그래서 당시 상사에게 물어봤습니다. “이 프로그램으로 계산한 결과를 우리가 100% 신뢰할 수 있나요?”라고요. 그랬더니 그 분은 “세상 사람들이 다 쓰는 프로그램인데 문제가 있었으면 벌써 무너졌거나 물이 넘쳤겠지.”라고 답했습니다.

 

저는 충격을 받았습니다. 엔지니어는 이렇게 일하면 안 된다고 생각했기 때문입니다. 제 손을 거쳐 내보낸 설계는 온전히 제 것이어야 하고 제가 책임을 져야 하는데 도저히 납득할 수가 없었습니다. 세상 어느 프로그램을 사용하든 결과 값은 제가 책임져야 한다고 생각했습니다. 왜냐하면 저는 엔지니어이기 때문입니다. 그래서 저는 가장 먼저 설계 기준에 완벽하게 맞는 엑셀 계산서를 만들었습니다. 완전히 새로운 방식으로 만들어서 입력하기도 편하고, 어떤 설계 기준에도 어긋나지 않는 계산서였으며, 누구나 검증할 수 있도록 셀의 계산식을 매뉴얼로 친절하게 설명까지 곁들여 만들었습니다. 만들어서 직원들에게 공유했더니 반응은 의외로 좋지 않았습니다. 일단 신입 엔지니어가 만든 프로그램이라서 신뢰도가 떨어졌고, 가장 큰 문제는 다들 기존의 프로그램을 왜 대체해야 하는지에 대해 필요성을 딱히 느끼지 못하고 있었다는 점이었습니다. 그리고 설계 기준에는 어긋나지 않지만 기존 프로그램과 결과 값이 약간이지만 차이가 나는 것에 두려움을 갖고 있었습니다.