천객만래 [千客萬來] (It has an interminable succession of visitors)

SW 개발자의 길, 아니다 싶으면 포기하라


20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다

Posted by SB패밀리


프로그래머, 훌륭한 프로그래머란….

과연 내가 성공한 프로그래머라고 말할 수 있는지 내 스스로 확신할 수는 없다. 나는 다만 어떻게 하면 완벽하게 알고리즘을 만들어 프로그래밍을 해야 할지 항상 생각하고 있고, 학교에서 강의를 통해 학생들이 좋은 프로그래머가 되기 위해 어떻게 해야 하는지 계속 훈련시키고 있을 뿐이다.

또 미국의 한 소프트웨어 회사의 연구소를 방학마다 방문해 데이터베이스와 데이터마이닝 등 여러 문제를 놓고 어떻게 하면 아무런 문제없이 쓸 수 있는 소프트웨어를 더 완벽하게 만들 수 있는지를 항상 고민하고 있다.

'그냥 컴퓨터랑 프로그램이 미칠 정도로 좋아서' 거기에 푹 빠져 평생 살아온 것이고, 그래서 전공도 전산학으로 바꿔 소프트웨어의 본고장이라 말할 수 있는 미국에서 공부하고, 미국의 HP, IBM, 루슨트, 마이크로소프트 등 여러 소프트웨어 회사에서 큰 프로젝트를 수행한 경험을 갖고 있을 따름이다.

하지만 가만히 생각해 보니 과연 진정한 프로그래머란 무엇일까라는 질문에 대해 내 나름대로 한번 골똘히 생각해보는 것이 가치있는 일인 것 같고, 또 IT의 강국이라 불리우는 미국에서의 경험이 프로그래머가 되려하는 국내의 많은 이들에게 조금이나마 도움될 것 같아서 내가 그동안 살아온 인생 역정을 간략하게 소개하기로 한다.

부족한 점이 있더라도, 혹은 나와 다른 생각을 가진 독자가 있더라도 너그러이 이해해주길 바란다.

컴퓨터에 푹 빠졌던 그 시절
내가 프로그래밍에 처음 관심을 갖게 된 것은 1983년 여름방학으로 거슬러 올라간다.

당시 국내에서는 퍼스널 컴퓨터에 대한 기술이나 노하우가 전혀 없었던 실정에서 삼성전자와 금성사(지금의 LG전자)는 일본의 NEC에 돈을 주고 PC의 설계를 의뢰해 그 설계대로 PC를 만들어 국내에 판매하고 있었다.

그때만 해도 뭄?컴퓨터는 단지 베이직이라는 언어만을 제공하고 있었다. 또한 청계천의 전자상가에서는 미국 애플 컴퓨터를 불법으로 복제해 팔고 있었고, 애플 컴퓨터의 여러 고급 언어뿐만 아니라 수많은 소프트웨어가 불법으로 국내에 유통되고 있었다.

당시에는 국내 기업들이 PC를 사거나 약간의 수강료를 낼 경우 자사의 컴퓨터를 쓸 수 있도록 1주일 정도 간단하게 베이직 언어 등을 가르쳐줬다. 나도 그때 컴퓨터가 무엇인지 알기 위해 수강료를 내고 1주일 동안 금성사의 퍼스널 컴퓨터를 배웠다.

나에게 있어서 PC는 너무나 신기한 것이었다. 음악을 연주할 수 있고, 그림을 그릴 수도 있고, 또 간단한 수학적인 것들을 계산해 볼 수도 있고, 주어진 숫자들을 정렬할 수도 있었다. 이러한 것들은 대학 2학년생이던 나를 너무나 매료시켰다. 일주일 동안 배운 내용으로는 부족한 것이 많아 동화서적에서 나에게 컴퓨터를 가르쳐준 강사를 계속 찾아가 궁금한 것을 물어 보며 배우기 시작했다.

하나씩 알아가는 기쁨이 있었던 PC
그때는 정말 밤새도록 프로그래밍을 하면서 내가 원하는 것이 PC로 수행되는 것을 볼 땐 정말 즐거웠다. 국내에 PC에 대한 서적이 거의 없는 현실에서 이것저것 베이직 인터프리터의 내용을 분석해 하나씩 알게 될 때마다 그 기쁨은 이루말할 수 없었다.

사실 베이직 인터프리터라는 것이 기계어로 돼 있어 C++와 같은 고급언어로 돼 있는 프로그램과 달리, 눈으로 보고 이해하기는 많은 어려움이 있었다. 그래서 인터프리터의 기계어를 역 어셈블해 하나하나 분석한 후에 이해할 수 있었을 때는 정말 뛸 듯이 기뻤다. 또 청계천의 서점에서 일본책들을 구해, 비록 국내 PC와 호환성은 없는 내용이지만 바꿔서 국내 퍼스널 컴퓨터에서 돌아가게 했을 때, 그 기쁨은 말할 수 없었다.

어렵게 알아낸 만큼, 알아낸 내용을 값지게 활용하고픈 욕심은 어쩌면 당연한 것이었다. 국내에서 주최하는 각종 PC 경진대회에 출전해 여러번의 입상 기회를 가질 수 있었다. 1985년 대우전자에서 주관하는 소프트웨어 공모전에서 금상을, 과기처주관 소프트웨어 경진대회의 경시부문과 공모부문에서 문교부 장관상과 상공부장관상을 각각 수상했다.

또한 1985년부터 1987년에 걸쳐 마소에 'MSX의 모든 것'을 시작으로 여러 편의 글을 기고하기도 했다. 당시에 MSX는 여러 회사의 PC 소프트웨어들의 호환성을 보장하기 위해 제안된 표준사양이었다. 그때엔 이처럼 하나하나 분석해 알아낸 것들을 국내에 알려주는 일 역시 큰 기쁨 중에 하나였다.

프로그래머 인생의 새로운 출발, 미국으로의 유학길
이렇게 퍼스널 컴퓨터와 씨름하면 할수록 궁금증은 더해만 갔다. 예를 들어 정렬 알고리즘들이 왜 여러 가지가 존재하는지 나는 사실 이해할 수 없었다. 단지 책에 나와 있는 내용을 그대로 베껴 수행시켜보면 알고리즘에 따라 수행속도가 무척 다르다는 점만 알고 있었다.

하지만 내가 사서 봤던 일본 서적들은 단지 라이브러리처럼 소스 코드를 보여주기만 할 뿐, 왜 같은 데이터로 다른 수행속도를 보이는지에 대해서는 전혀 설명하지 않았다.

나의 이러한 호기심은 전산학 과목을 들으면서 조금씩 해소되기 시작했다. 자료구조론, OS, 컴파일러, 시스템 프로그래밍 등의 강의는 나의 궁금증을 조금씩 해소시켜줬다. 하지만 국내에 전산학을 제대로 전공한 사람들이 당시에는 별로 없었으며, 시대적 여건 또한 힘든 상황이었기 때문에, 나는 미국에 유학가기로 마음을 먹었다. 유학을 가기로 마음을 정한 후에는 정말 열심히 공부했다.

하지만 웬만한 부자가 아니라면 유학은 꿈도 못꿀 일이었다. 가난했던 내가 유학을 가기 위해서는 미국의 학교에서 재정적인 보조를 받아야만 했기 때문에, 좋은 학점을 받아야만 했고, 그래서 열심히 공부했다.

본격적으로 전산학 교육을 받으면서
마침내 졸업할 땐 내가 공부했던 전기공학과에서 수석으로 졸업할 수 있었고, 미국에서 전산학 분야로 이름난 학교 중 하나인 University of Maryland at College Park의 전산학과 대학원에서 학비 전액 면제와 생활비 보조를 받으며 공부할 수 있는 기회를 얻었다. 전산학과를 졸업하지 않았어도, 다른 학부 전공에서 우수한 성적을 얻은 만큼, 전산학을 하더라도 잘할 거라고 믿어주는 교육 시스템은 기꺼이 나를 받아준 것이다.

나는 사람들에게 기회를 주는 미국의 시스템을 존경한다. 내가 전산학을 할 수 있었던 것도 사실은 유학을 갔기 때문에 가능했던 것 같다. 당신 국내 대학원에 진학하려면 전산학 관련 과목의 시험을 봐야했고, 또 해당 학과를 나오지 않으면 대학원 진학이 무척 힘들던 시절이었다. 하지만 미국 대학들은 그런 점에 상관하지 않고 나에게 기회를 줬고, 프로그래머로서의 내 인생은 달라졌다.

대학 1학년 때 지하철을 타고 가다 리더스 다이제스트 잡지에서 읽었던 한 구절의 글이 인상깊은 기억으로 남아있다. "항구에 정박해 있는 배는 안전하다. 그러나 배는 항구에 묶어두기 위해 만든 것이 아니다". 그 글을 본 순간 나는 너무나 벅찬 감동을 받았다.

돌이켜 생각해 보면 그 글은 내가 인생을 살면서 여러 갈래의 길에 서게 될 때마다 어려운 길일지라도 항상 도전할 수 있는 힘과 용기를 갖게 해줬다. 아마 내가 어려운 가정 형편이지만 미국으로 유학을 가려고 시도했던 것도 바로 그 글 때문이 아니었을지….

창의력 기르기 위한 끊임없는 훈련 돌입
미국의 대학원에서 전산학을 공부하며 제일 먼저 놀란 점은 아무도 프로그래밍이나 숙제를 남의 것을 베끼지 않고, 누구나 스스로 한다는 것이었다.

또한 우리 나라의 주입식 교육 방식과 달리 창의력을 길러주기 위한 방향으로 교수가 가르친다는 점이었다. 예를 들어 전산과에 1학년으로 들어오면 그 당시에는 파스칼이라는 언어를 가르치는데, 프로그래밍을 할 때 쓸 수 있는 타입은 캐릭터만을 주고 정수(integer)나 실수(float) 타입은 전혀 쓸 수 없게 해서 프로젝트를 코딩하게 한다.

이렇게 하면 "I := I+1"과 같은 문장 하나를 수행시키려 해도, "0" 이면 "1"로 바꾸고 "1"이면 "2"로 바꾸는 한 자리 숫자에 1을 더하는 프로시쥬어를 먼저 만들어야 한다. 그 다음에 그, 프로시쥬어를 이용해 여러 자리의 수에 1을 더하는 프로시쥬어를 만들고 사용해야만 한다.

물론 이렇게 코딩하려면 기존의 언어에서 간단하게 할 수 있는 프로그램도 사이즈가 길어지고 아주 많은 잡일이 필요해진다. 하지만 쓸 수 있는 언어의 모든 기능을 허용하지 않음으로써, 학생들은 많은 생각을 해야만 하고 그렇게 해서 창의력이 길러지는 것이다.

또한 1부터 10까지 더하는 프로그램이 있을 경우, 그 프로그램이 정말로 그 합을 구한다는 것을 증명하는 방법을 학생들에게 가르쳤다. 당시 미국으로 공부하러 갈 때까지 프로그램을 증명 한다는 말은 들어보지도 못한 때였다.

또 자료구조라는 과목을 미국에서 들었는데 학기말 프로젝트가 LISP라는 언어의 인터프리터를 만드는 것이었다. 당시에 상용화 돼 팔리고 있던 소프트웨어를 학기말 프로젝트로 한다는 게 과연 가능할까 생각했지만, 그 과목을 공부하는 동안 그런 능력을 갖출 수 있도록 스케쥴대로 우리들은 훈련되고 있었다.

LISP라는 언어는 리스트, 스택, 해싱 등 자료구조 과목에서 배우는 모든 것을 실제로 사용해야만 완성할 수 있는 것이라서, 그 과목에서 배운 내용을 실제 사용할 수 있게끔 만드는 경험을 얻을 수 있도록 나를 훈련시켜줬다.

처음부터, 학부 과정부터, 다시 시작하는 마음으로
단지 생각나는 대로 주먹구구식으로 프로그래밍을 하던 나에겐 너무나 충격적이고 익숙하지 못한 시스템이었기에 처음에는 공부하기가 너무나 힘들었다. 시험 문제도 족보에서 나오지 않았으며, 암기해서 쓸 수 있는 문제 또한 시험에 전혀 나오지 않았다.

10년 된 강의 노트를 그대로 사용하지도 않았고, 숙제조차도 교수가 일일이 매번 새로 문제를 만들어 나눠주기 때문에, 항상 많은 시간 생각을 해야만 풀 수 있었던 문제들…. 그것들을 통해 나는 아주 느리지만 조금씩 창의력을 키워나갈 수 있었던 것 같다.

나는 그때까지 내가 배워왔던 모든 것을 떨쳐버리고 처음부터 시작한다는 마음을 먹기로 했다. 한국에서 '일류대'라 부르는 학부를 졸업했고, 과 수석을 했다는 사실은 모두 던져버리고 겸손해져야 제대로 배울 수 있다는 생각으로, 전산과 학부 과목부터 하나씩 들었다.

그로 인해 석사나 박사를 받는 시기가 늦어지긴 했지만, 어떻게 보면 오히려 학부 과목부터 하나씩 공부하고 기초부터 튼튼하게 키움으로써, 나중에 더 만족할만한 논문을 쓸 수 있지 않았나 싶다.

우리 나라에서 종종 20대 박사라는 둥, 박사과정을 몇 년만에 마쳤다는 둥 그런 이야기를 신문이나 잡지에 내세우고, 또 자부심을 갖는 걸 보면 참 한심하다는 생각이 든다. 미국에서는 그런 걸 별로 중요하지 않게 생각한다. 오히려 중요한 것은 얼마나 좋은 논문을 썼는가, 얼마나 세상에 영향을 끼칠 수 있는 것을 연구해 개발했는가를 더 중요하게 생각한다.

또 박사학위를 받은 후에 좋은 곳에 일자리를 얻기 위해 졸업을 할 수 있지만 일부러 졸업을 미루면서 더 좋은 논문을 많이 쓰려고 하는 경우도 많이 볼 수 있다. 사실 무조건 학위를 받는 것이 중요하다면 얼마든지 쉬운 논문 주제를 찾아 쉽게 졸업할 수도 있다. 하지만 단지 박사 학위만을 받는 것이 과연 무슨 의미가 있을까.

왜 데이터베이스인가, Because it is there!
나는 1988년에 컴퓨터 그래픽 분야로 석사논문을 썼고, 국내에 병역문제로 들어왔다가 다시 들어가서 1990년 여름부터 박사과정을 계속했다. 나는 여러 분야 중에서 데이터베이스 분야를 박사 논문주제로 연구하기로 했다. 관계형 데이터베이스 시스템(Relational Database System)에서는 SQL이라는 언어를 가지고 질의(Query)를 표현하는데, 이 언어에서는 데이터 중에서 무엇을 원하는지를 나타내면, 데이터베이스 시스템의 질의 수행에 있어 가장 최적의 수행 방법을 찾아 수행시켜준다.

이때 최적인 방법을 찾는 문제는 아주 복잡한 문제로(전산 용어로 NP-Hard의 클래스에 들어가는 문제임) 질의의 최적화(Query Optimization)라 불리운다. 이 최적화가 효율적으로 기능을 발휘할 때 비로소 데이터베이스 시스템이 초보자에게도 효과적으로 사용될 수 있다. 논문을 준비하던 당시에는 객체 지향형 모델(Object-Oriented Model)을 관계형 데이터베이스 시스템(Relational Database System)에 접목하려던 시점이었기 때문에 새로운 여러 질의 최적화 문제를 해결해야만 할 때였다.

질의 최적화의 문제들은 새로운 알고리즘을 만드는 것이었고, 프로그래밍을 즐겼던 나에게는 너무나 재미있는 문제들이었기 때문에 데이터베이스의 질의 최적화 는 나의 관심을 사로잡을 수 있었다.

이쯤에서 George Mallory라는 영국 탐험가 이야기를 꺼내려 한다. 그는 에베레스트 산의 등정을 최초로 여러 번 시도하다가 사고로 죽었는데 아직도 그가 에베레스트 산의 정상에 올라간 후에 죽었는지 아니면 오르지 못하고 죽었는지는 미스테리로 남아있는 부분이다. 그러한 그가 죽기 전에 많은 사람들이 그에게 왜 위험한데도 에베레스트 산을 자꾸 오르려 하냐고 질문했다. 그때 그는 이렇게 대답했다고 한다. "Because it is there."

만일 나에게 누가 왜 데이터베이스를 연구하게 됐는지 물어본다면 나도 그렇게 말하고 싶다. "엄청난 양의 데이터가 언제나 바로 내 옆에 있었기 때문이다"라고. 이젠 인터넷 전체가 커다란 데이터베이스나 다름없다. 간단한 컴퓨터와 인터넷만 있으면 나에게 필요한 모든 데이터를 쉽게 접근할 수 있는 시대가 돼버린 것이다.

완벽한 소프트웨어를 만든다는 것
박사 과정 중에는 데이터베이스의 최첨단 연구소 중 하나인 HP 연구소에서 Surajit Chaudhuri 박사의 섬머 인턴 학생으로 1992년과 1993년 여름에 공동으로 연구했고, 여러 편의 논문을 데이터베이스 분야에서 권위있는 여러 데이터베이스 학술회의에서 발표했다.

미국 실리콘밸리의 벤처 1호 회사라고 알려진 이 회사는 스탠포드 대학을 졸업한 윌리엄 R. 휴렛과 데이빗 패커드가 1939년 공동으로 차고에서 시작했다. 그들이 처음 만들어 판매한 제품은 오디오 오실레이터로 월트 디즈니사에 처음으로 납품했고, 그때 사용된 차고는 지금 미국 캘리포니아 주의 역사적인 사적지로 지정돼 있다.

이 회사의 연구소에서 느꼈던 것은 프로그래머들이 그냥 무조건 코딩을 하는 것이 아니란 점이다.

오랫동안 수많은 연구와 생각을 거듭해 자신이 디자인한 알고리즘이 전혀, 조금이라도 문제가 없다고 생각될 때라야 코딩을 한다. 그냥 일단 별 생각없이 코딩부터 시작하는 나의 초창기 프로그래머로서의 모습과는 너무나 대조적인 스타일이었다. 하지만 그것이 얼마나 중요한 일인지는 그 뒤로 명성있는 미국 소프트웨어 회사들에서 일하며 몸소 깨닫게 됐다.

코딩을 위한 기초 공사 튼튼히 해야
사실 보통 사람들은 프로그래밍을 하는데 주먹구구식으로 그냥 코딩부터 하는 경우가 많다. 하지만 강조하고 싶은 것은 훌륭한 프로그래머가 되려면, 우선 깊이 생각해서 알고리즘을 디자인한 후에 정말로 우리에게 주어진 문제를 완벽하게 수행해준다는 것을 증명하고, 수행 속도라든가 필요한 메모리의 양을 분석해야 한다는 것이다.

그런 다음에 정말로 코딩을 해서 실제 데이터를 갖고 알고리즘을 수행시켰을 경우 완벽하게 해낼 수 있는 완전한 시스템을 만들 수 있으리라는 확신이 섰을 때에 비로소 코딩해야 한다.

프로그래머가 되려는 사람 중에는 이러한 분석이나 디자인을 위해 필요한 기초인 자료구조, 오토메타 이론, 알고리즘, 데이터베이스, OS 등의 내용을 배우려하는 것을 등한시하면서도 프로그래머가 될 수 있다고 생각하는 이가 있다.

다시 한번 강조하지만 건물이나 다리를 짓는 데에 있어서도 지진이나 그밖에 다른 이유로 무너지지 않게 하려면 아주 정확한 계산에 의한 설계와 기초 공사가 아주 중요하다. 마찬가지로 완벽한 소프트웨어를 만들려면 그러한 것을 코딩하기 위한 기초가 되는 내용들을 열심히 공부해 튼튼히 쌓아야만 가능하다는 것이다.

IBM Almaden 연구소에서 데이터마이닝 연구
박사학위를 받은 뒤에는 우리 나라의 경제기획원에 해당하는 미국의 Federal Reserve Board의 리서치 부문에서 약 1년간 연구했다. 그때 놀란 것은, 그들이 전세계 수많은 나라의 경제에 관련된 데이터를 계속 모으고 있으며 그것을 이용해 세계 경제의 흐름을 이해하려 하고 또 자국의 이익을 위해 사용한다는 것이었다. 그렇기 때문에 우리 나라에 몇 년전에 발생했던 IMF도 미국이 먼저 알았다는 말이 나온 게 아닐까 생각한다.

내 생각엔 미국의 힘은 그들이 계속 모아오고 있는 수많은 데이터인 것 같다. 지금도 계속 우주에서 보내오는 우주 사진들을 후세를 위해 미국은 계속 그냥 모아놓고 있다.

어떻게 보면 지금 바로 쓸 수도 없는 그 많은 양의 데이터를 계속 수집하고 있는 것이 무슨 소용이 있나라고 의아해하고 있는 사람들도 있을 것이다. 하지만 사실 나중에 그 데이터들을 사용할 수 있는 기술들이 개발될 때를 위해 지금의 데이터를 수집하고 있는 미국의 개척자적인 모습은 역사가 짧을지라도 세계적으로 앞서가는 나라를 만들 수 있었던 저력이라 생각한다.

내가 Federal Reserve Board에서 일하는 동안 소프트웨어분야의 최첨단 연구소 중 하나인 IBM Almaden 리서치 센터의 Rakesh Agrawal 박사가 막 시작하려던 퀘스트 데이터마이닝 프로젝트에 참여를 제안 받았다. 그 당시에는 미국의 여러 기업이 상업용 데이터베이스 소프트웨어를 이용해 자사의 소비자들에 대한 정보를 모두다 컴퓨터에 보관하고 있었다.

하지만 마케팅이나 CRM(Customer Relationship Management) 등에 그 데이터를 어떻게 이용해야 할지 전혀 모르고 있던 시절이었고, 그렇기 때문에 이 데이터에서 유용한 정보를 찾아내려는 데이터마이닝이라는 분야가 처음 태동되는 시기였다.

내가 대학원에서 전공한 분야와 다른 새로운 분야를 시작한다는 것이 조금은 주저가 되었지만 새로운 분야를 개척해보고 싶은 열망과 훌륭한 연구소 중 하나인 IBM Almaden 리서치 센터에서 일하고 싶어 흔쾌히 제안을 받아들였다. 그 후로 1994년부터 1996년까지 Rakesh Agrawal 박사와 열심히 데이터마이닝 분야에 대해 연구했다.

내가 그때 연구하고 코딩한 것들 중에는 IBM에서 상용화해 현재 팔고 있는 데이터마이닝 소프트웨어인 IBM Intelligent Miner의 주요 엔진의 일부로 현재 많은 사람들이 사용하고 있다.

그곳에서 본 프로그래머의 모습
나는 이 프로젝트의 초기에 참가해 최첨단의 새로운 분야의 연구를 주도하는 자세와 방법, 그리고 실제 상업용 시스템 소프트웨어를 개발하는 값진 경험을 습득할 수 있었다. 우선 이들은 계속 공부한다는 점이다.

가까운 대학에 나가 계속 새로운 지식을 배우고, 또 자기가 참여하고 있는 프로젝트에 관련된 유명한 사람들을 불러 계속 세미나를 듣고 또 회사에서 그러한 일에 투자하는 것을 아깝게 여기지 않았다. 왜냐하면 나중에 그들이 프로그래밍을 프로젝트를 위해 일할 때에 다 쓰일 것이기 때문이다. 또한 그들은 누구나 코딩을 잘한다.

한국에 돌아와 국내 연구소에서 일하는 사람들로부터 종종 듣는 얘기가 있다. "나는 코딩 같은 것은 안한다"고. 우리 나라 연구소에서는 코딩을 하면 마치 수준이 낮은 것처럼 평가받는 듯하다.

하지만 세계적으로 유명한 소프트웨어 회사의 명망 있는 연구원들은 누구나 코딩을 잘 한다. 코딩을 하지 않으면 실제 소프트웨어를 디자인할 때 병목현상이 어디서 발생하는지, 실제 소프트웨어가 돌아가는 데 있어 어떤 것을 해결해야 하는지를 잘 알 수 없다. 그렇기 때문에 좋은 논문을 쓸 수 없고 소프트웨어를 만든 후에 생각지도 못한 일들이 생겨 수년동안 애써 일한 것이 모두 수포로 돌아가는 경우가 많다.

IBM이나 마이크로소프트를 비롯한 소프트웨어 회사 연구소의 연구원들은 프로그래밍에 있어서도 세계 최고 수준이다. 또한 디버깅을 위해 사용할 수 있는 여러 가지 툴을 아주 적절히 사용할 수 있는 능력을 갖추고 있어, 빠른 시간 안에 프로그래밍을 할 수 있는 능력을 갖고 있다.

세상 사람들에게 널리 유용하리라고 생각하고 연구해 개발하고 디자인한 알고리즘들을 회사에서 상용화하도록 밀고 나가려면 우선, 프로토 타입도 스스로 만들어 데모도 하고 그 가능성을 또한 보여줘야하기 때문이다. 그렇기 때문에 나는 교수이지만 아직도 많은 경우에 스스로 코딩을 할 때가 많다. 그리고 코딩을 직접 할 때마다 대학생 시절 프로그래밍에 빠져들었던 때의 열정을 다시 조금이나마 경험하곤 한다.

벨 연구소에서 Serendip 데이터마이닝 프로젝트를 시작
나는 IBM Almaden 연구소에서 경력을 쌓고 있는 동안 전산 분야의 세계적인 연구소인 벨(Bell) 연구소로부터 데이터마이닝 프로젝트를 새로 시작해보지 않겠냐는 제안을 받았다. 벨 연구소는 수많은 노벨상 수상자를 배출한 곳으로서, 현재 모든 전자제품의 반도체에 사용되는 트랜지스터를 최초로 개발한 곳이다. 또한 지금 보편화돼 사용하고 있는 레이저를 개발한 아주 명성 높은 연구소다.

IBM에서 Rakesh Agrawal이라는 대가의 지도를 받으며 연구하는 것도 좋았지만, 언젠가는 내 스스로 큰 프로젝트를 주도해 수행하려면 경험을 쌓아야 하므로 그 제안을 흔쾌히 받아들였다. 그리하여 1996년 3월 Bell 연구소로 옮겨, 그곳에서 Serendip 데이터마이닝 프로젝트를 Rajeev Rastogi 박사와 함께 시작해 많은 공동연구를 했다.

옛날에 페르시아에 'Serendip'이라는 조그만 나라가 있었는데 그 나라의 왕자들은 어디를 가든지 생각지도 않았던 아주 소중하고 값진 것들을 발견하는 재주가 있었다고 한다. 여기서 유래된 Serendip이라는 단어는 Serendipity의 어원으로써 '생각하지도 않았던 값진 것을 우연히 찾는 것'을 뜻한다. 그렇기 때문에 내가 Bell 연구소에서 시작한 데이터마이닝 연구의 프로젝트 이름으로 이 단어를 사용했다.

약 4년 동안, 나는 KAIST에 조교수로 부임하기까지 다수의 논문을 명성있는 국제 학술회의에 발표했으며, 또한 국제 저널에 다수의 논문을 게재했다. 나는 이 프로젝트의 리더로서 연구를 성공적으로 수행함으로써 데이터마이닝 분야에서 나의 공헌을 인정받는 계기를 얻었다. 이 프로젝트에서 개발된 수많은 연구는 현재 미국 특허를 이미 받았거나 신청 중에 있다.

나는 또 벨 연구소에 있는 동안 매년 섬머 인턴으로 미국의 대학에서 여러 학생들을 받아 지도해 내 분야의 최고 국제 학술회의에 논문을 실을 수 있도록 했다. 돌이켜 보면 나는 벨 연구소의 경험을 통해 새로운 최첨단 분야의 프로젝트를 스스로 제안하고 개척해 리더로서 성공하도록 수행하는 방법을 터득했다.

우리 나라에 돌아와서
미국에서 성공적으로 해당 분야에서 명성을 쌓고 있는 동안에 항상 마음 한구석에는 내가 40대가 되기 전에 적어도 몇 년만이라도 나의 조국을 위해 일해야 한다는 생각에 종종 잠기곤 했다. 하지만 그 결정이 쉽지는 않았다. 왜냐하면 프로그래머에게 환경이 아주 잘 정착돼 있는 미국에서 일하는 것이 너무나 효율적이고 편하기 때문이다.

하지만 언젠가 '이집트의 왕자'라는 디즈니의 만화영화를 영화관에 가서 아이들과 함께 보다가 이집트에서 최고의 교육을 받고 이집트의 왕자가 됐지만, 자기 민족을 위해 이집트 왕자로서의 모든 부귀와 영화를 버리고 과감히 이집트를 떠난 그의 마음을 이해할 수 있었다. 그 이후로 국내에 돌아오기로 결정하고 KAIST에 부임했다.

KAIST에서 강의하는 일과 함께 전자상거래와 인터넷 검색 엔진, 그리고 인터넷 보안에 관련된 연구도 데이터마이닝과 함께 열심히 연구하고 있다. 특히 전자상거래와 인터넷에서 차세대에 주로 사용될 예정인 XML 형태의 효율적인 처리에 관해 미국 마이크로소프트 연구소와 공동으로 연구를 활발히 진행하고 있고, 또 벨 연구소와도 계속 데이터마이닝에 관해 연구하고 있다. 지난 겨울에도 미국의 시에틀에 위치한 마이크로소프트 연구소에 방문 과학자로 초대돼, 마이크로소프트의 XML 관련 인터넷 소프트웨어의 효율성을 위해 열심히 연구했다.

간단히 논문 한편 쓰는 것과 실제 사람들에게 사용될 수 있는 완벽한 소프트웨어를 만들기 위하여 연구하는 것은 큰 차이가 있다. 실제 소프트웨어를 코딩하기 전에 아무런 문제가 없다는 것을 완벽하게 증명해야 하고 이것저것 고려할 것도 많기 때문이다.

그렇기 때문에 더욱더 어렵고 힘든 일이지만 또 그렇기 때문에 가치 있는 일이라 생각한다.

세계 소프트웨어 시장으로 진출하기 위해
우리 나라에 돌아온 뒤에는 국내 산업에도 기여하고 싶어 와이즈엔진(www.wisengine,com), 엠브레인(www.embrain.co.kr), 그리고 에어마인(www.airminesoft,com) 등의 국내 벤처 회사들에 데이터마이닝과 인터넷 관련 소프트웨어 기술에 대한 자문을 해주고 있다. 우리 나라도 미국처럼 한 사람이 수천 명을 먹여살릴 수 있는 그런 소프트웨어 회사들이 나올 수 있기를 기대한다. 그러기 위해 강조하고 싶은 것이 있다면 우리도 우리 기술을 가져야 한다는 것이다.

또한 나는 교육의 중요성도 새로이 인식하고 학생들의 전산학과목도 열심히 성심을 다해 강의하려 한다. 특히 학생들을 세계적인 수준으로 만들기 위해서는 영어의 필요성을 너무나 깊이 인식하고 있고 또 국제화시키기 위한 일환으로 KAIST에서 내가 강의하고 있는 모든 과목을 영어로만 진행하며, 시험이나, 숙제, 그리고 프로젝트 모두 영어로 내주고 있다. 영어 역시 훌륭한 프로그래머가 되기 위해 갖춰야할 것 중 하나라고 강조하고 싶다.

전산학 분야에서 앞서가고 있는 선진국을 따라 잡으려면 영어를 잘해서 그들이 만들어 놓은 논문이나 책을 빨리 이해하고 우리 것으로 만들 수 있어야 하기 때문이다.

또한 우리가 어떤 소프트웨어를 만들든지 작은 국내 시장에서 안주하지 말고 세계 시장으로 나가야 할 것이다. 그러기 위해서는 영어가 아주 중요한 역할을 한다고 생각한다.

우리는 그들에게서 무엇을 배워야 하나
전산학 분야는 노벨상이 없지만 그 대신 튜링상(Turing Award)이라는 것이 있다. 내가 말하고 싶은 건 이 상을 받았던 역대 수상자들은 논문 개수로 받은 것이 아니라 별로 많지 않은 논문일지라도 그 연구 결과가 이 세상에 끼친 영향이 너무나 크기 때문에 받았다는 사실이다. 국내 최고니 아시아에서 최고니 그런 건 별 의미가 없다. 세계 최고의 기술력을 확보할 수 없다면 경쟁력을 갖출 수 없기 때문이다.

현재 내가 몸담고 있는 KAIST뿐만 아니라 국내의 다른 대학들도 세계적인 대학으로 발돋음할 수 있기를 진정 바라고 있다. 그러기 위해서는 교수와 학생에 대한 대우나 평가도 세계적인 명문대학 수준으로 해줘야 한다고 생각한다.

그러지 않고 어떻게 세계적인 수준으로 우리들이 갈 수 있겠는가. 또 그렇게 되지 않고 어떻게 선진국의 소프트웨어 회사들과 경쟁할 수 있겠는가. 같은 환경이라도 우리는 뒤늦게 출발해 더 어려운 상황이니 말이다.

지금 많은 학생이 유학을 떠나고 있고, 또 많은 학생들이 학부나 석사과정만 마치고 더 이상 박사학위에 지원하지 않고 있다. 그렇기 때문에 국내 대학에서 일하는 나와 같은 교수들은 같이 연구할 학생들이 없어 더욱 어려움에 처하고 있다.

하지만 어쩌면 국내 대학이 학생들에 대한 자세를 선진국의 명문 대학처럼 바꾸려고 노력할 수 있는 계기가 될 수 있을 것 같아 한편으로는 기쁘다. 왜냐하면 대학의 주인은 교수나 교직원이 아니라 바로 학생들이기 때문이다. 우리 나라의 대학들이 이것을 인식하지 못하고 구태의연하게 있는 동안 학생들이 점점 빠져나갔기 때문이다.

나는 또한 공부를 중단하고 벤처 회사로 나가는 학생들에게 한 가지 당부하고 싶은 게 있다. 선진국의 소프트웨어의 벤처 회사에서 일하는 많은 이들은 전산학 공부를 대학원 과정을 통해 열심히 훈련을 받은 후에 자기만의 기술을 독자적으로 개발했기 때문에 가능한 것이지, 탄탄한 기초와 자기만의 기술이 없이 그냥 아무렇게나 시작한 것이 아니라는 것이다.

또한 자신이 개발한 소프트웨어는 모두 특허를 신청해 자사의 지적 재산권을 보호하고 있다. 이러한 것들을 우리 나라의 프로그래머들도 배워야하지 않을까.


하나에만 몰두하는 바보가 되라
내가 미국에서 공부하면서, 그리고 미국의 많은 소프트웨어 회사의 연구소에서 일하면서 느낀 점은 미국의 학생들은 정말로 전공하는 학문을 좋아하기 때문에 대학에 오고 또 대학원에 진학한다는 사실이다. 그렇기 때문에 정말로 열심히 열정적으로 한 가지만 공부하고 연구한다. 영화 '포레스트 검프'에 나오는 주인공처럼 한 가지만 몰두해서 바보처럼 일할 때 우리는 그 분야의 전문가가 될 수 있다. 또 그렇게 할 때 정말 뭔가를 이뤄낼 수 있다는 생각이 든다.

만일 어떻게 하면 성공한 프로그래머가 될 수 있냐고 나에게 묻는다면 난 이렇게 말하고 싶다. 정말로 프로그래밍이 미칠 정도로 좋으냐고. 컴퓨터만 보면 미친 사람처럼 좋은지, 프로그래밍을 하면 정말로 즐거운지 묻고 싶다. 만일 여러분이 그렇다면 프로그래머로서 성공할 수 있는 가능성을 충분히 갖췄다고 생각한다. 그 다음은 앞서 말한 기본적인 기초 과목을 공부해 기반을 튼튼히 다져서 어떤 것을 코딩하든지 완벽하게 하려는 열정을 갖도록 하라. 그리고 나이에 상관하지 말고 계속 공부하라.

미국의 대학에 있다보면 30대에서 60대까지 다양한 연령층이 대학에 와서 대학생들과 함께 전산학 강의를 듣는 것을 볼 수 있다. 그렇게 계속 공부하지 않으면 프로그래밍에 관해서 새로 개발된 좋은 언어나 알고리즘을 이용할 수 없어 코딩한 프로그램이 비효율적일 가능성이 높다. 전산학 자체가 물리나 화학과 같은 분야처럼 고전적인 학문이 아니고 지금도 계속 새로운 내용들이 아주 빠르게 개발되고 변화하는 분야이기 때문에 계속 공부를 해야 한다는 사실을 강조하고 싶다.

또한 팀웍의 중요성을 말하고 싶다. 하나의 프로젝트를 수행하려면 여러 사람이 한 팀을 이뤄서 서로 다른 부분을 프로그래밍해야 한다. 그러려면 그 프로젝트를 성공시키겠다는 목표를 향해 자신을 희생할 줄도 알아야 한다. 안되면 밤을 새워서라도 반드시 계획대로 만들어 내려는 그런 의지를 갖고 서로 협조해 일하는 자세가 필요하다.

미국의 훌륭한 소프트웨어 회사에서 일하는 사람들에게서 느낄 수 있었던 것 중의 하나가 바로 이점이었다. 또 소프트웨어 분야 선진국의 발전된 모습이 필요할 때면 언제든지 이해하고 우리에게 적용할 수 있도록 영어를 잘하도록 갖추라고 말하고 싶다.

그래야 세계 시장에서 팔릴 수 있는 소프트웨어를 만들어 우리 나라 산업의 발전에 기여할 수 있기 때문이다. 앞서 언급한 사실들을 명심하고 준비한다면 반드시 훌륭한 프로그래머로 성공할 수 있으리라 생각한다.

컴퓨터가 좋아서, 프로그래밍이 좋아서
이 글을 맺으면서 하고 싶은 말이 있다면, 'Life is full of Serendipity'라는 말이다. 우리글로 표현한다면 '인생이란, 아주 먼 옛날에 신이 나를 위해 미리 준비해놓은 소중하고 값진 것들을 하나씩 찾아가는 기쁨'이라는 의미로, 내가 만들어낸 말이다. 이 말은 짧은 인생이지만 그동안 살아오면서 인생에 대해 내가 느낀 것을 아주 함축적으로 잘 나타내 주는 말이다. Serendipity라는 단어를 나는 무척 좋아한다.

앞서 얘기했듯이, 벨 연구소에서 수행한 데이터마이닝 프로젝트의 이름으로 사용한 Serendip이라는 어원에서 나온 단어이기도 해서 그런지도 모르겠다.

마소에 처음 기사를 썼던 1985년에는, 그 후로부터 지금까지 내가 살아온 경험들을 전혀 상상하지 못했다. 단지 컴퓨터가 좋아서 프로그래밍을 배웠고, 또 프로그래밍이 좋아서 전산학을 공부했다.

또 좀더 모험을 하고 싶어 유학을 갔으며, 데이터베이스 한 분야에 머물러 있기 보다는 새로운 분야를 개척해보고 싶어서 데이터마이닝 분야에 프론티어로 달려들었다. 중요한 것은 내가 좋아서 한 것이기 때문에 좋은 연구 결과도 낼 수 있었고 또 그렇기 때문에 미국 대학에서 사용되는 데이터베이스나 데이터마이닝 교재에 내가 한 연구나 논문이 많이 인용될 수 있었던 것 같다.

새로운 분야가 끝없이 펼쳐진 길 위에 서서
가만히 생각해보면 나 자신이 축복을 참 많이 받았다고 생각한다. 내가 좋아하는 것을 그래도 평생 할 수 있으니까. 그게 가능했던 건 현재에 머무르지 않고 내가 좋아하는 것을 찾아 항상 도전하는 자세를 갖고 있었기 때문이라 생각한다. 그렇기 때문에 훌륭한 프로그래머가 되기 위해 준비하는 이들에게 이 말을 해주고 싶은 것이다. "도전하는 자세로 삶을 살아가라".

다시 말해 어려운 프로젝트를 해야 할 기회가 생겼을 때 겁먹고 주저하지 말고 달려들어 경험해 보라고. 훌륭한 프로그래머가 되려면 많은 훈련을 통해 담금질 돼야하기 때문이다. 그렇게 하지 않고는 될 수 없다. 또 그렇게 인생을 살지 않으면 아주 먼 옛 날에 이미 당신을 계획한 조물주가 당신을 위해 준비하고 감추어 놓은 소중하고 값진 것들을 경험할 수 없으니까….

돌이켜 보면 지나온 내 인생의 나날들 하나하나가 모두 나에겐 소중한 추억이고 어느 것 하나 버릴 것이 없다. 물론 힘든 일도 참 많았지만, 그 모든 일이 지금처럼 성숙하고 원숙한 30대의 나를 만든 게 아닌가 생각한다. 난 지금도 앞으로 나에게 다가올 것들에 대한 기대로 가슴이 너무 설레고 벅차다. 앞으로 10년 후에는 과연 어떤 모습의 나로 변해 있을까. 또 나에게는 어떤 새로운 만남이나 경험이 준비돼 있는 걸까. '캐스트 어웨이'라는 영화의 마지막 장면에서 끝이 보이지는 않는 여러 갈래의 길을 바라보았던 Chuck Noland의 맘이 이랬을까. @

출처 http://blog.naver.com/kdw1109mania/110013547809

Posted by SB패밀리

그린컴퓨터 최중구님의 글입니다. http://greenpc.co.kr/programmer.htm
-----------------------------------------------------------------
프로그래머의 글
1) 글을 시작하면서

오늘 이 글을 통해 혼란한 국내 소프트웨어 개발(프로그래머) 직종을 이해할 수 있는 설명을 하고자 합니다. 더 나아가 프로그래머라는 직종을 이해하는 것을 시작으로 프로그래머의 길을 걷고자 하시는 많은 분들이 밟아 올라가야할 방향을 제시할 수 있기를 바라는 마음에서 이 글을 적어봅니다.

2) 프로그래머에 대한 아마추어적인 발상

최근들어 인터넷이 사회적인 이슈로 떠오르면서 자연히 소프트웨어 개발에 대한 관심이 증대되고, 자연히 프로그래머라는 직업을 갖고싶어 하는 사람들이 늘고 있습니다. 하지만 소프트웨어 개발에 대한 잘못된 시각때문에 전문 직종으로 분류되어야할 프로그래머가 일반 직종으로 분류되고 있는 기현상을 보이고 있는 점은 프로그래머가 되고자 노력하고 있는 한 사람으로서 가장 걱정되는 부분입니다.

프로그래머라는 직업을 의사라는 직종을 예로들어 비교를 해본다면, 의사가 되기 위해서는 의대의 정규과정을 이수한 후 국가공인 자격시험을 통해 인턴/레지던트/전문의 순서를 밟아야 합니다. 이 처럼 의사라는 직종은 분야도 확실하게 나뉘어져 있을뿐만 아니라 의사로서의 자질을 평가하는 제도적인 체계가 정확하게 잡혀있습니다. 하지만, 프로그래머라는 직종은 그렇지 못합니다. 전산과를 나온다고해서 프로그래머가 되는 것도 아니고, 대학을 나오지 않았다고 해서 프로그래머가 되지말라는 법도 없습니다. 정보처리 관련 국가공인 자격증을 갖고있다고 해서 프로그래머가 되는 것은 더더욱 아니고 분야 또한 정확하게 구분할 수 없는 것이 프로그래머라는 직종입니다.

이처럼 프로그래머에 관한 정확한 정의가 내려지지 못하고 있는 상황에서 사회적 분위기는 소프트웨어 인력시장에 있어 큰 혼란을 초래하고 있는 것이 사실입니다. 때문에 프로그램 공부를 시작하려는 많은 사람들에게 혼란을 주고 있는 것이라 생각되는군요. 분야와 개인의 노력여부에 따라 틀리겠지만, 단순히 학원에서 몇 개월 과정을 이수한 것이나 프로그램 몇가지를 개발해본 경력으로 자신을 프로그래머라 칭하고 또 인정하는 사회적인 분위기에는 문제가 있습니다. 저도 올해로 프로그램을 시작한지 15년째고 실무경력은 15년 이지만, 지금도 저 자신을 프로그래머라 부르기에는 부끄러운 점이 많습니다. 사실 프로그래머라는 직종은 전문직에 속하는 것입니다. 의사보다는 훨씬 못하겠지만 그에 못지 않게 오랜 기간동안 공부하고 경험을 쌓아야만 비로소 프로그래머가 될 수 있는 것인데, 프로그래머라는 직종을 보는 일반적인 시각은 너무 쉽게 생각하는 경향이 있지 않는가 하는 생각이 들 때가 많습니다.

3) 풍요속의 빈곤

이러한 잘못된 사회적 통념이 굳어져 가고 있는 우리나라의 프로그래머 인력시장의 구조를 살펴보면 그 문제점을 가장 단적으로 알 수 있습니다. 우리나라 소프트 업계의 인력시장의 구조는 초보자로 부터 시작해 고급자로 균형이 있게 올라가는 정상 피라미드와는 많은 차이가 있습니다. 초급에 해당하는 아래부분은 비정상적 포화상태를 띠고있는 반면에 중급자 및 고급자들은 거의 찾아보기 힘든 구조를 나타내고 있습니다.

이러한 현상은 프로그래머라는 직종에 단순한 흥미와 사회적 분위기에 휩쓸려 뛰어드는 사람들은 많지만, 체계적인 교육과 평가 방법의 부재 및 영세한 국내 소트웨어 업계의 투자부족으로 인하여 중급이상으로 발전하는 프로그래머 지망생이 없기 때문에 나타나는 현상으로 볼 수 있습니다.

이와는 별도로 외국기술과 객관적으로 비교해 봤을때 훨씬 뒤진 기술조차 공유하는 것을 꺼려하고 있다는 점 또한 국내 소프트웨어 업계의 발전을 저해하는 요소로 지적할 수 있습니다. 하루가 다르게 변모하고 있는 세계적인 소프트웨어 업계와 경쟁하려는 생각은 하지 않고 오히려 지금 갖고 있는 지금까지 해왔던 일들만 편하게 하려는 안일한 생각들은 물론이고 그 보잘것 없는 기술을 통해 기득권을 유지하려는 잘못된 생각이 가장 큰 문제점이라 할 수 있습니다.

이러한 비정상적 인력시장 구조 속에서 정말 필요로 하는 프로그래머를 찾기란 하늘의 별따기와도 같으리라는 점은 누가 봐도 자명한 사실입니다. 풍요속의 빈곤이라는 용어가 어울릴정도로 프로그래머로 일하려는 사람은 많은 반면 정말 실력있는 프로그래머는 손에 꼽는 현상이 나타나는 것입니다.

4) 프로그래머가 갖추어야할 자질

프로그래머가 되기 위해 갖추어야할 자질에는 여러가지가 있습니다. 그 모두가 천재적인 재능을 필요로 한다기 보다는 끊임없는 노력을 통해 얻어질 수 있는 것이라 할 수 있는 것들입니다.

첫째, 집요하고 꼼꼼해야 합니다.

프로그래머의 직업병이라고도 할 수 있는 집요함이 있어야 합니다. 문제점을 찾아내고 해결하기 위해서 집요하게 들러 붙어 있을 수 있는 근성이 필요합니다. 차분하고 꼼꼼하면서 끈질긴 성격을 가진 분들은 어디가나 성공하시겠지만 프로그래머에게는 필수조건이라고 할 수 있습니다. 차분한 성격은 타고나는 것도 있겠지만 훈련을 통해 개발될 수도 있는 것입니다. 예를 들면, 마인스위퍼를 한다던가~ ^^퍼즐등을 통해서 키워질 수 있겠죠.

둘째, 논리력이 뛰어나야 합니다.

프로그램의 거의 대부분을 차지하는 것은 조건판단, 분기, Loop문을 작성하는 것입니다. 논리력이 없이는 할 수 없는 일들입니다. 일반적으로 남성에 비해 여성이 논리력이 뒤진다는 속설이 있어서 그런지는 모르지만 이 점 때문에 여성 프로그래머가 많지 않다고들 합니다. 집요하면서도 꼼꼼하게 논리를 구축해야 Bug 없는 프로그램을 작성할 수 있다고 봐도 과언이 아닙니다. 논리력 또한 훈련을 통해서 개발될 수 있는 것이죠. 역시 마인스위퍼를 한다던가~ ^^ 논리학등을 공부하고 일상생활에서 논리적인 사고를 하기위해 노력을 함으로써 개발할 수 있겠죠. 전 세가지 다 했습니다.

셋째, 세상을 보는 관찰력과 추상력이 뛰어나야 합니다.

프로그램은 추상화를 기본으로 하고 있습니다. 실세계를 축소해 놓은 것이 프로그램이라고 말해도 과언이 아닐 정도록 현실과 밀접한 관계를 갖고 있는 것이 프로그램입니다. 때문에 관찰력과 추상력이 필요합니다. 실세계의 특징을 찾아내고 단순화 하고 추상화하는 과정은 프로그램의 설계부분에 들어가기 때문에 전체적인 성능을 좌우하는 중요한 요소로 작용하기 때문입니다. 관찰력과 추상력은 경험을 통해서 개발될 수 있을 겁니다. 꼼꼼한 성격도 한몫을 할 수 있겠죠.

이러한 기본 자질들은 상호보완적인 관계속에서 프로그래머의 능력 개발에 도움을 줄 수 있는 것들입니다. 이러한 자질만을 갖고 있다고 해서 프로그래머가 될 수 있는 것은 아닙니다. 기본적인 전산이론은 물론 기타 관련 이론에 대한 공부가 필수적입니다.


첫째, 전산개론

일종의 상식공부라고 할 수 있습니다. 전산의 변천사는 물론 전산의 폭넓은 분야를 아는 것이 지금의 자신의 위치를 알 수 있는 가장 중요한 방법이 되기 때문입니다.

둘째, Hardware의 구조 및 동작원리

프로그래머는 Hardware는 몰라도 된다는 식의 발상은 정확하게 틀린 말입니다.Software는 Hardware상에서 구동되는 것이기 때문에 Hardware의 구조가 어떻고 어떤 원리와 절차에 의해서 구동되는지에 관한 특성을 알지 못하면 Hardware에 맞는 최적화된 Program을 개발할 수 없기 때문입니다. Pentium 계열의 CPU 에서 Pipeline Optimize의 개념을 알지 못한다면 Speed 최적화를 할 수 없는 것과 마찬가지입니다. 고급 프로그래머가 되기 위해서는 결코 등한시 해서는 안되는 점임을 잊지 마시기 바랍니다.

셋째, OS 이론

모든 프로그램은 OS 환경가 제공하는 환경에서 구동되도록 되어 있습니다. HW와의 복잡한 일들을 모두 맞아서 처리해주는 것은 물론 기타 유용한 Service를 제공해주는 OS를 몰라서는 그 OS에서 구동되는 프로그램을 개발할 수가 없습니다. 보다 넓은 시야를 갖고 전체적인 그림을 그리기 위해서는 OS를 어떻게 만들 것인가에 관한 이론들을 아는 것이 중요합니다. OS도 만드는데 다른 프로그램을 왜 못 만들겠습니까?

넷째, 자료구조/알고리즘 이론

프로그램의 꽃이라 할 수 있는 기본 이론들입니다. 프로그램에서 가장 중요한 부분인 자료의 저장과 처리에 관한 방법론들을 정리해 놓은 이론들로서 반드시 거쳐야하는 난코스라고도 할 수 있습니다. 자료구조/알고리즘을 모른다면 단순 Coder도 못된다는 결론이 날정도로 프로그래머가 되기위한 가장 기본적인 조건입니다.

다섯째, 전산언어론

C/Pascal/Fortran 등의 언어가 없을때는 어떻게 프로그램을 했을까? 라는 질문에 대한 답을 던져줄 수 있는 이론들입니다. Assembler로 부터 4GL까지의 발전사를 알 수 있을 뿐 아니라 C/C++와 같은 언어를 어떻게 만들 것인가를 정리하는 이론들입니다. Compiler 를 어떻게 만들 것인가에 대해 고민해보신적 있습니까? Compiler를 만든다면 그 Compiler가 번역하는 언어는 자유자제를 넘어 신의 경지에 오를 수 있지 않겠습니까?

여섯째, 개발방법론

전산언어론과는 또 다른 개념의 이론들을 모아놓은 것으로써 소프트웨어를 생산에 공학개념을 도입하고자 하는 이론들입니다. 체계화된 방법론을 통해 소프트웨어 개발의 생산성을 높이고자 하는 목적을 갖는 이론들입니다. 생산성을 생각하지 못한다면 경쟁력을 갖지 못하는 것은 당연한 것 아니겠습니까?

일곱째, 전산언어

C/C++과 같은 언어의 문법을 배우는 단계입니다. 가장 처음 프로그래머가 되겠다고 마음 먹은 사람들이 가장 많이 만나는 첫번째 적수이지요. 하지만 전체적인 그림속에서 전산언어가 차지하는 비중은 제일 마지막에 속하고 있다는 점을 유념하시기 바랍니다. 어떤 언어를 사용하는가는 중요하지 않다는 점입니다. 언어는 도구일 뿐이지 목적이 아니라는 점을 다시한번 강조하고 싶군요.

위에 나열된 주제들은 대부분의 전산과 교과목에 포함되어 있는 내용들입니다. 모두 한학기 분량이지만 결코 한학기 안에 끝낼 수 있는 내용들이 아닙니다. 1년 동안 세가지를 끝낸다고 해도 2년이 넘는 시간이 필요하다는 단순계산이 나옵니다. 결코 만만한 일은 아니죠.

여덟째, 실무경험

위의 조건들을 갖춘 대부분의 사람들은 일반적으로 실무경험이 부존한 것이 현실입니다. 단순히 이론적인 것으로만 접근해서는 좋은 프로그램이 나올 수 없습니다. 프로그램의 최종 사용자는 고객입니다. 고객의 입장에서 만들어야 가장 좋은 프로그램이 될 수 있습니다. 고객이 되어 본 사람은 좋은 프로그램을 만들 수 있습니다. 왜냐하면 고객은 그 업무를 가장 잘 알기 때문입니다.

5) 기본위에 쌓여진 경험

2년 안에 위에서 나열한 기본들을 모두 마스터 한다고 해도 Coder로 인정받기란 쉬운 일이 아닙니다. 원론을 그대로 적용해 해결할 수 있는 문제는 하나도 없다는 것은 너무나도 당연한 사실입니다. 책 속의 이론이 내안의 경험으로 쌓일때 비로소 내것이 될 수 있는 것입니다.

지금의 저 또한 그 기본위에 경험을 쌓기 위해 노력중인 사람이라고 말씀드리고 싶습니다. 항상 따라가도 먼저 뛴 사람들은 저만큼 앞서 가고 있다는 걸 느낄때마다 프로그래머라는 직업이 얼마나 피곤한 직업인가를 새삼 깨닫고 있으니까 말입니다.

6) 글을 맺으며... 세상 밖으로...

장황하게 나마 프로그래머라는 직종에 대해 설명을 해보았습니다. 글을 읽다 짜증이나시지나 않았나 모르겠군요. 하지만 이것이 지금의 제가 보고 있는 국내 업계의 현실입니다. 물론 상황에 따라 부분적으로 틀릴 수도 있겠지만 큰틀에서 본다면 제 글에서 벗어나는 것이 없습니다.

그 것은 바로 얼마전까지 워드프로세서를 만들던 한 소프트웨어 업체가 국내 소프트웨어 업계를 대표했었다는 사실만 봐도 알 수 있습니다. 그 폐단은 지금에 와서 더더욱 커지고 있죠. 외국과의 자료교환이 불가능 하다는 결정적인 문제점을 남겨놓고 무책임하게도 사라져버리지 않았습니까? 한국의 빌게이츠라는 말이 창피할 정도로 몰락하고만 기업에서 한동안 일을 했던 경험이 이렇게 더 큰 분노를 만들고 있습니다.

기본을 무시하고 사상누각을 쌓았던 한국병이 이 소프트웨어 업계에도 어김없이 자리잡고 있다는 것을 왜 아무도 지적하지 않는지 모르겠습니다. 밴쳐라는 이름아래 개혁의 면죄부를 받고 있는 기업들이 지금도 많다는 것에 안타까울 뿐입니다.

눈을 한번 돌려보시죠. 어느 나라가 워드프로세서 업체를 자국의 소프트웨어 대표기업이라고 떠들어대는지를...

우리는 아직 멀었습니다
Posted by SB패밀리

프로그래머, 개발자, 엔지니어, 코더, 아키텍트, 디자이너, 예술가… 전산학과, 컴퓨터 공학과, 6개월 마스터 과정 학원 교습까지… 과연 개발자의 세계는 어디까지일까. 개발자의 세계를 설명하는 수많은 용어의 홍수 속에, 지금의 시점에서 개발자로서 자신이 가야할 길이 어디인지 고민하는 이들을 위한 길잡이를 제시하고자 한다.

 

신승근 (데브 CEO 겸 수석 컨설턴트 )
   2001년 4월호

 

  "아무도 걸어가지 않은 길을 걷는다는 것은 쉬운 일은 아니지만, 가치있는 일입니다. 누군가가 내 뒤를 따라오기 때문입니다."
  개발자에 대해 나온 책들이 몇 권 있지만, 언어를 가르치거나 형식적인 면에 그치는 경우가 많아서 이번 기회에 개발자에 대한 글을 써보기로 했다. 개발자에 대한 분석이나 자료들이 거의 없어 자료를 찾는 일과 명상에 많은 시간을 투자했음을 밝힌다.
  모두가 잠든 새벽, 키보드 자판을 두드리는 한 명의 남자, 옆에는 식은 커피잔과 어질러진 서류들, 부시시한 머리에 이글거리는 눈동자. 나라를 위협하는 전자 장비나, 바이러스 소프트웨어를 몇 시간만에 만들기도 하고, CD롬에 저장된 정보를 몇 분만에 분석해 스파이를 찾아내고….
  앞에 묘사한 것은 영화에 나오는 해커나 소프트웨어 개발자의 모습이다. 실제 개발자의 모습과 비슷한 부분도 있지만, 사실과는 동떨어진 묘사도 있다. 그렇다면 실제 개발자의 모습은 어떤 것일까.
  개발자를 알기 전에 개발자가 만드는 소프트웨어(프로그램)에 대해 먼저 살펴봐야 한다. 소프트웨어를 모른다면 개발자도 알 수 없기 때문이다. 우선 프로그램이라는 단어에 대해 알아보자. 신문을 펼치면 'TV 프로그램 안내'를 쉽게 찾을 수 있다. TV 프로그램 안내는 TV 순서 안내와 같다. 즉 프로그램이란 '순서'를 뜻한다. 그러나 이 설명만으로는 뭔가 부족한 듯하다. 좀더 자세히 알아보자.
  소프트웨어를 알면 개발자가 보인다 우리는 연극의 3요소, 희곡의 3요소 등을 학교에서 배웠다. 소프트웨어를 알기 위해서는 그런 요소들을 살펴보는 것이 제일 빠른 방법이 아닐까. 소프트웨어(프로그램)의 3요소는 무엇일까. '소프트웨어의 3요소'란 정의는 없지만, 대신에 70년 이후 프로그램에 대한 묘사(?)를 정리하면서 끌어낼 수 있다.
  대부분의 소프트웨어 공학 책에 나와있는 프로그램의 원론적인 정의는 <그림 1>과 같다. 입력을 받고 처리해 결과를 내놓은 것이 프로그램이라는 표현은 명확하지만, 이 정의는 프로그램의 요소 중에서 프로세스(처리)만 강조를 하고 있는 정의라 할 수 있다. 70년대에 만들어진 프로그램은 대부분 이 정의에 입각해 입력과 출력, 처리에 관한 기술을 하고 있다. 당시의 프로그램들은 업무의 범위도 매우 작았고, 극히 작은 메모리와 매우 느린 CPU에서 실행되므로 이런 정의는 매우 정확했다.
  소프트웨어 공학에서는 프로그램에 대한 다른 의미로 '실세계를 컴퓨터에서 처리하기 위해 모델링(코드화)한 것'이라는 표현(<그림 2>)도 사용한다. 이것은 프로그램이라는 것은 실세계의 투영체에 불과하다는 개념에서 비롯된 것이다. 현재는 소프트웨어가 실세계의 반영를 넘어서고 있으므로 하나의 다른 세상을 보여주고 있다. 따라서 이런 정의는 부분적인 설명에 그치고 있다.
  한편, 파스칼을 설계한 스위스 쮜리히의 공과 대학 교수인 니클라우스 워스(Niklaus wirth)는 그의 저서(Algorithm + Data Structure = Program)에서 프로그램에 대해 다음과 같이 설명했다.


알고리즘 + 자료구조 = 프로그램


 

이런 정의는 70년대 초부터 80년대 말까지는 적절한 설명이었다. 당시 프로그램들은 구조적 설계에 의해 개발되고 있었으므로 구조적 설계에 의해 프로세스와 필요한 데이터 구조를 파악하고 이를 구현하는 것이 하나의 프로그램 개발 방법이었기 때문이다. 그래서 지금까지도 대학에서는 자료구조와 알고리즘을 가르치고 있는 것이다.
  90년대 초에 그래디 부치(Grady Booch)는 객체지향적인 시각에서는 프로그램을 구성하는 객체들의 합이라고 설명했다(Program are organized as cooperative collection of objets; Object Oriented Analysis and Design second edition, Benjamin Cummings Pub, Grady Booch, 1995). 그는 니클라우스 워스의 구조적 사고에서 일보전진한 객체적 사고에서 프로그램을 구성하는 최소 단위를 객체를 선택한 것이다.


데이터 + 메쏘드 = 객체

객체 + 객체 = 프로그램


 

  그렇다면 요즘 소프트웨어 불법 사용 단속이 한창인데, 저작권법 측면에서 보면 프로그램이란 무엇일까. 컴퓨터프로그램보호법 제2조 1항에 의하면 프로그램을 저작물로 인정해 다음과 같이 설명한다.
  '컴퓨터프로그램저작물'이라 함은 특정한 결과를 얻기 위해 컴퓨터 등 정보처리능력을 가진 장치(이하 '컴퓨터'라 한다)내에서 직접 또는 간접으로 사용되는 일련의 지시·명령으로 표현된 창작물을 말한다.
  저작권법에 의해 보호받는 범위까지 고려하면 프로그램 창작물의 범위는 문서까지 확잔된다. 프로그램 그 자체 뿐만 아니라 매뉴얼, 설명서도 프로그램 저작물이 되는 것이다.


알고리즘 + 자료구조 + 문서 = 프로그램

 

  6년 전부터 필자는 다음과 같은 주장을 강력히(?) 펼치고 있다. 앞으로 소프트웨어를 개발함에 있어 외부의 드러나는 사용자 인터페이스와 내부의 프로그래밍 인터페이스가 점차 중요하게 부각될 것이며, 또한 소프트웨어를 개발하는 방법론은 프로그램의 개발에서 가장 중요한 부분을 차지하게 되리라는 이야기다.


알고리즘 + 자료구조 + 인터페이스 + 문서 + 방법론 = 프로그램


 

  이제 소프트웨어가 무엇인지 이해되는가. 지금 살펴본 프로그램의 정의는 입장에 따라서 표현은 다르지만, '어떤 절차에 의해 기술된 코드로서 컴퓨터에서 실행될 수 있는 것'이라는 사실에는 변함이 없다.
그런데 절차라는 것이 프로그래머를 다소 융통성 없는 사람으로 만들어왔다. '절차적으로 매일 작업을 하는데, 삶 자체가 그렇지 않겠어'라는 생각에서, 프로그래머는 일반인으로부터 시간관념이 매우 명확하고 절차적으로 일을 처리하는 매우 답답한 사람으로 인식돼온 게 사실이다.
  앞의 글에서 프로그램과 소프트웨어라는 단어를 혼용해 사용하고 있는데, 프로그램과 소프트웨어의 차이점은 무엇일까. 프로그램은 절차적인 진행만을 강조하는 표현이고, 소프트웨어는 하드웨어의 반대적 입장에서 제품적인 성격을 표현한 것이라 할 수 있다. 그러나 결국은 동일한 것을 가리킨다.
  개발자 명칭에 이렇게 깊은 뜻이 개발자가 누구인지 알았지만, 우리는 개발자라는 직업에 대해 더 살펴볼 필요가 있다. 이를 통해 개발자에게 한 발자국 더 가까이 다가갈 수 있는 것이다. 소프트웨어를 개발하는 직업에 대한 명칭은 크게 코더, 프로그래머, 개발자로 구분을 한다. 각 용어마다 조금씩 차이가 있다. 이 구분은 누군가가 정해놓은 것이 아니라, 개발자의 세계에서 사용되는 경우를 좀더 세밀하게 구분해 본 것이다.


◆ 코더(Coder) : 약간은 개발자를 비하하는 용어이기도 하지만, 이미 정해진 루틴에 따라 프로그램을 입력하는 오퍼레이터로 보면 된다. 외국의 경우 파워빌더와 같은 개발툴을 사용할 때, 업무 컨설턴트가 분석한 내용에 따라서 주부들이 코더로 소프트웨어를 개발한다는 이야기도 들었다.
  아무래도 일정한 패턴을 따르는 분야에서는 인건비가 저렴한 코더를 많이 사용한다고 한다. 소프트웨어 분야의 개발 자동화 시스템의 발달로 난이도 있는 개발을 할 수 있는 프로그래머는 점점 사라지고, 단순한 개발을 맡을 수 있는 코더들이 할 수 있는 일이 늘어날 것이라는 전망도 나오고 있다. 한국에서는 '이 코더 수준 밖에 안되는 놈'이라는 표현에 자주 등장하면서 비하하는 의미로 생각하는 개발자도 있기 때문에 함부로 사용하기 어려운 용어다.

◆ 프로그래머(Programmer) : 개발자라는 명칭을 사용하기 전부터 사용해오던 명칭이다. 이전에는 소프트웨어라는 단어보다는 프로그램이라는 단어가 더 널리 사용됐고, 프로그램(Program)을 만드는 사람이라는 어미(er)가 붙어 프로그래머(Programmer)가 사용됐다. 까마득한 옛날에는 프로그래머의 주요 작업이 순서도를 만드는 것이었다. 따라서 세간에는 자에 잰 듯한 생활로 고리타분한 직업의 대명사이기도 했다.

◆ 개발자(Developer) : 프로그래머보다는 일보 진보된 개념으로서 연구를 해서 제품을 만드는 사람을 의미하는 단어인데, 최근 5년 전부터 많이 사용되기 시작했다. 널리 사용되는 제품을 만들기 위해서는 이전처럼 순서도에 입각한 작업보다 더 많은 지식과 이해가 필요하므로 단순 프로그래머가 아닌, 연구자로서의 자질과 승부근성까지도 필요하게 됐다. 따라서 유명한 소프트웨어 개발자들은 프로그래머 차원이 아닌 제품의 개발자로 표현되고 싶어한다.
  프로그래머와 개발자의 차이를 억지로 구분해본다면, 프로그래머란 이미 주어진 환경 속에서 일부 모듈을 코딩하는 자를 뜻하지만, 개발자란 새로운 것을 창조해낼 수 있는 능력까지도 갖고 있는 자를 의미한다. 일부 회사에서는 프로그래머는 순서도에 입각해 코딩하는 직원으로, 개발자는 새로운 제품을 만드는 직원으로 분류하기도 한다. 이런 분류와 관계없이 프로그래머와 개발자는 혼용해 사용되고 있으나, 실제로는 현재 개발자라는 명칭을 더 선호하는 듯 하다.
  개발자는 어떻게 만들어지는가 '어떻게 해야 개발자가 될 수 있을까요'라는 질문을 많이 받는다. 기고를 많이 하다보니, 어떤 학생들은 임금을 받지 않고 일을 배울테니, 1년간만 함께 있게 해달라는 경우도 있었다. 어떻게 하면 개발자가 될 수 있는지에 대한 궁금증이 많다는 사실에 놀라게 된다.
  대개의 경우, 학원에서 3∼6개월 과정을 마치고, 소규모의 개발회사에서 1∼2년쯤 지내면 충분히 소프트웨어 개발자로 자리잡을 수 있다고 생각을 한다. 그러나 아쉽게도 그런 방법으로 자리잡은 경우에 3∼5년 이내에 개발자보다는 시스템 관리나 다른 분야의 일을 하는 경우를 많이 봤다.
  프로그래밍이란 앞서 말했듯이 논리적인 순서의 나열이며, 데이터를 조작해 사용자가 원하는 처리를 하는 것이다. 10년 전까지만 해도 개발 규모가 매우 작았으나, 1995년을 넘어서면서 그 규모가 엄청나게 커지기 시작했다. 따라서 이제는 개발이란 개인의 단위가 아니라 최소한 팀 단위다.
  규모가 커졌기 때문에 팀 단위 프로젝트의 진행에 있어서나, 다음 버전의 개선을 위해서도 개발자는 거추장스런 방법론을 싫어한다는 것을 알아야 한다. 고객을 위한 품질 관리를 위해서는 최소한 ISO 9000과 ISO 12207이라는 규격 정도는 소프트웨어 개발사에서 인증받아야 한다. 특히 해외에 소프트웨어를 납품하기 위해서는 필수조건이다.
  또한 미국 국방성에 납품하려면 CMM 레벨 3 인증을 받아야 한다. 우리 나라의 업체 대부분이 레벨 1 정도이고 이제 겨우 3개 업체만 CMM 레벨 2를 받았다고 한다. 레벨 1을 올리는데 수십 개월 이상 소요됐다는 연구 결과를 접하면 국내 기업이 1년 내에 CMM 레벨 3을 받는 것도 매우 어려운 일이다.
  팀 단위, 개발도구, 그리고 지속적인 관심과 노력 개발도구 역시 이제는 만만한 일이 아니다. 비주얼 베이직의 경우를 예로 들어 살펴보더라도 객체지향적인 개발을 위해서는 OOP와 UML 정도는 익혀야 한다. 보통 OOP와 UML을 습득하는 데만 1년 이상이 소요된다는 점을 생각하면 이 역시 쉬운 일이 아니다.
  ADO와 액티브X 기술에 대한 것들, MTS(Microsoft Transaction Server), MMQ(Microsoft Message Queue) 등을 배우는 일도 개인적으로, 혼자하기에는 한계가 있는 것이다. 비주얼 베이직에 대한 도움말만 보더라도 그 분량이 매우 엄청나다. 보기만 해도 기가 질릴 정도이다.
  즉, 이제는 개발을 하기 위해서는 소규모가 하나의 완성된 제품을 내놓기 위한 다양한 요소가 필요하다. 이를 습득하기 위해서는 참으로 오랜 기간이 필요하다. 모든 것을 습득한 뒤에 개발을 하기 위해서는 2∼3년을 공부만 한다 해도 시간이 부족하다.
2∼3년 뒤에는 또 다른 것이 나올 것이다. 비주얼 베이직 닷넷(VB.NET)만 해도 비주얼 베이직 6.0과는 전혀 다른 완전 OOP의 구조를 하고 있다. 지금까지 비주얼 베이직 개발자들이 소홀히 하던 객체지향개념을 모두 배워야 하며 게다가 XML이나 SOAP 등도 이해를 해야 하니, 산너머 산이다.
  이처럼 지속적인 관심과 노력이 매우 필요한 직업이 개발자다. 물론 회사에서 주어지는 일들만을 처리하겠다는 마인드를 가지는 개발자도 있겠지만, 2년만 새로운 기술 습득에 게으름을 피우면 2년 뒤에는 어떤 프로젝트에도 참여하기 어렵게 될 것이다.
최소한 개발도구와 언어에 대해서는 전문가가 되자. 개발도구에 대해서 전문가가 되기 위해 필요한 시간은 6개월 정도면 충분하다. 다양한 원서와 외국 저널, 외국 컨퍼런스 자료들을 공부하기에 6개월은 충분한 시간이다. 필자가 자주 가는 VBITS에서 한국 사람은 거의 찾기 어렵다. 중국인이나 일본인은 상대적으로 많이 볼 수 있다. 넓게 보면 그만큼 국내의 IT 기술에 대한 투자가 미약하다고 할 수 있다.
  그리고 많은 프로그램을 작성해보기를 권하고 싶다. 필자만 하더라도 비주얼 베이직을 처음 배울 때 500개의 예제를 혼자 만들어 비주얼 베이직의 모든 것을 직접 손으로 눈으로 머리로 체험을 했다. 500개의 예제를 만들어 연구해보는데, 필요한 기간은 고작 3개월이었다.
  대학에서 C 언어와 C++을 공부할 때도 약 30여권의 C언어 책을 읽고, 1000개의 예제를 만들어봤다. 이때 약 6개월 정도가 소요됐다. 이런 노력들은 다른 것을 습득할 수 있는 기본적인 능력을 배양을 해준다. 이런 노력 없이 전산학원을 다니거나, 전산과 전공을 한다 해도 그것은 크게 도움되지 않을 것이다.
  이런 과정을 통해 개발도구나 언어에 익숙해지면 프로그램을 개발할 수 있는 기본기는 충분히 갖춘 셈이다. 이제는 개발하면서 효과적인 개발에 대해 관심을 가져야 한다. 대부분의 개발자들이 개발의 결과에만 집착한다. 소프트웨어는 그 특성상 성능과 기능 개선이 지속적으로 진행되지 않는다면 그 생명력을 잃는데, 개발한 소스가 체계적으로 개발돼 있지 않다면 다음 버전은 새로운 출발을 해야 한다.
  따라서 개발자가 좋은 소프트웨어 개발에 대해 관심을 갖게 되면 방법론과 소프트웨어 공학에 대해 새로운 시각을 가지게 되는 것이다. 소프트웨어 공학이나 방법론은 이론으로만 배운다면 적용하기도 어렵고 적용 자체가 피상적이므로 좋은 효과를 얻을 수가 없다.
  학원 교육과 자격증 취득의 허실 혼자 공부하기 어렵다면서 학원을 추천해달라고 필자를 찾는 경우가 많았다. 그러나 국내에서 프로그래밍을 제대로 가르칠 수 있는 학원은 거의 없다고 할 수 있다. 이렇게 단정짓는 이유는 학원의 교과과정이 개발도구에 치우쳐 있거나 기초적인 이론에만 치우쳐 있기 때문이다.
  이것은 학원이 상대적으로 많은 비용을 차지하는 강사 비용을 줄이기 위해 주당 강의 시간을 줄이기 때문이다. 또한 유능한 강사의 경우 그 비용이 만만치 않으므로 그보다는 다소 지도 능력이나 경험이 떨어지지만 강의료가 덜 비싼 강사들을 선호하므로 더욱더 강의의 내용이나 질은 떨어진다.
  그래서 필요한 과목별로 제대로 가르치는 강사들을 찾아다니면서 배우는 것이 다소 비용이 들더라도 효과적인 방법이 아닐까라는 생각도 해본다. 문제는 능력(?) 있는 강사를 찾아내는 것이긴 해도, 도전해볼만한 가치는 있다.
실제로 필자는 국내에서 유명한 S사의 M학원에서 오라클에 대한 교육을 받은 적이 있다. 단기간의 프로젝트를 진행하기 위해 오라클에 대한 지식을 단기간에 얻을 수 있는 좋은 방법이라고 생각해 교육을 받았는데, 강사는 유창한 영어발음으로 책만 내내 읽으며 질문을 해도 질문 자체를 이해하지 못하거나 매우 형식적인 답변으로만 일관했다. 굴지의 M학원에서 이 정도라면 다른 학원들은 말할 나위도 없다.
  또한 M학원의 소프트웨어 전문가 과정을 졸업하면 MCSE와 MCSD를 취득하는 놀라운 실적을 보여주고 있지만, 실제 자격증 취득자를 면접한 결과 가장 기초적인 프로그래밍 상식조차 없는 경우도 있었다. 페이퍼 자격증의 폐해를 그대로 보여주는 것이다. 외국에서는 경력 없는 자격증은 인정조차 안되므로 학생이나 무경력자가 자격증을 취득하는 일은 그리 많지 않다고 한다.
MCSE란 최소한 2∼3년의 경력을 보증하는데, MCSE를 취득하고도 NT 설치가 안되면 그 원인을 파악하지 못하니 자격증이 보증하는 것이 도대체 무엇인지 모르겠다. 특히 국내에서는 고등학생들도 MCSE 자격증을 가지고 있다고 하니 외화낭비라는 생각까지 든다.
  빌게이츠와 스티븐잡스를 생각하라 개발자라면 가장 기초적인 전산의 학문에 대해서도 소양을 갖춰야 한다. 예를 들어서 알고리즘이나 데이터구조, 데이터베이스, 객체지향프로그래밍, 소프트웨어공학, 컴파일러 이론 등에 대해서는 기초지식을 습득해야 한다.
  유명한 개발자들은 대부분 기초학문에 있어서는 상당한 이론가임을 알 수 있다. 그런 기초가 없다면 모래 위에 집을 짓는 것과 같다. 필자가 큐(Queue)를 작성하는데 걸리는 시간은 30분 정도다. 동일한 작업을 전산과 4학년에게 시켰더니 약 5일이 걸렸다.
그 간단한 프로그램을 디버깅하는데 그렇게 오랜 시간이 걸리다니! 기초 학문에 대한 몰이해와 프로그래밍에 대한 연습이 부족하다면 충분히 발생할 수 있는 일이다. 이런 수준으로는 전산과를 나왔다고 말하기가 창피한 수준이다.
  '개발자 동의보감'에서도 이야기했듯이 개발자가 되겠다고 교육을 받아도 일부만이 개발자로 성장하고, 대부분은 다른 직업을 찾는다. 실제로 프로그래밍을 해보니, 그 과정이 '생 노가다'나 '허드렛 일'이어서 금방 실증이 나고, 시간 낭비로 치부해 버린다.
그러나 잘 생각해보면 미술가는 붓질을 통해 예술품을 만들고 소설가는 펜대를 굴려 베스트 셀러를 만들어낸다. 소프트웨어 개발로 성공한 빌게이츠와 스티븐잡스를 생각해보라, 그들이 한 생 노가다가 이뤄낸 결과를 바라보라.
  앞으로 나의 길은 어디에 소프트웨어 개발에 대해 대학이나 학원에서 배우고 나면, 그 다음 행로는 어디인가. 개발자가 가야할 길은 소프트웨어 개발뿐인가, 아니면 다른 길들도 있단 말인가. 개발자들의 역할은 어디까지인가 이런 내용들을 설명하기 위해서 가상적으로 소프트웨어 개발 회사(부서)를 세우고, 이 개발 회사에 필요한 인력들의 배치도를 만들어 소프트웨어에 관련된 직업들을 찾아보겠다. 직업별로 업무 영역이 구분되므로 배워나가야 할 방향도 다르다.
  개발업체에 따른 분류 먼저 회사를 세우려면 회사의 특징을 명확히 세워야 한다. 개발자가 근무하게 되는 회사의 종류를 명확히 나누기는 어렵지만, 근무하는 부서는 크게 네 가지 유형으로 나눌 수 있다. 어떤 회사는 이런 유형의 부서를 모두 갖추고 있는 경우도 있다.


  전산실(업무 개발실)

  패키지 개발(제품 개발실)

  외주개발(시스템 통합)

  IT 컨설팅


  전산실 전산실은 일반적인 기업의 내부에 있다. 자사의 업무를 파악해 필요한 시스템을 개발한다. 기업의 전산실은 다소 안정적이지만, 기업의 활동에 초점이 맞춰있어 기존 시스템의 유지 보수에 치우친 일이 많다.
  따라서 중소기업의 전산실은 새로운 기술을 도입하거나 습득하기 어렵고, 기업의 전산화를 위해 경영진을 직접 설득해야 하는 어려움에 부딪혀 좌절하는 경우가 많다고 한다. 경험자의 증언(?)에 의하면 대기업의 전산실도 외주 관리를 주로 하거나, 주어진 업무만을 담당하므로 역시 새로운 기술 습득에는 어려움을 겪고 있었다.
  특히 전산실에서 가장 핵심적인 인력은 업무를 아는 전산인력이므로, 제조업의 전산실의 경우 정규 전산을 배운 사원보다는 3년 이상의 업무 경험자가 특정한 기회에 전산을 배워 전산실로 발령난 사람들이 많다고 한다.
  패키지 개발 패키지 개발 업체는 패키지 제품(박스 제품)을 만들고 그 매출로 운영을 한다. 따라서 충분한 자금이 없는 경우가 많고, 개발 기간이 상대적으로 오래 소요되므로 운영에 매우 큰 어려움을 겪는다.
  그러나 상대적으로 인력들 사이에 유대관계가 좋고, 패키지가 시장에서 좋은 반응을 얻게 되면 판매가의 20% 정도의 높은 수익을 올릴 수 있으므로 소프트웨어 개발에 자신의 모든 것을 바치는 경우가 많다. 급여는 가장 낮은 편이지만, 대개 일에 만족하는 경우가 높다. 통상 개발자라고 할 때 패키지 개발 업체의 프로그래머를 가리키기도 한다.
  패키지 개발 업체는 제품이 갖는 한정된 범위의 기술과 내용에만 관심을 가지므로 의사결정의 범위가 다소 좁은 경우가 많다. 이것은 관심 밖의 기술들은 시장이 원할 때만 습득하게 되는 원인이 될 수 있다. 따라서 신기술의 습득보다는 기존 제품의 기술을 그대로 유지하려는 성격이 강할 수 있다.
  외주개발 외주개발을 주로 하는 업체는 인력파견 업체 또는 시스템통합 업체라고도 한다. 대형 프로젝트는 대기업이 수주를 해 인력관리만을 맡고, 실제 개발은 인력파견업체의 개발자들이 작업을 한다.
  예를 들어 대기업에서 M/M 비용을 600만원에 프로젝트를 수주하면 브로커업체에게 400만원에 하청을 줘서 5개정도의 인력파견업체를 모으도록 한다. 브로커업체는 다시 인력파견업체에 200∼300만원을 주고 인력공급을 받는다.
  급여의 수준은 인력파견업체가 높은 편이다. 대형 프로젝트의 경우 유지보수, 후속 개발 등의 작업들이 많으므로 개발자의 투입율이 100%를 넘어서 150%(한 사람이 1.5개의 프로젝트에 참여)인 경우들이 많으므로 충분한 자금 회전이 가능하기 때문이다.
그러나 수주한 프로젝트가 새로운 기술 요구 사항이 많고 단기간에 종료돼야 하므로 개발자의 스트레스가 매우 심한 편이다. 그래서 인력파견업체의 개발자는 하나의 프로젝트가 종료되면 회사를 옮기거나 프로젝트 도중에 그만두는 경우가 많으므로 인력의 이동이 심한 편이다.
  IT 컨설팅 IT 컨설팅 업체는 기술 컨설팅, 업무 컨설팅, 감리 컨설팅으로 구분될 수 있다. 업무 컨설팅 분야는 해당 분야의 업무 경력(대개는 MBA, CPA등 요구)이 필요하므로 개발자가 쉽게 도전하기 어렵고 기술 컨설팅이나 감리 컨설팅 분야는 도전해볼만 하다. 컨설팅은 상담과 브리핑을 통해 고객에게 필요한 것을 파악해 리포트 형태로 제공하는 업종이다.
연봉은 일반 개발 회사에 비해 2∼3배를 받는다. 대부분의 개발자가 꿈꾸는 직업이기는 하지만, 이런 회사들은 정확한 발음, 다소 높은 학력을 요구하는 편이서 취업이 쉽지 않다.
  개발 분야에 따른 분류 회사나 부서별 특성을 대략 이렇게 파악할 수 있지만, 개발 분야는 다른 이야기가 될 수 있다. 패키지 개발 업체라고 하더라도 유틸리티를 만들 수도 있고, 개발도구를 만들 수도 있기 때문이다. 그래서 개발 분야에 대해서도 알아야 한다.
개발 분야는 크게 나누면 <표 1>처럼 7가지 정도로 나눠볼 수 있다. 프로그램의 예는 출시 연도나 구성요소에 따라 약간씩 변할 수 있다. 예를 들어 웹 브라우저의 경우 인터넷 익스플로러는 시스템 프로그래밍에 가깝지만, 동일한 성격이라도 오페라는 유틸리티의 성격에 가깝다.
  우리 나라는 90년대초 K-DOS 이후에 운영체제에 대한 연구가 거의 진행되지 않다가 최근 다시 리눅스를 대상으로 한 바람이 크게 불고 있다. 개발툴 분야도 몇몇 제품이 나오기는 했으나 세계적인 제품으로 성장하지는 못했다.
  나모 웹에디터가 세계 시장에서 좋은 반응을 얻고 있다고 하니 좋은 소식을 기대해본다. 유틸리티 분야는 거원의 제츠오디오가 외국에서 폭발적인 인기를 얻어 널리 사용되고 있다. 다른 분야에서는 이렇다할 제품이 나오지 못하고 있거나 이제 시작 단계다.
업무에 따른 분류 지금까지 회사와 개발제품에 대해 알아봤는데, 소프트웨어 개발 업체라 해서 무조건 개발자로 근무하는 것은 아니다. 그 안에도 여러 가지 업무가 있고, 업무에 따라 다양한 직업이 있다. 여기서는 국내 컴퓨터 분야의 직업 뿐만 아니라 외국의 예도 함께 넣었다. 다만, 명칭은 국내의 명칭으로 통일했다. 참고로 디자인 분야의 다양한 직업을 반영하면 훨씬 더 많은 직업이 있겠지만, 여기서는 웹 디자이너에 한정시켰다.


제품개발자 : 박스로 팔리거나 다운로드 형태로 팔리는 패키지 제품을 개발한다.

시스템통합개발자 : 외주 개발에 참여하는 개발업무를 담당한다.

시스템프로그래머 :드라이버나 운영체제 기능의 일부를 개발한다.

품질관리자 ː 최근 2∼3년 사이에 나타난 대형 SI 프로젝트의 소프트웨어 품질관리 책임자를 말한다. 세부 업무를 보면 형상관리,

 

위험관리 등의 업무를 맡고 있다. ISO 9000, ISO 12207에 대한 연구를 별도로 해야 한다.

업무분석가 ː 주로 기업의 회계나 운영 시스템에 대한 업무를 컨설팅해 해당 조직에 맞는 설계를 내놓는 역할을 한다. 업무능력과

IT 능력을 어느정도 겸비하면 상대적으로 많은 연봉을 받을 수 있기 때문에 경영, 회계, 산업공학을 전공자가 많이 지원을 하는 분야다. 국내에 있는 외국계 컨설턴트들은 대개 업무분석가 또는 업무 컨설턴트인 경우가 많다.

프로젝트관리자 ː 프로젝트 진행의 모든 책임을 맡고, 예산부터 최종 결과물을 일정에 맞춰 진행하도록 감독한다. 현재는 경력 5년 이상인 개발자가 맡는 경우가 많은데, 프로젝트 관리를 제대로 하려면 SPICE나 CMM에 대한 학습이 필요하다.

전문테스터 ː 전문테스터는 아직 국내에서는 정착되지 않은 직업이다. 보통 개발자로서는 능력이 부족하지만, 개발을 이해할 수 있는 자가 그 역할을 담당하거나 신입사원이 담당하는 경우가 많다. 외국에는 개발자 1명당 테스터가 2명이라는 말이 있을 정도로 프로그램의 테스터에 대한 중요성을 인식하고 있지만, 국내에서는 개발자가 테스트까지 전부 맡아하는 경우가 많다. 그러나 이 분야도 앞으로는 품질관리가 중요해지면서 전문화될 가능성이 크다.

시스템엔지니어 ː 개발된 소프트웨어의 설치와 설치시에 발생하는 문제점, 운영시에 발생하는 문제에 대한 대책을 기술 지원하는 역할을 맡고 있다. 대개는 시스템엔지니어링 교육을 받거나, 운영체제를 잘 다루는 개발자가 맡기도 한다.

웹 디자이너 ː 웹 디자이너는 웹에서 필요로 하는 이미지 제작 업무 외에 DHTML과 자바 스크립트를 사용해서 홈페이지를 구성할 수 있는 능력을 갖춰야 한다. 웹 디자이너를 보면 이미지 도구에 의존적인 경우와 스스로 이미지를 창조하는 능력을 가진 경우로 나뉘는데, 창조력이 없다면 이미지 제작은 한계에 부딪히게 된다.

아키텍처 ː 소프트웨어에 대한 비전과 미래, 방향을 제시하는 사람으로서 미국의 빌게이츠 회장이 마이크로소프트에서 이 역할을 맡고 있다. 일반적으로 CIO가 전산 정책 결정의 최고 의사결정자라면, 아키텍처는 소프트웨어의 개발 방향 결정자라는 점에서 조금 차이가 있다.

기술컨설턴트 ː IT 관련 기술에 대한 컨설팅을 주업무로 한다. 국내에서는 활동하는 컨설턴트가 몇 명 되지 않는다. 기술 컨설턴트는 이론과 실무를 겸비해야 하므로 30대 초반의 차장급이어야 하는데, 국내에서는 병역문제로 30대 초반에 개발경력 경력 7∼9년차인 차장급이 거의 없기 때문이다.

감리컨설턴트 ː 국내에서 활동하는 컨설턴트의 대부분이 이에 해당하는데, 개발 전에는 업체 평가업무를 개발 후에는 개발된 소프트웨어에 대해 평가하는 역할을 한다. 대개 40대 후반에서 50대 초반에서 많이 활동하는 분야다. 감리 컨설턴트는 ISO 9000 심사관 자격증을 하나 정도는 가지고 있다.

전문기고가 ː 전문기고가는 기술분야의 기고를 업으로 한다. 국내 여건상 기고료가 매우 낮은 편이고, 출판사에서 높은 인세를 꺼려하고 있다. 게다가 책이 많이 팔려야 1만부이고 대부분 2∼3천부 정도만 팔리므로 생계 유지가 어려워 대부분 강사를 겸하고 있다. 외국에서는 전문 기고가는 백만장자들도 많다는 점에서 우리 나라와는 많은 차이를 보인다.
이와 같이 회사, 부서에 따라 요구되는 개발자의 성향도 다르고 같은 회사에서 내에서도 역할에 따라 다양한 직업이 있다는 점을 생각해 진로를 정하기 전에 많은 고려를 할 필요가 있다. 한 번 발을 들이면 분야를 바꾼다는 것은 매우 힘들므로 최소한 5년 앞을 내보다고 진로를 결정해야 할 것이다.

  마지막으로 소프트웨어 분야가 여성적인 직업이라는 점에 주목을 하자. 섬세함과 정교함이 요구되는 분야가 바로 소프트웨어 분야다. 그런데 정작 여성들은 개발자로서의 능력을 인정받는 경우가 매우 드물다. 그보다는 여성스러운 남성, 섬세한 남성들이 더 두각을 나타내고 있다.
  이런 현상은 여성들이 밤낮없는 근무시간과 끝없는 변화의 요구를 수용하기 어렵기 때문으로 보인다. 또한 여성 개발자에 대한 경영자나 관리자의 기피현상도 들 수 있다. 여성 개발자는 프로젝트가 완료되기 전에 그만두는 경우가 왕왕 있고, 서약서를 쓰고서도 계약근무기간을 지키지 않거나, 남자보다는 사소한 이유로 회사를 그만두는 일이 많다는 것이 경영자의 불만이다.
소프트웨어 개발분야는 그 어떤 분야보다 여성이 진출하기 쉬운 분야인데, 몇 가지 장벽으로 그 능력을 제대로 발휘하지 못한다면 국가적인 손실이라고 할 수 있다. 여성이 필요한 곳에 여성이 기피된다는 것은 사회적인 편견도 있겠지만, 소프트웨어 개발사의 근무형태 개선 없이는 여성이 제대로 역할을 하기 어렵다.
  어떤 개발자가 될 것인가 요즘 IT 업계에 사람이 부족하다고 컴퓨터와 관련이 거의 없던 사람들도 프로그램 개발을 배우겠다고 마구잡이로 덤벼들고 있다. 배우는 것도 좋지만, 개발자로서의 가능성에 대해서는 한번쯤 생각해야 할 것이다. 다음과 같이 개발자가 갖춰야 할 다섯 가지 능력을 기준화했다.

  협동심 : 함께 일할 때 얼마나 동료애를 발휘하며 조직 친화적인지를 나타낸다.

  기술력 : 작업의 기술적 능력으로 개발능력을 나타낸다.

  학습력 : 최소한 영어능력과 지속적인 학습이 가능한지를 나타낸다.

  인간성 : 사람됨됨이를 나타내는 것으로 측정하기 가장 어려운 항목이다.

  인내력 : 실증내지 않고, 얼마나 오랫동안 작업할 수 있는가를 나태낸다.

  이 다섯 가지 능력을 5단계로 나누고, 이 단계를 점수화해 선을 연결하면 자신의 개발자로서의 성향을 알 수 있다. 가장 높은 점수가 5이고, 가장 낮은 점수가 1이다. 여기서는 점수별로 해당하는 예시가 없어 점수화가 다소 어렵지만, 대략적으로 3을 평균으로 생각해 상대적으로 값을 매긴다.
  이 방법은 주로 약점을 분석하기 위해 사용되는 방법인데, 개발자의 유형을 파악하는 데에 적용을 해본 것이다. 아마 <그림 3>처럼 거의 정오각형의 유형이 완전한 개발자의 모습일 것이다. 그러나 이 모두를 다 갖춘 사람은 거의 찾기 힘들다. 실제적으로는 <그림 4, 5, 6>과 같은 형태가 나타나게 된다.
  <그림 4>와 같이 마름모가 나타나는 경우에는 개발자보다는 프로젝트 관리자쪽으로 눈을 돌려보는 것도 좋을 것이다. 기술은 다소 떨어져도 사람을 관리하고 작업에 대한 추진력이 높기 때문에 프로젝트 관리쪽으로 매진하면 좋은 결과를 얻을 수도 있다.
<그림 5>와 같이 우측지시자형은 기술력이나 학습력에 강하나 인간성 부분이 부족해 대인관계에는 어려움이 많다는 것을 뜻하므로 IT 컨설팅에 매진하는 것이 좋다. IT 컨설팅의 경우 단체 작업보다는 업체와 컨설턴트가 단독으로 작업하는 것이 많고 컨설팅을 위한 학습력이 매우 많이 요구되므로 우측지시자형에 적합하다.
  <그림 6>과 같은 사다리꼴형은 인내력이나 협동력이 상대적으로 매우 부족하므로 이런 경우에는 개발에 있어 코어라이브러리를 만드는 작업을 할당받는 것이 좋다. 라이브러리는 특성상 작업량은 적으나 꽤 많은 기술력을 요구하므로 누운 사다리꼴의 경우에 적합하다.
  이와 같이 자신을 판단할 수 있는 좋은 척도가 되므로 직접 스스로의 유형을 테스트해보기를 권한다. 나는 개발자로서 어떤 특성을 갖고 있는지 알 수 있다면 업무를 선택하거나 회사를 선택할 때도 도움이 되리라 생각한다.
  개발자란 예술가와 공학도의 야누스 어느 벤처기업의 이야기는 좋은 개발자의 필요성을 온몸으로 느끼게 해준다. K 기업은 지난해에 S대의 재학생에게 음성합성프로그램 개발을 용역을 줬는데, 개발된 프로그램의 성능이 외국에 비해 세 배 이상이었다.
  그러나 프로그램은 더 이상 개선되지 못하고 제품화에도 실패를 했다. 그 이유는 뛰어난 성능의 프로그램임은 분명한데 개발한 학생 외에는 아무도 수정할 수 없었기 때문이다. 학생은 개인적인 이유로 유학을 떠났고, 남은 개발자들이 제품화를 맡았는데, 여기를 수정하면 저기가 에러가 저기를 수정하면 여기에서 에러가 발생하니, 아무도 그 소스를 수정하지 못했다고 한다. 결국 그 기업은 2년간 투자한 사업을 접어야 했다.
 

 뛰어난 개발자들이 많지만, 좋은 개발자가 적은 이유는 무엇일까. 뛰어난 개발자와 좋은 개발자의 차이는 무엇일까. 그것은 단순한 능력 이상의 것이 요구된다는 것이다. 좋은 개발자가 되기 위해서는 최소 3∼5년 이상의 경력을 가지면서도 스스로 제품을 만들기 위한 정열과 제품을 만드는 능력을 갖는 것은 기본이다. 그 능력 외에 품질을 유지하기 위한 마인드가 필요하다. 그런 마인드가 없다면 좋은 소프트웨어를 만들 수 있는 좋은 개발자란 없다.
  국내는 IT 벤처의 열풍으로 수만명의 학생이 전공과는 관계없이 전산을 배운다고 한다. 지난 1년간에 정부에서 전산관련 취업교육에 사용한 비용만 수천억원에 이른다. 학원은 여기저기서 강사 구하기에 바쁘다고 한다. 그러나 속지 말라. 한줌의 지식보다 더 중요한 것은 마인드라는 것을!

  개발자란 예술가적인 정렬과 예리함, 감각을 지녀야할 뿐 아니라 평가하고 측정하고 품질을 유지하는 능력 또한 지녀야 한다. 왜 우리는 전세계적으로 팔리는 소프트웨어가 거의 없느냐의 문제에 대한 답이 아닐까 한다.
  바로 좋은 개발자가 없기 때문이다. 좋은 개발자의 능력을 가진 자가 한국에 있다고 해도 사회적 문화적 환경이 뒷받침되지 못한다면 개발자는 그 빛을 발하기 힘들다. 바로 여러분이 좋은 개발자이길 바란다. 오늘도 '개발의 득도'를 위해 전진해보자.

  정리 : 이종림 nowhere@sbmedia.co.kr

Posted by SB패밀리
보편적 관리자? 프로젝트 매니저(관리자)? 업종 변경?

당신이 개발자라면 어떤 것을 택하시겠습니까?



프로그래머 경력 3년차, 이제 어디로 갈까?

35세 정년 과감하게 뛰어 넘는 경력 관리 해법 찾기

지금 다니는 직장에 몇 개월째 근무하고 있는가? IT 종사자들의 근무 주기가 점점 짧아지고 개발자들도 한 분야만 알아서는 경력 관리를 하기가 힘들어졌다. 평생 직장 개념은 이미 사라진지 오래. 프로그래머라는 직업을 갖고 언제까지 일할 수 있을지 자문해 보자. 프로그래머 정년이 35세라는 말이 공공연히 나돌면서 이제는 자신의 경력을 꼼꼼하게 관리해야 할 때가 왔다. 목표를 확실히 세우고 50세가 되어 있을 자신을 그려 보자.


글·김영미 기자 kelly@pserang.co.kr 사진·권현진 기자 guswls 337@pserang.co.kr

중소 IT 업체에 근무하는 A씨는 요즘 아침에 출근해 컴퓨터를 켜면 암호로 잠궈 둔 이력서를 연다. 자신의 경력기술서를 주욱 보다가 한숨짓는 K씨. 프로그래밍이 좋아 IT 업계로 뛰어든지 어언 3년째, 회사에선 주임으로 승진도 했고 자리도 잡았다. 그동안 갖가지 프로젝트에 밀려 일주일에 서너 번은 밤을 새고 까다로운 클라이언트사의 비위도 맞춰 가면서 프로그래머 경력을 쌓아 왔지만 요즘은 왠지 모르게 자괴감이 밀려 온다.
프로그래머 정년 35세라는 주변의 이야기들을 차치하고서라도 지금하고 있는 업무를 언제까지 할 수 있을지 의문이기 때문이다. 실력이 뛰어난 후배들은 계속 밀려들어 오고 학교다닐 때처럼 계속 공부를 한다는 것도 심적으로 부담이다. K씨는 회사를 계속 다니고는 있지만 앞으로 어떻게 경력을 관리해야 할지 심각하게 고민 중이다.

프로그래머는 왜 이직율이 높을까?

취업 사이트인 인쿠르트의 통계에 따르면 IT 종사자의 이직 주기는 상당히 짧은 것으로 나타났다. 인크루트( www.incruit.com)가 1,982명의 IT 재직자를 대상으로 이직 동향에 대해 설문 조사를 실시한 결과 1~2년마다 회사를 옮기는 종사자가 38.4퍼센트(761명)에 달했다. 5년 이상 주기로 회사를 옮기는 종사자는 4.7퍼센트(94명)에 불과한 것으로 나타났다. 이직시 10~20퍼센트의 연봉을 올려 받는 것으로 드러났다.
‘2~3년마다 이직한다’는 대답은 31.4퍼센트, 3~5년 단위로 이직하는 경우는 13.6퍼센트, 1년 이하 주기로 이직하는 경우는 11.9퍼센트 등이었다. 전체 이직 주기로 보면, 1~3년마다 이직하는 비율이 전체의 69.8퍼센트에 달해 대다수 IT 종사자들이 1~3년 내에 다른 직장으로 옮기는 것으로 조사됐다. 이직 사유로는, ‘회사의 비전이 없기 때문’이라고 답한 응답자가 33.5퍼센트(664명)로 가장 많았고, 그 뒤를 이어 ‘자기 계발을 위해 이직한다’가 33.1퍼센트(655명)에 달해 직장 생활에서 회사 비전과 개인의 발전 가능성을 가장 중시하는 것으로 드러났다.

그렇다면 프로그래머들은 왜 이직을 자주 하는 것일까? 물론 고용 불안에서 오는 구직자들의 자발적 이직도 있지만 거꾸로 이야기하면 그만큼 기회가 많기 때문이라고 해석할 수도 있다.
잡서치코리아의 이기대 사장은 국내 2~3년차 프로그래머들의 문제점을 IT 산업 계층 구조에서 기인한다고 설명한다. 그는 “국내 IT 업체들은 산업 자체가 영세한데다 SI 업체가 많아야 프로그래머가 대접을 받는데 SM(시스템 운영) 업체들이 대부분이다. IT업체들이 2차, 3차로 하청을 주는데 이 하청 업체에 2~3년차 프로그래머들이 몰려 있다. 따라서 업무 환경도 열악하고 자기 개발할 여유도 없이 경력을 쌓게 된다. 노가다성 코딩 작업만 하다보니 자신의 능력을 업그레이드할 기회가 없어 슬럼프에 빠진다”고 말한다.


프로그래머 10년, 관리자 10년
국내 IT 환경에서 개발자들이 전산 업무를 10년 정도 하면 관리자로 승진하고 더 이상 개발자로 일하지 않는다. 이는 본인의 선택적인 측면이 많지만 장유유서(長幼有序)로 대변되는 사회분위기와 무관하지 않다. 또 30대 중반이 되면 아이들이 커가고 밤새고 일하는 것이 즐겁지 않다. 관리하고 싶은 마음이 생기는 것이다. 여기에서 프로그래머 ‘35세 정년’이라는 말이 나오기 시작한다.


개발자로서 수명이 다한 인력들은 다른 분야로 전직하거나 개발자들을 관리하는 매니저로 승진하는 것이 통상적인 국내 프로그래머들의 경력 지도이다. 일부 IT 컨설턴트라고 하는 개발자와 관리자의 중간 단계의 직종으로 자리를 옮기는 경우도 있지만 문과 출신이면서 IT 기업 근무 경력이 있고 경영학 석사 등 각종 학위로 무장한 이들에 밀려 빛을 보지 못하는 경우가 많다. 사정이 이렇다보니 서른만 넘겨도 의욕을 상실하는 프로그래머들도 생겨난다. 그렇다면 경력 관리는 언제, 어떻게 시작해야하는 것일까. 헤드헌팅 포털 HP존에 따르면 헤드헌터들은 이직 희망자들의 가장 큰 문제점을 경력 관리 미흡과 조직 생활 부적응을 꼽았다.


전문가들은 초보 개발자 시절부터 자신의 목표를 명확히 해야한다고 말한다. 삼성멀티캠퍼스 교육사업팀 오형석 과장은 “자신이 제너럴리스트로 성장할 것인지 스페셜리스트로 성장할 것인지에 대해서는 확실한 주관이 있어야 한다”고 말한다. 경력 관리에 기술적인 접근이 필요하다는 것.


계속 프로그래밍을 할 것인지, 개발 지식을 토대로 기술 영업을 할 것인지, 프로젝트 매니저가 될 것인지 2~3년차에 결정해야 한다는 인크루트 김현정 IT 담당 부장은 “취업 시장에서는 프로그래머의 수명은 약 20년이다. 이 중 순수하게 프로그래밍(코딩) 업무만으로 파악하면 약 10년 정도이다. 이는 다른 산업군에 비하면 상당히 길다. 프로그래밍 분야 즉, 코딩 작업을 할 수 있는 기간이 10년이라는 이유는 IT 트렌드가 끊임없이 바뀌고 있고 개발 언어 또한 계속 교체되기 때문”이라고 쐐기를 박는다. 그러나 이 기간 동안 프로그래머 업무에 충실하고 경력 관리를 제대로 하면 길을 얼마든지 있다.

변화에 알맞는 경력 지도 그려야
올해 31세인 5년차 프로그래머 장윤기씨의 경우 현재 네 번째 직장에 다니고 있다. 이 중 1년씩 일한 직장이 2곳, 3년 동안 일한 업체를 거처 포스데이타라는 SI 업체에 안착했다. 그는 중소 IT 업체에서 경력을 쌓고 대기업으로 경력을 업그레이드 했다. 올해 30세인 권영민 시큐어소프트 과장의 경우 병역특례 경력을 합하면 프로그래머 경력만 7년째다. 비주얼 C에서 자바로 업그레이드하고 프로그래머로써 경력을 쌓다가 경력이 10년쯤되면 독자적인 프로젝트 매니저로 승부를 낼 생각이다.


프로그래머의 일반적인 경력 지도는 약 10여 년의 프로그래머 생활을 거친 후 기술 영업을 하거나 전산실 매니저가 되거나 프로젝트 매니저로 성장하는 방안을 들 수 있다. 기술적인 백그라운드가 있고 전문성이 있기 때문에 가능하다.


이 중 프로그래머 실력을 기반으로 성장하고 싶은 개발자들은 프로젝트 매니저에 관심을 가져보자. 급변하는 IT 트렌드를 봤을 때 개발자가 2~3가지 프로그래밍 언어까지는 학습이 가능하지만 그 이상은 어려운 것이 현실이다. 메인프레임을 사용하던 개발자가 C/S 환경에서 웹으로 전환하기가 사실상 힘들기 때문이다.


프로젝트 매니저는 프로젝트 일정을 관리하고 전산 자원을 배분하여 프로젝트를 효율적으로 이끄는 역할을 하는 핵심 인력이다. 자신이 수행한 프로젝트로 경력을 인정받는 프로그래머는 금융이나 통신과 같은 산업 분야 별로 경력을 쌓거나 원가, 회계, 재무와 같은 직무별 커리어를 쌓는 것이 경력 관리에 도움이 된다.


분야별 전문 지식을 토대로 관리 능력을 쌓아가는 것이 프로그래머 경력을 극대화시키는 방법 중 하나이다. 국내의 경우 ‘관리자=People Management’로 인식되는 경향이 있으나 점차 바뀌어가고 있다. 이는 우리나라 전산인들이 프로젝트 관리를 제대로 하지 않는다는 반성에서 비롯된다. 잡서치코리아 이기대 사장은 “프로그래머로 경력을 쌓고 관리자가 되면 피플 관리가 아닌 프로젝트 관리로 포지셔닝을 해야 한다. 건별 계약이든 기업의 전산 관리자로 있든 경력이 어느 정도 쌓이면 PM(Project Manager)역할을 할 수 있어야 하는데 국내에는 이러한 인력이 턱없이 부족하다. SI 인력도 적을 뿐더러 프로젝트 관리 능력이 떨어져 결과적으로 IT 결과물의 퍼포먼스가 떨어진다”고 말한다.


실제로 30대 중반의 프로젝트 매니저를 헤드헌팅업체에서 많이 찾는데 국내에서 찾기 힘들다는 것이 전문가들의 견해이다. 전반적인 기술이나 프로젝트에 대한 관리 능력을 갖춘 전문가가 시급하다는 것. 프로그래머는 많아도 관리자는 드문 것이 국내 전산 환경의 현 주소이다.


경력을 쌓아 교육 분야로 진출하는 것도 바람직하다. IT 교육 전문가가 턱없이 부족하기 때문이다. 대학이나 기업에서도 IT 분야를 가르칠 사람이 없어 애를 먹고 있다.


얼마 전 한 중견 IT 업체는 최근 호주 소프트웨어 회사의 수석 엔지니어를 초빙해 3일간 프로그램 교육을 실시했다. 강사료는 1,000만 원. 국내에서는 이같은 인력을 찾을 수 없었다는 업체 측의 전언이다. 노동연구원 조사 결과에서도 고급 인력이 절대적으로 부족한 직종 1위는 IT 교육 전문가이다. 지난해 보고서에 따르면 대학과 학원, 직업 훈련 기관의 부족한 IT 교원은 1,374명이었다. 1년차 개발자 100명 중 5년이 지나고 남는 개발자가 15명밖에 안된다는 말이 이를 반증해 준다.



조직 내 커뮤니케이션·리포팅 능력 중요
일반적으로 프로그래머의 특성을 살펴 보면 외곬수에 커뮤니케이션 능력이 약하다는 평가를 내리는 사람들이 많다. 한 대기업의 마케팅 부서 이사는 “자신의 의사를 적절히 표현하지 못하는 프로그래머들이 많다. 회의 시간에 한 마디도 못하거나 요점없는 이야기로 시간을 낭비하고 대답을 못하거나 의견을 제시하면 무조건 할 수 없다고 말하는 개발자들이 많아 현업에서 불만”이라고 이야기한다. 어려운 프로그래밍 서적만 보다보니 커뮤니케이션 능력이 상대적으로 떨어진다는 것.


인크루트 김현정 부장은 “프로그래머들은 업무 성향이 오기와 비슷한 독특한 특성이 있다. 커뮤니케이션 활동이 폐쇄적인 데다 오픈마인드를 갖고 있지 않다”고 평가한다. “IT 조직은 서비스 조직이라는 생각을 갖고 있어야 한다. 지원 조직이고 현업을 서비스하는 조직이라는 마인드를 갖고 있어야 한다. 프로그래머가 현업과의 커뮤니케이션에서 융통성을 발휘하고 서포팅을 잘하면 인정받기도 쉽다”고 조언한다. 그러나 프로그래머들이 현업을 이해가기가 만만치 않은 것이 현실이라고 말한다.


실제로 프로그래머들 중 상당수는 상사와의 갈등이나 동료와의 불협화음으로 이직을 하려는 개발자도 많다. 소규모 IT 기업에서 근무하던 개발자 B씨는 회사가 급성장 하면서 조직이 확대되어 개발 인력이 수십 명으로 불어났으나 이에 적응하지 못하고 실직한 경우다. 이전의 가족같은 분위기가 사라진 데다 새로 영입된 팀장의 업무 스타일에 적응하지 못한 것. 조직 내 커뮤니케이션이 프로그래머에게 큰 문제로 나타난다는 것이 전문가들의 의견이다. 이기대 사장은 “커뮤니케이션을 잘하는 가장 손쉬운 방법은 상대방이 하는 말을 주의 깊게 듣고 있다가 그 방식으로 그대로 설명하는 것”이라고 조언한다.


프로그래머들에게 또 하나의 벽은 글쓰기와 프리젠테이션 능력이다. 자신의 생각을 표현해 내는 과정에서 타 부서인들의 이해를 구하려는 노력이 필요하다는 것. 권영민 시큐어소프트 과장은 “개발자들이 스케줄 관리와 다큐멘테이션에 약하다. 프리젠테이션 능력과 글쓰기 노력을 병행해야 한다. 자신이 가진 기술만큼 중요한 것이 생각을 표현해 내는 능력”이라고 말한다.



장기계획 세우고 목표 확실히 설정
초보 개발자 시절부터 장래에 대한 계획을 확실히 세우고 꾸준히 계단을 올라 가면 더할 나위 없겠지만 안타깝게도 경력 관리에 대해 여유를 갖게 되는 것은 시간이 한참 흐른 후이다. 이번 기회에 다시금 자신을 되돌아보는 계기를 만들어 보자.


여러 가지 이유 때문에 실직했다면 공백을 최우선으로 줄이는 것이 경력 관리에 흠을 없애는 방법이다. 무엇보다 공백 기간이 6개월 이상 장기화되지 않도록 노력해야 한다. 프로그래머에게 있어 반년 이상의 공백은 일을 안한다는 의미가 아니라 직무 능력이 떨어짐을 의미하기 때문이다. 따라서 실업이 장기화될 가능성이 있을 때는 차라리 직장 눈높이를 낮춰서라도 재직 상태를 유지하는 것이 좋다. 불가피하게 공백기를 가졌다면 업무의 연속성을 가져야 한다. 아르바이트를 하거나 커뮤니티 활동, 연구, 단기 프로젝트 활동을 할 수 있도록 노력해야 한다.


특히 유의할 점은 일을 놓고 싶더라도 목표없이 그만 둬서는 안된다. 업무를 진행하면서 주기적으로 휴식을 취할 수 있는 공간을 만들어야 한다. 또, 취업 정보를 꾸준히 받을 수 있는 상황인지 살펴 봐야 한다. 퇴직 준비를 하면서 정보 검색을 하지 않았다면 반성해야 한다. 프로젝트 매니저로서 대우를 받을 수 있는 경력은 5년차 이상일 때 옮기는 것이 좋다. 프로젝트 경험 많은 7년차가 가장 좋다.


슬럼프에 빠졌다면 보직이나 근무지를 바꿔 같은 일이라도 새로운 환경에서 일하도록 하는 것이 좋다. 업무와 관련된 교육 기회를 찾아 그간의 관점을 바꿀 수 있는 신선한 주제를 제공하여 분위기를 전환하는 것도 좋은 방법이다.
Posted by SB패밀리

훌륭한 컨설턴트가 되기 위한 세 가지 口訣
글/이정규/안랩코코넛 대표이사
 
필자는 한 때 컨설턴트 직업에 대한 지향을 가진 적이 있었다. 10년 전 까지만 해도 IT 컨설턴트는 업계 경험이 적어도 20년은 넘어야 명함을 내밀 수 있다는 것이 일반적인 생각이었다. 그러나 최근에는 젊은 프로페셔널도 컨설턴트의 직함을 새겨 다니는 것을 보면 컨설팅 업무의 모델이 많이 변화된 것 같다.

필자의 경험에서 배움의 열망이 컷 던 시절인 90년 중반, 일본에서 미국의 D.H. Brown에서 온 두 명의 컨설턴트로부터 교육을 들었다. 일본 수강생들과 함께 영어로 수업을 들었는데, 영어에 대한 핸디캡인지 일본 수강생들은 거의 질문도 없었고, 강의 후에 강사를 심심하게 만들었다. 필자는 강사들에게 수업 후 세션을 제안했고, Pub 바에서 맥주를 겸한 저녁식사를 같이 하게 되었다.

맥주를 몇 잔 하자 분위기가 화기애애해졌고, 필자는 한 컨설턴트들에게 질문을 던졌다. “훌륭한 컨설턴트가 되려면 무엇이 필요한가? 당신은 25년 이상 컨설팅하면서 깨달은 중요한 것들이 무엇인지 전수해 줄 수 있는가?”. 질문은 받은 그는 씩 웃으며 “오늘 맥주 값 당신이 내겠소?”라고 묻자 나는 선뜻 “그렇다.”고 했다. 골똘히 ? 珝▤求?그는 다음과 같은 이야기를 해주었다.

훌륭한 컨설턴트 혹은 프로젝트 매니저는 다음의 세가지 지침을 잘 지키면 된다는 것이다. 이 지침은 너무 심오하고, 일반인들에게는 오해를 불러 일으키는 말이니, 필자만 알고 있고 절대로 제3자에게는 노출시키지 말라는 것이었다. 필자는 그의 말을 냅킨에 메모하고 오늘날까지 기억하고 또한 명심하고 있다.

오늘 필자가 그 컨설턴트의 무림비급(?)을 전달하지만, 잘못 수련하여 주화입마(走火入魔) 에 빠지는 것은 책임질 수 없다. 무엇보다 그 행간의 의미를 정확하게 파악하는 것을 주지하기 바란다.

첫째, 내일 할 일을 오늘 하지 마라!(Don’t do what you can do tomorrow!)
둘째, 남이 할 수 있는 일을 네가 하지 마라!(Don’t do what others can do!)
셋째, 받은 만큼 일해라(Don’t overwork above what you got paid!)


이 세 가지 지침을 듣는 순간, 필자는 한대 얻어 맞은 것처럼 망연해 졌다. 내용이 “성실과 정직”과는 거리가 멀게만 느껴지는 궤변같이 느껴졌기 때문이다. 설명은 이랬다. ‘첫 번째, 많은 컨설턴트는 내일 할 수 있는 일임에도,! 조바심에 미리 그 일을 앞당겨 하려는 습성을 가졌다. 이는 프로? ㎷?구성 원을 과로에 시달리게 만들고, Man-month 기반 프로젝트의 경우 고객이 서비스 금액에 의문을 갖게 한다는 것이다.

두 번째, 프로젝트팀은 다양한 경력과 스킬(Skill)을 보유한 “다기능팀”이어야 한다. 그런데 남이 맡은 일을 내가 해 버리면 상대방의 존재가치를 떨어뜨림은 물론, 자신의 과업을 위한 시간을 허비하게 되고, 조직의 구성도 최적화되어 있지 않다는 것을 반증한다는 것이다.

세 번째, 서비스 초기에 분명치 않던 고객의 요구사항은 시간이 지나갈수록 더욱 많아지게 마련이고, 협상력이 떨어지는 프로젝트관리자는 추가적인 수익이 없는 과도한 일을 멤버들에게 전가하게 마련인데, 이러한 고객의 요구는 더욱 거세진다. 이는 프로젝트의 납기를 지연시킴은 물론 수익성과 직원의 모럴을 떨어뜨리게 된다. 그는 “때때로, 컨설턴트는 고객의 과제를 즉시 해결할 방법을 제시할 수 있더라도, 계약된 기간에 맞추어 해답을 내는 것이 더욱 현명하다”는 코멘트도 덧붙였다.’

강사의 말을 필자가 잘 이해하였다고 하자, 그는 이야기의 반만 했다고 하며, 위의 원칙은 다음의 세 가지 대응원칙과 균형을 이루어야 한다고 했다! .

첫째, 내일 할 수 없다면, 반드시 오늘 해야 한다.
둘째, 남이 할 수 없다면, 가르쳐서 해내거나 네가 직접 해야 한다.
셋째, 일을 더했다면, 보상을 요구한다.


설명하면 첫 번째, 일정을 맞추기 위하여 오늘 해당과제를 완료해야 한다면 반드시 해내야 한다는 것이다. 두 번째, 타인에게 과업 위임을 할 수 없다면, 해낼 수 있도록 교육을 하거나, 시간에 쫓긴다면 내가 직접 해내야 한다는 것이다. 세 번째, 계약된 공수 이상의 과업을 수행하였다면, 그 대가를 요청하거나 추후 2차 사업에서 보전할 수 있도록 고객을 빚쟁이로 만들어야 한다는 것이다. 당시에 앞 부분의 세 가지 원칙 보다 뒤 부분의 세 가지 대응 원칙이 필자는 이해하기가 쉬웠다. 여러분은 어떠한가? 앞 부분의 세 가지 원칙을 쉽게 이해하였다면 여러분은 분명 내공이 출중한 컨설턴트로서의 자질이 있다 하겠다.

필자 이정규 안랩코코넛 대표이사는 현 정보보호산업협회의 부회장, 정보관리기술사, 미국공인회계사로 IBM과 안철수연구소를 거쳐 안랩코코넛에 이르기까지 22년간 IT 산업에 종사하여온 IT 전문가이다
Posted by SB패밀리