컨설팅에 대해 많은 이야기를 했는데 실은 저는 컨설턴트라는 직업 이전에 꽤 오랫동안 훌륭한 개발자가 되기를 꿈꾸었던 사람이었습니다. 저의 경우에는 처음 중학교 3학년 겨울방학 때 COBOL을 배우기 시작했는데 그 전부터 프로그램에 어느 정도 관심을 가지고 있었으나 이를 계기로 저의 개발자로의 꿈이 시작되었다고 보는 것이 맞는 것 같습니다. 아마 그렇게 된 것은 여러 가지 원인들이 복합적으로 작용했다고 생각하지만, 제가 처음 배울 때 저에게 프로그램이라는 과정을 알려주신 분들이 너무나도 훌륭하게 보였던 거 같습니다. 또한, 프로그램을 배울 때 비교적 원론에 충실하게 배웠던 것도 제가 프로그래밍이라는 과정에 매혹되었던 이유 중 하나였던 것 같습니다.

제가 당시 배웠던 COBOL이라는 언어는 메인 프레임이라는 장비를 통해 운영이 되었었고 상당히 비싼 장비였기에 지금의 PC처럼 개인이 직접 모든 것을 통제하는 것이 아닌 일괄처리방식에 의해서 운영되던 장비였습니다. 좀 쉽게 설명하자면, 미리 프로그램들을 대기시켜 놓고 하나의 프로그램이 종료되면 다른 프로그램들을 구동시키는 방식이어서 개인이 직접 운영을 할 수 없었던 시스템이었습니다. 게다가 당시만 하더라도 PC가 상당히 고가에 속하는 장비였기에 개인마다 다 지급이 되는 것은 생각할 수 없었던 시기라 제가 프로그래밍을 배울 때는 종이와 연필 그리고 지우개를 가지고 프로그래밍을 배웠습니다. 조금 황당하게 생각하실지도 모르겠지만 그 당시를 저에게 프로그래밍을 가르쳐주셨던 분들은 머리 속으로 디버깅(프로그래밍 과정에서 문제점을 찾아내는 과정)까지 가능했던 분들이었기에 그 당시 저로서는 프로그램을 할 때 종이와 연필을 가지고 하는 것을 당연하게 생각했던 것 같습니다.

그 당시 프로그램을 배웠던 과정을 잠시 소개하면 일단 프로그램의 진행과정을 설계한 뒤에 종이 위에 프로그래밍을 하면 다른 분이 잘못된 부분을 점검하고 문제가 없으면 이를 노란 종이로 만들어진 천공카드에 입력하는 과정을 거치게 됩니다. 그 다음 천공카드에 기입된 내용이 프로그래밍 코도와 일치하는지를 검수하는 과정을 거친 후 문제가 없다면 카드리더기를 통해 메인 프레임에 대기상태로 들어가게 되고 차례를 기다려서 프로그램이 돌게 되면 그 처리결과를 프린터를 통해 받을 수 있었습니다. 이렇게 복잡한 방식으로 프로그래밍을 배웠기에 한번 프로그램을 수행한다는 것은 상당히 많은 과정을 거칠 뿐만 아니라 시간적으로 꽤 오래 걸렸기에 프로그램을 수행하기 전 사전에 발생할 수 있는 다양한 문제점을 미리 시뮬레이션 할 수 있는 능력은 프로그래밍에 있어서 매우 중요한 과정 중에 하나였습니다.

따라서, 이런 과정들을 수없이 반복하였던 분들이 저의 선생님들이었으니 머리 속에서 디버깅을 하는 것은 어쩌면 너무나도 당연한 일이었던 것 같습니다. 지금은 좋은 컴파일러를 통해 프로그램을 점검할 수 있어서 너무 편하게 프로그래밍을 할 수 있지만, 제 생각에는 프로그래밍을 하기 전에 PC 앞에 앉아서 프로그램을 하는 것이 좋은 습관은 아니라고 생각합니다. 프로그램의 길이가 짧은 경우에는 이런 방식도 문제가 없을 수 있으나 큰 프로그램의 경우 문제가 발생할 소지가 다분히 있고 또한, 프로그램을 설계하는 과정이 남지 않기 때문에 다른 분들이 어떤 과정을 통해 이 프로그램들이 만들어졌는지 알 수 없기 때문입니다.

제 개인적인 생각이기는 하나 그 당시 제가 배웠던 방식이 어쩌면 지금 유명하고 있는 페어 프로그래밍 방식이나 테스트 팀을 통해 QA를 하는 과정과 상당히 유사하다는 생각이 듭니다. 물론, 페어 프로그래밍 방식은 각자 프로그램을 해서 그 과정을 비교하기 때문에 한 사람이 한 프로그래밍을 다른 사람이 점검해주는 방식과 다를 수 있겠지만, 다른 프로그래머가 다른 사람이 한 프로그램을 점검 해주어야 하기 때문에 최대한 이해하기 쉽게 프로그램을 한다는 차원에서 어느 정도는 유사한 부분이 있다고 생각합니다. 제가 그 당시에 프로그래밍을 하면서 자연스럽게 배웠던 과정은 다름아닌 함수와 프로시저의 개념이었는데, 그것은 프로그래밍을 종이와 연필로 작업을 했기에 배울 수 있었던 과정이라고 생각합니다.

보통 프로그래밍의 경우 최종적으로 프로그램이 완성되기까지 많은 부분을 고치고 수정하게 되는데 이 작업을 연필과 종이로 진행할 경우 상당한 제약조건에 직면하게 됩니다. 그 이유는 프로그램을 수정하거나 할 때 해당 부분의 영역이 모자랄 경우 코드를 적기가 매우 어려워 종이를 오려 붙이거나 지우고 수정하기를 반복하다가 종이가 찍어지는 경우가 빈번했기 때문이었습니다. 그래서, 이런 문제를 조금이라도 편하게 진행하기 위해서는 설계 단계에서부터 레고 블록을 만들 듯이 각 영역을 분리하고 그 영역을 조합해서 만드는 과정을 반복하게 되었던 것 같습니다. 다시 말해 프로그래밍을 하다가 코딩이 좀 길어진다 싶으면 자연스럽게 함수를 부르고 다른 종이에 함수에 대한 기능을 정의하게 되었고, 그러한 과정을 통해 모듈화에 대한 개념을 자연스럽게 습득하게 된 것 같습니다. 

고등학교를 졸업하고 대학에 들어온 뒤로 꽤 많은 컴퓨터 언어들을 배웠던 같습니다. Pascal, C, PC Assembler, Fortran, Windows Pascal, Windows C, Java, Visual Basic 등 당시에 유행했던 언어들을 거의 다 배웠다는 생각이 드는데, 왜 그렇게 컴퓨터 언어들을 배우는데 집착을 했는지 모르지만 그런 언어들을 배우는 것에 강한 열망을 지니고 있었던 것을 보면 그 당시 저에게 컴퓨터라는 것은 단순한 컴퓨터 이상의 것이었다는 생각도 하게 됩니다. 아마 요즘 흔히 이야기되는 Geek이나 Nerd와 같은 기질이 다분히 있었던 같은데, 그 당시에는 그런 것들을 크게 개의치 않고 살았던 것 같기도 합니다. 대부분의 개발자들 그렇듯 이런 언어들을 배우는데 있어서 학원을 다니면서 배우기보다는 책을 통해 하나씩 배웠는데, 비싼 학원비를 내는 것도 아깝웠을뿐만 아니라  제가 직접 하나씩 해보면 배워나가는 과정이 더 재미있었기 때문에 그렇게 했던 것 같습니다. 

그 당시 저에게 가장 강력한 영향력을 준 사람은 아무래도 피터 노턴(Peter Norton)인데, 그 분의 PC에 대한 해박한 지식은 저를 시스템 프로그래밍 분야에 집중하게 만들었고 상당기간 동안 어셈블러 언어를 공부하게 만든 분이기에 저에게 상당한 영향을 끼친 분이라고 말할 수 있을 것 같습니다. 지금 생각해보면 그 당시 PC 자원이 상당히 열악했기에 어쩔 수 없이 배웠던 것들이기는 하지만, 64K라는 비교적 낮은 사양에서 프로그램을 하는 것을 배웠기에 모바일 프로그램을 하는데 얻은 장점도 꽤 있다고 생각합니다.

게다가 나중에 C언어를 배울 때 왜 메모리 제어가 왜 중요한지를 이미 알고 있었기에 C언어에서의 가장 어려운 개념 중 하나인 포인터를 좀 더 쉽게 이해할 수 있던 것 같기도 합니다. 이런 과정을 통해 제가 얻을 수 있었던 하나의 시사점은 다른 학문도 마찬가지이겠으나 컴퓨터 공학이라는 학문도 초기에는 넓게 배우는 것이 중요하다는 것입니다. 무언가를 배울 때는 그 하나 하나가 도움이 안될 수도 있지만, 어느 정도 깊이를 가지게 되면 다른 것들을 배울 때 많은 도움이 된다는 것입니다. 특히 저의 경우에는 컴파일러 이론을 공부할 때 이런 느낌을 많이 받았는데, 컴파일러 분야의 많은 부분들이 대수학과 연계되는 것을 보면서 이렇게도 연관이 되는구나 하는 깨달음을 얻게 된 것 같습니다. 덕분에 무언가를 배울 때 조금은 확실하게 배워두는 것이 좋다는 생각을 가지게 되었고, 실제로 후에 IT 분야에서 컨설턴트로 일을 하게 되었을 때 프로그램 및 시스템에 대한 이해를 높이는데 많은 도움이 되었던 것 같습니다.