코더의 길

서두에 밝혀야 할 것이.. 아래의 글은 매우 주관적이기 때문에 전적으로 신봉하지도 말 것이고 자신의 생각과 다른 부분이 있을 수 있습니다.

모티브 글
http://sparcs.kaist.ac.kr/~ari/each/article.each.756.html

직업에는 두가지가 있다고 생각한다. 재미있는 직업과 재미없는 직업. 그리고 이것은 매우 지극히 주관적이다. 음악에 살고 죽는 뮤지션이라 해도 그 음악이 매일 자신을 괴롭히는 존재일 수도 자신의 생명 그이상의 것일 수도 있다. 이세상의 코더들에게 자신의 직업에 대한 생각은 두가지일 것이다. 빨리 돈벌거나 돈많은 배우자를 만나서 때려쳐야 할 대상이거나 꿈과 이상을 실현하면서도 돈까지 벌게 해 주는 것일테다.

전산학(Computer Science)의 많은 이론들은 이미 6~70년대에 전자석에 코일 감으시던 분들이 전자석 사이에 끼인 벌레를 잡는동안 8~90%가 끝났다고 할 수 있다. 지금 사용하고 있는 운영체제나 웹 브라우저, 웹 어플리케이션의 이론적인 베이스는 더이상 나올 수 있는 새로운 것이 거의 없다라 할 수 있다. C/C++이나 Java, PHP, Ruby 나 기타 정체불명의 새로운 언어들이 나오고 있지만 컴퓨팅파워-그 언어로 할 수 있는 일은 결국 Turing Machine이라는 아무 멍청한(?) 기계랑 동일하다. 갑자기 G라는 언어가 새로 나온다 해도 그 옛날 전자석에 못하던 새로운 일을 할 수 있는 것은 아니다.

많은 코딩 지망생들은 언젠가 대단한 프로그램을 만들어 내고 싶다는 꿈을 가진다. 뭐 운영체제나 게임을 만들것이라고 한다. 현재의 리눅스 커널이나 윈도우의 NT 커널이 특별한 운영체제일까? 이론적인 베이스는 역시 저 무시무시한 전기배선공(전자석에 코일감아서 진짜 회로 만들고 있었으니.. 에니악을 봐도 뭐;;)에 의해 이미 설계가 되어 있고 그것을 구현한 하나의 코드일 뿐이다. 새로 나오는 프로그램중에 대단하다고 하는 대부분의 것은 이론적인 부분을 좀더 강화하거나 다른 이론을 추가해서 구현함으로써 속도가 향상되거나 좀더 쉽게 확장성을 가지게 되거나... 아니 대부분은 그저 기존의 구현코드를 새로 정리한 것들이다. 새로운 운영체제를 만들고 싶다면 당장 전산학은 그만두고 수학부터 공부해야 할 것이며 도서관 유리창에 아무도 알 수 없는 기호들을 나열하길 권장한다.

코더는 그럼 단지 IT회사의 부속에 지나지 않는가? 이런 질문에 대해 최근 대학들이 "전산학과(Computer Science)"란 명칭 대신 "컴퓨터 공학과(Computer Engineering)"로 변경하는 추세를 들고 싶다. 코더는 Scientist가 아닌 Engineer라 할 수 있다. 공정에서 실제로 작업하는 Worker는 컴퓨터이고 컴파일러, 서버 어플리케이션, 개발툴등의 프로그램들이다. 이들을 효율적으로 돌게 하는 엔지니어인 것이다.

"화학"을 보자. 물을 전기분해하면 수소와 산소가 나온다는 것은 중학교 아니 요즘의 조기교육 추세를 보면 유치원 때 이미 알고 있을 것이다. 하지만 수소를 얻기위해 중학교 실험실에서 하는 방법을 사용하지 않는다. 이것을 다루는 부분이 "화학공학"이다. 수소를 만드는 공장을 만든다고 해 보자. 일단 중요한 것은 건설비용이다. 수소를 팔았을 때 휘발유 정도의 이익을 얻는데 원자력 발전소 건설비용이 들었다간 당장 쫓겨난다. 이제 세세히 들여다 볼까? 수소란 놈은 민감해서 산소와 데이트를 잘못 했다간 독일의 비행정처럼 멋진 불꽃놀이를 선사한다. 시간당 생산량도 중요하다. 1리터 페트병정도의 수소를 얻는데 다음세대를 기약해야 한다면 안된다. 안정성, 효율성, 경제성등을 고려하여 공장이 생성된다. 공장의 유지보수나 공정개선등 실험실에서 금속판 두개 넣고 12볼트 전압을 거는 것과는 사뭇 다른 과정이 된다. (사실 공업적 수소를 전기분해로 얻는지는 모르겠다. 다른 효율적인 방법이 있을지도.. 나야 화학공학을 전공하지는 않았으니;;;)

코더도 엔지니어다. 저 꼭대기의 PM이 모든 공정관리를 한다고 생각하지 말길 바란다. 계층적 구조에서 상부는 하부의 공정 측정데이터를 모아 전체를 관장할 뿐 실제적인 설계나 수행은 하부를 의지할 수 밖에 없다. 상위 PM은 말단 코더의 삽질을 최대한 방지하기 위한 장치를 하겠지만(물론 유능하다면 말이다.) 반대로 전체 프로젝트에 있어 말단 코더도 중요한 역할을 수행하는 엔지니어인 것이다.

이전에 코더가 창의적이어야 한다느니 용감 무쌍하게 적진 한가운데 열혈단신으로 폭탄을 던지는 람보가 되어야 한다느니 하는 말에 동의할 수 없었던 것이 이런 이유일 것이다. 프로젝트 듀가 일주일 앞으로 다가왔는데 좀더 생산성이 좋은(이라고 믿는) 언어로 변경하자고 외치다가 정말 용기를 내어버려 혼자 변경하는 행동을 하라는 것인가? 멀쩡하게 잘 돌고 있는 프로그램을 이렇게 하면 더 빨라진다면서 어셈블리 언어로 변경하거나 매우 객체지향적인 언어로 새로 바꾸는 것이 코더의 본분일까?

공정속의 노동자가 되라는 것은 아니다. 이것은 분명 직무유기다. 코더는 다시한번 말하지만 엔지니어이고 엔지니어의 가장 중요한 본분은 공정 개선이다. 개선의 기준은 항상 현재다. 현재보다 좋아질 가능성이 보인다면 항상 검토하고(과학자처럼 저지르고 보는 것이 아님에 유의!) 아니 그전에 언제나 좋게 만드는 방법을 끊임없이 찾아야 한다. 소프트웨어 공정 개선은 위의 메니저만 하는 것은 아니다. 그 사람들은 겉멋만 들어서 실제 말단의 공정개선을 가늠조차 할 수 없다. 코더들이 아무런 데이터와 의견을 주지 않으면 전체 개선도 불가능하다.


학생때의 꿈을 가지고 사회에 나와서 당장 "저 빌어먹을 PM"때문에 직업을 후회하고 있다면 우선은 코더란 직업에 대한 약간의 오해를 해결하길 바란다. 만약 자신이 공정속의 부속 같다라는 느낌이 든다면 자신을 옆에 있는 컴퓨터의 CPU나 멀리 떨어져 있는 프린터 내지 팩스로 한정하고 있는 것과 동일하다. 자신이 gcc 보다 못하다고 생각하는가?
소프트웨어 공장에서 모든 엔지니어는 공정을 개선해야 할 의무가 있고 그것으로 밥벌어 먹고 사는 것이고 덤으로 개선된 공정에 뿌듯해 할 수 있는 특권이 있고 생각한다. 물론 이런 것이 맘에 들지 않는다면 적성이 맞지 않는다고 할 수 있겠지만 적어도 자신을 프린터와 동급으로 놓고 신세 한탄하는 것은 일단 이르다고 말하고 싶다.

적어도 현재 난 PHP 인터프리터나 아파치 웹서버보단 더 많은 일을 하고 있다. 그것들은 나처럼 N사 포털에서 재미있는 글을 발견해서는 사람들에게 메신저와 게시판, 블로그로 퍼다 나르는 짓을 못하니.