글이 쓰여진 것이 2007년인지는 확인을 못한 상태에서 현실과 너무 동떨어지는 개발자에 대한 현실에 비판을 안 할 수 가 없었던 입장 이었습니다.
그럼에 5throck 님께서 먼저 반론의 글을 쓰고 알려 줄 수 있지 않았느냐 - 라는 댓글에 심히 부끄러움을 느끼게 되었네요.
그리고 트랙백으로 걸린 글을 읽어 보았습니다.
일단 이 글로 5throck 님에게 어떠한 동의도 없이 반론의 글을 쓰게 된 것 을 이 자릴 빌어 죄송함을 표하고 싶습니다.
5throck 님의 글을 보면, 당연히 저보다는 연세가 있으시고, 제가 밟았던 언어와 비슷한 배경을 가지고 계시더군요.
이전에도 제 블로그에 간혹 과거에 대한 단상을 쓴 적이 있습니다만, 이번에도 다시 과거를 돌이켜 볼 필요가 있어 보이는 군요.
5throck 님이 COBOL 로 시작한 언어에 저는 Apple IIe 에서 BASIC 으로 시작 하였습니다.
그당시 MSX 는 Color CRT 모니터에 16색이라는 놀라운 표현력은 물론, 내장 동시 4ch 이라는 소리를 낼 수 있는 기능 덕에 최고의 게임 머신으로 까지 등극해 있었습니다.
그당시 저는 지금의 초등학생, 그당시엔 국민학생 이었죠.
그 당시 기업에서 COBOL 을 배우셨다는 5throck 님과는 상이한 입장 이었습니다.
그러다가 compile 이라는 개념을 알게 되었습니다.
인터프리터어 인 BASIC 이 가지는 구조와는 다른 기계어로의 변환이 일어 나는 compile 과 link 의 개념은 어린나이에 깨닫게 된 이유가 바로 Quick BASIC 에 이은 Borland 사의 Turbo Pascal 이었습니다.
아마 5throck 님이 만져 보셨다는 PL-1 의 후속이 바로 Pascal 이겠죠.
아마 저와는 접근의 방법이 이전부터 다르셨던 점이 보입니다.
저는 은행권에서 일한 것이 아닌, 직접 기계어로의 접근을 위한 도구로 Pascal 을 배우고, C 언어를 접근하게 되었습니다.
그당시 인터넷이란건 있지도 않았을 뿐더러, MODEM 을 통한 통신으로 엄청난 전화비를 지불 해야 하는 고통이 따르는 수단 외엔 서점에 파는 책가지가 제가 얻을 수 있는 지식의 전부 였습니다.
5throck 님이 pascal 의 function 과 procedure 를 알아 가실때, 저는 inline assembler 를 알아 가던 때 같습니다.
아마 이런 점이 겉으로는 개발이라는 공통된 특징을 가지지만 내부로서는 서로 다른 지표를 가진 서로 다른 개발 방향을 가지고 있었다는 차이가 되겠습니다.
프로그래밍에 완전 빠졌을 때에 저 역시 언제나 키보드를 손에 잡을 수 는 없었습니다. 컴퓨터 성능은 우수하지 못하였고, 제가 가진 PC 의 저장장치 성능 또한 우수하지 못하였을 때 이기 때문이죠 (대학 전 까지 제 PC 는 아버지가 몫돈 들여 사 주셨던 삼성 SPC-2500C 라는 i80286 12MHz 에 메모리 640KB , 플로피 디스크 2개 달린 컴퓨터 였습니다)
물론 그런 이유로 제 코딩은 공책에 쓰이는 손으로 만드는 코드 였습니다.
그때 배운게 순서도 입니다.
하지만 그 순서도는 그저 전체적인 흐름만을 만들 수 있었을 뿐, 세부 코딩은 역시 손으로든 키보드로든 직접 만드는 방법 외엔 없었죠. 비슷해 보이는 부분도 없지 않아 있을 것 으로 보입니다.
포인터는 pascal 에서 부터 이해 하고 있었던 지라, C 언어와 C++ 의 포인터는 좀 더 유연하고 쓰기 더 편한 좀 더 편한 언어 정도 였습니다. 물론 compile 에 이은 link 가 가지는 놀라운 느린 속도는 저에게 C/C++ 보다는 pascal 을 지금까지 쓰게 만든 원동력이 되었습니다만 ...
그당시 DOS에는 Install shield 같은 패키징 솔루션이 업었습니다.
사실 제가 패키징이란 걸 처음 사용한것은 Windows 3.1 이전에 DOS 에서 였겠네요.
그당시 게임들은 모두 Text 모드에 ASCII 문자들로 표시되는 progress bar 와 글자들이 전부 였을 겁니다.
그걸 저는 음악+MCGA mode 라 불리던 13h 레지스터를 이용한 그래픽, LZH 압축 알고리즘을 이용한 설치 패키지 프로그램을 만들었었습니다.
분리된 여러 LZH 압축 파일들을 설치되는 위치(보통 하드디스크)에 풀어 주고, 이 과정을 간단한 그래픽과 지루하지 않은 음악으로 표현 했었고, 당시 컴퓨터 잡지에도 실려 소개 되기도 했었습니다.
이렇게 시작된 프로그래밍에 관련된 제 생활은 지금까지 이어지고 있습니다.
단지 달라진 것은 그당시에 사용되는 컴파일러는 지금에 쓰이지 않고 있지만 여전히 GCC/MinGW 를 쓰고 있고, Object-pascal 로 이어진 Delphi 는 Free Pascal Compiler 를 통해 ARM base WindowsCE 이나 Android 등의 타 플랫폼으로 까지 사용이 가능한 상태 입니다.
그럼에도 저는 아직 5throck 님의 입장에 반대적인 점은 변함이 없다는 점.
이유는 많습니다만, 제가 격었던 System Engineer 는 금융권이 아닌 일본 대기업의 VLSI 에 들어가는 드라이버 및 시스템 프로그래밍 관련 분야 였고, 이는 서로 다른 성향의 SE 였는데다, 그 이후 지금까지 그 경험은 아깝지 않은 저의 재산이라는 점 입니다.
게다가 제가 지금은 하지 않게 된 IT 를 그만두게 된 이유가 이런 일로 인한 어려움이 아니라, 바로 몇년간 지속되는 야근과 시간에 쫒기는 개발일정, 그리고 낮은 연봉, 잦은 주말 출근, 보상받지 못하는 노동 이었기 때문 입니다.
5throck 님은 제가 격은 SE 와는 전혀 다른 SE, (제가 알기론 SI 에 속하는 듯 합니다만) 를 격고 나서 택하신 일이 컨설팅이라 하셨죠. 만약 개발자로서 저와 같은 어려움을 격고, 그 어려움을 이해 했었다면 이전의 그 글 처럼 개발자 부족에 대한 이해가 그러하진 않았을 것이라 믿어 의심치 않습니다.
1년중 집에 일찍 가는날이면, 마치 죄책감을 가져야 하고, 다음날이면 왜 이리 일찍 가느냐? 일이 없느냐? 라는 이야길 들어가면서 일을 해 보셨다면 과연 그런 글을 쓰실 수 있었을까? 하는 생각을 해 봅니다.
정말 어렵게 IT 개발자로서의 일을 해 보셨다면, 지금 하시는 컨설팅에서 과연 어떤 의미에서의 "프로페셔널리즘" 인지 모르는, 그 이유로 개발자가 야근과 주말 출근에 까칠한 반응을 보이는지 이해 못하지 않았을 것 이란 점 입니다.
5throck 님께선 지금도 컨설팅을 하고 계신지 모르겠습니다만, 컨설팅이 주업 이시라면 그 달라진 차이를 먼저 이해 해 주셨으면 하는 바램 입니다.
전 여전히 키보드로 프로그래밍을 하는 일을 지금도 하고 있습니다.
하지만 대한민국에서 IT 라 불리는 그런 을,병,정에 이어지는 재봉틀 대신의 키보드를 쥐는 막노동성 일을 전혀 하고 있지 않기에 과감히 IT 라 하지 않습니다. (회사는 의료기를 생산 합니다)
그러기에 IT 에서 격어던 온갖 서러운 일과, 지금도 그곳에서 내 생활을 회사에 반납해 가며 제대로 된 대우를 받지 못하는 여러 동료와 후배들을 알고 있습니다.
그들을 생각하면 5throck 님의 몇년전 이야기는 그당시나 지금이나 모두 형용될 수 없는 글이란 것을 다시금 알아 주셨으면 하는 바램입니다. 몇년이 지났지만 IT 에서 달라지는 것은 전혀 없었습니다.
만약 지금도 그 "프로페셔널리즘" 이 그때와 다르지 않은 이해로 5throck 님에게 사용되고 있다면 ...
다시금 그 "프로페셔널리즘" 이 어떤 것인지 재정의 해 보심은 어떨지 권유해 보고 싶습니다.
개발자 들이 공감하지 못하는 그 "프로페셔널리즘"은 과연 어떤 것인지 말이죠.
물론 3년전의 이야기를 제가 들고 일어 선 것이니 지금의 5throck 님의 생각과는 분명 다를 것이라 생각 됩니다.
또한 제가 이렇게 글을 쓰는 것 역시, 세대의 차이는 있었겠지만 - 저 역시 오랜 기간 개발이란 것을 통해 생업을 하고 있고 지금 역시 그 개발이란 것에 제 인생을 걸고 있기 때문에 쓰는 것임을 넓은 아량으로 이해 해 주셨으면 좋겠습니다.
컨설팅이란 분야가, 실제 개발자들을 포용적으로 이해 하고 하실 수 있다면 정말 최고의 컨설터가 될수 있지 않을까 하는 생각도 해 봅니다.
감사합니다.
