태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.



프로그래머들은 특별한 사람이라고 평가되는 것을 좋아한다. 사실은 어떤 모범적인 프로그래머들은 다른 프로그래머들의 이상한 점을 개발자들의 커뮤니티 내에서도 발견한다. 아래에 10가지 타입의 프로그래머를 소개한다. 여러분은 이 중에 어떤 타입인가?

#1: 간달프(Gandalf)

이 프로그래머 타입은 ‘반지의 제왕’에 나오는 마법사 간달프와 닮았다. 이 타입의 외관은 턱수염을 기르고, 이상한 모자를 쓰고, 겨울에 망토 같은 외투를 입을지도 모르며, 좋게 보면 간달프와 같은 마법으로 팀을 위하고, 안 좋은 면은 팀원들이 간달프가 눈길을 걸어올라 오는 시간을 기다리듯이 그가 전산실에 오는 시간을 오랫동안 기다려야 한다는 것이다.

이런 타입은 실력이 아주 뛰어난 중요한 인물이지만 보통은 같이 일하기를 꺼려한다. 하지만 문제가 해결이 안 될 때는 간달프의 마법이 필요하듯 이런 타입의 도움도 필요한 법이다.

#2: 순교자

다른 업종에서는 순교자(The Martyr)는 워커홀릭이다. 하지만 개발 분야에서 순교자는 그 차원을 넘어 선다. 워커홀릭은 최소한 집에 가서 샤워하고 잠은 자기 때문이다. 순교자 타입은 다 먹은 피자 박스에 둘러싸인 책상에 엎드려 자는 것을 자랑스럽게 생각한다.

문제는 아무도 이렇게 일하는 것을 원하지 않았다는 것이다. 순교자 타입은 다른 팀원에게 부담스러운 말을 한다. “먼저들 들어가. 저녁 맛있게 먹고…. 나는 오늘밤에 3주 동안 해야 할 코딩을 모두 하고 들어갈래.”라는 식으로 말이다.

#3: 팬보이

팬보이(Fanboy)는 조심해야 한다. 이런 사람이 여러분 주의에 있다면, 그는 드래곤볼 Z와 건담 윙 중 어느 것이 재미있는지 또는 플레이스테이션3와 X박스 360중 어느 것이 더 좋은지에 관해 과장 좀 해서 3시간 동안은 이야기를 들어야 할 것이다.

팬보이의 책상 주변에는 일본에서 수입한 액션 피규어, 포스터 또는 장식품 등을 진열해 놓았을 것이다. 이들은 자신들이 가지고 있는 장식품을 가지고 생각하는 것을 좋아해서, 그 생각에 시간을 많이 허비한다. 이런 타입은 가끔 무엇 때문에 채용을 했는지 모를 때가 가끔 있다.

#4: 빈스 닐(Vince Neil): 미국 밴드 머틀리 크루의 리드싱어

마치 1984년으로 돌아간 것 같은 타입이다. 긴 머리카락, 찢어진 청바지에 큰 스카프를 목에 두르고 업무 시간 동안 본 조비, 데프 레퍼드(Def Leppard)와 같은 음악을 따라 흥얼거리며 일한다. 빈스 타입은 일반적으로 재미있고 경험도 많지만 발전이 없다. 게다가 힙합 스타일과 아웅다웅할지도 모른다. 이런 타입과 매일 일하는 것은 꽤 힘들 것이다.

#5: 닌자

닌자 타입은 여러분 팀의 MVP이지만, 아무도 누구인지 모른다는 것이다. 전설적인 자객처럼, 닌자 타입은 일을 하는 건지 안 하는 건지 모르지만 아침이 되면 결과물이 나와 있는 것을 발견할 수 있다.

여러분이 소스 제어 시스템을 가동하고, 새벽 4시에 한번 확인 해보라. 여러분은 닌자가 그 프로젝트를 알고 있을 것이라고 생각하지도 않았지만, 여러분이 일주일 동안 작업한 계획의 문제를 코드 레벨에서 확인하고 알려 두었을 것이다. 여러분이 다른 회의에 참석해 있을 때, 닌자 타입은 일을 하고 있을 테니 확인해 보라.

닌자 타입은 아주 비밀스럽게 일을 한다. 여러분은 그 사람의 이름조차 모르지만 모든 프로젝트마다 아주 깔끔하게 정리되어 있는 것을 볼 수 있다. 이런 타입은 신중하게 다가가야 한다. 이런 사람을 조직 내에서 순위를 매기거나 파일로 업무를 관리하려고 하지 마라. 닌자 타입은 혼자 일하는 전사이며, 관리 당하는 것을 싫어한다.

#6: 이론가(The Theoretician)

이 타입은 프로그래밍에 관해 알아야 하는 모든 것을 알고 있다. 이 타입은 애매한 프로그램 언어의 역사에 관해 4시간 정도 떠드는데 시간을 소비하거나 어떻게 프로그래밍 하면 런타임을 줄이고, 최적화 프로그래밍을 할 수 있는지에 대해 시간을 허비할 수 있다.

문제는 이런 타입은 소프트웨어 개발에 관한 것을 알지 못하고 있다는 것이다. 이론가 타입이 코딩을 하면 정말 말도 안 되게 ‘엘레강스’하다. 또 좋아하는 기술은 ‘반복’이며, 모든 코드는 최대한 꼬여 있어 읽는 데 시간이 많이 걸린다.

이런 타입은 주의가 산만해 쉽게 다른 일에 관심을 돌린다. 몇 시간이면 개발할 수 있는 일을 이런 타입은 석 달은 족히 걸린다. 왜냐하면 기존의 툴은 충분하지 않다며 새로운 라이브러리를 만들어 새로운 툴을 만들어 사용하려고 하기 때문이다.

이런 타입은 잘만 컨트롤 하면 아주 잘 활용할 수 있다. 프로젝트에서 정확히 할 일에 대한 범위를 정해 주고 다른 일에 시간을 허비하지 못하게 한다면 말이다.

#7: 코드 카우보이(The Code Cowboy)

이 타입은 절대 스스로 멈추는 법이 없다. 이런 타입은 거의 항상 최고의 프로그래머이며, 다른 사람보다 두세배는 빠르게 일을 할 수 있다. 하지만 문제는 그렇게 빠르게 하는 일의 반을 대충 한다는 것이다. 소스 컨트롤 하는 코드 확인에 시간이 걸리고, 외부 컨피규레이션 데이터 저장에 시간이 걸리고, 다른 사람과 대화중에 생각을 이해하는 데도 시간이 걸린다.

이 타입의 코드는 스파게티처럼 혼란스럽다. 이유는 프로그래밍 하면서 리팩토링 하는 것이 절대 일어나지 않게 빨리 하기 때문이다. 프로그래밍 책에 예제로 되어 있는 “이렇게 하지 마세요”라고 7페이지에 걸쳐 중요하게 설명되어 있는 것과 비슷하게 프로그래밍을 했지만 신기하게도 프로그램은 돌아간다.

코드 카우보이 타입은 다른 사람과 함께 일을 잘 하지는 못한다. 그리고 여러분이 이런 타입 두 명을 같은 프로젝트에 투입시키면, 서로의 변화에 대해 인정을 하지 않고 싸우기 때문에 확실히 실패 한다.

이 타입은 정확하게 해야 하는 프로젝트보다 납기 일정이 더욱 중요한 프로젝트에 투입하는 것이 좋고, 코드는 항상 일정 전에 완성되어 있을 것이다. 코드 카우보이는 ‘시끄러운 닌자 버전’이라고 보면 된다. 닌자가 정교한 외래 수술을 하는 것에 비유한다면, 코드 카우보이는 성난 소처럼 저돌적으로 자신의 길을 달려가는 것에 비유할 수 있다.

#8: 공수부대요원(The Paratrooper)

여러분은 영화에서 적지 깊숙이 침투하여 비밀스럽게 업무를 수행하는 특공대 요원을 본적이 있을 것이다. 이 타입은 소프트웨어 개발 세계에서 ‘공수부대 요원’이라고 한다. 이 요원은 다 죽어 가는 프로젝트를 살리기 위해 마지막으로 보내는 프로그래머이다.

이 요원은 장기 프로젝트에 대해서는 부족하지만, 그들의 최대 자산은 친숙하지 않는 코드를 배워서 작업을 하는 불가사의한 능력이다. 다른 프로그래머들은 이러한 것을 충분히 배워서 프로젝트를 실행하는 데 몇 주 내지 몇 달이 걸릴지도 모르지만, 공수 부대 요원들은 몇 시간 또는 하루 정도면 충분하다.

이 요원들은 그 코드의 핵심을 알 정도로 배우지는 못하지만, 전체의 팀이 실패할지도 모르는 곳에서 성공할 수 있는 것을 의미한다.

#9: 보통사람(Mediocre Man)

“충분히 좋다”라고 듣는 것이 이 ‘보통사람’ 타입에게서 들을 수 있는 최고의 찬사이다. 이 이름에 속지 말아라. ‘보통사람’이라는 타입에는 엄청난 다양함이 있다. 그리고 이들은 다른 팀원들보다 더 나쁜 코드를 만드는 데 시간이 더 걸린다.

이 타입들의 특징은 느리고 침착하게 하지만 프로젝트가 언제 끝날지 모르며, 회사에 오랫동안 일을 하기 위해 항상 “충분히 좋다”라는 슬로건을 외친다.

이런 타입을 인터뷰 할 때 그들은 많은 프로젝트에 관여한 사실을 여러분에게 이야기 하겠지만 실제로 관여한 프로젝트는 많지 않다. 이러한 타입을 알아내는 것은 쉬운데 그들이 한 일에 대한 자세한 질문을 하면 아마 갑자기 건망증 증세를 보일 것이다. 이런 타입을 채용한다면 퇴사시키는 데 몇 년은 걸릴 것이다.

#10: 이반젤리스트(The Evangelist)

여러분이 어떤 환경에 처해 있더라도, 이반젤리스트는 지금 사용하고 있는 툴, 프로세스를 버리고 다른 것들로 대체해 업무 향상을 할 수 있다고 주장한다. 이반젤리스트는 실제로 이론가(The Theoretician)와 정반대이다. 이들은 솔직하고, 소프트웨어 개발에 관하여 많이 알지만 실질적으로 프로그래밍 작업은 거의 하지 않는다.

이들은 자신이 프로젝트 매니저나 부서장이라고 마음속으로 생각하고 있으나 지식이나 프로젝트 경험은 부족하다. 따라서 이들은 순수하게 경영자 역할을 할 수 있으므로 다른 사람들은 이들이 변혁을 시도하는 것을 참을 필요가 있다.



가끔 안철수연구소에서 메일이 오는데 좋은 글이 있어서 담아옵니다^^
출처는 : 안철수연구소 메일
원문은 : http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39164694,00.htm
            Justin James ( TechRepublic )
이올린에 북마크하기(0) 이올린에 추천하기(0)


Trackback URL : http://prolee2001.tistory.com/trackback/62

Leave a comment




예전부터 관심을 가지고 있었던 Ruby에 대한 설치 및 설정법을 이글루스 밸리에서 발견하여 담아옵니다.
출처 - http://bumjin.egloos.com/3501429


1. 설치
http://www.rubyonrails.com/down
Ruby => Windows Installer 를 선택하면 http://rubyforge.org/frs/?group_id=167 에서
최신버전의 One-Click Ruby Installer 설치파일인 http://rubyforge.org/frs/download.php/27227/ruby186-26_rc2.exe를 다운받을 수 있다.

F:\ruby 에 설치를 하고, 내컴퓨터 -> 고급 -> 환경변수에 RUBY_HOME=F:\ruby 를 설정

2. 개발툴/플러그인 설정
Intellij Idea
(www.intellij.net/eap) 에서 최신버전의 idea 를 다운받고

http://plugins.intellij.net/plugin/?id=1293에서 최신버전의 Ruby 플러그인(http://plugins.intellij.net/plugin/?action=download&id=4759)  을 다운받아서 idea 의 플러그인 디렉토리(F:\java\idea\plugins)에 푼다.
F:\java\idea\plugins\ruby형태로 풀렸을것이다.

3. idea를 실행하고, New Project  (Create from scratch) 로 Ruby Module를 선택한다.
 JRuby on rails 같은 프로젝트를 구성한다.

4. 프로젝트 뷰에서 루비파일을 선택하고 마우스 오른쪽 버튼 으로 run 을 통해 실행해볼 수 있다.

eclisep로 Ruby 환경 꾸미기
http://www.ibm.com/developerworks/kr/library/os-ecl-radrails/



20분 강좌 : http://www.ruby-lang.org/ko/documentation/quickstart/

동영상강좌 :

[동영상 강좌] 루비의 기본적인 문법

[동영상 강좌] Ruby 프로그래밍 연습 1-5

[동영상] Ruby 프로그래밍 연습 6-8


 http://ias.springbook.playmaru.net/pages/336101     JRuby on Rails 시작

이올린에 북마크하기(0) 이올린에 추천하기(0)


Trackback URL : http://prolee2001.tistory.com/trackback/44

  1. # BlogIcon BlueFrontier 2008/03/02 04:08 Delete Reply

    저도 한때 RoR 너무 좋아했었는데요.
    요녀석으로 프로그래밍 세계가 천하 통일 되었으면 합니다. ㅋㅋㅋ

    1. Re: # BlogIcon 프로리 2008/03/03 09:22 Delete

      ㅋㅋ
      저도 많이 조아라한답니다..ㅋㅋ
      천하통일이 되는 그날을 위하여~ㅋㅋ

Leave a comment



이글루스 밸리를 돌아다니다, 갑자기 슬퍼지는 글을 보게 되어 가져옵니다.

앞으로 LAMP를 시작으로, 흔히 말하는 IT계열을 준비하려는 나에게,
상당히 슬픈 현실로 다가옵니다. 그래도, 아직 젊으니까.. ^^


원본출처 : http://blog.naver.com/cyberlifes?Redirect=Log&logNo=40041597394



-------------------------------------------------------------------------------------

# 내가 it를 그만둔 이유...


참 오랜 동안 프로그래머라는 직종에 있었던 것 같다. 2000년 큰 꿈을 안고 신입 프로그래머로 첫 직장에 취직을 했다. 그때가 20대 초반의 7월. 그땐 직장에서 날밤 새면서 프로그램 짜는 사람들이 이상해 보이지 않았다. 아니 오히려 멋져 보였다. 어디서부터 만들어진 선입관인지 모르지만 그게 진정한 프로그래머의 모습이라고 생각했다.


한달 풀출근하고 추석도 출근하래서 안나갔더니 원청 대기업의 수석이 우리 회사 사장한데 업무 비협조라고 시말서 쓰라고 한다.


어려서부터 뭘 만들길 좋아해서인지 내손으로 만든 프로그램을 납품한다는 생각에 2~3달 동안 매일 2~3시간씩만 자면서 개발을 했다. 그러면서 스스로 자랑스러워했고. 난 이런 거 개발한다고 좋아했다.

그 회사엔 기숙사가 있었는데, 출퇴근하는 나에게 왜 기숙사에 안들어오냐고 했다. 그땐 그냥 별 감흥이 없었다.


그렇게 3년을 지내고, 이번엔 서버 쪽 개발이었다. 메신저 서버 개발이었는데, 첨 들어가자마자 2달 만에 완성하란다. 개발자는 단 두 명. 그때 난 개발이 다 그렇지 했다.


이번에 모바일 회사에 들어갔다. 입사 첫날 밤 11시 퇴근을 했다. 1년 동안 일요일 쉰 게 손가락에 꼽는다. 어쩌다 사무실 공사로 6시 퇴근을 하니 적응이 안 되었다. 뭘 해야 할지도 몰랐다. 퇴근은 매일 밤 10시가 넘었다.


20대 중반을 넘긴 나이에, 국내 최고의 대기업 외주 업체로 폰을 만들러 미국 출장을 갔다. 아침 9시 출근 밤 12시 퇴근이 정해졌다. 일주일에 하루는 완전 날밤 샜는데, 그런 날은 아침 7시 퇴근해서 오후 3시 출근했다. 휴일은 한달에 하루. 빨래할 시간도 안준다.


그런데 바뀐 갑의 담당자 왈 "디자인 다시 하고 서비스기획 다시 하죠" 자기들이 컨펌한걸 다시 하란다. 그리고 그 지옥같은 일정이 다시 한달 반복되었다.


재작년 이 회사 폰파트에 입사한 선배에게 전화 해보니 전화 할 때마다 회사 침실이다. 중국 출장 갔다고 해서 연락해보니, 중국에서도 그런 식으로 일하고 있다.


한달 풀출근하고 추석도 출근하래서 안나갔더니 원청 대기업의 수석이 우리 회사 사장한데 업무 비협조라고 시말서 쓰라고 한다.


그리고 지난 3년간, 이동통신회사 블로그 서비스를 싹 다 모바일로 바꾸는 작업을 했다. 처음 프로그램을 만들 땐 2주 동안 집에 3일만 갔다. 그것도 옷 갈아입으러. 그리고 사무실에서 날밤의 연속. 그렇게 1차, 2차, 또 다른 프로그램. 사무실 인근에 여관방을 잡아놓고 새벽 4시 퇴근 9시 출근했다. 당연히 주말은 없다. 3달짜리 프로젝트를 하루도 안 쉬고 4시간 자며 했더니 겨우 테스트 일정에 맞춰 개발했다.


그런데 바뀐 갑의 담당자 왈 "디자인 다시 하고 서비스기획 다시 하죠" 자기들이 컨펌한걸 다시 하란다. 그리고 그 지옥같은 일정이 다시 한달 반복되었다.


이젠 지겹다. 그래서 사표 던졌다.


도데체가 왜 프로젝트는 항상 급한 건지. 왜 항상 일정은 왜 반도 안 주는 건지. 왜 10명이 개발할 거를 세 명이 개발하는 건지. 왜 당연히 야근을 해야 한다고 생각하는 건지 일정에 왜 당연히 야근이 들어가는 건지. 왜 주말, 국경일이 존재 하지 않는 건지. 회사 사규에 "회사가 주말출근과 야근을 요구할시 직원은 흔쾌히 동의한다."라는 게 왜 있는 건지.


내가 PL로 일하면서 프로젝트를 겨우 겨우 잘 맞춰서 6시 칼퇴근을 몇 번 했는데 그 다음 연봉협상 할 때 "그때 별로 힘들게 일안했자나?" 라고 한다. 야근을 하지 않으면 열심히 일하지 않는 직원이란 건가. 일을 어떻게 하든 야근하는 직원은 연봉이 오르고 시간 내에 마치고 일찍 가면 인정 받지 못한다. 야근 수당이나 주말 출근 수당은 회사 사정상 줄 수 없다 하고 추가로 근무한 시간을 평일대체가 된다거나 하는 것도 없다. 결국 개발자에게 돌아오는 것은 아무것도 없다.


미래를 바라보고 주식시장 상장을 바라보고 일하라고 하는데 이런 상황에서 상장했다고 해서 과연 날밤 샌 직원들에겐 뭐가 돌아오겠나. 장담 할 수 없다.


요즘 개발자가 금값이라 개발자 구하기 힘들다. 6 명이 할 프로젝트를 2명이 하게 되었다. 사람을 뽑아 달라고 하니, 면접보곤 쓸만한 개발자에게 터무니없는 연봉을 제시한다. 결국 개발자 구하는 데만 두 달이 넘게 걸렸다. 그러고선 개발 일정 못 맞춘다고 닥달한다. 개발자 몸값이 올라갔으면 그만큼 올려서 구해야 하는데 이놈의 연봉 수준은 몇 년전 수준 그대로다. 연봉 몇 백 더 주고 몇 억짜리 프로젝트일정을 맞추는 게 중요한 건지 몇 백을 아끼는 게 중요한 건지, 간부들이 똥인지 된장인지 구분도 못하고 있다.


개발자들이 매일 밤 12시까지 일하는 거 보고 프랑스 사람이 노동부에 신고를 해서 프랑스 노동부가 영업정지를 내려, 아예 법인을 해체하고 다른 나라로 옮겼다고 한다.


이제 서른을 넘긴 나이 c/C++ 8년차가 되었다. 내 위에 중년을 바라보는 개발자들이 있다. 그들은 여전히 새벽 퇴근과 날밤새기 주말 출근을 당연히 받아 들이며 살고 있다. 내가 보기엔 그들은 이제 야근을 즐기고 있는 거 같다. 그냥 그런 문화에 젖어서 오히려 야근에 불만을 가지는 사람들을 ‘부적응자라’고 판단하기도 한다.


난 TV나 신문에서 한국의 남편들이 세계에서 가장 가사 노동 참여 시간이 적다는 뉴스를 볼 때마다 막 화가 난다. 독일 9시전 출근 3시 퇴근이다. 미국 9시 출근 5시 퇴근이다. 호주 4시반이면 짐 싼다. 캐나다 영국 별반 틀리지 않다. 내가 아는 개발자들 대부분은 한달에 야근 안하고 퇴근 하는 날이 손꼽는다. 이 상황에서 어떻게 자기 개발을 하고, 가사노동에 참여한단 말인가? 홍길동의 분신술을 익혀야 하나?


모바일 프로그래머 마지막 연봉은 4천만원 가까이 되었다. 퇴사하기 얼마 전엔 모 회사로부터 4,500만원의 연봉을 제시 받았다. 제법 큰 회사였고 안정된 회사였다. 하지만 가지 않았다. 직원 한 명이 퇴사해서 새로 사람을 구하는 거였는데, 바로 그 퇴사한 직원과 업무를 같이 할 기회가 있어 회사사정을 잘 알았기 때문이었다. 그 회사에서 9시 출근해서 밤 12시 퇴근했다고 한다. 한달에 이틀 쉬었는데, 그 휴일마저도 건너뛰기 일쑤였다고 한다. 크리스마스와 기타 국경일 모두 다 출근했고, 설날도 하루만 쉬었다고 한다.


4,500 만원? 5,000, 6,000을 줘도 안 간다.


시간만 축나는 게 아니라. 건강과 젊음까지 갉아 먹는다. 그렇게 일하다 난 매달 약을 먹어야 하는 알러지성 폐질환까지 얻었고 내 뒤에서 쟤는 왜 저렇게 빌빌대고 혼자 일찍 퇴근 하냐는 임원들의 수근거림을 다른 사람을 통해서 듣기도 했다. 결국 그런 노동환경에서 나 말고도 건강에 피해를 입는 사람들이 계속 나타나는데도 다른 건강한 사람들도 있지 않냐며 모른척 한다. 공기 청정기 하나 놔주지 않는다. 이게 한국의 it 회사다.


비전이 보이지 않는다. 내가 꿈꾸는 6시 퇴근, 주 3일 영어학원, 아내와 아들과 저녁식사, 주말에 운동, 가족과 나들이. 한국에서 it 개발자로 있는 한 그건 꿈이다. 꿈.


8 년만에 휴식으로 아침에 약수터 도서관 책보기, 저녁엔 농구, 가족과 식사 아들과 놀아주기 같은 해보고 싶었던 것들을 하고 있다. 당연히 회사 다니면서도 할 수 있는 일인데, 난 이게 너무나 감사하다.


몇 년전 프랑스의 한국대기업 현지 법인이 사라졌다고 한다. 개발자들이 매일 밤 12시까지 일하는 거 보고 프랑스 사람이 노동부에 신고를 해서 프랑스 노동부가 영업정지를 내려, 아예 법인을 해체하고 다른 나라로 옮겼다고 한다.


미국출장 시 갑자기 출근하지 않고 호텔에서도 사라진 개발자가 메신저로 로그인을 사직서를 제출한 일도 있다. 어느 여 개발자는 1년 여의 하드코어한 노동에 못견뎌 호텔화장실에서 벽에 X를 칠하고 미쳐버렸다는 얘기도 돌았다.


2004 년 미국 텍사스로 폰개발 출장 시 인근 대만 폰 제조사들도 있어서 대만 개발자들을 근처에서 볼 수 있었다. 우리는 9시 출근 밤 12시 퇴근하는데, 그들은 5시 퇴근해서 근처에서 농구를 하고 있다.


예전 미국 출장 때 미국 회사의 개발자들이 5시 퇴근 하면서, 저녁 먹으러 가는 우리 볼 때의 눈빛, 다 퇴근해 텅 빈 건물에서 매일 새벽 1시까지 일하다 퇴근 하는 우릴 바라보는 그 백인 할아버지 경비원의 눈빛, 잊을 수가 없다.


현지의 한국인 미국 영주권자 시민권자들은 5시 퇴근하는데, 한국에서 출장 온 우린 왜 매일 새벽 퇴근인지. 금요일 오후 3시만 되면 파티 복장과 반바지에 런닝화 신고 나타나는 사람들보며 우린 왜 저렇게 될 수 없을까 생각했다. 내 미래, 5년이 지나고, 8년, 10년이 지나도 달라지지 않을 것 같다. 그렇게 할 수 없다면 이 나라와 이 업계를 떠나서라도 찾아 가겠다.


it 개발자. 그만둔다.




# it맨과의 인터뷰




언제쯤 직장을 관두셨는습니까? 부인께서 걱정을 하시지 않으셨습니까?


올해 5월 중순에 그만두었습니다. 아내는 결혼 후 가장 잘한 일이라고 좋아했습니다. 아내도 힘들어 짜증 부리는 절 받아주기 지쳤고, 프로젝트만 하면 밤샘하고, 몇 일에 한번 들어 오는 것에 지쳤더군요. 이 기회에 건강을 되찾으라고도 합니다.


두 달 걸리는 프로젝트를 3주만에 만들어 달라고 하는 경우도 있습니다. 결국 이런 경우엔 개발 자체가 불가능하기 때문에 실제 프로그램 외에 그 담당자 인사고과용으로 demo만 돌릴 다른 프로그램도 같이 개발하기도 하죠.


일을 그만두시고 애기와 보내는 시간이 많아졌을텐데, 어떻습니까. 애기가 달라진 점은?


15개월 된 아들이 있는데, 그동안 몇 번 황당한 경험 했습니다. 7~8개월 쯤인가 일주일만에 집에 들어갔더니 아들이 낯을 가립니다. 돌이 지났을 때도 몇 일만에 집에 가고, 퇴근 시간이 매번 12시를 넘기다시피 하니 아들이 아빠를 어색해 하더군요.


그만두고 난 후 요즘은 항상 안고 밥 먹고 샤워도 같이 하며 놀아주니까 너무 좋아합니다. 몇 주간 그렇게 하니까 이젠 밥먹을 때는 저한테 와서 먼저 안기기도 합니다. 아내는 집안일도 도와주고 주일에 한번은 혼자 외출도 하고 하니 좋아하고요.


앞으로 어떤 일을 구상하고 계십니까.


여러가지 많았는데 3가지로 줄였습니다. 첫번째, it를 계속 한다면 무조건 이민을 갈겁니다. 두 번째, 그전부터 관심 있던 자산관리, 금융쪽으로 공부를 해서 전직을 할 생각도 있습니다. 세 번째, 맘 맞는 회사동료들과 창업도 얘기하고 있습니다. 한 두 달 쉬면서 충분히 알아보고 결정을 하려고 합니다.


동료 중에 비슷한 이유로 직장을 관두신 분들이 많습니까? 관두신 분들은 대개 어떤 식으로 자리를 잡으십니까?


비슷한이유로 그만두는 분들이 늘고 있습니다. 빵집을 차리거나 장사를 하죠. 예전 대학동창도 비슷한 이유로 그만두고 옷장사를 하고 있는데, 일요일도 없이 힘들긴 하지만 밤을 새서 하더라도 자기 수입이니까 할맛 난다고 하네요. 음식점 쇼핑몰로 전업한 사람들도 그렇게 얘길합니다. 하지만 배운 게 도둑질이라고 다시 돌아오는 사람들도 적지 않습니다. it만 하던 사람들은 이 것외엔 다른 건 전혀 생각을 못하는 경우가 많거든요. 그리고 며칠 뒤에 같이 근무하던 친한 동료들도 몇 명 같은 이유로 퇴사한다고 합니다.


큰 대기업의 뛰어난 기술자들이 왜 외국으로 기술을 빼돌릴까요? 그들이 왜 부모형제 있는 자라온 이 땅을 떠나서 다른 나라로 갈까요?


“사직서를 쓴 이유”의 내용을 보니, 야근의 적잖은 부분이 막 뎀비는 것, 그러니까 사전기획의 실패에서 비롯된 것이 많은 것 같습니다. 앞서 해외에 계신 교포분들 얘기도 선진국은 업무를 서두르면 실수가 벌어졌을 때 개선 비용이 더 많이 들어간다 생각하기 때문에 철저히 기획한다는 의미심장한 말을 해주었는데, 어떻게 생각하십니까.


처음 it를 시작한 8년전과 비교해 나아진 게 없습니다. 어디까지 구현한다는 범위와 기간 및 인력배분에 거짓이 많습니다. 폰제조로 미국 출장 갔는데, 국내최고의 대기업이라는 회사가 기능 구현 및 일정에 대한 기획서도 없었습니다. 국내 최일류 대기업마저 그렇게 허술하리라곤 생각못했습니다. 마지막 근무했던 업체의 경우 사전 기획에 대해서 신경을 쓰긴 하지만, confirm!!해서 만드는 기능조차도 변경되는 경우가 비일비재합니다. 그래도 납품기한은 그대로입니다.


기간 또한 항상 어처구니없게 짧습니다. 예를 들어 9to6, working day기준 두달 걸릴 프로젝트를 그냥 한 달로 잡습니다. 기획단계에서 야근과, 주말 출근이 들어가는거죠. ‘갑’쪽에서 너무 it에 대한 지식이 없어서 그럴 수도 있지만, 심할 때는 갑의 담당자가 자기 인사고과 반영하기 위해서 두 달 걸리는 프로젝트를 3주만에 만들어 달라고 하는 경우도 있습니다. 결국 이런 경우엔 개발 자체가 불가능하기 때문에 실제 프로그램 외에 그 담당자 인사고과용으로 demo만 돌릴 다른 프로그램도 같이 개발하기도 하죠.


인력도 참여 인원은 10명이라고 하곤 실제 투입된 인원은 4명인 경우가 비일비재 합니다. 더욱이 그 일만 하는 게 아니라. 다른 프로젝트와 양다리 걸치는 일도 많습니다. 결국 불가능한 기간과 없는 인력으로 프로젝트를 진행하다보니 비용이 더 들어가게 됩니다. 정상적인 설계가 되어야 하는데 나중엔 그냥 짜집기나 땜질식 개발이 됩니다. A버그를 해결하게 되면 B버그가 생기게 되죠. A버그를 잡을 때 발생될 side effect를 생각하지 못하게 되는 겁니다. 나중엔 너무 스트레스를 받아, 결국엔 개발자도 그냥 될 데로 되라 식이 됩니다. 이러니 개발기간은 늘어지게 되고 비용은 증가 하죠.


외국회사에서 근무를 해보지 않아서 잘은 모르지만 아는 개발자를 통해서 들은 바로는, 일정자체가 근무시간을 기준으로 하고, 세부적인 기능까지 구현일정을 잡아 정확한 인력을 투입한다고 합니다. 이렇게 하기 위해서 기획단계가 개발기간 중 가장 길다고 합니다. 할당 기간을 보면 기획>구현>검증 이 되는데 우리나라는 구현>검증>기획이라는 기형적인 형태가 됩니다. 노동강도가 0~10까지라면 외국은 4로 쭉 가다가 개발 끝 무렵이나 중간 큰 문제가 발견됐을 때만 잠깐 7정도로 올라간다고 하더군요. 그러나 한국은 제가 경험해본 거의 대부분의 프로젝트는 시작부터 끝가지 항상 7 이상이었습니다.


경영진이나 간부들은 이런 열악한 it 근무환경에서 일하는 직원에 대해 다독임이라도 있는가요.


제가 겪은 경영진의 마인드는 ‘개발자 또 구하면 돼지 뭐!’ 이런 식입니다. 몇 주씩 연속으로 날밤 새면서 개발하고 있는데 고작 탕비실에 강장제 한통 갖다 놓는 게 끝이더군요. 새벽 4시에 근처 여관으로 퇴근을 하면 다시 출근을 하더라도 오후 4시정도는 쉬어야 하는데, 그거 안봐줍니다. 그냥 정상 출근입니다. 회사의 생각은 "우리가 여관비 대주고 근처에서 재워줬지 않았냐?" 이런 식입니다. 초강도의 프로젝트를 진행하면서 회사는 얘기 합니다. "프로젝트 끝나고 refresh휴가 줄께." 두달을 매일 날밤 새기와 주말 풀출근을 하고 겨우 3일 받죠. 그러면 회사는 refresh휴가 가고 좋겠네 합니다.


실질적으로 직원들이 느낄 수 있는 보상은 거의 없습니다. 있다 하더라도 몇날 몇일을 날밤새며 근무한 거에 비하면 새발에 피죠. 회사에서 개발자를 보는 인식은 같이 가야할 팀원, 서로서로 윈윈하는 관계가 아닌 그냥 싸게 사용하고 버릴 도구 정도입니다.


이 살인적인 야근 등의 노동환경을 방치하는 이 사회에 한 마디 해주십시오.


그만둔 가장 큰 이유는 이런 문화가 외국처럼 변화할 기미가 거의 없기 때문입니다. it가 우리나라를 먹여 살릴 먹거리라고 떠드는 국가에서조차 개발자들의 처우 개선이나 노동법의 적용엔 인색하거나 아예 무시하고 있습니다.


다른 분야도 비슷하지만 폰분야는 정말 혹독하기로 유명합니다. 전 세계 다른 기업들의 체계잡힌 기획에 무조건 노동력투입으로 따라가는 방식은 한계가 있다고 생각합니다. 이제 점점 한국의 사람들도 돈보다는 삶의 질을 따지게 되는데 지금 고등학교 중학교, 대학교를 다니는 사람들이 저렇게 일을 할까요? 제 주위만 봐도 it학과를 나온 사람 중 개발자를 1~2년하고 포기한 사람이 80%이상입니다. 요즘 신입개발자 10명중 8명은 전업한다는 얘기가 있습니다. 그게 현실입니다.


큰 대기업의 뛰어난 기술자들이 왜 외국으로 기술을 빼돌릴까요? 그들이 왜 부모형제 있는 자라온 이 땅을 떠나서 다른 나라로 갈까요? 신문에선 연일 ‘매국노’니 ‘밤새서 열심히 개발해야할 개발자들의 정신력이 없어졌다’ 라니 떠드는데, 그럴 때마다 저는 이게 이 나라 한계구나라는 생각을 합니다. 나라를 위해서 힘든 군대까지 갔다온 제 애국심은 이제 온데간데 없이 사라졌습니다.


전 개발자라는 일을 너무 좋아합니다. 그러나 이제. 더이상은 이일을 지속할 생각이 없습니다. 정말 내일 아침 나라에 무슨 혁명이라도 나서 개발자들의 처우가 확 개선되어 다시 이땅에서 개발자란 일을 할 수 있었으면 합니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)


Trackback URL : http://prolee2001.tistory.com/trackback/30

  1. # BlogIcon Keating 2008/01/06 11:01 Delete Reply

    정말~ 슬픈현실입니다;;
    저도 이런 비슷한거 좀 당해보긴 했지만, 그래두 아직은 당해본 경험이 적은 탓인지
    아직까지는 떠날마음보단 어케든 이겨내고픈 마음이 더욱 큽니다!

  2. # BlogIcon BlueFrontier 2008/03/02 04:21 Delete Reply

    장문의 내용.... 잘 읽었습니다.
    한국의 프로그래머의 현실을 가장 적나라하게 표현한 글이 아닌가 합니다.
    IT업계를 떠나신다고 세상이 끝나는건 아니니까요.
    앞으로 계획하시는 일이 잘되셨으면 합니다.
    가족과의 행복도요.
    좋은 하루 되세요.

    1. Re: # BlogIcon 프로리 2008/03/03 09:23 Delete

      헛..ㅋㅋㅋ
      제가 당한게 아니구.. 다른분이 쓰신거 가져온거에요^^
      전 아직 파란만장한 22살이라구요~ ㅋㅋ

Leave a comment



출처 블로그 > 0 과 1 사이의 양다리
원본 http://blog.naver.com/sejinhom/120024150957

좋은 글이고 공부에 관한 전반적인 흐름에 관해서 적어놓아서 퍼올립니다.

작자 : 리사아빠 (원본출처:http://www.phpschool.com)


프로그램이란것은 컴퓨터가 알아 먹는 말로 일을 하게끔 하는 것에 불과하다는 생각이 듭니다. 그러기 위해서 알고리즘이나 자료구조나

언어라든지 한는 부수적인 지식들이 필요한 것이구요.


저는 인문계열 출신인데도 요즈음에는 프로그램을 할때 인문계열에서 공부를 한 것이 더 도움을 줄때가 많이 있습니다. 거의가 응용이지만 프로그램 언어를 공부할때도 알고리즘도 인문교양지식이 많은 도움을 줍니다. 대부분 사람들이 하면 할 수록 프로그램이 어렵다고 하는 것은 자신의 기본지식을 응용하는데에 한계점에 다달해서뚜렸한 실마리를 찾지 못해서 그렇다고 생각을 합니다. 저의 경우 인간의 언어에 대해서는 어느 정도 자신이 있는데 이 언어를 가지고 설명을 해 보겠습니다.



저는 스페인어 프랑스어 독일어 그리고 중국어는 보면 대충 이해를 하고 영어와 일본어는 모국어 가깝게 구사를 하는 편입니다. 그런데 이렇게 할 수 있었던 배경이 일본어를 모국어처럼 사용을 하게 되면서 자연스럽게 다른 언어를 쉽게 쉽득하는 습관이나 사고가 몸에 베어서 다른 언어를 쉽게 습득한 것에 불과하다고 생각을 합니다.



그런데 일본어를 배울 때 제가 가장 어렵게 느꼈던 것이 일본어가 아니라 모국어인 한국어가 어려웠던 사실입니다. 모든 언어의 기본이 되는 국어 실력이 없었던 것이지요. 한국에서는 고등학교밖에 나오지 못해서 언어라는 기본 개념도 없었던 것입니다.



그리고 언어라는 것은 한 언어의 단어를 많이 안다고 잘하는 것도 아니고 정치 경제 사회 문화등 각분야별로 어느 정도의 지식도 필요하기 때문에 단지 한국말이 모국어라고 해서 다들 한국말을 잘한다는 것도 아니라는 사실을 알게 되었지요.



그래서 제가 일본어를 배우는데 가장 먼저 착수한 것이 어떠한 언어라도 각분야의 지식이 필요하다는 생각에서 일본의 정치 경제 사회등 각분야의 책과 논문이나 사설등을 읽기 시작했습니다. 이해가 되지 않으면 그에 관련된 서적을 읽으면서 참고도 하였습니다.



그러면서 언어에는 각 단어마다 뚜렸한 개념이라는 것이 있고 그 개념에는 학문일 경우에는 그 학설을 주장하는 학자가 각 용어에 대한 정의를 뚜렸하게 제시하고 있다는 것을 깨닫게 되고 사전을 보는 습관이 생기게 되었습니다. 이러한 언어를 정확하게 개념적인 측면에서 일반 생활과 밀접한 부분을 가장 잘 정리해놓은 것이 육법전서라는 것도 알게 되었지요.



한치의 불필요한 말도 없고 더 보탤 말도 없을 정도로 완벽하리 만큼 논리적이면서 정확한 언어로 구사되어 있음을 알았습니다. 그래서 대학에서는 법에 관한 과목과 신학 철학 심리학등 학문의 기본이 되는 과목을 많이 선택해서 들었습니다. 그리고 제일 외국어를 프랑스어를 선택하고 영어는 영어로 강의하는 과목만을 수강을 했습니다.



이러면서 어느 순간에 일본어나 영어로 습득된 지식이 한국어로 습득된 지식의 양을 초월하게 되었지요. 그러나 역으로 이러한 지식들로 인해 언어에 대한 뚜렸한 개념이 몸에 베어 한국어로 된 전문서적이나 소설을 대할 때에 한층 더 모국어인 한국어에 대한 이해력과 국어 실력이 늘었다는 것을 경험하게 되었습니다.

그리고 고등학교 때에 미분과 적분 그리고 백터에 대한 개념과 왜 그러한 이론이 필요한것인가에 대해서 수학 선생님한테 물었다가 되지게 욕만 먹고 건방지다면서 가르쳐준 대로 하면 문제를 풀 수 있는데 말이 많다고 많은 친구들 앞에서 꾸지람을 당한 적이 있었습니다.



그 이후로 수학이라는 과목은 쳐다 보기도 싫었고 항상 꼴지에서 뱅뱅돌아 선생님한테 넌 가르쳐주는 것도 모르면서 말이 많다고 줄업할때까지 욕을 먹었던 기억이 있습니다. 한마디로 교육의 폭행을 당한 것이죠. 그러나 대학에서 심리학이란 과목을 들었을때 거의가 확율과 수학의 이론에의해 가설을 입증하고 하나의 이론으로 정립되 가는 것을 보고 너무 어려워서 그 담당 교수에게 부탁을 해서 따로 필요한 수학 지도를 받았는데 너무나도 이론과 개념에 대해서 상세하게 가르쳐 주어서 2시간 만에 미분과 적분 확율 그리고 백터까지 정확하게 개념적으로 이해를 할 수 있었던 경험도 있습니다. 경제 경영 마케팅이란 과목도 거의 수학이었는데 심리학과 그 교수 덕분에 쉽게 점수를 딸 수 있었습니다.



위의 과목에서 제가 한국어로라도 수학적인 기본지식이 있었다면 따로 교수에게 부탁을 하지 않고도 수월하게 그 과목을 이해를 할 수 있었을 겁니다.


이러하듯이 언어란 것은 일반적인 사회생활이나 전문적인 분야에서도 관련지식이 따라 주어야 진정한 언어로서의 실력이 느는 것입니다. 영어나 일어를 대학에서 전공한다고 해서그 사람이 그 언어를 아주 잘 한다고 할 수 없는 것도 이러한 이유때문입니다. 한국에서 대학을 다녀보지 못해서 모르지만 영어를 전공하면 문학을 하는 사람도 있을테고 영어의 문법을 학문적으로 하는 사람도 있을 겁니다. 그러나 이런 전공을 하는 사람들도 학문적으로 연구를 하기 위해서는 자신이 연구하는 분야에서 자신의 가설을 증명하기 위해서는 영어라고 하더라도 모든 학문에서처럼 그 검증 방법이 대부분이 같다는 것입니다.


예를들어 자연 인류학에서 여기 저기에서 발굴되는 뼈와 유적들을 가지고 체계있게 정리를 하고 그것에서 얻어진 자료들을 바탕으로 이러이러했을 것이라는 것을 가설을 세우고 그것을 과학적으로 입증한 것이 학설입니다. 그리고 그 학설이 많은 학자들로부터 인정을 받고 의심의 여지가 없고 권위가 있으면 우리들은 역사책에서 그것을 줄쳐 가면서 외우고 입시에도 시험문제로 나오고 하는 것입니다. 자료를 정리하는 예를 하나 설명하자면 여러 유물들이 출토 되었을 때 그 자료들을 하나의 자료에 대해서 하나의 카드에다 기록을 합니다. 그리고 카드를 섞어서 자료들이 완전히 무의미하고 아무 관련성이 없는 상태로 합니다. 이것은 자신의 선입관이나 몸에 베어있는 지식에 영향을 받지 않게 하기 위해서입니다. 그리고 여러 사람들이 모여서 카드 한장 한장을 책상위에 같은 부류라고 생각되는 것을 직감적으로 같은 곳으로 모아 둡니다. 그러면 자료들이 정리가 되고 그 자료들의 연관성이 보이고 다시 분류를 하고 하는 과정을 되풀이 하다보면 일관된 규칙들이 발견됩니다. 그리고 이 규칙들을 기본으로 재 정리하고 과학적인 방법으로 입증해 사람들이 알아보게 언어로 설명을 하면 그것이 학설입니다. 학문이라고 어려운 것은 아닙니다.


이러한 기본적인 과학적인 입증방법으로 정리해서 글을 쓰면 그것이 학문이 되는 것이지요. 언어도 마찬가지로 하나의 언어를 아주 잘 구사할 수 있으면 언어의 공통적인 개념들이--과학적인 입증방법이 모든 학문에서 거의 동일 하듯이--비슷하기 때문에 다른 언어도 쉽게 익힐 수 있는 것입니다. 제 경험으로 6개월이면 하나의 언어를 어느정도 마스터할 수 있으리라는 생각을 합니다.


가끔 영어는 어떻게 공부하면 되요 라는 글을 대하는데 가장 좋은 방법은 그냥 소설책 하나 사다가 다 외워 버리면 됩니다. 그리고 그것을 바탕으로 다른 책들을 계속 읽어 나가다 보면 저절로 실력이 늡니다. 영어를 하기 위해서 공부하지 말고 필요한 지식을 영어로 습득하기 위해서 책을 보아야지 항상 줄쳐 가며 이놈 영어 배워야지 정복해야지 하다보면 죽을 때까지 영어만 공부하다가 끝입다. 회화를 하고 싶으면 어느정도 이러한 실력을 키우고 현지에 가서 더도 말고 6개월 정도만 살다 오면 귀가 트이고 왠만한 것은 다하게 됩니다. 이것은 언에에 대해서 저의 경험담을 쓴 것입니다. 그럼 프로그램의 경우는 어떠할까요?



프로그램을 하기 위해서는 적어도 하나의 컴퓨터 언어를 습득해야합니다. 많은 사람들이 컴퓨터 언어를 배우다가 프로그래머의 일을 마치거나 어느 정도 하다가 관리자가 되어 프로그래머의 길을 떠나는 사람들도 있습니다. 또는 중도하차하는 사람들도 많구요.


프로그램 언어도 인간의 언어와 마찬가지로 국어 하나만 잘하고 언어의 개념만 확실히 정립해 놓으면 새로운 다른 언어를 쉽게 배우고 새 문화에 대해서 바로 익숙해 질 수 있는 것처럼 새 언어와 기술이 나오더라도 별 큰 의미는 없는 것입니다. 0과1의 세계는 다름이 없기 때문입니다.



언어는 타인과 의사소통을 위한 수단이고 컴퓨터 언어는 컴퓨터가 알아 먹고 일을 하게끔하는 수단에 불과합니다. 만약 양자 컴퓨터가 실용화되어 0과1의 중간의 개념도 배워야 하는 시대가 온다면 지금까지 배워온 모든 것을 버리고 개념부터 다시 배워야 하겠지만요.



가끔 이 포럼란에 그러한 언어에 대한 글이 올 때마다 왜 그러한 언어에다가 목적을 두고 살아가야 하는 것인가에 대한 의문을 가지게 됩니다. 그것은 회사에서 채용을 할때 이러 이러한 언어가 할 수 있어야 하고 경험은 몇년이고 하는 채용 풍토나 기준으로 인해 학원이나 전문대등에서 언어 습득에 목적을 두는 교육을 받은 사람들이 많았기 때문이라고 제 나름대로 분석을 하고 있습니다. 그리고 2,3년에 모든 컴퓨터 이론을 가르친다는 것도 불가능하구요.



사실 하나의 소프트 엔지니어다운 엔지니어를 한명을 배출해 내려면 미국이나 일본의 커리쿨럼으로 7년이라는 과정이 필요합니다. 동경대의 한 교수가 소프트 공학 커리쿨럼에 대한 연구 논문이 책으로 나와서 한번 읽어본 기억이 있습니다. 이 논문에서는 경영과 일반 인문교양도 많이 포함되어 있고 실질적으로 인턴과정을 포함하면 10년이 필요하다고 주장합니다.


2년 3년으로 한가닥 한다는 것은 택도 없는 소리입니다. 저역시 프로그램은 오래하고 있지만 많이 부족하고 아직도 공부를 계속하고 있습니다. 저는 공부를 할때에 주로 일반 미국의 공과대학에서 커리큘럼 과목으로 지정되어 있는 것들을 10년 계획으로 조금씩 공부를 하고 있습니다. 지금은 컴파일 이론을 실질적인 프로그램 소스와 서적으로 공부하고 있습니다. 제가 머리가 나빠서 아마 2년 정도 걸리리라고 생각을 합니다. 자료구조나 이러한 것은 도서관학에 관한 서적을 주로 많이 봅니다. 현재 프로그래머로 일하는 대부분의 사람들이 회사에 다니면서 일을 하기 때문에 일하는데 바빠서 다른 공부를 할 기회도 없을 것이라는 생각을 합니다.


그리고 현재에 알고 있는 몇개의 언어 지식을 최대한 우려먹고 우려먹고 해서 더짜도 국물도 제대로 안나오는 상황에 처한 분들도 많이 있을 겁니다. 응용이니 하는 것들은 상상도 할 수 없는 상황도 많을 거구요. 그러다 새로운 무슨 NET니 뭐니 하는 것이 나오면 저것도 해야지 밥줄 끊기지 않겠구나 하는 위기감에 처해 지거나 불안해 하고 힘들어서 더이상 프로그램일 못해 먹겠다 하고 생각하는 사람도 많이 있을 겁니다.

하나의 컴퓨터언어에 대해서 정확하게 프로그램소스를 이해하고 진정한 프로라고 말을 할 수 있을 정도의 실력이 되려면 PHP와 같은 스크립 언어라고 해도 제 생각으로는 주변 지식들을 포함하면 적어도 4년은 걸릴거라는 생각이 듭니다. 제가 머리가 나빠서 그렇게 걸리고 머리 좋은 천재는 1년 이내에도 해 내겠죠. 일본어의 경우는 제가 어느정도 실력을 갖추었다고 생각을 한것이 항상 사용하면서도10년째가 되었을 때입니다.

영어도 그랬구요. 그래도 부족하다고 생각이 들어 지금도 시간이 있으면 서점에 가서 책을 사다가 분야를 가리지 않고 읽고 있습니다.


다른 언어를 6개월만에 어느정도 할 수 있다고 말한 것은 이러한 한 언어의 기본이 있기 때문에 필요성이 느껴진다면 6개월 정도 집중적으로 한다면 어느 정도는 할 수 있다고 말한 것에 불과합니다. 그리고 어느 정도 프로그래머로 일해서 팀장이나 해서 프로그램일을 때려 치우고 싶다는 생각을 가진 사람도 많으리라고 생각을 합니다. 그러면 컴퓨터 소프트 공학의 입문도 마치지 않은 영원한 초보로 남을 것이고 그러한 초보 밑에서 일하는 사람 역시 똑같은 초보의 길로 유도를 하리라고 생각을 합니다.


요즈음 서울 대학이나 여러 대학의 전삭학과 연구실 사이트를 들락 거리고 있습니다. 그러면서 전산학 계열의 대학을 나온 다고하더라도 연구 분야의 내용이나 커리큘럼의 과목이나 수준을 보면 역시 대학을 나와도 소프트 엔지니어 차원에서는 아주 초보라는 생각이 많이 들게 됩니다. 그런 고급 인재들은 회사에 취직하면 대부분이 어느정도 하다 실력이 막 늘고 어느 정도 실력자가 되려고 할때 그들은 전부 관리직으로 가게 되고 또 다시 그들 밑에는 초보자들이 들끊는 회사로 전락을 하게 되는 것을 되풀이 하는 것이 아닌가하는 마음이 듭니다. 이러한 것은 일본의 미즈호 은행과 같은 참사를 낼 소재들을 만들어 가는 것이라고 생각을 합니다. 일본도 어느 프로그램 일을 하면 관리직으로 일을 하는 것은 마찬가지 입니다. 제가 일본에서 취업 활동을 하면 거의 대부분의 회사가 관리직으로 와달라고 합니다. 연봉은 800만엔 이상 주겠다고들 합니다. 저는 연봉이 그 반 값이라도 프로그래머로 일하고 싶다고 해도 그런 자리는 제가 만 35살이라는 이유로 프로그래머로서는 회사측에서 고용을 할 수 없다고 합니다. 저는 그러면서 일본도 이제는 맛이 갔구만, 이대로 10년 정도만 흐르면 일본의 시스템도 빵꾸가 나겠구만, 미즈호 은행사건이 있었으면서도 회사들이 아직도 정신을 차리지 못했구나 하는 생각으로 프리랜서로서의 길을 고집하고 있습니다. 프로그래머로 오래 남으려면...? 이 아니라 저는 오래 해야만 된다는 생각을 하는 사람입니다. 그렇지 않으면 언제까지나 한국은 미국 소프트의 최대 소비국으로 남을 것이고 매번 새로운 언어나 개발툴이 나올때마다 테스트 시장으로 전락을 하게 되리라고 생각을 합니다. 그리고 PHP는 훌륭한 언어입니다. 펄도 그렇구요. 다들 쓸모가 있기에 있는 언어이고 하나라도 잘 하면 다른 것들도 다 잘 하게 되고 어렵지 않습니다. 만약에 다른 언어가 필요하다면 구현하기 위한 필요한 부분만 하면 되는 것입니다. 많은 프로그래머들이 먼저 현시점에서 자신이 가장 자신이 있는 하나의 언어를 정말로 프로라고 자신할 만큼 해놓고서 다른 언어에 대해서도 이야기를 해주었으면 하는 바램입니다. PHP 2,3년 하고 게시판떼기 일주일만에 만들었다고 하는 것은 소프트 엔지니어 세계에서는 의미가 없는 일입니다.



게시판도 제대로 만들면 저는 3년은 걸리리라고 생각하고 있고 실제로 제가 하나 만들고 있는 게시판은 펄로 5년째 작업을 하고 있는 것도 있습니다. 처음 이곳에 와서 그러한 이야기들을 읽고 다들 대단하구나. 정말로 나라는 인간은 돌대가리구나 하는 생각도 가져도 보고 얼마나 잘 만들었나하고 다운로드해서 설치해도 제법 잘 돌아가고 해서 다들 천재들만 이곳에 오는 구나하고 한때에 감탄도 하고 그랬습니다. 몇개의 개시판 소스를 면밀히 분석해 보고 타이핑 속도까지 계산을 해서 일주일 만에 가능 한가를 조사해 보기도 했지요. 설계부터 완전하게 새롭게 만든다면 대부분이 뻥이고 만들어 놓은 것 같다 붙이면 하루 라도 만들 수도 있고 그렇다는 생각을 하게 되었습니다. 일주일 만에 만들었다고 해서 저는 모두 새롭게 만들었을 때를 기준으로 생각을 했었지요. 저야 회사다니면서 일을 하는 것이 아니라 완전히 개인 플레이라서 다른 사람이 어떻게 프로그램을 하고 회사에서는 어떻게 일을 하는 지도 모릅니다. 제가 이렇게 혼자서 일을 하는 것은 회사에서 나와같은 사람을 유용하게 활용할 수 있는 그런 회사가 거의 없기 때문입니다. 그리고 저는 죽는 그날까지도 프로그램을 할 생각입니다. 그렇게 해도 모자라고 모르는 것이 많이 남아 있으리라고 생각을 하고 있습니다.



정말로 프로그래머다운 프로그램을 하고 싶으면 배워야 하는 것이 끝이 없습니다. 저는 프로그램때문에 대학에서 졸업한 사회인에게 공개하는 강좌 중에 증권 투자분석 과목을 들은 적도 있습니다. 그 밖에도 많이 있습니다. 언어 하나만 달랑 배워서 프로그램을 한다는 자체가 문제가 있는 것이라고 생각을 합니다. 한때 데이터 베이스와 파일 시스템을 연구 할때에 일본 국회 도서관에 가서 어떻게 책이 대출되고 어떠한 방법으로 그많은 책들을 관리 하는가 하느 것들을 조사한 적도 있습니다. 이러한 경험들은 운영시스템의 파일 시스템을 설계하는 데에 많은 도움을 준 부분입니다. 알고리즘과 같은 것은 이러한 여러 경험과 지식에서 힌트를 얻습니다. 어느정도 하나의 컴퓨터 언어를 하게되면 응용력과 여러 지식들이 결합되어 하나의 소프트를 창출해 내는 것이라고 생각을 합니다. 많은 사람들이 C언어를 해야 됩니까라고 질문을 하는데 그 이전에 어떠한 것을 만들고 싶다라는 것이 선제 되어야 합니다. 저의 경우 스피드가 빠르고 사이즈가 작은 운영체계를 하나 만들고 싶다라고 하여 어셈블러를 선택한 것입니다. 사실 C언어로 해도 상관은 없습니다.


그러나 C언어로는 링커로 링크를 할때 불필요한 데이터들이 많이 들어 가고 아무리 사이즈를 최적화 해도 어셈블러의 스피드와 사이즈에서 따라 잡을 수가 없습니다. 언어는 하다보면 언젠가는 자연스럽게 수준이 높아지고 잘 할 수 있습니다. 그러나 그언어로 구사하는 프로그램은 언어를 잘하는 것만으로는 잘 할 수 없는 것이라고 생각을 합니다. 위에서 말한 인간의 언어에서와 마찬가지로 다방면의 지식과 경험이 훌륭한 프로그램을 만들 수 있는 것이라고 생각을 합니다. 하나의 소설을 쓰자면 언어는 물론 그 소설에 등장한는 모든 인물의 직업에 관해서도 그 인물이 회사에서 어떠한 일을 하는지도 일반 회사에서의 인간관계 하다못해 점심시간에는 어떤 메뉴를 잘 먹는다라는 사소한것도 잘 알아야 하니까요.